http://root.cern.ch/root/Linus_vs_Tanenbaum.html爭論原文
Linus vs. Tanenbaum 譯文（轉）
前兩天看到徐宥的博客上提到了 “Linus 和 Tanenbaum 吵了一場著名的架”，很好奇，就在 google 上找到了這篇文章。原文鏈接在http://www.dina.dk/~abraham/Linus_vs_Tanenbaum.html 我准備翻譯一下。但它實在是太長了，只能做個長期打算。每周都會翻譯一點的。 (以下是正文)
這是一份 Andy Tanenbaum 和 Linux Benedict Torvalds 關於內核設計，自由軟件和其他討論的摘錄。里面只包含了一些主要的東西。
Linux 過時了
Andy Tanenbaum
From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: LINUX is obsolete Date: 29 Jan 92 12:12:50 GMT Organization: Fac. Wiskunde &h; Informatica, Vrije Universiteit, Amsterdam
我到美國才有幾周，所以我還沒過多評論 LINUX（並不是說我不常到這里），但現在我不妨在這里評論兩句。
你們大多數都知道，MINIX 是我的業余愛好。它是我在晚上寫書寫累了，電視上卻沒有 CNN 來報道戰爭、起義或參議院的時候搗鼓的東西。我的工作是一名教授、研究員，研究的就是操作系統。
因為我的工作領域，我認為我知道一些關於操作系統未來 10 年發展趨勢或着類似的東西。有兩方面特別明顯：
微內核 vs 宏內核系統(Microkernel vs Monolithic System)
大多數老的系統是宏內核系統，即整個系統是一個單一運行在“內核模式”下的 a.out 文件[二進制，lijunsong注]。這個二進制文件包含了進程管理，內存分配，文件系統和其他。比如 UNIX, MS-DOS, VMS, MVS, OS/360, MULTICS 等等都是這種系統。
另一種是基於微內核的系統，大多數這樣的系統是由運行在內核外部的分離的進程構成。進程間的通信靠信息的傳遞。內核的任務就是傳遞信息、終止操作、管理低級程序甚至 I/O 。這種設計的例子是 RC4000, Amoeba, Chorus, Mach, 和還沒有發布的 Windows/NT。
雖然我在這里可以深入歷史，說說這兩種設計相關的特點，但可以說，微內核和宏內核的爭論在那些設計操作系統的人群中已經結束。微內核勝了。宏內核唯一可稱道的地方就是性能，但現在有足夠的證據表明微內核系統也能夠和宏內核系統跑得一樣快（比如，Rick Rashid 發表的對 Mach 3.0 和宏內核系統對比的論文），所以現在除了吼叫之外什么都結束了。
MINIX 是一個基於微內核的系統。文件系統和內存管理是分離的進程，運行於內核之外。I/O 驅動也是分離的進程（它運行在內核中，但這是因為 Intel CPU 的缺陷而不得不如此）。 而 LINUX 是一個宏內核的系統。這真是巨大的跨越，可惜是跨到了 70 年代。這就像把一個正在運行着的 C 程序用 BASIC 重寫了。對我來說，在 1991 年還寫了一個宏內核的系統真是一個愚蠢的選擇。
可移植性
曾經存在過 4004 CPU，然后它發展成 8008，后來它又經過塑形手術變成了 8080，又發展成 8086， 又發展成了 8088，又發展成了 80286，又發展成了 80386，又發展成了 80486，然后繼續，直到了第 N 代。與此同時， RISC 芯片產生了，他們有的跑起來頻率能超過 100 MIPS。能超過 200 MIPS 的出現將會是近幾年的事情。這些事情不會突然消失，而將要發生的，是這些東西會從 80x86 起步繼而逐步發展。它們將會通過模擬 80386 來運行老的 MS-DOS 命令。（我曾經在我自己 IBM PC 上用 C 寫過模擬程序。這個模擬程序你可以通過 FTP 從 ftp.cs.vu.nl = 192.31.231.42 在 minix/simulator 目錄中獲得）我認為為任何一個特定的體系結構設計一個操作系統實在是個錯誤，因為它不會長久。
MINIX 設計得很便捷，已經發展到了 680x0（Atari, Amiga, Macintosh）, SPARC, 和 NS32016。LINUX 被緊緊邦在了 80x86 上面，走不遠的。
不要誤解我，我對 LINUX 沒有惡意。它會得到那些想從 MINIX 轉向 BSD UNIX 的人。但坦誠地說，我建議那些想得到先進又免費（原文是 MODERN "free", lijunsong注 ）操作系統的人，好好找一個基於微內核的，可移植的操作系統，比如像 GNU 。
Andy Tanenbaum (ast@cs.vn.nl)
P.S. 畫外音： Amoeba 有一個 UNIX 仿真器（在使用者的空間里工作），但它離完成尚早。如果有人想在上面工作，請通知我。要運行 Amoeba，你需要幾個 386 CPU，其中一個需要 16M，所有的 CPU 都需要 WD 以太網卡。
----
Linus Benedict Torvalds
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 29 Jan 92 23:14:26 GMT Organization: University of Helsinki
好吧，既然談到了這個話題，我想我不得不作出回應。無論如何，我先在這里對聽夠了 linux 的 minix 用戶道個歉。我本來應該“忽略那些惡心的話”，但……是時候回擊了。
In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) 寫道：
我到美國才有幾周，所以我還沒過多評論 LINUX（我不願說得過多），但現在我不妨在這里評論兩句。
你們大多數都知道，MINIX 是我的業余愛好。它是我在晚上寫書寫累了，電視上卻沒有 CNN 來報道戰爭、起義或參議院的時候搗鼓的東西。我的工作是一名教授、研究員，研究的就是操作系統。
你就用這個來掩飾 minix 有限性？很抱歉，你說得太隨意了：我有比你多的理由，linux 幾乎在所有的領域里面都能戰勝 minix，還沒有提大多數為 minix PC 的優秀代碼都是 Bruce Evans[Bruce Evans 是 minix 操作系統32 位版本的主要編制者，他與 Linux 的創始人Linus Torvalds 是很好的朋友。lijunsong 注] 寫的。
Re 1：你把 minix 看作一個愛好 – 看看那些用 minix 賺錢的，和那些創造 linux 但免費分發的人，然后再說愛好。minix 也免費的話，我的一些抱怨會稍有緩解。Linux 對我才真正是個愛好（嚴格說來是最好的方式）：我沒有因它而賺到錢，並且它不關乎我在學校里學習的事情。我用我自己的時間，在我自己的機器上完成了 linux。
Re 2：你是一名教授和研究員：這恐怕就是 minix 上一些致命缺陷的最好理由。我只能希望（和假設）Amoeba 不會狗屎得和 minix 一樣。
1. 微內核 vs 宏內核系統
的確，linux 是宏內核，並且我承認微內核要更好些。對於一些無需爭論的話題，我勉強同意你說的。從理論的（和審美的）角度，linux 並不嚴謹。如果 GNU 內核去年已經做好，我也就不會如此麻煩地做我的項目：事實是，GNU 內核到現在都沒有做出來。就可用性來說，Linux 打了場勝仗。
MINIX 是一個基於微內核的系統，LINUX 是一個宏內核系統。
如果這是唯一衡量內核“優秀”的尺度，你是對的。但你沒有提到的是，minix 並沒有把微內核的能力發揮出來，並且對於真正的多任務（在內核中的）處理還有問題。如果我做了個在多線程文件系統有問題的 OS，我就不會忙着去批評其他的 OS，而會盡最大努力彌補以前出過的丑。 ［是的，我知道 minix 有很多多線程處理的技巧，但只不過是技巧而已，並且 Bruce Evans 告訴我有很多的版本］
2. 可移植性
“可移植性的存在是為了那些不會編程的人”
–我，此時此刻（傲慢的神態）
事實是 linux 移植性比 minix 好。“怎么可能!”我聽到你在問我。它就是真的 - 但不是 ast[即 Andy Tanenbaum, 這里 Linus 直呼其名了, lijunsong注] 的那個意思： 我根據我了解的(如何來做)做出來的 linux (當時沒有 POSIX 標准放在我面前) 是和標准一致的。把東西導入到 linux 中普遍而言比導入到 minix 中簡單得多。
我同意可移植性是個好東西：但只在有意義的前提下。嘗試着把一個操作系統變得可移植沒有必要：附帶一個輕便的 API 就足夠了。一個操作系統的理念是利用硬件的特點，並且把他們隱藏在一層層的高級調用中。這就是 linux 做的：它比其他的內核利用了更多的 386 特點。當然這也使得內核變得不大有移植性，但它也變得更容易設計。一個值得做的交易！也是一個讓 linux 成為了第一的交易。
我也同意 linux 變得越來越不可移植：我去年一月得到了我的 386， linux 項目教會了我關於它的部分東西。如果它是一個真正的項目的話，更多的東西將會更輕便地完成。但我沒有過分地（為沒有這樣做）找借口：它是一個關於設計的決定，並且去年 4 月當我開始這個項目的時候，我不認為有人會想用它。我那時候很樂意告訴大家我錯了，並且因為我的代碼可以免費得到，即使想要移植它不會太容易，但人們能夠自由地去嘗試。
Linus
PS. 我為我有時說得過於刺耳而抱歉：minix 在你什么也沒有的時候的確很好。如果你有 5-10 個空的 386，Amoeba 可能是個好的選擇，但我明顯沒有。我不容易生氣，但對 linux 我有些過敏 ：）
Andy Tanenbaum
From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 30 Jan 92 13:44:34 GMT Organization: Fac. Wiskunde &h; Informatica, Vrije Universiteit, Amsterdam
Linus Benedict Trovalds 寫道：
你就用這個［作為一名教授］掩飾 minix 的有限性？
MINIX 的有限性不說全部，至少也有部分和我當一名教授有關系：一個很明顯的設計目標就是讓它能在便宜的硬件上跑，讓學生能夠付得起價格。特別是它已經在一台平均頻率 4.77 MHZ 的無硬盤電腦上跑了很多年。你可以在這做任何事情，包括修改和重新編譯系統。需要明顯指出，大概一年以前，有兩個版本，一個是為 PC（360K） 設計的而另一個是 286/386（1.2M） 設計的。PC 版本比 286/386 版本多銷售1-2倍。我手邊沒有數據，但我猜測現在的六千萬台電腦中比起 8088/286/680x0 來說 386/486 占了很小一部分。在學生中它更少了。對於那些花了很多錢，買了一級設備的人來說，做免費軟件是個很可笑的概念。當然，5 年以后會有不同，但 5 年之后每個人都會在他們頻率只有 200 MIPS，64M SPARCstation-5 電腦上使用免費的 GNU 系統。
Re 2：你是一名教授和研究員：這恐怕就是 minix 上一些致命缺陷的最好理由。我只能希望（和假設）Amoeba 不會狗屎得和 minix 一樣。
Amoeba 不是為了在一台沒有硬盤的 8088 機器設計的。
如果這是唯一衡量內核“優秀”的尺度，你是對的。但你沒有提到的是，minix 並沒有把微內核的能力發揮出來，並且對於真正的多任務（在內核中的）處理還有問題。如果我做了個有多線程文件系統問題的 OS，我就不會忙着去批評其他的 OS，而會盡最大努力彌補以前出過的丑。
一個多線程的文件系統只是一個性能上的改造。當只有一個任務在運行的時候 – 一台 PC 上通常的情況 – 它就沒什么作用並且還增加了代碼的復雜性。在那些快得足夠支持多用戶的機器上，你也許會有足夠的緩存區來保證緩存命中率，這種情況下，多線程也沒什么作用。它只是在多個程序在真正做硬盤讀寫的時候才有優勢。是否值得為此把系統做的更復雜就無需爭論了。
我仍然堅持在 1991 年設計了宏內核是個錯誤這樣的觀點。很慶幸你不是我的學生。要不然你這個設計不會得高分的 :-)
事實是 linux 移植性比 minix 好。“怎么可能!”我聽到你在問我。它就是真的 - 但不是 ast 的那個意思： 我根據我了解的(如何來做)做出來的 linux (當時沒有 POSIX 標准放在我面前) 是和標准一致的。
把東西導入到 linux 中普遍而言比導入到 minix 中簡單得多。
這個新聞組中的人都知道，MINIX 是在 POSIX 之后設計的，並且在逐漸 POSIX 化。每個人都同意有“用戶級別標准”是一個很好的主意。另外，恭喜你能夠在沒有 POSIX 標准的情況下寫出一個與 POSIX 一致的系統。我發現即使學習標准之后它仍然是很難的。
我的觀點是，寫一個和專門的硬件，特別是奇怪得像 Intel 產品線那樣的硬件緊密聯合的操作系統，基本上是錯誤的。一個 OS 本身應該能簡單地移植到硬件平台上。當為 IBM 360 設計的 OS/360 在 25 年前用匯編寫好時，它們應該能夠運行。當專為 8086 的 MS-DOS 在 10 年前寫好時，就沒那么成功，IBM 和 Microsoft 現在終於痛苦地意識到了。在 1991 年為 386 寫一個新的 OS 讓你得到學期的第二個 'F'。但如果你在期末考試表現得很好，你仍然可以通過考試。 Prof. Andrew S. Tanenbaum (ast@cs.vu.nl)
----
Linus Benedict Torvalds
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 31 Jan 92 10:33:23 GMT Organization: University of Helsinki
Andy Tanenbaum 寫道：
MINIX 的有限性不說全部，至少也有部分和我當一名教授有關系：一個很明顯的設計目標就是讓它能在便宜的硬件上跑，讓學生能夠付得起價格。
是，它是一個真正技術上的目標，也使我的一些說法變得無可辯解。但同時，你也搬石頭砸了自己的腳：現在你承認一些 minix 的錯誤是有很大的移植性–包括了那些不是為 unix 設計的機器。這個 假定 也導致了 minix 不能方便地擴展來執行分頁機制，甚至是在那些支持它的機器上。是的， minix 是可移植的，但你把它改為“不能用上任何特性”依然是正確的。
一個多線程的文件系統只是一個性能上的改造。
不正確。它是微內核性能上的改造，但它在你寫宏內核時就有的一個特性 – 一方面是微內核工作得不太好（正如我在給 ast 的個人郵件里提到的那樣）。用過時的方法來寫 unix，你就會得到一個多線程的內核：每個程序只做它自己的事情，你不需要做一些像信息隊列那樣討厭的東西來使得它變得高效。
除此之外，有人認為“只是性能上的改造”是重要的：除非你有一個 cray-3，我猜每個人都厭倦了等待電腦做出反應。我知道我用 minix 的時候就是這樣（不可否認，我在 linux 上也是，但它好多了）。
我也同意在 1991 年設計了宏內核是個錯誤這樣的觀點。很慶幸你不是我的學生。要不然你這個設計不會得高分的 :-)
不是你的學生我大概也得不到高分：我和這個學校的一個教 OS 設計的老師有過爭吵（完完全全和 OS 無關的爭吵）。我懷疑我什么時候才學得會 :)
我的觀點是，寫一個和專門的硬件，特別是奇怪得像 Intel 生產線那樣的硬件緊密聯合的操作系統，基本上是錯誤的。
但 我 的觀點是，操作系統 不 該受限於任何進程： UNIX 跑在大多數真實存在的處理器上。的確，這種實現是有特殊硬件的關系，但是有很大的不同。 你把 OS/360 和 MS-DOS 看作不好的設計是因為他們是決定於硬件的，我也同意。但，這和 linux 有個很大的差別： linux API 是可移植的（不是因為我的聰明，而是我借鑒了相當成熟的 OS： unix）
如果你現在為 linux 寫程序，在 21 世紀，你不應該感到吃驚的事情是只需要為 Hurd(GNU 自己的內核，當年就是因為 Hurd 沒有做出來 Linux 內核才發展壯大的, lijunsong 注) 重新編譯它們就可以（在 Hurd 上運行）了。正如同被提過的那樣（不只是我），linux 內核只是一個完整系統中的一小部分：現在運行的 linux 源碼壓縮后大概有 200k – 而一個完整的開發系統源碼壓縮后至少有 10M（並且很容易就變得大得多）。所有的這些源碼都是可移植的，除了這個你如果沒有任何先前知識就需要至少一年時間來重寫（或許，我之前做過）源代碼的小小內核。
實際上， 整個 linux 內核比起在 mach 中依靠386的要小得多：現有的 mach 版本 i386.tar.Z 壓縮后超過了 800kB（nic.funet.fi 上顯示是 823391 字節）。不可否認，mach 要大得多並且有更多的特性，但這也預示了其他的一些東西。
Linus
Linus Benedict Torvalds
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Apologies (was Re: LINUX is obsolete) Date: 30 Jan 92 15:38:16 GMT Organization: University of Helsinki
我曾寫過：
好吧，既然談到了這個話題，我想我不得不作出回應。
我回應了，並且完全拋棄也沒有想到要有良好的網絡禮節。對 ast 致歉，也感謝 John Nall 友好的一句“那不是它運作方式”[因為這里只有些主要的觀點(見文章前面的說明)，所以這里就沒有那些打醬油的人說的話]。我當時有點過激，現在正在給 ast 寫一封私人信（言辭不尖銳的）。希望人們不會因為 linux 過時而轉身離開（我仍然認為不是這么回事兒，雖然那些批評家言辭確鑿）– 一個急性子如是說 :-)
Linus “我第一次，希望也是最后一次回擊” Torvalds
----
之后的部分貌似就是大家激烈辯論的部分，被這篇網頁的制作者給拿出來了。
看這一群 hacker 的激烈辯論，我也會不知不覺沉迷其中。這種感覺和當初看生活大爆炸，卻看到那群物理學的博士在生活中提到薛定諤的貓的感覺有點像……:-)只有這個時候，我才感覺到科學知識和我們的生活聯系得如此緊密。
不愉快的兩派陣營
Andy Tanenbaum
From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: Unhappy campers Date: 3 Feb 92 22:46:40 GMT Organization: Fac. Wiskunde &h; Informatica, Vrije Universiteit, Amsterdam
我最近收到了幾封從不愉快的陣營中發來的信。（實際上在 43,000 個讀者中的 10 封信可能微有點多，但這不真實。）看上去大概有三個堅挺的立場：
- 宏內核和微內核一樣好
- 可移植性不是那么重要
- 軟件應該免費使用
如果你們想要來真正一次微內核和宏內核的討論，沒問題。我們可以在 comp.os.research 上做那個。但如果你不知道你自己在說什么，請閉嘴。我幫助設計和完成過三個操作系統，一個宏內核和兩個微內核，並且對其他也有細致地研究。很多這里叫嚷的是都不是初學者了（e.g. 微內核不好是因為你不能在用戶空間中用 paging – Mach 可以用是個例外）。
如果你不知道更多關於微內核和宏內核的對比，在一篇我和 Fred Douglis, Frans Kaashoek 和 John Ousterhout 在 1991 年 11 月 為 USENIX 雜志的 COMPUTING SYSTEMS 問題合作寫的論文里面有一些有用的信息。如果你沒有那份雜志，你可以從 ftp.cs.vu.nl(192.31.231.42) 上得到。在 amoeba/papers 目錄中的 comp_sys.tex.Z (TeX 壓縮文件) or comp_sys.ps.Z (PostScript 壓縮文件)。這篇論文給出了可行的性能比較尺度，也證明了 Rick Rashid 的結論–微內核系統和宏內核系統的效率是一樣的。
提到可移植性，不可能再有任何嚴肅的討論了。 UNIX 已經移植到了包括 PC 到 Cray 上。寫一個可以移植的 OS 並不比寫一個不可移植的難，並且現在所有的系統應該有意識地被寫成可移植的。當然 Linus 的 OS 教授指出了這一點。OS 代碼的可移植性不是我在 1987 年發明的。
盡管大部分人能理性地討論內核設計於它的可移植性， ---- （待續） 查 as an aside cray-3
Date: 2010-09-19
HTML generated by org-mode 7.4 in emacs 23
Linus vs. Tanenbaum
This is an extract of the discussion between Andy Tanenbaum and Linus Benedict Torvalds about kernel design, free software, and more. Only contributions from the main actors are included. The complete archive is also available, but only in BABYL format. You can use Emacs RMAIL to read it conveniently.
Per Abrahamsen <abraham@dina.kvl.dk>
Linux is obsolete
Andy Tanenbaum
From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: LINUX is obsolete Date: 29 Jan 92 12:12:50 GMT Organization: Fac. Wiskunde &h; Informatica, Vrije Universiteit, Amsterdam
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:
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.
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 80x86 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 680x0 (Atari, Amiga, Macintosh), SPARC, and NS32016. LINUX is tied fairly closely to the 80x86. 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.
Linus Benedict Torvalds
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix 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 :)
Andy Tanenbaum
From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 30 Jan 92 13:44:34 GMT Organization: Fac. Wiskunde &h; Informatica, Vrije Universiteit, Amsterdam
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/680x0 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)
Linus Benedict Torvalds
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix 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
Linus Benedict Torvalds
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix 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
Unhappy campers
Andy Tanenbaum
From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: Unhappy campers Date: 3 Feb 92 22:46:40 GMT Organization: Fac. Wiskunde &h; 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:
- Monolithic kernels are just as good as microkernels
- Portability isn't so important
- 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)
Fred Fish
From: fnf@fishpond.uucp (Fred Fish) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 4 Feb 92 20:57:40 GMT Organization: Amiga Library Distribution Services
In article <12667@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
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.
The distribution cost is not the problem. As you've noted, nobody complains about the FSF's distribution fee being too high. The problem, as I see it, is that there is only one legal source for for the software for people that simply want a working release. And from watching the minix group since minix first became available, my impression is that nobody enjoys dealing with PH for a whole host of reasons.
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.
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. Sure there are variant versions of gcc, but most of the really good enhancements, bug fixes, etc are eventually folded back into a master source base that future distributions derive from. Thus you would have been left in peace to continue your tight control over the educational version of minix, and everyone else that wanted more than an educational tool could put their energies into enhanced-minx.
The primary reason I've never gotten into using minix, after the initial excitement of hearing about it's availability way back when, is that I have no interest in trying to apply random patches from all over the place, sort out the problems, and eventually end up with a system that does what I want it to, but which I can't pass on to anyone else.
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.
Where is the sizeable group of people that want to evolve gcc in a way that rms/FSF does not approve of?
Where is the sizeable group of people that want to evolve emacs in a way that rms/FSF doesn't approve of?
I'd say that if the primary maintainers of a large piece of useful, freely redistributable, software are at all responsive to incorporating useful enhancements and acting as the central repository and clearing house for the software, then these splinter groups simply do not have sufficient motivation to form. Having a single source for the software, and having the primary maintainer(s) be unresponsive to the desires of a large group of users, is the catalyst that causes these sorts of pressures; not the freedom of the software.
-Fred
--
|\/ o\ Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA
|/\__/ 1-602-491-0048 {asuvax,mcdphx,cygint,amix}!fishpond!fnf
Andy Tanenbaum
From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 5 Feb 92 23:23:26 GMT Organization: Fac. Wiskunde &h; 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)
Linus Benedict Torvalds
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix 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