can.
Rule of Representation: Use smart data so program logic can be stupid and robust.
Rule of Separation: Separate policy from mechanism; separate interfaces from
engines.
Rule of Optimization: Prototype before polishing. Get it working before you optimize
it.
Rule of Diversity: Distrust all claims for one true way.
Rule of Extensibility: Design for the future, because it will be here sooner than you
think.



The Unix philosophy in one lesson
Applying the Unix philosophy
Attitude matters too


Those who do not understand Unix are condemned to reinvent it, poorly.

--Henry Spencer

Prev Up Next

Part I. Context

Home Culture? What culture?

Culture? What culture?

Prev Chapter 1. Philosophy

Next



Culture? What culture?

This is a book about Unix programming, but in it we're going to toss around the words
鈥榗ulture鈥�, 鈥榓rt鈥� and 鈥榩hilosophy鈥� a lot. If you are not a programmer, or you are a programmer
who has had little contact with the Unix world, this may seem strange. But Unix has a
culture; it has a distinctive art of programming; and it carries with it a powerful design
philosophy. Understanding these traditions will help you build better software, even if you're
developing for a non-Unix platform.

Every branch of engineering and design has technical cultures. In most kinds of engineering,
the unwritten traditions of the field are parts of a working practitioner's education as
important as (and, as experience grows, often more important than) the official handbooks
and textbooks. Senior engineers develop huge bodies of implicit knowledge, which they pass
to their juniors by (as Zen Buddhists put it) 鈥渁 special transmission, outside the scriptures鈥�.

Software engineering is generally an exception to this rule; technology has changed so
rapidly, software environments have come and gone so quickly, that technical cultures have
been weak and ephemeral. There are, however, exceptions to this exception. A very few
software technologies have proved durable enough to evolve strong technical cultures,
distinctive arts, and an associated design philosophy transmitted across generations of
engineers.

The Unix culture is one of these. The Internet culture is another 鈥� or, in the twenty-first
century, perhaps the same one. The two have grown increasingly difficult to separate since
the early 1980s, and in this book we won't try particularly hard.

Prev Up Next

Chapter 1. Philosophy

Home The durability of Unix

The durability of Unix

Prev Chapter 1. Philosophy

Next



The durability of Unix

Unix was born in 1969, and has been in continuous production use ever since. That's several
geologic eras by computer-industry standards 鈥� older than the PC or workstations or
microprocessors or even video display terminals, and contemporaneous with the first
semiconductor memories. Unix holds the record for longest service life of any multiuser
operating system, ever. [2]

Unix has found use on a wider variety of machines than any other operating system can
claim. From supercomputers to handhelds and embedded networking hardware, through
workstations and servers and PCs and minicomputers, Unix has probably seen more
architectures and more odd hardware than any three other operating systems combined.

Unix has supported a mind-bogglingly wide spectrum of uses. No other operating system has
shone simultaneously as a research vehicle, a friendly host for technical custom applications,
a platform for commercial-off-the-shelf business software, and a vital component technology
of the Internet.

Confident predictions that Unix would wither away, or be crowded out by other operating
systems, have been made yearly since its infancy. And yet Unix, in its present-day avatars as
Linux and BSD and Solaris and Mac OS X and half a dozen other variants, seems stronger
than ever today.

At least one of Unix's central technologies 鈥� the C language 鈥� has been widely naturalized
elsewhere. Indeed it is now hard to imagine doing software engineering without C as a
ubiquitous lingua franca of systems programming. Unix also introduced the now-ubiquitous
tree-shaped file namespace with directory nodes.

Unix's durability and adaptability have been nothing short of astonishing. Other technologies
have come and gone like mayflies. Machines have increased a thousandfold in power,
languages have mutated, industry practice has gone through multiple revolutions 鈥� and
Unix hangs in there, still producing, still paying the bills, and still commanding loyalty from
many of the best and brightest software technologists on the planet.

Much of Unix's success has to be attributed to Unix's inherent strengths, to design decisions
Ken Thompson and Dennis Ritchie and Brian Kernighan and Doug McIlroy and Rob Pike
and other early Unix developers made back at the beginning; decisions that have been proven
sound over and over. But just as much is due to the design philosophy, art of programming,
and technical culture which grew up around Unix in the early days. This tradition has
continuously and successfully propagated itself in symbiosis with Unix ever since.


[2] About the only competitor in longevity is IBM's MVS operating system for S/390
mainframes, born in 1965.

Prev Up Next

Culture? What culture?

Home The case against learning Unix
culture

The case against learning Unix culture

Prev Chapter 1. Philosophy

Next



The case against learning Unix culture

Unix's durability and its technical culture are certainly of interest to people who already like
Unix, and perhaps to historians of technology. But Unix's original application as a general-
purpose timesharing system for larger computers is rapidly receding into the mists of history,
killed off by personal workstations. And there is certainly room for doubt that it will ever
achieve success in the mainstream business-desktop market presently dominated by
Microsoft.

Outsiders have frequently dismissed Unix as an academic toy or a hacker's sandbox. One
well-known polemic, the Unix Hater's Handbook [Garfinkel et al.] follows an antagonistic
line nearly as old as Unix itself in writing its devotees off as a cult religion of freaks and
losers. Certainly the colossal and repeated blunders of AT&T, Sun, Novell, and other
commercial vendors and standards consortia in mis-positioning and mis-marketing Unix
have become legendary.

Even from within the Unix world, Unix has seemed to be teetering on the brink of
universality for so long as to raise the suspicion that it will never actually get there. A
skeptical outside observer's conclusion might be that Unix is too useful to die but too
awkward to break out of the back room, a perpetual niche operating system.

What confounds the skeptics' case is, more than anything else, the rise of Linux and other
open-source Unixes. Unix's culture proved too vital to be smothered even by a decade of
vendor mismanagement. Today the Unix community itself has taken control of the
technology and marketing, and is rapidly and visibly solving Unix's problems.

Prev Up Next

The durability of Unix

Home What Unix gets wrong

What Unix gets wrong

Prev Chapter 1. Philosophy

Next



What Unix gets wrong

For a design that dates from 1969, it is remarkably hard to identify design choices in Unix
that are unequivocally wrong. There are several popular candidates, but each is still a subject
of spirited debate not merely among Unix fans but across the wider community of people
who think about and design operating systems.

Unix files have no structure above byte level. File deletion is forever. The Unix security
model is arguably too primitive. There are too many different kinds of names for things.
Having a file system at all may have been the wrong choice. We will discuss these technical
issues in Chapter 18 (Futures).

Perhaps the most enduring objections to Unix are consequences of a feature of its philosophy
first made explicit by the designers of the X window system. X strives to provide
鈥渕echanism, not policy鈥�, supporting an extremely general set of graphics operations and
deferring decisions about toolkits and interface look-and-feel (the policy) up to application
level. Unix's other system-level services display similar tendencies; final choices about
behavior are pushed as far towards the user as possible. Unix users can choose among
multiple shells. Unix programs normally provide many behavior options and sport elaborate
preference facilities.

This tendency reflects Unix's heritage as an operating system designed primarily for
technical users, and a consequent belief that users know better than operating-system
designers what their own needs are. But the cost of this approach is that when the user can
set policy, the user must set policy. Non-technical end-users frequently find Unix's profusion
of options and interface styles overwhelming and retreat to systems that at least pretend to
offer them simplicity.

In the short term, Unix's laissez-faire approach may lose it a good many nontechnical users.
In the long term, however, it may turn out that this 鈥榤istake鈥� confers a critical advantage 鈥�
because policy tends to have a short lifetime, mechanism a long one. Today's fashion in
interface look-and-feel too often becomes tomorrow's evolutionary dead end (as people using
obsolete X toolkits will tell you with some feeling!) So the flip side of the flip side is that the
鈥渕echanism, not policy鈥� philosophy may enable Unix to renew its relevance long after

competitors more tied to one set of policy or interface choices have faded from view.

Prev Up Next

The case against learning Unix
culture

Home What Unix gets right

What Unix gets right

Prev Chapter 1. Philosophy

Next



What Unix gets right

The explosive recent growth of Linux, and the increasing importance of the Internet, give us
good reasons to suppose that the skeptic's case is wrong. But even supposing the skeptical
assessment is true, Unix culture is worth learning because there are some things that Unix
and its surrounding culture clearly do better than any competitors.

Open-source software

Though the term 鈥渙pen source鈥� and the Open Source Definition were not invented until
1998, peer-review-intensive development of freely shared source code was a key feature of
the Unix culture from its beginnings.

For its first ten years AT&T's original Unix was normally distributed with source code. This
enabled most of the other good things that follow here.

Cross-platform portability and open standards

Unix is still the only operating system that can present a consistent, documented application
programming interface (API) across a heterogenous mix of computers, vendors, and special-
purpose hardware. It is the only operating system that can scale from embedded chips and
handhelds, up through desktop machines, through servers, and all the way to special-purpose
number-crunching behemoths and database back ends.

The Unix API is the closest thing to a hardware-independent standard for writing truly
portable software that exists. It is no accident that what the IEEE originally called the
Portable Operating System Standard quickly got a suffix added to its acronym and became
POSIX. A Unix-equivalent API was the only credible model for such a standard.

Binary-only applications for other operating systems die with their birth environments, but
Unix sources are forever. Forever, at least, given a Unix technical culture that polishes and
maintains them across decades.

The Internet

The Defense Department's contract for the first production TCP/IP stack went to a Unix
development group because the Unix in question was largely open source. Besides TCP/IP,
Unix has become the one indispensible core technology of the Internet service industry. Ever
since the demise of the TOPS family of operating systems in the mid-1980s, most Internet
server machines (and effectively all above the PC level) have been Unix.

Not even Microsoft's awesome marketing clout has been able to dent Unix's lock on the
Internet. While the TCP/IP standards on which the Internet is based evolved under TOPS-10
and are theoretically separable from Unix, attempts to make them work on other operating
systems have been bedeviled by incompatibilities, instabilities, and bugs. The theory and
RFCs are available to anyone, but the engineering tradition to make them into a solid and
working reality exists only in the Unix world.

The Internet technical culture and the Unix culture began to merge in the the early 1980s,
and are now inseparably symbiotic. To function effectively as an Internet expert, an
understanding of Unix and its culture are indispensible.

The open-source community

The community that originally formed around the early Unix source distributions never went
away 鈥� after the great Internet explosion of the early 1990s, it recruited an entire new
generation of eager hackers on home machines.

Today, that community is a powerful support group for all kinds of software development.
High-quality open-source development tools abound in the Unix world (we'll examine many
in this book). Open-source Unix applications are usually equal to, and are often superior to,
their proprietary equivalents [Barton et al.]. Entire Unix operating systems, with complete
toolkits and basic applications suites, are available for free over the Internet. Why code from
scratch when you can adapt, reuse, recycle, and save yourself 90% of the work?

This tradition of code-sharing depends heavily on hard-won expertise about how to make
programs cooperative and reusable. And not by abstract theory, but through a lot of
engineering practice 鈥� unobvious design rules that allow programs to function not just as
isolated one-shot solutions but as synergistic parts of a toolkit.

Today, a burgeoning open-source movement is bringing new vitality, new technical

approaches, and an entire generation of bright young programmers into the Unix tradition.
Open-source projects including the Linux operating system and symbiotes such as Apache
and Mozilla have brought the Unix tradition an unprecedented level of mainstream visibility
and success. The open-source movement seems on the verge of winning its bid to define the
computing infrastructure of tomorrow 鈥� and the core of that infrastructure will be Unix
machines running on the Internet.

Flexibility in depth

Many operating systems touted as more 鈥榤odern鈥� or 鈥榰ser-friendly鈥� than Unix achieve their
surface glossiness by locking users and developers into one interface policy, and offer an
application-programming interface that for all its elaborateness is rather narrow and rigid. On
such systems, tasks the designers have anticipated are very easy 鈥� but tasks they have not
anticipated are often impossible or at best extremely painful.

Unix, on the other hand, has flexibility in depth. The many ways Unix provides to glue
together programs mean that components of its basic toolkit can be combined to produce
useful effects that the designers of the individual toolkit parts never anticipated.

Unix's support of multiple styles of program interface (often seen as a weakness because it
increases the perceived complexity of the system to end-users) also contributes to flexibility;
no program that wants to be a simple piece of data plumbing is forced to carry the
complexity overhead of an elaborate GUI.

Unix tradition lays heavy emphasis on keeping programming interfaces relatively small,
clean, and orthogonal 鈥� another trait that produces flexibility in depth. Throughout a Unix
system, easy things are easy and hard things are at least possible.

Unix is fun to hack

People who pontificate about Unix's technical superiority often don't mention what may
ultimately be its most important strength, the one that underlies all its successes. Unix is fun
to hack.

Unix boosters seem almost ashamed to acknowledge this sometimes, as though admitting
they're having fun might damage their legitimacy somehow. But it's true; Unix is fun to play
with and develop for, and always has been.