Although I started writing this blog last October, I intentionally waited until January 1, 2020, the 50th anniversary of the Unix epoch, to start putting it online. I’m a Unix person, and a big anniversary like that was too good to pass up. (That, and I’m so lazy it took me three months to set up a web server.)
The story of Unix is a lovely story that’s been told many times, by people more skilled at storytelling than I am, many of whom were there to see it, some of whom did it. So I’m not going to retell it here. There’s plenty of stuff to read up on at TUHS if you want to learn more.
For all the talk about Unix starting a revolution, it was really an evolutionary step, building on the results of the previous decade of operating system development. Don’t take my word for it, take Dennis Ritchie’s:
In most ways UNIX is a very conservative system. Only a handful of its ideas are genuinely new. In fact, a good case can be made that it is in essence a modern implementation of MIT’s CTSS system. This claim is intended as a compliment to both UNIX and CTSS.
You heard the man, let’s take a look at CTSS, shall we?
CTSS is relatively obscure today - though compared to Unix and Windows, every operating system is relatively obscure. It never ran on more than two computers at once, both of which were at MIT. It was written mostly in assembly language for three successive models of the IBM 709x architecture (the 709, 7090, and 7094), which were top-of-the-line mainframes for scientific computing when development started in 1961, but obsolete relics by the time it ended in 1969.
The name stood for the Compatible Time-Sharing System. Time-sharing meant a single computer could support multiple simultaneous users, each of whom interacted with it on their own terminal - a revolutionary concept at the time, when the only way to interact with most computers was to drop off a deck of punched cards and wait a few hours for the operators to run your job and hand you back the printed results. It was compatible in that existing users with batch jobs in decks of punched cards could still run them the old way too.
I see CTSS as the first “real” operating system, to which all later ones owe something significant. This is, as with all firsts, a matter of controversy. In particular, the Brits have a case that the Supervisor on the Manchester Atlas was the first “real” OS. But looking at the documentation on the Atlas, it’s clear they were solving a different problem. The Atlas had a multiprocessing batch OS, capable of handling 16 separate batch jobs at once, but had no methods of interaction. Impressive, to be sure. Others at MIT and BBN had simultaneously written time-sharing systems for the PDP-1, the original minicomputer. MIT system, written by and for the original “hackers” at RLE, relied on punched paper tape for data storage and had an arcane debugger-based interface. The BBN system I’ve found precious little information about, though John McCarthy was involved so it had to be pretty good.
But you look at the first CTSS paper - that’s a command line! In 1962, when everyone else was still dealing with punched cards and paper tape! When I look at earlier systems, it takes me a while to get into the proper state of mind to figure out how they were used and translate them into more modern concepts. CTSS has a few archaisms, but I bet if you sat me down with the CTSS Programmer’s Guide I’d get the hang of it pretty quickly.
And the manual, if you flip to the back section of the second edition
to where the commands are described - those are man pages! CTSS was
used for early Multics development by what would become the Unix team,
and the influence is obvious. And the commands themselves - ARCHIV
is clearly the inspiration for ar and tar, and some of the
single-letter options haven’t changed since the ‘60s. From RUNOFF
came nroff and troff. CTSS MAIL and Unix mail are both
simple, file-based inter-user communication, down to the “From” lines
that are why you can’t start an email with “From” even today. And as
far as text editors go, QED looks a lot like ed, sharing many
commands and the regex syntax. But of course it does. It was written
by Ken Thompson, based on the same-named editor he used at Berkeley,
after all.
But there wasn’t just a standard text editor, because there wasn’t a standard for “text.” Three character encodings were in use on CTSS: the six-bit native encoding of the 709x in all caps, a twelve-bit encoding that allowed for lowercase and some additional symbols, and seven-bit ASCII, which would’ve been the obvious choice to start with if it had existed in 1961, but it didn’t until 1963. They all had their own editors, and ad-hoc tools for converting among each other and “compressing” them into 36-bit words more efficiently.
File names were six characters long, in all-caps six-bit characters,
because 36 bits. Files also had six-character “secondary names” or
“types”, which functioned in the same way as extensions on later
operating systems, including Unix. (I can hear the purists shouting
now - “Unix doesn’t have extensions!” Funny, nobody told make about
that.)
There was, originally, no “shell” in CTSS. The supervisor read
commands directly from each terminal and executed them. Two later
programs would lay the basis for Unix shells: RUNCOM, which took in
a file of CTSS commands and ran them in sequence, and . SAVED, an
advanced user interface on top of CTSS with a more advanced command
language. There’s enough to talk about in these two programs for
their own post, but suffice it to say they laid the groundwork for
shell scripting and, oddly enough, instant messaging.
This post is already long enough, but there’s so much more to talk
about, including the background behind CTSS and the technical details
of how all this was implemented. And there were more Unix ideas that
came from elsewhere, most notably the Project Genie time-sharing
system, which gave us QED and inspired fork(), and Multics, the
joint venture between the CTSS team at MIT and the future Unix team at
Bell Labs, with its hierarchical directories and its shell
deliberately designed as a programming language.
Unix itself had only a few new ideas, but made a lot out of a little. Ken and Dennis and company deserve a lot of credit, but they also took a lot from their predecessors.
