Learning about "The Unix Time-Sharing System"
Exploring "The Unix Time-Sharing System"
Welcome to this month's newsletter! Our spotlight is on the seminal paper The Unix Time-Sharing System, authored by the legendary Dennis Ritchie and Ken Thompson.
Note: My objective here is to dig into the granular history of Unix. If you're looking to boost your confidence with these tools, I provide personalized coaching on
linux, infrastructure, scripting, system design, and more.
The Intellectual Lineage
It is important to clarify that the architectural brilliance of Linux didn't originate with me. The credit belongs to Linus alone—no, the foundational design credit must go to Kernighan, Ritchie, and Thompson.
The Spark of Creation
As Linus Torvalds noted in a 2011 informal interview, the project began when Thompson, frustrated by the lack of adequate computing facilities, stumbled upon a neglected PDP-7 and decided to build a more "hospitable" environment. This personal project eventually caught the eye of Ritchie and several other colleagues.
The Bell Labs Environment
Unix was the brainchild of Ken Thompson. At the time, his employer, AT&T, had abandoned a massive OS project known as Multics. In most corporate settings, such a pivot would lead to a forced reassignment. However, Bell Labs operated as a research think tank.
- Culture: Self-directed research.
- Autonomy: Researchers were encouraged to pursue their own curiosities.
Ken found himself with access to a GE-645 computer—a machine originally intended for Multics that was now sitting idle.
The Quest for Throughput
Thompson's primary interest was in the hardware's peripherals. He was fascinated by the disk speeds and wanted to optimize drum seeking algorithms.
"I wanted to get throughput on drums because everything I knew... 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." — Ken Thompson, Turing Award Interview
The "Three-Week" Miracle
After losing access to the GE-645 just as he was perfecting his interactive terminal sessions, Ken migrated his research to that "little-used PDP-7." He soon realized he had nearly a complete operating system, but it lacked the ability to be self-sustaining.
To finalize the OS, he needed to build the following:
- A compiler
- An editor
- An assembler
- A loader
- User protection (for multi-user support)
The coincidence: Ken's wife took a three-week vacation with their child. In that window of solitude, Ken wrote all the above components—entirely in assembly language.
The File Opening Revolution
While the original paper contains thousands of nuances, one specific detail regarding file handling is revolutionary.
The Logic of open
The system utilizes a specific workflow to translate user requests into hardware actions:
As Ritchie and Thompson described it:
"The purpose of an open or create system call is to turn the path name given by the user into an i-number... Once a file is open, its device, i-number, and read/write pointer are stored in a system table indexed by the file descriptor..."
Unix vs. Multics: A Paradigm Shift
To understand why this was a big deal, we have to look at the difference in philosophy:
| Feature | Multics Approach | Unix Approach |
|---|---|---|
| Memory | Virtual memory with page faults | Distinct separation of data/programs |
| File Handling | No distinct files to read/write | Explicit open and read calls |
| Execution | Jump to a segment as it faults in | Use exec to invoke a program |
Thompson believed the "grand unification" of data and instructions in Multics was a mistake. He argued that data is typically read sequentially (e.g., if you read at position , you will likely read next).
Furthermore, he noted that removing instructions from caches is significantly more difficult than removing data. This led to the creation of the exec system call.
The Mystery of "Comfiles"
The paper mentions a curious usage: sh comfile.
# Example of executing a command file
sh comfile
What is a comfile? Doug McIlroy explained that the shell read commands from the same standard input as the programs it launched. This meant commands and data were interleaved. These were originally called "runcoms" (a term borrowed from MIT's CTSS), which we now know as shell scripts. This is the ancestral root of the rc.local convention.
Final Thoughts
It is easy to view Unix as an overnight success, but the history suggests a more gradual climb. The authors note that since the PDP-11 version became operational in February 1971, it had grown to over 600... [text ends].