The document discusses the Unix design philosophy and how it has evolved over time. Some key aspects of the original philosophy included programs doing a single task well, using text streams as a universal interface, and combining programs using pipes. This allowed small simple programs to work together to accomplish complex tasks. However, the author argues that modern Unix has strayed from this philosophy, with bloated programs that try to do many tasks instead of one well. Adhering to the original design philosophy of small, specialized programs is important to keep Unix powerful and adaptable.

1. Adil Sadik
Final Paper
System Administration
Unix Design Philosophy: A Brief Discussion
Unix is a fairly unique operating system in a number of respects -- not the least of which
is the fact that many of its Linux-based derivatives can be had entirely for free and open-
sourced. Furthermore, Unix forms the backbone for a great number of modern operating
systems and platforms: iOS, OS X, and Android are all partially or entirely based in Linux or
Unix. Surely, there are countless other examples, but those three platforms represent a rather
large percentage of the current computing market. Surely, part of Unix’s success in the
marketplace -- both visibly and behind-the-scenes, so to speak -- owes to its stringent design
philosophy. This design philosophy has evolved a great deal over the years, but still manages to
maintain the same core principles. The history and evolution of the Unix design philosophy is
worth looking into both as a guideline for how today’s Unix applications should be developed
and as a parallel to the story of Unix itself’s evolution. Finally, it is worth considering whether or
not today’s applications -- many of them mobile, GUI-based applications -- are adhering to the
Unix design philosophy.
One of the first references to a Unix design philosophy comes in the preface of the 1984
book The Unix Programming Environment, by Brian Kernighan and Rob Pike, both of whom
were working for Bell Labs at the time (the birthplace of Unix.) They state that what makes Unix
work is “the effective approach to programming, a philosophy of using the computer.” Thus,
even in the infancy of Unix and consumer computing, the importance of design philosophy was
clear and stated. Furthermore, they go on to state that “the power of a system comes more from
the relationships among programs than from the programs themselves. Many Unix programs do

2. quite trivial things in isolation, but, combined with other programs, become general and useful
tools.” Thus, Kernighan and Pike had already laid down some fundamental Unix design
philosophies that continue to carry through to this day. They emphasized the importance of
interrelationships between programs over the power of any individual program. Furthermore,
they stress that it is these relationships between programs that give Unix its true power. The fact
that nearly any program can be used as a pipe to another program lends itself to adherence to
this philosophy.
The true power of the relationships between programs -- and indeed, the ability to exploit
relationships between programs to create some truly powerful command-line arguments --
comes from the Unix idea of pipes. Any Unix user -- whether beginner or advance -- can
acknowledge the power of pipes, and how they allow a user to use several relatively simple,
seemingly unrelated programs in combination to execute some truly powerful tasks. The
significance of pipes by themselves hardly warrants explanation, but their mention is worthwhile
as without their existence, Unix philosophy could not possibly have evolved in the way it did.
Rather, it would have been required to form a new application for a given task for which an
application did not exist, rather than using existing applications in tandem (via pipes) to
accomplish new and interesting goals, beyond the scope of even the designer’s imagination.
We owe the existence of pipes to a man named Doug McIlroy. Furthermore, McIlroy contributed
a great deal to the development of a Unix design philosophy, and it is safe to say that Unix
would not be what it is today if it were not for McIlroy’s contributions to the project, both in the
technical sense (in terms of his development of pipes) and in a more intangible sense (his aid in
developing the philosophy.) As early as 1978, he began to make statements regarding Unix
design philosophy, but it wasn’t until 1994’s publication of A Quarter Century of Unix that he
found a way to briefly summarize Unix philosophy: “This is the Unix philosophy: Write programs

3. that do one thing and do it well. Write programs to work together. Write programs to handle text
streams, because that is a universal interface.”
The influence of this design philosophy becomes readily apparent when one uses most
any true Unix application, especially with regard to the applications that have been with Unix
since “the beginning of time,” so to speak. These basic and indispensable programs -- cat, sed,
awk, grep, to name a few -- all adhere quite clearly to McIlroy’s design philosophies. All of these
programs do one thing and one thing alone: whether that be to output text, manipulate data
streams, search regular expressions, or parse tables. They work together extremely well due to
their nature of using text as both an input and output, and the ease with which one can pipe
input and output from one program to another. While the Unix philosophy has undergone
several evolutions since McIlroy made this succinct description, its core always harkens back to
those three directives: do one thing and do it will, write programs to work together, and write
programs to handle text streams.
Thus, we have a clear and decisive direction of the Unix philosophy and its core
directives. It is also fairly easy to see how this philosophy influence Unix’s development over
time (especially in its earlier stages) and how it benefits both the programmers and the users of
applications. The question, then, is how well does modern Unix -- and moreover, Linux --
adhere to the clearly beneficial Unix philosophy as stated by Doug McIlroy? Well, McIlroy
himself has had something to say about modern Unix and Linux, and how it has strayed from
this core design philosophy. He has stated that “adoring admirers have fed Linux goodies into
disheartening state of obesity,” meaning that, as a byproduct of people’s fondness of Linux, it
has unfortunately grown into a state where most Linux programs -- and indeed, many
distributions of Linux themselves -- do not “do one thing and do it well.” Instead, these
distributions seek to appeal to the greatest number of people in order to try and amass the

4. greatest market share and to be seen as the “best” variant of Linux. This has the unintended
side-effect of making a great number of Linux distributions largely indistinguishable from one
another, as well as ensuring that none of them are particularly well-suited to one task. Rather,
they are all more or less average at performing all tasks, and very few excel at any one
particular task.
McIlroy contrasts this with the approach toward development at Bell Labs, stating that
“everything was small.” He address man pages as a microcosm of this phenomenon, describing
that “the manual page, which really used to be a manual page, is now a small volume.” The
bloat of manual pages can be directly correlated with the bloat of the software it describes --
after all, it naturally follows that a larger, more complicated program will require a larger, more
complicated manual page. This phenomenon, however, is in direct contradiction of the Unix
philosophy of doing one thing and doing it well. Rather, one ends up with a program that does
many things only kind of well. Furthermore, McIlroy implicitly contrasts current development
discussions with those at Bell Labs, stating that “we used to sit around the Unix Room saying
‘what can we throw out? Why is there this option?’” Options were only added if they were
deemed absolutely necessary. He also stated that the addition of options is “often because
there is some deficiency in the basic design,” and that to correct this, one should, “instead of
adding the option, think about what was forcing you to add that option.” It seems, then, that
many modern Unix developers have forgotten about the basic Unix philosophies, seeking
instead to make bigger, more powerful applications that “do it all,” rather than focusing on
creating several smaller utilities that “do one thing and do it well” and work very well together
through the use of pipes.
Thus, the significance of the Unix philosophy is quite clear. One can see its influence
whenever one works with any basic Unix utility, especially those that have been around for quite

5. some time. Cat, sed, awk, and grep are all fairly trivial in their usage in isolation, but can be
linked to execute some extremely powerful commands. It is a shame, then, that it seems we
have begun to stray quite far from these core Unix philosophies. Many programs do not deal
explicitly in text streams, and it is increasingly difficult to get modern applications to work well
with one another. Furthermore, software has become bloated to the point that developers seek
to have their programs “do it all,” at the expense of doing it all well. It is clear, then, that Unix
developers have “lost their way,” so to speak. That being said, the importance of the Unix
philosophy is possibly greater now than even when it was initially stated. Small, specialized
programs that work well in tandem form the core of the Unix platform as a whole, and are part of
the reason it is so powerful and so easy to use. Applications can be used together to
accomplish tasks that the developers may never even have dreamed possible. This
phenomenon is what makes Unix such an excellent system, but the design philosophy that
makes it possible is fading fast. In order to truly advance the Unix and Linux platforms and to
keep them relevant -- as well as to maintain their power and uniqueness in an increasingly
crowded computing field -- designers must recall the Unix design philosophies of yesteryear and
begin applying them to the development of new Unix applications. By doing so, developers can
ensure that Unix continues to be one of the most powerful, flexible, and adaptable platforms
available today.
Works Cited
Kernighan, Brian W., and Rob Pike. The UNIX programming environment. Englewood Cliffs,
N.J.: Prentice-Hall, 1984. Print.
McIlroy, Douglas. "Remarks for Japan Prize award ceremony for Dennis Ritchie, May 19, 2011,
Murray Hill, NJ." cs.dartmouth.edu. N.p., 19 May 2011. Web. 24 July 2014.
<http://www.cs.dartmouth.edu/~doug/dmr.pdf>.

6. Salus, Peter H.. A quarter century of UNIX. Reading, Mass.: Addison-Wesley Pub. Co., 1994.
Print.
The Bell System Technical Journal: cumulative index 1922-1982.. Short Hills, NJ: American
Telephone & Telegraph Co., 1983. Print.