FreeBSD 中文社区 2025 第二季度问卷调查
FreeBSD 中文社区(CFC)
VitePress 镜像站QQ 群 787969044视频教程Ⅰ视频教程Ⅱ
  • FreeBSD 从入门到追忆
  • 中文期刊
  • 状态报告
  • 发行说明
  • 手册
  • 网络文章集锦
  • 笔记本支持报告
  • Port 开发者手册
  • 架构手册
  • 开发者手册
  • 中文 man 手册
  • 文章与书籍
  • UNIX 四分之一世纪
  • Unix 痛恨者手册
  • Unix 痛恨者手册中文版
  • 前言
  • 序言
  • 事情还没到最糟,接下来只会更糟
    • 我们是谁
    • Unix 痛恨者手册往事
    • 贡献者与致谢
    • 排版惯例
    • Unix 痛恨者手册免责声明
  • 反序言(作者: Dennis Ritchie)
  • 第一部分:用户友好?
    • Unix:世界上第一款计算机病毒
    • 欢迎,新用户!就像装满六发子弹的俄罗斯轮盘赌
    • 文档?什么文档?
    • 邮件:别跟我说话,我不是打字机
    • 无聊的网络:我发帖,故我在
    • 终端错乱:靠!又挂了!
    • X-Windows 灾难:教你把 50 MIPS 工作站慢成 4.77MHz IBM PC
  • 第二部分:程序员的系统?
    • csh、管道和 find:强力工具,大力出奇迹
    • 编程:别动,这一点儿也不疼
    • C++ 九十年代的 COBOL
  • 第三部分:系统管理员的噩梦
    • 系统管理:Unix 的隐形成本
    • 安全:哦,抱歉,先生,请继续,我没意识到您是 root 用户
    • 文件系统:它确实会损坏你的文件,但你看看它有多快!
    • NFS:噩梦文件系统(Nightmare File System)
  • 第四部分:等等
    • 尾声:通过 Unix 获得的启示
    • 作者坦言 C 和 Unix 是骗局。新闻稿:立即发布
    • “宁拙勿巧”的崛起(作者:Richard P. Gabrie)
    • 参考文献:正当你以为已经脱离困境时
  • 附录
    • Unix 的流行病学(Philip E. Agre 于 1994)
    • 评论《Unix 痛恨者手册》(Andrew Kuchling 于 1997)
    • 重新审视《Unix 痛恨者手册》(Raymond, Eric S 于 2008)
由 GitBook 提供支持
LogoLogo

FreeBSD 中文社区(CFC) 2025

在本页
在GitHub上编辑
导出为 PDF
  1. 附录

评论《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 项目的人,去读一读这本书。读的过程中你也许会血压飙升,但请仔细审视每一个抱怨,问问自己:“这个抱怨确实是个问题吗?如果是,怎么修?我能做出这个改进吗?”

上一页Unix 的流行病学(Philip E. Agre 于 1994)下一页重新审视《Unix 痛恨者手册》(Raymond, Eric S 于 2008)

最后更新于3天前