Back to Eric's Home Page Up to Site Map $Date: 2001/02/09 02:25:36 $

The Art Of Unix Programming

You can browse the contents page and some chapters of my next book in progress here. I've posted it so you can comment on, add to, and correct the draft.

This book will attempt to capture the engineering wisdom and philosophy of the Unix community as it's applied today -- not merely as it has been written down in the past, but as a living "special transmission, outside the scriptures" passed from guru to guru. Accordingly, the book doesn't focus so much on "what" as on "why", showing the connection between Unix philosophy and practice through case studies in widely available open-source software.

Contents page
(Note: Many of the chapter links don't go anywhere yet!)

Preface
Who should read this book. How to use it. Acknowledgements.

Chapter 1
Philosophy Matters
Chapter 2
On Not Reinventing the Wheel
Chapter 3
Unix's Zoo of Languages
Chapter 4
The Tactics of Development
Where you see `FIXME' in the manuscript, take that as an invitation. This is an open project; critiques, comments and additions will be welcome. See below for more on how you can get involved.

My ambitions for this book are not small. With the assistance of the community, I hope to create a true classic here, a book that will speak with authority of and for for the Unix tradition -- and convey the essence of that tradition to the new generation of programmers who have grown up with Linux and the Web.

How This Project Came To Be

A few years ago, my friend Erik Troan (one of the principal developers at Red Hat Software, the leading commercial Linux distributor) did a book called "Linux Applications Development" with Addison-Wesley, and requested me as a manuscript reviewer. When I saw the manuscript, I wrote back that I thought it was very good as far as it went, but that a book on Linux development ought to cover a lot more than just the C API and operating system services.

I told Erik that I thought a really good book on Linux development ought to also tackle design-level and more philosophical issues, like

Erik turned around and challenged me to write that book. Later, three publishers (O'Reilly, Macmillan, and Addison-Wesley) made happy noises when they heard the concept.

How You Can Contribute

It would be hubristic and doomed for me to try and write a book like this entirely on my own. While I wouldn't be the least plausible person on the planet to make the attempt, the body of implicit knowledge the book must tour is just too big for any one person to have expert-level chops at all of it. Accordingly, I'm looking for help.

What I hope to do is develop a brains trust of contributors who will help shape, develop and critique the book at an earlier stage than technical reviewers normally get involved. These contributors will be credited by name and area of expertise in the book.

Contributors who are senior cadre with established public reputations for excellence across the entire Unix community will be directly quoted in the body of the book (see for example the epigram from Henry Spencer at the beginning of Chapter 1). Ideally, the effect will be almost Talmudic, with periodic bits of commentary by revered elders adding both depth and color to the mainline text.

The rule for who makes it into this revered-elder class is simple: if every Unix hacker has probably heard your name, you're eligible (in particular, Linux-community fame by itself will not be enough). These senior contributors must not only be the best, but be known to be the best.

I will do the heavy lifting in the writing and research department. The major responsibility of contributors will be to suggest and comment on software case studies illustrating (or perhaps refuting!) the principles discussed in the book. Note: it is not useful to toss names of potential case studies at me without some fairly detailed explanation of why you think they are applicable.

Formal co-authorship status may be available to one or perhaps two contributors who contribute lots of case studies and new topic material, especially if they do a lot of writing that I find needs little or no alteration to fit the book's theme and scheme.

(Yes, this is an unusual mode of collaboration. But I've already shown with The New Hacker's Dictionary that I can make something like it work to the satisfaction of the participants and the community at large.)

Current Status of the Project

Several publishers are interested in this book. I have not signed a contract, and won't until it's done -- and I'm not going to rush it, either.

Here are the recent changes:

7 Feb 2001 -- added "What Unix Got Wrong" and "Flexibility In Depth" to Chapter 1, working from a critique by the UIUC System Architecture Group. Minor updates to Chapter 2. Chapters 3 and 4 released.


Back to Eric's Home Page Up to Site Map $Date: 2001/02/09 02:25:36 $

Eric S. Raymond <esr@thyrsus.com>