Supertime的简约生活

原文作者：Dominic Humphries
原文链接：Linux is Not Windows
译者：sctronlinux
Linux != Windows
（ Linux 不是 Windows）
Derived works

如果你访问了这个页面，那么十有八九你是一个 Linux 的新用户，你正遇到许多关于如何由 Windows 转向 Linux 的困惑，这篇文章的目的正是向新手解释这个问题。由于这个大问题衍生出许多枝节，下面我将对此逐一进行讨论。
问题一：Linux 和 Windows 完全不一样
你一定会惊讶于有这么多人对 Linux 发出相似的抱怨，他们奔向Linux，希望找到一个免费的、开源版的 Windows。通常，这正是那些狂热的 Linux 使用者所告诉他们的那种状况。然而这却是个荒谬的期待。

人
们尝试 Linux 的原因不尽相同，但所有的原因都可以归结为一点：他们希望 Linux 会比 Windows
更优秀。正是出于这一点，Linux的低成本、更广阔的选择范围、高性能和高安全性——当然，还有许多其它的方面——被作为与 Windows
比较时的衡量标准。往往每一个开始尝试 Linux 的Windows 用户都是如此。

这正是问题之所在。

太多的人都忽
略了这样一个事实：从逻辑上讲，在保持某样东西与参考物体完全相同的前提下，将其做得更好是绝无可能的。正如一个完美的复制品将与它的母版毫无差异，但是
它不可能会超越原版。所以当你怀抱着 Linux 的使用方式该和使用 Windows 差不多的观念而尝试
Linux，并希望它能够做得更好，你便会不可避免地发现他们之间的不同，并且把这些不同之处看作是 Linux 的缺陷。

举一个简单的例子，让我们来想一想驱动程序的升级吧：通常的情况下，倘若我们要在 Windows 下升级某个硬件驱动，我们需要去硬件制造商的网站上找到并下载最新的驱动；然而在 Linux 下，我们只须简单地升级内核即可。

这意味着在 Linux 下，仅仅一次下载和升级便能提供所有适用的最新驱动，然而在 Windows 下我们却不得不浏览多个网站并分别下载升级程序。这是一个不同的过程。并且显然，这绝不会是一种糟糕的体验。然而却有很多人对此抱怨不停，只因为这不是他们习惯的方式。

或者从另一个更经常接触到的例子来看，想一想 Firefox ——开源软件最伟大的成功案例之一。这是一个席卷全球的浏览器。它是通过模仿 IE —— 那个“最流行的浏览器”而取得成功的吗？

不。
它的成功是因为它比 IE
更好。它之所以更好正是因为它的不同。它有标签页浏览方式，实时动态的书签，内建搜索条，PNG（图像格式）支持，adblock扩展（屏蔽广告插件），
以及其它美妙的东西。“查找”工具条显示在底部的工具栏中，它能够查找你键入的内容并且以红色标识表示没有相匹配的内容。而 IE
却没有标签页浏览，没有RSS订阅功能，搜索条只能通过第三方扩展实现，它的查找对话框还得通过点击“确认”按钮开始查找，而且还要再点击一次“确认”才
能清除“未发现”的错误提示。这无疑地证明了一个开源的应用程序通过“不同”而做到了“更好”，依靠“更好”进而取得了成功。如果 Firefox
只是一个 IE 的克隆，它必然早已销声匿迹于 IE 的阴影之下了。如果 Linux 是 Windows 的一个克隆，同样的事情也会发生在
Linux 身上。

因此，解决这个问题的关键在于：记住在 Linux 中那些对于你的使用习惯来说熟悉的部分，并不是说明 Linux 是新版的和改进版的 Windows。积极地面对那些不同之处，因为只有不同，Linux 才有机会真正闪耀出其光彩。

问题二 : Linux 和Windows 太不一样了
当
人们期待着 Linux 有所特色时，又一个问题接踵而至。Linux 和 Windows
实在是太不一样了，一些差异简直难以让人适应。也许最典型的例子就是可供 Linux 用户选择的东西实在是太多了。对于一个刚上手的 Windows
用户，他已拥有一个经典的或 Windows XP 风格的桌面主题、写字板程序、IE 浏览器，Outlook Express；然而对于一个初学
Linux 的家伙，他面前有上百种发行版供其挑选，然后，是 Gnome、KDE 或者 Fluxbox（桌面环境），vi、emacs 或者
kate（文本编辑器），Konqueror、Opera、Firefox 或者 Mozilla（网页浏览器），或者其他一系列可供选择的工具。

Windows 用户不曾为了安装和使用（操作系统）而面对过如此丰富的选择。“有必要提供那么多种选择吗？”这样的抱怨帖子很常见。

Linux 真的和 Windows 有那么大的区别吗？不管怎么说，它们都是操作系统。它们都做同样的工作：操作你的计算机，让你有个运行应用程序的东西，自然它们多少都有些共通的地方吧？

让我们从这个角度看问题：出门看看路上行驶的各种不同车辆。所有的车辆不管是什么样的设计，都有同样的目的：从路上把你由A处运到B处。注意它们有不同的设计。

但是你会想，汽车之间的差异非常小：它们都有方向盘、脚踏板、变速杆、手刹车、车窗、车门、油箱……如果你能够开这部车，你就能开任何一部车。

确实如此。但你有没看见过有些人不开汽车，取而代之他们骑摩托车？

从一个版本的 Windows 切换到另一个版本就像从一辆汽车换到另外一辆汽车。Win95 到 Win98 ，老实说我说不出有什么区别。Win98 到 WinXp，差别比较大但是也没有什么真正的重大区别。

但是从 Windows 切换到 Linux 就象从开汽车切换到骑摩托车。他们都是操作系统（道路车辆）。他们可能都使用同样的硬件（道路）。他们可能都提供一个运行应用程序的环境（把你从甲地运到乙地）。但他们使用本质不同的两种方法来达到目的。

Windows（汽车）对于病毒（小偷）并不安全，除非你安装反病毒软件（锁上车门）。Linux（摩托车）却没有病毒（车门），所以即使你没有安装反病毒软件（没锁车门）也非常安全。

让我们反过来看一看：

Linux
（汽车）从根本上用于多用户（乘客们）。Windows（摩托车）用于单用户（乘客）。每个 Windows
用户（摩托车驾驶员）每时每刻都要习惯集中精力控制他的计算机（车辆）。而一个 Linux 用户（汽车乘客）只有在以 root
根用户身份登录（坐在驾驶座上）时才要去控制计算机（车辆）。

通过两种不同的方法来达成同样的目标，他们各有优缺点：当载上一家子的成员
和大包小包的货物从甲地至乙地时，一辆车显然是明智的选择：因为它有充裕的座位以及足够的储存空间。而对于一个人从甲地到乙地的情况，摩托车则是更好的选
择：因为它不怎么会遇上堵车，消耗的燃油也更少。

无论选择摩托车或是汽车，仍有很多事情不会改变：你要把油加进油箱，把车开在同一条道上，而且必须遵守红绿灯，在转弯前要打转向灯，你同样也要遵守限速指示。

但是也终究有很多情况不同了：汽车驾驶者不必带着安全头盔开车，摩托骑手不用系安全带；开车的人转动方向盘来转弯，摩托车驾驶者则要倾斜身子改变重心；开车的人需要踩油门踏板来加速，而摩托车通过手旋转手把来控制加速。

一
位汽车司机如果试图通过转移重心来拐弯，很快就会陷入一堆麻烦中。同样的，一个 Windows
用户如果认为自己的经验可以直接派上用场，结果也会因为相同的原因而徒劳无获。事实上，较之电脑新手，一个 Windows “高级用户”在
Linux 的使用过程中常遇上更多麻烦。那些经验丰富的 Windows
用户在面对问题时，如果无法解决，常会觉得“如果我这么有知识的，都搞不定，那新手就更不别想了”，因而得出“Linux离桌面应用还有十万八千里呢”的
强烈想法。但这显然是与事实不符。

解决方法在于：Windows 用户必须意识到他只是一个有经验的 Windows 用户，而不是有经验的电脑用户，Windows 用户必须意识到当自己在尝试 Linux 时，他又成了一个新手。

问题三: 文化冲击
子问题 A : 那是一种文化
Windows
用户或多或少地处于一种消费者和供应商之间的关系：他们花钱买软件，获得授权，得到支持，等等。他们希望软件能够有确切的可用性。因此他们习惯于去得到使
用软件的权利：他们花钱去得到技术上的支持以及他们得到他们想要的权利。他们也经常要与一些除了个人之外的实体打交道：例如他们与一家公司签一份合同。

Linux 用户有着更多的一致性。他们不需要花钱去买软件，不需要为得到技术上的支持而耗费财力。他们免费下载软件，并且使用在线聊天工具和到论坛去寻求帮助。他们和个人打交道，而不是公司。

一个 Windows 的用户如果只是把他的观点带到 Linux 中，那么他是不会喜欢上 Linux 的，这需要慢慢地适应。

引
起矛盾的最大原因在于在线交流方面：一个初学 Linux
的菜鸟在遇到问题时寻求帮助，当他没有得到他可以接受的答案的时候，他便开始抱怨并且想要得到更多的帮助。因为这正是他以前用付费来获得帮助的方式。问题
就是这不是付费提供帮助的系统。而是很多热心人发自内心地帮助其他人解决问题的系统。一个新的用户没有任何权利去向这些热心人索要帮助，这就如同一个想要
得到施舍的人，还要求从捐赠者那里获得更多的捐赠品一样。

同样，一个 Windows
用户习惯了使用商业软件。这些软件在没有做到足够的可靠性、功能性以及对用户友好的界面之前，公司是不会发布该软件的。因此这正是 Windows
用户希望软件是从1.0 版本开始的。而 Linux 软件一旦重写就会立即发布，因此是从 0.1
版本开始的。这样的，真正需要这些功能的人就会马上得到它；感兴趣的开发者会来帮助改进代码，；以及社区就会知道接下来要做什么了。

如果菜鸟在使用Linux时遇到了困难，他会抱怨：这个软件没能满足我的需求，并且他认为他有权得到这样的满足。如果他得到这样带有讽刺性的回答：“如果我是你,我要求退款！”，他的情绪将会更差。

因此，为了避免这些问题，应做到：只要记住，你并没有付给那些软件开发者或者在线帮你提供技术指导的人任何钱。他们并不欠你任何东西。

子问题 B : 新的 VS. 旧的
Linux
几乎是因黑客的业馀爱好而诞生的。它的成长也使得易于它吸引了更多志同道合的黑客们。Linux
在获得一个易于使用的可用安装程序前一直默默无闻。在相当长的时间里，它在大众眼中只是一个极客（Geek）而已。可以说Linux“始于极客，馈于极
客”。直至今日，大多数 Linux 的老用户仍自认为是极客。

这是件非常好的事情：如果你在硬件或软件方面有问题，存在一大群极客们不断寻找解决方案这个状况，显然一种明显的优势。

但
长久以来 Linux 的成长仍旧十分有限。尽管存在一些可以被绝大多数人安装的发行版本，甚至一些版本基于 CD 并且与用户使用的硬件并无冲突。当
Linux
开始因其无病毒和廉价的升级而吸引一些非发烧友用户时，两大用户阵营间并不是没有摩擦，但双方都明了一点：对方都没有恶意，仅仅是缺乏相互理解而已。

首
先，你面临的是核心极客们仍然假设所有使用 Linux
的用户们都是极客同志。这意味着他们认为所有人都对此有很深入的理解，这导致了他人控诉他们的一些行为是傲慢、自大和无礼的。事实上，有时如此。但大多时
候却并非这样：“每个人都应知道”这样的善意表达被说成了“地球人都知道！”——大相径庭。

其次，你面临着从使用的商用操作系统转投而来的新用户。这些用户已习惯使用人机界面友好的软件，他们也是不确定因素。

这类问题起因于不同使用习惯的碰撞：第一类人沉醉于不断地按自己喜好重构系统，而第二类人对操作系统如何工作漠不关心，只要它能工作就好。

在乐高（Lego）玩具发生的类似的情况正好阐述这种问题。试想下面的情景：

新用户（以下简称“新”）：我想要一个新玩具汽车，每个人都因乐高汽车的好玩而着了迷。所以我也买了它，但当我到家後我才发现，我的盒子里只有积木和齿轮！我的车子在哪里？

老用户（以下简称“老”）：你应该在积木之外组装一辆车，这才是乐高的真谛。

新：什么？？我不知道应怎样拼装这个车子。我不是个机械师。为什么我应该知道如何组装它？

老：盒子里有使用手册。它上面写着拼装车子的步骤。你不用知道原理，只要按照按部就班就好。

新：好吧，我找到了步骤。这将占用我很多时间！为什么厂家不能装好了再卖给我，还得让我自己动手？？

老：并不是所有人都满足于将乐高做成玩具车。这些积木可以被我们组成万物。这才是游戏的真谛。

新：我仍旧不明白为什么厂商不能给我们这种想要车子的人一个成品，如果那些喜欢动手的人高兴可以自己拆了它阿。无论如何，我还是将它组装起来了，尽管某些部件时不时地掉下来。我有什么方法可以解决吗？我能将它们粘起来吗？

老：这就是乐高。他就是用来拆装的。这才是游戏的真谛。

新：但我不希望总是拆拆装装，我仅仅希望一个玩具车而已！

老：呃，欢迎您到地球来。你买的是乐高吗？

很明显，对那些只想要一个玩具车的人来说，乐高并不是为他们准备的。上面的情景应该不会发生在你的生活中。乐高的价值在于你可以建造过程中体会乐趣而且你也可以将它组装成任何你想要的东西。如果你不想动手拼装，只能说乐高不适合你。这显而易见。

由于长久以来一直关注 Linux 的老用户，同样的问题在 Linux 上越发明显：它是开源的、完全可定制的软件集。这才是真谛。如果你不想修改一些组件，为什么自找麻烦来使用它呢？

与
乐高出售成品玩具的做法略有相似，通过最近的一系列的成果提升了非黑客用户使用 Linux 的舒适性，这使得更广大的用户可以使用
Linux。也正因如此，你仍可以听到与上面相似的对话，程度也仅是略有不同。新用户抱怨老用户只考虑基本特性，他们不得不通过阅读手册才能实现一些功
能。对太多发行版本的抱怨，对软件过多配置选项的抱怨和对运行时时常报错的抱怨不正如对乐高有太多模块的抱怨一样忽略了它可以被用来按你想发拆装成事实
吗？

因此，为了避免这个问题：请铭记现在的 Linux 已今非昔比。Linux 社区最大的也是最关键的组成部分——黑客和开发者们，他们因 Linux 的可以按需定制而欢喜；他们也会可制定能力的丧失因而神伤。

问题四: 为设计者而设计
在汽车工业中，你很难发现一个人即设计车辆引擎也设计车辆内饰：这些是完全不同的技能。没有人想要只是看起来可以跑得很快的引擎，同样也没有人想要一个做工出众但狭小且肮脏的内饰。基于同样的道理，在软件产业，用户界面(UI)往往不是由软件编程人员设计的。

但
在 Linux 的世界却大不相同：一个项目往往是因个人的兴趣而产生。个人也包办了所有的工作，因此这些项目的界面往往缺乏了“用户友好”
的特性：用户对这个软件了如指掌，所以他也就不需要了帮助文件等。vi
就是一个很好的例子，最初它的目标用户就是为那些了解它工作方式的人。因而设计者从来都没有想过如何用其他方式退出 vi
，所以新用户不得不靠重启计算机退出的事情时有发生。

但是，自由开源软件（FOSS）程序员与商用软件程序员的一个最重大区别在于，
FOSS程序员的作品都是他们自己想要使用的东西。因此当作品不能被新用户“舒适”使用的同时，它又成为了最终用户最需要的东西：因为作者也是最终用的一
员。商用软件的程序员却大不相同，他们总是为其他人编写软件，而且这些用户都不是专家。

所尽管 vi 拥有拥有一个令新手望而生畏的界面，但它仍然在当今流行，这又归功于他的界面：当你熟悉後就会发现它原来无比强大。Firefox 也是被经常浏览网页的人编写出来的。Gimp 同样是出自经常处理图形文件的人之手。不胜枚举。

Linux
的界面对于新手而言同样的有些“难度”。尽管 vi
名声在外，但他仍然不在那些需要快速修改一些文件的新手的考虑之列。如果你在一个软件生命周期的早期使用它，光鲜亮丽且友善的用户界面永远只高挂在“计
划”列表之上：功能优先。没有人先雇好装修队再去找楼盘，程序员们都是实现功能再不断改进界面。

所以，为了避免这个问题：寻找那些已便于上手为目的设计的软件，或者接受那些与你使用习惯急剧不同的软件。抱怨 vi 对新手不够友好只是舍本求末罢了。

问题五: “用户友好”的神话
在电脑世界里，“用户友好“是一个十分广泛的专有名词。甚至有一个网络笑话就叫这个名字。但这个词却名不副实。

基本实现方法听起来似乎不错：软件的设计要从用户的想法和需要出发。这个方法一直都被认为是单一的实现办法，但事实并非如此。

如果你一辈子都在进行文书处理的工作，理想的软件对你来说就是个快捷强大、能让你投入最小的精力来实现最大的工作效率的文字处理软件。简单的键盘快捷键和无须鼠标的操作将是最基本的需求。

但如果你很少做字处理的工作，你只是要写一封普通的信，那么你不会想着去学会那些键盘快捷键操作方法。排列有序的菜单和一目了然的工具栏图标就是你的理想环境。

很明显，你为某个用户的需求所设计的软件可能对其他的用户来说并不合适。如此说来，若我们每个人都对软件有不一样的需求，那这些软件怎么能自称“用户友好”呢？

简单来说：“用户友好”并非事实，只是为了让复杂的情况看上去变得简单一点而已。

那么“用户友好”到底是什么意思呢？好吧，从那些使用这个词的文章中来看，“用户友好”的软件实际上意味着“该软件对那些以前从未使用这个软件的用户们来说也不是那么难上手”。这就使得那些看上去用户界面都差不多的软件都被归类为“用户友好”。
子问题 A: 熟悉的就是友好的
所以在大多数被认为“用户友好”的文字编辑 和文字处理的系统中，你的剪切和复制使用 “Ctrl+X” 和 “Ctrl+V” 来完成，这完全不直观, 但是每个人都习惯这些快捷键，所以他们把这当作“友好的”快捷方式。

如果有人使用 vi 并且发现里面 “d” 是剪切，“p” 是复制，这将被当成是不友好的：因为这不是大多数人习惯的方式。

但这是更好的方式吗? 明显是的。

如果使用“Ctrl+X”的方法，你怎样从你当前正在编辑的文件中剪切一个单词？（没有鼠标的前提下！）

你必须从开头的字符开始,用“ Ctrl+Shift+Right”来选择单词.

然後“Ctrl+X”把它剪切下来。

vi中的方式呢？“dw”就是删除单词的意思。

如果要剪切 5个单词使用 “Ctrl+X” 方式会出现什么情况呢？

从开头的单词开始：

“Ctrl+Shift+Right”

“Ctrl+Shift+Right”

“Ctrl+Shift+Right”

“Ctrl+Shift+Right”

“Ctrl+Shift+Right”

“Ctrl+X“

要使用5个动作

在 vi 中的情况呢?

d5w

vi
方式具有更好的功能性和直观性 。“X” 和 “V” 并不是能够直观记忆“Cut”和 “Paste” 命令的，反之 “dw” 对于
“delete” 和 “p” 对于 “Paste” 更加直观，相对于 “X” 和 “V” 方面，vi
明显是更好的。可是由于她不是大家所熟悉的，因此她被认为是不友好的。并不是因为其他的原因，纯粹的习惯因素使得Windows成为了更加友好的系统。因
此我们要学习问题一：Linux 和 Windows 完全不一样。告诉大家：不可避免，Linux 经常显得没有 Windows “友好”。

为了避免这个问题，你们要记住“友好”并不意味着习惯,试着用你的方式来做事，如果没有用的话，试着想想一个初学者会怎么做，然後你就知道了更简单的方法。
子问题 B: 低效的就是友好的
这是一个可悲的但无法逃避的事实。似乎你越想提高一个程序的功能性，它就看起来越友好。

这是因为友好性是通过在用户界面中使用简单、可视化的“线索”实现的——越多越好。毕竟，如果一个完全的计算机新手被放到一个所见即所得的字处理软件前并被要求把一些文本变成粗体，接下来很有可能：

    * 他会认为 "Ctrl+B" 是通常的方法。
    * 他会寻找线索，并尝试点击 "编辑" 菜单。如果不成功，他就会从接下来的一系列菜单中尝试比较像的那个：“格式”。新的菜单有一个看起来很有希望的“字体”选项。嗨！这里有我们想要的“粗体”选项。成功了！

下次你再做任何文字处理，都想试着通过菜单来完成每一件工作：不用快捷键，也不用工具栏图标。菜单就是一切。当任务突然需要大量按键和鼠标点击时，你会发现你比爬还慢。

è¿™
样使软件变得“用户友好”就像在自行车上装辅助轮一样：它让你能马上骑起来起来，不需要任何技巧和经验。这对一个初学者来说是完美的。但是没有人会觉得所
有的自行车都应该加上辅助轮销售。如果你今天得到这样的一辆自行车，我敢打赌你要做的第一件事就是除去这不必要的阻碍：一旦你知道怎样骑车了，辅助轮就没
用了。

同样的道理，大量的 Linux 软件是设计成不带“辅助轮”（辅助工具）的——它是为已经有一些使用的基本技能的用户设计的。毕竟，没有人是永远的新手：无知是短命的，知识是永远的。因此 Linux 软件是以大量的知识为前提设计的。

这听起来也许像是借口：毕竟，MS Word（微软的Word）有全部的友好菜单，并且有各种工具栏按钮， 而且有快捷键……它是世界上最棒的。真的吗？友好且有效的。

然
而，我们必须透过表象看问题。首先，这个想法的可行性：让一个软件拥有菜单、工具栏、快捷方式等一切意味着大量的源代码编写，而没人为 Linux
开发者花费的时间付帐；其次， 这样做依然没有真正考虑到那些高端用户；极少有专业的文字录入者使用MS Word。你见过哪个编程的人用 MS
Word 吗？与此相比，想想有多少人用 emacs 和 vi。

为什么会这样？首先，这是因为某些“用户友好”的行为会导致低效：参看
上面的“剪切和粘贴”的例子。其次，这还因为 Word
大部分的功能被放在了菜单里，因此你不得不使用菜单。只有某些最常见的功能可以作为按纽被放在界面的工具栏上。高级用户不得不花大量的时间来找到那些较少
用道，但对高级用户来说依然很常用的的功能。

另外请记住，不管怎样，那些“辅助轮”在 Linux 软件中也同样有，尽管他们不是那么容易被发现，但实际在 Linux 中通常都会有。

以
mplayer 播放器为例。你可以在终端输入 mplayer
视频文件名命令来播放视频文件。你可以使用方向键，PageUp、PageDown键进行快进、后退等操作.这些可能还不能称之为完全的“用户友好”，但
如果你在终端输入 gmplayer 视频文件名 ,你就会看到图形版的播放器，它同样拥有漂亮、友好的界面，熟悉的按钮。

再用从
CD 转换到 MP3（或 Ogg）为例: 如果使用命令行, 你需要先使用 cdparanoia
命令。然后你再需要一个编码器……这会是一个恶梦，就算你完完全全清楚如何使用 (imho) 包。所以，下载和安装
Grip吧。这是一个容易使用的图形软件，自动的在背后使用 cdparanoia 命令和编码器，令你的转换过程变得简单，甚至支持
CDDB，能自动为你的档案命名。

同样发生在抓取DVD上：选择正确的编码是一场噩梦。但是使用dvd::rip软件，可以在一个任何人都能操作自如的图形界面来完成整个编码过程。

因此避免这个问题：要记住“辅助轮”（辅助工具）仅作为Linux的扩展，而不是由主程序自动提供的。而且有时，“辅助轮”还不成为设计的一部分。

问题六：模仿 VS. 汇合
当人们发现 Linux 不是他们想要的 Windows 复制品时，经常争论一件事，就是坚持认为 Linux 一诞生，这就是（或应该是）其努力的方向，而且那些不明白这一点的人错误地帮助，使 Linux 更像 Windows。由于这一点，他们展开激烈的争论：

Linux 已经从命令行时代进入了图形界面时代，这是复制 Windows 的明显尝试。

不
错的理论，但是错了：最初的 X 窗囗化系统（见附录）是于1984年发布，继承自1983年移植到 Unix 上的 W 窗口化系统。而
Windows 1.0 是在1985年才发布的。Windows 在1990年发布第三版之前并没有做大——那时，X
窗口化系统已经演化成我们今天使用的 X11 版本好几年了。Linux 在1991年才开始，所以 Linux 没有开发一个
GUI（图形用户界面）来模仿 Windows：它只是使用了一个在 Windows 出现之前就已经存在的 GUI。

Windows 3 系列让位于 Windows 95，后者带来了图形界面的革命性变化；在这以后很多年，微软都没能作出与此类似的创举。Windows 95 带来了多项创新的特性：拖放功能、任务栏等等。当然，这些也同样被 Linux 所借鉴。

事实上……不是这样的。上述所有的特性在微软使用前就已经出现了。尤其，NeXTSTeP（见附录介绍）是一个非常先进的图形用户界面（就当时而言），它明显早于 Win95 ──1989年发布了第一版，1995年发布了最后一版。

不错，不错，所以微软并没有想出被我们认为是 Windows 界面的独有特性。但它还是创造了一种界面，Linux 从那时起尝试模仿它。

为了揭穿这些，我们可以引用一个经常被讨论的说法：趋同现象。它说的是：两个不同的、各自独立的系统随着时间的推移会逐渐变得类似。这种现象经常发生在生物学领域。举例来说：鲨鱼和海豚，他们都有着类似的背鳍、胸鳍和尾鳍，以及同样的流线型外形。

但
是，鲨鱼是由鱼进化而来的，而海豚则是由陆地上的哺乳动物进化而来的。他们拥有类似外形是由于他们都生活在同样的海洋环境中，他们必须朝最大效率适应海洋
环境的方向进化。实际上不会有一幕这样的场景：未进化的海豚看到鲨鱼以後就开始想“Wow,看看鲨鱼的鳍，它们非常有用。我也要这样进化一套自己的鳍！”

同
样，如果先看早期的 Linux 桌面、FVWM 和 TWM 以及许多简陋的 GUI（图形用户界面），然后再看看今天的 Linux
桌面、Gnome 和 KDE，以及它们带有的任务栏、菜单、视觉效果。是的，不得不说现在的 Linux 比早期的更像 Windows 了。

另一方面，Windows也同样如此；我印象中 Windows 3.0 没有任务栏。那么开始菜单呢？什么是开始菜单？

Linux 过去没有任何桌面像今天的 Windows，微软过去也没有。现在他们都有了，这说明什么问题呢?

这说明两个开发阵营的成员都在寻找提升GUI（图形用户界面）性能的方法，但是解决相同的问题可供选择的方法并不多，他们难免会使用类似的方法。类似并不能说明或暗指一方在模仿另一方。记住这一点，你就不会受到这个问题的困扰了。

问题七：那些 FOSS（自由和开源软件）的事
噢，这导致了问题。非本质的：自由和开源的软件是整个事情中一个极好的和很重要的部分。但是对于一些人看来，理解 FOSS（自由和开源软件）和私有软件之间的不同是一个巨大的改变。

我已经提醒了一些事实，人们认为他们需要并喜欢技术支持。但是事实往往离得很远。

微软的使命声明是“A computer on every desktop（每个电脑都需要桌面）”——不言而喻，每一台计算机应该运行 Windows。微软和苹果公司都销售操作系统，都尽他们最大的努力来保证大多数的人们使用他们的产品：他们是企业，为了赚钱。

并且FOSS（自由和开源软件）也在那里，甚至今天，几乎都是非商业的。

当
你发电子邮件告诉我，Red Hat、Suse、Linspire 和所有Linux发行版：是的，我知道他们在“销售”
Linux。我知道他们都希望 Linux 被广泛的采用，特别是他们自己的版本。但是不要混淆提供者和生产者。Linux
内核不是被一个公司创造，不是为了获取利润而维持它。这些 GNU 工具不是被一个公司创造，同样也不是为了牟取利润。X11
视窗系统……不错，当前最流行的实现方案是
xorg，并且“.org”应该部分地告诉你需要知道的（注：.org为非盈利组织）。桌面软件：好的。你提出一个例子，比如 KDE
，由于其基于的Qt是商业化的。（译者注：现在 Qt 已经不是商业化的了）。但是
Gnome、Fluxbox、Enlightenment等等，都是非盈利的。那儿是有人销售Linux，但是那只是非常少数的。

私有软
件最终用户数量的增加导致了制作那些软件公司直接的经济效益。对于
FOSS（自由和开源软件）来说，并不是这样，使用人数的增加并不会产生直接的收益。肯定是：个人自豪感，发现
Bug（错误）能力的增长，更多可能得吸引新的开发者，可能有机会得到个好的工作，等等。

但是 Linus Torvalds（
Linux 的创始人）没有从 Linux 使用权上挣钱。Richard Stallman（ GNU 创始人）没有从增长的 GNU
使用权中获利。所有运行 OpenBSD 和 OpenSSH 的服务没有放一分钱到 OpenBSD 项目的钱袋中去。所以我们来看，这就是在
Linux 和新用户之间最大的问题：

他们发现了不想要的东西。

新用户来到 Linux
，他们曾经使用一种操作系统，那时，最终用户的需求至高无上的，并且“用户友好性”和“以用户为中心”
被认为是第一位的。并且他们突然发现他们自己将要使用的操作系统：仍然依赖于‘man’文档，命令行，手动编辑配置文档和
Google。并且当他们抱怨时，他们没有获得悉心照顾或者承诺的更好的东西：他们屡屡碰壁。

当然，夸大其词了。有许多人尝试去转换到 Linux 但是失败了。

从
另一方面来说，FOSS（自由和开源软件）事实上是一个非常自我的发展方法：仅当人们想工作的时候才工作，仅工作于他们想工作的东西。大部分人们没有看到
任何的需求，让 Linux 对没有经验的用户更有吸引力：它已经按照他们想要的工作了，为什么他们应该关心它为什么没有为另外的人工作呢？

FOSS
（自由和开源软件）和 Internet
自身有很多相似的地方：你不需要付钱给一个网页（软件）的作者，去下载以及阅读（安装）它。对于已经有了带宽（知道如何使用软件）的人们来说，无限的宽带
（用户友好的界面）并不是很感兴趣的。博客（软件开发者）不需要很多的读者（用户）来证明写博客日志（编码）。
那里是有许多人从中获得了很多的钱，但它并不是大部分商业喜欢的旧有规则：“我拥有这个，如果你想要一些，你必须付钱”；而它提供了诸如技术支持（电子商
务）的服务。

Linux 对市场份额不感兴趣。Linux 没有客户。Linux 没有股东，或者一个盈利亏损的责任。Linux 不是为了赚钱而创造的。Linux 没有成为这个星球上最流行和最普及的操作系统的目标。

所
有的 Linux 社区都想要一种真正不错、充满特色、自由的操作系统。如果 Linux 最终成为一种非常流行的操作系统，那么是美妙的。如果
Linux 最终拥有直观的、用户友好的界面，那么也是美妙的。如果 Linux 最终成为一个数十亿美元的产业的基础，那也是美妙的。

它
是伟大的，但它不是重点。重点是，让 Linux 成为社区有能力制作的最好的操作系统。不是为了别人：为了它自己。如此普遍关于“除非 Linux
如此这样，否则永远不会占领桌面”的威胁是不恰当的：Linux
社区没有尝试占领桌面。他们完全不关心它放在你桌面上，是否够好，只要在他们的桌面，运行的够好。 憎恨微软的人，Linux
的狂热者，FOSS（自由和开源软件）提供者或许是吵闹的，但他们仍然只是少数的。

Linux 社区想要的是：一种操作系统能够被任何想要它的人安装。所以如果你在考虑转向 Linux。首先，问你自己，什么是你真的想要的。

如果你想要一种操作系统，没有一个汽车司机在你身边，除了给你把钥匙，把你放在驾驶员的座位上，并且希望你知道要做什么：得到 Linux。你将必须投入时间去学习如何使用它，但是一旦你学会了，你将拥有一种能够站起来跳舞的操作系统。

如
果你只是想要没有恶意软件和安全问题的 Windows：阅读好的安全实践；安装好的防火墙，恶意软件检测者和杀毒软件；用一个更安全的浏览器替换
IE ；并且保持升级到最新的安全更新。有人（包括我自己）使用 Windows 从 3.1 到
XP，从来不曾被病毒或者恶意软件感染：你也可以做到。不要用 Linux：非常不幸的是，它不会成为你想要它的那个样子。

如果你想要一
种基于 Unix 的操作系统的安全性和性能，和以客户为中心的特点和世界著名的界面：购买苹果公司的 Mac 操作系统。Mac OS
X是不错的。但是不要用 Linux：它不会做你想要它做的那样。（译者注：据个人观察，现在Linux界面已经接近或者超越Mac OS X。）

这不仅是关于“为什么我想要 Linux？”。也是关于“为什幺 Linux 想要我？”

本文遵循 Creative Commons License 创作共用协议。

IBM jsut delivered two specifications for building systems that use a Service-Oriented Architecture (SOA), which aim to provide developers with simpler and more powerful ways of constructing applications based on SOA: Service Component Architecture (SCA) and Service Data Objects (SDO).

You can find some detail info from this link:
http://www-128.ibm.com/developerworks/library/specification/ws-sca/
http://www.theserverside.com/news/thread.tss?thread_id=37859
The key words are:
Service Component Architecture (SCA)
Service Data Objects (SDO)
Business Objects (BO)

I have worked with SCA for much more than one year. I feel it is a elegant way to implement your own enterprise application. The dev only need to focus on the requirement, and provide a service component. And this component can be used by any other component. SCA provide several kind way for the invocation. The SCA’s implementation can be many type, SDO、WSDL、EJB、BPEL、JAVA、POJO. SCA can be invoked as a Web Service. And it can invoke a EJB, Web Service, any other SCA component…..
So many benefit need you to discovery… Read it, and "Enjoy the word of SCA"~

.tar
解包： tar xvf FileName.tar
打包：tar cvf FileName.tar DirName
（注：tar是打包，不是压缩！）
———————————————
.gz
解压1：gunzip FileName.gz
解压2：gzip -d FileName.gz
压缩：gzip FileName
.tar.gz
解压：tar zxvf FileName.tar.gz
压缩：tar zcvf FileName.tar.gz DirName
———————————————
.bz2
解压1：bzip2 -d FileName.bz2
解压2：bunzip2 FileName.bz2
压缩： bzip2 -z FileName
.tar.bz2
解压：tar jxvf FileName.tar.bz2
压缩：tar jcvf FileName.tar.bz2 DirName
———————————————
.bz
解压1：bzip2 -d FileName.bz
解压2：bunzip2 FileName.bz
压缩：未知
.tar.bz
解压：tar jxvf FileName.tar.bz
压缩：未知
———————————————
.Z
解压：uncompress FileName.Z
压缩：compress FileName
.tar.Z
解压：tar Zxvf FileName.tar.Z
压缩：tar Zcvf FileName.tar.Z DirName
———————————————
.tgz
解压：tar zxvf FileName.tgz
压缩：未知
.tar.tgz
解压：tar zxvf FileName.tar.tgz
压缩：tar zcvf FileName.tar.tgz FileName
———————————————
.zip
解压：unzip FileName.zip
压缩：zip FileName.zip DirName
———————————————
.rar
解压：rar a FileName.rar
压缩：r ar e FileName.rar

rar请到：http://www.rarsoft.com/download.htm 下载！
解压后请将rar_static拷贝到/usr/bin目录（其他由$PATH环境变量指定的目录也可以）：
[root@www2 tmp]# cp rar_static /usr/bin/rar
———————————————
.lha
解压：lha -e FileName.lha
压缩：lha -a FileName.lha FileName

lha请到：http://www.infor.kanazawa-it.ac.jp/…/lhaunix/下载！
>解压后请将lha拷贝到/usr/bin目录（其他由$PATH环境变量指定的目录也可以）：
[root@www2 tmp]# cp lha /usr/bin/
———————————————
.rpm
解包：rpm2cpio FileName.rpm | cpio -div
———————————————
.tar .tgz .tar.gz .tar.Z .tar.bz .tar.bz2 .zip .cpio .rpm .deb .slp .arj .rar .ace .lha .lzh
.lzx .lzs .arc .sda .sfx .lnx .zoo .cab .kar .cpt .pit .sit .sea
解压：sEx x FileName.*
压缩：sEx a FileName.* FileName

sEx只是调用相关程序，本身并无压缩、解压功能，请注意！
sEx请到： http://sourceforge.net/projects/sex下载！
解压后请将sEx拷贝到/usr/bin目录（其他由$PATH环境变量指定的目录也可以）：
[root@www2 tmp]# cp sEx /usr/bin/

 

.cpio

解包：cpoi -idvm < *.cpio

一. 大教堂和市集

　　Linux的影响是非常巨大的。甚至在５年以前，有谁能够想象一个世界级的操作系统能够仅仅用细细的Internet连接起来的散布在全球的几千个开发人员有以业余时间来创造呢？

　　我当然不会这么想。在１９９３年早期我开始注意Linux时，我已经参与Unix和自由软件开发达十年之久了。我是八十年代中期GNU最早的几个参与者之一。我已经在网上发布了大量的自由软件，开发和协助开发了几个至今仍在广泛使用的程序（Nethack,Emacs VC和GND模式，xlife等等）。我想我知道该怎样做。

　　Linux推翻了许多我认为自己明白的事情。我已经宣扬小工具、快速原型和演进式开发的Unix福音多年了。但是我也相信某些重要的复杂的事情需要更集中化的，严密的方法。我相信多数重要的软件（操作系统和象Emacs一样的真正大型的工具）需要向建造大教堂一样来开发，需要一群于世隔绝的奇才的细心工作，在成功之前没有beta版的发布。
Linus Torvalds的开发风格（尽早尽多的发布，委托所有可以委托的事，对所有的改动和融合开放）令人惊奇的降临了。这里没有安静的、虔诚的大教堂的建造工作——相反，Linux团体看起来像一个巨大的有各种不同议程和方法的乱哄哄的集市（Linux归档站点接受任何人的建议和作品，并聪明的加以管理），一个一致而稳定的系统就象奇迹一般从这个集市中产生了。

　　这种设计风格确实能工作，并且工作得很好，这个事实确实是一个冲击。在我的研究过程中，我不仅在单个工程中努力工作，而且试图理解为什么Linux世界不仅没有在一片混乱中分崩离析，反而以大教堂建造者们不可想象的速度变得越来越强大。

　　到了１９９６年中，我想我开始理解了。我有一个极好的测试我的理论的机会，以一个自由软件计划的形式，我有意识的是用了市集风格。我这样做了，并取得了很大的成功。

　　在本文的余下部分，我将讲述这个计划的故事，我用它来明确一些自由软件高效开发的格言。并不是所有这些都是从Linux世界中学到的，但我们将看到Linux世界给予了它们一个什么样的位置。如果我是正确的，它们将使你理解是什么使Linux团体成为好软件的源泉，帮助你变得更加高效。

二. 邮件必须得通过

　　１９９３年以前我在一个小的免费访问的名为Chester County InterLink的ISP的做技术工作，它位于Pennsylvania的West Chester。（我协助建立了CCIL，并写了我们独特的多用户BBS系统——你可以telnet到locke.ccil.org来检测一下。今天它在十九条线上支持三千的用户）。这个工作使我可以一天二十四小时通过CCIL的56K专线连在网上，实际上，它要求我怎么做！

　　所以，我对Internet email很熟悉。因为复杂的原因，很难在我家里的机器（snark.thyrsus.com）和CCIL之间用SLIP工作。最后我终于成功了，但我发现不得不时常telnet到locke来检查我的邮件，这真是太烦了。我所需要的是我的邮件发送到snark,这样biff(1)会在它到达时通知我。

　　简单地sendmail的转送功能是不够的，因为snark并不是总在网上而且没有一个静态地址。我需要一个程序通过我的SLIP连接把我的本地发送的邮件拉过来。我知道这种东西是存在的，它们大多使用一个简单的协议POP（Post Office Protocol）。而且，locke的BSD/OS操作系统已经自带了一个POP3服务器。

　　我需要一个POP3客户。所以我到网上去找到了一个。实际上，我发现了三、四个。我用了一会pop-perl，但它却少一个明显的特征：抽取收到的邮件的地址以便正确回复。

　　问题是这样的：假设locke上一个叫“joe”的人向我发了一封邮件。如果我把它取到snark上准备回复时,我的邮件程序会很高兴地把它发送给一个不存在的snark上的“joe”。手工的在地址上加上“@ccil.org”变成了一个严酷的痛苦。

　　这显然应是计算机替我做的事。（实际上，依据RFC1123的5.2.18节，sendmail应该做这件事）。但是没有一个现存的POP客户知道怎样做！于是这就给我们上了第一课：

　　1.每个好的软件工作都开始于搔到了开发者本人的痒处。

　　也许这应该是显而易见的（“需要是发明之母”长久以来就被证明是正确的），但是软件开发人员常常把他们的精力放在它们既不需要也不喜欢的程序，但在Linux世界中却不是这样——这解释了为什么从Linux团体中产生的软件质量都如此之高。

　　那么，我是否立即投入疯狂的工作中，要编出一个新的POP3客户与现存的那些竞争呢？才不是哪！我仔细考察了手头上的POP工具，问自己“那一个最接近我的需要？”因为：
　　2.好程序员知道该写什么，伟大的程序员知道该重写（和重用）什么。

　　我并没有声称自己是一个伟大的程序员，可是我试着效仿他们。伟大程序员的一个重要特点是建设性的懒惰。他们知道你是因为成绩而不是努力得到奖赏，而且从一个好的实际的解决方案开始总是要比从头干起容易。

　　例如，Linux并不是从头开始写Linux的。相反的它从重用Minix（一个386机型上的类似Unix的微型操作系统）的代码和思想入手。最后所有的Minix代码都消失或被彻底的重写了，但是当它们在的时候它为最终成为Linux的雏形做了铺垫。

　　秉承同样的精神，我去寻找良好编码的现成的POP工具，用来作为基础。

　　Unix世界中的代码共享传统一直对代码重用很友好（这正是为什么GNU计划不管Unix本身有多么保守而选取它作为基础操作系统的原因）。Linux世界把这个传统推向技术极限：它有几个T字节的源代码可以用。所以在Linux世界中花时间寻找其他几乎足够好的东西，会比在别处带来更好的结果。

　　这也适合我。加上我先前发现的，第二次寻找找到了9个候选者——fetchPOP，PopTart，get-mail，gwpop，pimp，pop-perl，popc，popmail 和 upop）。我首先选定的是“fetchpop”。我加入了头标重写功能，并且做了一些被作者加入他的1.9版中的改进。

　　但是几个星期之后，我偶然发现了Carl Harris写的“popclient”的代码，然后发现有个问题，虽然fetchpop有一些好的原始思想(比如它的守护进程模式)，它只能处理pop3，而且编码的水平相当业余(Seung-Hong是个很聪明但是经验不足的程序员)，Carl的代码更好一些，相当专业和稳固，但他的程序缺少几个重要的相当容易实现的fetchpop的特征(包括我自己写的那些)。

　　继续呢还是换一个? 如果换一个的话，作为得到一个更好开发基础的代价，我就要扔掉我已经有的那些代码。

　　换一个的一个实际的动机是支持多协议，pop3是用的最广的邮局协议，但并非唯一一个，Fetchpop和其余几个没有实现POP2.RPOP，或者APOP，而且我还有一个为了兴趣加入IMAP(Internet Message Access Protocol，最近设计的最强大的邮局协议)的模糊想法。

　　但是我有一个更加理论化的原因认为换一下会是一个好主意ï
¼Œè¿™æ˜¯æˆ‘在Linux很久以前学到的：

　　3.“计划好抛弃，无论如何，你会的”(Fred Brooks,《神秘的人月》第11章)

　　或者换句话说，你常常在第一次实现一个解决方案之后才能理解问题所在，第二次你也许才足够清楚怎样做好它，因此如果你想做好，准备好推翻重来至少一次。

　　好吧(我告诉自己)，对fetchpop的尝试是我第一次的尝试，因此我换了一下。

　　当我在1996年6月25日把我第一套popclient的补丁程序寄给Carl Harris之后，我发现一段时间以前他已经对popclient基本上失去了兴趣，这些代码有些陈旧，有一些次要的错误，我有许多修改要做，我们很快达成一致，我来接手这个程序。不知不觉的，这个计划扩大了，再也不是我原先打算的在已有的pop客户上加几个次要的补丁而已了，我得维护整个的工程，而且我脑袋里涌动着一些念头要引起一个大的变化。

　　在一个鼓励代码共享的软件文化里，这是一个工程进化的自然道路，我要指出：

　　4. 如果你有正确的态度，有趣的问题会找上你的，但是Carl Harris的态度甚至更加重要，他理解：

　　5.当你对一个程序失去兴趣时，你最后的责任就是把它传给一个能干的后继者。

　　甚至没有商量，Carl和我知道我们有一个共同目标就是找到最好的解决方案，对我们来说唯一的问题是我能否证明我有一双坚强的手，他优雅而快速的写出了程序，我希望轮到我时我也能做到。

三. 拥有用户的重要性

　　于是我继承了popclient，同样重要的是，我继承了popclient的用户基础，用户是你所拥有的极好的东西，不仅仅是因为他们显示了你正在满足需要，你做了正确的事情，如果加以适当的培养，他们可以成为合作开发者。

　　Unix传统另一有力之处是许多用户都是黑客，因为源优码是公开的，他们可以成为高效的黑客，这一点在Linux世界中也被推向了令人高兴的极致，这对缩短调试时间是极端重要的，在一点鼓励之下，你的用户会诊断问题，提出修订建议，帮你以远比你期望快得多的速度的改进代码。

　　6. 把用户当做协作开发者是快速改进代码和高效调试的无可争辩的方式。

　　这种效果的力量很容易被低估，实际上，几乎所有我们自由软件世界中的人都强烈低估了用户可以多么有效地对付系统复杂性，直到Linus让我们看到了这一点。

　　实际上，我认为Linus最聪明最了不起的工作不是创建了Linux内核本身，而是发明了Linux开发模式，当我有一次当着他的面表达这种观点时，他微笑了一下，重复了一句他经常说的话：“我基本上是一个懒惰的人，依靠他人的工作来获取成绩。”象狐狸一样懒惰，或者如Robert Heinlein所说，太懒了而不会失败。

　　回顾起来，在GNU Emacs Lisp库和Lisp代码集中可以看到Linux方法的成功，与Emacs的C内核和许多其他FSF的工具相比，Lisp代码库的演化是流动性的和用户驱动的，思想和原型在达到最终的稳定形式之前往往要重写三或四次，而且经常利用Internet的松散合作。

　　实际上，我自己在fetchmail之前最成功的作品要算Emacs VC模式，它是三个其他的人通过电子邮件进行的类似Linux的合作，至今我只见过其中一个人(Richard Stallman)，它是SCCS、RCS和后来的CVS的前端，为Emacs提供“one-touch”版本控制操作，它是从一个微型的、粗糙的别人写好的sccs.el模式开始演化的，VC开发的成功不像Emacs本身，而是因为Emacs Lisp代码可以很快的通过发布／测试／改进的过程。

　　(FSF的试图把代码放入GPL之下的策略有一个未曾预料到的副作用，它让FSF难以采取市集模式，因为他们认为每个想贡献二十行以上代码的人都必须得到一个授权，以使受到GPL的代码免受版权法的侵扰，具有BSD和MITX协会的授权的用户不会有这个问题，因为他们并不试图保留那些会使人可能受到质询的权力)。

四. 早发布、常发布

　　尽量早尽量频繁的发布是Linux开发模式的一个重要部分，多数开发人员(包括我)过去都相信这对大型工程来说是个不好的策略，因为早期版本都是些充满错误的版本，而你不想耗光用户的耐心。

　　这种信仰强化了建造大教堂开发方式的必要性，如果目标是让用户尽可能少的见到错误，那你怎能不会仅仅每六个月发布一次(或更不经常)，而且在发布之间象一只狗一样辛勤“捉虫”呢? Emacs C内核就是以这种方式开发的，Lisp库，实际上却相反，因为有一些有FSF控制之外的Lisp库，在那里你可以独立于Emacs发布周期地找寻新的和开发代码版本。

　　这其中最重要的是Ohio州的elisp库，预示了今天的巨大的Linux库的许多特征的精神，但是我们很少真正仔细考虑我们在做什么，或者这个库的存在指出了FSF建造教堂式开发模式的什么问题，1992年我曾经做了一次严肃的尝试，想把Ohio的大量代码正式合并到Emacs的官方Lisp库中，结果我陷入了政治斗争中，彻底失败了。

　　但是一年之后，在Linux广泛应用之后，很清楚，一些不同的更加健康的东西诞生了，Linus的开发模式正好与建造教堂方式相反，Sunsite和tsx-11的库开始成长，推动了许多发布。所有这些都是闻所未闻的频繁的内核系统的发布所推动的。

　　Linus以所有实际可能的方式把它的用户作为协作开发人员。

　　7. 早发布、常发布、听取客户的建议

　　Linus的创新并不是这个(这在Unix世界中是一个长期传统)，而是把它扩展到和他所开发的东西的复杂程度相匹配的地步，在早期一天一次发布对他来说都不是罕见的!而且因为他培育了他的协作开发者基础，比其他任何人更努力地充分利用了Internet进行合作，所以这确实能行。

　　但是它是怎样进行的呢?它是我能模仿的吗?还是这依赖于Linus的独特天才?

　　我不这样想，我承认Linus是一个极好的黑客(我们有多少人能够做出一个完整的高质量的操作系统内核?)，但是Linux并不是一个令人敬畏的概念上的飞跃，Linus不是(至少还不曾是)象Richard stallman或James Gosling一样的创新天才，在我看来，Linus更象一个工程天才，具有避免错误和开发失败的第六感觉，掌握了发现从A点到B点代价最小的路径的决窍，确实，Linux的整个设计受益于这个特质，并反映出Linus的本质上保守和简化设计的方法。

　　如果快速的发布和充分利用Internet不是偶然而是Linus的对代价最小的路径的洞察力的工程天才的内在部分，那么他极大增强了什么?他创建了什么样的方法?

　　问题回答了它自己，Linus保持他的黑客用户经常受到激励和奖赏：被行动的自我满足的希望所激励，而奖赏则是经常(甚至每天)都看到工作在进步。

　　Linus直接瞄准了争取最多的投入调试和开发的人时，甚至冒代码不稳定和一旦有非常棘手的错误而失去用户基础的险，Linus似乎相信下面这个：

　　8. 如果有一个足够大的beta测试人员和协作开发人员的基础，几乎所有的
问题都可以被快速的找出并被一些人纠正。

　　或者更不正式的讲：“如果有足够多的眼睛，所有的错误都是浅显的”(群众的眼睛是雪亮的)，我把这称为“Linus定律”。

　　我最初的表述是每个问题“对某些人是透明的”，Linus反对说，理解和修订问题的那个人不一定非是甚至往往不是首先发现它的人，“某个人发现了问题”，他说，“另一个理解它，我认为发现它是个更大的挑战”，但是要点是所有事都趋向于迅速发生。

　　我认为这是建造教堂和集市模式的核心区别，在建造教堂模式的编程模式看来，错误和编程问题是狡猾的、阴险的、隐藏很深的现象，花费几个月的仔细检查，也不能给你多大确保把它们都挑出来的信心，因此很长的发布周期，和在长期等待之后并没有得到完美的版本发布所引起的失望都是不可避免的。

　　以市集模式观点来看，在另一方面，我们认为错误是浅显的现象，或者至少当暴露给上千个热切的协作开发人员，让他们来对每个新发布进行测试的时候，它们很快变得浅显了，所以我们经常发布来获得更多的更正，作为一个有益的副作用，如果你偶尔做了一个笨拙的修改，也不会损失太多。也许我们本不应该这样的惊奇，社会学家在几年前已经发现一群相同专业的(或相同无知的)观察者的平均观点比在其中随机挑选一个来得更加可靠，他们称此为“Delhpi效应”，Linus所显示的证明在调试一个操作系统时它也适用——Delphi效应甚至可以战胜操作系统内核一级的复杂度。

　　我受Jeff Dutky (dutky @ wam.umd.edu)的启发指出Linus定律可以重新表述为“调试可以并行”，Jeff观察到虽然调试工作需要调试人员和对应的开发人员相交流，但它不需要在调试人员之间进行大量的协调，于是它就没有陷入开发时遇到的平方复杂度和管理开销。

　　在实际中，由于重复劳动而导致的理论上的丧失效率的现象在Linux世界中并不是一个大问题，“早发布、常发布策略”的一个效果就是利用快速的传播反馈修订来使重复劳动达到最小。

　　Brooks甚至做了一个与Jeff相关的更精确的观察：“维护一个广泛使用的程序的成本一般是其开发成本的40%，奇怪的是这个成本受到用户个数的强烈影响，更多的用户发现更多的错误”(我的强调)。

　　更多的用户发现更多的错误是因为更多的用户提供了更多测试程序的方法，当用户是协作开发人员时这个效果被放大了，每个找寻错误的人都有自己稍微不同的感觉和分析工具，从不同角度来看待问题。“Delphi效应”似乎因为这个变体工作变得更加精确，在调试的情况下，这个变体同时减小了重复劳动。

　　所以加入更多的beta测试人员虽不能从开发人员的P.O.V中减小“最深”的错误的复杂度，但是它增加了这样一种可能性，即某个人的工具和问题正好匹配，而这个错误对这个人来说是浅显的。

　　Linus也做了一些改进，如果有一些严重的错误，Linux内核的版本在编号上做了些处理，让用户可以自己选择是运行上一个“稳定”的版本，还是冒遇到错误的险而得到新特征，这个战略还没被大多数Linux黑客所仿效，但它应该被仿效，存在两个选择的事实让二者都很吸引　人。

　　
五. 什么时候玫瑰不是玫瑰?

　　在研究了Linus的行为和形成了为什么它成功的理论之后，我决定在我的工程(显然没有那么复杂和雄心勃勃)里有意识的测试这个理论。
但我首先做的事是熟悉和简化Popclient。 Carl Harris的实现非常好，但是有一种对许多C程序来说没有必要的复杂性。他把代码当作核心而把数据结构当作对代码的支持，结果是代码非常漂亮但是数据结构设计得很特别，相当丑陋(至少对以这个老LISP黑客的标准来看)，然而除了提高代码和数据结构设计之外，重写它还有一个目的，就是要把它演化为我彻底理解的东西，对修改你不理解的程序中的错误负责可不是一件有趣的事。

　　第一个月我只是在领会Carl’s的基本设计的含义，我所做的第一个重大修改是加入了IMAP支持，我把协议机重新组织为一个通用驱动程序和三个方法表(对应POP2、POP3å’ŒIMAP)，这个前面的修改指出一个需要程序员(特别是象C这种没有自然的动态类型支持的语言)记在脑中的一般原理：

　　9. 聪明的数据结构和笨拙的代码要比相反的搭配工作的更好

　　Fred Brooks也在他第11章中讲道：“让我看你的［代码］，把你的[数据结构]隐藏起来，我还是会迷惑；让我看看你的[数据结构]，那我就不需要你的[代码]了，它是显而易见的”。

　　实际上，他说的是“流程图”和“表”，但是在三十年的术语／文化演进之后，事情还是一样的。

　　此时(1996年9月初，在从零开始六个月后)，我开始想接下来修改名字——毕竟，它已不仅仅是一个POP客户，但我犹豫了，因为还没有什么新的漂亮设计呢，我的popclient版本需要有自己的特色。

　　当fetehmail学会怎样把取到的邮件转送到SMTP端口时，事情就完全改变了，但是首先：上面我说过我决定使用这个工程来测试我关于Linus Torualds所做的行为的理论，(你可能会问)我怎样做到这点呢? 以下面的方式：
　　　　1. 我尽早尽量频繁的发布(几乎从未少于每十天发布一次；在密集开发的时候是每天一次)。
　　　　2. 我把每一个和我讨论fetchmail的人加入一个beta表中。
　　　　3. 每当我发布我都向beta表中的人发出通告，鼓励人们参与。
　　　　4. 我听取beta测试员的意见，向他们询问设计决策，对他们寄来的补丁和反馈表示感谢。

　　这些简单的手段立即收到的回报，在工程的开始，我收到了一些错误报告，其质量足以使开发者因此被杀掉，而且经常还附有补丁、我得到了理智的批评，有趣的邮件，和聪明的特征建议，这导致了：

　　10. 如果你象对待最宝贵的资源一样对待你的beta测试员，他们就会成为你最宝贵的资源。

六. popclient变成了Fetchmail

　　这个工程的真正转折点是Harry Hochleiser寄给我他写的代码草稿，他把邮件转发到客户端机器的SMTP端口，我立即意识到这个特征的可靠实现将淘汰所有其他的递送模式。

　　几个星期以来我一直在修改而不是改进fetchmail，因为我觉得界面设计虽然有用但是太笨拙琐碎了，到处充满了太多的粗陋的细小选项。

　　当我思考SMTP转发时我发现popclient试图做的事太多了，它被设计成既是一个邮件传输代理(MTA)也是一个本地递送代理(MDA)。使用SMTP转发，它就可以从MDA的事务中解脱出来而成为一个纯MTA，而象sendmail一样把邮件交给本地递送程序来处理。

　　既然端口25在所有支撑TCP／IP的平台上早已被预留，为什么还要为一个邮件传输代理的配置或为一个邮箱设置加锁的附加功能而操心呢?尤其是当这意味着抽取的邮件就象一个正常的发送者发出的SMTP邮件一样，而这就是我们需要的。

　　这里有几个教益：ç¬
¬ä¸€ï¼ŒSMTP转发的想法是我有意识地模拟Linus的方法以来的最大的单个回报，一个用户告诉我这个非同寻常的想法——我所需做的只是理解它的含义。

　　11. 想出好主意是好事，从你的用户那里发现好主意也是好事，有时候后者更好。

　　很有趣的是，你很快将发现，如果你完全承认你从其他人那里得到多少教益的话，整个世界将会认为所有的发明都是你做出的，而你会对你的天才变得谦虚。我们可以看到这在Linus身上体现得多明显!(当我在1997年8月的Perl会议上发表这个论文时，Larry Wall坐在前排，当我讲到上面的观点时，他激动的叫了出来：“对了!说对了!哥们!”所有的听众都哄堂大笑起来，因为他们知道同样的事情也发生在Perl的发明者身上)。

　　于是在同样精神指导下工程进行了几个星期，我开始不光从我的用户那儿也从听说我的系统的人那儿得到类似的赞扬，我把一些这种邮件收藏起来，我将在我开始怀疑自己的生命是否有价值时重新读读这些信。:)

　　但是有两个更基本的，非政治性的对所有设计都有普遍意义的教益。

　　12. 最重要和最有创新的解决方案常常来自于你认识到你对问题的概念是错误的。

　　一个衡量fetchmail成功的有趣方式是工程的beta测试人员表(fegtchmail的朋友们)的长度，在创立它的时候已经有249个成员了，而且每个星期增加两到三个。

　　实际上，当我在1997年5月校订它时，这张表开始因为一个有趣的原因而缩短了，有几个人请求我把他们从表中去掉，因为fetchmail已经工作的如此之好，他们不需要看到这些邮件了!也许这是一个成熟的市集风格工程的生命周期的一部分。

　　我以前一直在解决错误的问题，把popclient当作MTA和具有许多本地递送模式的MDA的结合物，Fetchmail的设计需要从头考虑为一个纯的MTA，做为一个普通Internet邮件路径的一部分。

　　当你在开发中碰了壁时(当你发现自己很难想通下一步时)，那通常不是要问自己是否找到正确答案，而是要问是否问了正确问题，也许需要重新构造问题。

　　于是，我重新构造了我的问题，很清楚，要做的正确的事是(1)把SMTP转发支持放在通用驱动程序中，(2)把它做为缺省模式，(3)最终分离所有其他的递送模式，尤其是递送到文件和标准输出的选项。

　　我在第三步上犹豫了一下，担心会让popdiant的长期用户对新的递送方法感到烦心，在理论上，他们可以立即转而转发文件或者他们的非sendmail等价物来得到同样的效果，在实际中这种转换可能会很麻烦。
但是当我这么做之后，证明好处是巨大的，驱动程序代码的冗余的部分消失了，配置完全变得简单了——不用屈从于系统MDA和用户的邮箱，也不用为下层OS是否支持文件锁定而担心了。

　　而且，丢失邮件的唯一漏洞也被堵死了，如果你选择了递送到一个文件而磁盘已满，你的邮件就会丢失，这在SMTP转发中不会发生，因为SMTP侦听器不会返回OK的，除非邮件可以递送成功或至少被缓冲留待以后递送。

　　还有，性能也改善了(虽然在单次执行中你不会注意到)，这个修改的另一个不可忽视的好处是手册变得大大简单了。

　　后来，为了允许处理一些罕见的情况，包括动态SLIP，我必须回到让用户定义本地MDA递送上来，但是我发现了一个更加简单的方法。

　　所有这些给了我们什么启发呢?如果可以不损失效率，就要毫不犹豫抛弃陈旧的特性，Antonine de Saint-Exupery(在他成为经典儿童书籍作家之前是一个飞行员和飞机设计师)曾说过：

　　13. “最好的设计不是再也没有什么东西可以添加了，而是再也没有什么东西可以去掉。”

　　当你的代码变得更好和更简单时，这就是你知道它是正确的时候了，而且在这个过程中，fetehmail的设计具有了自己的特点，而区别于其前身popclient。

　　现在是改名的时候了，这个新的设计看起来比老popclient更象一个sendmail的复制品，它们都是MTA，但是Senmail是推然后递送，而新的popclient是拉然后递送。于是，在两个月之后，我把它重新命名为fetehmail。

七. Fetchmail成长起来

　　现在我有了一个简洁和富有创意的设计，工作得很好的代码，因为我每天都用它，和一直在增长的beta表，它让我渐渐明白我已经不是在从事只能对少数其他人有用的工作中，我写了一个所有有一个Unix邮箱和SLIP／PPP邮件连接的人都真正需要的程序。

　　通过SMTP转发功能，它成为一个潜在的“目录杀手”，远远领先于它的竞争者，这个程序如此能干以至于其他的程序不但被放弃简直被忘记了。

　　我知道你不可以真得瞄准或计划出这样的结果，你只能努力去设计这些强大的思想，以后这些结果就好象是不可避免的、自然的、注定了的，得到这种思想的唯一办法是获取许多思想，或者用工程化的思考其他人的好主意而超过原来想到它的人的设想。

　　Andrew Tanenbanm原来设想建造一个适合386的简单的Unix用做教学，Linus Torvalels把Andrew的可能想到的Minix可以做什么的概念推进了一步，成长为一个极好的东西，同样的(虽然规模较小)，我接受了Card Harris和Harry Hochheiser的想法，把它们变得更强大，我们都不是人们所浪漫幻想的天才的创始人，但是大多数科学和工程和软件开发不是被天才的创始人完成的，这和流传的神话恰恰相反。

　　结果总是执着的原因——实际上，它是每个黑客为之生存的成功!而且它们意味着我必须把自己的标准定高一点，为了把fetchmail变得和我所能设想的那样好，我必须不仅为我自己的需要写代码，而且也要包括对在我生活围主页外的人们的需求的支持，而且同时也要保证程序的简单和健壮。

　　在实现它之后我首先写的最重要的特征是支持多投——从集中一组用户的邮件的邮箱中取出邮件，然后把它路由到每个人手中。

　　我之所以加上多投功能部分是因为有些用户一直在闹着要它，更是因为我想它可以从单投的代码中揭露出错误来，让我完全一般地处理寻址，而且这被证明了。正确解释RFC822花了我相当长的时间，不仅因为它的每个单独部分都很难，而且因为它有一大堆相互依赖的苛刻的细节。

　　但是多投寻址也成为一个极好的设计决策，由此我知道：

　　14. 任何工具都应该能以预想的方式使用，但是一个伟大的工具提供你没料到的功能。

　　Fetchmant多投功能的一个没有料到的用途是在SLIP／PPP的客户端提供邮件列表、别名扩展。这意味着一个使用个人机器的人不必持续访问ISP的别名文件就能通过一个ISP帐户管理一个邮件列表。我的beta测试员提出的另一个重要的改变是支持8位MIME操作，这很容易做，因为我已经仔细的保证了8位代码的清晰，不仅因为我预见到了这个特性的需求，而且因为我忠实于另一准则：

　　15. 当写任何种类的网关型程序时，多费点力，尽量少干扰数据流，永远不要抛弃信息，除非接
收方强迫这么作!

　　如果我不遵从这个准则，那么8位MIME支持将会变得困难和笨拙，现在我所需要做的，是只读一下RFC 1652，在产生信头的逻辑加上一点而已。

　　一些欧洲用户要求我加上一个选项来限制每次会话取得消息数(这样他们就可以从昂贵的电话网中控制花费了)，我很长一段时间拒绝这样做，而且我仍然对它不很高兴，但是如果你是为了世界而写代码，你必须听取顾客的意见——这并不随他们不付给你钱而改变。

八. 从Fetchmail得来的另一些教益

　　在他们回到一般的软件工程问题以前，还有几个从fetchmail得到的教益需要思考。

　　rc文件语法包括可选的“noise”关键字，它被扫描器完全忽略了，当你把它们全抽取出的时候，关键字／值对更具可读性。

　　当我注意到rc文件的声明在多大程度上开始象一个微型命令语言时，这是一个Late-night的体验(这也是我为什么把popclient原来的“server”关键字改成了“poll”)。

　　对我来说似乎把这个微型命令语言变得更象英语可能会使它更容易使用。现在，虽然我对经过Emacs和HTML及许多数据库引擎所证实的“把它做成一个语言”的设计方式确信不疑，但是我并不是一个通常的“类英语”语法的狂热拥护者。

　　传统程序员容易控制语法使它尽量精确和紧凑，完全没有冗余，这是计算机资源还很昂贵时遗留下的一种文化传统，所以扫描策略需要尽可能的廉价和简单，而具有50%冗余度的英语，看来好象是一个非常不合适的模型。

　　这并不是我不用类英语语法的原因，我提到这一点是为了推翻它，在更廉价的时钟周期与核心的时代，简洁并没有走到尽头，今天对一个语言来说，对人更方便比对机器更廉价来的更加重要。

　　然而，有几个原因提醒我们小心一点，一个是扫描策略的复杂度开销——你并不想把它变成一个巨大的错误来源和让用户困惑，另一个是试图使语言表面上的类似可以和传统语言一样令人困惑(你可以在许多4GL和商业数据库查询语言上看到这一点)。

　　Fetchmail的控制语法避免了这些问题，因为语言的领域是极其有限的。它一点也不象一个一般性的语言，它很简单地描述的东西并不复杂，所以很少可能在英语的一个小子集与实际的控制语言之间发生混淆，我想这有一个更广泛的教益：

　　16. 如果你的语言一点也不象是图灵完备的，严格的语法会有好处。

　　另一个教益是关于安全的，一些fetchmail用户要求我修改软件把口令加密存贮在rc文件里，这样觑探者就不能看到它们了。

　　我没有这样做，因为这实际上起不到任何保护作用，任何有权读取你的rc文件的人都可以以你的名义运行fetchmail——如果他们要破你的口令，它们可以从fetchmail的代码中找到制作解码器的方法。

　　所以fetchmail口令的加密都会给那些不慎重思考的人一种安全的错觉，这里一般性的准则是：

　　17. 一个安全系统只能和它的秘密一样安全，当心伪安全。

九. 集市风格的必要的先决条件

　　本文的早期评审人员和测试人员坚持提出成功的市集模式开发的先决条件，包括工程领导人的资格问题和在把项目公开和开始建造一个协作开发人员的社团的时候代码的状态。

　　相当清楚，不能以一个市集模式从头开发一个软件，我们可以以市集模式、测试、调试和改进，但是以市集模式从头开始一个项目将是非常困难的，Linus没有这样做，我也没有，初期的开发人员的社团应该有一此可以运行和测试的东西来玩。

　　当你开始创建社团时，你需要演示的是一个诺言，你的程序不需要工作的很好，它可以很粗糙、很笨拙、不完整和缺少文档、它不能忽略的东西是要吸引哪些人卷入一个整洁的项目。

　　Linux和fetchmail都是以一个吸引人的基本设计进入公共领域的，许多和我一样在思考市集模式的人已经正确的认为这是非常关键的，然后得出了一个结论，工程领导者的高度的设计直觉和聪颖是必不可少的。

　　但是Linus是从Unix得到他的设计的，我最初是从先前的popmail得到启发的(虽然相对Linux而言，它最后改变巨大)，所以市集风格的领导人／协调人需要有出众的设计才能，或者他可以利用别人的设计才能?

　　我认为能够提出卓越的原始设计思想对协调人来说不是最关键的，但是对他／她来说绝对关键的是要能把从他人那里得到的好的设计重新组织起来。

　　Linux和fetchmail项目都显示了这些证据，Linus(如同前面所说)并不是惊人的原始设计者，但他显示了发现好的设计并把它集成到Linux内核中的强大决窍。还有我也描述了怎样从别人那里得到了fetchmail中最强大的设计思想(SMTP转发)。

　　本文的早期读者称赞我，说因为我做了许多关于原始设计的事，所以倾向于低估原始设计在市集项目中的价值，也许有些是对的吧，但是设计(而不是编码或调试)本来就是我最强的能力。

　　变得聪明和软件设计的原始创作的问题是它会变成一个习惯，当需要保持事物健壮和简洁的时候，你却开始把事情变得漂亮但却复杂。我曾经犯过错误，使得一些项目因我而崩溃了，但我努力不让它发生在fetchmail身上。

　　所以我相信fetchmail项目的成功部分是因为我抑制自己不要变得太聪明，这说明(至少)对市集模式而言原始设计并不是本质的，请考察一下Linux假设Linus Torvalds在开发时试图彻底革新操作系统设计，它还会象今天我们所拥有的内核那样稳定和成功吗?

　　当然基本的设计和编码技巧还是必需的，但我希望每个严肃考虑发起一个市集计划的人都已至少具备这些能力，自由软件社团的内部市场对人们有某些微妙的压力，让他们不要发起自由不能搞定的开发，目前为止，这工作得仍然相当好。

　　对市集项目来说，我认为还有另一种通常与软件开发无关的技能和设计能力同样重要——或者更加重要，市集项目的协调人或领导人必须有良好的人际和交流能力。

　　这是很显然的，为了建造一个开发社团，你需要吸引人，你所做的东西要让他们感到有趣，而且要保持他们对他们正在做的工作感到有趣，而且要保持他们对他们正在做的工作感到高兴，技术方面对达成这些目标有一定帮助，但这远远不是全部，你的个人素质也有关系。

　　并不是说Linus是一个好小伙子，让人们喜爱并乐于帮助他，也并不是说我是个积极外向的，喜欢扎堆儿工作，有出众的幽默感的人，对市集模式的工作而言，至少有一点吸引人的技巧是非常有帮助的。

十. 自由软件的社会学语境

   　下述如实：最好的开发是从作者解决每天工作中的个人问题开始的，因为它对一大类用户来说是一个典型问题，所以它就推广开来了，这把我们带回到准则1，也许是用一个更有ç
”¨çš„方式来描述：

　　18. 要解决一个有趣的问题，请从发现让你感兴趣的问题开始。

　　这是Carl Harris和原先的popclient的情形，也是我和fetchmail的情形，但这已在很长一段时间被大家知晓了，Linux和fetchmail的历史要求我们注意的有趣之处是下一个阶段——软件在一个庞大的活跃的用户和协作开发人员的社团中的进化。

　　在《神秘的人月》一书中，Fred Brooks观察到程序员的工作时间是不可替代的：在一个误了工期的软件项目中增加开发人员只会让它拖得更久，他声称项目的复杂度和通讯开销以开发人员的平方增长，而工作成绩只是以线性增长，这个说法被称为“Brooks定律”，被普遍当作真理，但如果Brooks定律就是全部，那Linux就不可能成功。

　　几年之后，Gerald Weinbeng的经典之作“The Psychology Of Computer Progromming”为我们更正了Brooks的看法，在他的“忘我(egoless)的编程”中，Weinberg观察到在开发人员不顽固保守自己的代码，鼓励其他人寻找错误和发展潜力的地方，软件的改进的速度会比其他地方有戏剧性的提高。

　　Weinberg的用词可阻止了他的分析得到应有的接受，人们对把Internet黑客称为“忘我”的想法微笑，但是我想今天他的想法比以往任何时候都要引人注目。

　　Unix的历史已经为我们准备好了我们正在从Linux学到的(和我在更小规模上模仿Linus的方法所验证的)东西，这就是，虽然编码仍是一个人干的活，真正伟大的工作来自于利用整个社团的注意和脑力，在一个封闭的项目中只利用他自己的脑力的人会落在知道怎样创建一个开放的、进化的，成百上千的人在其中查找错误和进行修改的环境的开发人员之后。

　　但是Unix的传统中有几个因素阻止把这种方法推到极致。一个是各种授权的法律约束、商业机密和商业利益，另一个(事后来看)是Internet还不够好。

　　在Internet变得便宜之前，有一些在地理上紧密的社团，它们的文化鼓励Weingberg的“忘我”编程，一个开发人员很容易吸引许多熟练的人和协作开发人员，贝尔实验室，MIT A1实验室，UC Berkeley，都成为传统的、今天仍然是革新的源泉。

　　Linux是第一个有意识的成功的利用整个世界做为它的头脑库的项目，我不认为Linux的孕育和万维网的诞生相一致是一个巧合，而且Linux在1993-1994的一段ISP工业大发展和对Internet的兴趣爆炸式增长的时期中成长起来，Linus是第一个学会怎样利用Internet的新规的人。

　　廉价的Internet对Linux模式的演化来说是一个必要条件，但它并不充分，另一个关键因素是领导风格的开发和一套协作的氛围使开发人员可以吸引协作开发人员和最大限度地利用媒体。

　　但是这种领导风格与氛围到底是什么呢?它不能建立在权力关系之上——甚至如果它们可以，高压的领导权力不能产生我们所看到的结果，Weinberg引用了19世纪俄国的无政府主义者Kropotkin的“Memoris of a Revolutionist”来证明这个观点：

　　“我从小生活在一个农奴主的家庭中，我有一个活跃的生活，象我们时代的所有年轻人一样，我深信命令、强制、责骂、惩罚等等的必要性。但是当我(在早期)必须管理一个企业，和(自由)人打交道时，当每一个错误都会产生严重后果时，我开始接受以命令和纪律为准则来行动和以普通理解为准则来行动的区别。前者在军事阅兵中工作的很好，但是它在现实生活中一文不值，目标达成只是靠许多愿望的聚合的简单后果。”“许多聚合在一起的愿望的直接后果”精确地指出了象Linux的项目所需要的东西。“命令的准则”在Internet这种无政府主义的天堂中一群自愿者之中是没有市场的，为了更有效的操作和竞争，想领导协作项目的黑客们必须学会怎样以Kropotkins含糊指出的“理解的准则”模式来恢复和激活社团的力量，他们必须学会使用Linus定律。

　　前面我引用“Delhpi效应”来作为Linus定律的一个可能的解释，但是来自生物学和经常学的自适应系统的更强大的分析也提出了自己的解释，Linus世界的行为更象一个自由市场或生态系统，由一大群自私的个体组成，它们试图取得(自己)最大的实效，在这个过程中产生了比任何一种中央计划都细致和高效的自发的改进的结果，所以，这里就是寻找“理解的准则”的地方。

　　Linux黑客取得的最大化的“实际利益”不是经典的经济利益，而是无形的他们的自我满足和在其他黑客中的声望，(有人会说他们的动机是“利他的”，但这忽略了这样的事实：利他主义本身是利他主义者的一种自我满足的形式)，自愿的文化以这种方式工作的实际上并非不寻常，我已参与一个科幻迷团体很长时间了，它不象黑客团体一样，显式地识别出“egoboo”(一个人在其他爱好者之中的声望的增长)作为自愿者活动背后的基础驱动力)。

　　Linus成功地把自己置于项目的守门人的位置，在项目中开发大部分是别人做的，他只是在项目中培养兴趣直到它可以自己发展下去，这为我们展示了对Kropokin的“共同理解原则”的敏锐把握，对Linux这种类似经济学的观点让我们看到这种理解是怎样应用的。

　　我们可以把Linus的方法视为创建一个高效的关于“egoboo”(而不是钱)的市场，来把自私的黑客个体尽可能紧密的联系起来，达成只能通过高度协作才能得到的困难的结果，在fetchmail项目中我展示了(在较小规模上)这种模式可以复制，得到良好的结果，也许我比他更有意识一点、更加系统一点。

　　许多人(尤其是哪些由于政治原因不信任自由市场的人)会盼望自我导向的自我主义者的文化破碎、报废、秘密和敌对，但这种盼望很明显地被Linux的文档的多样性、质量和深度打破了，程序员讨厌写文档似乎已是圣训，但Linux的黑客们怎么产生了这么多?显然Linux的egoboo自由市场比有大量资金的商业软件产品的文档部在产生有品德的、他人导向的行为方面工作的更好。

　　Fetchmail和Linux内核项目都表明，通过恰当的表彰许多其他黑客，一个强大的开发者／协调者可以用Internet得到许多协同开发人员而不是让项目分崩离析为一片混乱，所以关于Brooks定律我得到了下面的想法：

　　19. 如果开发协调人员有至少和Internet一样好的媒介，而且知道怎样不通过强迫来领导，许多头脑将不可避免地比一个好。

　　我认为自由软件的将来将属于那些知道怎样玩Linus的游戏的人，把大教堂抛之脑后拥抱市集的人，这并不是说个人的观点与才气不再重要，而是，我认为自由软件的前沿将属于从个人观点和才气出发的人，然后通过共同兴趣自愿社团的高效建造来扩展。

　　可能不只是自由软件的将来，在解决问题方面，没有任何商业性开发者可以与Linux社团的头脑库相匹敌，很少有人能负担起雇佣200多个为fetchmail出过力的人!

　　也许最终自由软件文化将胜利，不是因为协作在道德上是正确的或软件“囤积居奇”在道德上是错的(假设你相信后者，Linus和我都不)，而仅仅是因为商业世界在进化的军备竞赛中不能战胜自由软件社团，因为后者可以把更å
¤§æ›´å¥½çš„开发资源放在解决问题上。

**** 网友写给作者的感想: ****

你好，Eric：
我刚读了你的大教堂／市集的文章，因为你的主页指出你还要继续关于这个问题的思考，我提供一些个人的观察。
首先介绍一些背景：当1990年出现BSD Net／2的时候，Brad Grantham和我把它移植到了MacⅡ平台上，它在几个月之后以Mac BSD发布(当然是以市集风格)，后来成为Net BSD／Mac。
我作为一个市集协调人学到了一些东西：

1. 人们很快地自愿提供帮助，但是常常很慢，我们收到上百封信说：“我很想帮助，请告诉我需要什么?” 这些人没提供什么帮助，不管他们有多么积极，真正有帮助的人那些给我们的第一封信便说：“嘿，我修改了这个，这儿有一个补丁。”最后我们忽略了所有第一种类型的邮件(只是把他们引向工作列表)，培养与第二种人的关系，这种情况所有协调人都应知道，来克服看到这么多“志愿者”时的盲目高兴。
(注意：他们的动机是好的，他们只是没有认识到他们正在志愿做什么)。

2. 你已经提到了这一点，但我认为它是极端重要的：甚至在你宣布产品以前你必须有一个可工作的系统：例如，我们一直等到有了一个可引导的内核和一个单用户根shell之后才把它贴到Usenet，曾有过(据我所知)四个不同的Mac Linux项目，每一个都在Linux新闻组中有一大批拥护者，都创建了邮件列表，每个人都很热情，写了FAQ，还有许多诸如MacOS的图标应是什么样的讨论。所有这些项目没有发布一行代码或者一个内核、我挑选了MkLinux(Apple开发的)作为一个可工作的Mac版Linux(在一个项目中，MacLinux假设运转在68K Mac上，而邮件列表中所有的讨论都是关于怎样把它移植到Power Mac上。68K版本甚至不能远程工作!)，这些项目吸引了上述的第一种“帮助者”，热情高涨但是实际上却没做什么事，杀掉一个项目最快的方法是在你什么都还没有之前就宣布它，我已经见的太多了，尤其是在
Linux世界里。

我知道这两点看起来相当悲观，但我知道当我们想到“啊，我们做了这么多事了，肯定搞定了不少问题了吧！”的时候，我们太容易失去理智。而那实际上只不过是一些善良的动机罢了(谁说过：“不要把动机和行动混淆在一起?” 本·弗兰克林？)协调人需要解散所有那些诸如图标应该是什么样的、FAQ用HTML格式还是SGML模式的热情讨论，而把注意力放在取得产品的一个可工作的版本，一旦得到了，人们就真正开始帮助了。

（从正面来看，MacBSD极大地得益于从它的开发风格，我们得到了代码、设备驱动程序、钱和一些捐赠和借到的测试和开发的硬件设备)。
我期望看到对我上述观点的任何评论和你关于这个主题写的任何东西。

Lawrrance