UNIX编程艺术
哲学
unix 之失
Unix文件在字节层次以上再无结构可言。文件删除了就没法恢复。
Unix的安全模型公认地太过原始。
作业控制有欠精致。
命名方式非常混乱。
或许拥有文件系统本身就是一个错误。
X 致力于提供 一套“机制，而不是策略”
设计的信念：最终用户永远比操作系统设计人员更清楚他们究竟需要什么。
因为“用错误的方式解决正确的问题总比用正确的方法解决错误的问题好”。
unix 哲学基础
- 模块原则
- 清晰原则 // 代码是给人看的。优雅而清晰的代码不仅不容易崩溃，更容易让后来者理解 。
- 组合原则 （如果程序彼此之间不能有效通信，那么软件就难免会陷入复杂度的泥淖）
- 分离原则 （实现同设计分离，接口同引擎分离-前端、后端）
- 简洁原则
- 吝啬原则 （除非别无它法，不要编写庞大的程序）
- 最小原则
- 透明原则 （设计要可见，透明性-知道要做啥，显见性-自带监视和显示 内部状态的功能）
- 健壮原则 （健壮源于简洁与透明）
- 表示原则 （将知识叠入数据，以求逻辑质朴而健壮）
- 通俗原则 （最易用的程序是让用户需要学习最少的东西）
- 缄默原则 （如果一个程序没什么好说的，就保护沉默，想象一下，早期字符终端，启动时刷屏，什么都有，什么都没有）
- 补救原则
- 经济原则 宁花机器一分，不花程序员一秒
- 生成原则 （让程序生成程序）
- 优化原则 （先走会跑）
- 多样原则
- 扩展原则
- 态度
历史
1969-1995
1980 uucp --> usenet
sun 公司，unix 商业化造成源码贡献的枯竭，差异化和碎片化
开发者、工程师市场，商用 、家用市场
Larry Wall patch 实用程序 ，让1990 的协作开发成为可能 。 Perl
1985 intel 386 4G memory
1985 GNU
1991 linus Torvalds
1993-1994 互联网大爆炸
1998 开源运动
教训
在Unix历史中，最大的规律就是：距开源越近就越繁荣。任何将Unix专有化的企图，只能陷入停滞和衰败。
另一个教训是：别和低价而灵活的方案较劲。或者，换句话说，低档的硬件只要数量足够，就能爬上性能曲线而最终获胜。
最后，旧学派的Unix社区因采用了传统的公司组织、财务和市场等命令机制而最终未能实现“职业化”。只有痴迷的“极客”和具有创造力的怪人结成的反叛联盟才能把我们从愚蠢中拯救出来——他们接着教导我们，真正的专业和奉献精神，正是我们在屈服于世俗观念的“合理商业做法”之前的所作所为。
比较
如果你不知道怎样表现得高人一等，找个Unix用户，让他做给你看。
5 文本化
INI 格式
unix 文件格式约定
- 一行一记录
- 每行不超 80 字符
- "# " 注释
- ： 分隔
- \ 转义
- HEX First
- no tab , white space
- 记录多行 节格式 %%\n
应用协议设计实例分析-SMTP
应用协议设计实例分析-POP3
应用协议设计实例分析-IMAP
18 文档概念
20 Plan 9
但是在2003年，看起来Plan 9的失败仅仅是它的改进尚不足以取代它的前任。对比Plan 9，Unix似乎明显嘎吱作响，锈迹斑斑，但是 Unix 的工作完成得很棒足以保持它的地位。这是个教训，提示雄心勃勃的系统架构师：更优秀解决方案的最危险敌人，就是一个现存的、足够优秀的代码库。