读《UNIX编程艺术》· Eric S. Raymond
我会回答两个点，1. 为什么读此书 2. 收获
为何读此书
其实我也很想知道，“我想成为怎样的人？我为什么存在？我的立心之本是什么？”
“读史明智”
我需要向这些伟人学习，学两方面 1.精神 2.务实。
自从19年我认识 Deepin 以来，我才知道原来中国人也可以造操作系统。自那以后，我开始有了自我的意识，简单来说是自信。
我要复刻和积累前人的精神，虽历史不可复制，但我会以史为鉴，至少在很多的重要选择面前，我会有很多参考。
我想学好Linux，我想了解其背后的故事，我想知道 为什么Unix死了，而Linux又变成了新的Unix。我想知道，Unix是怎样的哲学。我也想将这种哲学应用到我的工作、生活、学习中去。
我想知道，前人是怎么Hack Unix。
收获
本书的Emacs占比较高，仿佛其已经认同Emacs非常符合Unix哲学。所以一直在以Emacs为例，与其他的软件进行对比。
有几点我非常赞同
- 如果软件太慢，不如等待下一个摩尔定律的周期到来
- Emacs就是因为踩上了摩尔定律的东风
- 起初的Emacs 900kb，而Vi 1500kb
- 因为性能问题，所以才强调需要高效的操作内存
- 现在性能够用，所以用自带内存管理的编程
- 比如 Java，c#，Golang，Emacs Lisp
- 其实这点很简单的就能知道，为什么XP经常崩，因为用的都是操作内存的编程，操作不好就会崩。
- 因为硬件性能太低（比如嵌入式现在还是需要这种极限操作）
- 这对于 那一代人有点噩梦的感觉
- 其实我想学怎么去操作内存，然后写一些高性能的程序出来
- 这是我的一个目标吧
- 要有优秀的设计，而不是在意极致的代码细节
- 这点其实，两方面很多人都做不到
- 代码写得烂
- 设计也很烂
- 还自以为是不得了，我写了个牛逼软件
- 要保证软件的质量，先要确保设计的透明性
- Another：我的代码写的很好，一看就懂
- 首先，Another的代码写的很烂，其次没有设计或者相关的文档
- 而且模块与设计思想不明确，没有正常的维护套路
- 这点其实，两方面很多人都做不到
- 我才发现，原来我一直想学的软件工程，设计优秀的软件思想，属于Unix哲学。
- 比起编码，我更强调先设计，再编码，再测试
- 不要过早的优化，这是万恶之源
- 这点我很有感受
- 不看中核心技术的重要性，没有侧重点
- 简单理解为，做一个灌溉工程，框架什么的，用钛金，用好的板材
- 水龙头用的是德国进口，可以用一百年
- 但水管却是一些烂水管，而且喜欢把水管摆成艺术的样子
- 然后大家都全心的去给灌溉工程贴膜这些，最后交接时
- 发现已埋的很深的水管全是些烂水管
- 你找埋水管的，他说是水管的问题，我已经埋好了
- 你找做水管的，他说，是埋的时候搞烂了
- 但近一步排查的时候，发布水龙头、蓄水池都要重装，或者换厂家
- 理论上来说，这一套工程，可以用到死
- 但理论永远是废话，现实的问题 像个皮球
- 仅可能简单，但不要为了简单而简单
准确来说，现代的Unix-Like，确实是继承了Unix的开山的思想，但是更优秀的设计或许并不来自于Unix系统。比如BSD，Unix死得好，但Unix死时硬拉着BSD重伤。
因为其先给学校免费用，然后培养出来一大堆工程师，这些工程师，师承UNIX的Ken Thompson。也就是AT&T想商业化这UNIX，结果UNIX死了。然后GNU以及BSD相关的软件便活了。
你可以理解为，UNIX这个商品死了，而UNIX设计思想活了。UNIX还好给 伯克利大学，以及其他的大学免费用。让这些学生知道其优良的设计，这才不至于让UNIX死于资本家之手。如果不是读了《Unix历史》和《UNIX编程艺术》我还一直被蒙在鼓里。
网络上这群人真的是闲的没事，编那些垃圾信息来骗刚入门的小白。
“现代的 Unix-Like系统，就是Unix系统。死的是商品UNIX。”
GNU Linux / BSD 相关的系统，都是现代Unix，但不是商品UNIX。
所以说 UNIX这种商品该死，好死，活该。
但 UNIX财富、哲学、思想，都被继承了，现在UNIX化成了 这些操作系统的灵魂。
其实一直对那些玩Linux的人没有什么好感，我觉得这种不务正业对吧。然后我突然想到了，是因为Unix提供了这样的一套配置的意思，让用户自由度很高，这也就是在 “Hack Unix”。
当然还有很多细节我没有提到，但并不代表我忘了。我会在不经意的那个瞬间想到我的答案。
“读史明智”
知道自己被那些“极客”骗了之后，终于有了自己的答案。往后 我不会再与这些人去争什么正统与否，或者什么哲学。我才明白，这些自以为是“技术大佬”的人，根本不懂Unix哲学，知道的东西非常的浅，与这种人交谈也只能浮于表面，全是些片面的歪理与伪史。
我若对一件有疑问，我先读其史，我知道其发展规律之后，我就可以自己回答自己的问题。绝不是从他人口中得知。
所以到这里，其实我的看法是，搞Linux,Unix ,BSD,Windows,这些人其实是工程师（也是一群科学家）。是这些工程师为那些“极客”提供了一个拉屎的机会。而不是什么“极客”自带什么天赋。
事务背后的发展规律，以及意向，在明晓其哲学后，都了解得非常自然。
知道这些伟大的事务的发展脉络之后，也知道自己想做成什么事，应该怎么做了。
读书笔记
《UNIX编程艺术》
理曼德
220个笔记
第五章 序 Preface
- 2024/01/01 发表想法
是我
原文：如果你是个初级或者中级水平的 Unix 用户，但是没什么开发经验，想学习在 Unix下如何高效地设计软件时，可以看看这本书。
第六章 Part Ⅰ Context
- 软件工程算是此规则的一个例外：技术变革如此之快，软件环境日新月异，软件技术文化暂如朝露。然而，例外之中也有例外。确有极少数软件技术被证明经久耐用，足以演进为强势的技术文化、有鲜明特色的艺术和世代相传的设计哲学。
- 从Unix诞生之日起，各种信誓旦旦的预言就伴随着它，说Unix必将衰败，或者被其它操作系统挤出市场。可是在今天，化身为Linux、BSD、Solaris、MacOS X以及好几个其它变种的Unix，却显得前所未有的强大。
- 贝尔实验室的Dick Hamming[插图]在1950年代便树立了此信条：尽管计算机稀缺昂贵，但是开放式的计算模式，即客户可以为系统写出自己的应用程序，这一点势在必行，因为“用错误的方式解决正确的问题总比用正确的方法解决错误的问题好”。
- Unix API几乎就可以作为编写真正可移植软件的硬件无关标准。
- 那些夸夸其谈Unix技术优越性的家伙一般不会提到Unix的终极法宝、它赖以成功的原因：Unix Hack的趣味。
- Unix哲学说来不算是一种正规设计方法。它并不打算从计算机科学的理论高度来产生理论上完美的软件。那些毫无动力、松松垮垮而且薪水微薄的程序员们，能在短短期限内，如同神灵附体般造出稳定而新颖的软件——这只不过是经理人永远的梦呓罢了。
- Unix哲学（同其它工程领域的民间传统一样）是自下而上的，而不是自上而下的。
- (i)让每个程序就做好一件事。如果有新任务，就重新开始，不要往原程序中加入新功能而搞得复杂。
- (ii)假定每个程序的输出都会成为另一个程序的输入，哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。 (ⅲ)尽可能早地将设计和编译的软件投入试用，哪怕是操作系统也不例外，理想情况下，应该是在几星期内。对拙劣的代码别犹豫，扔掉重写。 (iv)优先使用工具而不是拙劣的帮助来减轻编程任务的负担。工欲善其事，必先利其器。 后来他这样总结道（引自《Unix 的四分之一世纪》(A Quarter Century of Unix [Salus])）： Unix哲学是这样的：一个程序只做一件事，并做好。程序要能协作。程序要能处理文本流，因为这是最通用的接口。 Rob Pike，最伟大的C语言大师之一，在《Notes on C Programming》中从另一个稍微不同的角度表述了Unix的哲学[Pike]： 原则1：你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急于胡乱找个地方改代码，除非你已经证实那儿就是瓶颈所在。 原则2：估量。在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。 原则3：花哨的算法在n 很小时通常很慢，而n通常很小。花哨算法的常数复杂度很大。除非你确定n总是很大，否则不要用花哨算法（即使n很大，也优先考虑原则2）。
- ：一个程序只做一件事，并做好。程序要能协作。程序要能处理文本流，因为这是最通用的接口。
- 原则1：你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急于胡乱找个地方改代码，除非你已经证实那儿就是瓶颈所在。原则2：估量。在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。原则3：花哨的算法在n 很小时通常很慢，而n通常很小。花哨算法的常数复杂度很大。除非你确定n总是很大，否则不要用花哨算法（即使n很大，也优先考虑原则2）。原则4：花哨的算法比简单算法更容易出bug、更难实现。尽量使用简单的算法配合简单的数据结构。原则5：数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法[插图]。原则6：没有原则6。
- 11.缄默原则：如果一个程序没什么好说的，就沉默。
- 12.补救原则：出现异常时，马上退出并给出足够错误信息
- 15.优化原则：雕琢前先要有原型，跑之前先学会走。
- 要编制复杂软件而又不至于一败涂地的唯一方法就是降低其整体复杂度
- 永远不要去吃力地解读一段晦涩的代码三次。第一次也许侥幸成功，但如果发现必须重新解读一遍——离第一次太久了，具体细节无从回想——那么你该注释代码了，这样第三次就相对不会那么痛苦了
- 简单、文本化、面向流、设备无关的格式。在经典的Unix下，多数程序都尽可能采用简
- Unix中，文本流之于工具，就如同在面向对象环境中的消息之于对象
- 。GUI 工具包的观感时尚来去匆匆，而光栅操作和组合却是永恒的。
- 另一个方法是将应用程序分成可以协作的前端和后端进程，
- 2024/01/01 发表想法
java
原文：很快，庞大臃肿变成了业界标准，每个人都在使用臃肿不堪、bug 极多的软件，连软件开发人员也不敢敝帚自珍。
- 很快，庞大臃肿变成了业界标准，每个人都在使用臃肿不堪、bug 极多的软件，连软件开发人员也不敢敝帚自珍。
- 出于充分考虑透明性和显见性的目的，还应该提倡接口简洁，以方便其它程序对其进行操作——尤其是测试监视工具和调试脚本
- 大多数软件禁不起磕碰，毛病很多，就是因为过于复杂，很难通盘考虑。如果不能够正确理解一个程序的逻辑，就不能确信其是否正确，也就不能在出错的时候修复它
- 程序越简洁，越透明，也就越健壮。
- Unix中最古老最持久的设计原则之一就是：若程序没有什么特别之处可讲，就保持沉默。行为良好的程序应该默默工作，决不唠唠叨叨，碍手碍脚。沉默是金。
- 雕琢前先得有原型，跑之前先学会走
- 先制作原型，再精雕细琢。优化之前先确保能用
- 所有的Unix哲学浓缩为一条铁律，那就是各地编程大师们奉为圭臬的“KISS”原则：[插图]Unix 提供了一个应用KISS 原则的良好环境。本书的剩余部分将帮助你学习如何应用这个原则
- 用C编写前，先用解释性语言搭建原型。
- 过滤时，不需要丢弃的信息决不丢。
- 软件设计和实现应该是一门充满快乐的艺术，一种高水平的游戏。
- 97%的时间里，我们不应考虑蝇头小利的效率提升：过早优化是万恶之源
第七章 2 历史——双流记 History：A Tale of Two Cultures
- 性能的局限不仅成就了经济性，而且鼓励了设计的简约
- Lions的书是地下出版界轰动一时的大事。由于侵犯版权等诸如此类的问题，该书不能在美国出版，所以大家就你拷给我、我拷给你。我也有一份拷贝，至少是第六手了。在那个时代，若没有Lions的书，你就当不成内核黑客。
- 大多数 Unix 支持者都认为 AT&T 的拆分是个好消息。我们原以为，在拆分后的AT&T、Sun公司及效仿Sun的小公司中，我们看到了一个健康的Unix产业核心——利用基于低廉的68000芯片的工作站——能够挑战并最终打破压迫在计算机行业上的垄断者——IBM。
- 几家小公司试图在PC机上支持Unix，但都资金不足，仅专注于将产品出售给开发者和工程师，从未关注微软所瞄准的商用和家庭市场。
- 这是条大新闻，因为这意味着占据主导地位的Intel家族终于有了一款无需作出痛苦妥协就能运行Unix的微处理器。对Sun公司和其它工作站厂商来说，这真是不祥之兆，可惜它们并未觉察到。
- 1970年代的Unix 黑客先锋们人近中年，步履开始蹒跚。
- 过去的IBM垄断让位于现在的微软垄断，而微软设计糟糕的软件像浊流一样，围着我们越涨越高
- Torvalds还说，要是早知道有BSD项目，他就会加入BSD组而不是自己做一个。但是386BSD直到1992年早些时候才下线，而此时Linux第一版已经发布好几个月了。
- Berkeley
- 这一点极大地吸引了大多数黑客，他们虽然早就反感RMS的言辞，但他们的怀疑论一直缺个有影响力或者令人信服的代言人。
- 或者，换句话说，低档的硬件只要数量足够，就能爬上性能曲线而最终获胜
第八章 3 对比：Unix哲学同其他哲学的比较 Contrasts：Comparing the Unix Philosophy with Others
- 在Unix中，一组程序设计时不仅要尽量考虑相互协作，而且要考虑和未知程序的协作。
- （例如，掌控了 Word 程序的宏病毒可以格式化硬盘）；依赖大量的代码，如整个shell和GUI，这样任何代码的bug或对代码的成功攻击都可以威胁到整个系统
- 彻头彻尾的反Unix系统，让所有文件格式都采用不透明的二进制格式，后者要用重量级的工具才能读取和编辑。
- 彻头彻尾的反 Unix 系统，就是没有 CLI，没有脚本编程能力——或者，存在 CLI不能驱动的重要功能
- 人们常说，Unix是程序员写给程序员的——这个目标用户群在界面复杂度的承受力方面是出了名的。
- 就是一个自认为比你自己更懂你在干什么的操作系统，然后雪上加霜的是，它还做错了。
- 2024/01/08 发表想法
win
原文：彻头彻尾的反Unix系统，不可能进行轻松编程。
- 彻头彻尾的反Unix系统，不可能进行轻松编程。
- Macintosh的统一性理念非常强大，我们上面讨论过的其它设计方案要么受其影响，要么就无人问津。
- 假设你已经有 Macintosh 机器，那么晋级为开发者的代价一向不高。因此，尽管界面相当复杂，Mac 很早也形成了一种浓厚的玩家文化。开发小工具、共享软件和用户支持软件的传统一直非常盛行。经典的 MacOS 已
- 同时，像Linux这样的前沿Unix也开始从MacOS中借鉴一些理念，如文件属性（资源分支的泛化）
- 套接字编程没有类似Unix那种“一切皆是文件句柄”的统一数据对象，因此在Unix中很简单的多道程序设计和网络应用到NT下则要牵涉更多基础性概念
- Unix的系统配置和用户配置数据分散存放在众多的dotfiles（名字以“.”开头的文件）和系统数据文件中，而NT则集中存放在注册表中。
- Cygwin允许C程序既可以使用Unix API又可以使用原生API，许多为形势所迫不得不使用Windows的Unix黑客在Windows系统上安装的第一个程序就是Cygwin。
- 竞争者的相继倒下，微软转而青睐内部开发的战略，开始向外界隐藏 API，开发工具也越来越昂贵。早在Windows 95时期，微软就要求将保密协议作为购买专业级开发工具的一个条件。
- Linux并不含任何来自原始Unix源码树的代码，但却是一个依照Unix标准设计、行为像Unix的操作系统。
- Linux 的用户和开发者不断自我调整来消弭非技术用户对 CLI 的恐惧。他们比旧学派Unix、甚至同时代专有Unix更看重GUI及其工具的开发。其它开源Unix也在发生同样变化，变化虽小，但意义深远。
- 但是，Linux 给出“因为没安装对应的软件，所以打不开文件”这种Mac式诊断之时，就是Linux不再是Unix之日。
- 只有独立于Unix传统外的Microsoft Windows系统还算是一个真正活着的竞争对手。
- Windows在这些领域具有严重缺陷却逃脱了惩罚，这仅仅因为它们在连网变得真正重要以前就形成了垄断地位，并拥有一群已经对机器经常崩溃和无数安全漏洞习以为常的用户。
- 除了拥有与生俱来的服务器操作系统体系优势外，Unix一直不明确界定自己的目标受众。Unix的设计者和实现者从不自认为已经完全清楚Unix的所有潜在用途
第九章 Part Ⅱ Design
- 软件设计有两种方式：一种是设计得极为简洁，没有看得到的缺陷；另一种是设计得极为复杂，有缺陷也看不出来。第一种方式的难度要大得多。
- 早期的Unix程序员擅长模块化是因为他们被迫如此。操作系统就是一堆最复杂的代码。如果没有良好的架构，操作系统就会崩溃。
- 如果试着用纯人类语言描述设计（不许摘录任何源代码），能否把事情说清楚？
- 实际上，一些最有能力的开发者，一开始总是定义接口，然后编写简要注释，对其进行描述，最后才编写代码——因为编写注释的过程就阐明了代码必须达到的目的。
- 在模块很小时，bug发生率也出乎意料地增多，这在大量以不同语言实现的各种系统中均是如此。
- 一书中对正交性以及如何达到正交性有精彩的讨论。正如该书所指出的，正交性缩短了测试和开发的时间，因为那种既不产生副作用也不依赖其它代码副作用的代码校验起来要容易得多——需要测试的情况组合要少得多。
- 无垃圾，无混淆”(No junk，no confusion)
- ●如果有大量重复的样板代码，是不是可以用单一的更高层表现形式生成这些代码、然后通过提供不同的细调选项生成不同个例呢？
- 如果试探法以增加代码复杂性为代价，根据会获得的性能来判断一下是否值得这么做——不要猜想可能产生的性能差异，在做出决定前应该实际衡量一下。
- 限制不仅提倡了经济性，而且某种程度上提倡了设计的优雅
- 禅教导我们：依附导致痛苦；软件设计的经验教导我们：依附于被人忽略的假定将导致非正交、不紧凑的设计，项目不是失败就是成为维护的梦魇
- 另一方面，如果程序完全自底向上设计，很可能发现自己做了许多与应用逻辑无关的工作——或者，就像你想要造房子，却仅仅只设计了一堆砖头。
- (a)能够精确预知程序的任务，(b)在实现过程中，程序规格不会发生重大变化，(c)在底层，有充分自由来选择程序完成任务的方式
- 一方面以自顶向下的应用逻辑表达抽象规范，另一方面以函数或库来收集底层的域原语，这样，当高层设计变化时，这些域原语仍然可以重用。
- 如果你知道自己在做什么，三层就足够了；但如果你不知道自己在做什么，十七层也没用。
第一十章 5 文本化：好协议产生好实践 Textuality：Good Protocols Make Good Practice
- 2024/01/08 发表想法
是中国人发明了，而不是人类，更不是西方。
原文：众所周知，人类几千年前就已经发明了算盘之类的计算设备。
- 2024/01/08 发表想法
？旧约才几百年？ 有没有听过什么叫 驿站？
原文：，人类第一次使用通用计算机协议是在《旧约》中——当时摩西用控制海中止了埃及人的进程。
- ，人类第一次使用通用计算机协议是在《旧约》中——当时摩西用控制海中止了埃及人的进程。
- 于.newsrc文件有可能变得很大，某些新型阅读器（GNOME的Pan阅读器）就使用对速度优化的专用格式来避免启动等待。但对其他实现者而言，文本表达在1980年看起来就是很好的折衷方案，而且随着机器速度的提高和存储器价格的下降，这种选择现在愈发显得明智
- 事实上，Microsoft版CSV是一个如何设计文本文件格式的典型反面例子。
- MIME（多用途网际邮件扩充协议，Multipurpose Internet Mail Extension）提供了在RFC 822格式信息中嵌入类型化二进制数据的方法（在网上搜索以上这些名称的任何一个都可以找到相关标准）。
- XML 最严重的问题是无法很好和传统的 Unix 工具协作。读取XML 格式的软件需要XML解析器，这就意味着需要庞大复杂的程序。
- 这种格式可读性好，设计得不错，但和XML一样，不能与grep(1)或常规Unix脚本工具很好地配合使用。
- 所有现行各种编程语言的HTTP和Web访问程序库的基础代码都可以支持数据库的查询和更新。
- XML-RPC 非常具有 Unix 精神（其作者宣称在二十世纪七十年代通过阅读原始的Unix源码学会了编程）
第一十一章 6 透明性：来点儿光 Transparency：Let There Be Light
- 软件开发者喜欢代码本身（用户不可见部分）的这些品质，因为他们经常需要对代码有很好理解后才能进行修改和调试。同时，如果程序的设计使内部数据流程非常容易理解，则这个程序更不可能因设计者没有注意到的不良交互而崩溃，更可能优雅地向前发展（包括适应新维护者接手的变化）。
- 优雅是力量与简洁的结合。优雅的代码事半功倍；优雅的代码不仅正确，而且显然正确；优雅的代码不仅将算法传达给计算机，同时也把见解和信心传递给阅读代码的人。
- 。学习编写透明的代码是学习如何编写优雅代码的第一关，很难的一关——而关注代码的可显性则帮助我们学习如何编写透明的代码。优雅的代码既透明又可显。
- Emacs Lisp库是可显的，但却不透明。要获得足够的知识来领会一件事很容易，但要理解整个系统却相当
- 请记住：编写透明、可显的系统而节省的精力，将来完全可能就是自己的财富。
- 不要让调试工具仅仅成为一种事后追加或者用过就束之高阁的东西。它们是通往代码的窗口：不要只在墙上凿出粗糙的洞，要修整这些洞并装上窗。如果打算让代码一直可被维护，就始终必须让光照进去。
- 预处理器、解析器、代码生成器、汇编器和链接器
- 这个例子揭示的设计模式是驱动程序应该具备监控开关，这些监控开关仅仅（但足够了）揭示组件间的文本数据流。如同fetchmail的-v选项一样，这些选项也不是事后追加，而是为了可显性才设计进来的
- 这种“一个大文件”的方法还导致了臭名昭著的“注册表蠕变”现象
- 要为透明性和可显性而设计，就必须运用各种计策来保持代码的简洁，也必须专注代码同其他人交流的方式。
- 禅的一个主要教导是，通常我们都透过源于欲望的偏见和成见的迷雾观察世界。要开悟，我们必须遵循禅的教导，不仅要“去欲望，少依恋”，还要“如实见”——不要让偏见和成见蒙住了眼。
- 面向对象的设计并非必然是过度复杂的设计，但我们却发现事实往往如此。
- 程序员经常建造过分精细的抽象城堡，这一倾向的近亲是过度保护底层细节。
- 文本化器甚至能够对损坏的二进制对象进行读写操作，尽管很难，但值得去做。第一，可以对压力测试软件生成受损测试用例；第二，可以让紧急修复更容易
- 健壮原则就非常清楚了。简洁加上透明，降低了费用，缓解了每个人的压力，让人们从中解放出来，更多地投入到新问题中，而不是总为旧错误擦屁股
- “拿不准，用穷举”
- 实际上，跟编写最终用户文档相比，Unix程序员常常更善于编写开发者手册。
第一十二章 7 多道程序设计：分离进程为独立的功能 Multiprogramming：Separating Processes to Separate Function
- 管道线的成员除了终止外（在这种情况下，前一阶段的程序会在下一个写操作时得到SIGPIPE 信号）不可能回传控制信息。
- 子程序通过连接到标准输入和标准输出的管道，交互地和调用程序收发数据。
- 让主进程支持命令行开关或环境变量来允许调用者设置自己的从进程命令。
- 如果发送的字节已经到达，但是接收的机器却没有ACK确认，发送机器的TCP/IP栈将超时。因此得到一个错误不一定意味着字节没有到达；接收端可能已经用上了这些字节。
- 线程开发者已经觉察到这个问题。最近的线程实现和标准则体现了对提供线程本地存储的更多关注，其目的是限制共享全局地址空间所产生的问题。
第一十三章 8 微型语言：寻找歌唱的乐符 Minilanguages：Finding a Notation That Sings
- 2024/01/13 发表想法
语法糖不要用太多，不然别人读你代码的时候怎么想。
原文：这类东西的传统术语是语法糖(syntactic sugar)；与之联系在一起的一段格言是非常著名的俏皮话：“syntactic sugar causes cancer of the semicolon”（语法糖导致分号癌）[插图]。事实上，必须谨慎使用语法糖，以免造成的晦涩多于帮助。
- 这类东西的传统术语是语法糖(syntactic sugar)；与之联系在一起的一段格言是非常著名的俏皮话：“syntactic sugar causes cancer of the semicolon”（语法糖导致分号癌）[插图]。事实上，必须谨慎使用语法糖，以免造成的晦涩多于帮助。
- Emacs编辑器是最著名、最有效的现代实例。
- Java 和 JavaScript 这样的语言已被明确地沙盒化(sandboxed)——也就是说，它们对环境的访问是受限的，目的不仅是为了简化设计，而且是为了防止有bug或恶意代码执行潜在的破坏性操作。
- C 语言在数组初始化列表的末尾允许额外增加一个逗号，使得数组初始化的编辑和机器生成都更加容易。反例则是各种HTML阅读器的过分挑剔，即使遇到极小的嵌套错误也会导致大段文档被悄悄略过。
- 很容易说明和实现宏扩展，而且可以用宏扩展实现很多聪明的技巧。早期的设计者似乎都受到了使用编译程序的影响。在汇编程序中，宏经常是架构程序唯一的可用方法。
第一十四章 9 生成：提升规格说明的层次 Generation：Pushing the Specification Level Upwards
- 程序员束手无策……只有跳脱代码，直起腰，仔细思考数据才是最好的行动。表达是编程的精髓
- 尽可能少干活；让数据塑造代码；依靠工具；把机制从策略中分离。
- 家级Unix程序员要学会迅速自动地看出这些可能性。建设性的懒惰是大师级程序员的基本美德之一。
第一十五章 10 配置：迈出正确的第一步 Configuration：Starting on the Right Foot
- 如果程序是某种语言的解释器，那么人们就期望运行控制文件只是以该语言语法写成的并在启动时执行的命令文件。这是一条重要原则，因为Unix传统强烈提倡各种类型的程序都作为专门语言和微型语言来设计。此种类型文件的著名例子包括各种Unix命令的shell和Emacs可编程编辑器。
- fetchmail 具有一个精心设计的命令行选项集，但重复了大部分（但不是全部）.fetchmailrc所能够表达的内容。
- 本章所描述的约定都不是绝对的，但是违反这些约定会增加用户和未来开发者的磨合成本。如果必须打破规则，就放手去做——但在做之前要确信自己完全知道为什么要这样做。如果确实要打破规则，必须确保常规方法进行的尝试都非常明显地失败了，同时保证遵循补救原则给出了正确的错误反馈。
第一十六章 11 接口：Unix环境下的用户接口设计模式 Interfaces：User-Interface Design Patterns in the Unix Environment
- 2024/01/13 发表想法
存在不一定合理，这是个伪命题。
原文：Unix有几种竞争的接口风格。存在即是合理；它们为不同的情形而优化。通过理解任务和接口风格之间的配合，你将要学习到如何为你的工作选择正确的风格。
- Unix有几种竞争的接口风格。存在即是合理；它们为不同的情形而优化。通过理解任务和接口风格之间的配合，你将要学习到如何为你的工作选择正确的风格。
- 继续先前的编辑器例子，这就意味着如果必须实现一个内嵌的编辑器，编辑命令最好是那些著名通用编辑器命令集的一个子集。
- 2024/01/13 发表想法
因为mac和win用户，培养的用户习惯就是点击
原文：另一方面，许多非技术型的数据库用户不愿记忆SQL语法，而宁愿选择一个相对不简洁、表现力较差的全屏或GUI接口
- 另一方面，许多非技术型的数据库用户不愿记忆SQL语法，而宁愿选择一个相对不简洁、表现力较差的全屏或GUI接口
- 2024/01/13 发表想法
Unix要给用户一个自学习的过程，其实Win一开始也没有，但是因为足够简单，这么多点培养了这样的GUI操作习惯。 而Unix，一开始的设定就是为专业人士服务。 这点很像 京东现在也想走 拼多多的路线，但水土不服。
原文：实质的问题是他们已经假定所有的用户总是入门级的，然后非难Unix，因为Unix并不迎合这种模型。
- Unix程序员继承了一个强烈的偏爱，愿意使接口富有表现力和可配置。就像其他传统的程序员一样，他们考虑怎样将他们的接口同目标受众相匹配——但是在处理目标受众不确定性时有所不同。
- 2024/01/13 发表想法
所以这其实是本末倒置，技术理应当为需求服务。 例如：我写一个用户的日程软件，用户只需要能够点击使用即可。你偏要告诉用户，需要先读一下官方文档，然后配置了软件，然后你才开始用。
原文：这种思路导致了对于标准一致性组成方面一个更苛刻的态度，不完全的支持是难以容忍的。也许一个Macintosh或Windows开发者会说“我们不需要支持标准的所有特征；多数用户不会在意，而且对他们来说太复杂了”，而一个Unix开发者可能会说“我们并不知道是不是有人永远都不会需要这种功能或者选项，所以我们必须支持它。”
- 这种思路导致了对于标准一致性组成方面一个更苛刻的态度，不完全的支持是难以容忍的。也许一个Macintosh或Windows开发者会说“我们不需要支持标准的所有特征；多数用户不会在意，而且对他们来说太复杂了”，而一个Unix开发者可能会说“我们并不知道是不是有人永远都不会需要这种功能或者选项，所以我们必须支持它。”
- cantrip 接口设计模式是其中最简单的。没有输入，没有输出，只被调用一次，产生退出状态数值。
- 典型地，一个 spooler/daemon 系统具有四个部分：一个作业发布者、一个队列列表器，一个作业撤销功能和一个带 spooling 的守护进程。实际上，前面三个部分就是明显的线索，表明了在它们幕后某处一定有个后台spooler发送器。
第一十七章 12 优化 Optimization
- 过早优化乃万恶之源。
- 因此在这里，“小即是美”的建议比以往更有用，尤其是考虑到核心数据结构必须留在最快的缓存里。该建议也同样适用于代码；通常，指令加载要比执行花费的时间更多。
- Unix的模式更倾向于强大的服务器操作。提出低延迟价值，部分也是因为即使是新兴的Unix开发者有时也继承了旧的文化而偏向于吞吐量的优化。但是，现在世道变了。
- ，(a)对可以共享启动开销的事务进行批处理，(b)允许事务重叠，和(c)缓存。
- Emacs Lisp以.el 和.elc 文件使用同样的技术。这种技术能起作用，是因为缓存的读写访问都通过一个简单的程序来实现。
第一十八章 13 复杂度：尽可能简单，但别简单过了头 Complexity：As Simple As Possible，but No Simpler
- 2024/01/13 发表想法
Windows在使用上确实是 又蠢又简单，但是在设计上，没有艺术根据。
原文：在第1章末，我们概括Unix的哲学为“Keep It Simple，Stupid！”。贯穿整个“设计”部分的不变主题就是尽可能保持简单设计的重要性。但什么是“尽可能的简单”？又如何断定？
- 在第1章末，我们概括Unix的哲学为“Keep It Simple，Stupid！”。贯穿整个“设计”部分的不变主题就是尽可能保持简单设计的重要性。但什么是“尽可能的简单”？又如何断定？
- （对Unix程序员是难以想象的，但在别的系统中普遍存在的一个拙劣的例子，就是一个缺乏全局替换操作的编辑器。）尽管这种设计失误实在很普遍，但传统上，却没有一个名称。我们将称之为“manularity”（人力尺度）陷阱。
- 而在New Jersey哲学下，系统调用会返回一个错误表明已被中断，用户必须重新执行——这实现起来非常简单，但编程接口却较难使用。
- 良好品味和工程判断力要求，情况不同，则答案不同。重要的是要培养斟酌每一个设计的习惯。正如我们在讨论软件模块性之前的建议一样，复杂度的算盘必须打好。
- “什么是工程目标”的夹杂着简单即美的问题，也会牵扯到人们是不是足够聪明。
- Unix世界最常见的情况就是从编辑器内运行一个C编译器，捕捉其错误信息，从而无需离开编辑器就能够跳至任何出错地点。
- 2024/01/14 发表想法
曾经因为不会退出vim，然后把系统格了
原文：vi 使初学者饱受挫折，这是由于其简明扼要、单键击发式命令所致。它有一个模式界面——或者处于命令模式，或者处于文本插入模式。在文本插入模式，可用的命令仅仅只有使用ESC键退出该模式以及（在新版本中）光标移动键。在命令模式，键入的文本会被解释成各种命令，而且还会给文本内容带来奇怪的（可能是毁灭性的）后果。
- vi 使初学者饱受挫折，这是由于其简明扼要、单键击发式命令所致。它有一个模式界面——或者处于命令模式，或者处于文本插入模式。在文本插入模式，可用的命令仅仅只有使用ESC键退出该模式以及（在新版本中）光标移动键。在命令模式，键入的文本会被解释成各种命令，而且还会给文本内容带来奇怪的（可能是毁灭性的）后果。
- Emacs的设计者建立了一个可编程的编辑器，[插图]可以将与任务相关的知识定制进去，以针对数以百计的不同类特殊编辑任务。设计者赋予了它可以驱动其它工具的能力。结果就是Emacs支持在一个共享的上下文环境中处理所有的文本操作——文件、邮件、新闻、调试符号。
- 2024/01/14 发表想法
啊？
原文：在2003年中期，在Intel体系的机器上，vim有1500KB，而GNU Emacs是900KB。在这900KB中还有一大堆选择和偶然复杂度。
- 在2003年中期，在Intel体系的机器上，vim有1500KB，而GNU Emacs是900KB。在这900KB中还有一大堆选择和偶然复杂度。
- 所以Ken不会被受限去写一个过时产品。想想Pascal因为没有足够的时间写封短信而抱歉信写长了。
- 而锻炼良好的判断力和品味恰好是软件设计者所追求的。正如曹洞禅所说，行程才是目的；顿悟在每日的实践中
第一十九章 Part Ⅲ Implementation
- 但现在再没有“小型系统”了，至少在主流应用编程中没有了。在今天的条件下，自动化内存管理（并以使用更多的时钟周期和内存为代价而减少一个数量级的bug）的实现语言更有意义。
- C 语言最佳之处是资源效率和接近机器语言。而最糟糕的地方是其编程简直就是资源管理的炼狱。
- 2024/01/14 发表想法
所以其不适合于跨平台，如果需要跨平台，则需要大量的辅助 这点让我明白了，服务器运维脚本不能用shell写。
原文：shell 的最佳之处在于书写小型脚本非常自然快捷。最糟之处在于大型 shell脚本必须依靠大量辅助命令，而这些辅助命令不一定在所有目标机器上都表现一致甚至不一定存在。要在大型shell脚本中分析依赖关系并不容易。
- shell 的最佳之处在于书写小型脚本非常自然快捷。最糟之处在于大型 shell脚本必须依靠大量辅助命令，而这些辅助命令不一定在所有目标机器上都表现一致甚至不一定存在。要在大型shell脚本中分析依赖关系并不容易。
- 总结：Python的最佳之处在于它鼓励清晰、易读的代码，易学易用，又能够扩展到大型项目。最糟之处在于，不仅相对于编译语言，而且相对于其它脚本语言，它也是效率低下、速度缓慢的。
- 2024/01/14 发表想法
这一笔，让我明白了为什么Java一直在做Web。
原文：ava似乎在计算业中发现了一个安全的生存空间，让“servlets”在网页应用服务器的内部运行。Java 也经常用于不和数据库或网页服务器直接相连的企业内部编程。它也已经成为Microsoft的ASP/COM平台和Perl CGI的主要竞争者。
- ava似乎在计算业中发现了一个安全的生存空间，让“servlets”在网页应用服务器的内部运行。Java 也经常用于不和数据库或网页服务器直接相连的企业内部编程。它也已经成为Microsoft的ASP/COM平台和Perl CGI的主要竞争者。
- Freenet通过提供一个虚拟空间来达到这些目标，在这个虚拟空间中发布的文档不与任何具体的机器相关。发布信息和Freenet内部数据索引通过网络进行复制分发，即使是Freenet管理员在任何给定时间里也不清楚所有的物理文档会在哪里。Freenet浏览者或信息提交者的隐私通过强密码系统加以保护。Java 作为这个项目的上上之选至少有两个理由。首先：项目目标非常重视最广泛的实现兼容性，因此Java的高度可移植性成为一个主要优势。其次：这个项目的本质促使网络API变得非常重要，而Java恰好内置了一个强大的API。
- 2024/01/14 发表想法
这部分多数为 c++没有提供很好支持的Web领域，而c++的性能，是Java难企及的。
原文：C++被Java夺取了些许阵地。
- 2024/01/14 发表想法
当Next.js 说要内嵌 SQL时， PHP则已经全赢。 多年下来的前后端分离架构又被怀疑了。 笑死
原文：PHP正在侵蚀网络开发，挑战Perl CGI（以及ASP和服务器端Java），但是几乎从未使用在单机编程中。
第二十章 15 工具：开发的战术 Tools：The Tactics of Development
- 2024/01/14 发表想法
Emacs和Vi有满足这一点 用lazycat的话来说就是 达到一种 “心流合一”的状态。
原文：Unix作为一个良好的开发环境长期以来享有盛誉。许多程序员为程序员而写的工具使它配备精良。这些工具自动完成了不少琐碎的工作，从而让人心无旁骛地专注于开发中最重要（也是最享受）的部分——设计。
- Unix作为一个良好的开发环境长期以来享有盛誉。许多程序员为程序员而写的工具使它配备精良。这些工具自动完成了不少琐碎的工作，从而让人心无旁骛地专注于开发中最重要（也是最享受）的部分——设计。
- 两款编辑器完全统治了Unix编程界。两者都有几个次要的变种实现，有一个标准版本，可以毫无疑问地在任何现代 Unix 系统上找到。它们是 vi 和Emacs
- 2024/01/14 发表想法
veni vidi vici
原文：vi这个名字是“visual editor （可视编辑器）”的缩写，发音为/vee eye/（不是/vie/并且绝对不是/siks/！）。
- 2024/01/14 发表想法
Emacs的优势是需要投入一定时间，搭配自己的工作习惯。 可以将Emacs配置成任何编辑器的操作习惯，也可以将emacs配置成自己独立操作习惯。 还有就是Emacs as Shell。
原文：在早些时候讨论编辑器和可能复杂度时，我们注意到许多人都认为Emacs太过沉重。然而，花时间学习它可以获得很大的生产力回报。Emacs支持许多威力强大的编辑模式，能够为输入各种编程语言和标记语言提供语法上的帮助。我们在本章稍后部分可以看到Emacs 是如何同其它开发工具组合起来，从而获得并不逊于常规 IDE（在许多方面甚至超过）的能力。
- 多数预装GNU make的各种Unix都同时支持GNU Emacs；如果你的Unix也是如此，那通过Emacs的信息文档系统可能会找到完整的make在线手册。
- 有一个老Unix笑话，输入“make love”，输出是“Don’t know how to make love”。
- 为了解决这些问题，需要能够保留项目历史，并且加上注释来解释它。如果项目不止一个开发者，同时还需要一种机制能够确定开发者不会覆盖彼此的版本。
- Unix 存在一个提供工具来帮助完成这些任务的长期传统。多数开源 Unix 都拥有威力巨大的gdb（也是一个FSF项目）支持C和C++调试。
- 能
- 2024/01/14 发表想法
确实
原文：牢记Unix哲学。将时间花费在设计质量上，而不是低层次的细节上，尽可能地自动化一切——包括运行期调试的细节工作。
- 牢记Unix哲学。将时间花费在设计质量上，而不是低层次的细节上，尽可能地自动化一切——包括运行期调试的细节工作。
- 2024/01/14 发表想法
我刚好2岁
原文：在本书创作（2003年年中）期间，Emacs还不支持Tcl的调试。Tcl的设计似乎决定了这种特性不太可能加入到Emacs之中。
- 如果发现在低层次的机械开发部分花费了太多时间的话，先站住。应该运用Unix哲学。使用工具自动化或半自动化地完成任务。
- 作为对所有继承的回报，将自己的解决方案作为开源软件放置在互联网上。帮助把程序员同行们从蛮干中解放出来。
- 2024/01/14 发表想法
时过境迁，物是人非。
原文：本章稍早时，我们断言Emacs具备类似那些常规集成开发环境的能力，而且只会更强。现在，已经有足够的事实证明所言非虚。可以在Emacs中运行整个的开发项目，敲几下键盘就可以完成底层的技术性细节，从而减少了不断切换环境的脑力开销和那种不连贯的感觉。
- 使用Emacs Lisp，可以调整、定制以及增加与任务相关联的知识。同时，比起常规的IDE来说，Emacs在支持混合语言开发上做得更好。
- 通过密切注意开源社区，可以从千万的同行、以及面对同样挑战的Emacs使用开发者中受益。这更有效——也更有趣。
第二十一章 16 重用：论不要重新发明轮子 Reuse：On Not Reinventing the Wheel
- Unix的经验是，养成良好的习惯，尝试通过最少的新发明，组合现有组件以形成原型，而非匆忙地编写独立的、只能使用一次的代码。
- 浪费和重复工作相当普遍，尽管这种行为似乎既侵害代码生产者也侵害代码购买者的利益。为什么这种病态行为会持续存在？知道了原因，就走出了改正的第一步。
- 。代码处于崩溃和内存泄漏的痛苦之中，追下来又往往发觉祸根就是那个程序库，或者是某些他无法查看和修改的代码。小兵知道再追也许会追回到自己的代码，但是没有源代码，就算想追回到自己代码也是不可能的。
- 现在这不再好笑。小兵不仅仅同自己的经验缺乏斗争，也同由别人的粗心或者不胜任所制造的积压问题而斗争——这些问题他改不了，只能绕开。
- 千上万的小兵们，年复一年地随着年龄的增长，变得越来越愤世嫉俗，也越来越习惯那种系统。对于多数软件行业的现状，这就是巨大的时间、资本和人力资源浪费——这还没算上商家市场策略、管理缺乏竞争、不可能期限以及所有其它阻碍工作的压力因素。
- 在线常见问题解答(FAQ，Frequently Asked Questions)列表，以及相关的邮件列表或Usenet新闻组，也是良好软件的表征。这些都是一个鲜活、充实、有兴趣的社区已经围绕这个软件而成长起来的标志。网页上，最近的更新以及扩展的镜像站点列表也同样是可靠的标记，表明这个项目拥活跃的用户群体。荒废的软件包不可能有这种持续的投入，因为不值得。
- 2024/01/14 发表想法
我想知道，如果工作都没有省时间，而且花了很多时间，并且提升有限。
原文：作为Unix开发者，最有价值的时间投资方法之一就是，花时间在这些站点上去了解可以获得什么东西来重用。节省下来的编码时间就是自己的。
- 因此，在开源软件中，谁是版权所有者并不重要，但许可证条款却至关重要。
- 将作品置于开源许可证之下的人们往往并不是什么大企业，没有那些鸡蛋里面挑骨头的律师群照顾；他们只是一些个体或志愿群体，主要就是想发布他们的软件。
- 。但在缺少权威判例法的情况下，能做的99%就是明确承诺努力满足作者的要求；另外的或许可以（或许不能）通过咨询律师来达到保护自己的1%的额外努力，而这又有什么不同呢。
第二十二章 Part Ⅳ Community
- （任何）候选规范在被采用为互联网标准之前，必须得到实现，对操作的正确性以及众多独立方的互操作性必须得到测试，以及必须已经使用在要求越来越高的环境中。
- 2024/01/14 发表想法
这是非常正常的
原文：但是这个问题很严重，所以大多数在shell中稍重量级的编程都转移到诸如Perl、Python、Tcl等第二代脚本语言中完成。
- 但是这个问题很严重，所以大多数在shell中稍重量级的编程都转移到诸如Perl、Python、Tcl等第二代脚本语言中完成。
- 2024/01/14 发表想法
操你妈的微软
原文：微软拒绝在Windows中支持Java开发并试图以C＃来取代Java。●微软决定继续保留IE中对JDK 1.1版的小应用程序的支持。
- 2024/01/14 发表想法
Unix好死 将来的天下属于 Linux & BSD
原文：在2003年中期，Linux和其它开源Unix不但存在，并且已经证明了自身完全可以是出产高质量生产级软件的平台。现在开发者有了更好的选择，而不是依赖于为垄断而设计的短期商业决策。实施防御性设计——基于开放源码编程，便不会束手无策。
- 在2003年中期，Linux和其它开源Unix不但存在，并且已经证明了自身完全可以是出产高质量生产级软件的平台。现在开发者有了更好的选择，而不是依赖于为垄断而设计的短期商业决策。实施防御性设计——基于开放源码编程，便不会束手无策。
第二十三章 18 文档：向网络世界阐释代码 Documentation：Explaining Your Code to a Web-Centric World
- 2024/01/14 发表想法
Emacs Lisp有1000页的文档
原文：我从没见过一个愿意阅读17000页文档的人，如果有，我会杀了他，这样人的基因必须抹去。
- 愚弄读者，就是承认自己也是傻瓜。愚弄读者的文档同真正易于理解的文档大相径庭；前者偷懒而忽略了重要的东西，后者则要求深思熟虑以及不留情面的修订。
第二十四章 19 开放源码：在Unix新社区中编程 Open Source：Programming in the New Unix Community
- 软件工程的正统观念都是关于如何在重量级组织，例如企业和政府中，构建小型而管理紧密的团队。而实践却是紧密管理的大型团队。
- 2024/01/14 发表想法
其实我这是这样的，经常去赞赏开源工作者
原文：3.给贡献以表扬。如果不能够给合作开发者以物质奖励，就给予精神表扬。即使可以给予物质的奖励，也不要忘记人们往往是为展示才华而不是为钱努力工作。
- 代码中良好的注释可以帮助维护者理解代码。糟糕的则不然。
- ＃ifdef 和＃if 是最后一招，这通常是思路不当、产品过度差异化，无理由“优化”或是无用垃圾聚集的先兆。在代码中，它们就是诅咒。GNU 的/usr/include/stdio.h就是典型的悲剧。
- 拥有 FAQ 文件可以让你省很多力气。当关于项目的某个问题经常出现时，就加到FAQ 文件中；然后引导用户在发送问题或者错误报告之前首先阅读 FAQ 文件。一个发展良好的FAQ可以减少项目维护者一个数量级的负担，甚至更多。
- 2024/01/14 发表想法
github page
原文：如果试图围绕项目建立坚实的用户和开发者社区，那应该拥有一个项目网站。网站上需要包含如下一些标准的东西：
- 许可证被认为是涉及开源社区核心价值近似神圣的盟约，人们的情绪都变得非常激动。
第二十五章 20 未来：危机与机遇 Futures：Dangers and Opportunities
- 2024/01/14 发表想法
危机 就包含了 危险与机遇
原文：危机与机遇 Futures：Dangers and Opportunities
- 2024/01/14 发表想法
Solaris已经停止更新了，但是Linux & BSD 已经遍及全球。
原文：Plan 9尝试重做Unix，做更好的Unix。
- 我们已经走过了很长的路，但是我们还有更长的路要走。我们知道哪种商业模式在理论上管用，而且我们现在甚至可以指出一些零星的成功，展示了那些商业模式在实践中也确实运营良好；当然，现在我们必须显示那种模式可以可靠地运营更长的时间。
- 这些是经济问题。我们还有其它更政治化的问题，因为成功招徕敌人。
- 成为了网络和大铁块的守护者。我们潜在的要求是，如果想使用我们的软件，就必须学会像我们一样思考。
- 2024/01/14 发表想法
？你们的挑战？
原文：MacOS X拥有Unix的底层架构，并且在2004 年 Mac 开发者（虽然在某些方面有所斗争）进行了思想上的调整来学习注重内部架构的Unix美德。我们的挑战将是，相互地，吸纳Macintosh以用户为中心的美德。
- MacOS X拥有Unix的底层架构，并且在2004 年 Mac 开发者（虽然在某些方面有所斗争）进行了思想上的调整来学习注重内部架构的Unix美德。我们的挑战将是，相互地，吸纳Macintosh以用户为中心的美德。
- 2024/01/14 发表想法
我押注Unix会赢
原文：但我们总是可以重振旗鼓地王者归来。我们犯了错，但我们从错误中汲取了教训。我们的文化薪火相传；我们已经从早期的学院黑客、ARPANET 实验者、微机狂热者以及其它许多文化中汲取了精华。而开源运动已经复兴了我们早年的激情和理想，今天，我们的力量，我们的规模将远胜过去。迄今为止，打赌Unix玩家会输的人总是聪明一时糊涂一世。我们能赢——只要我们想赢。
第二十九章 附录D 无根的根：无名师的Unix心传 Rootless Root：The Unix Koans of Master Foo
- “当尊者Thompson发明Unix时，他并不理解它。随后他理解了，受益了，不再发明了。”“当尊者McIlroy发明管道时，他只知道它将传递软件，并不知道它能传播思想。”“当尊者Ritchie发明C时，他将程序员放到缓冲溢出、堆损坏和烂指针bug的地域中惩罚。”“说实话，这些尊者既瞎又蠢！”
- 2024/01/14 发表想法
至此，Emacs 不仅作为我的生活方式 Unix 更为我的生活方式
原文：无名师转向新门徒。“家猫也能欺负老虎”，无名师说，“但是猫叫永远比不过虎吼。”听到此，新门徒眼中一亮。
- 2024/01/14 发表想法
让我来续写“Unix禅道”
原文：无名师转向新门徒。“家猫也能欺负老虎”，无名师说，“但是猫叫永远比不过虎吼。”听到此，新门徒眼中一亮。
- 无名师转向新门徒。“家猫也能欺负老虎”，无名师说，“但是猫叫永远比不过虎吼。”听到此，新门徒眼中一亮。
来自微信读书
