The Unix Philosophy

The Unix Philosophy
 Author: David Calvert

---

---

The UNIX Philosophy

From The UNIX Philosophy by Mike Gancarz. Operating systems embody the philosophy of their creators.

• Mac/OS is visually based with all options presented to the user
• DOS attempts to create ``a taste of the mainframe''
• DEC VMS assumes users fear the machine and should be given a few powerful choices

The creators of Unix assumed that its users would be computer literate. Little effort was placed into making it accessible to novices. ``If you can't understand it, then you don't belong here.''

A Little History

Ken Thompson wrote the first Unix at Bell Labs in 1969. It ran on a DEC PDP-7 and was based upon Multics, one of the first time sharing (non-batch) operating systems. In 1972 he rewrote it in a portable language called B which was later modified by Dennis Ritchie to become C in 1973.

The UNIX Philosophy

The philosophy is a result of more than twenty years of software development and has grown from the UNIX community instead of being enforced upon it. It is a defacto-style of software development. The nine major tenets of the UNIX Philosophy are:

1. small is beautiful
2. make each program do one thing well
3. build a prototype as soon as possible
4. choose portability over efficiency
5. store numerical data in flat files
6. use software leverage to your advantage
7. use shell scripts to increase leverage and portability
8. avoid captive user interfaces
9. make every program a filter

The Ten Lesser Tenets

1. allow the user to tailor the environment
2. make operating system kernels small and lightweight
3. use lower case and keep it short
4. save trees
5. silence is golden
6. think parallel
7. the sum of the parts if greater than the whole
8. look for the ninety percent solution
9. worse is better
10. think hierarchically

Small is Beautiful

If you are writing a program, start small and keep it small. Strive for simplicity and keep the system components as small as possible. Small programs may not do very much themselves, but become quite powerful when combined with each other.

In most traditional software a large portion of the code is devoted to something other than the task which that program is intended. This can lead to greater complexity.

Example: A copy command can easily perform twelve different tasks, only one of which is copying a file.

Small Programs are Easy to Understand

Small programmes contain only a few algorithms and keep the focus on a single problem. Larger programs tend towards complexity and are difficult to understand. The sheer size of the program can make it unmanageable for the programmer.

Small Programs are Easy to Maintain

Ease of understanding translates to easier maintenance.

Small Programs Consume Fewer System Resources

Less memory is required to run, less time is required to load, and less disk space is needed to store small programs.

Small Programs are Easier to Combine with Other Tools

Monolithic programs are assumed to contain all of the features necessary for an application. This mistakenly assumes that the future of the software isn't going to be much different from today. The idea behind focused programs is that when new trends develop, new small programs can be built to take advantage of them.

Make Each Program Do One Thing Well

This compliments the tenet of smallness. Focusing on a single task helps the developer to avoid being caught-up in details which are unrelated to the programs primary function. Tasks like input and output formatting can be performed in other programs which are developed for such tasks.

Build a Prototype as Soon as Possible

This tenet developed because it is extremely difficult to predict the results of a software development project without first developing the software.

This idea runs counter to many software engineering methods which state that a majority of the design must be completed before any code is written. It is really an extreme form of prototyping and is intended to aid in the development of the final system. Prototyping is used to learn about the system and to reduce the risk of major problems in the final system.

Three Systems

Software systems tend to have three stages in their life. The UNIX Philosophy assumes that this must be the case and suggests that an iterative design method is therefore essential.

The First System is built:

• with the developers back against the wall (some constraint, usually time, forces the developer to try something drastic)
• when there is no time to ``do it right''
• usually by a single person or at most a small group
• and is a lean, mean, computing machine.

The first system usually contains a concept which is innovative and attracts the attention of other developers.

The second system is built when the first system has been seen as something good. The Second System is:

• built by ``experts'' using ideas proven in the first system
• designed by committee
• fat and slow
• gains a great deal of commercial acclaim

Despite their shortcomings, second systems usually have enough momentum to keep other contenders for the market from succeeding. The third system appears after people become disenchanted with their second system.

The Third System is:

• often built by people who have been ``burned'' by the second system
• often given a name change to disassociate it with the original obsolete technology
• still contains the original concept intact and is regarded as commonplace

The third system combines the best characteristics of the first and second systems. Its developers are given the time to properly develop the system.

Choose Portability over Efficiency

Software which is written specifically for one architecture is limited in its marketability and is usually quite difficult to port.

• Next year's hardware will run faster -- performance may not be an issue in a short amount of time.
• Don't spend too much time making programs run faster -- tuning a program is expensive and the gains are often not worth the time.
• The most efficient way is rarely portable -- programs tied to hardware are rarely portable. Hardware which is state-of-the-art when you create a program will soon be outdated and the worth of the program will drop quickly. It is better to have drivers for hardware which take advantage of advanced features but which also provide a consistent/stable programming interface.
• Portable software reduces the need for user training.
• Good programs will be imitated by others if you cannot port them.

Store Numerical Data in Flat ASCII Files

All numerical data should be stored as ASCII text. No special file formats should be used. Data should appear as stream of bytes separated by newline characters.

• ASCII text is a common interchange format -- it is not the best or most efficient, but it is the most likely to be understood on a variety of machine. Data which cannot be readily moved to another machine has limited value, and the act of converting data can be very expensive in time and money.
• ASCII is easily read and edited -- specialized tools to manipulate the data are not required.
• There already exists a wide array of text manipulation tools -- awk, cut, diff, grep, head, lex, more, perl, sed, sort, tail, test, wc.

Use Software Leverage to Your Advantage

Only so much can be done by one individual or group and a great deal has already been done.

• Good programmers write good code; great programmers ``borrow'' good code -- incorporating other people's modules and programs into your project has several advantages. It frees large amounts of development time, the obtained code is tested and debugged by the author, and it makes you look efficient.
• Avoid the not-invented-here syndrome -- there is no reason to reconstruct software which already exists. Most common applications are now standardized and produced by companies which specialize in their production.
• Allow other people to use your code to leverage their work -- the most successful software is the one which appears on the most computers. Proprietary software is usually more difficult to integrate into a system and if your product is too much trouble to use then competitors will develop a better version.
• Automate everything -- simply put, take advantage of the computing environment to do as much work for you as possible. Learn the shortcuts which the shell and many commands provide.

Use Shell Scripts to Increase Leverage and Portability

• Shell Scripts provide great amounts of leverage -- they provide you with the ability to use many previously developed and tested programs with little effort.
• Scripts save development time -- they are interpreted which eliminates compile time. However, they do not have a very good debugging system for scripts which can lead to time wasted searching for a problem.
• Scripts are more portable than 3GLs -- and will likely work on any machine with little to no modification.
• Resist the urge to rewrite shell scripts in a compiled language -- the components used by the shell have been developed by smart people and are probably more efficient than the ones you will write.

Avoid Captive User Interfaces

The problem with many small programs is that it is difficult to learn about them all and users become confused. In order to make them more easy to use developers often bind them together through a single interface. Captive User Interfaces (CUIs) prevent users from interacting with the system once the have started the application.

• CUIs assume the user is human -- they do not allow the program to be run in a non-interactive mode which can be very inefficient for large throughput systems. Similarly, they cannot be combined with other programs easily.
• CUIs and big and difficult to write -- they often require large amounts of system resources, and are very complex.
• CUIs don't scale well -- limitations are usually placed upon the operations which a CUI will allow you to perform to make the system easier to use. When too many instances of an operation must be repeated the interaction with the interface becomes a burden.

Make Every Program A Filter

Every program is a filter in the sense that it produces an output given an input. If the action of filtering is so common then it makes sense to build software which takes advantage of it.

If programmes are capable of producing output given a stream of input then they have the added flexibility of being used in non-interactive systems.

The Lesser Tenets

Allow the user to tailor the environment -- allows the user to build an environment they are comfortable with. The drawback is the imposing amount of knowledge required to learn about the environment.

Make operating system kernels small and lightweight -- keeping the kernel devoted to the basic system services makes the system robust. Added features do not have the ability to halt the system if they are not working correctly.

Use lower case and keep it short -- lower case provides more visual cues to the reader which makes it easier to read and correspondingly less stressful.

Save trees -- data which is in a form that cannot be manipulated is near useless. Keeping data online allows for more processing to be done with it.

Silence is golden -- Unix provides ``just the facts'' when executing a program and does not address the user in a conversational tone. If a program says nothing (ls on an empty directory) then it means there is nothing.

Think parallel -- the CPU is seldomly busy for long and should be kept busy with parallel tasks whenever possible.

The sum of the parts is greater than the whole -- many small components can be combined to produce a greater program.

Look for the ninety percent solution -- it is easier to solve most problems by ignoring the most difficult ten percent. If operations in a program are costly and will be used by few people it is better to drop them from the project.

Worse is better -- the niche which Unix occupied was never on the ``industrial strength'' systems of the world. It grew to fill the low end minicomputer and later workstation market.

Think hierarchically -- the method of ordering items from a more general description to a very specific one is a powerful way to arrange things.