FORM:http://www.hisnote.com/2013/10/27/tanenbaum-torvalds-debate/

本文根据维基百科码农逐梦者博客oreilly出版社整理而成。

AndrewTanenbaum

安德鲁·斯图尔特·塔能鲍姆博士(在comp.os.minix上叫 ‘ast’ )

塔能鲍姆-托瓦兹辩论(英语:Tanenbaum–Torvalds debate),由Minix创作者安德鲁·斯图尔特·塔能鲍姆(Andrew Stuart “Andy” Tanenbaum,昵称“安迪”,网络上的代号为“ast”)与Linux核心的作者林纳斯·托瓦兹(Linus Torvalds)之间,进行的网络论战,讨论的主题在于操作系统架构的选择。1992年在Usenet讨论组群comp.os.minix上发起。塔能鲍姆认为,以微内核架构设计的操作系统,在理论上,比宏内核架构更加优越,Linux采用的宏内核架构是过时的。但是林纳斯·托瓦兹以开发实务上的观点展开反击,并比较Minix与Linux的性能差异。稍后一些著名的黑客也加入讨论,如彼得·麦唐纳(Peter MacDonald,他创造了第一个linux发行版,Softlanding Linux System。他也协助发展了Wine软件)、大卫·米勒(David Stephen Miller,网络昵称为 DaveM,负责Linux核心网络功能以及SPARC平台的制作。他也参与其他开源软件的开发,是GCC督导委员会的成员之一)、曹子德(西奥多·曹,英语:Theodore Y. Ts’o,中文姓名曹子德,小名泰德·曹Ted Tso,他是Linux内核在北美最早的开发者,负责ext2、ext3与ext4档案系统的开发与维护工作。他也是e2fsprogs的开发者。为自由标准组织的创始者之一,也曾担任Linux基金会技术长)。这场辩论影响了Linux核心的设计走向。这场辩论有时也被视为一场口水战。

这个话题在 2006 年塔能鲍姆在 《Computer》杂志发表题为《我们能让操作系统可靠和安全吗?》的文章后被再次提起。尽管塔能鲍姆本人提到,他并不是想借这篇文章重启内核设计的论战,但是这篇文章本身和 Slashdot 技术网站上附加的 1992 年论战的归档共同使战火重燃。

391px-Linus_Torvalds

林纳斯·托瓦兹(Linus_Torvalds)

托瓦兹通过一个在线论坛反驳了塔能鲍姆的论点,几个技术新闻网站随即开始对其进行报道。这使 Jonathan Shapiro 回应称,大多数经过实际检验的安全可靠的计算机系统,都使用更近似于微内核的模式设计。

辩论过程

虽然初步的辩论显得相对温和,当事人双方仅仅平淡了讨论了有关内核设计的话题。但随着每一轮的发帖,辩论开始逐步变得详细和复杂,甚至跨足于内核设计之外的其它领域,如”微处理器架构将在未来战胜其它架构”,但其中也包括了一些人身攻击、意气之争的言词辩论。除了塔能鲍姆和托瓦兹,Linux开发社区中一些著名黑客也加入辩论,包括彼得·麦唐纳,早期的 Linux 内核开发者和第一个发行版 Softlanding Linux System 的创建者;大卫·米勒,Linux 内核的核心开发者之一;和曹子德,北美洲第一个 Linux 内核开发者。

Linux 是过时的

第一条有关这场辩论的记录,在1992年1月29日,塔能鲍姆在 comp.os.minux 上发表了他的批评。在题为《Linux 是过时的》(Linux is obsolete)的帖子中,塔能鲍姆指出宏内核在整体设计上是有害的。虽然他最初并没有加入高深的技术细节,来解释他认为微内核更好的原因,但他也表明,这关乎可移植性,Linux内核对Intel 80386架构的耦合度太高,但处理器架构的进化很快。不应该在某个特定架构上开发操作系统,所有的操作系统都应该具备可以被移植到其他处理器平台的能力。他提到,在1991年仍然以宏内核来设计操作系统,是“回到1970年代的巨大退步“(a giant step back into the 1970s),现代的操作系统,应该像GNU Hurd一样采用微核心架构。

托瓦兹在一天之后反击,他首先攻击Minix在设计上有缺陷(缺少多线程是一个主要例子)。托瓦兹说,他用自己私人的时间来开发,完全没有获利,免费将代码贡献出去(当时塔能鲍姆的Minix源代码,仍然要购买才能取得),因此,对于Minix设计不良,塔能鲍姆不能用“这只是兴趣”来为来辩护。托瓦兹说,从哲学及美学的观点出发,微核心的确是一个比较好的架构,但是采用微核心架构的GNU Hurd根本没有如期被成功开发出来,所以他才要开发Linux。托瓦兹强调,操作系统核心主要的功能都倚靠硬件特性,所以内核本身不需要过度具备可移植性,让高级的软件应用程序接口具备可移植性才是更重要的。Linux内核采用集成式核心架构,是因为它能够简化核心设计,这是一个权衡下的结果(An acceptable trade-off)。以Linux来跟Minix比较,移植程序到Linux上是更容易的。托瓦兹进一步说,可移植性是那些写不出新程序的人才需要的(Portability is for people who cannot write new programs)。Linux一开始针对Intel 80386架构来开发,一部份的理由是为了托瓦兹自己买的电脑就是80386,这正好可以让他对80386架构了解更多。Linux一开始就是准备自己使用的,如果想要移植到别的平台,代码都是开放的,想要的人可以自己做。

400px-Kernel-monolithic.svg

宏内核的内核空间完全运行在核心态

辩论全文

这个帖子时间太久远了(1992年1月29日首发),以至于2013年5月7号有个回帖称:”I am replying… to history. “,但如此灌水也需要勇气。。。

参考阅读:

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

原始链接:Linux过时了(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。它们不会在哪一天突然消失,而是会逐渐取代80×86的地位。它们会通过模拟80386的软件来运行那些老旧的MS-DOS程序(我自己还用C语言写了我IBM PC的模拟器,通过FTP站点ftp.cs.vu.nl=192.31.231.42,在minix/simulator的子目录中你可以得到一份拷贝)。我认为为一个特定的系统结构设计一款内核显然是个错误,因为这样的内核必然不能走远。

Minix在移植性上设计的较为合理。并且已经从英特尔的处理器移植到了68000,SPARC和NS32061的芯片上。Linux和80×86绑的太紧密了。这不是正道。

别误会我,我不是对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/680×0的机器来说肯定要少。在学生群体中这个数量就更少了。把软件搞成自由软件,这对于那些有钱买的起一流硬件的人来说只不过是一个很可笑的概念。当然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


发信人: rburns@finess.Corp.Sun.COM (Randy Burns)
主题: 回复:Linux过时了
日期: 30 Jan 92 20:33:07 GMT
组织机构: Sun Microsystems, Mt. View, Ca.

在文章<12615@star.cs.vu.nl>中ast@cs.vu.nl (Andy Tanenbaum)说到:

当然5年之后情况又会不同,但是5年之后大家早已纷纷在自己200MIPS、64兆的SPARC-5工作站上跑起免费的GNU系统了。

如果这事在将来能发生,让我含笑九泉我都行。

写一个新的操作系统还紧紧依附于某个特定的硬件,尤其是像英特尔这样的怪胎,这根本就是错到家了。——这就是我的观点。

首先,Linux里面最和80×86紧密相关的部分也就是内核底层和设备驱动。我自己觉得吧,即便linux只是我们在用GNU内核之前的一个权宜之计,为一个现今使用量最多的系统结构专程设计一款内核也是很值得的。

OS就应该能够轻易移植到新的硬件平台上。

Linux里面唯一不可移植的部分就是内核底层和驱动。和编译器啦、工具包啦、窗口管理系统啦什么的比起来,这也只占很少的一点工作量。既然Linux在系统调用上和可移植操作系统有很高的兼容性,那我也没什么好吐槽的了。能有一个OS让我们更有可能利用来自Berkeley、FSF、CMU等处的软件,我个人对此双手点赞。两三年后,相当实惠的BSD变种和Hurd的使用量或许会激增,那时Linux才算真过时了。至于现在么,Linux大大降低了如gcc, bison, bash之类工具的使用成本,这对开发相当有好处——比如说开发OS。


Linus Benedict Torvalds
发信人: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
新闻组: comp.os.minix
主题:回复:Linux过时了
日期: 31 Jan 92 10:33:23 GMT
组织机构: University of Helsinki

在文章<12615@star.cs.vu.nl> 中ast@cs.vu.nl (Andy Tanenbaum)说到:

minix的局限性至少和我作为一个教授是有点关系的:minix一个极为明确的设计目标是它能够运行在便宜的硬件上,这样学生才能负担的起。

很好:十足的技术观点,也让我的一些评论毫无辩解的余地。但是同时你有点搬起石头砸了自己的脚:现在你终于承认了minix里面的一些问题纯粹是出于它太可移植了,甚至还囊括了那些压根不是为unix系统设计的硬件平台。这个假定引出了如下事实:尽管硬件支持,要在minix上添加一些像分页之类的扩展是没这么容易的。不错,minix是有很好的可移植性,但是你要是换个说法如”没有使用任何硬件特性”仍旧不错。

一个多线程的文件系统只不过是一个性能上的技巧而已。

不敢苟同。在微内核架构上这是一个性能上的技巧,但当你写一个宏内核系统的话,你就能发现这是一个非常自然而然的特性,甚至都是一个微内核无法圆满完成的领域(我在给Andy Tanenbaum的个人邮件中已指出这一点)。当以”过时”的方式写一个UNIX的话,你很自然的就写出一个多线程的内核:每个进程各司其职,并且你也用不着为了提高性能去写诸如消息队列之类的丑陋代码。

另外,也总有人认为”仅仅一个性能上的技巧”是至关重要的:如我所料非错的话,除非你有一台cray-3,不然大家肯定都对长时间等待电脑响应头疼不已。我知道我在minix上就是如此(嗯,我在linux上也会这样,但是情况好多了)。

我仍旧表示在1991年设计一款宏内核的系统是大错特错。幸亏你不是我的学生。这样的设计在我这儿是拿不了优的。

好吧,就算没有你,我十有八九也考不出什么好成绩:我已经在这个学校和一个教操作系统设计的老师吵了一架了(完全是出于另一见不相干的事——甚至都和OS没什么关系)。

写一个新的操作系统还紧紧依附于某个特定的硬件,尤其是像英特尔这样的怪胎,这根本就是错到家了。——这就是我的观点。

但我的观点是操作系统是不依附于任何处理器硬件的:UNIX在现今绝大多数处理器上都跑的很顺畅。当然,怎么实现必须得看硬件,但这和”依附”是大大不同的。你把OS/360和MS-DOS作为糟糕设计的典型,因为它们依赖于硬件,这点我同意。但它们和linux完全不是一回事,linux的API是可移植的(不是由于我的设计有多么巧妙,而是由于我决定效仿一个在设计、实现和实践中都经过千锤百炼的系统:unix)

你现在为linux写程序,等你在21世纪想移植到Hurd上了你重新编译一下就好了,对此你必然不会大吃一惊。前面也提到了(不光是我说的),linux内核只不过是完整的系统里的九牛一毛:linux代码现在全加起来打个包也就大概200KB——开发一个像样点的完整系统打包好的代码量少说也得10个兆(并且很容易说多就多出一大堆)。除了这个微乎其微的内核之外,剩下的代码也都是可移植的。更何况就算你什么都不懂,从头写一个这样的内核也用不了一年(事实上我就是这样的)。

其实整个linux的内核加起来也远比Mach内核中和386相关的代码少的多:Mach当前版本的i386.tar.z打包文件超过了800KB(据nic.funet.fi数据,是823391个字节).诚然,mach作为一个”像样的”系统还要大些并且还有更多的特性——你们完全可以从中去琢磨出点什么东西 (译者注:考虑到Mach是微内核的,所以译者认为Linus仍然在嘲讽微内核)。

Linus


发信人: kaufman@eecs.nwu.edu (Michael L. Kaufman)
主题: Re: LINUX is obsolete
日期: 3 Feb 92 22:27:48 GMT
组织机构: EECS Department, Northwestern University

我试着在工作的时候发这两封邮件的。但是它们好像没发出去。如果你们已经看到了下面的信件,请原谅。

——————————————————————————-

Andy Tanenbaum写了一篇很搞笑的文章(发现他也上这个新闻组同样也很搞笑),但是我觉得他忽略了很重要的一点。

他说道:

很多人都知道,对我来说MINIX是一个业余爱好。

对于绝大部分玩Linux的人,我相信这也是事实。我们并未开发一个要占领OS市场的系统,我们只是乐在其中。

它们不会在哪一天突然消失,而是会逐渐取代80×86的地位。它们会通过模拟80386的软件来运行那些老旧的MSDOS程序。

如果这件事真的发生了,而我还是想玩Linux的话,我完全可以在我386的模拟器上面跑它们。

MINIX在移植性上的设计较为合理。并且已经从英特尔的处理器移植到了68000,SPARC,和NS32061的芯片上。LINUX和80×86绑的太紧密了。这不是正道。

对于有那些机器的人来说这是好事,但这其实是把双刃剑。可移植性的代价就是386性能和特性的损耗。在你决定说Linux不是正道的时候,你应该自己考虑一下你要用它来做什么。我要用它在我的486计算机上跑对内存和计算量都有很高要求的图形程序。对我来说,速度和内存要比什么所谓未来艺术上的优雅和可移植性重要多了。

但凭心而论,对于那些想要一个够现代够免费的OS的人们,我真心建议他们找一个基于微内核的可移植的OS,比如像GNU或者其他类似的。

我从来没听说过什么基于微内核的可移植的操作系统。GNU现在仍旧只是水月镜花,并且在可以预见的未来似乎依然会是这副样子。你有什么可推荐的么,或者你就是在寻我开心?

——————————————————————————

在文章12615@star.cs.vu.nl中ast@cs.vu.nl (Andy Tanenbaum) 说到:

写一个新的操作系统还紧紧依附于某个特定的硬件,尤其是像英特尔这样的怪胎,这根本就是错到家了。——这就是我的观点。OS就应该能够轻易移植到新的硬件平台上。

我觉得看到这儿我就不能赞同你了。你就是在拿OS设计里的一个结果来看待这个东西。Minix好是因为它可移植还基于微内核之类云云;Linux不好是因为它基于宏内核还紧紧绑在Intel上之类云云。这种态度扔学术界还不算奇怪,但是你如何让整个世界都信服?Linux不是写来教书的,也不是一个毫无实质意义的课后练习。写它是用来让人类在这个时代跑GNU软件的。重要的不是五年之后Linux也许会销声匿迹,而是现在我能用它想跑什么软件就跑什么软件。你继续吹捧你的Minix吧,反正它要是不能跑我想跑的软件,(在我眼里)它就是一文不值。

10年前的MS-DOS是专门为8088写的,这就有点不太明智,但IBM和微软好歹还是在吃尽苦头之后意识到了这点。

我还是老说法。微软折腾个dos出来不是用来做”OS前沿领域研究探索”的,而是为了美元。并且考虑到MS-DOS现在仍旧卖的大红大紫,很明显他们目的已经达到了,所以我也不赞同你说他们不明智。虽然说不管从哪个角度看,MS-DOS都算不上什么好货,但它满足了市场的需求。

Michael


发信人: richard@aiai.ed.ac.uk (Richard Tobin)
主题: 回复:Linux过时了
日期: 4 Feb 92 14:46:49 GMT
组织机构: AIAI, University of Edinburgh, Scotland

在文章12615@star.cs.vu.nl中ast@cs.vu.nl (Andy Tanenbaum) 说道:

一个多线程的文件系统只不过是一个性能上的技巧而已。考虑到一般情况下一台个人电脑只有一个任务运行,做一个这样的技巧实在是费力不讨好。

我发现在用Minix的时候,单线程的文件系统是我永远的痛。在我从软盘读文件(速度慢的让人抓狂)的时候,我总是想去干点什么别的事情。在等待大一点的C程序或lisp程序编译的时候,我连打人的冲动都有。

还有就是我总是喜欢编译一个文件时在文本编辑器里看另一个文件。

(如果文件系统只管文件操作而不和终端IO交互的话,这个问题的严重程度貌似有点减轻。)

当然,考虑到Minix没有虚拟终端并且根本也跑不了Emacs,上面的问题似乎不是什么大问题。但是对于很多人来说,这完全是劣势,而不是优势。根本不是由于什么在单用户的机器上跑多个进程没有意义;是因为大家早就都适应了垃圾电脑和垃圾的操作系统,这样解释差不多你的这句话就说得通了。

至于移植性么,Minix是靠着它没什么野心和理想才能获胜。如果你想要个有分页、有任务控制、有窗口系统的功能齐全的UNIX,是给Minix内核添加这些特性快呢?还是修改一些386的权限位,给Linux添加来的快呢?我觉得这么去黑Linux实在不公平,因为它的定位和Minix是如此的不同。如果你想要一个教学工具,那么毫无疑问Minix。但是如果你想在你的个人电脑上要一个无限接近Sun工作站的环境,这就要另当别论了。

Richard


发信人: ast@cs.vu.nl (Andy Tanenbaum)
主题: 回复:Linux过时了
日期: 5 Feb 92 14:48:48 GMT
组织机构: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

在文章6121@skye.ed.ac.uk中richard@aiai.UUCP (Richard Tobin) 说道:

如果你想要个有分页、有任务控制、有窗口系统的功能齐全的UNIX,是给Minix内核添加这些特性快呢?还是修改一些386的权限位,给Linux添加来的快呢?

你好像完全忘记了还有一个选择:买一个UNIX或者是一份拷贝。如果你就是想用用系统,而不是玩到内核内部去,你根本用不着源代码。Conerent才99美元,并且还有更多功能更完善的也更贵的UNIX变种。对一个真正的黑客来说,拿不到代码等于要了亲命。但是对于那些只想使用UNIX环境的人来说,选择多的是(虽然不是免费的)。

Andy Tanenbaum (ast@cs.vul.nl)


发信人: ajt@doc.ic.ac.uk (Tony Travis)
主题: 回复:Linux过时了
日期: 6 Feb 92 02:17:13 GMT
组织机构: Department of Computing, Imperial College, University of London, UK.

ast@cs.vu.nl (Andy Tanenbaum) 说:

你好像完全忘记了还有一个选择:买一个UNIX或者是一份拷贝。如果你就是想用用系统,而不是玩到内核内部去,你根本用不着源代码。Conerent才99美元,并且还有更多功能更完善的也更贵的UNIX变种。对一个真正的黑客来说,拿不到代码等于要了亲命。但是对于那些只想使用UNIX环境的人来说,选择多的是(虽然不是免费的)。

Andy,自从minix第一条消息发布到这个新闻组上起,我就随着minix的不停开发在用minix了,我现在用的是Bruce Evans打了补丁的1.5.10版。

我只想在我的机器上要一个UNIX并且我也对玩内核没什么兴趣,但是我真的想要一份源代码!

潜藏在UNIX的成功和流行背后一条很重要的准则就是”要建立在别人工作的基础上”的哲学。

这种哲学的前提是源代码是可以获取的,这样大家才能在开发新软件时审核它,修改它,重用它。

很多年以前,我对AT&T UNIX V7的源代码许可证非常满意;后来,你决定让Minix的源代码也是可以随软件发行的,这件事也让我颇感开心,因为这是对AT&T后续版权枷锁的一种解脱!!

我想你有时候会忘记你的这项”业余爱好”已经对”个人版”UNIX(即,大家能买得起的UNIX)的可用性产生了深远的影响。事实上,我现在386/SX上minix的这份拷贝要比我8086PC上跑的Minix1.2 的价格便宜的多。

是的,Minix不可能成为每个人的全部,但是正如在68000或者其他的基于线性地址空间架构的处理器一样,我在386上也看到Minix的进步:这对于我们这群人是好事,我们用minix,也对PC版基于分段体系结构的minix感到很不爽。

不管你说什么,我也不会去用Conherent的。

Tony


发信人: richard@aiai.ed.ac.uk (Richard Tobin)
主题: 回复:Linux过时了
日期: 7 Feb 92 14:58:22 GMT
组织机构: AIAI, University of Edinburgh, Scotland

在文章12696@star.cs.vu.nl中ast@cs.vu.nl (Andy Tanenbaum) 说道:

如果你就是想用用系统,而不是玩到内核内部去,你根本用不着源代码。

很不幸的是玩内核是我们要一个系统的唯一目的。要想说服我们,还得得BSD变种或者是GNU内核出来了——估计也就是最近几个月的事儿了吧(也有可能是最近几年)。

Richard


发信人: comm121@unixg.ubc.ca (Louie)
主题: 回复:Linux过时了
日期: 30 Jan 92 02:55:22 GMT
组织机构: University of British Columbia, Vancouver, B.C., Canada

在文章12595@star.cs.vu.nl中ast@cs.vu.nl (Andy Tanenbaum) 说:

但凭心而论,对于那些想要一个够现代够免费的OS的人们,我真心建议他们找一个基于微内核的可移植的OS,比如像GNU或者其他类似的。

对于像我一样想要一个”自由”操作系统的人来说,除了Linux好像真的没什么选择了。考虑到绝大多数人用的都是386,可移植性也基本不是什么大事啦。如果我有一台Sparc计算机,我会用Solaris。

值得一提的是,我不费吹灰之力装了linux,还在上面装了gcc,emacs 18.57,kermit和其他的GNU工具包。我就按着安装步骤一步步来的,也没有打任何补丁。如果不是Linux,我想我不管在哪儿不可能以如此低的成本搞到这么像样的一个OS来做我计算机科学的作业了。并且它似乎还支持网络,X-Window很快也会移植到Linux上,这一点又要比Minix捷足先登了。Linux真是实用。在我看来,标准UNIX软件的可移植性也很重要。

我也知道宏内核的设计不如微内核好。但是如果就看这一个学期(我知道这个学期我也只能用386了)的话,Linux完全适合我。

Philip Wu

pwu@unixg.ubc.ca


发信人: dgraham@bmers30.bnr.ca (Douglas Graham)
主题: 回复:Linux过时了
日期: 1 Feb 92 00:26:30 GMT
组织机构: Bell-Northern Research, Ottawa, Canada

在文章12595@star.cs.vu.nl中ast@cs.vu.nl (Andy Tanenbaum) 说道:

如果要争论这两种设计的优缺点,我可以花很多篇幅来讲。但是如果让那些真正设计过操作系统的人来说,这场争论毫无异议已经结束。微内核赢了。

你可以推荐一些(无偏见的)分析这两种设计优缺点的文献么?我知道肯定有一些讲微内核的文章,但是我怀疑的是Minix究竟和其他用微内核的系统有几分相像?不错,Minix用了不少的任务和消息,但是微内核的架构肯定不止这么些东西。我怀疑minix的代码在任务区分上是不是最优的。

微内核赢了。宏内核现今唯一拿的出手的只剩下了性能。——可惜现在有足够多的证据表明微内核也能和宏内核跑的一样快(如 Rick Rashid 已经发表的关于对比Mach 3.0和宏内核性能的论文)。所以,一切争论已经结束,剩下的都是瞎嚷嚷了。

我对Minix最想抱怨的地方不是性能,而是要给它添加新的特性是不是会让人苦不堪言——按理来说这对微内核架构应该要容易些。

MINIX是微内核系统。

这么说大家都同意么?

Linux是宏内核的.这完全是倒退到了20世纪70年代。这好比用Basic来重写一个已经出色工作的C语言程序一样。对我而言,在1991年写一个宏内核系统真是一个糟糕的主意。

这样的断言真是不错,但还是想听听你是怎么分析的。我琢磨Linux顶多也就12000行代码。我看不出怎样把它们分到不同的任务里然后再加一堆破破烂烂的消息才能对Linux有所提升。

别误会我,我不是对Linux不满意。这会使得那些想从Minix换到BSD UNIX的人对我唠叨个不停。但凭心而论,对于那些想要一个够现代够免费的OS的人们,我真心建议他们找一个基于微内核的可移植的OS,比如像GNU或者其他类似的。

好吧,最近我没注意到有什么别的选择了。但是如果GNU OS出现了,它可能还是很有吸引力的。我总觉得你对Linux多少有点不太满意(这也多少让我有些吃惊)。我只好猜想这是因为有这么多的人都投向它的怀抱,毕竟它提供了更多的特性。面对人们对新特性的诉求,你的处理方式已经渐渐让大家觉得他们再也得不到那些特性了。我的结论就是人们成批的转向Linux证明你错了。

免责申明: 我和Linux开发没任何关系的。我只是发现它是一个比Minix更易懂的系统。

Doug Graham

dgraham@bnr.ca

观点全来自个人


发信人: hedrick@klinzhai.rutgers.edu (Charles Hedrick)
主题: 回复:Linux过时了
日期: 1 Feb 92 00:27:04 GMT
组织机构: Rutgers Univ., New Brunswick, N.J.

软件的历史告诉我们可用性每次都能完胜优秀的技术。这是Linux最大的优势。它基于386,系统极为精巧,和通用UNIX兼容的非常好,而且还是自由开放的。几年前我就舍弃了Minix社区,因为那个时候以下几点已经变得很明显了:

(1)Minix在未来几年一点都没有要利用比8086更高级的特性的意思。

(2)许可证——尽管还是及其友好的——但仍旧很难让对其有兴趣的人们开发一个386的版本。有好几个人明显已经在386上做出了相当出色的工作了,但他们只能用diff给源代码发布补丁。这让新手想装一个386的系统变得不切实际,事实上我也不太确定我是不是愿意这么搞。

如果最近几年发生了新的动向,我在此致歉。如果现在有希望以某种形式搞到一个386版本拿来就能跑,而且社区也已经开发出一种共享Minix源代码的方式,而且在期间跑常规的UNIX程序变得容易了的话,我还是愿意重新考虑一下Minix的。我真心喜欢这个架构。

Linux也不是没有可能不会被GNU或者是BSD取代。但是如果GNU的操作系统也像其他的GNU软件一样的话,那么它至少也得需要128M的内存和1G的硬盘。再放一个小点的系统还是有空间的。我理想中的OS其实是4.4BSD。但是4.4向来喜欢长时间延期发布。一想到他们大部分成员都搬到了BSDI(Berkely Software Design Inc,伯克利软件设计公司),我就打死都不会相信这一点会有所改善。就我个人使用经验来看,BSDI的系统可能会比较给力。但是他们那些”诱人”的价格也极有可能对我们大部分学生都高的吓人。就算用户能从他们那儿拿到源代码,但是软件的所有权却再次意味着你没有权利把修改后的代码发布到FTP上。无论如何,现在有Linux了,让剩下的那些选择们吹他们的大牛去吧。


发信人: tytso@athena.mit.edu (Theodore Y. Ts’o)
主题: 回复:Linux过时了
日期: 31 Jan 92 21:40:23 GMT
组织机构: Massachusetts Institute of Technology

ast@cs.vu.nl (Andy Tanenbaum)说:

我认为为一个特定的系统结构设计一款内核显然是个错误,因为这样的内核必然不能走远。

认为Linux紧密依附于80386,这不是你的错,因为这么多的Linux拥护者(包括Linus自己)都是这么声称的。然而,Linux里与386相关的代码量比Minix的实现里大概也多不了多少,并且和4.3BSD里与VAX相关的代码量比起来,它的量明显要少得多。

但是,向其他体系结构的移植还没有开始呢。但如果让我在新的体系结构下面做一个类UNIX系统,我宁愿用Linux也不用Minix,很简单,至少在我的系统完成了之后我还是想对我的系统有点儿控制力的。不错,我肯定得为设备驱动和虚拟内存重写大量的代码——但是换哪个系统不是这样呢?或许和Minix比起来把Linux移植到新的体系结构上要难上那么一点点;但这仅仅适用于我们要移植的第一个新体系结构。

如果要争论这两种设计的优缺点,我可以花很多篇幅来讲。但是如果让那些真正设计过操作系统的人来说,这场争论毫无异议已经结束。微内核赢了。宏内核现今唯一拿的出手的只剩下了性能。——可惜现在有足够多的证据表明微内核也能和宏内核跑的一样快(如 Rick Rashid 已经发表的关于对比Mach 3.0和宏内核性能的论文)。所以,一切争论已经结束,剩下的都是瞎嚷嚷了。

这根本不是这么回事么。我想你肯定在现实基础上添油加醋了不少。我推荐你看点其他类的论文,比如Brent Welsh(welch@parc.xerox.com)的”文件系统应该包含在内核内部”。在这篇论文里它论述了文件系统作为一个成熟的抽象层,它应当包含在内核中,而不应该像微内核的设计那样在内核之外。

也有一些人在把OSF/1的Mach和宏内核系统做了对比后研究过它的性能;尤其是在管理网络通信时其所需的上下文切换的次数,举个更特殊的情况如网络文件系统。

我对微内核实现上有哪些优势还是一清二楚的。但是事实就是这样:Linux已经能用了,而GNU内核还不知道在哪里——并且人们在Hurd上面花的时间要比Linus在Linux上花的时间多多了。

我觉得在微内核还是宏内核的权衡上完全取决于你到底想干什么。如果你的兴趣是做研究,那么在微内核里删除替换一些模块那是容易的多,并且也就搞研究的家伙们发发OS的论文,照这个事实微内核肯定是正道。但是,我的确也认识很多别的人,他们不是研究人员,但他们是实实在在的内核程序员,他们更关心的是在微内核里内存复制的开销和上下文切换上的开销。

顺带说一句,你说你在单用户系统里用不着多线程的文件系统,我一点都不买你这个账。一旦你启动了一个窗口系统,并且一个窗口里运行了一个编译器,另一个窗口里运行了一个新闻组阅读器,并且UUCP(UNIX-to-UNIX Copy, 另外一个协议,在Intenet流行之前用的很多)新闻源源不断的从后台涌出,到这个时候你就想要一个性能好点的文件系统了,就算你跑的是单用户。也许对于一个理论家,这只是一个没用的优化,也只是一个”性能上的技巧”(盗用你的词),但我感兴趣的是真正的操作系统——不是拿来做研究的玩具。

Theodore Y. Ts’o


发信人: joe@jshark.rn.com
主题: 回复:Linux过时了
日期: 31 Jan 92 13:21:44 GMT
组织机构: a blip of entropy

在文章12595@star.cs.vu.nl中ast@cs.vu.nl (Andy Tanenbaum) 说到:

MINIX在移植性上的设计较为合理。并且已经从英特尔的处理器移植到了68000,SPARC,和NS32061的芯片上。

如果你在相信作者之前看看源代码,你就能知道这根本就是在吹牛。

他把’fubyte’替换成了一个函数,函数里还显式的使用了一个段寄存器。——但那明明很容易就能改掉。

类似的,一些地方假定使用了386的MMU,其他地方用几个宏把真正的页面大小隐藏起来也让移植变得非常琐碎。用386的TSS能让代码简单一些,而且VAX和WE32000里也有类似的结构啊。

他自己也承认过:再多花点时间设计,系统代码可能会更整洁些,但放点386汇编也不算为过啊。

其实恕我直言:

——全书(译者注:指Tanenbaum写的《操作系统,设计与实现》一书,在书中他用Minix作为示例讲解操作系统的实现)压根就没有提过可移植性的话题(除了一些“#ifdef M8088”的宏)

——在minix发布的时候,它已经依赖了很多8086的特性,这让68000的用户们颇为不满。

joe


发信人: entropy@wintermute.WPI.EDU (Lawrence C. Foard)
主题: 回复:Linux过时了
日期: 5 Feb 92 14:56:30 GMT
组织机构: Worcester Polytechnic Institute

在文章12595@star.cs.vu.nl中ast@cs.vu.nl (Andy Tanenbaum) 说到:

别误会我,我不是对Linux不满意。这会使得那些想从Minix换到BSD UNIX的人对我唠叨个不停。但凭心而论,对于那些想要一个够现代够免费的OS的人们,我真心建议他们找一个基于微内核的可移植的OS,比如像GNU或者其他类似的。

我相信你讲这话的时候肯定是有事实依据的,尽管我还不太确信微内核到底是不是更好一点。如果能把这二者有所结合的话兴许还更合理些。我最近在给Linux写进程间通信,我准备添加一些代码让文件系统和设备驱动在用户进程中运行。这将明显会降低性能,我也相信把所有东西都放到内核外是不明智的(TCP/IP肯定会在内核里面的)。

其实我对OS理论家们的主要问题是他们是不是从来不测试他们的想法的。这些主意看上去没一个靠谱的(Mach可能部分算得上一个意外)。32位的家庭电脑都流行了10多年了,但写一个能用的操作系统让大家省得花100000美元向AT&T买,Linus是第一人。一个手头能用的软件要比一堆不切实际的破烂有价值的多,OS理论家们指责起一个系统来倒是轻轻巧巧,但他们从来都不愿意提供一个选择给大家。

如果一个微内核上面从来都没跑过一个实际的应用程序,那么”微内核是发展趋势”这种论断就必然狗屁不通。

Linux的发布给了我一个机会让我尝试一些我好几年前就想试验的点子,之前我还没有过任何机会给一个运作良好的操作系统维护源代码。


发信人: ast@cs.vu.nl (Andy Tanenbaum)
主题: 回复:Linux过时了
日期: 5 Feb 92 23:33:23 GMT
组织机构: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

在文章1992Feb5.145630.759@wpi.WPI.EDU中entropy@wintermute.WPI.EDU (Lawrence C. Foard)说:

其实我对OS理论家们的主要问题是他们是不是从来不测试他们的想法的。

这简直是奇耻大辱。我不是什么理论家。不信去问问昨天在我们系开会的人们(开玩笑啦)。

事实上,这些想法已经在实践中做了很好的测试。OSF把它们整个商业业务的宝都押在一个微内核上(Mach3.0)。USL则押在另一个上(Chous)。这两个系统上都跑了大量的软件,并且他们也都和宏内核的系统做了广泛的对比。Amoeba有完整的实现,也用大量的软件做了测试。QNX是一个基于微内核的操作系统,有些人告诉我其安装量达20 0000。微内核不是白日做梦。事实证明它们代表了技术。

研究Mach的人们写了一篇名为”让UNIX作为一个应用程序”的论文。是Golub等人写的,发表在1990年夏天的USENIX会议上。Chorus的研究者们也有一篇关于微内核性能的技术报告,在这个话题上我也和别人合写过另一篇文章,昨天我刚提过(1991年12月发表在Computing Systems上)。你可以看一下。

Andy Tanenbaum (ast@cs.vu.nl)


发信人: peter@ferranti.com (peter da silva)
主题: 回复:Linux过时了
组织机构: Xenix Support, FICC
日期: Thu, 6 Feb 1992 16:02:47 GMT

在文章12747@star.cs.vu.nl中ast@cs.vu.nl (Andy Tanenbaum) 说到:

QNX是一个基于微内核的操作系统,有些人告诉我其安装量达20 0000。

好吧好吧,既然我扯进这个话题了….Amigas还超过三百万呢,这意味着它要比任何一个UNIX发行商卖出的量都多,或许比所有的UNIX系统加起来都多。


发信人: peter@ferranti.com (peter da silva)
主题: 回复:Linux过时了
组织机构: Xenix Support, FICC
日期: Thu, 6 Feb 1992 16:00:22 GMT

在文章1992Feb5.145630.759@wpi.WPI.EDU中entropy@wintermute.WPI.EDU (Lawrence C. Foard) 说到:

其实我对OS理论家们的主要问题是他们是不是从来不测试他们的想法的。

恕我略有微词…有那么多的微内核操作系统呢,从8088(QNX)到大型的研究性系统,它们有各种产品。

这些主意看上去没一个靠谱的(Mach可能部分算得上一个意外)。32位的家庭电脑都流行了10多年了,写一个能用的操作系统让大家省得花100000美元向AT&T买,Linus是第一人。

这些年我肯定生活在AmigaOS的幻觉里。对于这个我意淫出来的系统,我已经用了6年了。

AmigaOS作为一个微内核系统,其设计理念是消息传递,其响应时间和性能都强过现在任何一个能用的操作系统:包括minix,OS/2,Windows,MacOS,Linux,UNIX,当然还有MS-DOS。

事实证明微内核设计是无价之宝。像新型文件系统之类的东西,本来你只能从发行商那里得到,而在Amiga上总会有内核爱好者帮你实现出来。设备驱动要么就是共享库,要么就是入口地址和消息端口都固定的任务。像这样的模块还有文件系统,窗口系统,不一而足。它的设计简直棒极了,也证实了人们对微内核的一切预期。不错,要让他们顺畅运行,比起一个像UNIX一样基于宏内核的多任务系统来说,得多花点时间,但考虑到其完善性,这是件一劳永逸的事。

我真心希望Andy能吸取之前发布版的经验教训再做一个新的MINIX。MINUX做的有点太不负责了,但是它的基本理念还是相当不错的。

如果一个微内核上面从来都没跑过一个实际的应用程序,那么”微内核是发展趋势”这种论断就必然狗屁不通。

我又开始产生幻觉了。我深信Deluxe Paint, Sculpt 3d, Photon Paint, Manx C, Manx SDB, Perfect Sound, Videoscape 3d还有其他我为我Amiga买的软件是”真实存在”的。我估计得把这些该死的东西退回去了。

Linux自由好用是相当不错。它的存在很让我高兴。我也知道它能够如此迅疾得以实现的一个原因是它采用了宏内核的架构,这也是采用宏内核一个很正当的缘由。但是,这并不意味着微内核天生就很慢,或者仅仅只是一个用来研究的玩具。


发信人: dsmythe@netcom.COM (Dave Smythe)
主题:回复:Linux过时了
日期: 10 Feb 92 07:08:22 GMT
组织机构: Netcom-Online Communication Services (408 241-9760 guest)

在文章1992Feb5.145630.759@wpi.WPI.EDU中entropy@wintermute.WPI.EDU (Lawrence C. Foard) 说:

其实我对OS理论家们的主要问题是他们是不是从来不测试他们的想法的。这些主意看上去没一个靠谱的(Mach可能部分算得上一个意外)。

David Cheriton(在斯坦福大学任教授,并且是System V的作者)在一堂分布式系统的课上说过和这个类似的话。原话大意是这样的:

“研究人员分两种:实现过一些东西的和还没有实现过什么的。后者一般会和你说实现某某某有142种方法,但哪个最好目前还没有定论。而前者直接就会告诉你有141种是靠不住的。”

他实际上是在揶揄OSI的脾性,也是出于相似的原因。一方面,互联网协议只有在实际使用了一段时间后才可以被采纳,这样可以防止那些理论上很流行但永远都不可实现的东西标准化。另一方面呢,OSI的追随者们似乎总倾向于把什么都拿来标准化,包括那些脱离事实标准,还没有一个合理实现的东西。结果呢,你就会看到那些过时了的东西都籍此获得了永生,比如说半个字节的数据封包,当你的电脑接入带宽有10G以上的线路上时,这东西让高性能成了痴人说梦。


Linus Benedict Torvalds
发信人: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
主题: Apologies (was Re: LINUX is obsolete)
日期: 30 Jan 92 15:38:16 GMT
组织机构: University of Helsinki

在文章<1992Jan29.231426.20469@klaava.Helsinki.FI> 中我说道:

好吧,像这样的一个话题,恐怕我非回复不可。

我的确也做了回复,口气还甚是强硬,也没有注意到得体和礼节。在这里向Andy Tanenbaum道个歉,也多谢John Nall在“事情不是这么做的”这份信里的提醒。我言语有点过激,现在也正在给Andy Tanenbaum写信(语气缓和多了)。

希望没有人因这两点而对linux感到厌倦:它可能有点过时了(不过我仍旧觉得不是这么回事,尽管一些评价还是中肯的);它是一个愣头青写的。

但愿这是我第一次也是最后一次在网络上的激烈反击。

Linus Torvalds


发信人: pmacdona@sanjuan (Peter MacDonald)
主题:回复:Linux过时了
日期: 1 Feb 92 02:10:06 GMT
组织机构: University of Victoria, Victoria, BC, CANADA

考虑到我觉得在Minix和Linux的这场讨论中我属于最早发消息的,我觉得我还是有必要说说我为什么从Minix换成Linux的。我按重要程度罗列一下原因:

1) Linux是免费的。

2) Linux发展在一个让人满意的修改之中(因为Linus允许在发行版中添加新特性).

第一点需要稍加解释,因为如果我已经买了一款Minix的话,对价钱我还有什么可关心的?很简单。如果OS是免费的,就会有更多的人使用它,支持它,投向它的怀抱。当我买了一个386而没买sparc(只要多花30%的钱)时,我也是这么考虑的:PC便宜了,也好用了,肯定会有更多的人用,大量优秀的、便宜的/免费的软件自然也会随之而来。

只要之前用过Minix的人,第二点应当是相当明显的。总的来说,ast不允许对Minix做改进。这不是在挑衅,仅仅是陈述事实。ast对此有极好的也极为正当的理由,对此我也不想与其争辩。但是Minix里面有一些我完全难以忍受的缺陷,并且由于ast的这个策略,我觉得似乎再也看不到他们能够被及时解决了。这些缺陷包括:

•没有对386的支持没有虚拟终端

•没有符号链接

•没有select系统调用

•没有伪终端

•没有请求调页/盘交换区/共享正文段/共享库….(就是说没有有效的内存管理)

•chmem(内 存管理真够顽固)(译者注:在可执行文件中,一般会有一个字段指定该可执行文件的初始栈的大小。在绝大多数的现代操作系统中,如果栈的使用量达到这个值会 自动扩充。Minix的栈不会扩充,所以如果程序要使用较大的栈,需要在进程初始化的时候用chmem命令来指定栈的大小。)

•没有X-Windows(出于同样的原因,提倡Linux和386也添加这个特性)

•没有TCP/IP

•不能够和GNU/System V集成(可移植性)

一些缺陷可以通过打补丁修复(并且你如果自己试过了的话,我就不告诉你效果有多好了),但是至少最后五项之再也没有指望了。

最后,我曾试着把Minix伪终端补丁的代码当作一个如何在Linux下实现伪终端的教程,在此期间我产生了沮丧和困惑。所以我对Minix的段式内核或者微内核架构的评论更多的来说只是我这种情感的一种表现方式。一个很特殊的例子就是消息传递大大加剧了特性实现上的复杂程度。

对宏内核和”传递消息”我还是有自己的观点的,但现在不想说,以前也没有过说的意思。其实我的目光很短浅的(用最小的时间/开销/困难,实现功能的最大化),所以我的观点不怎么切题,也不应该会产生误会。

如果你不介意上面那些特性的缺失,那你可以考虑Minix,当然只要你不在乎付费。


发信人: olaf@oski.toppoint.de (Olaf Schlueter)
主题:回复:Linux过时了
日期: 7 Feb 92 11:41:44 GMT
组织机构: Toppoint Mailbox e.V

发表一些关于Linux对比Minix的评论,这个话题也是部分由于讨论微内核和宏内核而展开的。

如果记不住Linux和Minix是为不同应用设计的,那么我觉得两方在各自的概念上永远也不会有调和。如果你就想在一台机器上跑一个便宜,功能强劲并且可扩展的UNIX系统,并且还希望可以无痛使用标准的UNIX软件,那么Linux是你的不二选择。如果你对现代操作系统的概念感兴趣,也想学习一下一个微内核系统是怎么运作的,那么Minix则是一个更好的选择。

这并不是一场抵制微内核的争论,不是说当下在PC上基于宏内核的UNIX实现性能更好。这仅仅意味着,UNIX这种设计更适合用宏内核实现,至少如果只在一台机器上跑是这样的。从用户的观点来看,随你OS内部用什么实现都无妨。但是在网络出现之后这一点有改观了。在宏内核的实现里,一个文件服务器将会基于ethernet成为一个用户态进程。程序如果想使用这个设备的话,它们必须得利用一些库提供的接口调用来和服务器通信。在一个微内核里,服务程序很有可能就包含在内核内部了,也用不着新的系统调用。从用户角度来看,这是有优势的,因为系统没什么改动,性能就好起来了(比如就节省了磁盘空间这一点来说)。从实现这的角度来看,微内核系统能更快的适应硬件设计的修改。

大家也批评过了,ast拒绝minix的任何改进。由于他更感兴趣minix的教学价值,我理解他的说法——他想让代码保持的足够简洁,不想用特性使它超负荷。作为一个教学工具,minix实现成了一个微内核,尽管它跑在那些用宏内核性能会更好的硬件上。但是网络应用的领域正在发展中,像Amoeba或者Plan 9这样的现代OS不可能写成宏内核的。所以写Minix的目标就是给学生一个活生生的微内核操作系统的例子,让他们品玩任务和消息。提供给广大群众一个便宜而功能强劲的操作系统,而价格仅仅只是System Vh和BSD的十分之一,不是他的初衷。

总结:Linux不比Minix好,反过来说也不行。他们各自都有自己好的理由。


Andy Tanenbaum
发信人: ast@cs.vu.nl (Andy Tanenbaum)
新闻组: comp.os.minix
主题:有些人不高兴了
日期: 3 Feb 92 22:46:40 GMT
组织机构: Fac. Wiskunde &h; Informatica, Vrije Universiteit, Amsterdam

最近我一直有收到几个情绪有点不忿的小伙子的邮件(事实上是43000个读者中的10条消息,看起来有点多,其实还好)。内容集中在三个关键点上:

1.宏内核不比微内核差

2.移植性没那么重要

3.软件应该是自由免费的

如果有人需要对宏内核和微内核做一场严肃认真的讨论,完全可以。我们可以在comp.os.research上开展这件事情。但是发表言论的时候别让人觉得你都不知道自己在说什么。我参与设计和实现过三个操作系统了,一个是宏内核的,两个是微内核的,也仔细研究过很多其他的系统。你们很多东西听起来就是无稽之谈(例如什么微内核不行因为你不能在用户态空间下实现分页——是不是先得把Mach已经在用户态空间实现了分页排除出去呢)。

如果你对微内核和宏内核仍旧只是一知半解,你可以参考我和Fred Douglis、Frans Kaashoek还有John Ousterhout合写的一篇论文,里面应该有一些有用的信息,论文是1991年12月发表在USENIX journal上的,关键字是计算系统。如果你没有该期刊,在ftp.cs.vu.nl (192.31.231.42)上,你可以从amoeba/papers目录中下载该论文的tex源代码压缩包或者ps文档的压缩包。论文中给出了实际的性能测试,并且也支持了Rick Rashid’s的结论——微内核和宏内核性能一样好。

至于移植性么,几乎再难做什么严肃正式的讨论了。UNIX已经移植到了各种各样的PC上和各种各样的Cray上。写一个可移植的操作系统比写一个不可移植的并不会难多少,而在现今时代中,务必牢记写任何系统都得可移植性。当然教Linus操作系统课程的老师也提到了这一点。把操作系统的代码写的可移植又不是我在1987年发明的。

如果谈内核的设计和可移植性,大家还是可以有点理性思维的;但若涉及到免费这个话题,这完全就是情感上的问题了。我要说在不免费的minix上近期我根本没赚到几个子儿,你肯定不会相信。一份minix的价格是169美元,但是它的许可证允许有两份拷贝,所以一份minix的实际价格根本都不到60美元。更有甚者,教授可以向他的学生们随意发放拷贝。Coherent的价格是99美元。假若你没有互联网的话,FSF为它们的”自由”软件索取的磁带烧录费用超过100美元,而且我也从来没听过有人抱怨这个。4.4 BSD的价格是800美元。我真的不觉得钱是个问题。另外,这个新闻组的绝大部分读者或许都已经有一份Minix了。

我觉得把软件扔在ftp上让大家自由下载并不是提供广泛分发的最佳方式——我估计不是人人都赞同这个观点。因特网仍然还是一个非常小众的东西。绝大部分的计算机用户都不上网。当我从PH那里得知Minix使用最广泛的地方是德国而不是美国的时候,我就产生了这样的见解,因为有一家德国的电脑杂志一直在对Minix做大量的宣传推广。Minix在东欧,日本,以色列,南美等地方也很流行。如果没有一家公司做销售,这些人中的绝大多数肯定永远都不会用它。

让我们回来接着谈”自由”意味着什么,是源代码可自由获取么?Conerent只有二进制文件,但Minix也像Linux一样有源代码。只要你愿意,你怎么改都成,然后也可以把你修改后的东西发到这里来。人们都这么做了个5年了,也没出过什么问题。我也免费提供了好几年的升级了。

我觉得真正该谈的应该是别的一些东西。我一直收到各种各样的更新:虚拟内存,分页,符号链接,窗口系统。我总是回绝是因为我仍然试着让系统保持足够简洁,这样学生才可能搞懂它。你可以把这一堆东西都放到你的版本里去,而我不能。我想正是这点惹烦了那些说“Minix不自由免费”的人们,根本不是60美元的问题。

一个很有意思的问题就是Linus是不是愿意让Linux变得“自由”到他所不能掌控。人们能够修改它(或者糟蹋它)并且拿来出售么?还记得英格兰的Minix中心收费出售带有新闻邮件的磁盘么?还记得那成百上千份以“Re: 你的软件被出售了”为标题的消息么?

假设Fred van Kempen(译者注:Linux的重要缔造者,实现了Linux上面的网络协议栈)想把Linux接管过来,创建一份Fred的Linux和Linus的Linux,它们都很有用但是却并不相同。这可以么?当有一大群人想要以一种Linus并不喜欢的方式来发展Linux的时候,这样的挑战就来了。当然除非这样的事情真的发生了,不然就这么空说是没有意义的。如果你们偏向于Linus的哲学,而不是我的,那不管怎样追随他就是了,但不要声称你这么做是由于Linux是“自由的”。还不如说你想要个有很多花哨特性的系统。

另外,我有话要对那些不读新闻标题的人说。Linus在芬兰而我在荷兰。我们的存在是不是使这样的一种情形发生了:自由软件,作为一个关键的产业,一直是由美国主导的,现在逐渐被来自其他国家的竞争给取代了。我们是不是很快就能看到布什总统带着Richard Stallman和Rick Rashid来访问欧洲,然后要求欧洲引入更多的美国软件了呢?

Andy Tanenbaum (ast@cs.vu.nl)


发信人: fnf@fishpond.uucp (Fred Fish)
新闻组: comp.os.minix
主题:回复:有些人不高兴了
日期: 4 Feb 92 20:57:40 GMT
组织机构: Amiga Library Distribution Services

在文章<12667@star.cs.vu.nl>中ast@cs.vu.nl (Andy Tanenbaum) 说:

如果谈内核的设计和可移植性,大家还是可以有点理性思维的;但若涉及到免费这个话题,这完全就是情感上的问题了。我要说在不免费的minix上近期我根本没赚到几个子儿,你肯定不会相信。一份minix的价格是169美元,但是它的许可证允许有两份拷贝,所以一份minix的实际价格根本都不到60美元。更有甚者,教授可以向他的学生们随意发放拷贝。Coherent的价格是99美元。假若你没有互联网的话,FSF为它们的”自由”软件索取的磁带烧录费用超过100美元,而且我也从来没听过有人抱怨这个。4.4 BSD的价格是800美元。我真的不觉得钱是个问题。另外,这个新闻组的绝大部分读者或许都已经有一份Minix了。

发行版的价格不是问题。正如你所说,没有人抱怨过FSF发行版的费用太高。我个人认为,问题在于,对于那些就想要一个能用的发布版的人来说,该软件的源代码是不是只有一份是合法的。从Minix能用的时候算起,看看Minix新闻组里面的这些信息,我的印象就是没人愿意因为一堆问题去和PH交涉。

我觉得真正该谈的应该是别的一些东西。我一直收到各种各样的更新:虚拟内存,分页,符号链接,窗口系统。我总是回绝是因为我仍然试着让系统保持足够简洁,这样学生才可能搞懂它。你可以把这一堆东西都放到你的版本里去,而我不能。我想正是这点惹烦了那些说”Minix不自由免费”的人们,根本不是60美元的问题。

如果PH没有被授予发行上的垄断的话,所有的Minix黑客们很有可能已经组织创建了一个论坛组,来立志开发增强版的Minix了。这个组的目的可以是制作一个统一的、长期支持的Minix发行版来满足大家的升级需求。这将使得Minix可以在这么些年来按着gcc的模式发展。不错,现在是有好几个版本的gcc,但是绝大多数真正优秀的改进和缺陷修复最终都反馈到了主代码分支里——新的发布版也将依据这个而产生。这样的结果是:你可以继续牢牢控制着你的教育版minix,不想只要一个教学工具的其他们也能把他们的精力放到增强版的minix里。

刚开始听到minix能用这个消息时,我也很兴奋。但在这股高兴劲儿过后,我却一直都没有使用它。随便去试验各种补丁,然后找出问题,最后折腾一个我想要的系统,但我的经验根本无法适用于别人——我对这样的事情毫无兴趣:这也是我不用Minix的缘故。

当有一大群人想要以一种Linus并不喜欢的方式来发展Linux的时候,这样的挑战就来了。 当然除非这样的事情真的发生了,不然就这么空说是没有意义的。

想按着rms/FSF(译者注:rms是自由软件之父Richard Stallman全名的缩写;FSF是自由软件基金会的缩写)不赞同的方式发展gcc,这样的人在哪里?

想按着rms/FSF不赞同的方式发展emacs,这样的人在哪里?(译者注:事实上,在1991年,Jamie Zawinski等人因和rms的意见不和开始基于GNU Emacs 19做开发,几年后它发展成了emacs的另一个重要分支:xemacs。)

我想说的是:自由发布但有用的软件的主要维护者们对于吸收有用的更新能保持响应,并且扮演一个中心仓库的角色来保持软件的干净整洁,那么分散的软件组们根本就不会有足够的动机另起炉灶。软件只有一份代码,主要维护者们还对大量用户的愿望不理不睬,才是这种压力(指用户们希望对软件做个新的版本,译者注)产生的诱因;而非软件的自由。

Fred


发信人: ast@cs.vu.nl (Andy Tanenbaum)
主题: Re: Unhappy campers
日期: 5 Feb 92 23:23:26 GMT
组织机构: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

在文章<205@fishpond.uucp> 中fnf@fishpond.uucp (Fred Fish) 说:

如果PH没有被授予发行上的垄断的话,所有的Minix黑客们很有可能已经组织创建了一个论坛组,来立志开发增强版的Minix了。这个组的目的可以是制作一个统一的、长期支持的Minix发行版来满足大家的升级需求。这将使得Minix可以在这么些年来按着gcc的模式发展。不错,现在是有好几个版本的gcc,但是绝大多数真正优秀的改进和缺陷修复最终都反馈到了主代码分支里——新的发布版也将依据这个而产生。这样的结果是:你可以继续牢牢控制着你的教育版minix,不想只要一个教学工具的其他人们也能把他们的精力放到增强版的minix里。

这样的事也不是没可能发生。如果有这么一组人愿意做这件事情,那再好不过。我觉得和1000个遍布世界各地的怪人协调工作就像养猫一样容易,而且这么一来连法律问题都给免了。当准备发布一个新版本时,只要做一个diff列表然后把它放在ftp上就好了。尽管用户在安装的时候要花点儿功夫,但这也算不上什么麻烦事。再说了,我有shell脚本来制作diff并且安装他们。Fred van Kempen一直在做的也就是这个。他做的不对的地方是他一直坚持要发布新版本的权利,而不是基于PH来发布diff。这让PH退出了这场游戏,这一点都不奇怪,他们根本不热衷于这个。如果人们还想这么做,请自便。

当然,我必然不会把这些更新放到我的版本里,因此得需要花点功夫同步官方版本和和升级版本,但是我很愿意配合来最小化这件事的工作量。我也和Bruce Evans,Frans Meulenbroeks他们这么做了好久了。

如果Linus想要控制Linux的官方版本,然后一群狂热份子们想要朝着另外的一个方向发展,同样的问题就会出现。我不认为真正的问题在与版权,而是协作。像GNU,Minix或者是Linux这样的项目,只有当一个人在负责的时候才能维持下去。在70年代结构化变成被提出来的时候,Harlan Mills就指出说程序团队应当组织的像一个手术团队一样——有一个主刀医生,剩下的是助手;而不应该像屠宰场一样——每人拿一把刀然后各宰各的。

谁要说能让一批不在一起的人们给同一块复杂的代码编程并且还能防止彻底的混乱,那么他肯定从来没有管理过一个软件项目。

想按着rms/FSF不赞同的方式发展gcc,这样的人在哪里?

人们一般不会对一个编译器产生太大的兴趣。给定一个待编译语言(比如说,ANSI C标准),不会有太多的余地来让人们发明新的特性。而一个操作系统有无限的机会让人们来实现自己喜欢的特性。

Andy Tanenbaum (ast@cs.vu.nl)


发信人: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
主题:回复:有些人不高兴了
日期: 6 Feb 92 10:33:31 GMT
组织机构: University of Helsinki

在文章12746@star.cs.vu.nl中ast@cs.vu.nl (Andy Tanenbaum) 说:

如果Linus想要控制Linux的官方版本,然后一群狂热份子们想要朝着另外的一个方向发展,同样的问题就会出现。

这是我第二次受到ast的谴责,他对与自己可能都没有看过的内核妄加评论还感觉良好。至少他没有询问过我,甚至也没有在alt.os.linux上看过相关的东西。也正是如此,没有人把他的那些猜测当真过,对”控制”这个问题,我用两个词(三个?)来表明我的立场:

我不会的(译者注:原文是I won’t)。

一直以来,我对Linux实际保持的控制是我比别人更了解它,并且我也不断在把我的更新放到ftp上。它们实际上已经成了官方的发布,一段时间内我也不认为这个状态会发生改变:不是我觉得我有更多的权利来做这些事情,而是因为我听到的抱怨还不够多,要找到别人对内核所发生的变化和我有一样的感觉,也得等到几个月之后了。(呃,或许现在已经有人选了:tytso对0.10版本做了很大的改动,别人也在其上面做了修改)

事实上,我已经试着在创建一些“linux内核”的邮件列表来决定新版本的发布,因为我料想我无法完全支持所有必须添加的特性:如SCSI等,因为我没有硬件来做测试。响应现在仍是寥寥无几:大家似乎还不急着来改动内核。(嗯,有个人觉得我应当寻求捐赠,这样我就能支持那些特性了——如果我身边有谁有这样的硬件,那我非常感激也非常乐意接受这样的捐赠)。

版权的唯一能阻止(我也觉得这极为合理)的是,别人从中赚钱还不提供源代码……这或许不是个逻辑上的问题,但是如果这样的事情发生了我将会觉得非常糟糕:别人把我的成果拿去卖钱,而我却是特意提供给人们让大家来用它折腾一个自己的项目的。我想大多数人也能体会到我的想法。

另一方面,如果Fred van Kempen想做个超级版的Linux,我热烈欢迎。他从这个上赚不到多少钱(只有发布费用),我觉得把Linux分裂开了也不算什么好主意,但我仍然不会想去阻止他,即便版权允许我这么做。

我不认为真正的问题在与版权,而是协作。像GNU,Minix或者是Linux这样的项目,只有当一个人在负责的时候才能维持下去。

是的,合作是个大问题,我觉得Linux在短期内也离不了我这个”主刀医生”,部分原因也就是大家都知道这个问题。但是版权也的确是个问题:如果人们觉得我工作做得不好,他们可以自己来。这就更gcc一样。而Minix的版权则意味着如果有人觉得他可以做一个更好的minix,他要么必须得制作补丁(不管你怎么说,这都没你吹的那么好),要么必须的另起炉灶从头做起(因为你的不同意见还得遭受攻击)。

发行补丁没什么意思:我还没为任何一个版本的linux做过cdiff呢(我希望这点发生改变:补丁很快就会变得比内核小得多,同时制作补丁和完整的版本是个好主意——注意我也仍旧会让完整的版本可用)。补丁摞补丁很不切实际,尤其是人们可能自己来做修改。

想按着rms/FSF不赞同的方式发展gcc,这样的人在哪里?

人们一般不会对一个编译器产生太大的兴趣。给定一个待编译语言(比如说,ANSI C标准),不会有太多的余地来让人们发明新的特性。而一个操作系统有无限的机会让人们来实现自己喜欢的特性。

额,还有GNU Emacs呢……不要告诉我人们对文本编辑器没有兴趣。

Linus


发信人: dmiller@acg.uucp (David Miller)
主题:关于“Linux过时了”和后续的回复邮件
日期: 3 Feb 92 01:03:46 GMT
组织机构: Applied Computer Group

作为一个对操作系统设计感兴趣的看客,我实在忍不下去了。请注意到我对Minix和Linux都没什么使用经验:这么多年来我都是用Unix的。

首先,看完这么多信件后的评论:

写Minix是为了作为AST课堂上的一个教学工具,而非一个商用操作系统。让它成为源代码自由开放的UNIX,永远都不会成为其设计因素。我认为它也是操作系统设计上的一种阐释:怎样设计一个微内核,让分离的进程来尽可能的覆盖所需的功能。

写Linux对Linus而言基本是一个练习——怎样给386家族编程。设计一个终极的操作系统不是他的目标。提供一个自由可用的平台运行各种各样广泛应用的自由软件是他的一个考虑因素,这一点似乎完成的很好。

任何人对这两个系统的指责,说那不是他们想要的系统,都是不恰当的。无论如何,你的电脑不管跑的是哪个系统,你都可以非常自由的去做Linus和Andrew做过的事情:写一个你自己的系统。

一方面,我为Linux喝彩,他在开发Linux上付出了相当大的努力,还决定把它免费开放给每个人。让minix变成付费软件,我也为AST所做的努力喝彩——对于那些抱怨minix不免费的人,我真的很是不解。如果你能花时间研究minix和一个基础的计算机系统,150美元真的不多的——而且你还能随它买到一本书。

其次,有一些问题要问教授:

Minix的定位是”真正的操作系统”呢还是一个教学工具呢?作为一个教学工具它是一个杰作。作为一个真正的操作系统有些地方它表现的还是太糙了(为什么没有malloc(),仅仅是由于它是为初学者们准备的么?)。读你的书还有在这儿看了这些邮件给我的感觉就是你想要个工具来教学,然后很多其他人是把minix当成一个可以品玩的付费操作系统。他们一直在尝试把大量的特性栓到minix上让它成为一个”真正的操作系统”,不过他们都不太成功。

为什么要把OS的基础功能,如内存管理,挪到用户进程中呢?所有类UNIX领域的优秀专家们都知道,成功的手段是分而治之,目标应该是把问题简化成容易控制而定义明确的模块。如果把操作系统的基础部分分离到用户进程中,然后通过引入其他的技术(消息递送,复杂的信号机制)加剧系统的复杂程度,那么我们有达到简化设计与实现的目的了么?

我赞同UNIX系列的前景不容乐观——特别是SVR4。或许人们想要的那些不管是功能上的还是移植性上的特性都可以通过另外的一个东西来提供:运行时可加载模块/库。微内核仍然可以负责底层的资源管理,其所调用的函数过程在相应的模块/库中。这些模块可以是线程或用户态进程。(我觉得,操作系统黑客们可以在这里纠正一些我的错误)

我的观点没什么价值——回我邮件也不必拘谨。在计算机科学上我没有接受过正式的先进训练,所以我真是出于不懂才问这些问题的。我怀疑这个组里很多人脑子中都萦绕着这些问题,我只不过先拿出来问了。

David


发信人: michael@gandalf.informatik.rwth-aachen.de (Michael Haardt)
主题: 1.6.17总结以及为什么我认为ast是对的
日期: 6 Feb 92 20:07:25 GMT
组织机构: Gandalf – a 386-20 machine

我先总结一下在近期对Minix能有哪些东西值得期待,然后在解释一下为什么我认为AST是正确的。

前段时间,我咨询了一下minix下一个版本(1.6.17)的一些细节。我得到了一些回复,但都是从1.6.16的用户那里来的。以下信息均非来自官方,也有可能不正确,但这已经是目前我所知的一切。如果有错误希望指正。

•1.6.17补丁将和PH1.5的发行版相关。

•头文件清除了。

•两种文件系统可以混用。

•信号控制重新做了实现,和POSIX兼容。消除了旧缺陷。

•ANSI编译器(我猜是从Transmediar那儿来的)以二进制发布,更新了程序库。

•不再支持Amoeba的网络协议。

•修正了times函数的返回结果。实现了termios,但更多的来说只不过是一个技巧。我不知道实现是在内核里呢,还是在现在的模拟器上。

•新的文件系统没有文档。有了新的fsck命令和mkfs命令,不了解详细情况。

•有了ANSI编译器,浮点数得以更好的支持。

•调度策略做了改进,但仍旧不如Kai-Uwe Bloem的实现。

我询问这些事情的实际情况,然后开始据此决定等这场大讨论结束了我是升级到1.6.17呢还是升级成Linux呢。最后我做了决定:月底就换成Linux,然后从我的温盘上把Minix卸载掉。Linux能跑我所需的所有软件,现在我是在一个打满补丁的Minix上跑的。我想这估计要折腾我两个月。我说一下我做这个决定的原因:

•Minix根本就么有一个可以借其打补丁的“当前”发行版,也没有人知道1.6.17什么时候会出来。

•现在的运行库有几个缺陷,我听说现在都还没有修复。不会再有一个新的编译器,16位的用户们还得接着用满是缺陷的ACK(Amsterdam Compiler Kit,阿姆斯特丹编译套件)。

•1.6.17应该会支持更多POSIX,但是一个完整的伪终端仍旧没有。

我怀疑现在仍旧还有为16位用户做的大量开发。

我想几个月之后我将停止维护minix的软件列表。哪有人还愿意用它?除非Linux能在我机器上顺畅的运行,不然Origami(译者注:Minix下运行的一款老式的文本编辑器)每一次升级后仍旧跑在16位的Minix上。

我认为,ast对他Minix所做的决定是正确的。我读了这次论战,忍不住要说我喜欢Minix的发展方向,现在在这个方向上又有Linux了。Minix的优点有:

•你没有硬盘就能玩它,甚至都能编译程序。几年前我就这么干过。

•它很小,你不用了解多少就能获得一个跑的很爽的小系统。

•还有一本书。不错,虽然只有1.3版本的,但是书本绝大多数内容仍旧有用。

Minix是非宏内核系统的一个示例。不妨叫做微内核,或者是一个为克服愚蠢硬件而做的精巧软件:它证明了一种理念。

在我眼中,对于UNIX和系统编程入门来说,它是一个非常优美的系统。我绝大多数的UNIX知识都是从Minix上学到的。从UNIX下的C语言编程到系统管理(还有安全漏洞),Minix一直随着我成长:1.5.xx版的升级,虚拟终端,邮件和新闻,文本处理,交叉编译等等。我不再需要一个教学系统了,我需要一个更复杂的,特性更多的UNIX,现在有一个了:Linux。

再回到当年,v7的出现诠释了艺术二字。然后有了Minix,支持其绝大多数特性。一两年后,POSIX变成了你现在熟悉的样子。大家满是期待,希望Minix将会再次支持其绝大多数特性,而且还会有一本书,让想跑一个小型系统的大家有的可玩,有东西可做试验。

停止责骂吧,Minix和Linux,道不同不相为谋。一个是教学工具(我也认为是非常棒的一个),而另一个是为真正的黑客准备的真正的UNIX。

Michael

2. Open Sources: Voices from the Open Source Revolution - Appendix A, The Tanenbaum-Torvalds Debate

Appendix A

The Tanenbaum-Torvalds Debate

What follows in this appendix are what are known in the community as the Tanenbaum/Linus “Linux is obsolete” debates. Andrew Tanenbaum is a well-respected researcher who has made a very good living thinking about operating systems and OS design. In early 1992, noticing the way that the Linux discussion had taken over the discussion in comp.os.minix, he decided it was time to comment on Linux.

Although Andrew Tanenbaum has been derided for his heavy hand and misjudgements of the Linux kernel, such a reaction to Tanenbaum is unfair. When Linus himself heard that we were including this, he wanted to make sure that the world understood that he holds no animus towards Tanenbaum and in fact would not have sanctioned its inclusion if we had not been able to convince him that it would show the way the world was thinking about OS design at the time.

We felt the inclusion of this appendix would give a good perspective on how things were when Linus was under pressure because he abandoned the idea of microkernels in academia. The first third of Linus’ essay discusses this further.

Electronic copies of this debate are available on the Web and are easily found through any search service. It’s fun to read this and note who joined into the discussion; you see user-hacker Ken Thompson (one of the founders of Unix) and David Miller (who is a major Linux kernel hacker now), as well as many others.

To put this discussion into perspective, when it occurred in 1992, the 386 was the dominating chip and the 486 had not come out on the market. Microsoft was still a small company selling DOS and Word for DOS. Lotus 123 ruled the spreadsheet space and WordPerfect the word processing market. DBASE was the dominant database vendor and many companies that are household names today–Netscape, Yahoo, Excite–simply did not exist.

From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: LINUX is obsolete
Date: 29 Jan 92 12:12:50 GMT

I was in the U.S. for a couple of weeks, so I haven’t commented much on
LINUX (not that I would have said much had I been around), but for what
it is worth, I have a couple of comments now.

As most of you know, for me MINIX is a hobby, something that I do in the
evening when I get bored writing books and there are no major wars,
revolutions, or senate hearings being televised live on CNN. My real
job is a professor and researcher in the area of operating systems.

As a result of my occupation, I think I know a bit about where operating
are going in the next decade or so. Two aspects stand out:

1. MICROKERNEL VS MONOLITHIC SYSTEM
Most older operating systems are monolithic, that is, the whole operating
system is a single a.out file that runs in ‘kernel mode.’ This binary
contains the process management, memory management, file system and the
rest. Examples of such systems are UNIX, MS-DOS, VMS, MVS, OS/360,
MULTICS, and many more.

The alternative is a microkernel-based system, in which most of the OS
runs as separate processes, mostly outside the kernel. They communicate
by message passing. The kernel’s job is to handle the message passing,
interrupt handling, low-level process management, and possibly the I/O.
Examples of this design are the RC4000, Amoeba, Chorus, Mach, and the
not-yet-released Windows/NT.

While I could go into a long story here about the relative merits of the
two designs, suffice it to say that among the people who actually design
operating systems, the debate is essentially over. Microkernels have won.
The only real argument for monolithic systems was performance, and there
is now enough evidence showing that microkernel systems can be just as
fast as monolithic systems (e.g., Rick Rashid has published papers comparing
Mach 3.0 to monolithic systems) that it is now all over but the shoutin’.

MINIX is a microkernel-based system. The file system and memory management
are separate processes, running outside the kernel. The I/O drivers are
also separate processes (in the kernel, but only because the brain-dead
nature of the Intel CPUs makes that difficult to do otherwise). LINUX is
a monolithic style system. This is a giant step back into the 1970s.
That is like taking an existing, working C program and rewriting it in
BASIC. To me, writing a monolithic system in 1991 is a truly poor idea.

2. PORTABILITY
Once upon a time there was the 4004 CPU. When it grew up it became an
8008. Then it underwent plastic surgery and became the 8080. It begat
the 8086, which begat the 8088, which begat the 80286, which begat the
80386, which begat the 80486, and so on unto the N-th generation. In
the meantime, RISC chips happened, and some of them are running at over
100 MIPS. Speeds of 200 MIPS and more are likely in the coming years.
These things are not going to suddenly vanish. What is going to happen
is that they will gradually take over from the 80×86 line. They will
run old MS-DOS programs by interpreting the 80386 in software. (I even
wrote my own IBM PC simulator in C, which you can get by FTP from
ftp.cs.vu.nl = 192.31.231.42 in dir minix/simulator.) I think it is a
gross error to design an OS for any specific architecture, since that is
not going to be around all that long.

MINIX was designed to be reasonably portable, and has been ported from the
Intel line to the 680×0 (Atari, Amiga, Macintosh), SPARC, and NS32016.
LINUX is tied fairly closely to the 80×86. Not the way to go.

Don’t get me wrong, I am not unhappy with LINUX. It will get all the people
who want to turn MINIX in BSD UNIX off my back. But in all honesty, I would
suggest that people who want a **MODERN** “free” OS look around for a
microkernel-based, portable OS, like maybe GNU or something like that.

Andy Tanenbaum (ast@cs.vu.nl)

P.S. Just as a random aside, Amoeba has a UNIX emulator (running in user
space), but it is far from complete. If there are any people who would
like to work on that, please let me know. To run Amoeba you need a few 386s,
one of which needs 16M, and all of which need the WD Ethernet card.

From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Re: LINUX is obsolete
Date: 29 Jan 92 23:14:26 GMT
Organization: University of Helsinki

Well, with a subject like this, I’m afraid I’ll have to reply.
Apologies to minix-users who have heard enough about linux anyway. I’d
like to be able to just “ignore the bait”, but … Time for some
serious flamefesting!

In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>
>I was in the U.S. for a couple of weeks, so I haven’t commented much on
>LINUX (not that I would have said much had I been around), but for what
>it is worth, I have a couple of comments now.
>
>As most of you know, for me MINIX is a hobby, something that I do in the
>evening when I get bored writing books and there are no major wars,
>revolutions, or senate hearings being televised live on CNN. My real
>job is a professor and researcher in the area of operating systems.

You use this as an excuse for the limitations of minix? Sorry, but you
loose: I’ve got more excuses than you have, and linux still beats the
pants of minix in almost all areas. Not to mention the fact that most
of the good code for PC minix seems to have been written by Bruce Evans.

Re 1: you doing minix as a hobby – look at who makes money off minix,
and who gives linux out for free. Then talk about hobbies. Make minix
freely available, and one of my biggest gripes with it will disappear.
Linux has very much been a hobby (but a serious one: the best type) for
me: I get no money for it, and it’s not even part of any of my studies
in the university. I’ve done it all on my own time, and on my own
machine.

Re 2: your job is being a professor and researcher: That’s one hell of a
good excuse for some of the brain-damages of minix. I can only hope (and
assume) that Amoeba doesn’t suck like minix does.

>1. MICROKERNEL VS MONOLITHIC SYSTEM

True, linux is monolithic, and I agree that microkernels are nicer. With
a less argumentative subject, I’d probably have agreed with most of what
you said. From a theoretical (and aesthetical) standpoint linux looses.
If the GNU kernel had been ready last spring, I’d not have bothered to
even start my project: the fact is that it wasn’t and still isn’t. Linux
wins heavily on points of being available now.

> MINIX is a microkernel-based system. [deleted, but not so that you
> miss the point ] LINUX is a monolithic style system.

If this was the only criterion for the “goodness” of a kernel, you’d be
right. What you don’t mention is that minix doesn’t do the micro-kernel
thing very well, and has problems with real multitasking (in the
kernel). If I had made an OS that had problems with a multithreading
filesystem, I wouldn’t be so fast to condemn others: in fact, I’d do my
damndest to make others forget about the fiasco.

[ yes, I know there are multithreading hacks for minix, but they are
hacks, and bruce evans tells me there are lots of race conditions ]

>2. PORTABILITY

“Portability is for people who cannot write new programs”
-me, right now (with tongue in cheek)

The fact is that linux is more portable than minix. What? I hear you
say. It’s true – but not in the sense that ast means: I made linux as
conformant to standards as I knew how (without having any POSIX standard
in front of me). Porting things to linux is generally /much/ easier
than porting them to minix.

I agree that portability is a good thing: but only where it actually has
some meaning. There is no idea in trying to make an operating system
overly portable: adhering to a portable API is good enough. The very
/idea/ of an operating system is to use the hardware features, and hide
them behind a layer of high-level calls. That is exactly what linux
does: it just uses a bigger subset of the 386 features than other
kernels seem to do. Of course this makes the kernel proper unportable,
but it also makes for a /much/ simpler design. An acceptable trade-off,
and one that made linux possible in the first place.

I also agree that linux takes the non-portability to an extreme: I got
my 386 last January, and linux was partly a project to teach me about
it. Many things should have been done more portably if it would have
been a real project. I’m not making overly many excuses about it
though: it was a design decision, and last april when I started the
thing, I didn’t think anybody would actually want to use it. I’m happy
to report I was wrong, and as my source is freely available, anybody is
free to try to port it, even though it won’t be easy.

Linus

PS. I apologise for sometimes sounding too harsh: minix is nice enough
if you have nothing else. Amoeba might be nice if you have 5-10 spare
386′s lying around, but I certainly don’t. I don’t usually get into
flames, but I’m touchy when it comes to linux :)

From: ast@cs.vu.nl (Andy Tanenbaum)
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 13:44:34 GMT

In article <1992Jan29.231426.20469@klaava.Helsinki.FI> torvalds@klaava.Helsinki.
FI (Linus Benedict Torvalds) writes:
>You use this [being a professor] as an excuse for the limitations of minix?
The limitations of MINIX relate at least partly to my being a professor:
An explicit design goal was to make it run on cheap hardware so students
could afford it. In particular, for years it ran on a regular 4.77 MHZ PC
with no hard disk. You could do everything here including modify and recompile
the system. Just for the record, as of about 1 year ago, there were two
versions, one for the PC (360K diskettes) and one for the 286/386 (1.2M).
The PC version was outselling the 286/386 version by 2 to 1. I don’t have
figures, but my guess is that the fraction of the 60 million existing PCs that
are 386/486 machines as opposed to 8088/286/680×0 etc is small. Among students
it is even smaller. Making software free, but only for folks with enough money
to buy first class hardware is an interesting concept.
Of course 5 years from now that will be different, but 5 years from now
everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5.

>Re 2: your job is being a professor and researcher: That’s one hell of a
>good excuse for some of the brain-damages of minix. I can only hope (and
>assume) that Amoeba doesn’t suck like minix does.
Amoeba was not designed to run on an 8088 with no hard disk.

>If this was the only criterion for the “goodness” of a kernel, you’d be
>right. What you don’t mention is that minix doesn’t do the micro-kernel
>thing very well, and has problems with real multitasking (in the
>kernel). If I had made an OS that had problems with a multithreading
>filesystem, I wouldn’t be so fast to condemn others: in fact, I’d do my
>damndest to make others forget about the fiasco.
A multithreaded file system is only a performance hack. When there is only
one job active, the normal case on a small PC, it buys you nothing and adds
complexity to the code. On machines fast enough to support multiple users,
you probably have enough buffer cache to insure a hit cache hit rate, in
which case multithreading also buys you nothing. It is only a win when there
are multiple processes actually doing real disk I/O. Whether it is worth
making the system more complicated for this case is at least debatable.

I still maintain the point that designing a monolithic kernel in 1991 is
a fundamental error. Be thankful you are not my student. You would not
get a high grade for such a design :-)

>The fact is that linux is more portable than minix. What? I hear you
>say. It’s true – but not in the sense that ast means: I made linux as
>conformant to standards as I knew how (without having any POSIX standard
>in front of me). Porting things to linux is generally /much/ easier
>than porting them to minix.
MINIX was designed before POSIX, and is now being (slowly) POSIXized as
everyone who follows this newsgroup knows. Everyone agrees that user-level
standards are a good idea. As an aside, I congratulate you for being able
to write a POSIX-conformant system without having the POSIX standard in front
of you. I find it difficult enough after studying the standard at great length.

My point is that writing a new operating system that is closely tied to any
particular piece of hardware, especially a weird one like the Intel line,
is basically wrong. An OS itself should be easily portable to new hardware
platforms. When OS/360 was written in assembler for the IBM 360
25 years ago, they probably could be excused. When MS-DOS was written
specifically for the 8088 ten years ago, this was less than brilliant, as
IBM and Microsoft now only too painfully realize. Writing a new OS only for the
386 in 1991 gets you your second ‘F’ for this term. But if you do real well
on the final exam, you can still pass the course.

Prof. Andrew S. Tanenbaum (ast@cs.vu.nl)

From: feustel@netcom.COM (David Feustel)
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 18:57:28 GMT
Organization: DAFCO – An OS/2 Oasis

ast@cs.vu.nl (Andy Tanenbaum) writes:

>I still maintain the point that designing a monolithic kernel in 1991 is
>a fundamental error. Be thankful you are not my student. You would not
>get a high grade for such a design :-)

That’s ok. Einstein got lousy grades in math and physics.

From: pete@ohm.york.ac.uk (-Pete French.)
Subject: Re: LINUX is obsolete
Date: 31 Jan 92 09:49:37 GMT
Organization: Electronics Department, University of York, UK

in article <1992Jan30.195850.7023@epas.toronto.edu>, meggin@epas.utoronto.ca
(David Megginson) says:
>
> In article <1992Jan30.185728.26477feustel@netcom.COM> feustel@netcom.COM
(David > Feustel) writes:
>>
>>That’s ok. Einstein got lousy grades in math and physics.
>
> And Dan Quayle got low grades in political science. I think that there
> are more Dan Quayles than Einsteins out there… ;-)

What a horrible thought !

But on the points about microkernel v monolithic, isnt this partly an
artifact of the language being used ? MINIX may well be designed as a
microkernel system, but in the end you still end up with a large
monolithic chunk of binary data that gets loaded in as “the OS”. Isnt it
written as separate programs simply because C does not support the idea
of multiple processes within a single piece of monolithic code. Is there
any real difference between a microkernel written as several pieces of C
and a monolithic kernel written in something like OCCAM ? I would have
thought that in this case the monolithic design would be a better one
than the micorkernel style since with the advantage of inbuilt
language concurrency the kernel could be made even more modular than the
MINIX one is.

Anyone for MINOX :-)

-bat.

From: kt4@prism.gatech.EDU (Ken Thompson)
Subject: Re: LINUX is obsolete
Date: 3 Feb 92 23:07:54 GMT
Organization: Georgia Institute of Technology

viewpoint may be largely unrelated to its usefulness. Many if not
most of the software we use is probably obsolete according to the
latest design criteria. Most users could probably care less if the
internals of the operating system they use is obsolete. They are
rightly more interested in its performance and capabilities at the
user level.

I would generally agree that microkernels are probably the wave of
the future. However, it is in my opinion easier to implement a
monolithic kernel. It is also easier for it to turn into a mess in
a hurry as it is modified.

Regards,
Ken

From: kevin@taronga.taronga.com (Kevin Brown)
Subject: Re: LINUX is obsolete
Date: 4 Feb 92 08:08:42 GMT
Organization: University of Houston

In article <47607@hydra.gatech.EDU> kt4@prism.gatech.EDU (Ken Thompson) writes:
>viewpoint may be largely unrelated to its usefulness. Many if not
>most of the software we use is probably obsolete according to the
>latest design criteria. Most users could probably care less if the
>internals of the operating system they use is obsolete. They are
>rightly more interested in its performance and capabilities at the
>user level.
>
>I would generally agree that microkernels are probably the wave of
>the future. However, it is in my opinion easier to implement a
>monolithic kernel. It is also easier for it to turn into a mess in
>a hurry as it is modified.

How difficult is it to structure the source tree of a monolithic kernel
such that most modifications don’t have a large negative impact on the
source? What sorts of pitfalls do you run into in this sort of endeavor,
and what suggestions do you have for dealing with them?

I guess what I’m asking is: how difficult is it to organize the source
such that most changes to the kernel remain localized in scope, even
though the kernel itself is monolithic?

I figure you’ve got years of experience with monolithic kernels :-) ,
so I’d think you’d have the best shot at answering questions like
these.

Kevin Brown

From: rburns@finess.Corp.Sun.COM (Randy Burns)
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 20:33:07 GMT
Organization: Sun Microsystems, Mt. View, Ca.

In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>In article <1992Jan29.231426.20469@klaava.Helsinki.FI> torvalds@klaava.Helsinki.
>FI (Linus Benedict Torvalds) writes:

>Of course 5 years from now that will be different, but 5 years from now
>everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5.
Well, I for one would _love_ to see this happen.

>>The fact is that linux is more portable than minix. What? I hear you
>>say. It’s true – but not in the sense that ast means: I made linux as
>>conformant to standards as I knew how (without having any POSIX standard
>>in front of me). Porting things to linux is generally /much/ easier
>>than porting them to minix.
………
>My point is that writing a new operating system that is closely tied to any
>particular piece of hardware, especially a weird one like the Intel line,
>is basically wrong.
First off, the parts of Linux tuned most finely to the 80×86 are the Kernel
and the devices. My own sense is that even if Linux is simply a stopgap
measure to let us all run GNU software, it is still worthwhile to have a
a finely tuned kernel for the most numerous architecture presently in
existance.

> An OS itself should be easily portable to new hardware
>platforms.
Well, the only part of Linux that isn’t portable is the kernel and drivers.
Compare to the compilers, utilities, windowing system etc. this is really
a small part of the effort. Since Linux has a large degree of call
compatibility with portable OS’s I wouldn’t complain. I’m personally
very grateful to have an OS that makes it more likely that some of us will
be able to take advantage of the software that has come out of Berkeley,
FSF, CMU etc. It may well be that in 2-3 years when ultra cheap BSD
variants and Hurd proliferate, that Linux will be obsolete. Still, right
now Linux greatly reduces the cost of using tools like gcc, bison, bash
which are useful in the development of such an OS.

From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Re: LINUX is obsolete
Date: 31 Jan 92 10:33:23 GMT
Organization: University of Helsinki

In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>The limitations of MINIX relate at least partly to my being a professor:
>An explicit design goal was to make it run on cheap hardware so students
>could afford it.

All right: a real technical point, and one that made some of my comments
inexcusable. But at the same time you shoot yourself in the foot a bit:
now you admit that some of the errors of minix were that it was too
portable: including machines that weren’t really designed to run unix.
That assumption lead to the fact that minix now cannot easily be
extended to have things like paging, even for machines that would
support it. Yes, minix is portable, but you can rewrite that as
“doesn’t use any features”, and still be right.

>A multithreaded file system is only a performance hack.

Not true. It’s a performance hack /on a microkernel/, but it’s an
automatic feature when you write a monolithic kernel – one area where
microkernels don’t work too well (as I pointed out in my personal mail
to ast). When writing a unix the “obsolete” way, you automatically get
a multithreaded kernel: every process does it’s own job, and you don’t
have to make ugly things like message queues to make it work
efficiently.

Besides, there are people who would consider “only a performance hack”
vital: unless you have a cray-3, I’d guess everybody gets tired of
waiting on the computer all the time. I know I did with minix (and yes,
I do with linux too, but it’s /much/ better).

>I still maintain the point that designing a monolithic kernel in 1991 is
>a fundamental error. Be thankful you are not my student. You would not
>get a high grade for such a design :-)

Well, I probably won’t get too good grades even without you: I had an
argument (completely unrelated – not even pertaining to OS’s) with the
person here at the university that teaches OS design. I wonder when
I’ll learn :)

>My point is that writing a new operating system that is closely tied to any
>particular piece of hardware, especially a weird one like the Intel line,
>is basically wrong.

But /my/ point is that the operating system /isn’t/ tied to any
processor line: UNIX runs on most real processors in existence. Yes,
the /implementation/ is hardware-specific, but there’s a HUGE
difference. You mention OS/360 and MS-DOG as examples of bad designs
as they were hardware-dependent, and I agree. But there’s a big
difference between these and linux: linux API is portable (not due to my
clever design, but due to the fact that I decided to go for a fairly-
well-thought-out and tested OS: unix.)

If you write programs for linux today, you shouldn’t have too many
surprises when you just recompile them for Hurd in the 21st century. As
has been noted (not only by me), the linux kernel is a miniscule part of
a complete system: Full sources for linux currently runs to about 200kB
compressed – full sources to a somewhat complete developement system is
at least 10MB compressed (and easily much, much more). And all of that
source is portable, except for this tiny kernel that you can (provably:
I did it) re-write totally from scratch in less than a year without
having /any/ prior knowledge.

In fact the /whole/ linux kernel is much smaller than the 386-dependent
things in mach: i386.tar.Z for the current version of mach is well over
800kB compressed (823391 bytes according to nic.funet.fi). Admittedly,
mach is “somewhat” bigger and has more features, but that should still
tell you something.

Linus

From: kaufman@eecs.nwu.edu (Michael L. Kaufman)
Subject: Re: LINUX is obsolete
Date: 3 Feb 92 22:27:48 GMT
Organization: EECS Department, Northwestern University

I tried to send these two posts from work, but I think they got eaten. If you
have seen them already, sorry.

——————————————————————————-

Andy Tanenbaum writes an interesting article (also interesting was finding out
that he actually reads this group) but I think he is missing an important
point.

He Wrote:
>As most of you know, for me MINIX is a hobby, …

Which is also probably true of most, if not all, of the people who are involved
in Linux. We are not developing a system to take over the OS market, we are
just having a good time.

> What is going to happen
> is that they will gradually take over from the 80×86 line. They will
> run old MS-DOS programs by interpreting the 80386 in software.

Well when this happens, if I still want to play with Linux, I can just run it
on my 386 simulator.

> MINIX was designed to be reasonably portable, and has been ported from the
> Intel line to the 680×0 (Atari, Amiga, Macintosh), SPARC, and NS32016.
> LINUX is tied fairly closely to the 80×86. Not the way to go.

That’s fine for the people who have those machines, but it wasn’t a free
lunch. That portibility was gained at the cost of some performance and some
features on the 386. Before you decide that LINUX is not the way to go, you
should think about what it is going to be used for. I am going to use it for
running memory and computation intensive graphics programs on my 486. For me,
speed and memory were more important then future state-of-the-artness and
portability.

>But in all honesty, I would
>suggest that people who want a **MODERN** “free” OS look around for a
>microkernel-based, portable OS, like maybe GNU or something like that.

I don’t know of any free microkernel-based, portable OSes. GNU is still
vaporware, and likely to remain that way for the forseeable future. Do
you actually have one to recomend, or are you just toying with me? ;-)

——————————————————————————

In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>My point is that writing a new operating system that is closely tied to any
>particular piece of hardware, especially a weird one like the Intel line,
>is basically wrong. An OS itself should be easily portable to new hardware
>platforms.

I think I see where I disagree with you now. You are looking at OS design
as an end in itself. Minix is good because it is portable/Micro-Kernal/etc.
Linux is not good because it is monolithic/tightly tied to Intel/etc. That
is not a strange attitude for someone in the acedemic world, but it is not
something you should expect to be universally shared. Linux is not being written
as a teaching tool, or as an abstract exercise. It is being written to allow
people to run GNU-type software _today_. The fact that it may not be in use
in five years is less important then the fact that today (well, by April
probably) I can run all sorts of software on it that I want to run. You keep
saying that Minix is better, but if it will not run the software that I want
to run, it really isn’t that good (for me) at all.

> When OS/360 was written in assembler for the IBM 360
>25 years ago, they probably could be excused. When MS-DOS was written
>specifically for the 8088 ten years ago, this was less than brilliant, as
>IBM and Microsoft now only too painfully realize.

Same point. MSoft did not come out with Dos to “explore the frontiers of os
research”. They did it to make a buck. And considering the fact that MS-DOS
probably still outsells everyone else put together, I don’t think that you
say that they have failed _in their goals_. Not that MS-Dos is the best OS
in terms of anything else, only that it has served their needs.

Michael

From: julien@incal.inria.fr (Julien Maisonneuve)
Subject: Re: LINUX is obsolete
Date: 3 Feb 92 17:10:14 GMT

I would like to second Kevin brown in most of his remarks.
I’ll add a few user points :
- When ast states that FS multithreading is useless, it reminds me of the many
times I tried to let a job run in the background (like when reading an archive on
a floppy), it is just unusable, the & shell operator could even have been left
out.
- Most interesting utilities are not even compilable under Minix because of the
ATK compiler’s incredible limits. Those were hardly understandable on a basic PC,
but become absurd on a 386. Every stupid DOS compiler has a large model (more
expensive, OK). I hate the 13 bit compress !
- The lack of Virtual Memory support prevents people studying this area to
experiment, and prevents users to use large programs. The strange design of the
MM also makes it hard to modify.

The problem is that even doing exploratory work under minix is painful.
If you want to get any work done (or even fun), even DOS is becoming a better
alternative (with things like DJ GPP).
In its basic form, it is really no more than OS course example, a good
toy, but a toy. Obtaining and applying patches is a pain, and precludes further
upgrades.

Too bad when not so much is missing to make it really good.
Thanks for the work andy, but Linux didn’t deserve your answer.
For the common people, it does many things better than Minix.

Julien Maisonneuve.

This is not a flame, just my experience.

From: richard@aiai.ed.ac.uk (Richard Tobin)
Subject: Re: LINUX is obsolete
Date: 4 Feb 92 14:46:49 GMT
Reply-To: richard@aiai.UUCP (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland

In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>A multithreaded file system is only a performance hack. When there is only
>one job active, the normal case on a small PC, it buys you nothing

I find the single-threaded file system a serious pain when using
Minix. I often want to do something else while reading files from the
(excruciatingly slow) floppy disk. I rather like to play rogue while
waiting for large C or Lisp compilations. I look to look at files in
one editor buffer while compiling in another.

(The problem would be somewhat less if the file system stuck to
serving files and didn’t interact with terminal i/o.)

Of course, in basic Minix with no virtual consoles and no chance of
running emacs, this isn’t much of a problem. But to most people
that’s a failure, not an advantage. It just isn’t the case that on
single-user machines there’s no use for more than one active process;
the idea only has any plausibility because so many people are used to
poor machines with poor operating systems.

As to portability, Minix only wins because of its limited ambitions.
If you wanted a full-featured Unix with paging, job-control, a window
system and so on, would it be quicker to start from basic Minix and
add the features, or to start from Linux and fix the 386-specific
bits? I don’t think it’s fair to criticise Linux when its aims are so
different from Minix’s. If you want a system for pedagogical use,
Minix is the answer. But if what you want is an environment as much
like (say) a Sun as possible on your home computer, it has some
deficiencies.

– Richard

From: ast@cs.vu.nl (Andy Tanenbaum)
Subject: Re: LINUX is obsolete
Date: 5 Feb 92 14:48:48 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

In article <6121@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes:
>If you wanted a full-featured Unix with paging, job-control, a window
>system and so on, would it be quicker to start from basic Minix and
>add the features, or to start from Linux and fix the 386-specific
>bits?

Another option that seems to be totally forgotten here is buy UNIX or a
clone. If you just want to USE the system, instead of hacking on its
internals, you don’t need source code. Coherent is only $99, and there
are various true UNIX systems with more features for more money. For the
true hacker, not having source code is fatal, but for people who just
want a UNIX system, there are many alternatives (albeit not free).

Andy Tanenbaum (ast@cs.vul.nl)

From: ajt@doc.ic.ac.uk (Tony Travis)
Subject: Re: LINUX is obsolete
Date: 6 Feb 92 02:17:13 GMT
Organization: Department of Computing, Imperial College, University of London, UK.

ast@cs.vu.nl (Andy Tanenbaum) writes:
> Another option that seems to be totally forgotten here is buy UNIX or a
> clone. If you just want to USE the system, instead of hacking on its
> internals, you don’t need source code. Coherent is only $99, and there
> are various true UNIX systems with more features for more money. For the
> true hacker, not having source code is fatal, but for people who just
> want a UNIX system, there are many alternatives (albeit not free).

Andy, I have followed the development of Minix since the first messages
were posted to this group and I am now running 1.5.10 with Bruce
Evans’s patches for the 386.

I ‘just’ want a Unix on my PC and I am not interested in hacking on its
internals, but I *do* want the source code!

An important principle underlying the success and popularity of Unix is
the philosophy of building on the work of others.

This philosophy relies upon the availability of the source code in
order that it can be examined, modified and re-used in new software.

Many years ago, I was in the happy position of being an AT&T Seventh
Edition Unix source licencee but, even then, I saw your decision to
make the source of Minix available as liberation from the shackles of
AT&T copyright!!

I think you may sometimes forget that your ‘hobby’ has had a profound
effect on the availability of ‘personal’ Unix (ie. affordable Unix) and
that the 8086 PC I ran Minix 1.2 on actually cost me considerably more
than my present 386/SX clone.

Clearly, Minix _cannot_ be all things to all men, but I see the
progress to 386 versions in much the same way that I see 68000 or other
linear address space architectures: it is a good thing for people like
me who use Minix and feel constrained by the segmented architecture of
the PC version for applications.

NOTHING you can say would convince me that I should use Coherent …

Tony

From: richard@aiai.ed.ac.uk (Richard Tobin)
Subject: Re: LINUX is obsolete
Date: 7 Feb 92 14:58:22 GMT
Organization: AIAI, University of Edinburgh, Scotland

In article <12696@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>If you just want to USE the system, instead of hacking on its
>internals, you don’t need source code.

Unfortunately hacking on the internals is just what many of us want
the system for… You’ll be rid of most of us when BSD-detox or GNU
comes out, which should happen in the next few months (yeah, right).

– Richard

From: comm121@unixg.ubc.ca (Louie)
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 02:55:22 GMT
Organization: University of British Columbia, Vancouver, B.C., Canada

In <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:

>But in all honesty, I would
>suggest that people who want a **MODERN** “free” OS look around for a
>microkernel-based, portable OS, like maybe GNU or something like that.

There are really no other alternatives other than Linux for people like
me who want a “free” OS. Considering that the majority of people who
would use a “free” OS use the 386, portability is really not all that
big of a concern. If I had a Sparc I would use Solaris.

As it stands, I installed Linux with gcc, emacs 18.57, kermit and all of the
GNU utilities without any trouble at all. No need to apply patches. I
just followed the installation instructions. I can’t get an OS like
this *anywhere* for the price to do my Computer Science homework. And
it seems like network support and then X-Windows will be ported to Linux
well before Minix. This is something that would be really useful. In my
opinion, portability of standard Unix software is important also.

I know that the design using a monolithic system is not as good as the
microkernel. But for the short term future (And I know I won’t/can’t
be uprading from my 386), Linux suits me perfectly.

Philip Wu
pwu@unixg.ubc.ca

From: dgraham@bmers30.bnr.ca (Douglas Graham)
Subject: Re: LINUX is obsolete
Date: 1 Feb 92 00:26:30 GMT
Organization: Bell-Northern Research, Ottawa, Canada

In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:

> While I could go into a long story here about the relative merits of the
> two designs, suffice it to say that among the people who actually design
> operating systems, the debate is essentially over. Microkernels have won.

Can you recommend any (unbiased) literature that points out the strengths
and weaknesses of the two approaches? I’m sure that there is something
to be said for the microkernel approach, but I wonder how closely
Minix resembles the other systems that use it. Sure, Minix uses lots
of tasks and messages, but there must be more to a microkernel architecture
than that. I suspect that the Minix code is not split optimally into tasks.

> The only real argument for monolithic systems was performance, and there
> is now enough evidence showing that microkernel systems can be just as
> fast as monolithic systems (e.g., Rick Rashid has published papers comparing
> Mach 3.0 to monolithic systems) that it is now all over but the shoutin`.

My main complaint with Minix is not it’s performance. It is that adding
features is a royal pain — something that I presume a microkernel
architecure is supposed to alleviate.

> MINIX is a microkernel-based system.

Is there a consensus on this?

> LINUX is
> a monolithic style system. This is a giant step back into the 1970s.
> That is like taking an existing, working C program and rewriting it in
> BASIC. To me, writing a monolithic system in 1991 is a truly poor idea.

This is a fine assertion, but I’ve yet to see any rationale for it.
Linux is only about 12000 lines of code I think. I don’t see how
splitting that into tasks and blasting messages around would improve it.

>Don’t get me wrong, I am not unhappy with LINUX. It will get all the people
>who want to turn MINIX in BSD UNIX off my back. But in all honesty, I would
>suggest that people who want a **MODERN** “free” OS look around for a
>microkernel-based, portable OS, like maybe GNU or something like that.

Well, there are no other choices that I’m aware of at the moment. But
when GNU OS comes out, I’ll very likely jump ship again. I sense that
you *are* somewhat unhappy about Linux (and that surprises me somewhat).
I would guess that the reason so many people embraced it, is because it
offers more features. Your approach to people requesting features in
Minix, has generally been to tell them that they didn’t really want that
feature anyway. I submit that the exodus in the direction of Linux
proves you wrong.

Disclaimer: I had nothing to do with Linux development. I just find
it an easier system to understand than Minix.

Doug Graham dgraham@bnr.ca My opinions are my own.

From: hedrick@klinzhai.rutgers.edu (Charles Hedrick)
Subject: Re: LINUX is obsolete
Date: 1 Feb 92 00:27:04 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

The history of software shows that availability wins out over
technical quality every time. That’s Linux’ major advantage. It’s a
small 386-based system that’s fairly compatible with generic Unix, and
is freely available. I dropped out of the Minix community a couple of
years ago when it became clear that (1) Minix was not going to take
advantage of anything beyond the 8086 anytime in the near future, and
(2) the licensing — while amazingly friendly — still made it hard
for people who were interested in producing a 386 version. Several
people apparently did nice work for the 386. But all they could
distribute were diffs. This made bringing up a 386 system a job that
isn’t practical for a new user, and in fact I wasn’t sure I wanted to
do it.

I apologize if things have changed in the last couple of years. If
it’s now possible to get a 386 version in a form that’s ready to run,
the community has developed a way to share Minix source, and bringing
up normal Unix programs has become easier in the interim, then I’m
willing to reconsider Minix. I do like its design.

It’s possible that Linux will be overtaken by Gnu or a free BSD.
However, if the Gnu OS follows the example of all other Gnu software,
it will require a system with 128MB of memory and a 1GB disk to use.
There will still be room for a small system. My ideal OS would be 4.4
BSD. But 4.4′s release date has a history of extreme slippage. With
most of their staff moving to BSDI, it’s hard to believe that this
situation is going to be improved. For my own personal use, the BSDI
system will probably be great. But even their very attractive pricing
is likely to be too much for most of our students, and even though
users can get source from them, the fact that some of it is
proprietary will again mean that you can’t just put altered code out
for public FTP. At any rate, Linux exists, and the rest of these
alternatives are vapor.

From: tytso@athena.mit.edu (Theodore Y. Ts’o)
Subject: Re: LINUX is obsolete
Date: 31 Jan 92 21:40:23 GMT
Organization: Massachusetts Institute of Technology

In-Reply-To: ast@cs.vu.nl’s message of 29 Jan 92 12: 12:50 GMT

>From: ast@cs.vu.nl (Andy Tanenbaum)

>ftp.cs.vu.nl = 192.31.231.42 in dir minix/simulator.) I think it is a
>gross error to design an OS for any specific architecture, since that is
>not going to be around all that long.

It’s not your fault for believing that Linux is tied to the 80386
architecture, since many Linux supporters (including Linus himself) have
made the this statement. However, the amount of 80386-specific code is
probably not much more than what is in a Minix implementation, and there
is certainly a lot less 80386 specific code in Linux than here is
Vax-specific code in BSD 4.3.

Granted, the port to other architectures hasn’t been done yet. But if I
were going to bring up a Unix-like system on a new architecture, I’d
probably start with Linux rather than Minix, simply because I want to
have some control over what I can do with the resulting system when I’m
done with it. Yes, I’d have to rewrite large portions of the VM and
device driver layers — but I’d have to do that with any other OS.
Maybe it would be a little bit harder than it would to port Minix to the
new architecture; but this would probably be only true for the first
architecture that we ported Linux to.

>While I could go into a long story here about the relative merits of the
>two designs, suffice it to say that among the people who actually design
>operating systems, the debate is essentially over. Microkernels have won.
>The only real argument for monolithic systems was performance, and there
>is now enough evidence showing that microkernel systems can be just as
>fast as monolithic systems (e.g., Rick Rashid has published papers comparing
>Mach 3.0 to monolithic systems) that it is now all over but the shoutin’.

This is not necessarily the case; I think you’re painting a much more
black and white view of the universe than necessarily exists. I refer
you to such papers as Brent Welsh’s (welch@parc.xerox.com) “The
Filsystem Belongs in the Kernel” paper, where in he argues that the
filesystem is a mature enough abstraction that it should live in the
kernel, not outside of it as it would in a strict microkernel design.

There also several people who have been concerned about the speed of
OSF/1 Mach when compared with monolithic systems; in particular, the
nubmer of context switches required to handle network traffic, and
networked filesystems in particular.

I am aware of the benefits of a micro kernel approach. However, the
fact remains that Linux is here, and GNU isn’t — and people have been
working on Hurd for a lot longer than Linus has been working on Linux.
Minix doesn’t count because it’s not free. :-)

I suspect that the balance of micro kernels versus monolithic kernels
depend on what you’re doing. If you’re interested in doing research, it
is obviously much easier to rip out and replace modules in a micro
kernel, and since only researchers write papers about operating systems,
ipso facto micro kernels must be the right approach. However, I do know
a lot of people who are not researchers, but who are rather practical
kernel programmers, who have a lot of concerns over the cost of copying
and the cost of context switches which are incurred in a micro kernel.

By the way, I don’t buy your arguments that you don’t need a
multi-threaded filesystem on a single user system. Once you bring up a
windowing system, and have a compile going in one window, a news reader
in another window, and UUCP/C News going in the background, you want
good filesystem performance, even on a single-user system. Maybe to a
theorist it’s an unnecessary optimization and a (to use your words)
“performance hack”, but I’m interested in a Real operating system —
not a research toy.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Theodore Ts’o bloom-beacon!mit-athena!tytso
308 High St., Medford, MA 02155 tytso@athena.mit.edu
Everybody’s playing the game, but nobody’s rules are the same!

From: joe@jshark.rn.com
Subject: Re: LINUX is obsolete
Date: 31 Jan 92 13:21:44 GMT
Organization: a blip of entropy

In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>
> MINIX was designed to be reasonably portable, and has been ported from the
> Intel line to the 680×0 (Atari, Amiga, Macintosh), SPARC, and NS32016.
> LINUX is tied fairly closely to the 80×86. Not the way to go.

If you looked at the source instead of believing the author, you’d realise
this is not true!

He’s replaced ‘fubyte’ by a routine which explicitly uses a segment register
- but that could be easily changed. Similarly, apart from a couple of places
which assume the ’386 MMU, a couple of macros to hide the exact page sizes
etc would make porting trivial. Using ’386 TSS’s makes the code simpler,
but the VAX and WE32000 have similar structures.

As he’s already admitted, a bit of planning would have the the system
neater, but merely putting ’386 assembler around isn’t a crime!

And with all due respect:
- the Book didn’t make an issue of portability (apart from a few
“#ifdef M8088″s)
- by the time it was released, Minix had come to depend on several
8086 “features” that caused uproar from the 68000 users.

>Andy Tanenbaum (ast@cs.vu.nl)

joe.

From: entropy@wintermute.WPI.EDU (Lawrence C. Foard)
Subject: Re: LINUX is obsolete
Date: 5 Feb 92 14:56:30 GMT
Organization: Worcester Polytechnic Institute

In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>Don`t get me wrong, I am not unhappy with LINUX. It will get all the people
>who want to turn MINIX in BSD UNIX off my back. But in all honesty, I would
>suggest that people who want a **MODERN** “free” OS look around for a
>microkernel-based, portable OS, like maybe GNU or something like that.

I believe you have some valid points, although I am not sure that a
microkernel is necessarily better. It might make more sense to allow some
combination of the two. As part of the IPC code I’m writting for Linux I am
going to include code that will allow device drivers and file systems to run
as user processes. These will be significantly slower though, and I believe it
would be a mistake to move everything outside the kernel (TCP/IP will be
internal).

Actually my main problem with OS theorists is that they have never tested
there ideas! None of these ideas (with a partial exception for MACH) has ever
seen the light of day. 32 bit home computers have been available for almost a
decade and Linus was the first person to ever write a working OS for them
that can be used without paying AT&T $100,000. A piece of software in hand is
worth ten pieces of vaporware, OS theorists are quick to jump all over an OS
but they are unwilling to ever provide an alternative.

The general consensus that Micro kernels is the way to go means nothing when
a real application has never even run on one.

The release of Linux is allowing me to try some ideas I’ve been wanting to
experment with for years, but I have never had the opportunity to work with
source code for a functioning OS.

From: ast@cs.vu.nl (Andy Tanenbaum)
Subject: Re: LINUX is obsolete
Date: 5 Feb 92 23:33:23 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

In article <1992Feb5.145630.759@wpi.WPI.EDU> entropy@wintermute.WPI.EDU (Lawrence
C. Foard) writes:
>Actually my main problem with OS theorists is that they have never tested
>there ideas!
I’m mortally insulted. I AM NOT A THEORIST. Ask anybody who was at our
department meeting yesterday (in joke).

Actually, these ideas have been very well tested in practice. OSF is betting
its whole business on a microkernel (Mach 3.0). USL is betting its business
on another one (Chorus). Both of these run lots of software, and both have
been extensively compared to monolithic systems. Amoeba has been fully
implemented and tested for a number of applications. QNX is a microkernel
based system, and someone just told me the installed base is 200,000 systems.
Microkernels are not a pipe dream. They represent proven technology.

The Mach guys wrote a paper called “UNIX as an application program.”
It was by Golub et al., in the Summer 1990 USENIX conference. The Chorus
people also have a technical report on microkernel performance, and I
coauthored another paper on the subject, which I mentioned yesterday
(Dec. 1991 Computing Systems). Check them out.

Andy Tanenbaum (ast@cs.vu.nl)

From: peter@ferranti.com (peter da silva)
Subject: Re: LINUX is obsolete
Organization: Xenix Support, FICC
Date: Thu, 6 Feb 1992 16:02:47 GMT

In article <12747@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
> QNX is a microkernel
> based system, and someone just told me the installed base is 200,000 systems.

Oh yes, while I’m on the subject… there are over 3 million Amigas out there,
which means that there are more of them than any UNIX vendor has shipped, and
probably more than all UNIX systems combined.

From: peter@ferranti.com (peter da silva)
Subject: Re: LINUX is obsolete
Organization: Xenix Support, FICC
Date: Thu, 6 Feb 1992 16:00:22 GMT

In article <1992Feb5.145630.759@wpi.WPI.EDU> entropy@wintermute.WPI.EDU (Lawrence
C. Foard) writes:
> Actually my main problem with OS theorists is that they have never tested
> there ideas!

I beg to differ… there are many microkernel operating systems out there
for everything from an 8088 (QNX) up to large research systems.

> None of these ideas (with a partial exception for MACH) has ever
> seen the light of day. 32 bit home computers have been available for almost a
> decade and Linus was the first person to ever write a working OS for them
> that can be used without paying AT&T $100,000.

I must have been imagining AmigaOS, then. I’ve been using a figment of my
imagination for the past 6 years.

AmigaOS is a microkernel message-passing design, with better response time
and performance than any other readily available PC operating system: including
MINIX, OS/2, Windows, MacOS, Linux, UNIX, and *certainly* MS-DOS.

The microkernel design has proven invaluable. Things like new file systems
that are normally available only from the vendor are hobbyist products on
the Amiga. Device drivers are simply shared libraries and tasks with specific
entry points and message ports. So are file systems, the window system, and
so on. It’s a WONDERFUL design, and validates everything that people have
been saying about microkernels. Yes, it takes more work to get them off the
ground than a coroutine based macrokernel like UNIX, but the versatility
pays you back many times over.

I really wish Andy would do a new MINIX based on what has been learned since
the first release. The factoring of responsibilities in MINIX is fairly poor,
but the basic concept is good.

> The general consensus that Micro kernels is the way to go means nothing when
> a real application has never even run on one.

I’m dreaming again. I sure throught Deluxe Paint, Sculpt 3d, Photon Paint,
Manx C, Manx SDB, Perfect Sound, Videoscape 3d, and the other programs I
bought for my Amiga were “real”. I’ll have to send the damn things back now,
I guess.

The availability of Linux is great. I’m delighted it exists. I’m sure that
the macrokernel design is one reason it has been implemented so fast, and this
is a valid reason to use macrokernels. BUT… this doesn’t mean that
microkernels are inherently slow, or simply research toys.

From: dsmythe@netcom.COM (Dave Smythe)
Subject: Re: LINUX is obsolete
Date: 10 Feb 92 07:08:22 GMT
Organization: Netcom – Online Communication Services (408 241-9760 guest)

In article <1992Feb5.145630.759@wpi.WPI.EDU> entropy@wintermute.WPI.EDU (Lawrence
C. Foard) writes:
>Actually my main problem with OS theorists is that they have never tested
>there ideas! None of these ideas (with a partial exception for MACH) has ever
>seen the light of day.

David Cheriton (Prof. at Stanford, and author of the V system) said something
similar to this in a class in distributed systems. Paraphrased:

“There are two kinds of researchers: those that have implemented
something and those that have not. The latter will tell you that
there are 142 ways of doing things and that there isn’t consensus
on which is best. The former will simply tell you that 141 of
them don’t work.”

He really rips on the OSI-philes as well, for a similar reason. The Internet
protocols are adapted only after having been in use for a period of time,
preventing things from getting standardized that will never be implementable
in a reasonable fashion. OSI adherents, on the other hand, seem intent on
standardizing everything possible, including “escapes” from the standard,
before a reasonable reference implementation exists. Consequently, you see
obsolete ideas immortalized, such as sub-byte-level data field packing,
which makes good performance difficult when your computer is drinking from
a 10+ Gbs fire-hose :-) .

Just my $.02

D

From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Apologies (was Re: LINUX is obsolete)
Date: 30 Jan 92 15:38:16 GMT
Organization: University of Helsinki

In article <1992Jan29.231426.20469@klaava.Helsinki.FI> I wrote:
>Well, with a subject like this, I’m afraid I’ll have to reply.

And reply I did, with complete abandon, and no thought for good taste
and netiquette. Apologies to ast, and thanks to John Nall for a friendy
“that’s not how it’s done”-letter. I over-reacted, and am now composing
a (much less acerbic) personal letter to ast. Hope nobody was turned
away from linux due to it being (a) possibly obsolete (I still think
that’s not the case, although some of the criticisms are valid) and (b)
written by a hothead :-)

Linus “my first, and hopefully last flamefest” Torvalds

From: pmacdona@sanjuan (Peter MacDonald)
Subject: re: Linux is obsolete
Date: 1 Feb 92 02:10:06 GMT
Organization: University of Victoria, Victoria, BC, CANADA

Since I think I posted one of the earliest messages in all this discussion
of Minix vs Linux, I feel compelled to comment on my reasons for
switching from Minix to Linux. In order of importance they are:

1) Linux is free
2) Linux is evolving at a satisfactory clip (because new features
are accepted into the distribution by Linus).

The first requires some explanation, because if I have already purchased
Minix, what posssible concern could price have for me? Simple.
If the OS is free, many more people will use/support/enhance it.
This is also the same reasoning I used when I bought my 386 instead
of a sparc (which I could have got for just 30% more). Since
PCs are cheap and generally available, more people will buy/use
them and thus good, cheap/free software will be abundant.

The second should be pretty obvious to anyone who has been using Minix
for for any period of time. AST generally does not accept enhancements
to Minix. This is not meant as a challenge, but merely a statement of
fact. AST has good and legitimate reasons for this, and I do not dispute
them. But Minix has some limitations which I just could no longer
live with, and due to this policy, the prospect of seeing them resolved
in reasonable time was unsatisfactory. These limitations include:

no 386 support
no virtual consoles
no soft links
no select call
no ptys
no demand paging/swapping/shared-text/shared-libs… (efficient mm)
chmem (inflexible mm)
no X-Windows (advocated for the same reasons as Linux and the 386).
no TCP/IP
no GNU/SysV integration (portability)

Some of these could be fixed by patches (and if you have done this
yourself, I don’t have to tell you how satisfactory that is), but at
least the last 5 items were/are beyond any reasonable expectation.

Finally, my comment (crack?) about Minix’s segmented kernel, or
micro-kernel architecture was more an expression of my frustration/
bewilderment at attempting to use the Minix PTY patches as a guide
of how to do it under Linux. That particular instance was one where
message passing greatly complicated the implementation of a feature.

I do have an opinion about Monlithic vs Message Passing, but won’t
express it now, and did not mean to expresss it then. My goals are
totally short term (maximum functionality in the minimum amount of
time/cost/hassle), and so my views on this are irrelevant, and should
not be misconstrued. If you are non-plussed by the lack of the above
features, then you should consider Minix, as long as you don’t mind
paying of course :)

From: olaf@oski.toppoint.de (Olaf Schlueter)
Subject: Re: Linux is obsolete
Date: 7 Feb 92 11:41:44 GMT
Organization: Toppoint Mailbox e.V.

Just a few comments to the discussion of Linux vs Minix, which evolved
partly to a discussion of monolithic vs micro-kernel.

I think there will be no aggreement between the two parties advocating
either concept, if they forget, that Linux and Minix have been designed
for different applications. If you want a cheap, powerful and
enhancable Unix system running on a single machine, with the possibility
to adapt standard Unix software without pain, then Linux is for you. If
you are interested in modern operating system concepts, and want to
learn how a microkernel based system works, then Minix is the better
choice.

It is not an argument against microkernel system, that for the time
being monolithic implemenations of Unix on PCs have a better
performance. This means only, that Unix is maybe better implemented as
a monolithic OS, at least as long as it runs on a single machine. From
the users point of view, the internal design of the OS doesn’t matter at
all. Until it comes to networks. On the monolithic approach, a file
server will become a user process based on some hardware facility like
ethernet. Programs which want to use this facility will have to use
special libraries which offer the calls for communication with this
server. In a microkernel system it is possible to incorporate the
server into the OS without the need for new “system” calls. From the
users point of view this has the advantage, that nothing changes, he
just gets better performance (in terms of more disk space for example).
From the implementors point of view, the microkernel system is faster
adaptable to changes in hardware design.

It has been critized, that AST rejects any improvements to Minix. As he
is interested in the educational value of Minix, I understand his
argument, that he wants to keep the code simple, and don’t want to
overload it with features. As an educational tool, Minix is written as
a microkernel system, although it is running on hardware platforms, who
will probably better perform with a monolithic OS. But the area of
network applications is growing and modern OS like Amoeba or Plan 9
cannot be written as monolithic systems. So Minix has been written with
the intention to give students a practical example of a microkernel OS,
to let them play with tasks and messages. It was not the idea to give a
lot of people a cheap, powerful OS for a tenth of the price of SYSV or
BSD implementations.

Resumee: Linux is not better than Minix, or the other way round. They
are different for good reasons.

From: meggin@epas.utoronto.ca (David Megginson)
Subject: Mach/Minix/Linux/Gnu etc.
Date: 1 Feb 92 17:11:03 GMT
Organization: University of Toronto – EPAS

Well, this has been a fun discussion. I am absolutely convinced by
Prof. Tanenbaum that a micro-kernel _is_ the way to go, but the more
I look at the Minix source, the less I believe that it is a
micro-kernel. I would probably not bother porting Linux to the
M68000, but I want more services than Minix can offer.

What about a micro-kernel which is message/syscall compatible with
MACH? It doesn’t actually have to do everything that MACH does, like
virtual memory paging — it just has to _look_ like MACH from the
outside, to fool programs like the future Gnu Unix-emulator, BSD, etc.
This would extend the useful lives of our M68000- or 80286-based
machines for a little longer. In the meantime, I will probably stay
with Minix for my ST rather than switching back to MiNT — after all,
Minix at least looks like Unix, while MiNT looks like TOS trying to
look like Unix (it has to, to be TOS compatible).

David

From: peter@ferranti.com (peter da silva)
Newsgroups: comp.os.minix
Subject: What good does this war do? (Re: LINUX is obsolete)
Date: 3 Feb 92 16:37:24 GMT
Organization: Xenix Support, FICC

Will you quit flaming each other?

I mean, linux is designed to provide a reasonably high performance environment
on a hardware platform crippled by years of backwards-compatible kludges. Minix
is designed as a teaching tool. Neither is that good at doing the other’s job,
and why should they? The fact that Minix runs out of steam quickly (and it
does) isn’t a problem in its chosen mileau. It’s sure better than the TOY
operating system. The fact that Linux isn’t transportable beyond the 386/AT
platform isn’t a problem when there are millions of them out there (and quite
cheap: you can get a 386/SX for well under $1000).

A monolithic kernel is easy enough to build that it’s worth doing it if it gets
a system out the door early. Think of it as a performance hack for programmer
time. The API is portable. You can replace the kernel with a microkernel
design (and MINIX isn’t the be-all and end-all of microkernel designs either:
even for low end PCs… look at AmigaOS) without disturbing the applications.
That’s the whole point of a portable API in the first place.

Microkernels are definitely a better design for many tasks. I takes more
work to make them efficient, so a simpler design that doesn’t take advantage
of the microkernel in any real way is worth doing for pedagogical reasons.
Think of it as a performance hack for student time. The design is still good
and when you can get an API to the microkernel interface you can get VERY
impressive performance (thousands of context switches per second on an 8
MHz 68000).

From: ast@cs.vu.nl (Andy Tanenbaum)
Subject: Unhappy campers
Date: 3 Feb 92 22:46:40 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

I’ve been getting a bit of mail lately from unhappy campers. (Actually 10
messages from the 43,000 readers may seem like a lot, but it is not really.)
There seem to be three sticking points:

1. Monolithic kernels are just as good as microkernels
2. Portability isn’t so important
3. Software ought to be free

If people want to have a serious discussion of microkernels vs. monolithic
kernels, fine. We can do that in comp.os.research. But please don’t sound off
if you have no idea of what you are talking about. I have helped design
and implement 3 operating systems, one monolithic and two micro, and have
studied many others in detail. Many of the arguments offered are nonstarters
(e.g., microkernels are no good because you can’t do paging in user space–
except that Mach DOES do paging in user space).

If you don’t know much about microkernels vs. monolithic kernels, there is
some useful information in a paper I coauthored with Fred Douglis, Frans
Kaashoek and John Ousterhout in the Dec. 1991 issue of COMPUTING SYSTEMS, the
USENIX journal). If you don’t have that journal, you can FTP the paper from
ftp.cs.vu.nl (192.31.231.42) in directory amoeba/papers as comp_sys.tex.Z
(compressed TeX source) or comp_sys.ps.Z (compressed PostScript). The paper
gives actual performance measurements and supports Rick Rashid’s conclusion that
microkernel based systems are just as efficient as monolithic kernels.

As to portability, there is hardly any serious discussion possible any more.
UNIX has been ported to everything from PCs to Crays. Writing a portable
OS is not much harder than a nonportable one, and all systems should be
written with portability in mind these days. Surely Linus’ OS professor
pointed this out. Making OS code portable is not something I invented in 1987.

While most people can talk rationally about kernel design and portability,
the issue of free-ness is 100% emotional. You wouldn’t believe how much
[expletive deleted] I have gotten lately about MINIX not being free. MINIX
costs $169, but the license allows making two backup copies, so the effective
price can be under $60. Furthermore, professors may make UNLIMITED copies
for their students. Coherent is $99. FSF charges >$100 for the tape its “free”
software comes on if you don’t have Internet access, and I have never heard
anyone complain. 4.4 BSD is $800. I don’t really believe money is the issue.
Besides, probably most of the people reading this group already have it.

A point which I don’t think everyone appreciates is that making something
available by FTP is not necessarily the way to provide the widest distribution.
The Internet is still a highly elite group. Most computer users are NOT on it.
It is my understanding from PH that the country where MINIX is most widely used
is Germany, not the U.S., mostly because one of the (commercial) German
computer magazines has been actively pushing it. MINIX is also widely used in
Eastern Europe, Japan, Israel, South America, etc. Most of these people would
never have gotten it if there hadn’t been a company selling it.

Getting back to what “free” means, what about free source code? Coherent
is binary only, but MINIX has source code, just as LINUX does. You can change
it any way you want, and post the changes here. People have been doing that
for 5 years without problems. I have been giving free updates for years, too.

I think the real issue is something else. I’ve been repeatedly offered virtual
memory, paging, symbolic links, window systems, and all manner of features. I
have usually declined because I am still trying to keep the system simple
enough for students to understand. You can put all this stuff in your version,
but I won’t put it in mine. I think it is this point which irks the people who
say “MINIX is not free,” not the $60.

An interesting question is whether Linus is willing to let LINUX become “free”
of his control. May people modify it (ruin it?) and sell it? Remember the
hundreds of messages with subject “Re: Your software sold for money” when it
was discovered the MINIX Centre in England was selling diskettes with news
postings, more or less at cost?

Suppose Fred van Kempen returns from the dead and wants to take over, creating
Fred’s LINUX and Linus’ LINUX, both useful but different. Is that ok? The
test comes when a sizable group of people want to evolve LINUX in a way Linus
does not want. Until that actually happens the point is moot, however.

If you like Linus’ philosophy rather than mine, by all means, follow him, but
please don’t claim that you’re doing this because LINUX is “free.” Just
say that you want a system with lots of bells and whistles. Fine. Your choice.
I have no argument with that. Just tell the truth.

As an aside, for those folks who don’t read news headers, Linus is in Finland
and I am in The Netherlands. Are we reaching a situation where another
critical industry, free software, that had been totally dominated by the U.S.
is being taken over by the foreign competition? Will we soon see
President Bush coming to Europe with Richard Stallman and Rick Rashid
in tow, demanding that Europe import more American free software?

Andy Tanenbaum (ast@cs.vu.nl)

From: ast@cs.vu.nl (Andy Tanenbaum)
Subject: Re: Unhappy campers
Date: 5 Feb 92 23:23:26 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

In article <205@fishpond.uucp> fnf@fishpond.uucp (Fred Fish) writes:
>If PH was not granted a monopoly on distribution, it would have been possible
>for all of the interested minix hackers to organize and set up a group that
>was dedicated to producing enhanced-minix. This aim of this group could have
>been to produce a single, supported version of minix with all of the commonly
>requested enhancements. This would have allowed minix to evolve in much the
>same way that gcc has evolved over the last few years.
This IS possible. If a group of people wants to do this, that is fine.
I think co-ordinating 1000 prima donnas living all over the world will be
as easy as herding cats, but there is no legal problem. When a new release
is ready, just make a diff listing against 1.5 and post it or make it FTPable.
While this will require some work on the part of the users to install it,
it isn’t that much work. Besides, I have shell scripts to make the diffs
and install them. This is what Fred van Kempen was doing. What he did wrong
was insist on the right to publish the new version, rather than diffs against
the PH baseline. That cuts PH out of the loop, which, not surprisingly, they
weren’t wild about. If people still want to do this, go ahead.

Of course, I am not necessarily going to put any of these changes in my version,
so there is some work keeping the official and enhanced ones in sync, but I
am willing to co-operate to minimize work. I did this for a long time with
Bruce Evans and Frans Meulenbroeks.

If Linus wants to keep control of the official version, and a group of eager
beavers want to go off in a different direction, the same problem arises.
I don’t think the copyright issue is really the problem. The problem is
co-ordinating things. Projects like GNU, MINIX, or LINUX only hold together
if one person is in charge. During the 1970s, when structured programming
was introduced, Harlan Mills pointed out that the programming team should
be organized like a surgical team–one surgeon and his or her assistants,
not like a hog butchering team–give everybody an axe and let them chop away.

Anyone who says you can have a lot of widely dispersed people hack away on
a complicated piece of code and avoid total anarchy has never managed a
software project.

>Where is the sizeable group of people that want to evolve gcc in a way that
>rms/FSF does not approve of?
A compiler is not something people have much emotional attachment to. If
the language to be compiled is a given (e.g., an ANSI standard), there isn’t
much room for people to invent new features. An operating system has unlimited
opportunity for people to implement their own favorite features.

Andy Tanenbaum (ast@cs.vu.nl)

From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Re: Unhappy campers
Date: 6 Feb 92 10:33:31 GMT
Organization: University of Helsinki

In article <12746@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>
>If Linus wants to keep control of the official version, and a group of eager
>beavers want to go off in a different direction, the same problem arises.

This is the second time I’ve seen this “accusation” from ast, who feels
pretty good about commenting on a kernel he probably haven’t even seen.
Or at least he hasn’t asked me, or even read alt.os.linux about this.
Just so that nobody takes his guess for the full thruth, here’s my
standing on “keeping control”, in 2 words (three?):

I won’t.

The only control I’ve effectively been keeping on linux is that I know
it better than anybody else, and I’ve made my changes available to
ftp-sites etc. Those have become effectively official releases, and I
don’t expect this to change for some time: not because I feel I have
some moral right to it, but because I haven’t heard too many complaints,
and it will be a couple of months before I expect to find people who
have the same “feel” for what happens in the kernel. (Well, maybe
people are getting there: tytso certainly made some heavy changes even
to 0.10, and others have hacked it as well)

In fact I have sent out feelers about some “linux-kernel” mailing list
which would make the decisions about releases, as I expect I cannot
fully support all the features that will /have/ to be added: SCSI etc,
that I don’t have the hardware for. The response has been non-existant:
people don’t seem to be that eager to change yet. (well, one person
felt I should ask around for donations so that I could support it – and
if anybody has interesting hardware lying around, I’d be happy to accept
it :)

The only thing the copyright forbids (and I feel this is eminently
reasonable) is that other people start making money off it, and don’t
make source available etc… This may not be a question of logic, but
I’d feel very bad if someone could just sell my work for money, when I
made it available expressly so that people could play around with a
personal project. I think most people see my point.

That aside, if Fred van Kempen wanted to make a super-linux, he’s quite
wellcome. He won’t be able to make much money on it (distribution fee
only), and I don’t think it’s that good an idea to split linux up, but I
wouldn’t want to stop him even if the copyright let me.

>I don’t think the copyright issue is really the problem. The problem is
>co-ordinating things. Projects like GNU, MINIX, or LINUX only hold together
>if one person is in charge.

Yes, coordination is a big problem, and I don’t think linux will move
away from me as “head surgeon” for some time, partly because most people
understand about these problems. But copyright /is/ an issue: if people
feel I do a bad job, they can do it themselves. Likewise with gcc. The
minix copyright, however, means that if someone feels he could make a
better minix, he either has to make patches (which aren’t that great
whatever you say about them) or start off from scratch (and be attacked
because you have other ideals).

Patches aren’t much fun to distribute: I haven’t made cdiffs for a
single version of linux yet (I expect this to change: soon the patches
will be so much smaller than the kernel that making both patches and a
complete version available is a good idea – note that I’d still make the
whole version available too). Patches upon patches are simply
impractical, especially for people that may do changes themselves.

>>Where is the sizeable group of people that want to evolve gcc in a way that
>>rms/FSF does not approve of?
>A compiler is not something people have much emotional attachment to. If
>the language to be compiled is a given (e.g., an ANSI standard), there isn’t
>much room for people to invent new features. An operating system has unlimited
>opportunity for people to implement their own favorite features.

Well, there’s GNU emacs… Don’t tell us people haven’t got emotional
attachment to editors :)

Linus

From: dmiller@acg.uucp (David Miller)
Subject: Linux is Obsolete and follow up postings
Date: 3 Feb 92 01:03:46 GMT
Organization: AppliedComputerGroup

As an observer interested in operating system design, I couldn’t resist this
thread. Please realize that I am not really experienced with minux
or linux: I have been into unix for many years. First, a few observations:

Minix was written to be an educational tool for ASTs’ classes, not a commercial
operating system. It was never a design parameter to have it run freely
available source code for unix systems. I think it was also a statement of
how operating systems should be designed, with a micro kernel and seperate
processes covering as much of the required functionality as possible.

Linux was written mostly as a learning exercise on Linus part – how to
program the 386 family. Designing the ultimate operating system was not
an objective. Providing a usable, free platform that would run all sorts
of widely available free software was a consideration, and one that appears
to have been well met.

Criticism from anyone that either of these systems isn’t what *they* would
like it to be is misplaced. After all, anybody that has a computer that will
run either system is free to do what Linus and Andrew did: write your own!

I, for one, applaud Linus for his considerable effort in developing Linux
and his decision to make it free to everybody. I applaud AST for his
effort to make minix affordable – I have real trouble relating to complaints
that minix isn’t free. If you can afford the time to explore minix, and a
basic computer system, $150 is not much more – and you do get a book to go
with it.

Next, a few questions for the professor:

Is minix supposed to be a “real operating system” or an educational tool ?
As an educational tool it is an excellent work. As a real operating system
it presents some terribly rough edges (why no malloc() ?, just for starters)
My feeling from reading The Book and listening to postings here is that you
wanted a tool to teach your classes, and a lot of others wanted to play with
an affordable operating system. These others have been trying to bolt on
enough features to make it a “real operating system”, with less than
outstanding success.

Why split fundemental os functions, such as memory management, into user
processes? As all good *nix gurus know, the means to success is to
divide and conquer, with the goal being to *simplify* the problem into
managable, well defined components. If splitting basic parts of the
operating system into user space processes complicates the function by
introducing additional mechanisms (message passing, complicated signals),
have we met the objective of simplifying the design and implementation?

I agree that *nix has suffered a bad case of feature-itis – especially
sysVr4. Perhaps the features that people want for either functionality
or compatibility could be offered by run-time loadable modules/libraries
that offer these features. The micro-kernel would still be a base-level
resource manager that also routes function requests to the appropriate
module/library. The modules could be threads or user processes. (I think
- os hackers please correct me :-) )

Just my $.04 worth – please feel free to post or email responses.
I have no formal progressive training in computer science, so I am really
asking these questions in ignorance. I suspect a lot of others on the
net have similar questions in their own minds, but I’ve been wrong before.

– David

From: michael@gandalf.informatik.rwth-aachen.de (Michael Haardt)
Subject: 1.6.17 summary and why I think AST is right.
Date: 6 Feb 92 20:07:25 GMT
Reply-To: u31b3hs@messua.informatik.rwth-aachen.de (Michael Haardt)
Organization: Gandalf – a 386-20 machine

I will first give a summary of what you can expect from MINIX in *near*
future, and then explain why I think AST is right.

Some time ago, I asked for details about the next MINIX release (1.6.17).
I got some response, but only from people running 1.6.16. The following
informations are not official and may be wrong, but they are all I know
at the moment. Correct me if something is wrong:

- The 1.6.17 patches will be relative to 1.5 as shipped by PH.

- The header files are clean.

- The two types of filesystems can be used together.

- The signal handling is rewritten for POSIX. The old bug is removed.

- The ANSI compiler (available from Transmediar, I guess) comes with
compiler binaries and new libraries.

- There don’t seem to be support for the Amoeba network protocol.

- times(2) returns a correct value. termios(2) is implemented, but it’s
more a hack. I don’t know if “implemented” means in the kernel, or the
current emulation.

- There is no documentation about the new filesystem. There is a new fsck
and a new mkfs, don’t know about de.

- With the ANSI compiler, there is better floating point support.

- The scheduler is improved, but not as good as written by Kai-Uwe Bloem.

I asked these things to get facts for the decision if I should upgrade to
MINIX 1.6.17 or to Linux after the examens are over. Well, the decision
is made: I will upgrade to Linux at the end of the month and remove MINIX
from my winchester, when Linux runs all the software I need and which currently
runs under MINIX 1.5 with heavy patches. I guess this may take up to two
months. These are the main reasons for my decision:

- There is no “current” MINIX release, which can be used as basis for
patches and nobody knows, when 1.6.17 will appear.

- The library contains several bugs and from what I have heard, there is
no work done at them. There will not be a new compiler, and the 16 bit
users still have to use buggy ACK.

- 1.6.17 should offer more POSIX, but a complete termios is still missing.

- I doubt that there is still much development for 16 bit users.

I think I will stop maintaining the MINIX software list in a few months.
Anyone out there, who would like to continue it? Until Linux runs
*perfect* on my machine, each update of Origami will still run on 16-bit
MINIX. I will announce when the last of these versions appears.

In my opinion, AST is right in his decision about MINIX. I read the flame
war and can’t resist to say that I like MINIX the way it is, now where
there is Linux. MINIX has some advantages:

- You can start playing with it without a winchester, you can even
compile programs. I did this a few years ago.

- It is so small, you don’t need to know much to get a small system which
runs ok.

- There is the book. Ok, only for version 1.3, but most of it is still valid.

- MINIX is an example of a non-monolithic kernel. Call it a microkernel
or a hack to overcome braindamaged hardware: It demonstrates a concept,
with its pros and cons — a documented concept.

In my eyes, it is a nice system for first steps in UNIX and systems
programming. I learned most of what I know about UNIX with MINIX, in
all areas, from programming in C under UNIX to system administration
(and security holes:) MINIX grew with me: 1.5.xx upgrades, virtual
consoles, mail & news, text processing, crosscompiling etc. Now it is
too small for me. I don’t need a teaching system anymore, I would like
to get a more complicated and featureful UNIX, and there is one: Linux.

Back in the old days, v7 was state of the art. There was MINIX which
offered most of it. In one or two years, POSIX is what you are used to
see. Hopefully, there will be MINIX, offering most of it, with a new
book, for people who want to run a small system to play and experiment with.

Stop flaming, MINIX and Linux are two different systems with different
purposes. One is a teaching tool (and a good one I think), the other is
real UNIX for real hackers.

Michael

From: dingbat@diku.dk (Niels Skov Olsen)
Subject: Re: 1.6.17 summary and why I think AST is right.
Date: 10 Feb 92 17:33:39 GMT
Organization: Department of Computer Science, U of Copenhagen

michael@gandalf.informatik.rwth-aachen.de (Michael Haardt) writes:

>Stop flaming, MINIX and Linux are two different systems with different
>purposes. One is a teaching tool (and a good one I think), the other is
>real UNIX for real hackers.

Hear, hear! And now Linux articles in alt.os.linux (or comp.os.misc
if your site don’t receive alt.*) and Minix articles here.

eoff (end of flame fest :-)

Niels

GitHub 加速计划 / li / linux-dash
10.39 K
1.2 K
下载
A beautiful web dashboard for Linux
最近提交(Master分支:2 个月前 )
186a802e added ecosystem file for PM2 4 年前
5def40a3 Add host customization support for the NodeJS version 4 年前
Logo

旨在为数千万中国开发者提供一个无缝且高效的云端环境,以支持学习、使用和贡献开源项目。

更多推荐