《unix编程艺术》笔记

这本书我读了很多遍，至今仍在读，每读一遍，都有新的收获。随着你的知识和阅历的增长，你会越来越体会到这本书的价值所在。我想不少人也是冲着本书作者的名头才看这本书的，不过我要说的是：”阅读本书时，请放下你心里的成见，不管是好的还是坏的“，不要抱着否定一切或者支持一切的态度来读本书。请结合你自己的知识和经验辩证地看待书中的内容。

第一章 
Unix系统的很多知识非常稳定，可以使用很多年而不会过时，非常值得投资。比如语言，系统调用，命令用法等等。

第二章     历史 - 双流记

2.1 Unix的起源和历史
>''软件第二版效应'' and ''软件第三版效应''
2.4 Unix的历史教训
>1 距开源越近越繁荣；2 ''别和低价而灵活的方案较劲''，换句话说，低档的硬件只要数量足够，就能爬上性能曲线而最终获胜。

第四章
操作系统的设计造就了该系统下的软件开发风格。比如unix下便宜的创建进程开销，方便的IPC通讯造就了小程序，协作式的软件开发模式。

操作系统的风格元素: 多任务，协作进程，内部边界，文件属性和记录格式，二进制文件格式，首选用户界面风格，目标受众，开发的门槛。
开发门槛高造就了精英编程文化，编程项目通常都是大而严肃，开发成本高，这些成本会转嫁给用户。

层次的树形结构中的节点可以在系统不同细节层次上表示不同规模的软件组件，节点可以表示为函数，模块，甚至子系统。所以带层次结构的方块图用处很大。

策略(应用逻辑)应该与机制(域原语)清晰地分离。机制好像砖头，策略决定了砖头(机制)组成的是楼房还是平房。机制在实现方面表现为服务例程的集合，比如函数库等。结合上一段的描述，在面向服务(SOA)的系统中，机制就是提供服务的子系统。

第四章P107
如果你知道自己在做什么，三层就足够了; 但如果你不知道自己在做什么，十七层也不够。

第七章 多道程序设计，即多进程协作
Unix IPC分类 ，IPC:进程间通讯
下面列出的各种IPC都存在隐含的层次关系，即一个程序实际上控制或驱动另一个程序，而在反方向上却没有或仅有有限的反馈，按编程复杂度由低到高排列。
1 把任务转给专门程序，shell out。调用程序并不和被调用程序通讯，如邮件或新闻组程序调用编辑器。
2 管道，重定向和过滤器。
3 包装器
4 安全性包装器和Bernstein链
5 从进程
对等进程间通讯
1 临时文件
2 信号
3 套接字
4 共享内存

要避免的问题和方法
1 废弃的Unix IPC方法: System V IPC and Steams
2 远程过程调用RPC
3 线程---威胁或恐吓

第十三章 复杂度：尽可能简单，但别简单过了头

13.1.2 接口复杂度和实现复杂度的折中
>...差即是好...

第十四章 语言：C还是非C

14.2 为什么不是C
>...C和C++以增加实现时间和（特别是）调试时间为代价来优化效率...
>...急剧下降的成本从根本上改变了编程的经济含义...
>...经济方面的最优选择已经变成尽可能减少调试时间、尽可能延长人类对代码的长期可维护性...
>...使用脚本语言的性能损失对真实世界的程序来说经常微不足道，因为真实世界的程序往往受I/O事件等待、网络延迟以及缓存列填充等限制，而非CPU的自身效率...

14.4 语言评估
>...混合语言是一种知识密集型（而不是编码密集型）的编程...
>...我们不仅应该具备相当数量的多种语言应用知识，并且还必须具备能够判断这些语言在什么地方最合适、以及怎样把它们组合在一起的潜经验...

第十五章 工具：开发的战术

15.1 开发者友好的操作系统
>...尽管所需要的工具都是现成的，文档也做得很棒，但''并没有通过一个集成开发环境(IDE)结合在一起''...
>...在unix下，语言和实现的选择广泛多样...使用多个代码生成器、定制配置器以及许多其它标准定制工具就是司空见惯的事情了。
>...unix提倡一种更灵活的风格，一种以编辑/编译/调试为中心、排它性更少的风格...

第十六章 重用：论不要重新发明轮子

>...不愿做不必要的工作是程序员的一大美德...
>...牢记经济原则。每个新项目都从刀耕火种开始干起简直就是极端的浪费。...
>...重新发明轮子之所以糟糕不仅因为浪费时间，还因为它浪费的时间往往是平方级。''走捷径往往产生粗糙、未经思考的版本，长期而言这是假性节约的，但通过这种方式来节省重新发明时间的诱惑几乎总是无法抵抗的''...
>...在各种级别上，Unix都支持重用...
>...Unix的经验是，养成良好的习惯，尝试通过''最少的新发明，组合现有组件以形成原型''，而非匆忙地编写独立的、只能使用一次的代码...
16.2 透明性是重用的关键
>...猪小兵的多数麻烦（也意味着大规模质量问题）归根结底是透明性，更确切的说，是缺乏透明性。无法修正不通内情的东西...
>...“只有变化才是永恒的”，源码可以永续，目标码则不行...
>......

 

第十七章 可移植性：软件可移植性与遵循标准

>...对于可移植性，目标机器的操作系统和其硬件结构都是障碍，意识到这一点，可能会导致相当激进的意见：完全规避问题的方法，就是移植操作系统本身。...
>...Unix程序员往往设想硬件是易变的，只有Unix API才是稳定的...
>...一旦设想软件项目的生命周期很短，就非常容易犯错...往往尽量避免软件依赖于某种特殊易逝的技术，而严谨地遵循开放标准...
>...可移植性最直接的效益是工具和应用程序无需每隔几年就重写，因为Unix软件比起原生的硬件平台来的长久，这时再正常不过的...
>...间接地益处并不明显但可能更为重要。可移植性的戒律往往在架构、接口和实现上施加了一种简单化的影响。这既提高了项目成功的几率也降低了生命周期的维护成本...
17.1 C语言的演化
>...C语言如此成功是因为它可以作为计算机硬件上的薄胶合层，近似于[BlaauwBrooks]的“标准架构”...
17.4 规格DNA，代码RNA
>...Unix程序员更倾向于认为代码是可弃的。这是注重模块性的产物，使其更容易在无损失的情况下抛弃和更换系统的各个子部分....Unix文化则主张干脆拆毁重来...
>...IETF传统反复教导我们将代码作为标准的从属物来思考。正是标准让程序可以协作，将各项技术结合起来成为比部分之和更大的整体...
>...在X中，规格说明就是一切。有时规格存在缺陷需要修正，但是代码通常比规格说明具备更多的bug...
>...经验表明，遵从标准、喜欢抛弃重建的Unix文化，虽然花费额外时间，但相比于因为没有标准提供指导和连续性，而必须不停地对代码基础库缝缝补补，往往能够产生更好的互用性...

 

第二十章 未来：危机与机遇

20.1 Unix传统中的平质（本质）和偶然
>...三个特殊的技术变化驱动了Unix设计风格中的重大变革：''网络互联''，''位图图形''和''个人计算机''。在每场革新中，Unix传统都通过抛弃不再合适的偶然属性、寻找新方法来适应新技术的核心观念，从而成功战胜了挑战。...
>...最后当TCP/IP胜出以及BSD套接字重申Unix本质上一切都是字节流的隐喻时，迷惑一扫而空...
>...GUI非常漂亮，但是系统的太多层次都捆绑在一起...让分离''机制''与''策略''成为一个明确准则...X窗口系统将其确立下来。通过将X窗口构件与完成底层图形操作的显示管理器分离，他们创造了一种架构...
>尽管伴随着许多创新，但所有对这三个技术的响应都保持着Unix的设计准则：模块化，透明性，机制同策略分离及其它我们在本书早前描绘的品质。Unix程序员在30年风雨中学到最有经验的回应，就是回到最初的准则：优先从流，命名空间，进程等Unix基本抽象中得到更多效用，而不是增加新的东西。
20.2 Plan9：未来之路
>...更优秀解决方案的最危险敌人，就是一个现存的、足够优秀的代码库...