Learning about "The Unix Time-Sharing System"

Hey there - The feature in this month's newsletter is The Unix Time-Sharing System, by Dennis Ritchie and Ken Thompson. This newsletter's goal is to uncover real details about Unix' early history; to get more confident using these tools, I offer one-on-one teaching about linux, infrastructure tools, scripting, design and more. Check Mentorship for more. Background Linux, the design came from a great mind, and that great mind was not mine, I mean you have to give credit for the design of Linux to Kernighan and Ritchie and Thompson. Linus Torvalds, informal interview, 2011 The first version was written when one of us (Thompson), dissatisfied with the available computer facilities, discovered a little-used PDP-7 and set out to create a more hospitable environment. This (essentially personal) effort was sufficiently successful to gain the interest of the other author and several colleagues. Dennis Ritchie, The Unix Time-Sharing System Unix was initially written by Ken Thompson. His employer, AT&T, pulled out of an Operating System project called Multics. For most of us, when our employer leaves a project they give us a new assignment: Bell Labs worked differently. It was mostly a think tank for self-directed research; the researchers were left alone to follow their own interests 1. Ken, now at a loose end, decided he knew what interested him: he had access to a GE-645 computer that was bought for Multics work but was now idle. It had drum disks and he wanted to optimise disk throughput. Nobody had solved this before. In his own words: The peripherals were great...it had a set of disks that were faster than anything that I could imagine, and I wanted to write drum seeking algorithms, I wanted to get throughput on drums because everything I knew in the computer center or in Multics couldn't deal with drums well...Basically they would say "read" and wait for the read to come back, but what you want to do is simultaneous overlapped reads. Basically it was fun, but that's my life, that's my whole being. Ken Thompson, Turing Award Interview He lost access to the machine when he was ready to start interactive terminal sessions using his new disk layout and accessing scheme. To replace it, he found the "little-used PDP-7" and used it to continue his disk layout research. He realises that he's almost got a full operating system and needs about 3 weeks to finish it. Again, in his own words: It had a file system. It had a disc driver. It had I/O peripherals. It had, you know, it had everything except the ability to maintain itself. So I needed a compiler, editor, an assembler, a loader, and user protection to run multiple users. Ken's wife coincidentally took a 3 week vacation with their child, and so Ken finished up the remaining few tidbits. Just to ensure you know who you're dealing with, yes, Ken Thompson wrote a compiler and an editor and an assembler and a loader and user protection in 3 weeks, written in assembly. The File Opening Revolution There're about ten thousand small historical details worth commenting on in this paper, but I wanted to cover a really weird one that won't draw your attention unless you know what you're seeing. You see, Multics had what's known as a single-level store. Here's the quote: The purpose of an open or create system call is to turn the path name given by the user into an i-number by searching the explicitly or implicitly named directories. Once a file is open, its device, i-number, and read/write pointer are stored in a system table indexed by the file descriptor returned by the open or create. Thus, during a subsequent call to read or write the file, the descriptor may be easily related to the informa- tion necessary to access the file. Dennis Ritchie & Ken Thompson, The Unix Time-Sharing System We live in a world where this is such a mundane statement. Open...opens a file. What was contemporary at the time? Fortunately, Ken Thompson told us: Multics was a virtual memory system with page faults, and it didn't differentiate between data and programs. You'd jump to a segment as it was faulted in, whether it was faulted in as data or instructions. There were no files to read or write — nothing you could remote — which I thought was a bad idea. This huge virtual memory space was the unifying concept behind Multics and it had to be tried in an era when everyone was looking for the grand unification theory of programming, but I thought it was a big mistake. I wanted to separate data from programs, because data and instructions are very different. When you're reading a file, you're almost always certain that the data will be read sequentially, and you're not surprised when you fault a and read a + 1. Moreover, it's much harder to excise instructions from caches than to excise data. So I added the exec system call that says “invoke this thing as a program,” whereas in Multics you would fault in an instruction and jump to it. Ken Thompson, Unix And Beyond, 1999 Ken stumbled upon something that's still hitting us hard today, you should treat different things differently. Comfiles Here's another delightful quote that hides a deeper secret: Thus, when the shell is executed as a command with a given input file, as in: sh