Section 1.12. The Linux and UNIX Philosophy

[Page 12 (continued)]

1.12. The Linux and UNIX Philosophy

So what is Linux? Let's be clear, Linux is not UNIX. It shares no code with UNIX. But because both operating systems adhere to the same POSIX standard, they look and act almost alike, so for most people, the fact that they are not the same thing is only a technicality. But it is an extremely important technicality!

Linux is a complete reimplementation. Because it shares no common code with any version of UNIX, it does not connect into the UNIX "family tree." Even so, Linux has strong philosophical connections and design influences derived from virtually all versions of UNIX. When one talks about the philosophy of Linux and GNU utilities, it is truly to talk about the UNIX philosophy.

The original UNIX system was lean and mean. It had a very small number of utilities and virtually no network or security functionality. The original designers of UNIX had some pretty strong notions about how utilities should be written: a program should do one thing, do it well, and complex tasks should be performed by using these utilities together. To this end, they built a special mechanism called a "pipe" into the heart of UNIX to support their vision. A pipe allows a user to specify that the output of one process is to be used as the input to another process. Two or more processes may be connected in this fashion, resulting in a "pipeline" of data flowing from the first process through to the last (Figure 1-4).

Figure 1-4. A pipeline.

The nice thing about pipelines is that many problems can be solved by such an arrangement of processes. Each process in the pipeline performs a set of operations upon the data and then passes the results on to the next process for further processing. For example, imagine that you wish to obtain a sorted list of all the users on the system. There is a utility called who that outputs an unsorted list of the users, and another utility called sort that outputs a sorted version of its input. These two utilities may be connected together with a pipe so that the output from who passes directly into sort, resulting in a sorted list of users (Figure 1-5).

---

[Page 13]

Figure 1-5. A pipeline that sorts.

This is a more powerful approach to solving problems than writing a fresh program from scratch every time or using two programs but having to store the intermediate data in a temporary file in order for the next program to have access to it.

The UNIX (and therefore Linux) philosophy for solving problems can thus be stated:

• If you can solve the problem by combining multiple existing utilities using pipes, do it; otherwise

• ... ask people on the network if they know how to solve it. If they do, great; otherwise

• ... if you could solve the problem with the aid of some other hand-written utilities, write the utilities yourself and add them into the repertoire. Design each utility to do one thing well and one thing only, so that each may be reused to solve other problems.

  If more utilities won't do the trick

• ... write a program to solve the problem (typically in C, C++, or Java).

Inside Linux is hidden another more subtle philosophy that is slowly eroding. The original system was designed by programmers who liked to have the power to access data or code anywhere in the system, regardless of who owned it. To support this capability, they built the concept of a "super-user" into UNIX, which meant that certain privileged individuals could have special access rights. For example, the system administrator of a UNIX system always has the capability of becoming a super-user so that he/she may perform cleanup tasks such as terminating rogue processes or removing unwanted users from the system. The concept of super-user has security implications that are a little frightening. Anyone with the right password could potentially wipe out an entire system, or extract top-security data with relative ease.