Unix: An Oral History (1989)

Unix: An Oral History


[Still to come]


Gordon M. Brown

This is the story of Unix. To fully understand the evolution
of Unix, however, the story of Multics must first be told. Unix
was born at Bell Labs out of the aborted attempt to make Multics
the most advanced time sharing computer system yet available.
When Bell Labs pulled out of the joint venture, in 1969, it
brought with it numerous important ideas from Multics that would
later serve to define Unix. Furthermore, the shift in momentum at
Bell Labs, away from computing, created an environment of
creativity and independent thought which was integral to Unix
development. Multics, and Bell Labs decision to pull out of the
Multics project, were multi-faceted influences in the history of
the Unix time-sharing system.

Multics, MULTiplexed Information and Computing Service,
followed in the line of time sharing systems whose development
was driven by the need for greater access to computing. A key
proponent of this was J.C.R. Licklider, the head of ARPAs
Information Techniques Processing Office, who sought to more
efficiently integrate computers with human activities. IPTO
funded many computer related projects at the time, as was the
case with MITs Project MAC (Cambell-Kelly and Aspray, pg. 214).
Project MAC (standing for Multiple Access Computers
and also known as Man And Computer in
Marvin Minsky’s Artificial Intelligence Lab) was headed by Robert
M. Fano and included the Compatible Timesharing System. One of
the earliest time sharing systems, CTSS was a fully functional
system that could support up to 30 remote users and was an
integral part of Project MAC. Yet by 1965 Project MAC had
overloaded CTSS, and MIT had begun looking for a second
generation time sharing system. This was the Multics project,
which was intended as a dynamic, modular system capable of
supporting hundreds of users. Joining MIT in the effort was
General Electric and Bell Telephone Labs. GE had previously
supplied hardware for the Dartmouth Timesharing System and
provided a 635 mainframe (later to become known as the 645) for
the Multics project (Cambell-Kelly and Aspray, pg. 215). Bell
Labs, on the other hand, provided much of the programming
experience. As a public utility, Bell was constrained by the 56
Consent Decree which effectively limited independent computing
endeavors, hence the Multics project was a perfect outlet for
Bells computing talent and a great opportunity to build up its
software writing capability. Together, these three groups sought
to create a system that would set new standards for the computer
as a utility.

Multics was not simply intended as a replacement for the
overloaded CTSS, it was meant to go beyond time sharing to create
a community computing facility. An integral part of this was to
make the system modular, so as to support growth and change. To
enable this type of system to be maintained and to maximize
lucidity within the coding for it, PL/I was chosen as the
programming language. The development of the PL/I compiler was
contracted out to Digitek (Multics History, pg. 3) and while
waiting for the compiler to come back, the design of Multics was
laid out in the Multics System Programmers Manual (MSPM)
(Corbato, F.J., Saltzer, J.H., and C.T.Clingen, pg. 2). This
methodical approach to the planning reflected the disciplined
style that the programming team used to build the system, and was
thought necessary to effectively manage the complicated nature of
the project. The system was designed to include fault-free
continuous operation capabilities, convenient remote terminal
access and selective information sharing. One of the most
important features of Multics was to follow the trend towards
integrated multi-tasking and permit multiple programming
environments and different human interfaces under one operating
system. Doug McIlroy emphasized that it wasn’t that it [Multics]
allowed many people to share the cycles in the machine:

It was that it allowed many people to work
in the same huge pot of data and it was this synergy of
sharing data, to be able to quickly look at other people’s
files, pass messages around and so on, that was the best
thing that time sharing had to offer. The other was merely an
economic advantage, but the one of sharing was a
qualitatively different way of using the machines.

Although this greatly increased the complexity of Multics it
reflected the desire for an interactive system that could
increase the capacity of the computer as a communications tool.

Development continued on the system design for a year and
still no PL/I compiler had appeared. This was attributed to the
difficulties involved with implementing the full PL/I language.
Doug McIlroy and Bob Morris took it upon themselves to create a
backup for the system by using EPL/I (early PL/I) to write a
compiler which produced output in EPL Bootstrap Assembler
(Multics History, pg. 3). This was not only very slow in
compiling, but was also limiting in the features that could be
implemented using it. For example, McIlroy remarked that
“There were only two error messages, syntax error and
redeclaration, and one warning, idiotic structure” (Salus,
Peter, pg. 28). This problem was compounded by the necessity of
an unanticipated phase of design iterations due to gross
discrepancies between the actual and expected performance of the
various logical execution paths throughout the software.

As a result, the project began to fall behind schedule,
threatening the intermediate funding being provided by the
Cambridge Project, an ARPA funded political science computing
project (Multics History, pg. 4). Concern over the extent of the
software problems soon became widespread and as early as 1967
there existed growing doubts about the future of Multics. Sam
Morgan, director of Computing Science Research at Bell Labs
during this period, expressed his own concerns that Multics
research was going very slowly and wasting effort, saying:
“It was becoming clear to people that Multics was an attempt
to climb too many trees at once. The development was moving more
slowly than had been expected and users were sighing with varying
degrees of pungency.” In fact, to the entire labs computing
community, the failure of Multics to deliver promptly any sort of
useable system was increasingly obvious.

Consequently, Bell Labs pulled out of the project in March of
1969, leaving GE and MIT to salvage what they could of the
system. According to Berk Tague, it was Bill Baker who made the
decision to pull the plug, saying “Like Vietnam, he [Bill
Baker] declared victory and got out of Multics.” McIlroy
echoed these thoughts, mentioning that Bell Labs “had a
million dollars worth of equipment in the attic that was sitting
there being played with by three people. It became clear that we
were a drag on the computer center’s budget.” This sudden
loss of the Multics system was to have important consequences on
the direction of computing at Bell Labs and on the creation of

It was about this time that Sandy Fraser arrived at Bell Labs.
An aeronautical engineer by trade, Fraser had been working with
the ATLAS time sharing system in Cambridge, England, when he
decided that the future of computing lay not in England, but on
the other side of the Atlantic. He came with the hope of working
on Multics and was quite startled to discover that it had been
canceled, noting a similar reaction at Bell Labs:

It was quite clear that we were in the
course of a fairly traumatic change for a lot of people. [For
example], the end of the 60s, was a time of change for all
universities. It used to be that the computing science
research communities used to run the computing centers for
the university. However, as the budgets grew, soon this
became less and less practical, [and] one by one the
universities started moving the computers from the
responsibility of the computer centers into the
administrative area.That is what happened when Multics

With Multics gone, there was a decisive shift in the momentum
away from computing at Bell Labs, as the administration sought to
transfer impetus to other research areas.

Characteristic of the time was the loss of computer science
personnel to other departments or research organizations, and the
absence of both space and funding for computer science projects.
In fact, to prevent Multics from resurfacing, directors were
discouraged from buying any machines big enough for Multics to
run on. However, the group that was most involved with the
Multics project (Ken Thompson,

Dennis Ritchie
, McIlroy and J.F.
Ossanna) desired to continue the communal computing environment
provided by Multics. They found an alternative to Multics in

Unix, while not necessarily a reaction to Multics, certainly
represented a different approach to the time sharing problem.
Ritchie, a systems programmer at Bell Labs, expressed that
“it was really the combination of the disappearance of
Multics and the fact that Ken [Thompson] had always wanted to
write an operating system of his own [that] led fairly directly
to Unix.” He went on to explain another reason the
programming group created Unix was that

we didn’t want to lose the pleasant niche
we occupied, because no similar ones were available; even the
time-sharing service that would later be offered under GE’s
operating system did not exist. What we wanted to preserve
was not just a good environment in which to do programming,
but a system around which a fellowship could form (Dennis M.
Ritchie, pg. 1).

This mentality fostered a simple, yet effective system design
based on the ideals of ease of use and close communication.

Moreover, two key concepts had been picked up on in the
development of Multics that would later serve to define Unix.
These were that the less important features of the system
introduced more complexity and, conversely, that the most
important property of algorithms was simplicity. Ritchie
explained this to Mahoney, articulating that:

The relationship of Multics to [the
development of Unix] is actually interesting and fairly
complicated. There were a lot of cultural things that were
sort of taken over wholesale. And these include important
things, [such as] the hierarchical file system and
tree-structure file system – which incidentally did not get
into the first version of Unix on the PDP-7. This is an
example of why the whole thing is complicated. But any rate,
things like the hierarchical file system, choices of simple
things like the characters you use to edit lines as you’re
typing, erasing characters were the same as those we had. I
guess the most important fundamental thing is just the notion
that the basic style of interaction with the machine, the
fact that there was the notion of a command line, the notion
was an explicit shell program. In fact the name shell came
from Multics. A lot of extremely important things were
completely internalized, and of course this is the way it is.
A lot of that came through from Multics.

As will be discussed later, the integration of numerous
aspects of Multics design into Unix maintained the power of Unix
as a time-sharing system. In contrast, the simplicity of the Unix
system avoided many of negative facets of the Multics system, as
Ritchie relates below:

As far as other technical details, there
were enormous differences. The scale of not only both effort
and human resources, as well as machine resources, was just
incomparable. I forget now how big the Multics machine was,
it wasn’t very big of course by today’s standards, but the
first PDP-7 was tiny. [Unix was designed on] only 8k words of
memory, [whereas the machine Multics ran on had] 68k. So
there was a vast difference in complexity. And a lot of that
was forced just by conditions. But a lot of it really was a
sense of taste as well. One of the obvious things that went
wrong with Multics as a commercial success was just that it
was sort of over-engineered in a sense. There was just too
much in it. And it certainly explained why it took so long to
get going. Heavily consumptive of resources, of machine and
certainly in terms of people required to produce it.

Ritchie’s remarks reflect the impact of Multics failure on the
computing atmosphere at Bell Labs and subsequently illustrate
that the key to Unix was in avoiding these attributes through
simple, well written programs. As Sam Morgan alluded to, “if
you order an operating system of a group of programmers, you get
Multics. If you leave them to their own resources and
imagination, things like Unix will grow out of their
creativity.” As discussed next, the development of the file
system leading to Unix was clearly derivative of this mentality.


The Beginning

Michael Errecart and Cameron Jones

Files to Share

Development of Unix did not actually begin as work on an
operating system. Rather, the small group of computer scientists
who had seen their positions on the Multics project evaporate at
Bell Labs’ exit set out to create a file system that could be
shared efficiently within their workgroup. The operating system
was little more than an afterthought resulting from a need to
test this file system.

When Bell Labs broke off from the Multics project, Ken
Thompson and the rest of his subgroup had been working on the
file system for the project, “which never really came to
exist” because of several technical problems that had grown
so complex that they could not be ironed out. The goal that they
were seeking was “to develop read and write calls that were
sequential calls that turned around and ended just reading
sequentially out of pages,” but problems arose with a
technology called “paging”, which was intended to
simplify the process of reading and writing files to disk but
finally was abandoned.

The Unix file system was based almost entirely on the file
system for the failed Multics project. The idea was for file
sharing to take place with explicitly separated file systems for
each user, so that there would be no locking of file tables. The
main ideas of the file system as outlined by Thompson are
“to have the activity locus of manipulation of data for user
one and user two to be disjoined, so that in fact, [they]
wouldn’t be locking common tables. [They] wouldn’t be going
through anything common unless [they] in fact shared files. To
try to keep up real high, efficient access to disks. In fact,
interleave accesses in a way.” It is clear that the main
goal of Multics — universal access to unlimited central
computing power — was carried on in a large way through the
work of Thompson, Canaday and Ritchie as they developed the file
system for Unix. Stu Feldman noted that Project MAC and Multics
combined to influence the file system:

Project MAC had a rather weird, not really
tree-structured, two-deep file system, for every name also
had a two complement identifier. Multics had a very complex
file system, which went the opposite end from this, and had a
very messy directory structure… in which you could
represent a remarkable number of important things. Very
complicated access control, very complicated linking
control… All kinds of wonderful things. All this list of
wonderful things caused the system to sink into the mud…
Everything takes cycles. Many of these ideas have reappeared
in other forms. So, in some sense Unix, the Unix file system
was the reaction to both of these, if you look at it. It had
the flexibility. It had the essential tree flexibility of
Multics. But a real dirty idea for implementation, which was
to say that the file space was flat.

Ken Thompson was the person most involved in the creation of
the file system, as he handled all the coding and debugging,
while he bounced ideas off the others on a whiteboard. Doug
McIlroy, the project manager, talked about the transition between
Multics and Unix, saying

Thompson and Ritchie and Rudd Canaday, who
was an intern in my department for a year, were talking
about, ‘Well, how could we do this in a less massive way?’
And, there were many afternoons spent across the hall there,
working at the blackboard, working out the design of… what
became the Unix file system. ‘If we were to make a file
system, what would it look like?’

A major part of the answer to this question is that the file
system had to be open. The needs of the group dictated that every
user had access to every other user’s files, so the Unix system
had to be extremely open. This openness is even seen in the
password storage, which is not hidden at all but is encrypted.
Any user can see all the encrypted passwords, but can only test
one solution per second, which makes it extremely time consuming
to try to break into the system. Another example of the openness
of the file system was the omission of records, a decision which
came under heavy criticism from all sides. The proprietary nature
of records made them inaccessible to users who did not utilize
the exact same record format, and they were anathema to the
group. Thompson would “give talks, it would always come up,
you know, why you didn’t do records and I’d have some extra
slides, cause I knew I’d be asked this.” And he would walk
the audience through a sample problem that could occur between
incompatible record types to prove his point.

During this design process, Thompson made it clear that there
were certain aspects of the file system on the Multics project
that he would have liked to see happen, but which were never
implemented. A major example is “treating files and devices
the same… having the same read calls.” This meant that
terminals would input and output data in the same format that
mainframes did, leveling the playing field between users on
different computers. “Typically during those days there were
special calls for the terminal and then the file system itself…
Confusing them and redirecting I/O was just not done in those
days.” The idea of standard input and output for devices
eventually found its way into Unix as pipes. Pipes enabled users
and programmers to send one function’s output into another
function by simply placing a vertical line, a ‘|’ between the two
functions. Piping is one of the most distinct features of Unix
and will be covered in greater detail in a later section.
Thompson thought “everyone sort of viewed [standard I/O] as
a clean concept and the right thing to do but for some reason it
just wasn’t done.”

When the file system was finally past the point where it could
be developed and modified exclusively in the abstract, but rather
had to be implemented and tested on real hardware, Thompson laid
out his idea of what the file system should look like:
“there was the I-list, which is a definition of all the
files on the system; and then some of those files were
directories which just contained name and I-number. There’s
nothing in there that constrains it to a tree. So it was not in
fact, not hierarchical at all.” Just as terminals were to be
treated no differently from mainframes, directories were just
files that had an index attached to them. However, the flaws
inherent in the original implementation became clear:

When [the group] started writing things
like file systems checking programs and stuff, the locking of
the spaghetti bowl directories and finding of disjointed
things, you’d dissever something and never get it back,
because, you know, you’d lost it. Those problems became close
to insurmountable, and so in the next implementation we
forced a topology stronger than that.

This new topology, while slightly more constrained, still
treated files and directories roughly equally, true to the ethos
of the project.

Having moved past the question of whether one user was able to
use the system effectively, it became time to test the system as
it was intended be used, with many users connected at once making
read and write calls to the disk simultaneously.

To run the file system you had to create
files and delete files, re-unite files to see how well it
performed. To do that you needed a script of what kind of
traffic you wanted on the file system, and the script we had
was, you know, paper tapes, that said, you know, read a file,
read a file, write a file, this kind of stuff. And you’d run
the script through the paper tape and it would rattle the
disk a little bit… you wouldn’t know what happened. You
just couldn’t look at it, you couldn’t see it, you couldn’t
do anything.

Because of this inability to effectively monitor the successes
and failures of the file system in these tests, the group

built a couple of tools on the file
system… used this paper tape to load the file system with
these tools, and then we would run the tools out of the file
system… and type at these tools… to drive the file system
into the contortions that we wanted to measure how it worked
and reacted. So [the file system] only lasted by itself for
maybe a day or two before we started developing the things
that we needed to load it.

It was in this fashion, with the addition of system tools,
that the idea of the hierarchical file system became the
foundation for something more.

At this point, there were the first glimmers within the group
that they were working on something that would be more than just
a file system for some larger operating system. While most of the
file commands were still the pure system commands (“the
system read call was in fact the read call of the file system and
it was very synchronous”) there followed “a very quick
rewrite that admitted it was an operating system, and it had a
kernel user interface that you trapped across.” At that
point it could officially be called an operating system. It is
interesting to note that other members of the Unix group had
quite different opinions about the infancy of the file system
from those of its creator Ken Thompson. Stu Feldman claims
“[Thompson] was writing Space Wars and he got sick and tired
of having no support. So, he built a few things.” This
concept of building tools for one’s own benefit, and adapting
them to fit the needs of the group also stood out in Thompson’s
interview, as he explained his motivations for working on Unix.
“I was more interested in myself. Just selfish notions of
trying to get a environment to work in.” Dennis Ritchie, who
was also involved in the creation of the file system to a small
extent, further backs up this statement about the file system:

I think that (the file system research) was
basically part of Ken’s desire to do a system of his own. So
I don’t know what very specific thing sparked it… Then he
and I and Rudd Canaday started drawing pictures on the
blackboard or maybe white board. Drawing the structure of
this proposed system which was in most ways the predecessor
of Unix… Most of the ideas were Ken’s.

Whatever the motivations for Unix, however, it began to look
as if it had the potential to become something that nobody could
have anticipated. And, for it to continue on its path, it needed
solid code in a solid language.

Language from B to C

The selection of a programming language in which to write Unix
was one that would help to define it almost as much as the
development of the hierarchical file system had, if not more. At
first, Ken Thompson believed that Unix would have to have a
Fortran compiler in order to be considered a “serious
system.” After sitting down to do the Fortran grammar,
“it took him about a day to realize that we wouldn’t want to
do a Fortran compiler at all.” The Unix group knew that they
still wanted a high-level language, but PL/1, which was used in
Multics, was too high-level. So instead, Thompson created a new
but very simple language, called B.

At the time, both Thompson and Ritchie had worked with a new
language which was just emerging from MIT, BCPL, and were taken
by it. Unfortunately, it was too big to run on the 4K Unix
machines, so Thompson made B, which was nearly exactly the same,
although it was an interpreter, instead of a compiler. B made two
passes, one to turn code into an intermediate language and
another to interpret the intermediate language. Ritchie wrote a
compiler for B which worked off of the intermediate language.
Some system tools and utilities were written in B, but never the
operating system itself. B was essentially the same language as
BCPL; semantically, the two were exactly the same. Syntactically,
however, it looked like what became C, although it lacked types.

Thompson had the idea that B would be a very simple, very
clean and very portable language. “It was written in its own
language. That’s why its so portable. Because you just pull it
through and its up real quickly.” Thompson was intent on
having Unix be portable, and the creation of a portable language
was intrinsic to this.

B was a word-oriented language, and it operated on a
word-oriented machine, the PDP-7. However, when it was moved to
the new PDP-11, the interpreter had some trouble. Because the
PDP-11 was byte-oriented, the machine and the language didn’t fit
well together; in particular, B and BCPL had notions of pointers
which were names of storage cells and were oriented to a single
size of object, while the PDP-11 had objects of different sizes.
In addition, since B was an interpreter, it was doomed to be
slow, so the Unix group decided they wanted something better as
the systems language, which prompted Ritchie to begin to develop
C, which occurred in two phases.

Ritchie began by adding a type structure to B, and soon after
wrote a compiler for it, marking the first phase. After the
language changes, “it was called NB for New B… [and] it
was also an interpreter.” To make the C compiler, Ritchie
began with the B compiler, and “sort of merged it into the C
compiler” with the new type structure.

The basic construction of the compiler, of
the co-generator for the compiler, was based on an idea that
I heard about from someone at the Labs at Indian Hill —
I never actually did find and read the thesis, but I had the
ideas in it explained to me so that the co-generator for NB
was… based on this Ph.D. thesis.

Basically, C ended up containing B: “some of the
anachronisms of C, that are now gone, or, at least are not [but]
are unpublished to the point that no one knows they’re there, are

“The second phase was slower; it all took place within a
very few years, but it was a bit slower, so it seemed, and it
stemmed from… the first attempt to rewrite Unix.” In the
summer of 1972, Thompson undertook this project, but gave up.
“It may [have been] because he got tired of it or whatnot,
but there were sort of two things that went wrong. One was his
problem that he couldn’t figure out how to… switch control from
one process to another. The second thing that he couldn’t easily
handle — from my point of view the more important — was
the difficulty of getting proper data structure.”
Originally, C did not have structures, so it was “really
fairly painful” to make various types of tables; a technique
found to deal with this was clumsy at best. “It was a
combination of things that caused Ken to give up that

Over the next year, Ritchie added structures to C and made the
compiler somewhat better, with better code. “And so over the
next summer that was when we made the concerted effort and
actually did redo the whole operating system in C. That was
fairly successful. It took the winter of ’73 to do that. And
there were no really tough problems.”

After this, C took off. Part of its success was simply its
association with Unix. As Unix’s popularity increased, so did
C’s: “it just got carried along.” Another reason for
its popularity was that a number of machine dependent things can
be visible to C programs, and with a little care, portability is
possible. “Part of the art is to learn what sorts of things
you can depend on, and what you shouldn’t. I guess the only real
explanation for success is that there were a lot of people
writing in the language, typically prose, [who] are now able to
write in C. The programs are likely to be a lot better for

Before Unix had begun to be a widely used system, a number of
interesting tools were being developed, so there was an effort to
make the tools available to other people. “The best way to
do that was to have a C compiler on other machines.”
However, the real difficulties that the Unix group ran into when
moving the various Unix tools to the IBM, GE or Honeywell systems
were not due to differing underlying machine architecture,
although C made it possible to see, but to operating system
differences: “how you do I/O? How you write the so-called
portable libraries? There were messes in… keeping these
programs portable. It had nothing to do with the program itself.
It had a lot to do with the interaction with the rest of the
system.” The solution: to not waste time trying to make
individual programs portable while fighting the operating system,
but to make the operating system portable, too. Thompson had
proposed early on, while the group was still on the PDP-7, to

in B the very simple operating system that
would be very, very portable. It would run on all sorts of
microcomputers that were just here. It would not be
ambitious. The idea would be that this is something that
could be distributed widely… The idea was just put out one
day and I don’t think he spent any time at all working on it.
Even though nothing came of that immediately, or very
directly, that was the first sort of specific impulse towards
Unix portability. Upright system portability.

The early emphasis of the Unix group was both on the
development of the file system and on the portability brought
about by C. This set the stage for further development of the
operating system by laying down a basic framework in which the
group would function, and paved the way to the realization of the
Unix philosophy. But, before they could do so, they had to find a
computer of their own.

Finding a Machine

Darice Wong and Jake Knerr

After Multics’ cancellation in March of 1969, essentially no
department was allowed to buy a computer powerful enough to
continue Multics research. Sam Morgan became the department head
of computing science research at Bell Labs in 1967, well into the
Multics program. He was present during the cancellation of
Multics and the birth of Unix.

There was an announcement, a formal
announcement that the work was stopping, that we were
[devoting] no more effort to [Multics], and that we were
simply out of it. I believe it had to be done that way
because … unless there is a definite statement that you are
not going to work on a project anymore, why, some people will
continue to work on it. That’s the way… research goes. Folk
from day to day do their own thing. And so there was a clear
announcement that the work was over…It was simply… using
up effort and was not… advancing and showed no promise
of… turning into a user useful thing.

A number of factors contributed to AT&T’s decision to not
buy any more computers powerful enough to run Multics. As Sam
Morgan was able to recount about the removal of service computing
from all technical organizations in Bell Labs in the middle of

… service computing at all Bell Labs
locations … merged into a single division under a man named
Phil Thayer… All the comp centers were put under unified
management and for a year and a half I was both Director of
Service Computing at Murray Hill and Whippany, and Director
of Computing Science Research. … It just wasn’t reasonable
… for a research organization also to try to manage a
stable computing center. So anyhow, having a separate
computing service organization was long overdue. [The
separate computing organization] was started in the middle of
1969. And this was another impetus I think toward the
development of an operating system for small machines, namely
Unix, that went on in computing science research. Because
once the comp center machines were moved out from under the
research aegis, we had in research had our own machines, and
management would not buy big DEC PDP 10’s and so we had to do
something on minicomputers. And that was another impetus
toward Thompson and Richie in the Unix direction. Anyway,
that’s, that’s kind of the history of things.

Many scientists did not understand, or did not want to
understand, that AT&T was out of computers. Thompson in
particular recalls, “There was no explicit policy that we
weren’t going to get back into the computer business”

Thompson and Ritchie began work on a Multics like file system
because they enjoyed using Multics, as didmost of the scientists,
and wanted to continue research. Sam Morgan felt that scientists
liked Multics because “[Multics] was fun. You could develop
software, you could do all sort of things with it. It just wasn’t
… cost effective.” Because the writers of Unix liked the
type of environment Multics provided, when Unix was developed, it
“turned out to be a much simpler, more cost effective
environment which provided users with the pleasures of… the
same kind of sandbox,” the best of both worlds. Thompson and
Ritchie were determined to find a computer to continue
Multics-like research. What they found was an aging DEC PDP-7,
the only system available. It had a very limited memory but at
least they could implement a file system.

The PDP-7 in question was specially equipped for fancy
graphics work being done by Bill Minkey. It belonged to
department 13, headed by Joseph Condon, an electrical engineer
who worked on current flow. Condon’s group wasn’t using the
computer, and Ken Thompson and Dennis Ritchie were fooling around
with it. They even programmed a famous computer game, “Space
Travel”. Sam Morgan noted “that Ken Thompson had a
space war game that he played for a while when he was looking for
something to replace Multics.”

When asked how Thompson and Ritchie were using a computer not
in their department, Condon said, “I don’t know.” In
fact, Condon had become the head of the department that owned the
PDP-7 after Thompson and Ritchie began borrowing the machine.
Thompson explains how it happened:

It was another department that owned it,
and when it would break, it would be a hassle over who
maintained it, and we didn’t maintain it because we couldn’t
get our department to pay for maintenance. There was… no
money …[and] they just didn’t want us to do this. … this
department that owned the machine … wanted to throw it
away, but [we wanted] to keep it, on their space and maintain
it for [ourselves]. That was a precarious situation, and that
persisted. Then when it became clear that these machines were
nearing the end of their life, we … tried to get them
officially ours, which failed, our manager wouldn’t pick up
these machines, at zero cost, you know, they didn’t
want…the cost of the space.

When Thompson realized that the PDP-7 was not powerful enough
to implement a file system that could offer some of the
advantages of Multics he initially programmed a bare-bones file
system. The file system was then put on a PDP-10. Using this
enhanced capability, Thompson and the others slowly added tools
that helped them monitor what the file system was doing. Thompson
devoted a month apiece to the shell, editor, assembler, and other
software tools. When asked when he realized that a new operating
system was being born, Thompson replied,

… in the summer of ’69, it was totally
rewritten in a form that looked like an operating system,
with tools that were sort of known, you know, assembler,
editor, and shell — if not maintaining itself, right on the
verge of maintaining itself, to totally sever the GECOS

It was this point that the epic birth of UNIX became a
reality. After the OS was implemented in assembly language it was
dubbed UNIX as a play on Multics; MULTI- being many and UNI-
being one.

The file system on the PDP-7 was created in assembly language.
As noted above, Thompson realized that for an operating system to
be useful it needed to be created in a high-level programming
language by which it could be ported to any system. Thompson
initially began programming a Fortran compiler, but changed his
mind and created a very simple language called B. Ritchie
improved upon B and renamed the language C. UNIX was written in C
and could be ported to any computer.

Because of its portability, Unix could now be tried on a
larger machine. The only trouble was finding a machine around the
size of Multics and a department head to purchase it. Thompson
was able to recall the process.

… we started on a set of proposals for
getting a new machine,…… So what would happen was that we
would take these proposals for these machines and do all the
research on them and get the vendors in and waste everybody’s
time, and get these proposals up and they’d be thought about
our management for a extended periods of time and they’d say
‘no’ for some funny reason, you know, never for a real one
(unclear) computing anymore. There were several, really
several, of these big rounds of trying to get a vendor and a
machine and, to get….to do this work. Most of it was
carried on by Osanna and me, and the interference type
people. Ultimately what happened was um we found a PDP-11, it
was in fact not announced yet, but it was right on the edge
of being announced. …Osanna and I put together a proposal
to buy a PDP-11 to do … research in text processing,
(unclear) and document preparation, … it was the first of
the goals that were specific, … The other ones were…we
wanted to play with computers and operating systems, and they
were unspecific, and the our management went off and thought
about it, and rejected it again. But in the meantime going up
and down the hierarchy a sister department, 122, psychology
research, came over and said ‘well we’ll fund it out of our
area,’ embarrassed the hell out of our management. And they
bought it, gave it to us, and…They just had Insight, and
inspiration and unfortunately our management didn’t…. our
management was suffering from wounds from the Multics days.

Eventually, Lee McMahon, one of the four members of the Unix
machine proposal group, the only one who belonged to another
department, convinced his own department head to fund a machine.

Meanwhile, Joe Osanna convinced the Bell Labs patent office
that Unix would be a worthwhile investment as a text processing
system. Use of Unix started in the patent office of Bell Labs,
but by 1972 there were a number of non-research organizations at
Bell Labs that were beginning to use Unix for software
development. Morgan recalls the importance of text processing in
the establishment of Unix.

[Space Travel] was fun but the, the first
real application of the file system that became Unix was a
text processing system. And this was kind of the merging of
file system work and work that folks had been interested in
for a long time, text processing…

People were interested in text editing and
formatting and you could do this on a small computer… if
you had an operating system that involved easy handling of
files and… time sharing, … people could access and use
each other’s files. The Unix file system and the text editing
and formatting work kind of came together…

[A text processing system] was a system the
Labs was willing to buy a machine for. When this, the
proposal was first made that we should buy a machine for text
processing it was presented to me because I had to sign the
purchase order.

Though in afterthought Morgan admits to the merits of text
processing, he had this defense to his initial rejection:

[T]he pitch was not really that two of
Morgan’s MTS, having been thrown out of Morgan’s office (I
exaggerate here, but having been thrown out of Morgan’s
office), trot down the hall to Matthew’s and say, ‘Morgan
doesn’t love us what can you do for us?’ They came in through
McMahon’s director …The people who originally made the
proposition to me were Osanna, Thompson and McMahon, who were
working together.

Morgan admits to his underestimation of the proposals but,
acting as a department head, his responsibility was to rely on
what he knew, which wasn’t much about text processing.

I didn’t understand at the time the
innovative nature of the Unix file system, and we had done
text processing work in the past and I didn’t see that we
were, that any great research advance was being made. It
sounded as if people wanted to provide a service or something
with a typing pool. So the first proposal to buy a, I guess
it was a PDP1120 I turned down…As I said the first time
that Thompson and company asked for a computer they asked for
a DEC PDP10 and they were told no on that. It was simply too
big and you are not going to do operating system research for
a big computer just after Multics has been turned off. The
second time they asked, they wanted a PDP-1120 and I said, ‘I
am not convinced yet, I want to see more of what you say you
are going to do with your text processing system.’

In any event, his philosophy followed a somewhat lax path.

I didn’t stomp on them, but neither did I
sign their order and they found somebody else, another
director to sign the order, and the third time they came
around they wanted an 11/45 and by that time they had a
perfectly plausible and defensible story. So they got
selective enthusiasm used on them but not too violently or
with too short of a time scale. If it is going to be good it
will prove itself.

One of Morgan’s problems with accepting the proposals was in
dealing with his own management and the bureaucracy in the upper
levels of Bell Labs.

well I guess I had some difficulty in
sorting out the signal from the noise. I was quite well aware
that my bosses wouldn’t approve the purchase of a really
large computer to support any surreptitious continuation of
the Multics effort. And I was I think willing to wait for the
initial shouting to die down, and I figured that if there was
a research component involved in the text processing work
that it would appear in due course. And indeed it did.

Being a manager, Morgan had rules of management to follow.

The management principles here are that you
hire bright people and you introduce them to the environment,
and you give them general directions as to what sort of thing
is wanted, and you give them lots of freedom. Doesn’t mean
you always necessarily give them all the money that they
want. …You exercise selective enthusiasm over what they do.
And if you mistakenly discourage or fail to respond to
something that later on turns out to be good, if it is really
a strong idea it will come back…

To Morgan, his decision and the effects of his decision were a
natural process, and there was nothing to regret.

I have never been in an organization that
had enough money, or enough hiring slots, or enough office or
land space to do everything that we would like to do. So one
provides some back pressure. And in the case of the
transition from Multics to Unix, the Multics faucet had to be
turned off reasonably hard. It was a part of turning off, I
mean it was a management decision that this was going to be
turned off. And part of turning it off was not immediately
buying hardware on which Multics could be continued. In
retrospect, Thompson and Ritchie and other people did find
partly through their own efforts and partly by looking for a
director that was willing to buy a small amount of hardware,
did find machines on which they could work. And in due course
when it was clear to everybody around the research area that
Unix was going to go somewhere and needed to be supported,
they have had the machines that they wanted. They simply went
to the director of the other person in the trio. And I didn’t
think there was anything wrong with this or unreasonable
about it.

There was a reasonable justification for the way things
eventually worked out.

Max Matthews was a person who collected
little computers anyway, and it may be that he had more money
at the time than I did. We have certain plant budgets.
Anyway, I didn’t think that there was anything out of the way
about this and I didn’t feel that somebody was criticizing my
judgment. Max was perhaps in a better position to support the
machine, or I don’t know what. But anyway it didn’t seem
unusual to me, and now that I recall McMahon reported to me
for a long time. He transferred from Max’s organization into
mine not too long after this particular incident. But at the
time he was a department head for Max Matthews. So he added
his voice to the desires that the other fellows had and so
Max bought the first computer. But there was nothing, there
was nothing particularly unusual about this. And since it
would have been a little more unusual if people entirely from
one center had gone to a different director and said, ‘Can
you support this?’ In which case, I am sure that Max would
have come to me and said, ‘Look, two of your guys have come
to me and have said, will I buy them a computer? If a
computer is going be bought, you ought to buy it. Let’s
discuss whether it should be bought or not.’ The reason it
didn’t happen that way was that one of Max’s department heads
was in this story.

In Morgan’s view, Matthews’ department was a better choice for
supporting the funding of a new machine than his own.

I was told, ‘Look, Max Matthews can support
this.’ He was the other director. And why could he support
it? He could support it because he was interested in text
processing. He was doing, … he was in behavioral sciences
and psychology, and he had people who were working on text
processing, and in fact one of the folk who was, came in with
the proposition for the 11/20 that I turned down.

Fraught with difficulties, the search for a machine came to a
successful end. Though Thompson and his fellow Unix programmers
eventually obtained a PDP-11/45, the PDP7, the machine that was
too small, was integral in the way Unix developed. Had the PDP-7
not been available, history might have been different.

Building Unix

Jason Aughenbaugh
Jonathan Jessup
Nicholas Spicher

Once the group had a machine of its own, its members began to
articulate both the system and the style of computing they had
envisioned from their experience with Multics. Ostensibly in
support of the development of the text processing system for
which the machine had been purchased, they began to forge a
collection of software tools that would come to characterize the
Unix approach to computing. Designed to foster and facilitate
interactive programming, the tools formed the basis of a set of
“Workbenches” that turned Unix into a production
environment for Bell Labs at large. In the process, Unix itself
became as much a toolbox as an operating system. Central to that
toolbox was pipes, a system process that allowed routines to be
linked in sequence, the output of one providing the input for its
successor. According to both McIlroy and Kernighan, pipes created
the concept of tools. So the story of software tools must begin
with the creation of pipes.

As a metaphor, pipes emphasized the notion of tools as filters
or, more technically put, transducers, which transform a sequence
of input symbols into a sequence of output symbols. That notion
fit well with the line of research being pursued by the
theoreticians in Computing Research, most notably Al Aho. As a
result, many of the tools reflected in their conceptual structure
the application of recent results in the theory of automata and
formal languages and in the theory of algorithms. This tie to
theory became another characteristic of the Unix approach to
computing, or the Unix ethos.

Unix was intended to recreate the communal computing
environment that had so impressed the Bell Labs participants in
the Multics project. During the years in which the toolbox took
shape, its creators shared not only a computer system but also a
small attic room, and their physical proximity was often as
important to their collaboration as was the ability to share
files and programs. To understand the economy and efficiency of
the Unix programming environment, one must appreciate the
tight-knit community that created it.

What emerged from the building of Unix was not only, or even
primarily, a text-processing and programming systems that were
the vehicles of its dissemination throughout Bell Labs, AT&T,
and soon the academic community. In its inspiration and
articulation, Unix embodied an ethos of computing, a view of what
computers were for and how they should be used, indeed a view of
how computers could enable and encourage human community.

The sections to follow will begin, then, with the creation of
pipes and the development of some of the basic tools of Unix.
After a look at the theory that informed this work, we will take
a peek at the attic room and the patterns of collaboration that
are embedded in Unix. We will then follow the main lines of its
dissemination to the larger world, starting with the text
processing system that was its initial justification and moving
then to the spread of Unix itself. Finally, we will consider the
ethos that accompanied the software and that made Unix more than
just another operating system.

     The first edition of Thompson
and Ritchie’s The Unix Programmer’s Manual was dated
November 3, 1971; however, the idea of pipes is not mentioned
until the Version 3 Unix manual, published in February 1973.
Although Unix was functional without pipes, it was this concept
and notation for linking several programs together that
transformed Unix from a basic file-sharing system to an entirely
new way of computing. The ideas that led to pipes had existed in
various forms long before the concept was formally implemented.
In fact, McIlroy explains that pipes sprang from the earlier use
of macros:

[I]n the early sixties, Conway wrote an
article about co-routines. Sixty-three, perhaps in the C[ommunications
of the] ACM
, I had been doing macros, starting back in
‘59 or ‘60. And if you think about macros, they
mainly involve switching data streams. You’re taking in your
input, you suddenly come to a macro call, and that says,
‘Stop taking input from here, go take it from the
definition.’ In the middle of the definition, you’ll find
another macro call. So, macros… even as early as
‘64… Somewhere I talked of a macro processor as a
switchyard for data streams.

Aho recalls that McIlroy had developed the concept of pipes
much further:

Doug McIlroy, though, I think is probably
the author of translation…of pipes. That he had written, I
think, this unpublished paper when he [was] at Oxford back in
the ‘60s….You should read this paper because it’s UNIX
pipes. One of the interesting things about Doug is that he
has had these great, seminal ideas which not everyone knows
about. And whether his standards are so high that he doesn’t
publish them…or what? But it’s remarkable….

According to Thompson, the concept of pipes developed as a
result of a combination of ideas from the 940 system, CTSS, and

There were a lot of things that were talked
about but weren’t really done. Like treating files and
devices the same, you know, having the same read calls.
Typically during those days there were special calls for the
terminal and then the file system itself. Those calls weren’t
the same. Confusing them and redirecting I/O was just not
done in those days. So, that was… I think everyone sort of
viewed that as a clean concept and the right thing to do, but
for some reason it just wasn’t done.

Ritchie is even more willing to acknowledge the contributions
of earlier systems to pipes. To him, “the pipeline is merely
a specific form of co-routine. Even the implementation was not
unprecedented, although we didn’t know it at the time; the
‘communication files’ of the Dartmouth Time-Sharing System
did very nearly what Unix pipes do, though they seem not to have
been exploited so fully.”1

McIlroy, Thompson, and Pipes

     Although the concept of pipes
existed in some form long before 1972, it was McIlroy who
advocated an implementation of a pipeline structure into Unix.
From the beginning stages of the project, he had been seeking an
improved method of dealing with input/output structures. “It
was clearly a beautiful mental model, this idea that the output
from one process would just feed in as input to another.”
McIlroy further explains:

So, this idea had been ironed on in my head
for a long time….at the same time that Thompson and Ritchie
were on their blackboard, sketching out their file system, I
was sketching out on how to do data processing on this
blackboard, by connecting together cascades of processes and
looking for a kind of prefix notation language for connecting
processes together…

It was largely a result of his insistence that pipes was
finally implemented.

     According to Ritchie, McIlroy
later explained the pipeline idea to the Unix team on a
blackboard. However, this did not spark immediate enthusiasm.
There were objections to the notations and the one-input,
one-output command execution structure. 2 Nevertheless,
McIlroy succeeded in convincing Thompson to add pipes to Unix.
Thompson explains the difficulty in implementing McIlroy’s ideas:

Doug had…talked to us continually about
it, a notion of interconnecting computers in grids, and
arrays, you know very complex, you know, and there were
always problems in his proposals….I mean there’s just no
way to implement his ideas and we kept trying to pare him
down and weed him down and get him down, you know, and get
something useful and distill it. What was going on, what was
needed, what was real ideas, what was the fantasy of
his…and we …there were constant discussions all through
this period, and it hit just one night, it just hit, and they
went in instantly, I mean they are utterly trivial.

McIlroy recalls the events a bit differently:

Over a period from 1970 till ’72, I would,
from time to time, say ‘How about making something like
this?’, and I would put up another proposal, another
proposal, another proposal. Then one day I came up with a
syntax for the shell, that went along with the piping and Ken
said, ‘I’m gonna do it.’ He was tired of hearing all this
stuff…and that was certainly what makes it….That was
absolutely a fabulous day, the next day too. ‘I’m gonna do
it.’ He didn’t do exactly what I had proposed for the pipe
system call. He invented a slightly better one, that finally
got changed once more to what we have today. He did use my
clumsy syntax…

     Originally, pipes used the same
syntax as redirection (< and >). However, this proved to be
cumbersome, as several different combinations could represent the
same command. Just before a presentation in London, Thompson
decided to replace McIlroy’s syntax with the vertical bar,
eliminating the ambiguities of the old syntax. As Kernighan
recalls, “I remember the preposterous syntax, that
“>>” or whatever syntax, that somebody came up
with, and then all of a sudden there was the vertical bar, and
just [snaps fingers] everything clicked at that point.” The
beauty of the structure that McIlroy once described as
“garden hoses” was recognized; data would simply flow
from one program to another.

     In retrospect, the notation and
syntax of pipes were just as important as the concept itself;
pipes might not have been so successful without this further
distinction from redirection. As Aho recalls, the full
implications of pipes gradually developed after this:

I really didn’t appreciate the significance
of what you could do with it, at the time, in the ‘60s.
And I don’t think anyone did, because…what made a lot of
this philosophy…a lot of these tools go was the framework
that Unix provided. That you could have pipes on which you
could take the output of one program, and transmit it as
input to another program.

Kernighan explains why pipes was a superior method of

It’s not that you couldn’t do those kind of
things, because I had already written redirection; it
predates pipes by a noticeable amount. Not a tremendous
amount, but it definitely predates it. That’s an oldish idea.
That’s enough to do most of the things that you currently do
with pipes; it’s just not notationally anywhere near so
convenient. I mean, it’s sort of loosely analogous to working
with Roman numerals instead of Arabic numerals. It’s not that
you can’t do arithmetic, it’s just a bitch. Much more
difficult, perhaps, and therefore mentally…more

Pipes went far beyond McIlroy’s original goal of creating a
new I/O mechanism; the programmers used pipes to send an output
of one program to the input of another. As Kernighan explains:

That was the time, then, I could start to
make up these really neat examples [of pipe commands] that
would show things like doing, you know, running who,
and collecting the output in a file, and then word counting
the file to say how many users there were, and then saying,
‘Look how much easier it is with…[piping] the who
into the word count, and running who into grep,’
and starting to show combinations that were things that were
never thought of, and yet they were so easy that you could
just compose them at the keyboard and get them right every
time. That’s, I think, when we started to think, probably
consciously, about tools, because then you could compose the
things together if you had made them so that they actually
worked together.

It was the pipes concept that allowed the notion of the
software toolbox to develop. When interviewed by Mahoney, McIlroy
insisted that pipes “not only reinforced, [but] almost
created” the toolbox.

     The first step in developing
what would come to be known as the software toolbox was to ensure
that all programs could read from the standard input. McIlroy
explains the problem, and its solution:

Most of the programs up until that time
couldn’t take standard input, because there wasn’t the real
need. They had file arguments. grep had a file
argument, cat had a file argument. Thompson saw
that that wasn’t going to fit into this scheme of things, and
he went in and changed all those programs in the same night.
I don’t know how. In the next morning we had this orgy of
‘one-liners.’ Everybody had one-liner. ‘Look at this, look at

Kernighan elaborates with an example:

And that’s when people went back and
consciously put into programs the idea that they read from a
list of files, but if there were no files they read from the
standard input, so that they could be used in pipelines.
People went back and did that consciously in programs, like sort.
Sort–an example of a program that cannot work
in a pipeline, because all the input has to be read before
any output comes out–it doesn’t matter, because you’re going
to use it in a pipeline, right? And you don’t care whether it
piles up there briefly; it’s going to come out the other end.
It’s that kind of thing, where we say, ‘Hey, make them work
together. Then they become tools.’ Somewhere in there, with
the pipes, and maybe somewhere the development of grep–which
Ken did, sort of overnight–the quintessential tool, as I
guess Doug refers to it. A thing which, in a different
environment probably you don’t see it that way. But, in the
Unix environment you see it as the basic tool, in some sense.

grep was, in fact, one of the first programs that
could be classified as a software tool. Thompson designed it at
the request of McIlroy, as McIlroy explains:

One afternoon I asked Ken Thompson if he
could lift the regular expression recognizer out of the
editor and make a one-pass program to do it. He said yes. The
next morning I found a note in my mail announcing a program
named grep. It worked like a charm. When asked
what that funny name meant, Ken said it was obvious. It stood
for the editor command that it simulated, g/re/p (global
regular expression print)….From that special-purpose
beginning, grep soon became a household word.
(Something I had to stop myself from writing in the first
paragraph above shows how firmly naturalized the idea now is:
‘I used ed to grep out words from
the dictionary.’) More than any other single program, grep
focused the viewpoint that Kernighan and Plauger christened
and formalized in Software Tools: make programs that
do one thing and do it well, with as few preconceptions about
input syntax as possible.

     The idea of specialized programs
was carried even further with the development of eqn,
a mathematical text formatter developed by Kernighan and Cherry.
Kernighan explains how eqn developed:

[T]here was a graduate student named [name
deleted] who had worked on a system for doing mathematics,
but had a very different notion of what it should be. It
basically looked like function calls. And so, although it
might have worked, he a) didn’t finish it, I think, and b)
the model probably wasn’t right. I remember, he and Lorinda
had worked on it, or she had been guiding him, or something
like that. I looked at and I thought, ‘Gee, that seems wrong,
there’s got to be a better way to say it.’ I mean, then
suddenly I drifted into this notion of, do it the way you say
it. I don’t know where that came from, although I can
speculate. I had spent a fair length of time, maybe a couple
of years, when I was a graduate student, at Recording for the
Blind, at Princeton. I read stuff like computing reviews and
scattered textbooks of one sort or another, so I was used to
at least speaking mathematics out loud. Conceivably, that
trigged some kind of neurons. I don’t know.

eqn was an important software tool because,
according to Kernighan, it ‘was the first–something that sat on
top of, or in front of, a formatter to genuinely broaden what you
could do with them.’ eqn went a step beyond grep;
not only was it a small program that served one function, but it
served little purpose without being tied to another program
through a pipeline.

     eqn and grep
are illustrative of the Unix toolbox philosophy that McIlroy
phrases as, “Write programs that do one thing and do it
well. Write programs to work together. Write programs that handle
text streams, because that is a universal interface.” This
philosophy was enshrined in Kernighan and Plauger’s 1976 book, Software
, and reiterated in the “Foreword” to the
issue of The Bell Systems Technical Journal that also
introduced pipes. 4 By
the time these were published in the late 1970s, software tools
were such an integral part of Unix that one could hardly imagine
the operating system without them. As Kernighan explains:

People would come in and they’d say, ‘Yeah,
this is nice, but does the system do X?’ for some X, and the
standard answer for all of this was, ‘No, but it’s easy to
make it do it.’ Unix has, I think for many years, had a
reputation as being difficult to learn and incomplete.
Difficult to learn means that the set of shared conventions,
and things that are assumed about the way it works, and the
basic mechanisms, are just different from what they are in
other systems. Incomplete means, because it was meant as a
program development environment, it doesn’t have all the
finished products necessarily. But, as a program development
environment, it’s very easy to build a lot of these things.
It’s sort of like a kit. And if you want a new thing, you can
take the pieces out of the kit and assemble them to make your
new thing, rather more rapidly than you would be able to do
the same thing in some other kind of environment. So, we used
to say that. ‘Does it do X?’ ‘No, but it’s real easy. Do you
want one by tomorrow? I’ll give you one by tomorrow.’

As the software tools concept solidified, there was an
increased interest among Unix programmers in developing a wider
variety of specialized tools, and in developing them more

Little Languages

     The idea of tools was extended
to include the idea that people would actually use tools to
develop other tools. Thus, the Unix programmers developed highly
specialized scripting tools that became known as “little
languages.” Kernighan explains how the concept of little
languages developed for him:

Somewhere, somebody asked me to give a
talk. I looked back and realized that there was, in some way,
a unifying theme to a lot of the ways that I had been fooling
around over the years, which is that I had been building
languages to make it easy to attack this, that, or the other
problem. In some way, make it easy for somebody to talk to
the machine. I started to count them up, and, gee, there were
a lot of things there that were languages. Some of them were
absolutely conventional things, some of them were
pre-processors that sat on other things, some were not much
more than collections of subroutines; but, you know, you
could sort of call them languages. And they were all
characterized by being relatively small, as they were things
that were done by one or two people, typically. And they were
all not mainstream; I never built a C compiler. They were
attacking sort of off-the-wall targets. So, I said, gee,
well, they’re little languages.

According to the broad definition given by Kernighan, software
tools such as eqn, tbl, and make
can be considered little languages. Scripting languages are also
little languages because they simplify tasks that would otherwise
become complex under a full-scale language such as C.

     One such scripting language, awk,
was developed by Aho, Peter Weinberger, and Kernighan to be used
for “simple one or two-line programs to do some filtering as
part of a larger pipeline.”5
The modern language perl, a prominent scripting
language used on the World Wide Web, is a descendant of awk.
Kernighan explains the origins of awk:

We had this thing called qed….It
was a programmable editor, but it was programmable in some
formal sense. It was just awful, and yet it was the only
thing around that let you manipulate text in a program
without writing a hell of a lot of awkward code. So I was
interested in programmable editors, things that would let you
manipulate text with somewhat the same ease that you can
manipulate numbers. I think that that was part of my interest
in awk. The other thing is–that I remember as a
trigger for me–was a very, very specialized tool that a guy
named Mark Rochkind developed….He had a program that would
let you specify basically a sequence of regular expression
and message…and then it would create a program such that,
if you pass data through this program, when it’s an instance
of the regular expression, it would print the message. And
we’d use it for data validation. And I thought, what a neat
idea! It is a neat idea. It’s a really elegant idea. It’s a
program that creates a program that then goes off and
validates data, and you don’t have to put all the baggage in.
Some program creates the baggage for you. The only problem
with it was that it was specialized, this one tiny
application. And so my contribution to awk, if
you like, is the notion that you can generalize this.

Weinberger explains that one of the main purposes of awk
was to improve the database capabilities of Unix:

So we sat around and talked about this
stuff and there’s roughly speaking two pieces to databases.
One is the question of how you get stuff out of the database.
And the other is the question of how you sort of put stuff
into the database. And putting stuff into a database gets
involved in these ‘are we going to allow for concurrent
transactions?’ and ‘do we have to do locking?’ because
Unix was not particularly good…was incapable of in those
days. And it was just all too weird. Eventually we settled on
the idea of what we wanted was some…tool that would let you
get stuff out of ordinary Unix files in a way that was…more
general, more useful, more database-like, more report
generally like.

awk used a regular expression matching function
similar to grep, but greatly expanded on it by
adding the ability to replace the original expressions with the
desired data stream.

Formal Methods

Mark Tygert

The Unix development group had a rich background in
mathematical methods. Peter Weinberger had studied number theory
as a professor at the University of Michigan. Brian Kernighan
wrote his Ph.D. thesis on graph partitioning. Alfred Aho minored
in mathematics as a graduate student. And M. Douglas McIlroy
reports, “I went to Oxford for a year, solely so I could
imbibe denotational semantics from the source.”

Not surprisingly, then, the Unix group utilized formal methods
very early in its history. In fact, Aho arrived at Bell
Laboratories in 1967, and immediately began researching concepts
that are now fundamental to computer science. In Kernighan’s

The theory-based part of it [Unix] goes back to Al Aho, I
think, starting here [at Bell Labs] — having just finished a
thesis at Princeton on a particular class of formal
languages, having worked with John
, having had Jeff Ullman as
best friend all the way through graduate school, when the
analysis of formal languages was the hot topic in computer
science. Computer science didn’t really exist in those days,
but that was the topic. People were studying the properties
of languages [especially those useful for computing]. So,
when Al got here, he was still interested in that, and I
suspect that there were times when his management would wish
that he’d get off this damn language stuff and do something
that mattered. Fortunately, in the best tradition, he never

During the initial development of Unix, Aho co-authored many
of the standard textbooks associated with computer languages and
analysis of algorithms. Interestingly, all of these books include
examples of programming within Unix. Through these texts, Aho,
Hopcroft, and Ullman intertwined programming and Unix, while
helping to give compiler design a firm theoretical basis. Aho

So, in the early ’70s, we [Aho and Ullman] wrote this
two-volume sequence, Theory of Parsing, Translation,
and Compiling
, that attempted to distill the essence
of automata and language theory with applications to the
process of compilation. And, I think this was one of the
interesting demonstrations of putting a theoretical
foundation onto an important practical area of computer
science, that people in programming languages and compilers
are, I think, an indigenous part of computer science.

Aho and Ullman wanted to formalize the construction of
programming languages and their compilers. Aho recalls,

What we discovered when we wrote the theory of parsing
book…what we discovered was that the literature — the
scientific literature, if you could call it that — was very
inaccurate. These objects were so new, and the techniques for
dealing with them were so incomplete, that many of the claims
that were made and published about various parsing methods
were just wrong. The proofs did not hold. So one of the
things that Jeff [Ullman] and I did was to attempt to
understand what kind of techniques could be used to analyze
these formalisms, and also to put a clear picture into the
scientific literature — what was true and what wasn’t.

Clearly, Aho was interested in theory at least partly for its
own sake. However, theoretical work at Bell Laboratories involved
much more than just theory. Researchers always attempted to
create something useful. Aho reports,

And there’s also a certain consulattive aspect to the work
that the Math Center used to do that we would be treated as
consultants by the rest of the company, who could be called
upon to help out, to help understand phenomena that was
important to the telephone company. But, they were given a
charter in which there were no holds barred in how they
solved those particular problems, and some very innovative
solutions came out of that. I think that kind of tradition
was inherited by the Computing Science Research Center [the
home of the Unix development group]. And I think it’s a good
tradition to have. That…there were also very high standards
for the work and the people, that, no matter who came in, you
were expected to be the forefront of your field, and be able
to interact with the forefront of your field. There was
probably also an implication that the real contribution was
not just writing the paper, or, in fact, in many cases papers
were never written. But, the real contributions were the
ideas, and the refinement of the ideas, and showing people
how to use these ideas, to solve problems of interest.

Of course, others had somewhat different viewpoints. As
manager of the Unix development team, McIlroy regarded theory as
strictly a means, rather than an end:

Most of us are more computer types than mathematicians….
I had, in my department, system builders like Thompson, and
theoretical computer scientists like Aho. And Aho plowed the
fields of language theory from ’60…. He joined us in around
’66 — just around the same time as Thompson. Handing out
paper after paper of slightly different models of parsing and
automata. And that was supported with the overt idea that,
one day out of it, this really would feed computing
practice…. When the sound theory of parsing went into a
compiler writing system, it became available to the masses.
It…there is a case where…there’s absolutely no doubt
that, overtly, theory fed into what we do. There are lots of
other places where theory is an inspiration, or it’s in the
back of your mind.

But even though McIlroy subordinated theory to “what we
do,” he realized that theory was absolutely essential:
“I think really that yacc [yet another
compiler-compiler] and grep are what people hold up
[as] the ‘real tools’ — and they are the ones where we find a
strong theoretical underpinning.”

Interestingly, since some members of the Unix development team
had such pragmatic, tool-oriented views, they invented their
theoretically-based ideas in a somewhat peculiar manner. For
instance, when the Unix project had just begun, Stephen C.
Johnson asked Aho to construct a C parser for him. Aho remembers,

I foolishly decided to construct the parser by hand,
implementing one of these LR parser construction techniques
[a formalism from language theory]. And I had a huge sheet of
paper — big piece of cardboard — on which I carried out the
sets of items construction, usually while I was watching
television, ’cause it is such a trivial and mind-numbing
task. And, of course, I didn’t get it right. And I gave this
piece of cardboard to Steve, and Steve would then encode it
into his computer program. After a while, he become so
frustrated with me, that I couldn’t get it 100% right, he
wrote a program that automated this parser construction
technique. And that’s how the tool yacc was

Soon after the birth of yacc, Michael Lesk,
another Bell Labs scientist, created lex, a tool for
creating lexical analyzers. lex could create
programs that would take raw text, fresh from the fingertips of a
programmer, and group the characters of the text into lexical
units. Then, a yacc-generated compiler could map these
lexical units into object code, the binary code that computers
actually run. Thus, by feeding lex with regular
expressions (formalisms from language theory), and by feeding yacc
with a specification of a context-free grammar (another formalism
from language theory) and code for the actions associated with
each grammatical unit, one could automatically construct a
compiler for a programming language.

Obviously, such automation depended upon the associated formal
methods. The Unix group needed theory. Aho notes,

Well, with ad hoc methods you can do anything, but…at
least my point of view is that, if you have a scientific base
on which you can measure performance, and you can iterate and
improve your algorithms with this scientific understanding,
and then build an engineering design theory on that, you are
going to be unassailable in the work and some of the compiler
construction tools…. The other aspect of this is that it
improves software quality in a significant way, and
productivity in a significant way, ’cause you can write a
compiler much more quickly using these tools, than if you had
to do it from scratch. None of these stories that the first
FORTRAN compiler took dozens of staff years to produce.
Whereas now you could construct a compiler — a significant
compiler — as part of a classroom project in an
undergraduate computer science course.

Clearly, then, theory had practical value. Formal
methods often encouraged efficiency and clean coding. In
Weinberger’s eyes,

If you have a theory-based program, you can believe you
got the last bug out. If you have a hacked-up program, all it
is is bugs — surrounded by, you know, something that does
something. You never get the last bug out. So, we’ve got both
kinds. And it’s partly the style of the programmer. Both
kinds are useful. But one kind’s a lot easier to explain and
understand, even if it’s not more useful.

Aho prized formal techniques even more than Weinberger, as he
reveals in the following tale:

Doug McIlroy, in the previous year, had had a summer
student who had taken a classical algorithm for constructing
a deterministic automaton from a regular expression and
looked for these patterns. And it was written in machine
language. I was astonished to discover that the program that
I had written ran several times faster that what this machine
language program did. And, in fact, this sort of became an
avocation of mine for a number of years subsequently, and the
improvement in performance of that program has gone up by
almost two orders of magnitude….

Without a doubt, the Unix group benefitted enormously from
using formal methods.

Yet, formalism would sometimes prove cumbersome and
inefficient. Weinberger assesses early versions of the methods
underlying yacc as follows:

The theory is correct. The theorems are correct. But the
implications aren’t what they sound like. You learn…that’s
one of the annoyances. Now, on the other hand, if you don’t
base it on theory, it’s just chaos; you say, ‘Well, I can
hack it.’ We have programs which are not based on theory, and
some of our quite successful programs are not based on

Furthermore, on occasion the creators of Unix would make
theoretical discoveries inadvertently. In attempt to make
practical tools, they would generate new theories. For example,
while implementing efficient mathematical routines, Bob Morris
produced publishable techniques:

By and large, when I did things like writing sine, cosine,
tangent, exponential, and logarithm functions, I tried very
hard, to some success, to first do a very good job, and,
second, there was enough originality [i.e., theory] in
it that most of the work of that sort that I did got

Indeed, Kernighan believes that practical concerns strongly
influenced theoretical developments:

I think the reason [yacc] was well done is —
aside from the intrinsic brightness of the people involved,
and the fact that they picked good algorithms and continued
to refine them over the years — I think it’s the milieu of
other people sort of banging against it, and trying things
with it, and building things with it — build up sort of a
collection of things, where you could look at it and say,
‘Yeah, this is actually useful stuff. It’s not an academic
exercise. It’s genuinely a better way to do things than what
you might have had before.’

So, practicality dominated the Unix group. Yet, a wide range
of activities qualified as “practical.” For example,
the abstruse research into language theory eventually fueled the
automation of compiler construction, and therefore qualified as
practical. Kernighan clarifies exactly how Bell Labs scientists
were judged:

Impact is, I think, ultimately the criterion, but there’s
quite a long view taken, and quite a broad view of what
impact is. So, somebody who does purely theoretical work —
but whose theoretical work affects the community in some
sense, either because other people take it and produce
artifacts, or because that person is able to shape a field,
or something like that — that’s fine. That’s good work. That
has impact. It doesn’t mean that you can see it in a
telephone or anything like that; it means that it has had an
effect — a positive effect — on something of substance.

In this way, the Unix group practiced a distinctive type of
theory. For Kernighan,

…it’s [programming] different from at least pure
mathematicians; there is, in addition, the reward of utility
if you do it well. People come along and say, ‘Hey, look what
I did!’ Maybe mathematicians don’t get any jollies when
somebody says, ‘Oh, I used your theorem.’ But I think people
who write programs do get a kick out of it when somebody
comes along and says, ‘Hey, I used your program.’

Thus, the creators of Unix valued theory for its utility.
While speaking about awk, a scripting language
invented by Aho, Weinberger, and Kernighan, Weinberger noted that
“a lot of the other aspects of the program are irrelevant
compared to the fact that it does something useful.” As he puts it at another point:

When you prove a theorem, you now sort of know something
you didn’t know before. But when you write a program, the
universe has changed. You could do something you couldn’t do
before. And I think people are attracted to…these kinds of
things. I’ve always found thinking a lot of work. And
anything you can get the computer to do — that’s not what
you would call thinking…. And once the program is working,
it’s working, and if it can do different forms of the
calculation for you, it’s not just that it’s faster, it’s
also more accurate than doing them over and over by hand….

In short, formal methods were powerful, practical tools in the
Unix architects’ toolbox.

     It might have been more
difficult for the Unix programmers to develop software tools as
quickly as they did had they been working in a different
environment. The center of Unix activity was a sixth-floor room
at Murray Hill which contained the PDP-11 that ran Unix.
“Don’t think of a fancy laboratory, but it was a room up in
the attic,” as Morris describes it. In addition to the
programmers, four secretaries from the patent department worked
in the attic, performing the text-processing tasks for which Unix
was ostensibly developed. Morris describes the environment:

We all worked in the same room. We worked
all up in an attic room on the sixth floor, in Murray Hill.
In space that maybe was one and a half times the size of this
hotel room. We were sitting at adjacent terminals, and
adjacent, and we knew each other and we always in fact ate
lunch together. Shared a coffeepot. So, it was a very close
relationship and most of us were both users and contributors
and there was a significant initiative for research
contribution at all points.

The unique working conditions of the programmers led to a free
exchange of ideas and complete access to information. Moreover,
the close-knit environment led to certain standards of etiquette
among the programmers. Cherry gives an example:

[T]here was this attitude that he who
touched it last owned it. So if you needed pr to
do something pr didn’t do, and you went and
added it, you now owned pr. And so if some other
part of it broke, you owned it.

Despite the additional responsibilities that resulted from
changing a tool, the programmers did not hesitate to make any
improvements they deemed necessary. For example, Morris modified pr,
as he explains:

I remember, for example, one piece of
software that I made a noticeable change in. I was listening
one day in about 1974 to Ken and Dennis arguing about when
something happened, and even at that point they couldn’t
agree to the nearest year it happened. They had a printout in
front of them which had the date on it–month and day of the
month. And I looked at them, looked at the piece of paper,
their argument, and in my best Southern drawl I said, ‘Ah
shit,’ and turn around [to the] console and actually changed
the print programming program called pr and so
it would now print out the year.

Morris greatly appreciated the fact that tools were easy to
use and fix, even fixing problems before they were vocalized.

One day early on–let me pick about 1973–I
was watching Dennis Ritchie do some arithmetic computations.
I don’t mean anything fancy. He was just adding up a list of
numbers, using dc to do it, and as he was typing
them in he made a error of typing, and dc for no
particular reason except just the way it was designed–it
could have just printed him an error comment, but that’s not
what it did–it printed him an error comment and wiped out
the current sum. So, he had to start from scratch, and [I]
again went back to my favorite Southern drawl. Went in made
the change to the first program of dc.
Recompiled it and installed it and it when about ten minutes
later. Dennis, who probably hadn’t seen me, the fact that I
was watching him, said, ‘There’s a problem with your program
and think I ought to fix it.’ ‘Hey, it’s already installed.’
And that kind of thing could happen with any person, any
software, any time and was the rule rather than the

This example illustrates how the open, cooperative environment
in the attic improved the responsiveness and flexibility of the

     More importantly, each
programmer used all of the tools himself, and thus could correct
and enhance them in ways that would not have been possible in a
different environment. As Morris explains, no person involved in
the project could be a user without being a programmer.

I was a user and I was creating [a] system
that in part, in large parts I wanted to use. So, the parts I
was creating were in many cases the part I needed for my own
work. So, I was both a user and a contributor. But, that was
generally true. It was true of everyone.

He specifically discusses his calculator program, dc:

Though I didn’t write [dc] for
the public, I wrote it for myself and that’s true of a
lot of software that people are by and large writing software
according to their own standards. The way they wanted to. For
their own use, and the use of their friends and associates.

Similarly, Kernighan believes that no one could be a
programmer in Unix without being a user of the system.

We use our own stuff, and I think that’s a
critical observation about this group here. We do not build
tools for other people. We do not build anything for other
people. I think it’s not possible to build things for other
people, roughly speaking.

He continues:

If I build something for you, even if you
spend a lot of time describing to me what you want, and why
it’s the way it is, it’s not going to be as successful as
something where I personally face the problems. Now, I may
live with you long enough that I start to understand what
your problems are, and then I’ll probably do a better job,
but I think that we have historically done the best on
building things that address problems that we face ourselves.
That we understand them so well because we face them, either
directly–you know, I face that problem myself–or it’s the
person in the next office.

This environment fostered not only the toolbox idea, but an
entire philosophy of programming.

Text Processing and the Writer’s Workbench

David Silverman

The Writer’s Workbench exemplifies the collaborative
nature of the UNIX group. The people of the Unix project had
always done text processing. They had been writing and editing
code to create Unix and its tools. The project, moreover, had
received funding from the patent department in exchange for a
document preparation package. Lorinda Cherry, an experienced
programmer who had earned a computer science degree from Stevens
Institute in 1969, and Brian Kernighan built an open-ended system
of programs to deal with text. Their work on formatting, text
analysis and style helped to create troff,
ntroff and Writer’s
, programs still used today.

Three factors contributed to the interest in text processing:
in-house use, parts-of-speech programs, and statistical analysis
of text. As various groups investigated or required new ways to
process text, the number of tools grew. The team used text
processing to work on programs and prepare reports. Some of the
Unix team’s tinkering, moreover, led to improvements in the
new tools. Cherry’s self-described goal was to “see
what kind of neat new things I can make the computer do.”
Although Unix had used the text processor ed since its inception, Kernighan and
Cherry improved not only the way ed
performed its old functions, but created new functions for it.

The first improvements were troff
and ntroff. These commands
facilitated “a wide variety of formatting tasks by providing
flexible fundamental tools rather than specific features,”
according to the Bell Labs Technical Journal (Kernighan,
Lesk, and Ossanna 2119). Combined with the little languages
described above, notably eqn,
these features allowed the text processing and formatting both on
the computer and in printed documents. This was particularly
important for a company such as Bell Labs where so many reports
were on technical matters.

The second project to assist with text processing was Brent
Aker’s work on the Votrex machine, a peripheral that spoke
for the computer. The Votrex did not intonate or emphasize
properly. Cherry worked on a parts-of-speech program that would
allow the computer to pronounce words properly. The computer
needed “parts of speech …for syllabic stress.”

The third project was Bob Morris and Lee McMahon’s work
on the authorship of the Federalist papers. Working with the
ideas of statistician Fredrick Mosteller, Morris and McMahon were
trying to determine who wrote which paper using statistical
analysis. “Taking turns typing,” they entered the
papers into the machine to run them through various filters and
counters. They “developed lots of tools for processing text
in the process.” Typo, for example, was “one of the
early spell-checkers.” It worked based on trigram
statistics, a Mosteller technique that analyzed chunks of
repeated letters. Cherry’s familiarity with trigram
statistics had come from a compression project she worked on in
1976. She describes the process:

You take the whole string, if your
ten-letter work had maybe a trigram that was six letters
long that had a high enough count to be worthwhile, you
pick that entire six-letter string off and store it in a
dictionary and replace it with a byte and then with an
index into the dictionary.

This counting procedure was applied to the other forms of
analysis, for example, the Federalist papers authorship research.

Unix’s special capabilities made much of the text
processing work possible. Because ed
was general purpose, “programs originally written for
some other purpose” could be used in document preparation.
Rudimentary spell checkers utilized the sort
command, for example. “Case recognition,” which
“changed with Unix,” also enhanced the
programmer’s ability to analyze text. New methods of
accountingfor punctuation and blank space and
upper-lower case” also contributed.

With the background of formatting, part of speech analysis and
statistical filtering, Cherry embarked on the project Writer’s
. As the “grandmother” of this new aid,
Cherry created a word processor with the capacity to analyze
style, determine readability and facilitate good writing.

Cherry heard through a colleague that Bill Bestry, an
instructor in Princeton University’s English department
“had his students … count parts of speech.” The
students were then able to use the objective statistics to
improve their writing. Drawing on Cherry’s previous part of
speech work, Writer’s Workbench did the count
automatically. As Cherry put it:

There are various things you would
count and look at using parts of speech to decide whether
you’ve got a compound or compound sentencing
sentences types, so the part of speech program turned
into the style program.

This “layer on top of style and diction” features
filled the program with a wider range of capabilities for both
students and colleagues at Bell Labs. “There was a human
factors group in Piscataway,” for example, that wanted to
“look at [computer] documentation and decide whether it was
reasonable from a human factors standpoint.” The readability
indices of Workbench helped to edit the manuals of Unix

During beta testing with Colorado State, the Workbench
saw active faculty and student use. This program succeeded for
three main reasons – its reliability, structure, and the
programmers’ understanding of the writing process. The
competing IBM product, Epistle, was based on a parser,
making it slow and incapable of coping with incorrect student
grammar. Workbench “never really did check
grammar” but did illuminate the style of sentences employed.
The “press-on-regardless attitude” of workbench lead to
accuracy across the entire paper. The most important factor,
however, was the programmers understanding of the writing process
itself. They knew to present readability scales as estimates, not
to squeeze papers into pure numbers. They knew that the ultimate
lesson was to teach students that writing is a series of choices,
not a matter of pretty formatting on a laser printer. Cherry
expressed her vision of the Workbench’s use:

My feeling about a lot of those tools
is their value in education um is as much pointing out to
people who are learning to write that they have choices
and make choices when they do it. They don’t think
of a writing task as making choices per se. Once they get
it on paper they think it’s cast in stone. So it
makes them edit.

This step beyond formatting is what makes Unix truly able to
process text and improve the writing skills of its user.


Robert Murray-Rust and Malika Seth

The creation of the Unix operating system was a collaborative
effort of many mathematicians and theorists, and much of the
success of the project was due to the people involved and the
environment in which the system was written. Unlike most
businesses, the workplace at Bell Labs was relaxed, and specific
tasks were not assigned to individuals. According to Kernighan,
who worked with the same group at Bell Labs before joining the
Unix project, each person worked on projects of their choice:

It’s interesting, I had so much fun here in ’67 and
’68-just, you know, the people. It was just such a good
collection of people, and I’ve enjoyed it. I never
interviewed anyplace else; I never even thought of any other
place. I simply said I’d like to work here. And Sam Morgan,
in his wisdom, said, “We don’t want any Ph.D. dropouts,
so you have to get your degree finished. But, other than
that, sure, we’d love to have you.” That was it, and I
came early in ’69 and the charter, or my instructions,
were-as they are for everyone else-non-existent. Do what you
want. The hope is that the combination of people around you,
doing things that are interesting-and perhaps ultimately
relevant, but not instantaneously relevant, I don’t even
know-but the combination of people around you doing
interesting things, and getting their jollies, I think, from
having their interesting things affect other people, means
that there’s this sort of gentle gravitational pull towards
doing the same kind of thing yourself. It’s clear the reward
mechanism ultimately favors those people who have an impact
on the local community, impact on the Bell Labs community,
impact on AT&T, impact on the scientific community, in
some combination.

Likewise, Bob Morris felt that the researchers’ freedom was
essential and probably would not have been possible at any other
point in time.

…General attitude. People contributing system software
and that crucial, there were not working toward externally
separate departments. We were not bidding on some Goddamn
government project. Which meant somebody who didn’t know
anything had set out a lot of ways of how the system should
operate…We had almost total freedom in that, and we were
able to, and it’s a luxury. I mean no one could do that kind
of stuff with Unix now. Couldn’t possibly. Not with AT&T
Unix. Not with any Unix. You just couldn’t possibly laugh and
see something go so wrong with a program. See that it was
wrong. Go in, find the place when the change needed to be
made and install the result. Hey, that was perfectly
reasonable in 1974. By 1978, it was absolutely out of the

From the management side, this idea of freedom and the
importance of creating personal projects was reflected in
Morgan’s hiring practices. Morgan relates,

…We have the philosophy that you hire bright people, you
expose them to interesting problem areas, and you keep an eye
on what they are doing and in particular on their
interactions with other people. You attempt to give them
guidance only in a very general sort of way. Often times this
guidance is simply a lot of enthusiasm for something that
they are working on. An environment like that is self
perpetuating, so long as you keep your hiring standards up
and your management keeps its eyes open.

Another unique feature of the Unix project was that the
mangers were technically trained people with similar
qualifications to those developing the tools. Morgan says,

…The management around, around Bell Labs all are, at
least around the research area, all came up through the
technical route. And people don’t get promoted to management
in the research area here unless they have a good track
record. You may find a few folk who disagree with that. But
my view is that our department heads and directors and
executive directors were once technical hot shots. Sometimes
that back fires, because you get a technical hot shot who has
no people skills. But that is a different story. Your
technical people, your managers were once technical hot shots
and they were imbued with this general philosophy of how you
conduct, how you manage research at this kind of place. And
good things come out of this…philosophy of research
management…I didn’t create this, to some extent I keep it

Morgan felt there was a delicate balance between giving people
complete freedom and assigning tasks. Also, he only gave explicit
approval to certain projects when he felt the group was ready
(“selective enthusiasm”), for instance when Thompson’s
group asked for a computer. In Morgan’s words,

You can’t make it happen. You hire bright people, provide
them with a stimulating environment. And you do selective
pruning and encouragement of what they undertake. But you
don’t do this with too short a time constant. As I said, the
first time that Thompson and company asked for a computer,
they asked for a DEC PDP-10 and they were told no on that. It
was simply too big and you are not going to do operating
system research for a big computer just after Multics has
been turned off. The second time they asked, they wanted a
PDP-11/20 and I said, “I am not convinced yet, I want to
see more of what you say you are going to do with your text
processing system.” So I didn’t stomp on them, but
neither did I sign their order, and they found somebody else,
another director to sign the order, and the third time they
came around they wanted an 11/45 and by that time they had a
perfectly plausible and defensible story. So they got
selective enthusiasm used on them but not too violently or
with too short of a time scale. If it is going to be good it
will prove itself.

Similarly, Kernighan felt that there was no direct management
and that the group’s success was due to both coincidence and the
people involved. He explains,

I don’t think it was directed, or least if it was
directed, it was done in an incredibly deft and unobtrusive
way. Maybe management will tell you that that’s worse… .If
that is true then it is to their eternal credit. Now, I
think, in a sense-I mean, Doug was management of at least
some part of that. I guess Ken technically was in Doug’s
department, and Doug is superb [with] that kind of stuff.
Insofar as he manages it, he does by superlative constructive
criticism at the right time, and by going out and trying your
stuff and finding out where it works and where it doesn’t
work, and then telling you what was good about it and what
didn’t work. To a lesser degree, I suspect that, in some
sense, we all do that. I don’t think that this was done by
any direct management, so we can dispose of that part.

Part of it
is a confluence of really good people with reasonably good
taste. Particularly Ken and Dennis, who, as far as I can
tell, genuinely have truly deep insight, and at the same
time, good taste, and at the same time, essentially very
close to parallel taste, so that they don’t get going in
opposite directions. Part of it is happy coincidence, that
technology had gotten just about the right point where you
could get hardware-a machine to work on-where you didn’t have
to, in some sense, be beholden to other people. You didn’t
have to use that machine their way because they paid for it,
or something like that; that you could have something that’s
sort of your own, so you could furnish your computing world
the way you wanted it, the way you are comfortable with it.

Bob Morris also commented on Doug McIlroy’s role in the
project, both on the managerial and technical levels. Morris

Doug was a manager and he had a supervisory responsibility
for the whole thing anyway…He was a department head and I
think it was being done by people in his department. There
may well be exceptions but, most of them certainly were in
his department. So, at the early stage, he simply watched
this happen and thought it was a good idea, supported it, and
helped in an administrative way to make it happen. Perhaps a
couple of years later, he was right along in there pushing
along with the rest of them. On the technical level. That’s
why in this stage I include him. I don’t mean Doug as a
manager, as a department head. But, as a technical might, he
was in there by 1973 thereabouts.

At the same time, he felt that there was no particular
leadership during the project, and stressed the importance of
doing things yourself. Morris remarks,

It was [more cooperative]. I don’t think there was any
time when there was any notion of anybody adopting on
leadership. If Ken asked somebody to do something, the answer
would be, “Go suck a grapefruit”…Oh, no matter
who he asked. Or if someone in the group had been asked to do
something, “Do it yourself.” There was no
leadership that I detected for being in, was community.

In addition, there was a strong sense of responsibility for
the quality of the work, resulting in projects supported by
theory. According to Weinberger,

…there’s definitely been a tendency is, if you don’t
know how to do it right, just don’t bother in the Unix
development. And I think that’s one of the things
that…leads one to choose things that are backed by theory.

Because I have this feeling I make mistakes, everybody
makes mistakes, I also have this feeling that you never want
to have to touch the programs. So it’s important to do it
right early and that it [will] always be okay…. It’s not
just a problem of the minute, although one writes a lot of
code that’s got to do the problem of the minute. It’s got to
fill the niche permanently, which is completely unrealistic
but it’s certainly an attitude. And I think that matches this
other. If it’s just going to be a slipshod temporary hacked
up way of doing it it’s just not going to work long enough.
And you’re going to just have to come back and do it again
and it’s just too much like work. Not that reality actually
matches this in any way but I think that’s the attitude. I
think that makes it easier to pick up that ethos.

Although there was a push towards excellent quality of work,
Weinberger asserts,

It’s clear that the most powerful pieces of it have that
property [of being theory-driven] and that many of the
pieces, even where there’s no clear theoretical piece behind
them, have sort of… the next best cousin in programming
language, designer stuff like that… .Unix is famous for
this theory that it’s best to do 80% because the last 20% is
way too hard. But if there were a big piece you could chop
off, then you did it. And that’s why you get general regular
expressions instead of some other version…I think regular
expressions is clearly the…single thing that distinguishes
the Unix way from other ways, the MS DOS way and many others.
Yes, I think the compromises that are made are made somewhere
else. Not made in these places where there are strong

Lorinda Cherry felt that the theoretical foundation for the
work led to an attitude of discipline. Nothing was included
unless it was essential and people had to justify what they were
doing, to some extent. Cherry comments,

There’s certainly some discipline in what’s allowed to
hang around and what isn’t. One can watch that in whatever
manual is produced and Doug starts throwing programs or
people start, ‘Rather than document this file, we’re going to
remove it. It’s not really necessary, there’s another way to
do it.’

As previously discussed, this was also a sense a sense of
ownership, in that the last person to touch a program owned it.
These two factors, discipline and ownership, were unique to this
Unix project, according to Cherry. She compares it to the
Berkeley Unix system, suggesting that the variations are possibly
due to the differences between environments:

If you look at the Berkeley Unix system and some of the
commands that are similar, the same in Berkeley as what we
have here but you look at the Berkeley manual they’ve added
85 flags to the cat command or something. It was
a very simple elegant thing that did a very simple job. I
guess we’ve always had the attitude that it has to be really
useful to be worthwhile putting in. Maybe just ’cause it was
a smaller group than at Berkeley or maybe people in Berkeley,
everybody needs to find a niche so they’ve got to put a flag
on something, I don’t know what the environment is there. But
I think it was here to prevent featurism. I think that’s the
difference between the two systems. And I think that
undoubtedly has to do with the university environment where
everybody has to do something as opposed to the environment
where in some sense everybody had to justify what it is they
were doing to your cause. And there is also some hesitancy
’cause if you touched it you owned it, you thought hard about
whether you needed to add that flag or whether there was some
other way around it. Whether there was some program. You said
‘I’ll find some other way to do this ’cause I don’t want
to own this program.’

At the same time, however, people were both willing and
expected to help others with their programs in any way possible.
One example of this responsiveness was the previously mentioned
account of dc, told by Bob Morris. As shown from this example,
collaboration played an integral role in the success of the
project. The group discussed problems they were having, and often
worked together to solve problems. A perfect example of this is
AWK, a text processing language developed by Al Aho, Peter
Weinberger, and Brian Kernighan. As the name implies, it was
certainly not a singular effort.

According to McIlroy, the trend towards working together grew
stronger with the introduction of pipes. One aspect of this
approach that made their work more difficult was that they had to
be very careful that all the parts would work together; when many
small pieces are put together to form a finished project, the
interaction between the pieces can often lead to mistakes. It is
because of the internal efficacy of the individual pieces that
the project as a whole was a success. McIlroy says,

This is the Unix philosophy. Write programs that do one
thing and do it well. Write programs to work together. Write
programs that handle text streams because, that is a
universal interface. All of those ideas, which add up to the
tool approach, might have been there in some unformed way
prior to pipes. But they really came in afterwards.

In Morgan’s opinion, the management encouraged this
collaboration but sometimes had to help organize the partnership.
Morgan observes,

We do encourage people to be enterprising, that if they
want something done, or if they want somebody to cooperate
with them…You will occasionally get someone with feels that
he would like to have somebody working with him and this
won’t happen until somebody’s boss says, ‘You two guys
collaborate.’ One does not tell researchers to
collaborate with each other. You find, you find common
interests in somebody and then the collaboration occurs. So
if somebody came to me and said, ‘You tell somebody to,
you tell such and so to work with me.’ You make your own
contacts. So folks…are encouraged to be entrepreneurial in
the sense that they make contacts and they get collaborations

The cooperative efforts were facilitated by the close working
environment. The attic had a lot to do with that, but the success
was also due to the people working in the attic. Morgan remembers
the group as tight-knit, spending time with each other even when
they were not working. In his words,

From about 1970 to about 1976 or 1977 we had about two
dozen people, twenty four people in the whole group. We were
essentially not hiring anybody, we were in one of our chronic
hiring freezes and we just had a small group of good people
who generally ate lunch together, and who were quite willing
to argue with each other and to discuss and to use the
techniques they knew about to put together things that they
thought were interesting. It was a lot of work in text
processing at that time. There was a lot of work in practical
operating system development. There was a lot of work in
theoretical computer science, compiler theory and algorithms.
It was done essentially by a handful of people. But they were
people who did a lot of talking to each other and a lot of
shouting and who essentially collaborated. And that is the
way that research is supposed to be done.

This led to what Aho called “Darwinism in Unix.” The
programming languages were tested by users so that they would
best suit the users’ needs. Aho says,

Well, you [Mahoney] talked about Unix being a spirit. The
one way that I view it is that there’s a great deal of
Darwinism in Unix. If one looked at how certain commands and
languages came into being, it was because someone had an
idea. Say like Kernighan and Cherry for this language for
typesetting equations. They got a rudimentary form of the
language processor to be up and running, and then they let
their friends use it. Then the language evolved on the basis
of usage patterns. That, as users gained more experience with
the language, they would be able to say, ‘I’d like to
have these additional features.’ Or, ‘These are
some awkwardnesses in the language.’ So there was a
Darwinistic evolution of the language, and, in fact, of the
Unix system itself. That it is satisfied a certain user’s
needs, and there was enough time to refine the system so that
it satisfied those needs…I thought, quite efficiently and
quite elegantly. There is this “European approach,”
if you want to use that term, or this more dogmatic approach
to language design, where you have some august committee that
meets for a period of several years to come up with a
language specification. They…write a document. Compiler
writers work off that document for several years to produce a
compiler, only to discover that there may be some
infelicities in the language design. And, the process is much
more cumbersome. Natural languages evolve, and I think,
‘Why shouldn’t programming languages?’

Lorinda Cherry also described the importance of a natural
programming language, specifically in reference to eqn:

…the graphics is easy. The hard part is getting a
language that you can teach to a math typist that will just
flow off her fingertips to complicated graphics. I think the
language part of that was what was neat about it. It’s still
what’s neat about it.

Morris also described the same necessity for an intuitive math
program, also in reference to eqn:

…the damn thing ought to work and it ought to work in
obvious ways and I didn’t have a manual. Wasn’t going to get
one and never intended to look at one. [Brian Kernighan’s]
view was completely supportive of that…his view was if I
used common sense and tried to create some construct, and I
wrote integral from A to B of X that it should damn well
produce a nice integral sign and an A at the bottom of it and
a B at the top of it and an integrand and do all that without
a lot of messing around and if it didn’t recognize common
sense ways that ordinary people say this is mathematical text
so ordinary people who were writing that mathematical text,
then it ought to be changed. And that’s the way it stayed.
I’m still a user of eqn, and
I still never seen a manual with eqn.
That’s one of the credible ones. Because there are an awful
lot of possible differences. I mean looking at competing
packages of that sort damn near unusable, because you have to
learn so many rules to operate them that by the time you
learn half of the rules, you’re already bored with the whole

Morris conveyed this to Condon early on, and Condon expressed
a similar feeling, describing it as “cognitive
engineering”. He spoke of going to Bob Morris and asking

‘How do you understand what these commands do? The
manual pages aren’t all that clear.’ [Morris] would say,
‘What do you think is the reasonable thing to do?’
Try some experiments with it and find out. I think that was a
very interesting clue. At least his philosophy and some of
the other people’s philosophy, of Dennis’s also, of how
system commands should work. It should work in a way that is
easy to understand. It shouldn’t be a complex function which
is all hidden in a bunch of rules. I think the concept of
cognitive engineering…is that people form a model. You
present them with some instruments, tools, like a faucet,
electric stove or something like that and demonstrate how it
works. They then form in their heads a model that shows how
it works inside to help them remember how to use it in the
future. It may be a totally erroneous model of what is going
on inside the black box. What in fact is going on inside, I
think Bob Morris [told] me, I know he felt this way, is that
the black box itself should be simple enough. Such as when
you form a model of what is going on in the black box that’s
in fact is going on in the black box. [Don’t] write a program
to try and outwit and double guess what they’re going to want
to do. You should make it such that it is clear about what it

This idea of clarity characterizes of the Unix philosophy.
Unix was created in a environment of bright, motivated people
from various backgrounds. They were given the freedom to invent
their own projects and the system developed as a combination of
inputs from a variety of people. There was no a organized
structure, and tools were written as they were needed. Much of
the work had a strong theoretical basis resulting in disciplined
programming. Collaboration was also key to success, and this was
enhanced by the close working environment. The researchers all
worked together in the attic, and then continued their
discussions outside working hours. They strove for intuitive and
efficient programs, qualities that perhaps could not be
replicated if the project were to take place under other

The dissemination of Unix, with a focus on what went on
within Bell Labs

Steve Chen

     One of the appealing characteristics
of the Unix operating system is its efficiency. This aspect of
Unix arose out of two factors. First, the researchers at Bell
Labs were working on small machines to create Unix. Second, the
desire for efficiency was a natural reaction to the complexity of
Multics which turned out to included much code that didn’t have
anything to do with the operating system. Ken Thompson and Dennis
Ritchie understood what to leave out of an operating system
without impairing its capability.

     The way in which the Unix operating
system evolved in AT&T and within Bell Laboratories was
complementary to the philosophy that underlay the development of
Unix. When Unix evolved within Bell Laboratories, it was not a
result of a deliberate initiative by managememt. Rather, it
spread through channels of technical need and technical contact.
The popularity of Unix was not the result of some grand
advertising campaign, nor was it the result of brilliant
marketing strategy. Instead, departments at Bell Laboratories
came to know Unix simply because it was the most efficient and
flexible operating system available at that time.

     Unix had several advantages. First of
all, it was written in a high level language, C, rather than in
assembly language as were almost all of the previous operating
systems. This in turn meant improved portability. Unix eventually
became the only operating system to run on supercomputers and
micros alike. Also, the concept of pipes allowed streams for
connecting processes together. The Berkeley System Distribution
(BSD) added many of the network features such as sockets, and
many of the software tools came in with System V. Unix featured
simple treatment of files and devices. It was flexible enough to
be used on systems of all sizes, and its workbench concept
provided the user with an easily extendible toolset.

     After the withdrawal from Multics, as
researchers in Bell Laboratories were searching for the operating
system that Multics failed to become, the Bell System was faced
with the problem of automating its telephone operations using
minicomputers. According to Berk Tague, “The discovery that
we had the need– or actually, the opportunity– in the early
’70s to use these minis to support telephone company operations
encouraged us to work with the Unix system. We knew we could do a
better job with maintenance, traffic control, repair, and
accounting applications.” (“Interview with Berkley
Tague,” Unix Review, June 1985, p.59.) Tague
continues, “The existing systems were made up of people and
paper. The phone business was in danger of being overwhelmed in
the early ’70s with the boom of the 60’s. There was a big
interest then in using computers to help manage that part of the
business.” Coming into the late 1960’s, the New York Public
Service Commission and other such regulatory bodies began putting
pressure on AT&T to solve what was termed as a “service
crises.” This pressure led AT&T in search of
technological advances that would make its support operations
more efficient. This search eventually led to Unix.

     At first, AT&T had looked for
operating systems from outside vendors. However, it turned out
that the vendor operating systems that were available simply were
not adequate. Also, during that time, a number of people had
already started building their own operating systems. Thus,
AT&T launched into the development of Unix to satisfy its own

     Berk Tague played a major role in
providing support for the Unix system. He had been responsible
for systems engineering as head of the Computer Planning
Department. It was Tague who pushed for Unix to be adopted and
made the internal standard. In September of 1973, he had in place
an organization called Unix Development Support to provide
support for a standard Unix. In an interview with Michael S.
Mahoney, Tague talks about how he get started in Unix.

I got into the Unix business… in September of ’73 [and]
I got permission to put together the first Unix support group
in Bell Laboratories. I put a supervisory group together and
staffed that up. And at that time I was also interested in
supporting MERT. I thought I’d do MERT for real time and Unix
for a time sharing kind of application. MERT never got off
the ground. We wasted energy on that. Though MERT actually
got embedded in some of the Unix line systems that underlined
the ESS processors… But I was driven by my customers. When
I went into business all of my customers knew more than my
people did. So we spent the first year in documenting the
product, getting an LDI to Western that made it an official
product which is a submission of design information that had
to be done. And my people [were] learning to be as good as
their customers were in understanding what it was we had. But
we quickly got to the point where we understood what the
business was and we were trying to gain control of the
customers… We ended up just at the end putting in a lot of
that stuff in Unix to hold it together. (Berk Tague,
Interview with Michael S. Mahoney.)

This organization, along with Bell Labs Research, agreed on
the need for Unix portability. The goal was to allow Unix to
become an interface between hardware and software that would
allow applications to keep running while the hardware underneath
was changing. The fact that Unix was later rewritten in C meant
that it was no longer machine dependent. The decision to rewrite
Unix in C came from Ritchie and Thompson. This was a major
breakthrough in portability for the Unix operating system. Tague
recounts his first sale of Unix,

I vividly remember the first guy I sold Unix to. There was
a fellow here at Whippany and he’d gotten a crew of pretty
good programming talent off of Safeguard. They’d never
written for anything but large machines. They’d never done an
operating system before or a compiler or anything very
sophisticated in the way of systems software. And they had a
schedule that said they were going to buy a PDP-11… build
an operating system… write their own language and they were
going to compile an application that was going to be in the
field in the spring. I came around to review this purchase.
And I sat down with… a fella named Jan Norton… and he and
I were eyeball to eyeball pretty quickly… I said, ‘Look,
here’s the deal: I understand you guys will probably want the
world’s most portable operating system, but what I’m going to
insist you do, is you pick up Unix and that you use it as a
basis for your development because it’ll get this machine
running. And if you don’t do that you don’t have a prayer.
I’ll bet you money on that.’ So I said, ‘You can go on and do
your own operating system.’ Of course I knew what would
happen when they got this thing up, and they really realized
what they were up against. UNIX would be the only way they
had a prayer of getting anything done even close to the time
schedule. And indeed that was… and I repeated that process
with several people and the PDP-11 DEC had a good reputation.
It was clearly the machine they liked. (Ibid.)

Unix sold because it was the most effective operating system
for the job at hand. Along with Unix came various software tools
such as the programmer’s workbench and a technical staff to
support the operating system. This type of marketing and support
mirrored that of telephone systems at Bell Labs.

     Providing support for Unix was a
major part of Tague’s work at Bell Labs. In this sense, selling
Unix was like selling telephone systems. One couldn’t just sell
the product and be done with it. When selling Unix, one also sold
people to help support Unix.

I’ve always seen the business as having three layers.
There’s always been a top and middle and a small. And those
have changed their definition over the years but from about
the end of the ’60s on I can always find those three layers
and they’re defined not just by machine size but the approach
to the marketing machine was bundled is how it is. And it
ranges from the large end which is this thing when you buy a
machine we put people on your premises. It’s all a package.
The unbundling of course has attacked that a little bit but
it still stems from that tradition. It’s very much
seen.” (Ibid.)

When talking of the support for Unix in Bell Labs, Tague says,

It was clear that people wanted central support for UNIX.
For a developer to take an uncommented batch or code from
Research would normally be impossible. But you see these guys
had (hooked) themselves. Because they were promising to write
their own operating system from scratch. So I could point out
to them, ‘Look, you’re going to have to support an operating
system, so you might as well support one that exists. And
don’t tell me it’s going to be easier to write your own and
to beat this guy who’s doing his third operating system.’ And
by that time it was beginning to get some momentum. So that
was a seller. But I knew life would be easier if we had
central support. So I went to my boss and in effect what we
agreed to do was to split the planning department into two
pieces. And I took on a department that became UNIX-MERT
development… (Ibid.)

When talking about the PWB programmer’s workbench– a set of
tools that were started up independently but eventually grew to
become a tightly held complement of Unix– Tague says,

And there were very good tools that Dick and his people
had produced on the PWB for managing code and doing code
control and that sort of thing. Dick was not very patient for
that, but he appreciated [it]; his managers needed it. We
referred to them as a manager’s “Linus’ blanket,”
and there was a certain amount of fairness about it.”

Clearly, Unix was a very marketable product. However, the
transition from the research environment to the sales department
still had to be made. In addition, there was the need to
standardize Unix in order to present it as a marketable product.
Tague was a key player in facilitating this transition.

When the idea of marketing Unix as a product was presented to
Research, it was not very well received. Nonetheless, Research
eventually agreed to Tague’s proposal.

… I had this vision we ought to be able to take Unix as
an operating system but as a company we can support this as
an internal standard operating system along with C in an
environment. And then we can then front end a large external
agency and commercial agency in this. With the idea that
people would sort of see the machine and use a common front.
It was not well received by Research… My story is they may
not have appreciated it but it all came true. That really is
pretty much the way the business has gone. (Ibid.)

In his interview with Tague, Mahoney asks, ” Did you
decide at a certain point then that it was time to take over the
latest version of Unix and standardize it?” Tague replies,

Yes, as I say, in ’73 it was apparent that we needed the
support and the right thing to do was to go up to Research
and tell Ritchie… And we synchronized reasonable well in
that and my people took care of the dog work of putting
together the design information files and things that Western
required in order to capture the configuration and to do
configuration control. (Ibid.)

By 1976 Unix support was established, and Unix internally was
a sole product.

In September of ’78 Jack Scanlon was putting together the
initial computing business center… I guess there were five
of us. I was brought in for Unix, Lee Thomas was brought in
for the MAC-8 micro-processor chip, Nick Maralotto was
brought in for some of the software support tools for Jay and
Dick Haddon… I believe there was another whole hardware
center that did the 3B development… [We] tried to put
together a single Unix that would sell very easily across the
board in those places… The C machine was all very nice but
they really wanted to have the hottest Unix in the
marketplace out there… [that] the 3B should sell itself
because it was the hottest Unix box around was the idea
behind it. (Ibid.)

The 3B machines were mostly used within Bell Laboratories, and
very few were picked up outside the Labs.

In 1973, the first Unix applications were installed on a
system involved in updating directory information and
intercepting calls to numbers that had been changed. This was the
first time Unix had been used in supporting an actual, ongoing
operating business. Soon, Unix was being used to automate the
operations systems at Bell Laboratories. It was automating the
monitoring, involved in measurement, and helping to rout calls
and ensure the quality of the calls. Tony Cuilwik states,

Among the varied and wide-ranging functions these systems
perform are network performance measurement, automated
network testing, circuit order planning, circuit order record
keeping, automated trouble detection, automated or directed
trouble repair, service quality assurance, quality control,
inventory control, customer record-keeping, and customer
billing– as well as any number of other operational and
administrative functions. These functions all require the
ability to present data to users in real time.”
(“Reach out and Touch the Unix System,” by Tony
Cuilwik, “Unix Review,” June 1985, p.50.)

Cuilwik, who was the head of the Operations Systems
Development Department at Bell Laboratories and later the
director of AT&T Information Systems Laboratories at
Columbus, Ohio, relates the object in these systems was “to
guarantee a minimal acceptable human response time. This
challenge has been met by tuning the underlying Unix
system.” (Ibid.) In the end, the fundamental integrity of
the national telecommunications network came to depend on over
1000 real-time, mini-computer-based systems that were all built
on a version of the Unix operating system.

Because AT&T was not in the business of selling operating
systems, Unix soon became readily available to academic
institutions at a very small charge. There were numerous reasons
for the friendliness the academic society, especially the
academic Computer Science community, showed towards Unix. John
Stoneback relates a few of these:

Unix came into many CS departments largely because it was
the only powerful interactive system that could run on the
sort of hardware (PDP-11s) that universities could afford in
the mid ’70s. In addition, Unix itself was also very
inexpensive. Since source code was provided, it was a system
that could be shaped to the requirements of a particular
installation. It was written in a language considerably more
attractive than assembly, and it was small enough to be
studied and understood by individuals. (John Stoneback,
“The Collegiate Community,” Unix Review, October
1985, p. 27.)

Stoneback also relates how research Unix aided academic
computer science departments in establishing and developing
research in computer science.

Unix had another appealing virtue that many may have
recognized only after the fact — its faithfulness to the
prevailing mid-’70s philosophy of software design and
development. Not only was Unix proof that real software could
be built the way many said it could, but it lent credibility
to a science that was struggling to establish itself as a
science. Faculty could use Unix and teach about it at the
same time. In most respects, the system exemplified good
computer science. It provided a clean and powerful user
interface and tools that promoted and encouraged the
development of software. The fact that it was written in C
allowed actual code to be presented and discussed, and made
it possible to lift textbook examples into the real world.
Obviously, Unix was destined to grow in the academic
community. (Ibid., p. 27)

At its outset, Unix was very compatible with academic
institutions. Not only was it a capable operating system, but it
also provided professors with a model for teaching the newly
emerging field of Computer Science.

    The power of Unix as a tool in the
computer science research field was also been felt. By using Unix
as a basis for operating systems research, researchers have
benefited in three major was. First, the portability and
flexibility of Unix gave researchers a means through which they
could verify each other’s experiments by way of a common
operating system. Second, researchers were able to use the solid
base of systems software provided by Unix to build on the work of
others and to approach problems without wasting time by
developing all the pieces from scratch. Third, by allowing both
research and computing to be carried on within the same system,
Unix made it possible for researchers to move results from the
laboratory to the production environment rather quickly. This
speed is mandatory for state-of-the-art computing.

    Though AT&T gave Unix to the
academic community at a very low cost, the academic community
gave back to Unix in the form of testing and contributing to the
system. An example of this is the virtual memory version of Unix
for the VAX computer which was created by Babaoglu and Porker at
UC Berkeley and later optimized by Bill Joy.

    Within Bell Labs, as Unix was being
used for real-life applications, bugs would be discovered and
reported back to the programmers. There were also situations
where the departments using the Unix system would create new
applications for their own tasks. It was the job of the research
labs to provide maintenance for Unix, update the software, and
reporting the discovered bugs to the programmers and distributing
the fixes.

    The support group for Unix became
important in 1978 when Bell Labs started to depend heavily on the
Unix system for their operations. This trend began to show itself
with the introduction of Edition 7. At this point, the vision of
the support group was to develop a polished and more stable
version of Unix, while at the same time stabilizing the system so
that everything would run smoothly at Bell Labs. Unix was being
used as the operating system basis for many of the support
systems in the Bell Operating Companies, and Bell Labs simply
could not afford to let these support systems go down. Meanwhile,
in academia, Unix users were responsible for their own
maintenance. This fostered a community of Unix users who were
willing to help one another.

    UUCP was introduced with the Version 7
Unix. This was used to pioneer the advance of Usenet News. Usenet
News was a step forward from ARPANET, and was embraced
enthusiastically by the academic community, as it made
inexpensive electronic communication available to all of its
members. Through Usenet, a community was formed which was
democratic in the purest sense. It was a community that supported
it members and in turn was nurtured by the people it served. It
was open to new ideas, open to change, and generous with its
benefits. In 1980, a survey conducted by the Computer Science
Research Network (CSNET) of academic institution revealed that
over 90 percent of all departments were served by one or more
Unix systems. Usenet truly was a landmark in the history of the
dissemination of Unix, as it displayed in bright colors the
solidarity of the Unix community in the vast and dynamic world of

    The popularity of the Unix operating
system grew because it was innovative and was written efficiently
in a high level language with code that could be modified to fit
individual preferences. The key features and characteristics of
Unix that held it above other operating systems at the time were
its software tools, its portability, its flexibility, and the
fact that it was simple, compact, and efficient. The development
of Unix in Bell Labs was carried on under a set of principles
that the researchers had developed to guide their work. These
principles included:

(i) Make each program do one thing well. To do a new job,
build afresh

rather than complicate old programs by adding new

(ii) Expect the output of every program to become the
input to another, as yet unknown, program. Don’t clutter
output with extraneous information. Avoid stringently
columnar or binary input formats. Don’t insist on interactive

(iii) Design and build software, even operating systems,
to be tried early, ideally within weeks. Don’t hesitate to
throw away the clumsy parts and rebuild them.

(iv) Use tools in preference to unskilled help to lighten
a programming task, even if you have to detour to build the
tools and expect to throw some of them out after you’ve
finished using them.”

(M.D. McIlroy, E.N. Pinson, and B.A. Tague “Unix
Time-Sharing System Forward,” The Bell System Technical
Journal, July-Aug 1088 vol 57, number 6 part 2. P. 1902)

    The amazing aspect of Unix lies in the
philosophy that was used in creating the system and then realized
in the dissemination of Unix first within Bell Labs and later
among the academic community. Although it would be unjust to try
to describe the underlining philosophy behind Unix in one short
paragraph, it is nonetheless important to realize that this new
philosophy of computing was a revolutionary one. It encompassed
freedom and individuality. It featured efficiency, flexibility,
and versatility. It produced openness and a sense of community in
a world of programmers and researchers. Without a sales force,
without a marketing team, and without the support of hardware
makers, the Unix operating system was enthusiastically embraced
around the world. Therein lies the genius of Unix.

From Dissemination back to Ethos

J. Graham Spence

While the story of Unix’s dissemination and the story of the
evolution of its ethos are two distinct stories, one can
hardly refer to one without making reference to the other. The
Unix ethos as it existed at Bell Labs did not become
etched in stone the moment that Unix was exported to the outside
world. Dissemination played a major role in the evolution of the
Unix ethos because Unix found its way back to Bell Labs.
As surely as it was exported to the outside world, it was
imported back to Bell Labs. Here, once again we see that
indispensable Unix saying at work: “the last one who touches
it, owns it.” This statement may have been coined during the
construction of Unix at Bell Labs, but it is equally applicable
to the story of dissemination. For example, when Berkeley System
Designs redesigned the main Unix kernel in the late 70’s, its
modified version of Unix made its way back to Bell Labs. Berkeley
touched it last, so they owned it. The onus was on the Bell Labs
group to address the challenges and flaws of the new version.
These challenges were constantly reviving the Bell Labs
environment, forcing it to innovate. Moreover, this innovation
was not restricted to the design of Unix itself; in fact, it
encompassed the structure of the entire Unix operation.

So whose voice can begin to tell these intertwined stories of
dissemination and ethos, the story of Unix’s spread
to the outside world and then back to Bell Labs again? Who can
describe how Unix created a full-fledged international community
and with it, a reputation for innovation and portability? This
reputation, while well deserved, is nonetheless in need of some
support. Great claims have been made for Unix; in their broad
historical overview, Computer, historians Martin
Campbell-Kelly and William Aspray state that “Unix is one of
the great design masterpieces of the twentieth
century”(Campbell-Kelly and Aspray, 222). The surprising
candidate to describe the ongoing reinvention of the Unix
environment is Stu Feldman, best known as the author of
Unix’s make.

Feldman’s qualifications to tell this story are not
immediately evident. Feldman’s background and the profile of
his work on Unix do not indicate right away his value to the
project. Feldman got his undergraduate degree from Princeton in
astrophysics, and his Ph.D from MIT in applied mathematics and
the theories of galaxies in 1973. For a long time, Feldman
considered computing to be “a side interest”, and
claims that his only computer related academic work was a
graduate course at Princeton and Seymour Papert’s MIT
graduate seminar on automata. Feldman’s obvious aptitude
earned him summer work at Murray Hill, and some early work with
Bell Labs on the Multics project. Feldman’s rare blend of
technical expertise and relative inexperience tended to land him
on the periphery of some of the larger projects within Unix. This
perspective, in limbo between insider and outsider, is the
optimal vantage point from which to view the stages of
Unix’s dissemination and the evolution of its ethos. After
all, isn’t the story Feldman is trying to tell, that relationship
between ethos and dissemination, a classic case of trying
to link inside with outside? Feldman is that unusual composite of
insider and outsider, so who better to try and reconcile the
inside story of Unix with its outside story?

Feldman’s official contributions to the Unix project are
the efl language, the first complete f77
compiler, and make. Anyone familiar with the
technical obstacles which faced the Unix workers should
immediately acknowledge the importance of these contributions to
the construction of Unix itself. And yet these contributions do
not seem nearly as integral to the story of the dissemination of
Unix as they do to the story of Unix’s construction.
However, the value of Feldman’s contributions, make
in particular, can be recognized only through a more thorough

make is a script for Unix, a program designed by
Feldman to take control of the compilation process and form an
executable program. Feldman puts his invention of make in
1976, “give or take a year.” In Unix Systems for
, Ross Burgess explains the value of make
in the Unix programming environment.

If your program consists of a number of
different files, it may be difficult to remember which files
are included in a particular program, and which ones have
changed recently. For instance, you may have a number of
programs under development, any of which use a selection of
various common subroutines that you have written. Maybe you
have a team of programmers, each of them working on different
aspects of an overall suite of programs. To keep track of
what needs to be recompiled and linked in which program, you
can use the make utility. This keeps track of
which files are needed in which program, and what has to be
done with them. By noting the dates when the various files
were last altered, make can work out which of
them need to be reprocessed to produce the new version of the
complete program(Burgess, 194).

make searches out dependencies within files with
the aim of updating files and forming executable programs. In
short, make is a clerical system for Unix. Hear
Feldman place make in the larger Unix
perspective, both as a key tool to the system and as a symbol of
the system itself.

So, make
was possible because you could ask the file system a dumb
question, and it would answer, and if you wanted to run a
command, you would just run a command. You didn’t have
to plan it in advance, you didn’t have to get God’s
permission… you just did the damn thing. Therefore, I
just put it together without thinking.

In Life with Unix, as a prelude to his section on make,
Don Libes offers the following saying from Richard E. Fairley:
“The structure of a system reflects the structure of the
organization that built it”(Libes, 181). Make
is a worthy reflection of some basic components of Unix. make
is simple; Feldman put it together “without thinking.” make
is portable; it was used across Bell Labs by a wide variety of
workers performing a wide variety of tasks within the Unix

As it turns out, virtually every download of Unix that takes
place anywhere around the world relies on make to
govern and expedite the process. New users download Unix as a
series of makefiles. These files are key to
the efficient and successful download of Unix. make
is essentially a program designed by Feldman to take control of
the compilation process and form an executable program. Without make,
Unix users would have to make use of an array of programs such as
cc, ld, as, yacc, lex, mv,
cp, sed and ln, to rebuild
sophisticated software sets. In short, the entire process would
become much more confused and inefficient. In fact, one could
even argue that without make, Unix itself might not
be as enticing an option to the potential user. Without the make
program around to ease the installment, Unix might well have
lost ground to other operating systems. Without make,
Unix would retain the same level of portability, but the
resulting inefficiency of installation would equate to a lack of
portability for many potential users. Potential users might not
be able to take on the difficulties of installation, regardless
of Unix’s technical level of portability.

As things stand now, however, make retains
its elegant simplicity, and its indispensability is given its due
respect for every efficient download of Unix. make’s
ongoing services are continually reasserting the value of Feldman
to the dissemination of Unix. make never was
the key to the dissemination of Unix; only the design features of
Unix itself can lay claim to that title. Portability, relative
simplicity, self-sufficiency, and friendly manuals are the
features that earned Unix its reputation. make did
not “sell” Unix, but insofar as it aided the spread of
Unix’s reputation, it did serve as an agent to that sale,
and a catalyst to its dissemination.

Feldman stands further qualified to reflect on the
dissemination of Unix because of the year he spent at Berkeley,
working on the pivotal Berkeley Systems Design, or BSD. Not
realizing the full potential of their curious little operating
system, Bell Labs gave Unix away to educational institutions for
free, charging them only for the cost of the tape. BSD was the
first significant offshoot of Unix designed outside of its Bell
Labs home. Certainly it could not be claimed that BSD is solely
responsible for the pioneering, innovative spirit of Unix outside
Bell Labs. The string of early BSD Unix releases was so important
because it proved to the rest of the computing world that that
same spirit of innovation could thrive outside of the sheltered
environment at Bell Labs. BSD also gave Unix an unshakable
foothold in educational institutions, and helped in developing a
close relationship with those institutions that remains today.

So here we have make and its maker. We
have the surprise catalyst to the dissemination of Unix and the
man who designed that catalyst. What can they tell us about the
spread of Unix? Most of what Feldman offers us relates back to
the nurturing of the Unix ethic at Bell Labs. In the true spirit
of UNIX, Feldman seems to suggest that his listeners utilize a
tools approach in understanding the history of Unix. The onus is
on the listener (or user) to use these tools as a means of
extending their database of UNIX history. Feldman does not dole
out facts and dates, but instead chooses to reminisce about the
aura surrounding UNIX, and how that aura translated into
international success.

… if I have to say there’s a
technical strand to the things that I’ve done and that
I’m interested in now, it’s that of how do you use
one technology to get you out of the trouble of another one?
(Pause) And I’ve been quoted more than once on the line
that one of the great things about UNIX is that it lets you
get out of the troubles it puts you into.

If troubleshooting is a Unix trademark, then one could hardly
exclude the importance of serendipity to the project.

I’ll tell you one or two simple stories
about it(make) to give you an idea of the
environment. After a few months of its being used locally, it
spread around to other Unix systems. Unix was already in use
lightly throughout the company. Somebody came up from the
first floor support group; they decided to try using make
to support their systems releases. And somebody came into my
office saying, ‘I’m having trouble with this makefile.'
And they dropped this 1500 page makefile
on my
desk… My jaw dropped. I said, ‘Goddamn, it works on
that.’ Of course, I’d never used a makefile
longer than about 15 to 100 lines.

Feldman makes a key insight here. He reveals the feeling of
serendipity and constant surprise that pervades much of the Unix
ethos. In this passage, we see that Feldman did not know the
capability of his own tool, a program which he himself authored,
until that tool had been taken to work, used and dirtied. And if
he did not even know what his own tool could, how could he know
what the entire Unix system was capable of? How could he even
begin to assess the worldwide prospects of this new operating
system? This Feldman episode is even somewhat of a microcosm for
the Unix dissemination. Make a quaint little tool and give it
away, not knowing its real working capacity, and pretty soon that
same tool is being slammed back down on your desk. With it come a
list of capabilities you never knew it had, but also a whole new
host of flaws to address.

Well, Unix is a sparsely furnished or
spartanly furnished home. It lacks all the plush conveniences
of professional operating systems. The bad news is that over
the years, it has picked up much of the plushness and the
lousy handling… It was… I’m not a car expert,
but it was sort of the MG of operating systems in the early
days. It had just enough to get you from here to there. It
was fun to play with. It didn’t have the handling of a
Buick or a Cadillac, nor did it have the performance of a
Ferrari. It was fun. And if you wanted to do something, you
did it. This openness went, however, with the fact that
things were going to change under your feet. More than once,
the C compiler died with me as its only user at two in the
morning, because Dennis is a late night person also. And at
one thirty, he might install a small bug. He was actually
extremely good at this. More than once, I was the first
person to be hit. And the good answer was that at two thirty,
it would be fixed. That’s sort of the Unix ethic. We
were living in a high-risk, fun, changing place. That
hasn’t been true, of course, for a decade, since it
became an official product, and a major force in the
universe. With all the problems of annual releases and two
year bug recycles. Unix has gotten by with the world’s
dumbest loader and pretty offensive debuggers… because
nobody was going to build anything intrinsic.

Armed with hindsight, Feldman hits the high points of the Unix
ethos, and relates it to the early dissemination of Unix.
It is unlikely that Feldman, nor anyone for that matter, could
have predicted the overwhelming worldwide success of Unix. But of
course, this uncertainty only added to that “high-risk, fun,
changing environment” that was the Bell Labs Unix project.
What’s more, as a computing success story, Unix may just be
getting started. As recently as 1995, in The Unix Philosophy, Mike
Gancarz made the bold prediction that “it is only a matter
of time before Unix becomes the world’s operating
system”(Gancarz, xix). Feldman would likely refute this
statement: “Unix is a superb, simple… but it’s a
time-bound concept.” No one can really say whether Unix’s
days are numbered or whether we are just touching the tip of the
iceberg. What we can count on is that as long as Unix moves
throughout the computing community, the ongoing reinvention of
Unix will go on, trademark licenses and troubleshooting be


via Hacker News http://bit.ly/2bjBNS2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s