Linux过时了(1)(Linus vs. Tanenbaum的中文翻译)

写在前面

  第一次看到这篇文章的时候,是大学时期最迷茫的时候。无所畏惧的勇气正在被学业一点点的磨灭,改变世界的春秋大梦在现实中一点点的清醒,稳扎稳打的学习步伐也在困难和琐事中裹足不前——这个时候,Linus和他老师的对骂贴闯进了我的世界,可以想象当时的我看着这样的一篇文章是怎样的热血沸腾。
  那时的Linus正是风华正茂书生意气的时候,刚写好自己的Linux操作系统,大概也正像每个年轻人一样踌躇满志的傲视着这个即将因自己而改变的世界吧。他的前辈,Tanembaum,兼赫尔辛基大学的操作系统老师,兼操作系统学术界的大牛级人物,开始向他发难,在邮件组里发文言辞颇为激烈的批评Linux。这篇文章也是一石激起千层浪,不仅引来Linus的绝地反击,顺带把当时学术工业界的各路牛人都给引了过来。于是大家开始各执一词,从Linux讨论到Minix,讨论到操作系统和软件设计,甚至还有人对学术界不遗余力的做一下嘲讽。鉴于它汇集了各种观点,而之前网上有的翻译大都不全,故在此把能搜集到的部分邮件翻译整理了一下。权当作对Linus锋芒毕露的才华的致敬,也当是对这些靠着一己之力而改变世界的程序员们的致敬,更当是对那个黑客们风起云涌的年代的缅怀。
  (以下的内容译自http://oreilly.com/catalog/opensources/book/appa.html。原文的注释和我自己的注释全在括号中,但我自己的注释加了“译者注:”的标记)。

对骂内容

Andy Tanenbaum
发信人: ast@cs.vu.nl (Andy Tanenbaum)
新闻组: comp.os.minix
主题: LINUX过时了
日期: 29 Jan 92 12:12:50 GMT
组织机构: Fac. Wiskunde&h; Informatica, Vrije Universiteit, Amsterdam
  前段时间我在美国呆了几周,所以对Linux我没有多加评论(当然,并不是说如果我就在左近就会对这个话题谈论很多)。但考虑到这个话题还是很有价值的,我现在想说几句。
  很多人都知道,对我来说Minix是一个业余爱好。是我在晚上厌倦了写书,而CNN又没有战争、革命、参议院会议等事播报时,才会折腾的事情。我的本职工作是一名教授、一个操作系统领域的研究员。
  因为我研究领域的关系,对未来几十年操作系统的发展趋势,我认为我还是略知一二的。至少有两个方面是极为显著的:
  1. 微内核(Micro Kernel) vs 宏内核(Monolithic System)
  早期的操作系统绝大多数都是宏内核的,即,整个系统就是一个运行在“内核态(Kernel mode)”的a.out文件。进程调度、内存管理、文件系统等诸多事务全都包含在这样的一个二进制文件中。如UNIX,MS-DOS,VMS,MVS,OS/360,MULTICS,这样的系统不胜枚举。
  另外一个选择就是基于微内核的系统。在这样的系统中,OS的绝大部分模块都各自运行在内核之外的进程中。它们通过传递消息进行通信。内核的任务是处理消息、转发消息、控制中断、更为底层的进程管理以及输入输出。这种设计的例子有:RC4000,Amoeba,Chorus,Mach,还有即将发布的Windows/NT。
  如果要争论这两种设计的优缺点,我可以花很多篇幅来讲。但是如果让那些真正设计过操作系统的人来说,这场争论毫无异议已经结束。微内核赢了。宏内核现今唯一拿的出手的只剩下了性能。——可惜现在有足够多的证据表明微内核也能和宏内核跑的一样快(如Rick Rashid 发表了一篇论文,对Mach 3.0和宏内核的性能做了对比)。所以,一切争论已经结束,剩下的都是瞎嚷嚷了。
  Minix是微内核系统。文件系统和内存管理是两个分离的进程,并且它们运行在内核之外。输入输出设备的驱动也都有各自的进程(虽然是在内核态,但这全怪英特尔处理器那些愚蠢至极的特性),Linux是宏内核的。这完全是倒退到了20世纪70年代。这好比用Basic来重写一个已经出色工作的C语言程序一样。对我而言,在1991年写一个宏内核系统真是一个糟糕的主意。
  2. 可移植性
  很久很久以前,诞生了一款叫4004的处理器。没用多久,它摇身一变成了8008。紧接着它又改头换面成了8080。然后就有了8086,80286,80386,80486,直到子子孙孙无穷匮也。
  于此同时,精简指令集芯片横空出世,它们之中有的运行速度甚至能达到100 MIPS。在不远的几年中,速度很可能会达到200 MIPS。它们不会在哪一天突然消失,而是会逐渐取代80x86的地位。它们会通过模拟80386的软件来运行那些老旧的MS-DOS程序(我自己还用C语言写了我IBM PC的模拟器,通过FTP站点ftp.cs.vu.nl=192.31.231.42,在minix/simulator的子目录中你可以得到一份拷贝)。我认为为一个特定的系统结构设计一款内核显然是个错误,因为这样的内核必然不能走远。
  Minix在移植性上设计的较为合理。并且已经从英特尔的处理器移植到了68000,SPARC和NS32061的芯片上。Linux和80x86绑的太紧密了。这不是正道。
  别误会我,我不是对Linux不满意。这会使得那些想从Minix换到BSD UNIX的人对我唠叨个不停。但凭心而论,对于那些想要一个够现代够免费的OS的人们,我真心建议他们找一个基于微内核的可移植的OS,比如像GNU或者其他类似的。
  另:有一个基于Amoeba系统开发的UNIX虚拟机(跑在用户空间中),但是还远远没有完成。如果大家谁对这项工作感兴趣,请告知我。要运行Amoeba,你需要一些386计算机,其中得有一台有16M的内存,并且所有的计算机必需WD以太网卡。


Linus Benedict Torvalds
发信人: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
新闻组: comp.os.minix
主题: 回复:Linux过时了
日期: 29 Jan 92 23:14:26 GMT
组织机构: University of Helsinki
  好吧,像这样的一个话题,恐怕我非回复不可。不管怎样,首先向听够了Linux的Minix用户们道个歉。我本希望能够无视掉之前的那些文字,但是…是时候反击了。
  在文章12595@star.cs.vu.nl中ast@cs.vu.nl (Andy Tanenbaum)说:
  前段时间我在美国呆了几周,所以对Linux我没有多加评论(当然,并不是说如果我就在左近就会对这个话题谈论很多)。但是现在我有话想说,因为这很值得一谈。
  很多人都知道,对我来说Minix是一个业余爱好。是我在晚上厌倦了写书并且在CNN没有大规模战争、革命或者参议院会议播报的时候才会折腾的事情。我的本职工作是一名教授、一个操作系统领域的研究员。
  这就是你为Minix的局限性所找的借口?不好意思,你说的太随便了:我本可以比你有更多的借口,可Linux仍旧几乎在所有方面都完爆Minix。我甚至都懒的说以下事实:PC版Minix里的绝大部分漂亮代码都是Bruce Evans写的。
  回复1:你当Minix是你的一项爱好——怎么不先看看谁从Minix里赚到了钱,而又是谁无偿的把Linux给贡献了出来。接下来我们再来谈兴趣爱好。如果让Minix成为自由软件,那么我对Minix就没什么大的怨言了。Linux对我而言才完全是兴趣爱好(严肃的来讲:这是最好形式的爱好):我没有从它上面捞到过一分钱,它甚至都不是我大学学业中的一部分。我完全是利用自己的业余时间完成的,用的还是我自己的机器。
  回复2:你的工作是一名教授、一位研究员:对于Minix的一些硬伤,这个借口堪称完美。我只希望(并且假定)Amoeba不像Minix这样糟糕。
  1. 微内核vs 宏内核
  不错,Linux是宏内核的,并且我也赞同微内核更为优美。若不是一个这么具有争议性的话题,我八成已赞你绝大部分的观点。从理论的(和审美的)角度来看,Linux是输了。如果GNU内核在去年春天已经能用了的话,我肯定不会如此大费周章开展我的项目:事实是GNU内核那时还不能用,即便是现在仍旧不行。就可用性这点来看,Linux大获全胜。
  Minix是微内核的,Linux是宏内核的。
  如果这检验内核好坏的唯一标准,那你是对的。你没有提到的是Minix并没有把微内核该做的事情做好,并且Minix内核在实时多任务上有问题。如果我写了一个在多线程文件系统上有问题的内核,我将不会急着对别人说三道四:事实上,我会极尽全力以让别人忽略我出过的糗。
  (是的,我知道Minix的多线程里用很多的技巧,但那仅仅是技巧。并且Bruce Evans告诉我Minix里面也有很多的边界条件导致线程竞争。)
  2. 可移植性
  “可移植性是为那些不会写新程序的人们准备的。” ——至于我,现在毫无压力(译者注:这里的原文是“me,right now(with tongue in my ckeek)”。tongue in cheek有半开玩笑的意思。译者觉得Linus这句挑衅的话有随便开玩笑说说的感觉。所以在这里揣测语境随便意译了一下)。
  事实上Linux比Minix的移植性更好。“什么?”我已经听到了你惊讶的声音。这是真的——但不是ast(译者注:指Andy Tanenbaum。后面Andy Tanenbaum的姓名全部被缩写成了ast。)说的那个意思:我尽我所知让Linux尽量符合标准(在我手头没有任何POSIX标准的前提下)。总的来看,把一个程序移植到Linux下要比移植到Minix下容易的多。
  我完全赞同可移植性的优越性:但它必须是适度的。试着让一个操作系统过度的可移植完全是没有必要的:只要依赖于可移植的API就够了。一个操作系统的唯一准则恰恰是利用硬件的特性,然后把它们隐藏在更高的系统调用层中。这正是Linux所做的:它只不过是比别的内核稍稍多利用了一些386的特性,而这却又导致了一个精简的多的架构。一个让人能够接受的权衡,也让Linux有了成为一流内核的可能。
  我也承认Linux把不可移植性推向了一个极端:去年1月份我拥有了自己的386机器,从某个角度来看,Linux仅仅是一个让我学习386芯片的项目。如果它是一个真正的项目的话,很多地方应该完成的更具有移植性。尽管事实如此,但我并不是在为自己开脱:它是一个架构上的决定,并且在去年四月我开始这个项目的时候,我根本没有想到过会有别人真的想用它。我得非常开心的说在这点上我错了,并且由于我的源代码是可自由获取的,任何人都可以方便自由的自己去试着做移植,尽管这颇为不易。
Linus
  另:我有些时候话太糙了,对此我深表歉意:如果你手头一无所有,minix还是很不错的。如果你有身边有5到10台空闲的386,Amoeba估计也不会差,但显然我没有。我一般不会发火,但是一说到Linux,我就会变得非常敏感。


Andy Tanenbaum
发信人: ast@cs.vu.nl (Andy Tanenbaum)
新闻组: comp.os.minix
主题: 回复:Linux过时了
日期: 30 Jan 92 13:44:34 GMT
组织机构: Fac. Wiskunde&h; Informatica, Vrije Universiteit, Amsterdam
  在文章1992Jan29.231426.20469@klaava.Helsinki.FI中torvalds@klaava.Helsinki.FI(Linus Ben- edict Torvalds)说:
  这就是你为Minix的局限性所找的借口?
  Minix的局限性至少和我作为一个教授是有点关系的:Minix一个极为明确的设计目标是它能够运行在便宜的硬件上,这样学生才能负担的起。尤其是这么多年来,它一直运行在一个主频是4.77MHZ的PC上,而这台PC连硬盘都没有。在这台机器上你可以做任何事情,包括修改和重新编译整个系统。不妨也顺便告诉你,大概在一年以前,有两个版本的Minix,一个是PC版的(360K的磁盘空间),另一个是286/386版的(1.2M磁盘空间)。PC版大概要比286/386多卖出一倍。我没有统计过,但据我推测,当今世界现有的六千万台个人电脑中,386/486机器的数量相对8088/286/680x0的机器来说肯定要少。在学生群体中这个数量就更少了。把软件搞成自由软件,这对于那些有钱买的起一流硬件的人来说只不过是一个很可笑的概念。当然5年之后情况又会不同,但是5年之后大家早已纷纷在自己200MIPS、64兆的SPARC-5工作站上跑起免费的GNU系统了。
  回复2:你的工作是一名教授、一位研究员:对于minix的一些硬伤,这个借口堪称完美。我只希望(并且假定)Amoeba不像minix这样糟糕。
  Amoeba不是为一个无磁盘的8088计算机设计的。
  如果这检验内核好坏的唯一标准,那你是对的。你没有提到的是minix并没有把微内核该做的事情做好,并且minix内核在实时多任务上有问题。如果我写了一个在多线程文件系统上有问题的内核,我将不会急着对别人说三道四:事实上,我会极尽全力以让别人忽略我出过的糗。
  一个多线程的文件系统只不过是一个性能上的技巧而已。考虑到一般情况下一台个人电脑只有一个任务运行,做一个这样的技巧实在是费力不讨好。而在那种能运行多用户的高性能机器上,你又会拥有很多的磁盘缓存让磁盘操作都能命中到内存缓存中,那么这又将导致文件系统多线程的功能颇为鸡肋。只有当多个进程真正在做磁盘IO的时候,这个性能才会大有作为。有没有必要仅仅就为了这样一种情况就把系统做的这么复杂,还是很值得商榷的。
  我仍旧表示在1991年设计一款宏内核的系统是大错特错。幸亏你不是我的学生。这样的设计在我这儿是拿不了优的。
  事实上Linux比Minix的移植性更好。”什么?” 我已经听到了你惊讶的声音。这是真的——但不是ast说的那个意思:我尽我所知让Linux尽量符合标准(在我手头没有任何POSIX标准的前提下)。总的来看,把一个程序移植到Linux下要比移植到Minix下容易的多。
  Minix在设计的时候还没有POSIX,上这个新闻组的人也都知道它现在正在慢慢地POSIX标准化。每个人都赞同用户级的标准是个好主意。顺便插一句,恭喜你在手头没有POSIX标准的前提下做了一个和POSIX标准兼容的系统。我发觉即便在对标准做长时间学习后,想做到和它兼容都不是件容易事。
  写一个新的操作系统还紧紧依附于某个特定的硬件,尤其是像英特尔这样的怪胎,这根本就是错到家了。——这就是我的观点。OS就应该能够轻易移植到新的硬件平台上。25年前为IBM 360写的OS/360用的是汇编,这还情有可原。10年前的MS-DOS是专门为8088写的,这就有点不太明智,但IBM和微软好歹还是在吃尽苦头之后意识到了这点。在1991年为386新写一个操作系统也只能让你这个学期再拿一个”F”。但如果你期末考试考的还行的话,这门课估计你还不至于挂科。
Prof. Andrew S. Tanenbaum (ast@cs.vu.nl)


发信人: feustel@netcom.COM (David Feustel)
主题: 回复:Linux过时了
日期: 30 Jan 92 18:57:28 GMT
组织机构: DAFCO - An OS/2 Oasis
ast@cs.vu.nl (Andy Tanenbaum) 说:
  我仍旧表示在1991年设计一款宏内核的系统是大错特错。幸亏你不是我的学生。这样的设计在我这儿是拿不了优的。
  这点倒是不假。爱因斯坦数学和物理的成绩也臭的可以。


发信人: pete@ohm.york.ac.uk (Pete French.)
主题: Re: LINUX is obsolete
日期: 31 Jan 92 09:49:37 GMT
组织机构: Electronics Department, University of York, UK
  就微内核和宏内核的问题来说,这不是也取决于用什么语言写内核么?Minix作为一个微内核设计可能不错,但是最后不还是一整块二进制数据作为一个所谓的”内核文件”被加载到内存么?它没有被分开编译成好几个程序文件完全是因为C语言不支持一个代码块分开运行在不同进程中。把一个微内核写成好多个C文件和用OCCAM之类的语言写一个宏内核之间有什么本质上的区别么?我倒是觉得在这种情况下宏内核反倒要比微内核强,因为可以籍此利用语言内置的并发机制使内核代码比Minix更具有模块性。


发信人: kt4@prism.gatech.EDU (Ken Thompson)(译者注:Ken Thompson是UNIX的作者之一)
主题: 回复:Linux过时了
日期: 3 Feb 92 23:07:54 GMT
组织机构: Georgia Institute of Technology
  对一个事物的看法其实倒和这个事物的功效如何关系不大的。如果从设计的眼光来审视,我们用的许多软件——即便够不上绝大多数——都是过时的。对于广大用户来说,他们可能不怎么关心他们用的操作系统内部的设计是不是过时的。他们更关心的是性能和用户级上的兼容性。
  总的来说,我还是赞同微内核可能将会是未来的潮流。但是,我觉得还是实现一个宏内核的系统容易些。当然,在改动的过程中宏内核也更容易变成一团糟。
此致
Ken


发信人: kevin@taronga.taronga.com (Kevin Brown)
主题: 回复:Linux过时了
日期: 4 Feb 92 08:08:42 GMT
组织机构: University of Houston
  在文章47607@hydra.gatech.EDU中kt4@prism.gatech.EDU (Ken Thompson) 说到:
  对一个事物的看法其实倒和这个事物的功效如何关系不大的。如果从设计的眼光来审视,我们用的许多软件——即便够不上绝大多数——都是过时的。对于广大用户来说,他们可能不怎么关心他们用的操作系统内部的设计是不是过时的。他们更关心的是性能和用户级上的兼容性。
  总的来说,我还是赞同微内核可能将会是未来的潮流。但是,我觉得还是实现一个宏内核的系统容易些。当然,在改动的过程中宏内核也更容易变成一团糟。
  良好组织一个宏内核项目的目录结构以使的大多数改动都对代码没有大的负面影响,想做到这件事情的难度究竟有多大呢?在处理这种事情上你又遇到了怎样的误区呢,处理这些误区你有没有什么好的建议?
  我寻思我想问的可能是这个:即便是一个宏内核,对内核的改动整体来看也只是停留在局部上的——如果想达到这样的目的,组织代码的难度是多大呢?
  我觉得您在宏内核方面肯定有多年经验,所以我觉得对于这些问题您肯定有最切中要害的答案。
Kevin Brown

 

posted on 2013-01-11 16:22  码农逐梦者  阅读(...)  评论(...编辑  收藏

导航

统计