The Unix Philosophy
Author: Mike Gancarz
Publisher: Digital Press
Reviewer: Belinda Frazier, email@example.com
I was first drawn to this book by the title and by the following in the introduction: “The creators of the Unix operating system started with a radical concept: They assumed that the users of their software would be computer literate from the start.” Of course, it is just this assumption that helped keep Unix from being used very much outside the technical, university, computer-literate environment for many years. This book satisfactorily explains how and why the Unix operating system developed as it has; compelling arguments explain why the Unix philosophy allows for good software design and why, in the author's opinion, Unix will become the world's operating system.
The book is geared mostly toward readers who haven't yet used Unix, but the author also intended that experienced Unix programmers would reread it several times so as not to forget the nine main tenets of the Unix Philosophy, as well as the less stringently “enforced” minor tenets. (I think enforcement is accomplished by “true” Unix programmers looking down their noses at those who go astray from the true Unix philosophy.)
The book credits Stephen Bourne, William Joy, Brian Kernighan, and Dennis Ritchie, among the many people who contributed to the Unix Philosophy, each by giving some major contribution to Unix in the early days. For example, William Joy brought text editing and C-like command language (he developed vi and the C-shell); Dennis Ritchie brought us the C programming language.
The main tenets (each of which have sub-tenets) of the Unix philosophy are as follows:
Small is beautiful.
Make each program do one thing well.
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.
The author introduces each tenet with a simple, real-world example (or “case study”) , then further explains why the tenet is important by including non-technical computer-world examples.
Tenet 1. Small is beautiful.The book offers an example of how Volkswagen ran an ad campaign with the phrase “small is beautiful” in the US to promote the VW bug, but the idea was generally ignored in the US until the price of oil went up and Americans learned the advantages of small cars. The author draws an analogy to these nouveau small-car-appreciators to programmers at AT&T Bell Labs discovering that small programs were also easier to handle, maintain, and adapt than large programs.
In a non-Unix environment, a program to copy one file to another file might include, as in an example given in the book, twelve steps which do more than perform a file copy. The twelve steps perform extra tasks, some of which are considered “safety features” by some. The steps might include checking to see if the file exists, if the output files are empty, and prompting users to see if they know what they're doing (for example, “Are you really really sure you want to do this, and does your mother know you're doing this?”), etc. Just one step of the sequence might be the actual copy command. A Unix program (or command) would only include the one copy command step. Other small programs would each do the other 11 steps and could be used together if the Unix user wanted to use these extra steps. Although the author purposefully steers away from giving Unix examples until near the end of the book, I would have liked to see several Unix commands strung together to accomplish all the tasks described by the twelve steps.
Tenet 4. Choose portability over efficiency.The example given here is of the Atari 2600 which was the first successful home video game. Most of the code for the game cartridges was very efficient but nonportable. With the advent of new hardware (the “5200”), the code had to be rewritten to run on the 5200 which took time and money. The author proposes that Atari would have been the largest supplier of software in the world if its code had been portable.
There is a three-page analogy of selling Tupperware to the “use software leverage to your advantage” tenet. Who would have realized a multilevel marketing scheme is a good way to write software?
A sub-tenet of the leverage tenet is allow other people to use your code to leverage their own work. Many programmers hoard their source code. The author states that “Unix owes much of its success to the fact that its developers saw no particular need to retain strong control of its source code.” Unix source code was originally fairly inexpensive compared to the cost of developing a new operating system, and companies started choosing Unix as the platform to build their software on. Companies who chose Unix spent their effort and money on developing their applications, rather than on maintaining and developing an operating system.
There were a few too many pages in this book attempting to reach the stubborn Unix-haters, for example trying to soothe the ego of the programmer who measures him/herself by the number of pages to their large programs. I was slightly put off the book by the psychological explanations of how programmers might behave until I realized these were gentle nudges—and Unix-aficionados are not known for gentleness in talking about other operating systems—that might actually get through to even a lifetime-Brand X operating system user.
I'd strongly recommend this book for people from all operating system environments.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide