Rating: 
Summary: More books like this need to be written
Review: "The Art of UNIX Programming" (TAOUP) is a unique book, since it deals with "UNIX" engineering principles. ("UNIX" means the original OS as well as derivatives and relatives.) Rather than discuss the filesystem, commands, or services, TAOUP explains history, culture, and rationale. I found the book enlightening and easy to read and recommend it to all UNIX users.Several reviewers critique author Eric Raymond's assessments of programming languages and the Windows OS family. As a security engineer I see Windows continue to fail miserably, so much so that I'm beginning to agree that Windows cannot be secured. (Almost one year ago I criticized Bellovin et al for the same judgment, but now I tend to agree.) I would be surprised if a real Windows advocate reviewed and contributed to drafts of TAOUP, as a few strategic pro-Windows points might have made ESR's other arguments stronger. A second way to strengthen the anti-Windows stance would be more technical discussion of Windows flaws. The devastating "shatter" flaws of 2002 merit no more than a footnote on page 69, but could have a been a whole section unto themselves. Regarding languages and OS comparisons, at this early point in my career I fit the "fool" category of p. 507. I leave it to more experienced developers to debate programming language virtues. It seems the author is not as current on language developments as his critics, which is regrettable but understandable given TAOUP's scope. I personally questioned the repeated invocation of Emacs Lisp. I found ESR's recommendation to employ interpreted languages useful and plan to take a closer look at Python. I question ESR's claim on p. 382 that GCC is so powerful that "there is effectively no proprietary UNIX compiler market left," when Sun's compiler for Solaris seems to outperform GCC. I found histories of "UNIX vs. UNIX" and "UNIX vs the world" very informative. TAOUP presents concise explanations of licensing, RFC creation, and UNIX philosophy. I was happy to see that an open source project to which I contribute (Sguil) met many UNIX design criteria, like text-based communication between small collaborating daemons. I plan to follow TAOUP's recommendations for documentation so helpfully discussed in chapter 18 when I release the next set of Sguil guides. TAOUP offers numerous priceless quotes from UNIX pioneers, but ESR himself offers my favorite: "Open source is what happens when code reuse gets a flag and an army." I hope UNIX advocates everywhere carry TAOUP into battle against their proprietary, monopolistic OS foes. With a few more nods to the enemy and a more balanced comparison of languages, TAOUP will be unbeatable.
Rating: 
Summary: Hate to be the one to burst the proverbial bubble...
Review: ...but ESR's theory and ideology is rediculously flawed with misappropriated valuations. This is, yet another advocacy campaign for gnu/Linux, mixed in with a UNIX context. Given the purpose of the book, it's a fair assessment to label the burdening bias as filler and firewood: filler for those who really just wanted an explanation of the single-purpose, POSIX illustrated, hows and whys of UNIX programming philosophy; and firewood for those who tend to buy into slanderous hype at the whim of suggestion. Questions: What is the title of the book? What programmatic philosophies are portrayed? How many unices are open source? Of those, how many subscribe to the same opensource mentality as gnu/Linux? Answer: zilch. Question: Then what is the relevance of such topics to the objectives of the book, as depicted in the title? Answer: fudd-ala-mode. Aside from these intertwined distractions, and a severe Napoleonic complex against anything new or different, ESR does adequately represent the real purpose of the book, and in those efforts place value in the read.
Rating:
Summary: Hate to be the one to burst the proverbial bubble...
Review: ...but ESR's theory and ideology is rediculously flawed with misappropriated valuations. This is, yet another advocacy campaign for gnu/Linux, mixed in with a UNIX context. Given the purpose of the book, it's a fair assessment to label the burdening bias as filler and firewood: filler for those who really just wanted an explanation of the single-purpose, POSIX illustrated, hows and whys of UNIX programming philosophy; and firewood for those who tend to buy into slanderous hype at the whim of suggestion. Questions: What is the title of the book? What programmatic philosophies are portrayed? How many unices are open source? Of those, how many subscribe to the same opensource mentality as gnu/Linux? Answer: zilch. Question: Then what is the relevance of such topics to the objectives of the book, as depicted in the title? Answer: fudd-ala-mode. Aside from these intertwined distractions, and a severe Napoleonic complex against anything new or different, ESR does adequately represent the real purpose of the book, and in those efforts place value in the read.
Rating: 
Summary: Filled with good stuff
Review: By reading this book, one can truly realize the greatness of the Unix operating system and all of its glory. How it has revolutionized the software and more specifically the Operating System industry over and over again for the past 30+ years.
This book has four parts, and each part is packed with useful information... The first part talks about the philosophy, the history and background of Unix. It's a very easy read and it familiarizes the reader the background of Unix and what will be covered in the rest of the book. Basic rules that Unix was based upon and their explanations are to me, the highlight of the first section. Part 2, focuses on the various design rules and philosophies that were covered in part 1.
It is packed with small, easy to read and understand case studies that explain the design philosophy that was just explained. It is very interesting to see that some of what we call "best practices" today have been around for years and years in the Unix community and have been perfected thru out the years. Very valuable to any software architect. It will give you some ideas what has been done and what not to do when you are designing a piece of software - b/c the chances are that it has been implemented in Unix before. Part 3 goes into a great depth trying to explain the various options programmers have when developing for Unix.
Considering that an entire volume can be dedicated to this section, the author does a great job in explaining the various options for developers. Keeping the philosophies mentioned in part I, the author conveys the pros and the cons of various programming languages, scripting languages, took kits, etc... Part 4 covers odds and ends of this topic. It gives you tips on how to work with the Open Source Community and what you need to do if you want release code into the open source community. The tips are also very valuable even if you are developing software for your company... One of my favorite sections in part 4 was when the author talks about the various licenses and their differences and how to choose one. With all the lawsuits surrounding the Unix community, it's good for every developer to know what options are available out there.
Rating: 
Summary: Mixed Bag
Review: Eric does a good job of covering the history of UNIX. I wish there was more content from his "guest" writers -- they have more interesting and authoritative stories to tell. It's a good book if you like his style: a complex and changing mix between high-brow and plain-talk, history and personal opinions. The author would do well to follow his own advice: page 434, "Don't think for a moment that volume will be mistaken for quality." Don't worry, we won't. This is about the fattest and most wordy UNIX book you can find. I like how he continually disses the 'make' command for using a tab character in its 'makefile'. He calls it: "one of the worst design botches in the history of Unix". Then how can he wax poetic over Python, which also uses white space in a syntactically meaningful way? His distain for Tcl is apparent, but I wish he'd at least hate a version that's been made in the last 9 years. Quoting Ousterhout from 1995 doesn't seem relevant in 2004. Tcl has had namespaces for quite awhile now, and there are "batteries included" distributions. Saying it's simple, and then claiming it's complex, doesn't make sense. Finally, one of his examples of stellar programming is Audacity. I tried it and found it quite lacking. It's great if you want buttons as large as quarters, but the functionality wasn't enough for my modest editing needs. Yeah, I'm way too picky. But it's a $40 (list) book, so it ought to be better than it is. Perhaps it would have enjoyed life as an on-line book. On the other hand, there's nothing else like it on the market, so we have to be grateful that he put all the hard work into making it. Anon, just for the heck of it.
Rating:
Summary: Mixed Bag
Review: Eric does a good job of covering the history of UNIX. I wish there was more content from his "guest" writers -- they have more interesting and authoritative stories to tell. It's a good book if you like his style: a complex and changing mix between high-brow and plain-talk, history and personal opinions. The author would do well to follow his own advice: page 434, "Don't think for a moment that volume will be mistaken for quality." Don't worry, we won't. This is about the fattest and most wordy UNIX book you can find. I like how he continually disses the 'make' command for using a tab character in its 'makefile'. He calls it: "one of the worst design botches in the history of Unix". Then how can he wax poetic over Python, which also uses white space in a syntactically meaningful way? His distain for Tcl is apparent, but I wish he'd at least hate a version that's been made in the last 9 years. Quoting Ousterhout from 1995 doesn't seem relevant in 2004. Tcl has had namespaces for quite awhile now, and there are "batteries included" distributions. Saying it's simple, and then claiming it's complex, doesn't make sense. Finally, one of his examples of stellar programming is Audacity. I tried it and found it quite lacking. It's great if you want buttons as large as quarters, but the functionality wasn't enough for my modest editing needs. Yeah, I'm way too picky. But it's a $40 (list) book, so it ought to be better than it is. Perhaps it would have enjoyed life as an on-line book. On the other hand, there's nothing else like it on the market, so we have to be grateful that he put all the hard work into making it. Anon, just for the heck of it.
Rating:
Summary: Indispensable addition to a UNIX guru's bookshelf
Review: 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.
Rating:
Summary: The patterns of UNIX and how you can use them
Review: Even for a primarily Windows programmer, this is a great book to read. He provides a great overview of the Unix design philosophy, its evolution over time, and the things that it still doesn't handle well (user-centered design). He also digs deeper into a lot of the patterns in program organization and coordination to help you choose what to build into a utility, what to expose as a library, and what to package as a set of binaries. There's even a small bit of programming advice from place to place. I'd highly recommend reading the book to at least get a sense of perspective when you're designing your next system. He's right on the mark that the Windows and UNIX worlds have a completely different philosophy on program construction, each with their own merits. His comments about the Windows registry were a bit distressing, though -- not because they're negative, which I consider fine. Rather, it was obvious he'd never used it (comments like "there's no API for it") and it was also clear that he hadn't even bothered to research why it existed and what problems it was intended to solve. The comments were typical of what I'd expect of a Slashdot troll, but not of a bright, respectable person like ESR. I've programmed on both platforms extensively and only comment on what I have first-hand experience and knowledge of; I'd expect him to do the no less, especially as an author. It was also curious that several times he implied unit testing == XP == agile software development. For as tuned in as he seems to be to methodolgy work, missing the forest for a single leaf is a bit embarrassing.
Rating:
Summary: Great, sprawling read
Review: Focus on the strengths of the Unix philosophy. Helps experienced people put "things they've always known" into words.
Rating:
Summary: Good sound advice
Review: I purchased this book as soon as it was avalible is September 2003. Mr. Raymond gives good sound advice that this Computer Science student has taken to heart is his studies. The advice is so simple, obvious, and logical that you will find yourself wondering why you didn't think of these things in the first place.
Along with good advice this book also gives an insightful history of UN*X and some suggestions as why it is not "King" of the desktop today, as it should be.
Further into the book there numerious examples of good programming practices; featuring programs that follow the traditional UN*X philosophy of coding. This book also explains the many pitfalls that seem so prevenent programming practices. I say this as an experenced computer user not as programmer. With these observations I hope to become a quality UN*X programmer.
It has been noted in an other review that Mr. Raymond is big into the Linux community. Yes this is true. He is one of Linus Torvalds's right hand men and spokesmen. Mr. Raymond, to his credit, touches very little on the subject of Linux of his known dis-liking of M$ in this book.
This book will forever be in my library of programming books. You will never catch my copy of this book here on Amazon as a used book. (Unless of course I am starving to death or I am already dead and my family is selling off my stuff.) I would like to thank Mr. Raymond for sharing his many years of UN*X expertise. (I would actually like to meet him some day.)
| 
