I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
> From: Paul Guertin
> I teach math in college ... Sometimes, during an exam, a student who
> forgot to bring their calculator will ask if they can borrow mine I
> always say "sure, but you'll regret it" and hand them the calculator
> After wasting one or two minutes, they give it back
Maybe I'm being clueless/over-asking, but to me it's appalling that any
college student (at least all who have _any_ math requirement at all; not sure
how many that is) doesn't know how an RPN calculator works. It's not exactly
rocket science, and any reasonably intelligent high-schooler should get it
extremely quickly; just tell them it's just a representational thing, number
number operator instead of number operator number. I know it's not a key
intellectual skill, but it does seem to me to be part of comon intellectual
heritage that everyone should know, like musical scales or poetry
rhyming. Have you ever considered taking two minutes (literally!) to cover it
briefly, just 'someone tried to borrow my RPN calculator, here's the basic
idea of how they work'?
I've forgotten who created stdio, USG or the research group. Can any of the
youthful BTL folks of the 1970's refresh my mind.
Given that stdio was invented and, in my opinion at the time, a reasonable
and usable standard interface to IO on Unix, I am curious why no standard
for networking was developed or proposed and discussed. Sockets just
defined a new and very quirky IO interface for Unix based systems.
Was any thought given to defining networking
model of IO in UNIX?
Advice is judged by results, not by intentions.
Here is a question for the old hands from the Labs, I’m trying to get the timeline of some development steps right.
The two main things are: when did the 4.1 merge take place, and when were ‘streams’ added?
Going by file dates, the surviving 8th edition source appears to be from 1985. I can see that a lot of files in /usr/include did not change after Jan 1982 (e.g. nlist.h). This suggests that early in 1982 the merge between 4.1 code and 32V code took place, to create the foundation for further development (“proto 8th edition”, so to speak).
Similarly, there are a dozen or so files in the kernel that all have a file date of November 1982. The most interesting one of these is “dtline.c”, a character mode Datakit driver: it uses ‘streams’. This suggests that there was a further code merge late in 1982 and implies that ‘streams’ were developed prior to that date.
From the S/F-Unix papers it seems that ‘streams’ did not exist in 1981, at least they are not mentioned in an otherwise comprehensive set of papers. On the other hand, the S/F-Unix work was done in the Exploratory group, not the Research group: maybe it was inappropriate to mention.
All in all, my hypotheses would be that:
- the 32V/4.1 merge took place early in 1982
- ‘streams’ were developed in 1982 on 32V (maybe also V7) systems
- a further merge took place late in 1982 that combined the new base with latest developments
Does that sound correct, or was it all different?
Related is the question when the "file system switch" was added. It must have been later than 1981 and before 1985, but I have not been able to pinpoint it further.
Thanks, everyone, for pointing out the "accident of history".
This is a little morality tale about clever programming.
Joe Ossanna would never have tokenized \s constructs that
way if the CAT typesetter had been capable of a wider
range of type sizes. Brian seems to have kept it for
backward compatibility. But groff was perfectly willing
to break backward compatibility in tokenizing command
names. Why not in \s?
I encourage Branden to go whole hog and let
\s123DEWEY WINS produce a banner headline.
> From: Warren Toomey
> Quite good
The second part of:
"Sixth Edition sources are much more widely available than earlier versions,
thanks largely to the Lions book"
is I believe incorrect, though; I reckon it's because V6 was so widely
distributed, both inside and outside Bell. Many more copies -> higher
probability of retention.
Also, from 'Source code listing for the Lions' Commentary in PDF and PostScript':
"in 1988 I discovered an old 9-track tape being discarded of a PDP11
backup. It was hard to determine what it was running, but it did have an
intact /usr/src/ tree of which most of the files were timesamped 1979, even
at that time it seemed ancient. So it was either 7th edition or a derivative
like PWB, which I believe it was.
Do you still have the tape, or its contents?
> From: Paul Ruizendaal
> The paper is from late 1981. ... When did FIFO's become a
> standard Unix feature?
Err, V4? :-) At least, that's when pipes arrived (I think - we don't have V4
sources, but there are indications that's when they appeared), and a pipe is a
FIFO. RAND ports just allowed (effectively) a pipe to have a name in the file
The implementation of both is pretty straight-forward. A pipe is just a file
which has a maximum length, after which the writer is blocked. A port is
just a pipe (it uses the pipe code) whose inode appears in the file system.
> From: Clem Cole
> I think the code is on one of the 'USENIX' tapes in Warren's archives.
Doc is here:
and sources for all that are here:
(port.c is in 'dmr', not 'ken'where it should be).