Related References

Prev Preface

Next



Related References

Some famous papers and a few books by Unix's early developers have mined this territory
before. Kernighan & Pike's The Unix Programming Environment [Kernighan&Pike84]
stands out among these and is rightly considered a classic. But today it shows its age a bit; it
doesn't cover TCP/IP, the Internet, and the World Wide Web or the new wave of interpretive
languages like Perl, Tcl, and Python.

About halfway into the composition of this book, we learned of Mike Gancarz's The Unix
Philosophy [Gancarz]. This book is excellent within its range, but did not attempt to cover
the full spectrum of topics which we felt needed to be addressed. Nevertheless we are
grateful to the author for the reminder that the very simplest Unix design patterns have been
the most persistent and successful ones.

The Pragmatic Programmer [Hunt&Thomas] is a witty and wise disquisition on good design
practice pitched at a slightly different level of the software-design craft (more about coding,
less about higher-level partitioning of problems) than this book. The authors' philosophy is
an outgrowth of Unix experience, and it is an excellent complement to this book.

The Practice of Programming [Kernighan&Pike99] covers some of the same ground as The
Pragmatic Programmer from a position deep within the Unix tradition.

Finally (and with admitted intent to provoke) we recommend Zen Flesh, Zen Bones [Zen], an
important collection of Zen Buddhist primary sources. There will be references to Zen
scattered throughout this book. They are included because Zen provides a vocabulary for
addressing some ideas that turn out to be very important for software design but are
otherwise very difficult to hold in the mind. Readers with religious attachments are invited to
consider Zen not as a religion but as a therapeutic form of mental discipline 鈥� which, in its
purest non-theistic forms, is exactly what Zen is.

Prev Up Next

How To Use This Book

Home Conventions Used In This Book

Conventions Used In This Book

Prev Preface

Next



Conventions Used In This Book

The term 鈥淯nix鈥� is technically and legally a trademark of the X/Open group, and should
formally be used only for operating systems which are certified to have passed X/Open's
elaborate standards-conformance tests. In this book we use 鈥淯nix鈥� in the looser sense widely
current among programmers, to refer to any operating system (whether formally Unix-
branded or not) that is either genetically descended from Bell Labs's ancestral Unix code or
written in close imitation of its descendants. In particular, Linux (from which we draw most
of our examples) is a Unix under this definition.

This book employs the Unix manual page convention of tagging Unix facilities with a
following manual section in parentheses, usually on first introduction when we want to
emphasize that this is a Unix command. Thus, for example, read 鈥渕unger(1)鈥� as 鈥渢he
鈥榤unger鈥� program, which will be documented in section 1 (user tools) of the Unix manual
pages, if it's present on your system.鈥� Section 2 is C system calls, section 3 is C library calls,
section 5 is file formats and protocols, section 8 is system administration tools. Other
sections vary between Unixes but are not cited in this book. For more, type man 1 man at
your Unix shell prompt (older System V Unixes may require man -s 1 man).

Sometimes we will mention a Unix application (such as yacc, emacs, lex) without a manual-
section suffix. This is a clue that the name actually represents a well-established family of
Unix programs with essentially the same function, and we are discussing generic properties
of all of them. Yacc, for example, stands in not just for yacc itself but for bison and byacc as
well; emacs includes xemacs; and lex also includes flex.

At various points later in this book we'll refer to 鈥榦ld-school鈥� and 鈥榥ew-school鈥� methods. As
with rap music, new-school starts about 1990. In this context, it's associated with the rise of
scripting languages, GUIs, open-source Unixes, and the Web. Old-school refers to the pre-
1990 (and especially pre-1985) world of expensive computers, proprietary Unixes, scripting
in shell, and C everywhere. This difference is worth pointing out because cheaper and less
memory-constrained machines have wrought some significant changes on the Unix
programming style.

Prev Up Next

Related References

Home Our Case Studies

Our Case Studies

Prev Preface

Next



Our Case Studies

A lot of books on programming rely on toy examples constructed specifically to prove a
point. This one won't. Our case studies will be real, pre-existing pieces of software that are in
production use every day. Here are some of the major ones:

cdrtools/xcdroast
These are two separate projects that are usually used together. The cdrtools package is
a set of CLI tools for writing CD-ROMS; web search for 鈥渃drtools鈥�. The xcdroast
application is a GUI front end for cdrtools; see the xcdroast project site.
fetchmail
Fetchmail is a program that retrieves mail from remote-mail servers using the POP3
or IMAP post-office protocols. There is a fetchmail home page (or search for
"fetchmail" in page titles).
GIMP
The GIMP (GNU Image Manipulation Program) is a full-featured paint, draw, and
image-manipulation program that can edit a huge variety of graphical formats in
sophisticated ways. Sources are available from the GIMP home page (or search for
"GIMP" in page titles).
keeper
The program used to create World Wide Web and FTP indexes that put an easily-
navigable structure on the ibiblio.org (formerly Metalab, and before that Sunsite)
archives. Sources are available on ibiblio.org in the 鈥榮earch鈥� directory.
mutt
The mutt mail user agent is the current best-of-breed among text-based Unix
electronic mail agents, with notably good support for MIME (Multipurpose Internet
Mail Extensions) and the use of privacy aids such as PGP (Pretty Good Privacy) and

GPG (GNU Privacy Guard). Source code and executable binaries are available at the
Mutt project site.
xmlto
A command to render DocBook and other XML documents in various output formats,
including HTML and text and PostScript. Sources and documentation at the xmlto
project site.


To minimize the amount of code the user needs to read to understand the examples, we have
tried to choose case studies that can be used more than once, ideally to illustrate several
different design principles and practices. For this same reason, many of the examples are
from projects of the author. No claim that these are the best possible ones are implied,
merely that the author finds them sufficiently familiar to be useful for multiple expository
purposes.

Prev Up Next

Conventions Used In This Book

Home Author's Acknowledgements

Author's Acknowledgements

Prev Preface

Next



Author's Acknowledgements

This book benefitted from discussions with many people other than the guest contributors.
Mark M. Miller helped me achieve enlightenment about threads. John Cowan supplied some
insights about interface design patterns, and Jef Raskin showed me where the Rule of Least
Surprise comes from. The UIUC System Architecture Group contributed useful feedback on
early chapters. The sections on What Unix gets wrong and Flexibility in depth were directly
inspired by their review. Russell J. Nelson contributed the material on Bernstein chaining in
Chapter 6 (Multiprogramming). Les Hatton provided many helpful comments on the
Languages chapter and motivated the portion of Chapter 4 (Modularity) on Optimal module
size.

Special thanks go to Rob Landley and Catherine Raymond, who delivered intensive line-by-
line critiques of early drafts. Hundreds of Unix programmers, far too many to mention here,
contributed advice and comments during the book's public review period between January
and June of 2003.

The expository style and some of the concerns of this book have been influenced by the
design patterns movement; indeed, I flirted with the idea of titling it Unix Design Patterns. I
didn't, because I disagree with some of the implicit central dogmas of the movement and
don't feel the need to use all its formal apparatus or accept its cultural baggage. Nevertheless,
I owe the Gang of Four and other members of their school a large debt of gratitude for
showing me how it is possible to talk about design at a high level without merely uttering
vague and useless generalities. Interested readers should see Design Patterns: Elements of
Reusable Object-Oriented Software [GoF] for an introduction to design patterns.

Prev Up Next

Our Case Studies

Home Part I. Context

Part I. Context

Prev

Next



Context

Table of Contents

1. Philosophy
Culture? What culture?
The durability of Unix
The case against learning Unix culture
What Unix gets wrong
What Unix gets right
Open-source software
Cross-platform portability and open standards
The Internet
The open-source community
Flexibility in depth
Unix is fun to hack
The lessons of Unix can be applied elsewhere



Basics of the Unix philosophy
Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Composition: Design programs to be connected with other programs.
Rule of Clarity: Clarity is better than cleverness.
Rule of Simplicity: Design for simplicity; add complexity only where you
must.
Rule of Transparency: Design for visibility to make inspection and debugging
easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Least Surprise: In interface design, always do the least surprising
thing.
Rule of Repair: Repair what you can 鈥� but when you must fail, fail noisily
and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to

machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs
when you 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



2. History
Origins and history of Unix, 1969-1995
Genesis: 1969-1971
Exodus: 1971-1980
TCP/IP and the Unix Wars: 1980-1990
Blows against the empire: 1991-1995



Origins and history of the hackers, 1961-1995
At play in the groves of academe: 1961-1980
Internet fusion and the Free Software Movement: 1981-1991
Linux and the pragmatist reaction: 1991-1998



The open-source movement: 1998 and onward.
The lessons of Unix history



3. Contrasts
The elements of operating-system style
What is the unifying idea?
Cooperating processes
Internal boundaries
File attributes and record structures
Binary file formats
Preferred UI style

Who is the intended audience?
What are the entry barriers to development?



Operating-system comparisons
VMS
Mac OS
OS/2
Windows NT
BeOS
Linux



What goes around, comes around





Prev Up Next

Author's Acknowledgements

Home Chapter 1. Philosophy

Chapter 1. Philosophy

Prev Part I. Context

Next



Chapter 1. Philosophy

Philosophy Matters

Table of Contents

Culture? What culture?
The durability of Unix
The case against learning Unix culture
What Unix gets wrong
What Unix gets right
Open-source software
Cross-platform portability and open standards
The Internet
The open-source community
Flexibility in depth
Unix is fun to hack
The lessons of Unix can be applied elsewhere



Basics of the Unix philosophy
Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Composition: Design programs to be connected with other programs.
Rule of Clarity: Clarity is better than cleverness.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Repair: Repair what you can 鈥� but when you must fail, fail noisily and as
soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to
machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you