> I'd love to see the docs on that early stuff and see if Joe Ossanna
> added in his own magic or was he carrying forward earlier magic.
Here are scans of non-unix roff in 1971: https://www.cs.dartmouth.edu/~doug/roff71/roff71
I also have 1969, but it's bedtime and that will have to wait.
Relative numbers (+n), roman numerals, .ti, top and bottom margin settings,
.po, running titles, tab settings, hyphenation and footnotes were not in
Saltzer's runoff. Most other features were.
Doug
I found the following in the archive:
To: cbunix23(a)yahoo.com
Cc: Warren(a)plan9.bell-labs.com, Toomey(a)plan9.bell-labs.com,
<wkt(a)tuhs.org>
Subject: Re: cb/unix tapes
From: Dennis Ritchie <dmr(a)plan9.bell-labs.com>
Date: Tue, 15 Jul 2003 21:23:37 -0400
They've arrived on my doorstep; thanks, Larry.
9-track drives seem thin on the ground, but we'll
see.
Dennis
Does anybody know what became of those tapes? I know it was 13 years ago,
but it's one of the few sitings of CB-Unix tapes I could find...
Warner
Well, if we're going to get into editor, erm, version-control wars,
I'll state my unpopular opinion that SCCS and RCS were no good at
all and CVS only pretended to be any good. Subversion was the first
system I could stand using.
The actual basis for that opinion (and it's just my opinion but it's
not pulled out of hyperspace) is that the older systems think only
about one file at a time, not collections of files. To me that's
useless for any but the most-trivial programming (and wasn't
non-trivial programming what spurred such systems?). When I am
working on a non-trivial program, there's almost always more than
one source file, and to keep things clean often means refactoring:
splitting one file into several, merging different files, removing
files that contain no-longer-useful junk, adding files that
implement new things, renaming files.
A revision-control system that thinks only about one file at a
time can't keep track of those changes. To me that makes it
worse than useless; not only can it not record a single
commit with a single message and version number when files
are split and combined, it requires extra work to keep all
those files under version control at all.
CVS makes an attempt to handle those things, but the effect
is clunky in practice compared to successors like svn.
One shouldn't underestimate the importance of a non-clunky
interface. In retrospect it seems stupid that we didn't have
some sort of revision control discipline in Research UNIX, but
given the clunkiness of SCCS and RCS and CVS, there's no way
most of us would have put up with it. Given that we often had
different people playing with the same program concurrently,
it would have taken at least CVS to meet our needs anyway.
Norman `recidivist' Wilson
Toronto ON
George Michaelson writes:
> What Larry and the other RCS haters forget is that back in the day,
> when we all had more hair, RCS was --->FAST<--- and SCCS was S.L.O.W.
>
> because running forward edits on a base state of 1000 edits is slow.
> Since the majority action is increment +1 on the head state the RCS
> model, whilst broken in many ways
> was FAST
>
> -G
And also that RCS had a much friendlier interface.
John Reiser did do his own paging system for UNIX 32/V.
I heard about it from friends at Bell Labs ca. 1982-83,
when I was still running systems for physicists at Caltech.
It sounded very interesting, and I would love to have had
my hands on it--page cache unified with buffer cache,
copy-on-write from the start.
The trouble is that Reiser worked in a different group
from the original UNIX crowd, and his management didn't
think his time well spent on that work, so it never got
released.
I remember asking, either during my interview at the Labs
or after I started work there, why the 4.1 kernel had been
chosen instead of Reiser's. It had to do with maintainability:
there were already people who could come in and hack on the
Berkeley system, as well as more using it and maintaining it,
whereas Reiser's system had become a unicorn. Nobody in
1127 wanted to maintain a VM system or anything much close
to the VAX hardware. So the decision was to stick with a
kernel for which someone else would do those things.
Once I'd been there for a year or so and settled in, I found
that I was actually looking after all that stuff, because I
was really interested in it. (Which seemed to delight a lot
of people.) Would we have ended up using Reiser's kernel had
I been there a couple of years earlier? I don't know.
It is in any case a shame that jfr's code never saw the light
of day. I really hope someone can find it on an old tape
somewhere and we can get it into the archive, if only because
I'd love to look at it.
Norman Wilson
Toronto ON
> From: Steve Simon
> i went for a student placement there but didnt get it - i guess my long
> hair (then) didn't fit as the interview seemed good.
Maybe you seemed too honest! :-)
Noel
