Unix philosophy

from Wikipedia, the free encyclopedia

The Unix philosophy is a set of rules and approaches to software based on the experience of leading Unix programmers.

McIlroy: A Quarter Century of Unix

Douglas McIlroy , the inventor of the Unix pipes , summarized the philosophy as follows:

  • Write computer programs so that they only do one task and do it well.
  • Write programs that work together.
  • Write programs to handle streams of text, because that's a universal interface.

Usually this is shortened to, "Only do one thing and do it well."

Of these three theorems, the first two in particular are not limited to Unix, but Unix programmers emphasize all three theorems more than other programmers.

Pike: Notes on Programming in C

Rob Pike suggests the following rules as principles of programming, but they can also be seen as core ideas of the Unix philosophy:

  • Rule 1: You cannot say which part of the program will eat up the main part of the performance. Since bottlenecks often appear in surprising places, you shouldn't add anything to increase speed until you have shown where the bottleneck is.
  • Rule 2: Measure the program duration. Only hone the speed when you have measured it and even then only when the part you are looking at is consuming a dominant portion of the computing time.
  • Rule 3: Sophisticated algorithms are slow when the amount of input data (see complexity theory ) is small and that is the normal case. Sophisticated algorithms have high fixed costs. As long as you do not know that the values ​​will often be high, you should avoid sophisticated algorithms. (And even if it gets big, rule 2 applies first)
  • Rule 4: Sophisticated algorithms are more error-prone than simple ones and much more difficult to implement. Use both simple algorithms and simple data structures.
  • Rule 5: data is more important. If you've chosen the right data structures and everything is well designed, the algorithms will almost always work out on their own. Data structures are the central topic of programming, not algorithms.
  • Rule 6: There is no rule 6.

Rules 1 and 2 repeat the famous principle of Donald E. Knuth : "Optimizing too early is the root of all evil." Ken Thompson formulated rules 3 and 4 as "When in doubt, use brute force"; these rules are examples of the KISS principle . Rule 5 is from Fred Brooks , who mentioned it in The Myth of the Man Month , and is often phrased as "Write stupid code that uses clever data." Rule 6 is borrowed from the sketch by Bruces from Monty Python's Flying Circus (episode 22).

Mike Gancarz: The UNIX Philosophy

In 1994, Mike Gancarz (he was one of the developers of the X Window System ) published his experiences with Unix in the form of the book The Unix Philosophy , which is also based on anecdotes from discussions with colleagues and with people from other areas who were themselves dependent on Unix . Nine main demands are named:

  1. Small is beautiful.
  2. Design each program to do a task well.
  3. Create a working prototype as soon as possible.
  4. Prefer portability over efficiency.
  5. Save data in simple text files.
  6. Use the leverage of the software to your advantage.
  7. Use shell scripts to improve leverage and portability.
  8. Avoid user interfaces that captivate the user.
  9. Make every program a filter.

The following ten less stringent requirements are not generally accepted as part of the Unix philosophy and have led to heated debates (for example, whether a monolithic kernel or a microkernel should be preferred):

  1. Let the user set the environment according to their needs.
  2. Make operating system cores small and lightweight.
  3. Write lowercase and keep command names short.
  4. Spare trees .
  5. Silence is golden.
  6. Think in parallel.
  7. The sum of the parts is more than the whole.
  8. Find the 90/10 solution .
  9. Worse is better.
  10. Think hierarchically.

Worse is better

Richard P. Gabriel claims a fundamental benefit of Unix comes from a design philosophy that he calls worse is better . According to this philosophy, the simplicity of both the user interface and the implementation in the program is much more important than any other property of the system - including properties such as freedom from errors, consistency and completeness. Gabriel argues that this approach offers fundamental advantages in the further development of the software, but he also doubts the quality of the programs in some implementation of this approach.

For example, the first Unix systems had a purely monolithic kernel; User processes that made kernel function calls used the user stack for them. If a signal was to be sent to a process while it was blocked by a long kernel function call, the signal handler could not be executed - because there may be critical data for the kernel on the stack. What should be done One possibility would be to wait until the kernel call has finished with the signal - but this can take a long time, sometimes too long. Another possibility would be to buffer the kernel call, provided that everything goes smoothly with the signal handler, so that it can be continued later.

In such cases, Ken Thompson and Dennis Ritchie preferred simplicity to perfection. If such a case occurs, the kernel terminates the function call with an error message stating that the function call was not executed (this is the interrupted system call with the error number 4 = EINTR ; this interruption came of course from the signal handler). This only happens with a handful of long-running system calls such as B. read (), write (), open (), select () etc. This procedure has the advantage that it makes the I / O system much simpler (since special cases do not have to be taken into account). Most programs don't mind, because they don't use any signals anyway or they terminate on a SIGINT. The few programs that use signals can react to this problem by surrounding the kernel function calls with a wrapper that repeats the call when an EINTR occurs. This solves the problem in a simple way.

For these reasons, Unix was the operating system that crashed the most frequently (several times a day) in its early days, but also had the fastest restart. Because of its simplicity, Unix became the most stable system within ten years, with error-free runtimes in the range of months and years instead of hours.

Raymond: The Art of Unix Programming

In his book The Art of Unix Programming, Eric S. Raymond summarizes the Unix philosophy with the well-known engineering wisdom Keep it Simple, Stupid ( KISS ). He then describes how, in his opinion, this basic attitude is implemented in the practice of Unix culture (although in practice these rules are of course violated very clearly from time to time):

  • Rule of modularity : Write simple components that are connected by clean interfaces.
  • Rule of Clarity: Clarity is better than cunning.
  • Rule of Assembly : Design programs so that they can be linked to other programs.
  • Rule of separation: Separate the basic idea from the implementation, separate the interfaces from the processing logic.
  • Rule of Simplicity: Design with the aim of simplicity; only add complexity if absolutely necessary.
  • Rule of thrift: Only write a large program if it can be clearly shown that there is no other way.
  • Rule of Transparency: Design with the aim of transparency to make troubleshooting easier.
  • Rule of Robustness: Robustness is the child of transparency and simplicity.
  • Rule of representation: Put the knowledge in the data structures so that the program logic can be stupid and robust.
  • Rule of least surprises : When designing the interfaces, always do the closest thing that causes the fewest surprises for the user.
  • Rule of silence: If a program has nothing surprising to say, it should be silent.
  • Rule of Fixing: If the program fails, do it loudly and as early as possible.
  • Rule of Economy: Programmers work time is expensive; save them at the expense of computing time.
  • Code generation rule: Avoid manual labor; write programs that write programs if possible.
  • Rule of optimization: create prototypes before you start fine-tuning. Make it work before you tweak it.
  • Rule of versatility: distrust all claims to "the only true path".
  • Rule of extensibility: Design for the future, because it will come faster than you think.

Many of these standards are recognized outside of the Unix community - if they weren't first used on Unix, they were soon adopted. Even so, Unix experts consider a combination of these rules to be the basis of the Unix style.

Role of the operating system

The above statements describe the properties of programs that make Unix what it is. Another aspect of the Unix philosophy also affects the operating system itself: so that programs can be kept as simple, clear and modular as possible, so that they can work well together and so that they can be easily portable, the operating system must meet the appropriate requirements in the form of clear interfaces and create high abstraction. In practice:

Everything is a file

  • The access to both local drives as well as network drives via the same directory structure ; there are no different drives, everything are directories and files in the same tree structure.
  • Virtual drives can also be implemented without any problems, because they also only appear as a directory. Each image file at any location can be integrated into the directory tree at any point by mounting .
  • Devices are also accessed via the file system. A device driver is a special file in the directory / dev assigned; by reading and writing this file, a program can communicate with the device driver.
  • Kernel data can also be accessed through the directory structure, namely the / proc directory .

Client-server model

Communication always takes place via network connections. The internal communication between client programs and daemons , for example , is also carried out via network interfaces, so that programming is uniform and the programs can also be used optionally via the network.

For this reason, Unix does not have a specialized programming interface for every area of ​​application , but comparatively exotic applications are mapped to files or network connections.

Quotes

  • “Unix is ​​easy. It only takes a genius to understand its simplicity. ”( Dennis Ritchie )
  • "Unix was not designed to prevent its users from doing stupid things, because that would also prevent them from doing clever things." ( Doug Gwyn )
  • "Unix never says 'please'." ( Rob Pike )

See also

Web links

swell

Individual evidence

  1. ↑ Notes on Programming in C
  2. ↑ See for example Allen I. Holub: Enough Rope to Shoot Yourself in the Foot: Rules for C and C ++ Programming . McGraw-Hill 1995.