当某个彻底改变大家世界观的激进想法出现时，我们会本能地去怪罪那些带来新思想的信使
当人们自以为找到真理时，他是不会轻易放弃的。于是，Unix信徒们只能继续勇往直前，顽强地坚守着他们的信仰，并相信有一天世界会改变，软件的理想国终将来临。
这个世纪的哲学会成为下一世纪的常识
NIH(Not Invented Here，非我发明)综合症就是人们为了证明自己能够提供更加卓越的解决方案而放弃其他开发人员已经完成的工作。这是自私自利的做法。
Ken Thompson(Unix发明者)和Linus两人至少有一点相似之处，就是对事物的好奇心
Unix哲学概述（公认准则）
- 小即是美
比如想编写一个将A文件复制到B文件的程序，如果要严格遵循unix哲学的话，就只提供复制操作，而不关心文件是否存在合法等问题，这些问题由其他小程序负责
如果编写的程序有如下迹象，就表明该软件已经偏离了unix的设计哲学。
- 传递给函数的参数数量过多，导致代码走出了屏幕宽度
- 子程序代码的长度超过了整个屏幕。注意，使用较小的字体且在较大的显示器上
- 要靠阅读代码注释，你才能记住子程序到底在做什么
- 在开发程序过程中，你已经无法记起一个给定的错误信息是在什么条件下引发的
优秀的设计师会不遗余力地追求软件的可维护性，他们会给自己的代码加上完整而不冗余的注释，他们会尽量编写短小精悍的子程序。
大多数软件工程师不会满足于靠维护他人软件为生。他们认为只有编写新软件才能真正挣到钱，而不是修复旧有软件的bug。不幸的是，用户却不这么想。他们希望软件能够稳定运行。如果无法做到这一点，就会对程序供应商产生不满。
软件维护不是一份很吸引人的工作，因此程序员一直想办法让这个任务变得更容易，甚至干脆避开它。然而，大部分人都无法推卸这个责任，他们也许能够将这份烦人的工作交给新手来做，但更多时候，这一职责还是会落在原作者身上。
小程序消耗的系统资源较少，且容易与其他工具相结合
- 让每一个程序只做好一件事
作者举了一例，ls命令。作者认为：ls只需用来显示内容，不应该给它加上列格式化的代码，可以把格式化的工作交给其他命令来帮，ls命令就会小得多，也就会更容易理解、维护，占用较少资源。这种说法对吗？？
- 尽快建立原型（prototyping）
发生变化是不可避免的，这通常要归咎于人们沟通交流的失败。当产品的最终用户试图解释其需求时，他的叙述与实际情况会有出入。他可能忽略了一些事情，或是没精确表达出他脑海里那些想法的细节（这很有可能！）因此，工程师们只能用想象力来填补这些空白。尽管他会仔细阅读需求文档，但在设计过程中难免加入主观偏见。更糟糕的是，工程们与用户之间还隔着一些人，比如产品经理、销售团队、支持人员，这些人会进一步曲解最终用户的期望。
永远没有做完的软件，只有发布的软件
有了一个具体原型，你就可以指着它说道：“产品将会是这个样子。”如果能把它演示给值得依赖的客户看，并获得他们的反馈，你就会了解你的设计是否具有针对性了。通常你会收到大量批评，没关系，你已经获得宝贵的反馈信息，总好比在产品发布之后听到万千用户要求召回软件的愤怒声了
- 舍高效率而取可移植性
c程序缺乏shell脚本的可移植性。c程序往往要依赖头文件、计算机体系结构以及具体unix版本中一系列不支持的特性。
不要花太多时间去优化程序。很多unix程序员常犯的错误是，为了获得性能上一些微不足道的优势而采用c语言去重写shell脚本，这纯粹是浪费时间。如果必须要优化c程序的性能，unix平台提供了prof和其他一些工具来定位使用最频繁的子程序，对这些代码块进行优化，可以产生事半功倍的效果。
另一种提高程序性能的方法就是研究如何处理数据。
最高效的方法往往不可移植。很可能要利用某些特殊硬件功能的优势，当目标硬件被取代后，就不行了。
衡量应用程序是否成功的一个标准就是它能够在多少个系统上运行。人们在早期为可移植性软件付出的所有努力都会在后期得到丰厚回报。
- 使用纯文本文件来存储数据
便于可移植，通用的转换格式，易于阅读和编辑
那些被称为unix大师的人都会拥有自己的常用工具集，里面包含了一些程序和shell脚本，在他们从一台机器转换到另一台机器，一份工作换到另一份工作时，这些工具如影随形。
- 充分利用软件的杠杆效应
利用代码重用的优势。良好的程序员编写优秀代码，优秀的程序员借用优秀代码。那些能够有效地裁剪和组合模块的开发人员才真正拥有“就业保障”。如果有这个能力，开发人员往往能在很短的时间内写完很多软件，企业普遍会认为这些员工是无可替代的
避免NIH综合症。查看过别人的工作并夸口说自己可以做得更好，并不代表你更有创造性。
标准驱动着软件供应商逐步走向软件商品化的模式。所有的电子表格看来很相似，所有的文字处理软件也都有相同功能等等。为此，公司既要满足统一标准，又要保证独特性。想在市场上立于不败之地，就要增加产品的闪光点，而不是另起炉灶，从零开始。
允许他人使用你的代码来提高软件杠杆效应
- 使用shell脚本来提高杠杆效应和可移植性
无论什么时候，只要有可能，编写shell脚本来替代c程序都不失为一个良好选择。如果你真的想让shell脚本运行得更快，那么 你就必须找到不同的解决办法，而不是立刻改用c程序
使用shell脚本，你可以站在巨人的肩膀上，这些巨人其实也站在其他巨人的肩膀上，循环反复，这就是软件的杠杆效应。
- 避免强制性的用户界面
这样的界面往往是模态的
- 让每一个程序都成为过滤器
你永远猜不到人们将如何使用你的软件。永远不要自以为是地认为他们会完全遵从你的设计意图。
问题
现在的开源软件设计都遵循unix的公认哲学吗？
unix哲学在实践上有多大难度？
次要准则（不一定每个人都认同）
- 允许用户定制环境
- 尽量使操作系统内核小而轻巧
- 使用小写字母，并保持简短
- 并行思考
- 寻找90%的解决方案
百分百完成任务是很困难的 - 更坏就是更好
如果某一事物的包容性强到足以涵盖所有事物，那它就比那些“独家”系统要好很多
就算一群人认同你的观点，也不代表你就是对的。我同样可以找到另外一群认同我的观点的人。
Windows最像VMS，它们都基于这样的设想，那就是用户害怕使用计算机，而unix从来没有试图去满足新手易于使用的需要
这个世界上最快的全文搜索引擎其实只是运行在廉价的PC机集群上，运行的也是免费的操作系统
虽然在可移植性上，java比c要更好，但它的效率却是C的95%。真正与内核打交道的人是极少数，大部分开发人员都是在开发能够运行在windows和linux平台之上的应用程序。对他们来说，java可以很好地满足需求。