Unix Philosophy

The Unix Philosophy is a set of OS design principles first conceived by Unix architect Ken Thompson, based on the experiences of the Unix development team. The Unix Philosophy emphasizes the importance of single-purpose applications written with simple & reusable code, so that it can be easily maintained and repurposed by developers other than its creators.

As Unix evolved, the development staff and the Unix Philosophy evolved with it. In the Jul-Aug 1978 Issue of Bell System Technical Journal, Unix dev Douglas McIlroy gave the following outline:

1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

Because of this set of ideals that drove Unix development, Unix became incredibly popular amongst academic professionals, hobbyists and developers - all of whom were frustrated by the propriety & monolithic software platforms that were in common use at the time.

While Unix has largely been superceded by its descendants such as Linux and BSD, its influence has been elephantine. The Unix Philosophy still informs the decisions made by many influential developers & the open-source community to this very day. For AnonOps engineers, this means you will have to embrace this ideology if you want to be able to make the most efficient use of this software ecosystem.

The 1974 essay The UNIX Time-Sharing System by Thompson and fellow Unix dev Dennis Ritchie identifies the following tactical side-effect of this philosophy:

It is worth noting that the system is totally self-supporting. All UNIX software is maintained under UNIX; likewise, UNIX documents are generated and formatted by the UNIX editor and text formatting program.

Unix ((like Linux & BSD after it) is its own development environment and support structure. You don't need fancy third-party IDE's or hardware development kits to debug, modify or expand the system, because it's all part of the operating system or its stock package managers.

In The Unix Programming Environment by Bell Labs veterans Brian Kernighan and Rob Pike, they explained how this DIY mentality appealed to programmers and professors:

Why did it become so popular in the first place? The central factor is that it was designed and built by a small number (two) of exceptionally talented people, whose sole purpose was to create an environment that would be convenient for program development, and who had the freedom to pursue that ideal. Free of market pressure, the early systems were small enough to be understood by a single person.

The Unix Philosophy isn't a strict set of coded rules, but rather a flexible set of guidelines & ideals. It is best summarized by programmer Eric S. Raymond in his book The Art of Unix Programming:

The ‘Unix philosophy’ originated with Ken Thompson's early meditations on how to design a small but capable operating system with a clean service interface. It grew as the Unix culture learned things about how to get maximum leverage out of Thompson's design. It absorbed lessons from many sources along the way.

The Unix philosophy is not a formal design method. It wasn't handed down from the high fastnesses of theoretical computer science as a way to produce theoretically perfect software. Nor is it that perennial executive's mirage, some way to magically extract innovative but reliable software on too short a deadline from unmotivated, badly managed, and underpaid programmers.

The Unix philosophy (like successful folk traditions in other engineering disciplines) is bottom-up, not top-down. It is pragmatic and grounded in experience. It is not to be found in official methods and standards, but rather in the implicit half-reflexive knowledge, the expertise that the Unix culture transmits. It encourages a sense of proportion and skepticism — and shows both by having a sense of (often subversive) humor.