Misconceptions about the UNIX Philosophy (2024)

关于 UNIX 哲学（2024）的误解

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 Blow 在 Oxide 的《On The Metal》播客采访中关于“UNIX 哲学”的一些观点。我将在此处摘录部分访谈内容。（由于原始转录稿与我听到的 Jonathan 的原话存在一些出入，内容经过了轻微编辑）

Jonathan: I’m going to throw out another stone that will get people mad at me, but so in terms of all this complexity that needs to be collapsed, I think everything has its time. The thing– Bryan: God, what’s next? Where are you going after that? Jonathan: Well, the Unix philosophy for example it has been inherited by Windows to some degree even though it’s a different operating system, right? The Unix philosophy of you have all these small programs that you put together in two like ways, I think is wrong. It’s wrong for today and it was also picked up by plan nine as well and so- Bryan: It’s micro services, micro services are an expression of Unix philosophy, so the Unix philosophy, I’ve got a complicated relationship with Unix philosophy. Jess, I imagine you do too, where it’s like, I love it, I love a pipeline, I love it when I want to do something that is ad hoc, that is not designed to be permanent because it allows me– and you were getting inside this earlier about Rust for video games and why maybe it’s not a fit in terms of that ability to prototype quickly, Unix philosophy great for ad hoc prototyping.

Jonathan: 我又要抛出一个会惹恼大家的观点了。关于所有这些需要被精简的复杂性，我认为万物皆有时。那件事—— Bryan: 天哪，接下来是什么？你打算说什么？ Jonathan: 嗯，以 UNIX 哲学为例，尽管 Windows 是一个不同的操作系统，但它在某种程度上继承了这一哲学，对吧？那种将许多小程序组合在一起的 UNIX 哲学，我认为是错误的。它不适合今天，而且 Plan 9 也采用了这种哲学，所以…… Bryan: 这就是微服务，微服务是 UNIX 哲学的一种体现。所以我对 UNIX 哲学有着复杂的情感。Jess，我想你也是，我喜欢它，我喜欢管道（pipeline），我喜欢在做一些临时性的、非永久性的工作时使用它，因为它允许我……你之前提到过 Rust 在视频游戏开发中的应用，以及为什么它在快速原型设计方面可能不太合适，而 UNIX 哲学非常适合这种临时原型设计。

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.

有一种观点认为，所谓的 UNIX 就是拥有多个通过管道相互通信的小程序，有些人甚至更进一步，认为这种通信必须是纯文本格式。这种定义是对 UNIX 所提出理念的深刻误解，然而我发现许多同行都持有这种观点。当在现代系统的背景下谈论 UNIX 哲学时，人们往往会指向微服务并说：“看，微服务就是 UNIX，而微服务烂透了！”这是怎么发生的？我觉得这是人们混淆了“实现”与“设计”，犯了“只见树木，不见森林”的错误。

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:

我相信这是因为人们在脱离语境的情况下，将某些话当作咒语般引用和重复。我经常听到的一句是“编写只做一件事并将其做好的程序”，这句话归功于 Peter H. Salus 在《A Quarter-Century of Unix》中的论述。我也经常看到 Doug McIlroy 在《贝尔系统技术杂志》（Bell System Technical Journal）中写下的引言，特别是 Doug 在标题为“风格”（Style）的章节下给出的要点列表：

A number of maxims have gained currency among the builders and users of the UNIX system to explain and promote its charachteristic style: (i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. (ii) 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. (iii) 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. (iv) 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.

在 UNIX 系统的构建者和用户中，有几条准则广为流传，用以解释和推广其独特的风格： (i) 让每个程序都做好一件事。要完成一项新工作，应重新构建，而不是通过添加新功能来使旧程序变得复杂。 (ii) 期望每个程序的输出都能成为另一个未知程序的输入。不要用无关信息充斥输出。避免使用严格的列格式或二进制输入格式。不要强求交互式输入。 (iii) 设计和构建软件（甚至是操作系统）时，要尽早进行尝试，理想情况下在几周内完成。不要犹豫，丢弃笨拙的部分并重新构建它们。 (iv) 优先使用工具而非人工辅助来减轻编程任务，即使这意味着你需要绕道去构建这些工具，并且在用完后可能要丢弃它们。

These first two set of quotes seem to be so important that if you go to the Wikipedia 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.

前两组引言似乎非常重要，以至于如果你查看维基百科的“UNIX 哲学”页面，它们是“起源”部分给出的前两条引言。乍一看，这些话并没有错，我并不是说这两位作者错了，你可以观察到 UNIX 的实现确实遵循了这些理念。这里的错误在于，人们将这些实现细节外推为哲学本身，而实际上，这些只是将该哲学应用于操作系统时产生的副产品。

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 architecture for distributed systems and the notion of these small programs talking to each other is a rule for operating systems. The friction that people face are from shoving a square peg in a round hole.

Doug 给出的前两条风格规则明确指向“程序”，这是一种只有操作系统（其主要工作就是管理程序）才会关心的组织单元。第三条规则开始变得抽象，因为它指向的是“软件”而非“程序”，我认为这在操作系统之外也是很好的建议。继续看第四条规则，我们再次看到 Doug 指的是“工具”而非“进程”，因此我也同意这同样适用于更广泛的软件开发。然而，为什么在讨论“UNIX 哲学”时，后两条规则很少被提及？为什么人们似乎总是停留在将该哲学与操作系统概念紧密联系的层面？认为微服务就是 UNIX，仅仅因为它们是一堆相互通信的小程序，这是说不通的，因为微服务是分布式系统的架构，而小程序相互通信的概念是针对操作系统的规则。人们所面临的冲突，正是因为试图将方榫强行塞入圆孔中。

Actual UNIX Philosophy

真正的 UNIX 哲学

Let us dig a bit more to see if we can find something that is a bit more abstract. A good start is in the preface to “The UNIX Programming Environment” by Brian Kernighan and Rob Pike. Of which the following is an excerpt:

让我们深入挖掘一下，看看能否找到一些更抽象的东西。一个很好的切入点是 Brian Kernighan 和 Rob Pike 所著的《UNIX 编程环境》（The UNIX Programming Environment）的前言，以下是其中的摘录：

Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is an approach to programming, a philosophy of using the computer. Although the philosophy can’t be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial tasks in isolation, but, when combined with other programs become general and useful tools. Our goal in this book is to communicate the UNIX programming philosophy. Because the philosophy is base…

尽管 UNIX 系统引入了许多创新的程序和技术，但没有任何单一的程序或理念能使其运作良好。相反，使其高效的是一种编程方法，一种使用计算机的哲学。虽然这种哲学无法用一句话概括，但其核心理念是：系统的力量更多地来自于程序之间的关系，而非程序本身。许多 UNIX 程序在孤立状态下只执行琐碎的任务，但当与其他程序结合时，它们就变成了通用且有用的工具。我们编写本书的目标是传达 UNIX 编程哲学。因为这种哲学的基础是……