Misconceptions about the UNIX Philosophy
Posixcafe Who's asking
Misconceptions about the UNIX Philosophy
I recently had a discussion with a friend of mine about some talking points that Jonathan Blow made regarding the "UNIX Philosophy" during his interview on Oxide's On The Metal podcast. I'll place an excerpt of the provided transcript here. (slightly edited since there were some errors in the transcript compared to what I heard Jonathan say)
Jonathan<br>I'm going to throw out another stone that will get people mad at me,<br>but so in terms of all this complexity that needs to be collapsed,<br>I think everything has its time. The thing–
Bryan<br>God, what's next? Where are you going after that?
Jonathan<br>Well, the Unix philosophy for example it has been inherited by<br>Windows to some degree even though it's a different operating system,<br>right? The Unix philosophy of you have all these small programs that you<br>put together in two like ways, I think is wrong. It's wrong for today and<br>it was also picked up by plan nine as well and so-
Bryan<br>It's micro services, micro services are an expression of Unix philosophy,<br>so the Unix philosophy, I've got a complicated relationship with Unix philosophy. Jess,<br>I imagine you do too, where it's like, I love it, I love a pipeline, I love it when I want to<br>do something that is ad hoc, that is not designed to be permanent because it allows me– and you<br>were getting inside this earlier about Rust for video games and why maybe it's not a fit in terms<br>of that ability to prototype quickly, Unix philosophy great for ad hoc prototyping.
There is this idea that to be UNIX means you have multiple tiny programs talking to each other over pipes, and some even take it further to implicate that this communication must be plain text. This classification is a deep misunderstanding of the ideas put forward by UNIX, and yet is a position I see many of my peers share. I see this in how when the UNIX philosophy is brought up in context of modern systems, people point to microservices and say "look at that, microservices are UNIX and microservices suck!".
How did this happen?
I feel like this is the case of people confusing the implementation for the design. Missing the forrest for the trees. I believe this happened because of people quoting and repeating things as mantras without context. The one I hear a lot is "Write programs that do one thing and do it well", which is attributed to Peter H. Salus in "A Quarter-Centurary of Unix". I also see quotes quite often from Doug McIlroy written in a Bell System Technical Journal, in particular from a bulleted list that Doug gives under a section titled Style:
A number of maxims have gained currency among the builders and users of the UNIX system to explain and promote<br>its charachteristic style:
(i) Make each program do one thing well. To do a new job,<br>build afresh rather than complicate old programs by adding new features.
(ii) Expect the output of every program to become the input to another,<br>as yet unknown, program. Don't clutter output with extraneous information.<br>Avoid stringently columnar or binary input formats. Don't insist on interactive input.
(iii) Design and build software, even operating systems, to be tried early, ideally within weeks.<br>Don't hesitate to throw away the clumsy parts and rebuild them.
(iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour<br>to build the tools and expect to throw some of them out after you've finished using them.
These first two set of quotes seem to be so important that if you go to the Wikiepdia page for "UNIX philosophy" these are the first two quotes given in the "Origin" section. At a surface glance these are not exactly incorrect, I am not calling either author here wrong, you can observe that UNIX as it was implemented follows these ideas. The error here is when people extrapolate these implementation details out as the philosophy itself, when instead these are byproducts of applying the philosophy to specifically Operating Systems. The first two style rules given by Doug implicate specifically programs, a unit of organization that really only an operating system (whose primary job is managing them) would care about. Rule three here starts to get a bit more abstract, specifically because it implicates software and not programs, and is something I too find to be generally good advice outside of operating systems. Continuing to rule 4, we again see Doug refer to tools not processes and as such is something that I also agree with is generally adaptable to software at large.
Yet why aren't the last two style rules repeated more when discussing the "UNIX Philosophy"? Why do people seem to stop at things that tie the philosophy so closely to the notion of Operating Systems? Thinking that microservices are UNIX because it's a bunch of small programs talking to each other doesn't make sense because microservices is an architechture for distributed systems...