Unix 中 /bin、 /sbin、 /usr/bin、 /usr/sbin 的渊源

在包括 Linux、Mac、FreeBSD 等在内的绝大多数类 Unix 系统中，根目录下会存在 /bin /sbin /usr/bin /usr/sbin 等等目录，然而却没有文档能够明确地说明这些目录的相应规则。

其实，这还得从 Ken Thompson 和 Dennis Ritchie 发明 Unix 的时候说起……

1969 年两人在一台 PDP-7 机器上共同发明了 Unix，之后大概在 1971 年机器升级为 PDP-11，同时配备有两块磁盘作为存储。之后由于系统的扩展，一块磁盘已经不能满足系统根目录(root filesystem)容量需求，于是两人把系统的一部分移植进了第二块磁盘，第二块磁盘原本放置的是用户主目录(user home directories)，当时的挂载点为 /user。于是，在把 /bin /sbin /lib /tmp 等目录移植之后，出现了对应的 /usr/bin /usr/sbin 等。再之后，又有了第三块磁盘，顺便又把所有的用户目录(user directories)移植，并挂载至 /home。

于是，系统可以畅享三块磁盘的空间。这大概也是现在的系统目录分布情况了，几十年前因为磁盘空间不足导致的结果。当然，各 Unix 变体及 Linux 发行版会有区别。那么为什么在移植了最初的 /bin /sbin 等目录之后，还会有 /bin /sbin 存在于根目录呢？先假设所有的这些小程序都移植到了第二块磁盘，那么在系统启动的时候，系统为了获取这些程序需要挂载第二块磁盘。有什么地方不太对？mount 程序也在第二块磁盘吧。所以，需要挂载第二块磁盘才能使用 mount，但是需要先使用 mount 才能挂载第二块磁盘。因为这样一些先有鸡还是先有蛋的问题，根目录下需要保留一些程序。

详情可以参考这封邮件 Understanding the bin, sbin, usr/bin , usr/sbin split

正好前段时间在看 「Linux/Unix 设计思想」一书，我只能说，这种做法非常 Unix。在书中罗列的设计原则中，随处可见诸如：

• 良好的程序员写出优秀的软件，优秀的程序员「窃取」优秀的软件；
• 最好在原有软件基础上加强和拓展，而不是因为 Not Invented Here(非我发明，称之为 NIH 综合征)，自己重复造轮子；
• 充分利用软件的杠杆效应（代码重用）；
• 没有足够的时间写出「完美」的代码，只需要满足 90% 的需求；
• ……

结合 Linux 的历史轨迹，也正是上述的思想才导致了其蓬勃发展；代码高度复用，杜绝重复造轮子，以实用为主。但是也存在比较明显的弊端，借用 Linus 定律：

Given enough eyeballs, all bugs are shallow

软件层面的 bug 是技术层面的问题，比较容易修复；但是在设计层面而言，面对海量的开发者/志愿者，如何调度发展方向？几十年以来发展和使用的设计架构于代码库，如何迁移？光看看从 Xorg 到 Wayland 这几年的迁移多难就能明白。这种集市化的开发模式，也导致了其必定小众的特点，但同样借用上述一书的观点——「如果你不能理解，那你就不属于这个世界」。