Download Podcast in Small Lo-Fi format
Closing Music:Calico-The West Exit
Abstract: This is a script for a podcast. In this podcast, the book “Linux and the Unix Philosophy” by Mike Gancarz reviewed.
In this podcast, I will review the book “Linux and the Unix Philosophy” by Mike Gancarz, which was published by Digital Press in 2006, and supersedes his original book “The Unix Philosophy” published by the same company in 1995.
The first thing I suppose one would ask oneself, is if the author is authoritative. Is he credible to be speaking on such a topic? Well, the preface, which was authored by Jon “maddog” Hall, places the author with him and other prominent early BSD developers. The author also discusses some of the programs he has written professionally. Impressively enough, one is a “hack” to make bash scripts totally index large collections of emails. Obviously, something Bash was not ever designed to do.
Another good thing is that the author does not say “this is the Unix philosophy” after producing a dogmatic list. Instead, he breaks things into two sections, the first of which is what he has found through research to be agreed upon in the great majority of books about Unix development. The second section, is a group of tenants less agreed upon. This functional division makes the philosophy of software development expounded upon more acceptable as being “the Unix Philosophy.”
Here are the major and minor points of the philosophy.
Major Points:
Minor Points:
Now, it is not my place to elucidate on each of these points, that would be like reading the book to you. I list them, so that you may get a feel for what the book intends to explore. Armed with that, you can tell if the book would be good for you.
Instead of reading the book to you, I want to mention some of the high points of the book. So please keep in mind that the book explores all these tenants in detail, but I will only be mention some of the big things that stood out for me.
Early on in the book, the author discusses how systems come about in general, and calls this “the Three Systems of Man.” This first is the hasty prototype that gives a proof of concept. The second, is the all-inclusive system designed by a large committees. Thirdly, is the next new system that takes for granted with this system proved. The author gives examples from both software and other conceptual fields to drive his points home as well as showing the pattern and explaining the motivations of people involved at the different points in the process.
The second high point for came later in the book, it was a case study of MH. MH is a text based email system created by the Rand corporation, even though now it is superseded by NMH, for “New Mail Handler.”
Mail Handler is used to show off what can go right when the tenants of the Unix Philosophy are applied. MH is interesting because it adds one or two dozen commands just for handling email to your system.
The first thing about MH is that it uses plain text files and folders for storing email. Ever try to recover a single email from some backup medium? I needed to once, and it was a breeze with MH because each email was a text file in the backup, so I could actually find and email it using regular mount command and less and a file browser. It’s funny, because just over lunch today, I was trying “Mintcast” on for size and one of the hosts was lamenting about Microsoft Outlook at his office. It turns out that Outlook stores it’s emails in a proprietary file called PST or PTN’s or something, and get this, he had a recovery issue. One of his firms lawyers had to recover one email out of a two gigabyte file! This poor guy ended up having to send huge groups of email forwarded through a server so that the lawyer could create separate files and receive forwarded emails and sort them into new smaller files. It absolutely amazes me when people store their data in captive formats, you know, when somebody sends me something in a .doc format, I can open it with open office, but somehow, I am much more apt to just throw it out unless it is a PDF.
The second thing, and you have probably asked yourself this already, is what about GUI? We all love them, even me. I do a lot in an xterm, but I do want a GUI myself. Well, you have an X-based front end for MH is what you do. I used to do exactly this until I found my favorite email program “Claws,” which can just be set to store it’s files in MH compatibility. Thus, I feel safeguarded against future file recovery problems. These front ends are easy to write against MH because it’s program structure of commands doesn’t differentiate between a human invoking a command and a person invoking a command. MH itself comes with a curses-style front end also.
Third thing about the MH example, is that the author gives himself a chance to brag about a programming coup of his, which was a group of bash scripts that indexed already received emails and searched for them as easily as searching a database-based system. Essentially, he managed to pre-grep all the files in the email folders, and then the text file which served as a database had the indexed word followed by file names, which could be extracted - again, either by person or another program- using grep.
You know, when I give you detail like that, I have a motive dear listener. While you can see from the example a further buttressing of the flat file parts of the “Unix Philosophy,” this bangs home two other points about portability and performance. Performance: you may have heard the recommendation that when script’s speed is too slow, that Unixer’s rewrite in C. This example also shows that this step may not be the best way, because you lose portability when you rewrite under C. An interpreted bash script does not need recompiling! To me, some of the best software is written in Perl, there is one Debian package for these things with an architecture called “all.” beautifully simple, and the next big change in computers is less likely to kill a program. The other point on performance is that your slowness will be fixed by next years faster hardware.
The author concludes by looking at the memes behind other operating systems, and critiques them in light of the memes behind UNIX and Linux.
I’d like to end this book review by quoting an ancient book written for Samurai called “The Hagakure,”
It is bad when one thing becomes two. One should not look for anything else in the way of the Samurai. If one understands things in this manner, he should be able to hear about all Ways, and be more and more in accord with his own.