⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 00000006.htm

📁 一份很好的linux入门资料
💻 HTM
📖 第 1 页 / 共 4 页
字号:
<HTML><HEAD>  <TITLE>BBS水木清华站∶精华区</TITLE></HEAD><BODY><CENTER><H1>BBS水木清华站∶精华区</H1></CENTER>发信人:&nbsp;reden&nbsp;(鱼&nbsp;~&nbsp;梦娜丽莎的微笑&nbsp;流星的故事),&nbsp;信区:&nbsp;Linux&nbsp;<BR>标&nbsp;&nbsp;题:&nbsp;[范文][AKA]大教堂与市集(Eric&nbsp;Raymond)&nbsp;(转载)&nbsp;<BR>发信站:&nbsp;BBS&nbsp;水木清华站&nbsp;(Wed&nbsp;Nov&nbsp;18&nbsp;17:28:37&nbsp;1998)&nbsp;<BR>&nbsp;<BR>【&nbsp;以下文字转载自&nbsp;FreeDevelop&nbsp;讨论区&nbsp;】&nbsp;<BR>【&nbsp;原文由&nbsp;Aka&nbsp;所发表&nbsp;】&nbsp;<BR>说明:&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;本文的作者Eric&nbsp;Raymond是Open&nbsp;Source&nbsp;Software领域的领袖,这方面许多&nbsp;<BR>新的思想正是从他那儿产生的,同时他也是UNIX上最流行的Email软件Fetchmail&nbsp;<BR>的作者。&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;下面这篇文章有点儿长,然而它是值得你去耐心把它读完的。文章以Fetchmail&nbsp;<BR>为例,讨论了Internet上集市风格的开发方式。&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;我们应该感谢HansB,是他把这篇长文章翻译成了中文。&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;Eric的主页地址在:<A HREF="http://www.tuxedo.org/~esr/">http://www.tuxedo.org/~esr/</A>&nbsp;<BR>&nbsp;<BR>-------------------------------------------------------------------------&nbsp;<BR>&nbsp;<BR>一.&nbsp;大教堂和市集&nbsp;<BR>&nbsp;<BR>  Linux的影响是非常巨大的。甚至在5年以前,有谁能够想象一个世界级的操&nbsp;<BR>作系统能够仅仅用细细的Internet连接起来的散布在全球的几千个开发人员有以业&nbsp;<BR>余时间来创造呢?&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;我当然不会这么想。在1993年早期我开始注意Linux时,我已经参与Unix&nbsp;<BR>和自由软件开发达十年之久了。我是八十年代中期GNU最早的几个参与者之一。我&nbsp;<BR>已经在网上发布了大量的自由软件,开发和协助开发了几个至今仍在广泛使用的&nbsp;<BR>程序(Nethack,Emacs&nbsp;VC和GND模式,xlife等等)。我想我知道该怎样做。&nbsp;<BR>&nbsp;<BR>  Linux推翻了许多我认为自己明白的事情。我已经宣扬小工具、快速原型和演&nbsp;<BR>进式开发的Unix福音多年了。但是我也相信某些重要的复杂的事情需要更集中化的,&nbsp;<BR>严密的方法。我相信多数重要的软件(操作系统和象Emacs一样的真正大型的工具)&nbsp;<BR>需要向建造大教堂一样来开发,需要一群于世隔绝的奇才的细心工作,在成功之前&nbsp;<BR>没有beta版的发布。&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;Linus&nbsp;Torvalds的开发风格(尽早尽多的发布,委托所有可以委托的事,对所&nbsp;<BR>有的改动和融合开放)令人惊奇的降临了。这里没有安静的、虔诚的大教堂的建造&nbsp;<BR>工作——相反,Linux团体看起来像一个巨大的有各种不同议程和方法的乱哄哄的&nbsp;<BR>集市(Linux归档站点接受任何人的建议和作品,并聪明的加以管理),一个一致&nbsp;<BR>而稳定的系统就象奇迹一般从这个集市中产生了。&nbsp;<BR>&nbsp;<BR>  这种设计风格确实能工作,并且工作得很好,这个事实确实是一个冲击。在我&nbsp;<BR>的研究过程中,我不仅在单个工程中努力工作,而且试图理解为什么Linux世界不&nbsp;<BR>仅没有在一片混乱中分崩离析,反而以大教堂建造者们不可想象的速度变得越来越&nbsp;<BR>强大。&nbsp;<BR>&nbsp;<BR>  到了1996年中,我想我开始理解了。我有一个极好的测试我的理论的机会,&nbsp;<BR>以一个自由软件计划的形式,我有意识的是用了市集风格。我这样做了,并取得了&nbsp;<BR>很大的成功。&nbsp;<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;在本文的余下部分,我将讲述这个计划的故事,我用它来明确一些自由软件高&nbsp;<BR>效开发的格言。并不是所有这些都是从Linux世界中学到的,但我们将看到Linux世&nbsp;<BR>界给予了它们一个什么样的位置。如果我是正确的,它们将使你理解是什么使Linux&nbsp;<BR>团体成为好软件的源泉,帮助你变得更加高效。&nbsp;<BR>&nbsp;<BR>二.&nbsp;邮件必须得通过&nbsp;<BR>&nbsp;<BR>  1993年以前我在一个小的免费访问的名为Chester&nbsp;County&nbsp;InterLink的ISP&nbsp;<BR>的做技术工作,它位于Pennsylvania的West&nbsp;Chester。(我协助建立了CCIL,并写了&nbsp;<BR>我们独特的多用户BBS系统——你可以telnet到locke.ccil.org来检测一下。今天它&nbsp;<BR>在十九条线上支持三千的用户)。这个工作使我可以一天二十四小时通过CCIL的56K&nbsp;<BR>专线连在网上,实际上,它要求我这么做!&nbsp;<BR>&nbsp;<BR>  所以,我对Internet&nbsp;email很熟悉。因为复杂的原因,很难在我家里的机器&nbsp;<BR>(snark.thyrsus.com)和CCIL之间用SLIP工作。最后我终于成功了,但我发现不&nbsp;<BR>得不时常telnet到locke来检查我的邮件,这真是太烦了。我所需要的是我的邮件&nbsp;<BR>发送到snark,这样biff(1)会在它到达时通知我。&nbsp;<BR>&nbsp;<BR>  简单地sendmail的转送功能是不够的,因为snark并不是总在网上而且没有一&nbsp;<BR>个静态地址。我需要一个程序通过我的SLIP连接把我的本地发送的邮件拉过来。&nbsp;<BR>我知道这种东西是存在的,它们大多使用一个简单的协议POP(Post&nbsp;Office&nbsp;&nbsp;<BR>Protocol)。而且,locke的BSD/OS操作系统已经自带了一个POP3服务器。&nbsp;<BR>&nbsp;<BR>  我需要一个POP3客户。所以我到网上去找到了一个。实际上,我发现了三、&nbsp;<BR>四个。我用了一会pop-perl,但它却少一个明显的特征:抽取收到的邮件的地址&nbsp;<BR>以便正确回复。&nbsp;<BR>&nbsp;<BR>  问题是这样的:假设locke上一个叫“joe”的人向我发了一封邮件。如果我&nbsp;<BR>把它取到snark上准备回复时,我的邮件程序会很高兴地把它发送给一个不存在的&nbsp;<BR>snark上的“joe”。手工的在地址上加上“<A HREF="mailto:@ccil.org”变成了一个严酷的痛苦。">@ccil.org”变成了一个严酷的痛苦。</A>&nbsp;<BR>&nbsp;<BR>  这显然应是计算机替我做的事。(实际上,依据RFC1123的5.2.18节,&nbsp;<BR>sendmail应该做这件事)。但是没有一个现存的POP客户知道怎样做!于是这就给&nbsp;<BR>我们上了第一课:&nbsp;<BR>  1.每个好的软件工作都开始于搔到了开发者本人的痒处。&nbsp;<BR>也许这应该是显而易见的(“需要是发明之母”长久以来就被证明是正确的),&nbsp;<BR>但是软件开发人员常常把他们的精力放在它们既不需要也不喜欢的程序,但在&nbsp;<BR>Linux世界中却不是这样——这解释了为什么从Linux团体中产生的软件质量都如&nbsp;<BR>此之高。&nbsp;<BR>&nbsp;<BR>  那么,我是否立即投入疯狂的工作中,要编出一个新的POP3客户与现存的那&nbsp;<BR>些竞争呢?才不是哪!我仔细考察了手头上的POP工具,问自己“那一个最接近我&nbsp;<BR>的需要?”因为:&nbsp;<BR>  2.好程序员知道该写什么,伟大的程序员知道该重写(和重用)什么。&nbsp;<BR>&nbsp;<BR>  我并没有声称自己是一个伟大的程序员,可是我试着效仿他们。伟大程序员&nbsp;<BR>的一个重要特点是建设性的懒惰。他们知道你是因为成绩而不是努力得到奖赏,&nbsp;<BR>而且从一个好的实际的解决方案开始总是要比从头干起容易。&nbsp;<BR>&nbsp;<BR>  例如,Linux并不是从头开始写Linux的。相反的它从重用Minix(一个386机&nbsp;<BR>型上的类似Unix的微型操作系统)的代码和思想入手。最后所有的Minix代码都消&nbsp;<BR>失或被彻底的重写了,但是当它们在的时候它为最终成为Linux的雏形做了铺垫。&nbsp;<BR>&nbsp;<BR>  秉承同样的精神,我去寻找良好编码的现成的POP工具,用来作为基础。&nbsp;<BR>&nbsp;<BR>  Unix世界中的代码共享传统一直对代码重用很友好(这正是为什么GNU计划不&nbsp;<BR>管Unix本身有多么保守而选取它作为基础操作系统的原因)。Linux世界把这个传&nbsp;<BR>统推向技术极限:它有几个T字节的源代码可以用。所以在Linux世界中花时间寻&nbsp;<BR>找其他几乎足够好的东西,会比在别处带来更好的结果。&nbsp;<BR>&nbsp;<BR>  这也适合我。加上我先前发现的,第二次寻找找到了9个候选者——fetchPOP&nbsp;<BR>,PopTart,get-mail,gwpop,pimp,pop-perl,popc,popmail&nbsp;和&nbsp;upop)。我&nbsp;<BR>首先选定的是“fetchpop”。我加入了头标重写功能,并且做了一些被作者加入&nbsp;<BR>他的1.9版中的改进。&nbsp;<BR>&nbsp;<BR>  但是几个星期之后,我偶然发现了Carl&nbsp;Harris写的“popclient”的代码,&nbsp;<BR>然后发现有个问题,虽然fetchpop有一些好的原始思想(比如它的守护进程模式),&nbsp;<BR>它只能处理pop3,而且编码的水平相当业余(Seung-Hong是个很聪明但是经验不足&nbsp;<BR>的程序员),Carl的代码更好一些,相当专业和稳固,但他的程序缺少几个重要的&nbsp;<BR>相当容易实现的fetchpop的特征(包括我自己写的那些)。&nbsp;<BR>&nbsp;<BR>  继续呢还是换一个?&nbsp;如果换一个的话,作为得到一个更好开发基础的代价,&nbsp;<BR>我就要扔掉我已经有的那些代码。&nbsp;<BR>&nbsp;<BR>  换一个的一个实际的动机是支持多协议,pop3是用的最广的邮局协议,但并&nbsp;<BR>非唯一一个,Fetchpop和其余几个没有实现POP2.RPOP,或者APOP,而且我还有一&nbsp;<BR>个为了兴趣加入IMAP(Internet&nbsp;Message&nbsp;Access&nbsp;Protocol,最近设计的最强大的&nbsp;<BR>邮局协议)的模糊想法。&nbsp;<BR>&nbsp;<BR>  但是我有一个更加理论化的原因认为换一下会是一个好主意,这是我在Linux&nbsp;<BR>很久以前学到的:&nbsp;<BR> 3.“计划好抛弃,无论如何,你会的”(Fred&nbsp;Brooks,《神秘的人月》第11章)&nbsp;<BR>&nbsp;<BR>  或者换句话说,你常常在第一次实现一个解决方案之后才能理解问题所在,&nbsp;<BR>第二次你也许才足够清楚怎样做好它,因此如果你想做好,准备好推翻重来至少&nbsp;<BR>一次。&nbsp;<BR>&nbsp;<BR>  好吧(我告诉自己),对fetchpop的尝试是我第一次的尝试,因此我换了一下。&nbsp;<BR>&nbsp;<BR>  当我在1996年6月25日把我第一套popclient的补丁程序寄给Carl&nbsp;Harris之&nbsp;<BR>后,我发现一段时间以前他已经对popclient基本上失去了兴趣,这些代码有些陈&nbsp;<BR>旧,有一些次要的错误,我有许多修改要做,我们很快达成一致,我来接手这个&nbsp;<BR>程序。不知不觉的,这个计划扩大了,再也不是我原先打算的在已有的pop客户上&nbsp;<BR>加几个次要的补丁而已了,我得维护整个的工程,而且我脑袋里涌动着一些念头&nbsp;<BR>要引起一个大的变化。&nbsp;<BR>&nbsp;<BR>  在一个鼓励代码共享的软件文化里,这是一个工程进化的自然道路,我要指&nbsp;<BR>出:&nbsp;<BR> 4.&nbsp;如果你有正确的态度,有趣的问题会找上你的,但是Carl&nbsp;Harris的态度甚&nbsp;<BR>至更加重要,他理解:&nbsp;<BR> 5.当你对一个程序失去兴趣时,你最后的责任就是把它传给一个能干的后继者。&nbsp;<BR>&nbsp;<BR>  甚至没有商量,Carl和我知道我们有一个共同目标就是找到最好的解决方&nbsp;<BR>案,对我们来说唯一的问题是我能否证明我有一双坚强的手,他优雅而快速的写&nbsp;<BR>出了程序,我希望轮到我时我也能做到。&nbsp;<BR>&nbsp;<BR>三.&nbsp;拥有用户的重要性&nbsp;<BR>&nbsp;<BR>  于是我继承了popclient,同样重要的是,我继承了popclient的用户基础,&nbsp;<BR>用户是你所拥有的极好的东西,不仅仅是因为他们显示了你正在满足需要,你做&nbsp;<BR>了正确的事情,如果加以适当的培养,他们可以成为合作开发者。&nbsp;<BR>&nbsp;<BR>  Unix传统另一有力之处是许多用户都是黑客,因为源优码是公开的,他们可&nbsp;<BR>以成为高效的黑客,这一点在Linux世界中也被推向了令人高兴的极致,这对缩短&nbsp;<BR>调试时间是极端重要的,在一点鼓励之下,你的用户会诊断问题,提出修订建&nbsp;<BR>议,帮你以远比你期望快得多的速度的改进代码。&nbsp;<BR>&nbsp;<BR> 6.&nbsp;把用户当做协作开发者是快速改进代码和高效调试的无可争辩的方式。&nbsp;<BR>&nbsp;<BR>  这种效果的力量很容易被低估,实际上,几乎所有我们自由软件世界中的人&nbsp;<BR>都强烈低估了用户可以多么有效地对付系统复杂性,直到Linus让我们看到了这一&nbsp;<BR>点。&nbsp;<BR>&nbsp;<BR>  实际上,我认为Linus最聪明最了不起的工作不是创建了Linux内核本身,而&nbsp;<BR>是发明了Linux开发模式,当我有一次当着他的面表达这种观点时,他微笑了一&nbsp;<BR>下,重复了一句他经常说的话:“我基本上是一个懒惰的人,依靠他人的工作来&nbsp;<BR>获取成绩。”象狐狸一样懒惰,或者如Robert&nbsp;Heinlein所说,太懒了而不会失&nbsp;<BR>败。&nbsp;<BR>&nbsp;<BR>  回顾起来,在GNU&nbsp;Emacs&nbsp;Lisp库和Lisp代码集中可以看到Linux方法的成功,&nbsp;<BR>与Emacs的C内核和许多其他FSF的工具相比,Lisp代码库的演化是流动性的和用户&nbsp;<BR>驱动的,思想和原型在达到最终的稳定形式之前往往要重写三或四次,而且经常&nbsp;<BR>利用Internet的松散合作。&nbsp;<BR>&nbsp;<BR>  实际上,我自己在fetchmail之前最成功的作品要算Emacs&nbsp;VC模式,它是三个&nbsp;<BR>其他的人通过电子邮件进行的类似Linux的合作,至今我只见过其中一个人&nbsp;<BR>(Richard&nbsp;Stallman),它是SCCS、RCS和后来的CVS的前端,为Emacs提供“one-&nbsp;<BR>touch”版本控制操作,它是从一个微型的、粗糙的别人写好的sccs.el模式开始&nbsp;<BR>演化的,VC开发的成功不像Emacs本身,而是因为Emacs&nbsp;Lisp代码可以很快的通过&nbsp;<BR>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -