Slashdot Mirror
Linux and 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.
SCO has determined that this book has violated it intellectual property. While you can buy the book, you require an additional SCO license to read the book. That'll be $699.
Some of the major tenets of the original UNIX philosophy were:
- Small is beautiful.
- Make each program do one thing well.
Why is it then that there are people out there who spend their entire lives with UNIX/Linux, and who ignore this?
Some of the best examples are sendmail and emacs. And no, this isn't a troll. But I just don't understand why such people just don't get it. Clearly it isn't a lack of intelligence.
But this paradox is something which I've never been able to figure out.
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?
Small is beautiful
...and the ten lesser points:
All program names 4 chars please
Make each program do one thing
But provide for it to do that thing in 52 different ways.
Build a prototype as soon as possible
And then stop.
Choose portability over efficiency
Remember that you are only interested in porting to other Unix systems.
Store numerical data in flat ASCII files
So much for small being beautiful
Use software leverage to your advantage
Err, whatever.
Use shell scripts to increase leverage and portability
While simultaneously decreasing maintainability!
Avoid captive user interfaces
Preferably by not having any user interfaces.
Make every program a filter
Especially the 'shutdown' command.
Allow the user to tailor the environment:
Sure saves you having to figure out what works.
Make operating system kernels small and lightweight:
But keep them monolithic, Linus!
Use lower case and keep it short
Keep those commands under 5 characters!
Save trees
And don't bother with manuals!
Silence is golden
Don't waste time with error output. Or other human beings.
Think parallel
Yeah, don't chain those commands together with pipes, run them all at once. Oh, hang on...
Look for the 90 percent solution
And then quit your job. Heh, let the next guy finish it.
Worse is better
0 is 1, too.
-----