Bookpool: The Art of UNIX Programming

Eric S. Raymond unlocks the software design secrets of the original UNIX designers for the next generation with advice from the masters themselves. Written by Open Source icon and GNU pioneer Eric S. Raymond--the author of The Cathedral and the Bazaar. Learn how the UNIX and Linux masters design software that is fast, portable, reuseable, modular, and long-lived. Includes contributions from UNIX luminaries including Doug McIlroy, David Korn, Jim Gettys, Keith Packard, and Henry Spencer.

1. Philosophy.

Culture? What culture?
The durability of Unix.
The case against learning Unix culture.
What Unix gets wrong.
What Unix gets right.
Basics of the Unix philosophy.

The Unix philosophy in one lesson.

Applying the Unix philosophy.
Attitude matters too.

2. History.

Origins and history of Unix, 1969-1995.
Origins and history of the hackers, 1961-1995.
The open-source movement: 1998 and onward.
The lessons of Unix history.

3. Contrasts.

The elements of operating-system style.
Operating-system comparisons.
What goes around, comes around.

4. Modularity.

Encapsulation and optimal module size.
Compactness and orthogonality.
Libraries.
Unix and object-oriented languages.
Coding for modularity.

5. Textuality.

The Importance of Being Textual.
Data file metaformats.
Application protocol design.
Application protocol metaformats.

6. Transparency.

Some case studies.
Designing for transparency and discoverability.
Designing for maintainability.

7. Multiprogramming.

Separating complexity control from performance tuning.
Taxonomy of Unix IPC methods.
Problems and methods to avoid.
Process partitioning at the design level.

8. Minilanguages.

Taxonomy of languages.
Applying minilanguages.
Designing minilanguages.

9. Transformation.

Data-driven programming.
Ad-hoc code generation.

10. Configuration.

What should be configurable?
Where configurations live.
Run-control files.
Environment variables.
Command-line options.
How to choose among configuration-setting methods.
On breaking these rules.

11. Interfaces.

Applying the Rule of Least Surprise.
History of interface design on Unix.
Evaluating interface designs.
Tradeoffs between CLI and visual interfaces.
Transparency, expressiveness, and configurability.
Unix interface design patterns.
Applying Unix interface-design patterns.
The Web browser as universal front end.
Silence is golden.

12. Optimization.

Don't just do something, stand there!
Measure before optimizing.
Non-locality considered harmful.
Throughput vs. latency.

13. Complexity.

Speaking of complexity.
A Tale of Five Editors.
The right size for an editor.
The right size of software.

14. Languages.

Unix's Cornucopia of Languages.
Why Not C?
Interpreted Languages and Mixed Strategies.
Language evaluations.
Trends for the Future.
Choosing an X toolkit.

15. Tools.

A developer-friendly operating system.
Choosing an editor.
Special-purpose code generators.
Make in non-C/C++ Development.
Version-control systems.
Run-time debugging.
Profiling.
Emacs as the universal front end.

16. Re-Use.

The tale of J. Random Newbie.
Transparency as the key to re-use.
From re-use to open source.
The best things in life are open.
Where should I look?
What are the issues in using open-source software?
Licensing issues.

17. Portability.
Evolution of C.
Unix standards.
Specifications as DNA, code as RNA.
Programming for Portability.
Internationalization.
Portability, open standards and open source.
18. Documentation.
Documentation concepts.
The Unix style.
The zoo of Unix documentation formats.
The present chaos and a possible way out.
The DocBook toolchain.
How to write Unix documentation.
19. Open Source.
Unix and open source.
Best practices for working with open-source developers.
The logic of licenses: how to pick one.
Why you should use a standard license.
Varieties of Open-Source Licensing.
20. Futures.
Essence and accident in Unix tradition.
Problems in the design of Unix.
Problems in the environment of Unix.
Problems in the culture of Unix.
Reasons to believe.
A. Glossary of Abbreviations.
B. References.
C. Contributors.

Oct 29, 2003 Philip S. Ehrens from Los Angeles, CA, USA
No UNIX guru Should be without it!
Eric S. Raymond has achieved a wide reputation; as an advocate of Open Source (as opposed to Free Software), as a writer of manifestos (The Cathedral and The Bazaar), as the original maintainer of The Jargon File, and even as a programmer (Fetchmail, and recently Bogofilter). His advocacy has been sometimes at the expense of Richard M. Stallman, which has not always redounded to Raymond's benefit.

With The Art of UNIX Programming, Raymond moves into a new area (for him), the software engineering guide. This is a relatively obscure genre comprising a relatively small number of books, including to my way of defining it, Modern Operating Systems (Tanenbaum), The Practice of Programming (aka "The Wiener Dog Book", by Kernighan and Pike), The Magic Garden Explained (currently selling for $300 used!!), and a few others. These books share the common goal of imparting maximum accumulated wisdom to those best positioned to take advantage of it. These books target the folks who live, eat, and breathe software.

While not a cookbook, The Art of UNIX Programming does provide an extensive set of rule-of-thumb and the-right-way recommendations for designing interfaces and for generally maintaining a UNIX style approach to implementation. Examples are presented of interfaces to protocols, and to client software, mixing the discussion of frontends and backends in a unified context that works very well.

Raymond makes no bones about being an active critic of the various incarnations of Microsoft Windows. He makes strong arguments against the sanity of the windows development model, and supports those arguments very well. Perhaps it is a reflection of my own prejudice that I can support this while being offended by his treatment of Richard Stallman. But then again, Windows really sucks.

A pet peeve of mine is unneccesary bashing of the Tcl programming language. Raymond takes a far greater number of pokes at Perl than at Tcl, but does nevertheless propagate the myth that Tcl's namespace facility is in some way a limiting factor to scalability of Tcl programs. This is, of course, ridiculous, and it is unfortunate that nobody capable of correcting this mistake was in the right place at the right time to nix it. Not only does Tcl have a well implemented namespace facility, but it has a brilliant core socket abstraction, and most importantly, an efficient event loop, similar to the one that Raymond lauds in X (hence it's ability to manage complex Tk programs).

I find considerable evidence within the text of The Art of UNIX Programming suggesting that the original title may have been The Zen of UNIX Programming, or maybe Zen and The Art of UNIX Programming,. I think the references to Zen in the text would seem less out of the blue if the title had been so, anyway. A more on-the-ball editor could have made a better job of it.

In spite of many things that I have written here that seem critical of the book, I recommend The Art of UNIX Programming highly. I have given several copies to friends, and I have recommended it as a software design and implementation handbook at work. I recommend this book to anyone working in a UNIX environment in any capacity, but to coders especially. Raymonds observations on threads are worth the price of the book, to anyone willing to heed the warning.

Table of Contents