Welcome!

Linux Authors: Katharine Hadow, Hovhannes Avoyan, Anatoly Krivitsky, Pat Romanski, Suresh Krishna Madhuvarsu

Related Topics: Linux

Linux: Article

The Art of UNIX Programming

The history, culture, and philosophy behind UNIX development

"Those who do not understand UNIX are doomed to reinvent it, poorly."

– Henry Spencer, Usenet signature, November 1987

So begins the first chapter of Eric Raymond's newest book, The Art of UNIX Programming. In the pages that follow Eric does his best to make sure readers do understand UNIX by bringing them along on a journey beginning in the earliest days of "timesharing" systems in the 1960s and continuing right up to today. Along the way, readers meet (via their review comments inserted into the book) such UNIX luminaries as Ken Thompson (original inventor of UNIX while at AT&T Bell Labs), David Korn (who wrote the Korn shell), Brian Kernighan (Author of the classic book The C Programming Language), and a number of others. The Art of UNIX Programming is a seminal work from one of the masters in the field.

Eric strives to achieve two equally important goals with this book. First, he attempts to teach the reader the "art" of developing applications using UNIX. To accomplish this he provides a great number of examples, design patterns, case studies, and "rules of thumb" that the reader can use to understand what essentially is a series of best practices for application development and architecture using UNIX.

Second, and potentially more valuable, Eric does his best to instill in the reader an understanding of the culture and history of UNIX and of the "Hacker Culture" that grew up around it. He provides quotes and anecdotes from many of the pioneers behind UNIX, a chapter dedicated directly to UNIX philosophy and culture, and a series of parables, or koans, in the form of lessons from a Zen Master Foo to an aspiring student.

Some of the design "rules" that Eric provides are:

  • Rule of Clarity: Clarity is better than cleverness
  • Rule of Modularity: Write simple parts connected by clean interfaces
  • Rule of Composition: Design programs to be connected with other programs

    While simple ideas, taken together they will teach developers to program in a way that will allow them to become most successful using UNIX. These ideas will also make UNIX administrators more effective by helping them understand why the programs they use work the way they do.

    But why does the world need a book that outlines and teaches the history, culture, and philosophy behind UNIX development? To begin with, we need it because many of the original UNIX pioneers are getting to the point of retiring now. Much of the lore behind the early development of UNIX and how it came to be is an oral (and Usenet-based) history; if no one writes it down in a single place, much of it will simply be lost.

    Also, with the explosion of Linux, there are now many more developers using UNIX than there ever were before. It's important to the community in existence now that we pass these stories and the culture and values we've created to this new generation.

    It also takes developers a long time to learn all this if they have to learn it on their own. I spent close to five years as a C/UNIX developer and can tell you having this book would've helped me understand how to become more effective much faster.

    But even more important is understanding this culture and its impact on the history (and future) of Linux. As Linux becomes more and more popular and its worldwide economic impact grows, the pressures on it to become controlled and directed by major corporations will grow as well. The only thing that will ensure its independence, and potentially its survival, will be the community around it. The culture and philosophy outlined in this book can help tie the community together and strengthen it.

    After all, what is a community except a group of individuals united by a common purpose and sharing a common culture, philosophy, and values?

  • More Stories By Kevin Bedell

    Kevin Bedell, one of the founding editors of Linux.SYS-CON.com, writes and speaks frequently on Linux and open source. He is the director of consulting and training for Black Duck Software.

    Comments (1) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Rick Burque 12/16/03 10:16:30 AM EST

    I think the preference to code it yourself vs. uunderstand and use other's code is pretty widespread. I have have been an applications programmer for years and I have to admit that many times I have found it easier (and faster) to arrive at a solution to a problem by writing my own routines rather than step through someone elses work. Also, psychologically, I think programmers get more satisfaction coming up with their own solutions. I think programmers tend to be strong individualists who get their sense of self-worth from actively creating things. There is less glory in spending a lot of time trying to make sense of someone elses work. Programmers love to code. There is also an egotistical element at work which tends to trivialize others work or voice doubts as to its effciency or correctness. "I can do better than that..." is the mentality. This is a positive attitude when it leads to real improvements, but in many cases is probably just "vanity".