封面
版权信息
内容简介
悦读上品 得乎益友
其 他
译序
NOTE
这本书是给读者增长见识的，很多案例分析不管结论如何，读者都可以从中见到红蓝两方的思维方式和行事方法，以及各方高手看待问题的角度
2022-01-28 00:40:43
序
NOTE
你将学到那些Unix专家们都不自知的Unix开发知识。少一点技术，多一些共享文化：显见和隐微的，直观和潜流的——这是本书和大多数Unix书籍不同的地方——不止于方法，更重乎理念
2022-01-29 12:39:21
NOTE
将Unix哲学的原理细分为有关设计与实现的、更专门的建议
2022-01-29 12:50:58
NOTE
人与人之间的事务与约定，而这正是Unix文化拥有高效能的原因
2022-01-29 12:51:09
NOTE
因为本书着力传递文化，因此加入了很多野史和坊间传说，这在技术书中并不多见
2022-01-29 18:18:58
NOTE
三十年河东，三十年河西，眼前所见，也许过不了多久就会过时，而需要重新检省
2022-01-29 18:30:14
Part Ⅰ
1 哲学
NOTE
没有哪一种操作系统能像 Unix 那样，能同时在作为研究工具、定制技术应用的友好宿主机、商用成品软件平台和互联网技术的重要部分等各个领域都大放异彩
2022-01-29 18:30:15
NOTE
Robert Metcalf[以太网络的发明者]曾说过：如果将来有什么技术来取代以太网，那么这个取代物的名字还会叫“以太网”。因此以太网是永远不会消亡的（注[2]）。Unix也多次经历了类似的转变。
2022-01-29 18:30:15
NOTE
性能—时间的指数曲线对软件开发过程所引发的结果，就是每过18个月，就有一半的知识会过时。Unix并不承诺让你免遭此劫，只是让你的知识投资更趋稳定。
2022-01-29 18:39:38
NOTE
Unix的本源用途——作为大中型计算机的通用分时系统，由于受到个人工作站的围剿，正迅速地退出舞台，隐入历史的迷雾之中。因而 Unix 究竟能否在目前被Microsoft主宰的主流商务桌面市场上取得成功，人们自然也存在着一定的疑问
2022-01-29 18:40:23
NOTE
挫败这些怀疑者的不是别的，正是Linux和其它开源Unix（如现代BSD各个变种）的崛起
2022-01-29 18:43:12
NOTE
X 致力于提供 一套“机制，而不是策略”，以支持一套极端通用的图形操作，从而把使用工具箱和界面的“观感”（策略）推后到应用层
2022-01-29 18:44:14
NOTE
最终用户永远比操作系统设计人员更清楚他们究竟需要什么。
2022-01-29 18:44:38
NOTE
用错误的方式解决正确的问题总比用正确的方法解决错误的问题好”
2022-01-29 18:44:59
NOTE
策略相对短寿，而机制才会长存
2022-01-29 18:45:44
NOTE
但是自由共享源码的同僚严格复审的开发方式打从 Unix 诞生起就是其文化最具特色的部分。
2022-01-29 18:47:39
NOTE
Unix API
2022-01-31 11:05:21
2 历史——双流记
3 对比：Unix哲学同其他哲学的比较
NOTE
与不同操作系统相关的设计和编程风格可以追溯出三个源头：（a）操作系统设计者的意图；（b）成本和编程环境的限制对设计的均衡影响；（c）文化随机漂移，传统无非就是先入为主。
2022-01-31 11:12:46
NOTE
其中最重要的一点应当是“一切皆文件”模型及在此基础上建立的管道概念[1]。
2022-01-31 11:13:09
NOTE
系统工具和API塑造的模型将反渗到应用编程中
2022-01-31 11:13:22
NOTE
彻头彻尾的反Unix系统，就是绝无多任务处理能力——或者通过对进程管理增设诸多的规定、限制和特殊情况来削弱多任务能力——的一个废物。
2022-01-31 11:21:56
NOTE
Unix至少设立了三层内部边界来防范恶意用户或有缺陷的程序。一层是内存管理：Unix 用硬件自身的内存管理单元（MMU）来保证各自的进程不会侵入到其它进程的内存地址空间。第二层是为多用户设置的真正权限组——普通用户（非root用户）的进程未经允许，就不能更改或者读取其他用户的文件。第三层是把涉及关键安全性的功能限制在尽可能小的可信代码块上。在Unix中，即使是shell（系统命令解释器）也不是什么特权程序。
2022-02-01 14:33:39
Part Ⅱ
4 模块性：保持清晰，保持简洁
NOTE
自从19世纪晚期人们采用标准螺纹以来，硬件的模块性就一直是工程技术的基石之一
2022-02-01 14:52:42
NOTE
更加笃信重视模块化、更注重正交性和紧凑性等问题。
2022-02-01 14:53:11
NOTE
快速内层循环
2022-02-01 14:54:32
NOTE
模块化代码的首要特质就是封装。封装良好的模块不会过多向外部披露自身的细节，不会直接调用其它模块的实现码，也不会胡乱共享全局数据。模块之间通过应用程序编程接口（API）——一组严密、定义良好的程序调用和数据结构来通信。这就是模块化原则的内容
2022-02-01 14:58:54
NOTE
在模块很小时，bug发生率也出乎意料地增多，这在大量以不同语言实现的各种系统中均是如此。
2022-02-01 15:01:00
NOTE
模块小时，几乎所有复杂度都在于接口；想要理解任何一部分代码前必须理解全部代码，因此阅读代码非常困难。
2022-02-01 15:01:18
NOTE
人类短期记忆能够容纳的不连续信息数就是七，加二或减二。这给了我们一个评测API紧凑性的很好的经验法则：编程者需要记忆的条目数大于七吗？如果大于七，则这个API不太可能算是严格紧凑的。
2022-02-02 15:14:54
NOTE
尤其是严格的shell 编程，要求你必须知道其他六个工具，如sed（1）和awk（1）等
2022-02-02 15:15:38
NOTE
“……限制不仅提倡了经济性，而且某种程度上提倡了设计的优雅”。要达到这种简洁性，尽量不要去想一种语言或操作系统最多能做多少事情，而是尽量去想这种语言或操作系统最少能做的事情——不是带着假想行动，而是从零开始（禅称为“初心”（beginner’s mind）或者叫“虚心”（empty mind））。
2022-02-02 18:51:10
NOTE
依附导致痛苦；软件设计的经验教导我们：依附于被人忽略的假定将导致非正交、不紧凑的设计，项目不是失败就是成为维护的梦魇
2022-02-02 18:51:33
NOTE
自底向上，从具体到抽象
2022-02-02 18:48:30
NOTE
自顶向下，从抽象到具体
2022-02-02 18:48:33
NOTE
网页浏览器的顶层设计是对浏览器预期行为的规格说明：可以解析什么类型的URL（http：，ftp：还是file：），可以渲染哪些类型的图像，是否可以或者带哪些限制来支持 Java 或 Javascript 等等。与这个顶层意图相对应的实现层是浏览器的主事件循环；在每个周期内，这个循环等待、收集、分派用户的动作（例如点击网页链接或在某个域内键入字符）
2022-02-02 19:07:15
NOTE
当以下三个条件都成立时，自顶向下不失为好方法：（a）能够精确预知程序的任务，（b）在实现过程中，程序规格不会发生重大变化，（c）在底层，有充分自由来选择程序完成任务的方式
2022-02-02 19:19:42
NOTE
程序员尽量双管齐下——一方面以自顶向下的应用逻辑表达抽象规范，另一方面以函数或库来收集底层的域原语，这样，当高层设计变化时，这些域原语仍然可以重用。
2022-02-02 19:20:14
NOTE
出于后天学得的本能，Unix程序员更倾向于自底向上的编程方式
2022-02-02 19:20:31
NOTE
阻抗匹配（impedance match）
2022-02-02 19:21:15
NOTE
胶合层是个挺讨厌的东西，必须尽可能薄，这一点极为重要。胶合层用来将东西粘在一起，但不应该用来隐藏各层的裂痕和不平整。
2022-02-02 19:21:32
NOTE
渲染代码作为浏览器中最易产生 bug 的地方而臭名昭著。它的存在，是为了解决HTML解析（因为形式不良的标记太多了）和GUI工具包（可能未必具有真正需要的原语）中存在的问题
2022-02-02 19:38:13
NOTE
Unix编程风格强调模块性和定义良好的API，它所产生的影响之一就是：强烈倾向于把程序分解成由胶合层连接的库集合，特别是共享库（在Windows和其它操作系统下叫做“动态连接库”（DLL）
2022-02-02 19:40:09
NOTE
GIMP被做成了一个图像处理和辅助程序的库，由一个相对较薄的控制层代码调用。驱动码知道 GUI，但不直接知道图像格式；反过来，程序库程序知道图像格式和图像操作，但不知道GUI
2022-02-03 07:06:47
NOTE
在C语言中模仿真正的对象很费力。正因为这样，堆砌抽象层是一件非常累人的事
2022-02-03 07:10:21
NOTE
a+a+a+a可以用a*4来表示，如果a是整数，也可以表示成a＜＜2。但是如果构建了一个类并重新定义了操作符，就根本没什么东西可表明运算操作的交换律、分配律和结合律。既然不能查看对象内部，就不可能知道两个等价表达式中哪一个更有效。这本身并不是在新项目中避免使用OO技法的正当理由，那样只会导致过早优化。但这却是在把非OO代码转换为类层次之前需要三思而后行的原因
2022-02-03 07:11:11
5 文本化：好协议产生好实践
NOTE
序列化（保存）操作有时也称为列集（marshaling），其反向操作（载入）称为散集（unmarshaling）。
2022-02-03 11:25:40
NOTE
，不要在任何文本字段中嵌入冒号。良好的做法应该是这样：告诉文件先用换码符嵌入冒号再写代码，然后告诉文件读取代码对其解释。对此，Unix传统偏爱使用反斜杠
2022-02-03 11:27:41
NOTE
XML的一个优势在于经常无需知道数据语义，仅通过语法检查就能发现形式不良、损坏或错误生成的数据
2022-02-03 11:31:43
NOTE
需要XML 解析器，这就意味着需要庞大复杂的程序
2022-02-03 11:31:53
NOTE
和XML一样，不能与grep（1）或常规Unix脚本工具很好地配合使用
2022-02-03 11:33:14
NOTE
如果可能，每行不超过80个字符。这样使格式可以在普通尺寸的终端视窗上浏览。如果很多记录一定要超过80个字符，考虑使用分节格式（stanza format）
2022-02-03 11:34:37
NOTE
对于复杂的记录，使用“节（stanza）”格式：一个记录若有多行，就使用%%\n或%\n作为记录分隔符。
2022-02-03 11:36:39
6 透明性：来点儿光
NOTE
如果实际上能预测到程序行为的全部或大部分情况，并能建立简单的心理模型，这个程序就是透明的，因为可以看透机器究竟在干什么。
2022-02-03 07:15:58
NOTE
可显性是一种主动品质。在软件中要达到这一点，仅仅做到不晦涩是不够的，还必须尽力做到有帮助
2022-02-03 07:16:43
NOTE
拿不准，用穷举
2022-02-03 11:22:20
NOTE
包含开发者手册（hacker’s guide）。在发布源码的同时包含指导文档，简略地描述代码的关键数据结构和算法，这种做法永远得到高度认可
2022-02-03 11:23:06
7 多道程序设计：分离进程为独立的功能
NOTE
多处理
2022-02-03 07:47:37
NOTE
Unix操作系统提倡把程序分解成更简单的子进程，并专注考虑这些子进程间的接口。这至少可通过以下三种方法来实现：● 降低进程生成的开销。● 提供方法（shellout[shell 执行模块]、I/O 重定向、管道、消息传递和套接字）简化进程间通信。● 提倡使用能由管道和套接字传递的简单、透明的文本数据格式。
2022-02-03 11:24:55
NOTE
必须更多地关注在进程间传递信息和命令的协议设计（在所有种类的软件系统中，接口都是 bug聚集之地）
2022-02-03 11:25:11
NOTE
我们在第 5 章分析了这个设计问题的底层——如何统筹透明、灵活、可扩展的应用协议。
2022-02-03 11:25:20