评论《Unix 痛恨者手册》（Andrew Kuchling 于 1997）

《Unix 痛恨者手册》（1994）

作者：Simson Garfinkel、Daniel Weise、Steven Strassman

序言：Donald Norman

“反序”：Dennis Ritchie

摘要：这本书对 Linux 爱好者来说可能令人气愤，但其中确实隐藏着一些有价值的见解。

Dennis Ritchie 在本书的“反序言”中写道：“你们声称在追求进步，但你们的主要成果是发牢骚。”这其实是对本书的相当准确的评价；整本书是一连串的抱怨，抱怨因系统崩溃而丢失的工作、为绕过 bug 而浪费的时间、不清晰的文档、以及晦涩的命令行参数。类似的书其实可以写关于任何操作系统。显然，我并不完全赞同这本书；否则我也不会在用 Linux。但对于 Linux 开发者来说，其中的确有些值得关注的材料。

这本书描述了 Unix 中的问题和烦恼；由于其灵感来自一个著名的邮件列表 UNIX-HATERS，其中收录了很多现实生活中的恐怖故事，有的令人发笑，有的令人揪心。书中提到的一些问题确实存在，但有不少后来已被修复，或通过进一步开发而变得无关紧要。两个例子：

• 关于 Unix 文件系统：“……由于大多数磁盘驱动器可以一次传输高达 64K 字节，先进的文件系统以连续块的形式存储文件，以便可以在一个操作中读取或写入……这些特性都已经在商用操作系统中构建并投入使用了。Unix 一个都没有。”但事实是，大多数 Linux 系统使用的 ext2 文件系统确实做到了这一点；没有什么妨碍更好文件系统的实现。

• “Unix 没有内建系统来自动加密硬盘上存储的文件。”（你知道有什么操作系统一出厂就具备这个功能吗？你能想象那些忘记密码的用户会发出多大的抱怨吗？）无论如何，相关的软件已经被编写出来了，或者是作为加密的 NFS 服务器（CFS），或者是作为内核模块（loopback 设备）。

我从阅读这本书中得到的一些结论如下：

首先，这本书写于 1994 年，当时自由 Unix 系统还不太知名，因此书中所述的系统主要是商业系统。自由软件的支持者应该注意到，书中许多问题都源于当时大多数 Unix 变种的专有性质。作者指出 shell 和工具中的各种 bug 和功能缺失，如果能获得源代码，这些问题是可以修复的。

更好的解决方案有时没有流行开来，是因为它们被一些无意共享代码的公司所拥有。例如，书中称赞了 Veritas 文件系统这样的日志型文件系统，认为它们操作更快，系统崩溃时数据丢失风险更小。作者写道：“日志型文件系统会在整个 Unix 世界流行开来吗？大概不会，毕竟它不标准。”我认为更重要的原因是，这个文件系统是专有软件，公司要么把代码藏起来（以维持竞争优势），要么收取高额授权费（以改善财务报表）。

书中关于 X Window 系统的章节极度一针见血；X 的确是款异常复杂的系统，它在客户端和服务器之间的划分也并不总是最优的。书中提出了一个有趣的解决方案：让程序通过发送代码扩展图形服务器。这种做法曾在 Sun 的 NeWS 系统中使用过，NeWS 以 PostScript 作为语言。不幸的是，NeWS 现在早已死亡——它毕竟是个专有系统，最终被 MIT 自由发布的 X 所取代。（冷知识：NeWS 是由 James Gosling 设计的，他后来因设计 Java 而出名。Sun 看来决心不再让 Java 重蹈 NeWS 的覆辙……我们拭目以待。）

其次，许多问题可以通过整合更好的工具进系统来解决。书第 8 章中准确地指出了 Unix “find” 命令的各种问题，但这些问题在 GNU find 中似乎已经修复了。有人还写了 GNU locate，它是一种更简单的查找文件方式。它每晚运行脚本构建文件名数据库，然后“locate”命令在该数据库中搜索匹配项。这个数据库其实可以不止包含文件名；加上文件大小、创建时间后，就可以对这些字段进行搜索。完全可以设想一个守护进程，在内核支持下实时保持数据库更新。源代码是可得的，所以只需要有作者来实现这个想法……

第 8 章还指出 shell 编程复杂且受限；shell 脚本依赖如 “ls” 这样的子程序，而这些子程序在不同系统之间可能行为不同，使得可移植性成问题。引用规则也复杂，递归应用时尤为困难。这是真的，也正是为什么如今很少有人写体量大的 shell 脚本；人们转而使用 Perl 或 Python 这样的脚本语言——更强大，也更易用。

对 Linux 支持者来说，最重要的一点是：本书所述的缺陷中，并非所有在 Linux 中都已被修复！例如，大多数 Linux 发行版仍然无法真正让你“撤销删除”文件，尽管 Midnight Commander 程序似乎支持恢复删除。正如作者所说，“sendmail” 确实非常多 bug，Unix 的安全模型也不算强大。但人们已经在开发替代 sendmail 的新程序，同时也在编码诸如“不可变属性”这样的安全特性，甚至还在辩论全新的安全机制。

因此，这本书对于 Linux 开发者来说，是指出“尚待修复之处”的宝贵指南。我鼓励 Linux 开发者，或那些在寻找 Linux 项目的人，去读一读这本书。读的过程中你也许会血压飙升，但请仔细审视每一个抱怨，问问自己：“这个抱怨确实是个问题吗？如果是，怎么修？我能做出这个改进吗？”