The UNIX Time-Sharing System

The situation

In the 1960s Bell Labs had taken part in Multics, an ambitious joint project with MIT and General Electric to build a powerful time-sharing operating system. Multics introduced many important ideas, but it was large, late and expensive, and Bell Labs withdrew in 1969. Ken Thompson and Dennis Ritchie, two researchers who had worked on it, missed the interactive computing environment it had promised.

The paper itself tells what happened next, plainly: the first version of Unix was written when Thompson, dissatisfied with the available computer facilities, found a little-used PDP-7 minicomputer and set out to create a more hospitable environment. The effort attracted Ritchie and colleagues, and later justified the purchase of a PDP-11.

What it argues

The paper is mostly a description of the system, written with unusual clarity. It explains the file system, the shell, processes and the commands. It declares: “The most important role of the system is to provide a file system.” From the user’s point of view there were three kinds of files, ordinary files, directories and special files representing devices. Treating devices as files meant the same simple operations worked for everything.

The striking claims come in the section on perspective. “Perhaps the most important achievement of Unix is to demonstrate that a powerful operating system for interactive use need not be expensive either in equipment or in human effort: it can run on hardware costing as little as $40,000, and less than two man-years were spent on the main system software.”

The authors explain the system’s success in three considerations visible in retrospect. First, because they were programmers, they designed it to make writing, testing and running programs easy. Second, “there have always been fairly severe size constraints on the system and its software,” and these constraints “encouraged not only economy, but also a certain elegance of design.” They add, drily, that this “may be a thinly disguised version of the ‘salvation through suffering’ philosophy, but in our case it worked.” Third, the system was soon able to maintain itself.

And there is a surprising admission: “Perhaps paradoxically, the success of the Unix system is largely due to the fact that it was not designed to meet any predefined objectives.” The authors had not been faced, they write, “with the need to satisfy someone else’s requirements, and for this freedom we are grateful.”

The idea underneath

The paper is a case study in bounded rationality as a design advantage. With little memory, little money and two people, the authors could not build everything, so they built a small number of general mechanisms that combined well. Constraint forced coherence.

It is also an illustration of Conway’s law: a system built by a tiny group of colleagues who shared an outlook has a unity of design that systems built by large organisations rarely achieve. And it reflects the value of dispersed knowledge at the scale of a team: the builders were the users, so the knowledge of what mattered never had to travel up a hierarchy.

The contrast with Multics, a system designed by committee to meet ambitious requirements, is the “worse is better” argument in embryo, which Richard Gabriel later made explicit in contrasting the MIT and New Jersey styles discussed in the Lisp machines road.

How it was received and what followed

Because AT&T, Bell Labs’ parent, was restricted by antitrust rules from selling computer products, Unix was licensed cheaply to universities, often with source code. A generation of students learned on it, modified it and carried it into industry. The University of California, Berkeley, produced its own influential versions. Rewritten in the C language, which Ritchie designed, Unix became portable across machines. Its descendants and imitators, including BSD, Linux, macOS, iOS and Android, now run most servers, phones and much else, as the operating systems essay describes.

Reading it today as a decision-maker

The paper’s lesson about constraints is easy to state and hard to apply. Generous budgets and long requirement lists often produce large, incoherent systems; tight constraints force choices that make a design coherent. The small first pattern collects many cases.

Its other lesson is about requirements. The authors credit their success to not meeting anyone else’s predefined objectives. That is not a licence to ignore customers. It is a reminder that the best requirements often come from real use, ideally the builders’ own, rather than from specifications written in advance.

Sources and limitations

Quotations are from the revised version of the paper published on Dennis Ritchie’s Bell Labs pages, which reproduces the later Bell System Technical Journal text and may differ slightly from the 1974 original in Communications of the ACM. The history of Multics and Unix’s spread draws on Ritchie’s 1984 retrospective and Kernighan’s memoir. The interpretations linking the paper to Conway’s law and bounded rationality are the author’s.