The UNIX Time-Sharing System

October 30, 2001

This 1974 paper from Ritchie and Thompson introduces the third version of the
UNIX operating system, which ran on the DEC PDP-11/40 and /45 systems.  It
describes the initial environment that led to the creation of UNIX, and it
describes the filesystem, process abstractions, the shell and other operating
system internals in a high level of detail.

At this point, PDP-11 UNIX had an installation base in the dozens.  It could be
run on hardware costing only $40,000 (which adjusted for inflation today,
would probably be about $70,000).  The system exhibited the reliability of
many current operating systems -- it experienced a crash roughly every other
day.

The major portion of this first version of UNIX was the file system.  The system
seemed motivated by the urge to have a multi-processing, time-sharing system
with one single filesystem for the user population.  To this end, this version
of UNIX included both mountable file systems and a rooted tree directory
structure.  Many of the design decisions about the filesystem can still be seen
in modern UNIXes, such as r/w/x protection bits (though this system only had
user and world, no group bits), direct and indirect blocks, i-nodes and
i-numbers, the directory layout and implementation, hard linking, etc.  The
soundness of Thompson's design has allowed it to persist.

Humourously, the authors point out that "Although it is possible for the
contents of a file to become scrambled when two users write on it
simultaneously, in practice, difficulties do not arise."  We know this to be
somewhat false in practice -- two processes writing the same file can cause
problems.  The lack of well-integrated locks in the filesystem is a problem that
persists, even today.  As mentioned above, the filesystem also distinguished
between "small" and "large" files -- small files fit into eight or less blocks
and used no indirect blocks, while large files were implemented by pointing
their direct blocks to indirect blocks, allowing for filesizes up to 1 MB.

The paper is weak at times at justification and analysis.  For instance, it
explores the complexity in implementing users quotas, and then points out that
the current version of UNIX solves this by not implementing quotas.  Similarly,
in section 4.1, they present some numbers and perform no interpretation, with 30
years distance, it's difficult to judge whether those numbers are good or bad.
The lesson would seem to be, always interpret results, if only for posterity.

The process structure is also incredibly similar to that of current UNIXes.  A
process's vm space is divided into text, heap, and stack portions.  The text
space is read-only and shared among each copy of a process.  The stack grows
downward from the top of the vm space, and the heap grows upward.  New processes
are created using fork(), new programs are executed using execv(), and
inter-process communication is available using pipes.

The shell described here, which is admittedly inspired by MULTICS, has similar
semantics to the current sh.  The shell supports pipes, I/O redirection,
background processes (using the \& operator), and basic control structures.  For
the most part, the only things separating this version of sh and current
versions of tcsh are tab-completion, line editing and job control.

In many ways, the paper seems a Lampson-esque response to the MULTICS system --
as the authors point out, "the success of UNIX is largely due to the fact that
it was not designed to meet any predefined objective."  That is, previous
systems had tried to design a panacea operating system that solved all user
problems.  The MULTICS paper muses about the ultimate goal of operating systems
-- so-called "no-futz" computing, where users can use the system without
understanding the algebraic structure underneath.  35 years later, that dream
has still not been fully-realized.  The MULTICS paper worried about what was
needed for an ideal computing infrastructure.  The UNIX paper explored what was
tractable to implement with current hardware and software tools.

The toolkit approach to UNIX also allowed for incremental modifiability, an
essential design methodology for complex systems.  Similarly, Thompson designed
a system he could use, rather than designing a system for "The Masses."  In
doing this, he ensured that he would be forced to live with his own design
decisions.  As the posters at Microsoft say, "Help make XXX be the best product
it can be -- use it!"

UNIX was born out of the chaos that was MULTICS.  The success of UNIX may have
inspired Lampson's later advice: make it small, make it fast, and make it work.