I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Seventh Edition:
http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html
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.)
----- Forwarded message from meljmel-unix(a)yahoo.com -----
Warren,
Thanks for your help. To my amazement in one day I received
8 requests for the documents you posted on the TUHS mailing
list for me. If you think it's appropriate you can post that
everything has been claimed. I will be mailing the Unix TMs
and other papers to Robert Swierczek <rmswierczek(a)gmail.com>
who said he will scan any one-of-a-kind items and make them
available to you and TUHS. The manuals/books will be going
to someone else who very much wanted them.
Mel
----- End forwarded message -----
Hi all, I've just heard that the Usenix board of directors do not want
to explicitly celebrate the 50th anniversary of Unix.
It's been suggested that we, the TUHS members, both lobby the board and
also offer our assistance to help organisation such a celebration.
Who, on the list, would put their hands up to help organising something
that coincided with the 2019 Usenix ATC in July 2019?
I'd like to get the bare bones of an organising team, then approach the
Usenix board, offer our help and ask them to support us.
What do you think? 11 months to go.
Thanks, Warren
P.S. Nokia Bell Labs are also going to organise something, possibly a month
earlier but I have no solid details yet.
I was just reading this book review:
http://www.pathsensitive.com/2018/10/book-review-philosophy-of-software.html
and came across these paragraphs:
<book quote>
The mechanism for file IO provided by the Unix operating system
and its descendants, such as Linux, is a beautiful example of a
deep interface. There are only five basic system calls for I/O,
with simple signatures:
int open(const char* path, int flags, mode_t permissions);
ssize_t read(int fd, void* buffer, size_t count);
ssize_t write(int fd, const void* buffer, size_t count);
off_t lseek(int fd, off_t offset, int referencePosition);
int close(int fd);
</book quote>
The POSIX file API is a great example, but not of a deep
interface. Rather, it’s a great example of how code with a very
complicated interface may look deceptively simple when reduced to C-style
function signatures. It’s a stateful API with interesting orderings
and interactions between calls. The flags and permissions parameters
of open hide an enormous amount of complexity, with hidden requirements
like “exactly one of these five bits should be specified.” open may
return 20 different error codes, each with their own meaning, and many
with references to specific implementations.
The authors of SibylIFS tried to write down an exact description of the
open interface. Their annotated version[1] of the POSIX standard is over
3000 words. Not counting basic machinery, it took them over 200 lines[2]
to write down the properties of open in higher-order logic, and another
70 to give the interactions between open and close.
[1]: https://github.com/sibylfs/sibylfs_src/blob/8a7f53ba58654249b0ec0725ce38878…
[2]: https://github.com/sibylfs/sibylfs_src/blob/8a7f53ba58654249b0ec0725ce38878…
I just thought it was a thought-provoking comment on the apparent elegance
of the Unix file API that actually has some subtle complexity.
Cheers, Warren
The last couple of days I worked on re-setting the V3-V6 manuals.
I reconstructed V5 from the scan as best I could, unfortunately some
pages were missing.
You can find everything I used to do this here,
please read the BUGS section:
https://github.com/aap/unixman
The results can be found here, as HTML and PDF:
http://squoze.net/UNIX/v3man/http://squoze.net/UNIX/v4man/http://squoze.net/UNIX/v5man/http://squoze.net/UNIX/v6man/
Reconstructing V1 and V2 n?roff source and converting the tty 37 output
to ps is something I want to do too, but for now this was exhausting
enough.
Now for the questions that I arose while I was doing this:
Are there scans of the V4 and V6 manual to check my pdfs against?
Where does the V5 manual come from? As explained in the README,
some pages are missing and some pages seem to be earlier than V4.
Is there another V5 manual that one could check against?
Why is lc (the LIL compiler) not in the TOC but has a page?
And most importantly: is the old troff really lost?
I would love to set the manual on the original systems
at some point (and write a CAT -> ps converter, which should be fun).
Doing all this work made me wish we still had earlier versions
of UNIX and its tools around.
Have fun with this!
aap
Of interest to the old farts here...
At 22:30 (but which timezone?) on this day in 1969 the first packet got as
far as "lo" (for "login") then crashed on the "g".
More details over on http://en.wikipedia.org/wiki/Leonard_Kleinrock#ARPANET
(with thanks to Bill Cheswick for the link).
-- Dave
> From: Steve Johnson
> references that were checked using the pointer type of the structure
> pointer. My code was a nightmare, and some of the old Unix code was at
> least a bad dream.
I had a 'fun' experience with this when I went to do the pipe splice() system
call (after the discussion here). I elected to do it in V6, which I i) had
running, and ii) know like the back of my hand.
Alas! V6 uses 'int *' everywhere for pointers to structures. It also, in the
pipe code, uses constructs like '(p+1)' to provide wait channels. When I wrote
the new code, I naturally declared my pointers as 'struct inode *ip', or
whatever. However, when I went to do 'sleep(ip+1)', the wrong thing happened!
And since V6 C didn't have coercions, I couldn't win that way. IIRC, I finally
resorted to declaring an 'int *xip', and doing an 'xip = ip' before finally
doing my 'sleep(xip+1)'. Gack!
Noel
> From: Dave Horsfall
> We lost ... on this day
An email from someone on a related topic has reminded me of someone else you
should make sure is only your list (not sure if you already have him):
J. C. R. Licklider; we lost him on June 26, 1990.
He didn't write much code himself, but the work of people he funded (e.g.
Doug Engelbart, the ARPANet guys, Multics, etc, etc, etc) to work on his
vision has led to today's computerized, information-rich world. For people who
only know today's networked world, the change from what came before, and thus
his impact on the world (since his ideas and the work of people he sponsored
led, directly and indirectly, to much of it), is probably hard to truly
fathom.
He is, in my estimation, one of the most important and influential computer
scientists of all. I wonder how many computer science people had more of an
impact; the list is surely pretty short. Babbage; Turing; who else?
Noel