A History of UNIX That Clicks / Bonus 6The headwaters of the lineage ── closing the series

A journey begun at the bottom (hands, hardware), closed at the very top

Multics → Unix ── What Was It a Reaction Against? The Finale's timeline opened with "~1965 Multics." That's the headwaters of the whole lineage. Thompson and Ritchie stepped away from the huge, ambitious Multics ── so why did they build a small, spare Unix instead? It was an objection to "bigger is better" ── and that spirit resonates deeply with the "smallness" we met again and again on this journey.

Prerequisites: Episode 7 (the first Unix), Finale (the timeline) Closing thought: start small, build up

This series began its journey at the very bottom (a hand-carved seed, wired-up hardware) and climbed all the way up to Linux. For our last stop, we go to the very top ── the headwaters of the lineage. Just before Unix was born, there stood a giant OS called Multics. In a sense, Unix was born as a reaction against it. This time, by asking "what was Unix a reaction against?", we touch the design philosophy that runs through this whole family, and close the series. That philosophy turns out to be one and the same as the "small seed" idea that kept reappearing as we traced the chicken and egg all the way down.

01The Multics ambition ── computing, like electricity

In 1964, MIT, GE, and Bell Labs joined forces to begin developing the time-sharing OS Multics (Multiplexed Information and Computing Service). The stage was the GE-645. The goal was breathtaking for its time ── hundreds of people using it at once, turning computation into a public utility like electricity or running water. It was also a pioneer in writing an OS in a high-level language, PL/I. A ball of innovation. But ── it was too ambitious for the technology of its day.

02Retreat, and "rebuild it small"

Bell Labs gradually grew disillusioned with the size and complexity of Multics and pulled out at the end of the 1960s (Episode 7). The researchers left behind ── Ken Thompson, Dennis Ritchie, Doug McIlroy, Joe Ossanna ── did not want to give up the good parts of time-sharing they had tasted in Multics. So they decided ── let's rebuild that same goodness, but far smaller. On an idle PDP-7 (Episode 7). That was Unix.

CONNECTING VOICE ── a reaction right down to the name As we saw in Episode 7, the name UNICS was a play on Multics (Multiplexed…): "Uniplexed…" = a castrated Multics, pronounced like "eunuchs." A wry, small dig at the giant Multics. The design philosophy was carved right into the name.

03Design as reaction ── small and spare

Multics and Unix had opposite design philosophies. In the figure below, switch between the two.

Figure 1: Contrasting design philosophies. Multics: "all functionality in one giant system." Unix: "small tools joined by pipes ── do one thing well."
The Unix philosophy (as summarized by McIlroy and others)

Each program does one thing well.

• For a new job, don't bloat an old program with new features ── build something new.

• Join programs with pipes, and do big jobs by combining small tools (ls | grep | wc). ── Not "one big complete system" but "small parts, and their combinations."

04Yet what Unix inherited from Multics

Unix was Multics's cautionary example, but also its teacher. In the words of Episode 1 ── it inherited not a single line of code, but the ideas. The hierarchical file system; the notion of making the shell just a user program (not part of the kernel); and above all, the very experience of "using it interactively via time-sharing." Unix was born inheriting both the ideas of the good parts of Multics and the lessons of its overreach. A reaction is at once a rejection and a deep act of learning.

The crux of the closing ── "smallness" is the red thread running through this series

Unix's "start small, build up by combining" is in fact the very idea we met again and again on this journey ── the small core of intermediate code (Episode 4), the 357-byte seed (Bonus 2), the few hand-carved words (Episode 9). A great tower, built up from a small foundation. The bootstrapping principle was Unix's design philosophy itself. The "small seed" that came into view as we traced the chicken and egg all the way down was the very thing Unix had cherished from the very start. In the figure below, follow that red thread.

Figure 2: The lineage of "smallness." From the reaction against Multics to Unix, the pipe philosophy, the small core of intermediate code, the 357-byte seed, the few hand-carved words ── a single thread running through the series
THE HONEST LINE ── Multics was not a failure

(1) Multics was not a "failure." It left behind many innovations ── ring-based security protection, dynamic linking, single-level storage ── and had a large influence on later systems. Even after Bell Labs pulled out in 1969, development continued, and Multics stayed in real operation until 2000. "Too big" is a statement relative to the technology of its time. (2) The bullet list of the "Unix philosophy" is a later distillation by McIlroy and others, and has an idealized side to it. Actual Unix/Linux also bloated considerably over their history.

(3) "Reaction" is a narrative simplification; the continuous influence (inheritance) from Multics to Unix is just as large. (4) There are various accounts of the origin of the name UNICS (Episode 7). ── Including all these caveats, history is not a single straight line, but a weave of influence and rebellion.

Practice problems (solvable with just this installment)
  1. State the Multics ambition in one line. Why was it "too big" for its time?
    See the answer
    A time-sharing OS that would turn computation into a public utility like electricity and let hundreds of people use it at once. It pioneered writing an OS in PL/I, but its features and scale were too ambitious for the capabilities of the hardware of the day, and its size and complexity became a burden.
  2. Describe the Unix design philosophy, contrasting it with Multics.
    See the answer
    Multics = all functionality in one giant system. Unix = each program does one thing well, don't bloat but rebuild, join small tools with pipes to do big jobs (small and spare).
  3. What did Unix "inherit" from Multics, and what did it not?
    See the answer
    Inherited = the ideas (hierarchical file system, making the shell a user program, the interactive time-sharing experience). Not inherited = the code (not a single line; the reimplementation tree of Episode 1) and the over-ambitious perfectionism.
  4. Which of this series' "small seeds" does Unix's "smallness" resonate with?
    See the answer
    The small core of intermediate code (Episode 4), the 357-byte seed (Bonus 2), the few hand-carved words (Episode 9). "Start small and build up" = the bootstrapping principle = the Unix design philosophy.

Closing the seriesFrom a small seed, a whole world was built up

At the headwaters of the lineage stood the huge, ambitious Multics (1964, MIT/GE/Bell Labs, GE-645, PL/I, "computation as a public utility"). Bell Labs grew disillusioned with its size and complexity and pulled out, and those who remained ── Thompson, Ritchie, McIlroy, Ossanna ── rebuilt "that same goodness, but far smaller." That was Unix. It was a reaction against Multics right down to the name (UNICS). The philosophy: "each program does one thing well, joined by pipes." But it inherited not Multics's code but its ideas, taking on both the good parts and the lessons (the reimplementation tree of Episode 1).

And this "start small, build up by combining" was exactly what we met again and again as we traced the chicken and egg all the way down ── the small core of intermediate code (Episode 4), the 357-byte seed (Bonus 2), the few hand-carved words (Episode 9). The bootstrapping principle is the Unix design philosophy itself. The journey that began at the bottom (hands, hardware) came back, at the headwaters (the reaction against Multics), to the same single truth ── big things are always built up from a small seed.

Which came first, the chicken or the egg?
── The first egg was carved by hand.
And a small seed became a world.

"A History of UNIX That Clicks" ── 11 main episodes plus 6 bonuses ── is now complete. Thank you for reading to the very end.

This document is Bonus 6 (final) of "A History of UNIX That Clicks." Historical facts: Multics (Multiplexed Information and Computing Service) was a time-sharing OS begun in 1964 as a joint effort of MIT, General Electric, and Bell Labs. On the GE-645 it aimed for simultaneous use by hundreds of users and the "utility-ization" of computing, and it was also a pioneer in being written in the high-level language PL/I. Its scale and complexity were ambitious relative to the technology of the day, and Bell Labs pulled out at the end of the 1960s. Unix was what those who remained ── Ken Thompson, Dennis Ritchie, Doug McIlroy, Joe Ossanna, and others ── rebuilt on a smaller scale. Its design is characterized by principles such as "each program does one thing well," "don't bloat with new features, rebuild instead," and "combine small tools with pipes" (as summarized by McIlroy and others). Unix did not inherit Multics's code, but received ideational influence such as the hierarchical file system and making the shell a user program (the reimplementation tree of Episode 1). Multics left behind many technical innovations, and after the retreat, development continued, with it in operation until 2000. The "Unix philosophy" is a later distillation and contains idealization. There are various accounts of the origin of the name UNICS (Episode 7). ── To print, use your browser's "Print" and "Save as PDF" (in the print version, the figures' controls and answers are static/hidden). Keep this table of contents and each episode's HTML in the same folder (the links use relative paths).

Print / Save as PDF: ⌘+P (Ctrl+P on Windows). On screen, use the buttons in Figure 1 for the Multics/Unix design philosophies, and the slider in Figure 2 to trace the lineage of "smallness." Click "See the answer" to open each solution. All 17 installments ── thank you for your company.