Linux and the Unix Philosophy

limbo_14 writes "Mike Gancarz takes his oft'-quoted original book, The Unix Philosophy and spruces it up for the Brave New World of Linux with Linux and the Unix Philosophy. Since The Unix Philosophy was written, Unix has undergone many changes and evolutions. Now with Linux emerging as the new face of Unix, he has updated his book with the same philosophy and tenets that were in the first, but updated the book to include considerations for the Open Source community and the new world of Operating Systems in which we live." Even the old version of The Unix Philosophy is worth finding; it may remind you of Neil Stephenson's In the Beginning Was the Command Line. Read on for the rest of limbo_14's review. Linux and the Unix Philosophy author Mike Gancarz pages 200 publisher Butterworth-Heinemann rating Recommended reviewer limbo_14 ISBN 1555582737 summary An updated and expanded version of Gancarz's original book, The Unix Philosophy.

The good stuff... I enjoyed Mike Gancarz' first book The Unix Philosophy greatly when I was first getting into the Unix world, and was hoping for an updated version. The thing that makes this book stand out in the shelves full of How-To, Dummy, and Administrator guides is the fact that it covers the What and Why of Unix/Linux rather than the How's. I am constantly amazed at Unix books that are mostly printed man files, and things that can easily be googled. This book explains with great precision why Unix is the way it is, and what separates it from other OS paradigms.

I realized the importance of this book after reading it, and being forced to do interviews for a Unix Engineer at my office. Of the 7 candidates, 6 of them seemed to know the textbook stuff. They knew the commands, they knew vi and a handful of scripting languages to a degree of proficiency. Alas, this is what it takes to become a Unix Administrator, not an Engineer that needs to see the whole picture. In this world of "puppy mill" Unix admins who have certifications and know one or two flavors of Unix/Linux, this book really teaches people the core of why Unix/Linux is the way it is, and why it is so attractive to those who really care about which OS to use.

The last chapter -- "Brave New (Unix) World)" -- is the real kicker. Gancarz really drives it home, and shows how the Unix/Linux philosophy has made it into other aspects of technology, and in the world we live in.

The not-so-good stuff ... With every good book, there must be some bad, although this one's errors are quite forgivable. Although I appreciate any book that loosens the RFC style nature of so many technical books, sometimes it can go a little too far. This, however, is for each reader to judge. Some of the puns made me squirm, but for the most part they added a nice touch of levity to the book. So, depending on your threshold for python-esque puns or corny Elvis jokes, the book may not be for you, but knowing the /. Crowd, I don't think it will cause anything more than some groans and giggles. All in All... This is a quality book. It is one that should be re-read every now and then to make sure you do not stray from the Tenets that Gancarz drives home throughout the book via anecdotal evidence.This book can and should be read by anyone from a newbie hacker to a Corporate CEO. It is just technical enough not to make one feel patronized, and eases you into it with general concepts just enough to make it not feel like reading IETF standards. Here are the chapters, which give a good overview of what each is about:

• Table of Contents
• The Unix Philosophy: A Cast of Thousand
• One Small Step for Humankind
• Rapid Prototyping for Fun and Profit
• The Portability Priority
• Now THAT'S Leverage!
• The Perils of Interactive Programs
• More Unix Philosophy: Ten Lesser Tenets
• Making Unix Do One Thing Well
• Unix and Other Operating System Philosophies
• Through the Glass Darkly: Linux vs. Windows
• A Cathedral? How Bizarre!
• Brave New (Unix) World

Although this is not the cheapest book in the rack, it packs more of a punch than half of the books on my shelf, so I think it is worth it. I found it a great read on the metro on the way to work in the morning, and found myself finishing it well within a week. With 200 pages, and by making it fun to read, Linux and the Unix Philosophy breezes by and makes for a great read.

You can purchase Linux and the Unix Philosophy from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Is the Unix philosophy real?

[GGardner]

I've been using Unix for 20 years, and can write some mean shell scripts. I've read all the original papers which talk about how great it is to have many small tools and little languages which you can hook up via pipes. That sounds great on paper, but I've never really seen it work out in practice.

Sure, we've all writing massively pipeline shell one-liners to do day-to-day tasks, but these are just one-time, throw-away code. All of my real Unix apps that I use every day are huge monolithic applications, not a composition of many tiny apps connected by pipes. My web browser is a monolithic app, not connected by pipes. GCC is a couple of monolithic applications, optionally connected by pipes, but never reconnected in any useful way (cpp notwithstanding). My newsreader and mailreader again, monolithic applications. My MTA, again, a monolithic application. Not one large program I use is a shell script, or collection of small, interchangeable programs.

So, is this Unix tool philosophy useful for real applications, or just for little shell scripts?

When is it Unix and Not Unix?

[peter303]

Avoiding Stallman's pun, what exactly is UNIX? Does Linux qualify? Apple OS X+? Exotic OS's like Mach?

In the mid-1980s an industrial/governemnt consortium tried to defined an unified UNIX API, called Posix. Then it would be straight forward to implement the UNIX utilities, command user interfaces, and apps on top this. I recall some companies layering Posix on top of VMS, MVS, and other non-UNIX kernals. Are these UNIX?

Another approach was extending the UNIX philosophy of a simple machine image to more modern computers than those in the early 1970s. Mach assumed a computer model with multiple CPUs and memory subsystems. BeOS assumed a computer model where multimedia was the norm. So are these OS's "more UNIX-like than UNIX" then?

Lacking -- I have (many) more questions

[dodell]

I found this review to be lacking in content. It doesn't discuss the content of the book to any extent; instead it talks about how it got him a job promotion to UNIX Engineer. How did it do this? What did you learn from the book that gave you such an additional skillset to be promoted to UNIX Engineer? What are the differences between the UNIX Administrator and the UNIX Engineer you are referring to?

I am constantly amazed at Unix books that are mostly printed man files, and things that can easily be googled. This book explains with great precision why Unix is the way it is, and what separates it from other OS paradigms.

I've not found any books that are mostly printed man pages. Nor have I found any circumstances where the man pages don't cover things I need to know. In any case, what parts of UNIX does it explain? Is it explaining Linux or UNIX? What OS "paradigms" are you referring to? You are going by this definition aren't you?

I realized the importance of this book after reading it, and being forced to do interviews for a Unix Engineer at my office.

What importance did you realize this book serving after you had read it? Are you sure this gave you applicable knowledge to separate "UNIX Administrators" from "UNIX Engineers"? What is the difference here?

Although I appreciate any book that loosens the RFC style nature of so many technical books, sometimes it can go a little too far.

Why? If it's discussing that you need to know an RFC to understand why something works the way it does (you've stated that this book talks more about the why than how), how does it make it "not-so-good"?

So, depending on your threshold for python-esque puns or corny Elvis jokes, the book may not be for you...

Do the few puns in the book really take that much of the quality away?

I don't think that this book should be re-read from time to time. I think new editions should be published as UNIX and Linux continue to evolve in their own separate directions (yes, they're going in somewhat separate directions).

Your listing of the TOC didn't give me any idea about what was covered? WTF is "Now THAT'S Leverage" about? What "Lesser Tenants" are being referred to? What "One Thing" does UNIX do well?

You've left me with more questions about this book than I would have had otherwise. Please try to do a more thorough review next time.

And, to get on a technicality that will probably cost me this comment as a Troll, Linux IS NOT THE NEW FACE OF UNIX. Most distributions also don't even come close to being something that would compare to a UNIX certified system.

Finally, please excuse my harshness. I just feel you could have done a better, much more descriptive job. Don't take it personally.

Re:Something I've never been able to figure out.

[Planesdragon]

Why is it then that there are people out there who spend their entire lives with UNIX/Linux, and who ignore this?

Because it's old and out of date. The new ideals should be:

- Stable is beautiful

- Make each program do what it does completely.

Few folks enjoy puny programs that do one thing very well--when they want to do something slightly different, they wind up using a bunch of differenet tools.

Also, the advent of windowing, color, and richly formated files has made "small simple programs" too hard to use. A whole new set of "single-task, fast-running" programs would be nice--but they'd have to be designed from the ground up to (1) work together and (2) work with richly formatted (XHTML) files.

'course, the end-user wouldn't see distinct programs--they'd ideally just see their computer, and do what they want to without ever having to think about tasks, programs, or appellets ever again.

Re:Good For Geeks-In-Training

[alex_ant]

Linux is a good thing because it allows you to be a part of a small clique that is able to feel superior to everyone else by virtue of your fiddling about with a system that was designed by the programmer, for the programmer rather than by the programmer for the user (Windows) or by the user for the user (Apple). The fact that non-geeks find it very difficult to e.g. burn a CD using the Linux command line is a great source of pride to dejected geeks everywhere who reason that, if they can't be accepted by mainstream society (due to their obvious massive intelligence of course, not their shocking lack of social skills), they can at least construct their own alternate reality in which they are of superior intelligence (even if that "intelligence" translates into nothing more than the ability to control a computer using cryptic textual commands).

Re:Something I've never been able to figure out.

[imhotep1]

There are tradeoffs to using the make each program do one thing vs. make each program do everything technique.

I am currently working on a small web content management CGI in C, based on the "small is beautiful / Make each program do one thing," paradigm. It is made of several smaller programs, each does one thing (one part is the CGI, and recieves the request and returns the output, one part is an XSLT transform engine, one part is a cacheing engine that will cache the XSLT output and only rerun the XSL transform if the source file has changed, and so on and so fourth)

I am mostly doing this for self education, but I have noticed that along with the several advantages to my approach (flexibility in application and extensibility,) there are significant drawbacks.

There is processor overhead to loading each program, and while on a server with few hits this will not be an issue, I am positive that my little CMS will pale in comparison to something like MOD_PERL + some random CMS under Apache. Mine is smaller, simpler, more Unix-like, but not nessecarily better.

I think the Unix ideals are good design technique, and should be kept in mind when designing any project, but a systems designer needs to be prepared to drop them if they impede in the performace of the final application.

Think of programs like cars. Formula one race cars are horribly designed taxis. They also absolutly CANNOT handle going off road. Tis doesn't mean they are poorly designed.

Re:Interesting perspective, but wondering....

[crazyphilman]

In terms of flat files, XML is a great idea. It makes parsing easy, it aids readability, and it can be matched with stylesheets when you want a nice-looking printout of your data. I wouldn't use anything BUT XML for flat files... :)