> I can think of at least 4 things, some big, some small, where post-V7
> Research Unix was influential
Besides streams, file system switch, /proc, and /dev/fd. v8 had the
Blit. Though Rob's relevant patent evoked disgruntled rumblings from
MIT that window systems were old hat, the Blit pioneered multiple
windows as we know them today. On the contemporary Lisp Machine, for
example, active computation happened in only one window at a time.
V8 also had Peter Weinberger's Remote File System. Unlike NFS, RFS
mapped UIDS, thus allowing files to be shared among computers in
different jurisdictions with different UID lists. Unfortunately, RFS
went the way of Reiser paging.
And then there was Norman Wilson, who polished the kernel and
administrative tools. All kinds of things became smaller and
cleaner--an inimitable accomplishment
> No clue what was new in V10
This suggests I should put on my to-do list an update of the Research
Unix Reader's combined table of man-page contents, which covers only
v1-v9. I think it's fair to say, though, that nothing introduced in
v10 was as influential as the features mentioned above.
Doug
I don't know the exact history of RFS a la System V, but I
don't think it was Peter Weinberger's stuff, and it certainly
wasn't his code. Nor his name: he called his first version
neta and his second netb (he knew it would be changing and
allowed for it in the name from the start).
I don't remember us ever calling it RFS, or even remote
file systems, inside 1127; we called it network file systems
(never NFS because the Sun stuff existed by then).
For those who don't know it, Peter's goal was quite different
from that of NFS. The idea behind NFS seems always to have
been to mount a remote file system as if it were local, with
a base assumption early on that everything was within the
same administrative domain so it was OK to make assumptions
about userids matching up, and running code as super-user.
Peter described his intent as `I want to be able to use your
disks, and that's a lot simpler if I don't have to get you
to add code to your kernel, or even to run a program as
super-user.' Hence the entirely-user-mode server program,
which could use super-user privileges to afford access as
any user if it had them, but also worked fine when run as
an ordinary user with only that user's file permissions.
We did in fact normally run it as super-user so each of
our 15 or so VAXes could see the file system tree on each
other, but we also occasionally did it otherwise.
That was one reason device files worked as they did, accessing
the device on the server end rather than acting like a local
special file on the client: we didn't care about running
diskless clients, but we did occasionally care about accessing
a remote system's tape drive.
Peter, being a self-described fan of cheap hacks, also wasn't
inclined to spend much time thinking about general abstractions;
in effect he just turned various existing kernel subroutines
(when applied to a network file system) into RPCs. The
structure of the file system switch was rather UNIX-specific,
reflecting that.
That also means Peter's code was a bit ad-hoc and wonky in
places. He cleaned it up considerably between neta and netb,
and I did further cleanup later. I even had a go at a library
to isolate the network protocol from the server proper, converted
the netb server to use it, and made a few demo servers of my own
like one to read and write raw FILES-11 file systems--useful for
working with the console file system on the VAX 8800 series,
which was exported to the host as a block device--and a daemon
to allow a tar archive to be mounted as a read-only file system.
In modern systems, you can do the same sort of things with FUSE,
and set up the same I-want-to-use-your-disks (or I want to get
at my own files from afar without privileges) scheme with sshfs.
I would be very surprised to learn that either of those borrowed
from their ancient cousins in Research UNIX; so far as I know
they're independent inventions. Either way I'm glad they exist.
Norman Wilson
Toronto ON
interesting to know the vax was a complete dead end.
i do remember jmk (rip) reporting on 9fans, maybe even releasing, the vax plan9 kenc compiler he discovered in a dusty corner of the dump filesystem.
I was intrigued and asked if there was anything else, but he said he said there where no kernel or driver fragments to go with it.
-Steve
For those interested in a quick feel for V8 and early SysV, I recommend the excellent unix50 stuff:
SSH to unix50: "ssh unix50(a)unix50.xn--org-9o0a
Password is “unix50”
You end up in a menu with:
SDF Public Access UNIX System presents ...
/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/
/~/~ H Y S T E R I C A L ~ U N I X ~ S Y S T E M S ~/~/
/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/~/
[a] UNICS (Version Zero) PDP-7 Summer 1969
[b] First Edition UNIX PDP-11/20 November 1971
[c] Fifth Edition UNIX PDP-11/40 June 1974
[d] Sixth Edition UNIX PDP-11/45 May 1975
[e] Seventh Edition UNIX PDP-11/70 January 1979
[f] Research UNIX 8 VAX-11/750 1984
[g] AT&T UNIX System III PDP-11/70 Fall 1982
[h] AT&T UNIX System V PDP-11/70 1983
[i] AT&T UNIX System V 3b2/400 1984
[j] 4.3 BSD MicroVAX June 1986
[k] 2.11 BSD PDP-11/70 January 1992
[w] What's running now?
[q] QUIT (and run away in fear!)
User contributed tutorials are at https://sdf.org/?tutorials/unix50th
Want persistent images? networking? more ttys? Join https://sdf.org
Don’t to exit from a run, press Ctrl-E to return to sims, type 'exit', type ‘q'
I just tried V8 and it still works, although the boot log suggests that an image reset may be in order.
Many, many thanks to whoever is maintaining this!
As one of the few remaining people who has actually worked
with the original dmr stream I/O system, I'd love to dive
into the debate here, but I don't have time. I can't resist
commenting on a few things that have flown by, though. Maybe
I can find time to engage better on the weekend.
-- If you think there were no record delimiters in the stream
system, you don't know enough about it. A good resource to
repair that is Dennis's BSTJ paper:
https://www.bell-labs.com/usr/dmr/www/st.pdf
It's an early description and some of the details later
evolved (for example we realized that once pipes were
streams, we no longer needed pseudoterminals) but the
fundamentals remained constant.
See the section about Message blocks, and the distinction
between data and control blocks. Delimiters were one kind
of control; there were others, some of them potentially
specific to the network at hand. In particular, Datakit
(despite being a virtual-circuit network) had several sorts
of control words, including message delimiters. Delimiters
were necessary even just for terminals, though: how else
does the generic read(2) code know to return early, before
filling the buffer, when a complete line has arrived?
-- It's hard to compare sockets to streams and make much
sense, because they are very different kinds of thing.
When people talk about sockets, especially when complaining
that sockets are a mess, they usually mean the API: system
calls like connect and listen and getpeername and so on.
The stream system was mainly about the internal structure--
the composable modules and the general-purpose queue interface
between them, so that you could take a stream representing
an (already set up) network connection and push the tty
module on it and have a working remote terminal, no need
for user-mode programs and pseudo-terminals.
It's not inconceivable to build a system with socket-like
API and stream internals.
-- Connection setup was initially done with network-specific
magic messages and magic ioctls. Later we moved the knowledge
of that messy crap into network-specific daemons, so a user
program could make a network call just by calling
fd = ipcopen("string-destination-name")
without knowing or caring whether the network transport was
TCP or Datakit or involved forwarding over Datakit to a
gateway that then placed a TCP call to the Internet or whatnot.
That's what the connection server was all about:
https://www.bell-labs.com/usr/dmr/www/spe.pdf
Again, the API is not specific to the stream system. It
wouldn't be hard to write a connection server that provided
the same universal just-use-a-string interface (with the
privileged parts or network details left up to daemons)
on a system with only socket networking; the only subtle
bit is that it needs to be possible to pass an open file
descriptor from one process to another (on the same system),
which I don't think the socket world had early on but I
believe they added long ago.
-- There's nothing especially hard about UDP or broadcast.
It's not as if the socket abstraction has some sort of magic
datagram-specific file descriptor. Since every message sent
and every message received has to include the far end's
address info, you have to decide how to do that, whether
by specifying a format for the data (the first N bytes are
always the remote's address, for example) or provide an
out-of-band mechanism (some ioctl mess that lets you
supply it separately, a la sendto/recvfrom, and encodes it
as a control message).
There was an attempt to make UDP work in the 9th/10th edition
era. I don't think it ever worked very cleanly. When I
took an unofficial snapshot and started running the system
at home in the mid-1990s, I ended up just tossing UDP out,
because I didn't urgently need it (at the time TCP was good
enough for DNS, and I had to write my own DNS resolver anyway).
I figured I'd get around to fixing it later but never did.
But I think the only hard part is in deciding on an interface.
-- It's certainly true that the Research-system TCP/IP code
was never really production-quality (and I say that even
though I used it for my home firewall/gateway for 15 years).
TCP/IP wasn't taken as seriously as it ought to have been
by most of us in 1127 in the 1980s. But that wasn't because
of the stream structure--the IP implementation was in fact
a copy of that from 4.2 (I think) BSD, repackaged and
shoehorned into the stream world by Robert T Morris, and
later cleaned up quite a bit by Paul Glick. Maybe it would
have worked better had it been done from scratch by someone
who cared a lot about it, as the TCP/IP implementors in the
BSD world very much did. Certainly it's a non-trivial design
problem--the IP protocols and their sloppy observance of
layering (cf the `pseudo header' in the TCP and UDP standards)
make them more complicated to implement in a general-purpose
framework.
Or maybe it just can't be done, but I wish someone had
tried in the original simpler setup rather than the
cluttered SVr4 STREAMS.
Norman Wilson
Toronto ON
> Sockets (which btw, totally SUCK PUS) were coded into things
> and even (YECHH) made POSIX and IETF spec status. Streams didn't stand
> a chance.
The question that originally pulled me into researching Unix networking 1975-1985 was more or less “how did we end up with sockets?”. That was 7 years or so ago, I now have a basic feel for how it came to be, and I also have better appreciation of the trade offs. What is the most “Unixy” of networking (as in the API and its semantics) is not something with an easy answer.
If I limit myself to the 1975-1985 time frame, I see three approaches:
1. The API used in Arpanet Unix, which was also used by BBN in its first reference implementation of TCP/IP
2. The BSD sockets API, in two flavours: the Joy flavour in BSD4.1a, and the Karels flavour in BSD4.1c and later
3. The Ritchie/Presotto IPC library / API from V8/V9. This evolved into SysV networking, but the original is the clean idea
At a high level of abstraction, there is a lot of similarity; close-up they are quite different. I like all three solutions!
One thing that struck my attention was that the Ritchie/Presotto IPC library has the concept of “calling” a host and the host/network can reply with a response code (“line busy”, “number unknown”, “not authorised”, etc.). BSD sockets do not cover that. I guess it derives from Spider/Datakit having that functionality, and Arpanet / tcp-ip not having that (resorting to a connection ‘reset’ or dead line instead). Sockets have a more elegant solution for connectionless datagrams (imo), and for the same reason I guess.
Sure, sockets has too much of the implementation sticking through the abstractions, but it is IMO not a bad design. That it became dominant I think is in equal measure due to economics and due to being “good enough”.
If someone has a proposal for a network API that is cleaner and better than what was out there, and would have worked with the hardware and use cases of the early 80’s, I’m all ears. But maybe better on COFF...
Paul
Wholeheartedly agree with the observations on forgotten versions, lack of source and a smaller pool of people back in the day.
It is not just the Research versions, also the internal AT&T versions and the base System V versions get little attention. Same reasons I think.
Luckily, these days the sources are available (although in the case of SysV of unclear legal status).
Part of the problem I think is that it is not well known what innovations are in each version. About 2 years ago I did a lot of spelunking through the V8 source and with the help of this list could come up with a list of highlights for V8 (text is now on the TUHS V8 source web page).
Never had the time to do that for V9. I think it was mentioned that it had a new filesystem with a bitmap free list. Also, it seems to have a lot of cleaned-up implementations of things that were new and rough in V8.
No clue what was new in V10.
Similar with Unix 3, Unix 4 and Unix 5. I’m thrilled that the docs for Unix 4 showed up recently. In these doc’s there is no material on IPC. From this I think that the IPC primitives from CB-Unix did not get merged in Unix 4, but only in Unix 5 (in a reworked form).
Personally, I’m still working (off and on) on recreating the Reiser demand paging system. To keep it interesting I’ve now got Sys III running on a small RISC-V board, and when I find another time slot I’ll try to add Reiser paging to it.
So the forgotten versions are only mostly forgotten, not totally forgotten :^)
Maybe make www.tuhs.org a CNAME for tuhs.org?
Surely a site devoted to the history of UNIX should use a
real link, not a symbolic one.
Norman `Old Fart' Wilson
Toronto ON
Hi all, we have a new addition to the Unix Archive at:
https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/
This is the documentation for Unix 4.0 which preceded System V. The
documents were provided by Arnold Robbins and scanned in by Matt Gilmore.
Cheers, Warren
