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.
The book is not about business philosophy, it is about the OS itself: the paradigm that Unix/Linux was designed around.
Unix started as a way to run a non-vender-supported OS on cheap PDP-11s. Unix eventually became highly commercialized and proprietized, but it started life as a hobbyist project (of sorts).
Ita erat quando hic adveni.
This review basically consisted of one paragraph describing the book and a table of contents. I didn't get a real good feel of what to expect from the book. Why is it like In The Beginning?
I guess I was hoping for a little more detail about why this book is good other than "it's not man pages or RFCs."
Mike Gancarz's book The UNIX Philosophy (Digital Press, 1995) describes many of the ideas and conventions that have made unix a great sytem. It starts with a short run down of the history, quickly getting to the meat of things, discussion of the major ideas of Unixdom and illustrations of why they are such good ideas. While many of the ideas may seem relatively obvious to anyone who's worked with the system before, it makes an excellent introduction to the traditions of the Unix world, as well as an excelent bit of advocacy for why the Unix way is the Right Way.
...and the ten lesser points:
Listed in the first chapter, the following nine points are the key tenets:
Small is beautiful
Make each program do one thing
Build a prototype as soon as possible
Choose portability over efficiency
Store numerical data in flat ASCII files
Use software leverage to your advantage
Use shell scripts to increase leverage and portability
Avoid captive user interfaces
Make every program a filter
Allow the user to tailor the environment:
Make operating system kernels small and lightweight:
Use lower case and keep it short
Save trees
Silence is golden
Think parallel
The sum of the parts is greater than the whole
Look for the 90 percent solution
Worse is better
Think hierarchiacally
Perhaps you have heard of BSD Unix...?
Does IPC count as a pipe? Do you run any filters on your email? How many times have you run | grep (granted that this is a one time thing)? I have a good number of shell scripts I use (for sed scripts, for instance) that make use of pipes (not extensively though). I'd suggest that pipes are used much more than you give credit for here.
www.sitetronics.com/wordpress
Thought i'd let you know ...
B0mbtruck, one base at a time
That is [the] point of the Unix philosophy.
Sort of. The "UNIX philosophy" has some very good elements in it--but it's not without its flaws.
The biggest one, IMO, is getting a tool changed and automating multiple computer tasks to one human-task.
And if you need some functionality that the tools can't provide, you don't need to install a 100% beginning-to-end solution complete with duplicate functionality and learning curve, you install a new small, specialized tool (i.e. gphoto2 to fetch photos from a camera) to solve the 1% of the problem that needed a new tool and use the tools you already know and have for the other 99% of the problem.
Depends on the problem, what what your current state of learning is. (Don't toss around statistics that you don't have--we have perfectly good words for "majority" and "minority")
As I said, the problem is the advent of the GUI and the commonality of richly formatted documents--two major elements of modern computer usage that weren't really dealt with when the orignal UNIX system was created. For some modern applications, such as working with pictures, small apps added to the old apps can work. For other applications, such as 3D design, the current suite of small apps don't work.
Some people argue (as you have) that these come at the expense of ease of use, but that is only true for small (admittedly often consumer-oriented) problems.
A minority ("1%") of computers are used to solve problems. Most computers in service today are used to replace pen & paper, communicate, or play games. And most of these computers are used in a GUI environment, never (or almost-never) using the command line.
I would love to see a removal of the division between "command line" and "GUI", just as I would love to see a removal of the user-distinction between "programs" and "tasks" et al.
Ahh, then, you really should read the book.
There really is a philosophy to Unix and Linux,
and you'll find that when the same philosophy's
applied to things other than OS design, it
results in some interesting and elegant ideas.
This book describes the philosophies embodied in
Unix (and largely copied and expanded upon by
Linux) very well, and in such a way as to not
be religious about it. However, it may give
"non-believers" some understanding of how
Unix and Linux folks think, and therefore a
better sense of why the OSs are the way they are,
and hopefully, a respect for them.
So philosophy, ya, I think so. When applied to
OS design, perhaps you can call them design
principles, but I think that this book is able
to abstract it better than that.
That's NOT what he's talking about.
The "Unix Philosophy" is the philosophy behind Unix-like O/S'es LIKE LINUX. It's a design philosophy, NOT a marketing one, or even an economic one. Vastly oversimplifying,
1. Don't create huge monolithic programs if you can help it. Create small, elegant programs that each do one specific thing well. Use a scripting language to pipe them together, amplifying their usefulness.
2. Because you want to be able to pipe small programs together to aggregate their usefulness, avoid "captive user interfaces", i.e. interactivity. Lean towards writing software that is comfortable running in batch, on a pipe, in a script. Use command line arguments.
3. Don't reinvent the wheel. If there's already a tool that does what you want to do, use it. If you need to extend its functionality, script it with another tool or tools.
4. Lean towards command line programming, because then everything you've got can be scripted, run in crontab, run in batch, etc. The command line is your friend.
5. Everything is a file. This lets you interact with hardware directly, in your software.
6. Store data as flat text whenever possible, so that down the road, if you want to use it with another program, you'll be able to. This also lets you sift through your data using grep and awk.
7. Use text streams whenever you can, for similar reasons to #6. Got a socket? Pass flat text, not binary. Unless you really MUST pass binary.
I've probably left a whole lot out, but this is the basic gist of it. It's why Linux, Unix, and the *BSDs are so much more useful than Windows.
Farewell! It's been a fine buncha years!
The text for Neal Stephenson's book "In the Beginning..." can be downloaded here. Haven't read it yet, but when did that stop anyone here :-)