译——了解/bin-/sbin和/usr/bin和/usr/sbin之间的关系
为什么？Linux中的操作系统目录结构如此繁琐？
正文
这是一封关于Unix和Linux文件结构历史的电子邮件。以下是其中文翻译：
David Collier在2010年11月30日15:58:00写道：
我看到busybox将其链接分散在这四个目录中。
有没有一个简单的规则来决定每个链接位于哪个目录中……
例如，我看到kill在/bin中，而killall在/usr/bin中……我不明白这其中的逻辑。
你知道Ken Thompson和Dennis Ritchie是如何在1969年的PDP-7上创建Unix的吗？
好吧，大约在1971年，他们升级到了一台配备了一对RK05磁盘包（每个1.5兆字节）的PDP-11用于存储。
当操作系统变得太大而无法适应第一个RK05磁盘包（他们的根文件系统）时，他们让其“泄漏”到第二个磁盘包中，这就是所有用户主目录所在的位置（这就是为什么该挂载被称为/usr）。他们在那里复制了所有的操作系统目录（/bin、/sbin、/lib、/tmp……），并将文件写入这些新目录，因为他们的原始磁盘空间不足。当他们获得第三个磁盘时，他们将其挂载在/home上，并将所有用户目录重新定位到那里，以便操作系统可以消耗两个磁盘上的所有空间，并增长到整整三兆字节（哦哇！）。
当然，他们制定了规则：“当系统首次启动时，它必须能够启动到足够的状态，以便能够在/usr上挂载第二个磁盘，所以不要把像mount这样的命令放在/usr/bin中，否则我们在启动系统时会遇到先有鸡还是先有蛋的问题。”这相当简单明了。这也非常特定于35年前的v6 Unix。
/bin与/usr/bin的分割（以及所有其他分割）是这一情况的产物，这是20世纪70年代的一个实现细节，这个细节被几十年来从未质疑过自己为什么要做这些事情的官僚们延续了下来。在Linux被发明之前，这种做法就已经没有意义了，原因有多个：
1）早期的系统启动是initrd和initramfs的职责，它们处理“此文件需要在该文件之前”的问题。我们已经有了一个可以启动主系统的临时系统。
2）共享库（由伯克利大学的人引入）阻止你独立升级/lib和/usr/bin部分。这两个分区必须匹配，否则它们将无法工作。1974年的情况并非如此，因为当时一切都是静态链接的，所以它们在一定程度上是独立的。
3）便宜的零售硬盘在1990年左右超过了100兆字节，而分区调整软件也在那时出现了（Partition Magic 3.0于1997年发布）。
当然，一旦分割存在，一些人就制定了其他规则来证明其合理性。根目录用于你从上游获得的操作系统内容，而/usr用于你的站点本地文件。然后，/用于你从AT&T获得的内容，/usr用于你的发行版（如IBM AIX、Dec Ultrix或SGI Irix）添加到其中的内容，而/usr/local用于你的特定安装文件。然后，有人决定/usr/local不是一个安装新软件包的好地方，所以我们添加了/opt！我还在等待/opt/local的出现……
当然，在30年的时间里，这种分割产生了一些有趣的发行版特定规则的出现和消失，比如“/tmp在重启之间会被清除，但/usr/tmp不会”。（当然，在Ubuntu上，/usr/tmp并不存在，而在Gentoo上，/usr/tmp是指向/var/tmp的符号链接，现在它具有“重启之间不会被清除”的规则。是的，所有这些都早于tmpfs。这与只读根文件系统有关，在这种情况下，/usr总是只读的，而/var是你的可写空间，/在大多数情况下都是只读的，除了/etc的某些部分，他们试图将其移动到/var，但实际上，将/etc符号链接到/var/etc的情况更为常见……）
像Linux基金会这样的标准官僚机构（多年前在其不断增长的吸积盘中消耗了自由标准集团）乐于记录并增加这种复杂性，而从未试图理解它首先存在的原因。“Ken和Dennis因为PDP-11上的RK05磁盘包太小，而将他们的操作系统泄漏到了相当于家的位置”这句话，他们根本听不懂。
我相当肯定，busybox安装只是将二进制文件放在历史上其他版本的二进制文件所在的位置。现在再也没有任何实际原因了。就我个人而言，我在自己组建的系统上，会将/bin、/sbin和/lib符号链接到它们在/usr中的对应位置。嵌入式开发人员会尝试理解和简化……