Linux的边界

Linus Torvalds 著

雷红旗 译

洪峰 校

今天，Linux有好几百万用户、数以千计的开发人员和一个正在增长的市场。它已应用到嵌入式系统中，用于控制机器人设备，甚至应用到了航天飞机上。尽管我可说我以前就知道这一切都会发生，这是它主导世界的全部计划的一部分，但说老实话，这一切仍有些出乎我的意料。比起由100个用户增加到100万用户，我对于由最初所发展的100个用户更重视。

Linux所取得的成功，不是因为当初所制定的广泛的可移植性和广泛的有效性目标决定的，而是由于它是建立在一个良好的设计原则和良好的发展模式上。这一坚实的基础使得可移植性和有效性更加容易实现。

与其他有强大的商业背景的公司的产品（如Java或Windows NT）相比，Linux是有区别的。Java令人激动不已的成就使许多人确信“一旦写成，随处运行”是一个有价值的目标。我们正进入一个计算时代，范围越来越广泛的硬件投入应用，所以这的确是具有重要的价值。但是，“一旦写成，随处运行”并不是Sun的发明，可移植性是计算机工业长期梦寐已求的目标。例如，微软公司当初也希望Windows NT成为可移植的操作系统，希望它不但可在Intel机器上运行，而且也可在基于RISC芯片的工作站环境上运行。Linux以前从来没有过这么值得炫耀的初始目标，但具有讽刺意味的是，它的跨平台代码变成了一种非常成功的介质。

Linux起初的目标只是定位在Intel 386一个体系上。今天，Linux可运行于从PalmPilot道Alpha工作站等任何一个体系上。它被广泛地移植到PC机的操作系统上。如果你编写了一个在Linux上运行的程序，那么它就能在相当广泛的机型范围内做到“一旦写成，随处运行”。所以，看一看当初Linux的设计时所作出的决定，Linux发展进程中所做的努力，以及如何管理Linux，使后来出现的版本与当初版本不完全相同，是件有意思的事情。

Amiga和Motorola

Linux是一个“类Unix”操作系统，但它不是Unix的一个版本。这使得Linux具有了与FreeBSD不同的继承性。我的意思是说：FreeBSD的创立者是从Berkeley Unix的源代码起步的，FreeBSD的内核就是那个源代码的直系后代，所以FreeBSD是Unix的一个版本，它是Unix家族的一个成员。另一方面，Linux的目标则是提供一个与Unix兼容的界面，但是它的内核是从头编写的，并没有参考Unix的源代码。所以Linux本身并不是Unix的一个移植版本，它是一个新的操作系统。

将这一新的操作系统移植到其他平台上的确不是我最初的主意。最初我只是想在我的386机器上运行它。

从Linux被移植到DEC的Alpha机器上开始，经过认真的努力，Linux内核代码具备了可移植性。然而，Alpha平台上Linux版本并不是Linux的第一个移植版本。

Linux的第一个移植版本是一个工作小组将Linux内核移植到Motorola 68K系列平台上后实现的。Motorola 68K是早期在Sun、Apple和Amiga的计算机上使用的芯片。将Linux移植到Motorola上的程序员确实想做一些低级别的工作。当时在欧洲，有许多属于Amiga阵营的人，他们尤其对使用DOS或者Windows不感兴趣。

尽管Amiga阵营的人们真的做到了在68K系列上运行Linux系统，但我认为这不是一个成功的Linux移植版本。他们的工作方法与我最初编写Linux时所采取的方法是一致的：都是瞄准某种界面从头编写代码。所以，第一个68K系列的移植版本可以看成是一个“类Linux”的操作系统，它从最初的代码库（codebase）中分离了出去。

从某种角度上看，第一个68K Linux对于创立可移植的Linux是没有帮助的，但从另一角度看，又是有帮助的。当我考虑向Alpha移植Linux时，我就要借鉴68K的经验。如果在向Alpha移植时采用同样的方式，那么在维护Linux时就将要支持三个不同的代码库。这样即使在编码时是可行的，但从管理的角度来看却是不可能的。如果某个人每次想在一个全新的体系上移植Linux时都要我跟踪全套新的代码库的话，那么我就将无法管理Linux的发展。而我想完成的系统，要么是具有Alpha规格的代码树，要么是68K规格的代码树，或者是x86规格的代码树，但它们全都属于一个通用的代码库。

因此，当时对内核进行了重大的改写。而改写的真正原动力，却是为了更好地适应与快速扩大的开发人员群体协同工作。

微内核

当我开始编写Linux内核时，学术界对如何编写可移植系统有一个共识，他们通常认为明智的选择就是必须用微内核样式（microkernel-style）的体系。

在如Linux内核这样的“整体内核”（monolithic kernel）中，内存被分为用户空间和内核空间。内核空间是用以存放内核代码以及内核级别操作的内存。内核操作包括调度、进程管理、信号、设备输入/输出、分页和转换等。这些都是其他程序赖以运行的关键操作。由于内核代码含有与低层硬件的交互作用功能，所以整体内核看起来似乎只能局限于某一特定的体系。

微内核是只在较有限的形式下完成较少操作的一个集合，如进程间通信、有限的进程管理与调度，以及一些低级别的输入/输出等。由于许多系统特性被划分给了用户空间，因此微内核似乎与硬件关系不大。微内核体系基本上只是对进程控制、内存分配、资源分配等细节的一种抽象方式，要将它移入另一类芯片只需做很小的改动。

因此，1991年当我开始编写Linux时，人们都认为只有微内核方法可以解决可移植性。因为它在当时是计算机科学家研究的宠儿。然而，我是个固执、讲求实际的人，当时我对微内核的看法是：

1. 仍处于实验阶段；

2. 比整体内核复杂得多；

3. 运行速度明显地比整体内核慢。

由于运算速度对于现实世界中的操作系统意味着一切，所以，当时许许多多的科研经费都花在了对微内核的最优化检测上，看它是否运行得如同正常内核一样快。令人好笑的是，如果你真正读一读那些论文的话，你就会发现，研究人员应用在微内核上的最优化技巧，事实上可以很容易地应用到传统内核上以加快其运行速度。

实际上，这使我觉得微内核方案就像是一个自欺欺人的方案，目的是获取更多的研究经费。我并不是说这些研究人员诚心要欺骗，也许他们只是愚昧，或者是搞错了。我说的这些都是我的真实感受。这种不诚实来自于当时笼罩在研究领域的强大压力，迫使人们致力于微内核方面的研究。在计算机科学实验室里，你要么在研究微内核，要么就根本不是在研究内核。所以大家都在被迫表现出这种不诚实，甚至包括设计Windows NT的人们。即使NT工作小组的人员知道最终的结果不是采用微内核方案，他们也不得不迎合这一思想。

值得庆幸的是，我没有受到追随微内核的压力。芬兰赫尔辛基大学从60年代末起一直从事操作系统的研究，他们不再把操作系统内核视为一个研究焦点。从某些方面说这是正确的。操作系统的基础，也就是Linux内核的扩展的基础，早在70年代初就已被人们了解得很清楚，这之后的任何事都是某种程度上的自我满足的练习。

如果你想编写出具有可移植性的代码，那么你不必非要能建立一个抽象层才能实现代码的可移植。相反，你只需要编程时聪明一点就可以到达目的。基本上可以这样说，想方设法使微内核可移植是浪费时间。这好比使用方型轮胎来研制一种超高速的汽车。一味地将内核中的一件事单独提取出来，盲目地追求其速度，其相应的效果只能是适得其反。

当然，微内核的研究并不局限于上述努力，但问题的大部分就是目的上的不同。很多微内核研究的目的是针对某个理想化的理论而设计的，以求这种设计能够跨跃任何可能的体系，从而实现可移植性。我并没有想在Linux上实现这么虚幻的目标。我感兴趣的是在现实的系统上实现可移植性，而不是在理论的系统上。

从Alpha到可移植性

Linux向Alpha平台的移植始于1993年，花了大约一年的时间完成。虽然一年后全部工作并未结束，但大体上可以说是已经完成了。虽然这一移植非常困难，但是它为Linux确立了一些从那时起一直在遵循的设计原则，给以后的移植带来了便利。

在编写Linux内核时，我并没有考虑到要将它移植到任何一个体系上。我认为如果一个目标体系在基础上是足够健全的、并且遵守一些基本的原则的话，那么Linux就应基本上能够支持这一模式。例如。不同的机型在内存管理方面存在很大的区别。我阅读了68K、Spare、Alpha以及Power PC的内存管理文件，发现它们尽管在具体的细节上存在着差别，但是在分页、缓冲等方面有许多共同之处。Linux内核的内存管理就可以建立在这些体系的共性之上，随后再对一个特定体系内存管理代码的细节进行修改时，就不再是一件那么困难的事了。

有一些假设简化了许多移植问题。例如，如果你认为CPU必须分页，那么内核必须扩充，以含有某种“翻译查询缓冲”（TLB，translation loopup buffer），来告诉CPU如何将虚拟内存映射给CPU使用。TLB在计算时具体采用何种方式分页你并不需要知道。但实际上，你唯一要知道的是，当你决定让它实际运作时应该如何填充它和如何刷新它。因此在这一健全的体系中，你应该清楚地知道需要在内核中编写部分针对特有机器的代码，但大多数的代码都建立在如同TLB这样的通用机制之上。

我遵循的另一个优秀技巧是，使用编译时间常量总是比使用变量要好。通常按照这一规则，编译器在处理代码最优化时更加出色。这样做显然是明智的，因为这可以使建立的代码的定义更具弹性，但是易于优化。

这一方式的趣味性在于：它是一种试图定义一个健全的通用体系的方案，也就是说，你可以由此为操作系统提出一个更好的体系，而不是真正地去迎合一个实际的硬件平台。这样做似乎是与直觉相反，但非常重要。考察系统并寻找其共性与通过优化来改进内核的性能经常是一样的。

瞧，当你做了大量充分的调查，例如页面表的实现（page table implementation），而且在观察的基础上做出判断后，发现决定页面树只需要三层深度，你接着就会发现如果真的要追求高性能的话，那么你只能照此方案去做。换句话说，假如你一直没有将可移植性当做一个设计目标来考虑，而只是考虑针对某一特定的体系如何使内核最优化的话，那么你很快就会得到相同的结论，即，内核表达页面树的的优化深度就是三层。

这不只是碰上了好运气。当一个体系在一些具体的细节上经常偏离一个健全的总体设计时，就是因为设计本身是糟糕的。同理，当你专心地追求可移植性的同时，也经常使你围绕一个不好的设计特性打转，并花费更多的精力去优化总体设计。基本上，我走的是一条中间道路：将好的理论与今天的计算机体系的现实情形相结合。

内核空间与用户空间

对于像Linux这样的整体内核，在允许新代码和新特征进入内核时要非常谨慎，因为这些东西将对以后关键内核开发工作之外的开发阶段的许多方面产生影响。

第一个非常基本的规则是，要避免出现新的界面。如果有人想增加的内容涉及一个新的系统界面时，更是要格外地当心。一旦给用户们提供一个新的界面，他们就会开始为它编制代码，而一旦有人开始为它编写代码，那你就得忍受它的存在。你想在你的系统今后的生命周期中支持与此完全一样的界面吗？

其他代码没有这么大的问题。只要它不涉反界面（例如一个磁盘驱动程序），那就不必过多担心。你可以尽管放心地增加一个磁盘驱动程序，这类行动并没有什么风险。如果Linux以前没有那个驱动程序，增加一个并不影响其他已经使用Linux的人。这样，Linux对新用户是开放的。

对于其他事情，则需要仔细权衡一下。这是一个好的设计吗？增加一个特性真的好吗？有时尽管特征很好，但是问题是要么界面不好，要么是那个特征的设计暗含着某种限制，使你现在或将来都永远不能做某些别的事情。

例如，让我们看一个涉及界面时的情形，假设某人有一个设计得很愚蠢的文件系统，规定文件名不能多于14个字符。而实际上，你在界面中设置这类限制的真实意图却是要尽量避免使它们成为绊脚石。否则当你想扩展这一文件系统时，就会被捆住手脚，你必须寻求一个解决办法，以适应这个以前设置的较少的界面。更糟糕的是，每一个需要一个文件名的程序时只留下一个13个字符的变量，因此当遇到一个较长的文件名时就会出现冲突。

目前唯一作出这一蠢事的软件商就是Microsoft。起码在阅读DOS或Windows文件时，就会遇到这一荒谬的界面，规定文件名为8+3=11个字符。NT允许使用更长的文件名。因此除非某个例程本身就能处理长文件名，那么你就不得不增加一整套新的例程来做其它例程所做的事。这说明一个不好的界面会妨碍以后的工作。

另外有一个Plan 9操作系统的例子。他们有一个非常漂亮的系统调用来更好地生成进程——用一个简单的办法将程序自身一分为二，然后同时继续处理两个子进程。这一新的fork（分叉）在Plan 9中叫着R-Fork（SGI后来称为S-Proc）。它从根本上创建了两个独立的进程空间，它们共享同一地址空闹。这点对于处理线程特别有利。

Linux在其系统调用克隆中也是这么做的。但设计得很适当。按照SGI和Plan 9的例程，两个分叉的程序使用同一地址空间，但使用相互独立的堆栈。通常情况下，当在两个线程中使用相同的地址，可得到同一内存地址，但堆栈段（stack segment）是不相同的。所以当使用一个基于堆栈的内存地址时，你可以得到两个不同的内存地址，共享同一堆栈指针（stack pointer），不需要占用其他堆栈。

这是一个明智的做法。不利的一面是过高地维持堆栈在实际中是愚蠢的，他们发现这一问题时已经太晚，程序性能一塌糊涂。因为他们编写了程序，但是程序使用的界面他们却修改不了。这样一来，他们不得不引入一个附加的适当编写的界面，以像往常那样明智地利用堆栈空间。

一些专有版权系统经销商有时试图将某个设计缺陷责任归咎于某一体系。在编写Linux时，我们不需要这样的做法。

还有另外一个例子，说明从维护Linux发展的角度出发与从制定Linux的设计决策的角度出发可以推导出一致的方案。从实际的角度出发，我无法应付许多的开发人员将自己的界面提供给内核。这将使我无法保持对内核的控制。但是从设计的角度出发，这也是一个正确的决定：保持内核相对小巧，控制界面的数量和将其它制约将来发展的因素降到最少限度。

当然，在这一方面Linux不是非常干净的。Linux从以前的Unix版本那里继承了一些可怕的界面，所以从某种角度来说，如果没有维持全部的Unix界面我会更加感到快乐。如果不是完全从头开始的，Linux就会像一个普通的系统一样短小精悍。如果你想得到可以运行Unix应用程序的好处，你就要继承一些Unix的包袱。能够运行这些Unix应用程序对于Linux的流行是至关重要的，因此做出一些牺牲也是值得的。

GCC

Unix本身在可移植性方面是一个非常成功的例子。Unix内核与其它内核一样，依赖于C语言的存在，C满足了Unix许多重要可移植性方面的需求。对Linux也是一样的。C编译器对许多体系的广泛的有效性，使得Unix对这些体系的移植成为可能。

所以Unix深谙编译器的重要性。我选择GPL（GNU Public License）做为Linux的许可证的一个原因也是考虑到编译器的重要性。GCC编译器的许可证就是GPL。相比之下，我觉得GNU工程只有GCC是我真正唯一关注的东西，GNU工程的其它东西对于Linux来说意义不大，而且有一些我还很讨厌，例如Emacs编辑器就是极其可怕的。虽然Linux比Emacs还要大，但至少Linux有理由应该如此。

但归根结底，编译器是真正最需要的东西。

现在Linux内核遵循了通常的可移植性的设计原则，至少对于健全的体系是如此。一旦有了一个适当的编译器，可移植性才有可能实现。对于将来出现的各种芯片，我不担心内核的体系可移植性会出现问题。我担心的是编译器。Intel的64位芯片Merced就是一个明显的例子，因为从编译器的角度来看，Merced是非常与众不同的。

所以Linux之所以具有可移植性，在很大程度上是因为GCC编译器已经被移植到了主要的芯片体系上。

内核模块

有了Linux内核后，有一点很快就变得很清楚，我们需要系统尽可能地模块化。开源软件发展模式非常需要模块化，否则你就不能保证所有的人平行地开展工作。如果有许多人都在内核的同一部分工作，但发生了冲突，那将是件痛苦的事。

如果没有模块化，我就需要检查每一个文件的改动。那是非常巨大的工作。但是如果有了模块化后，当有人送来补丁文件以增加新的文件系统时，我不需要检查补丁文件本身就能确定如果别人不使用这一文件系统，不会对系统造成任何影响。

例如，Hans Reiser正在创建一个新的文件系统，他尽管做下去好了。这时进入Linux内核2.2版是没有任何意义的。但是因为有了内核模块，当我需要这样做时就可以做到，而且做起来也不困难。关键是要保证大家相互可以跟着各自的脚印走下去。

随着Linux内核2.0版的出现，Linux确实长大了许多。我们增加了可装载的内核模块。为编写模块，我们制定了明确的模块结构，这显著地改进了模块化。程序开发人员可以在不同的模块上开展工作，而不存在相互干涉的危险。我控制着将什么样的内容写入内核。管理人员和管理代码两者得到了相同的设计结论。保护在Linux上工作的许多人协调地工作，我们需要建立内核模块，而从设计角度来看，也需要这样做。

模块化的其他部分不很重要，但问题却不少，这就是运行时的装载部分。每个人都承认这是件好事，但却引起了新问题。第一个问题是技术性的，但技术性的问题往往是容易得到解决的。更重要的是一些非技术性的问题。例如，从哪方面判断一个模块是从Linux派生出来的，因此要将它置于GPL许可证之下？

当第一个模块界面完成后，就有人已经写成了SCO驱动程序。他们不愿意按照GPL要求公开源代码，但他们同意为Linux提供经重编译的二进制代码。出于道德的原因，我决定在这种情况下不能应用GPL。

GPL要求一个由GPL许可证作品“衍生出来”的作品，也必须置于GPL许可证之下，但不幸的是，对于什么样的作品就是衍生作品却含糊不情。当准备划定一个作品为衍生作品时，问题随即变成“你根据什么来判定？”

我们最后决定（也许是我自己作出了决定）系统调用不能视为与内核相联系。也就是说，任何一个在Linux顶端运行的程序都可以不受GPL的控制。这一决定很早就作出了。我甚至特地写了一个自述文件（见本书附录二），以便所有的人都知道这一点。有了这一点之后，商业性的供货商可以为Linux编写程序而不必担心要受GPL的约束。

对于模块编制人员来说结果是：如果你只是为了装载而使用Linux的正常界面，你就可以编写具有专有版权的模块。然而这仍然是内核的灰色地带。这一灰色地带留有漏洞供大家利用，这也许是因为GPL的确对于像模块界面一类的问题并不很清楚。如果有人滥用GPL的原则，以某种方式使用输出记号只是为了欺骗GPL，那么我觉得因他就应该受到起诉。但我不认为任何人会误用内核。那些对内核表现出商业兴趣的人已经这样做了，因为他们对从这一开发模式中受益感兴趣。

Linux的巨大威力在于，它身后社团的协同工作所显示的力量与代码本身的力量一样大。如果Linux被劫持——也就是说，假如有人企图利用Linux制作并发行一个具有专有版权的版本——这正是Linux的魅力所在，而且是开源软件发展模式的基本特点——那么Linux的魅力将因那个专有版权的版本而丢失殆尽。

可移植性的现状

今天，Linux已经实现了许多设计目标。这些目标是人们原来认为只有靠微内核体系才能实现的。

通过从各种典型的体系中抽象出有共性的元素，Linux建立了一个通用的内核模型，而且Linux内核获得了许多可移植性的利益，而且不需要抽象层，也没有像微内核在性能上付出了沉重的代价。

通过允许建立内核模块，针对硬件特性的代码通常被置于某个模块中，这使得关键内核有很高的可移植性。设备驱动程序就是高效利用内核模块的一个极好的例子。如果将所有的硬件特性都放入关键内核，运行速度虽然加快了，但内核的移植性太差；反之将所有的硬件特性放入用户空间，又会造成或者系统运行速度缓慢，或者系统稳定性差，甚至二者兼有。而内核模块化是一种很好的中间解决方案。

但是，Linux的可移植性解决方案对于围绕Linux进行开发的社团也提供了大量的好处。使Linux具有可移植性的决定，也保证了一个大的社团可以同时地在Linux的某个部分上工作，同时我仍然掌握着对Linux内核的控制权。Linux所基于的体系普遍性，也给了我提供了一个参考框架，来检查内核需要做哪些改变，并提供了充足的抽象，使我不需要对不同的体系的代码分支保持彻头彻尾的维护。所以，即使有一个庞大的群体在Linux上工作，但是关键内核中却总是有一些东西由我来掌握。内核模块为程序设计人员清楚地指明了，在系统的某些部分上独自工作时，究竟哪些部分应该真正是独立的。

Linux的未来

Linux在内核空间上追求小型化，我相信这是我们作出的正确选择。从这一角度上讲，我不想对内核作出重大的升级。一个成功的软件项目在某个时候成熟起来后，改动的步子也应慢下来。内核的存储上不会有重大的革新。主要的问题不是别的，而是如何使其支持的系统更加广泛。如何利用Linux可移植性的优势，并将Linux安装到新的系统之中。

还将会有新的界面出现，但其中一部分界面目的，是为了满足支持范围更加广泛的系统的需要。例如，你正开始做群集计算机时，突然间你又想告诉调度程序调度某些处理器组作为一个团队去执行调度，等等。但同时，我不想让每个人都只集中于群集计算或超级计算。将来更多的是笔记本电脑，或者随处可插可用的磁卡，或者其他类似的东西。因此我希望Linux也能朝这个方向上发展。

还有嵌入式系统，嵌入式系统根本没有用户界面，真的。也许，你刚进入一个系统后，就想更新其内核，而它已经就在那儿了。这正是Linux的另一个方向。我认为Java或者Inferno（Lucent的嵌入式操作系统）在嵌入式设备上不一定能取得成功。他们已经违反了著名的摩尔定律。开始时他们专门为一个特殊的嵌入式设备设计一个最优化的系统看起来不错，而当可操作的设计方案完成时，摩尔定律却使市场上出现了功能更强大而且更通用的硬件设备，因此使原来针对专用设备所做设计的贬值。价格狂跌，买一台新的桌面计算机操作系统的价格与买一个嵌入式设备的价格几乎相同。这将使每个人的生活变得更加轻松。

对称多处理技术（SMP）将是一个有待开发的领域。Linux内核的2.2版将能很好地同时控制4个芯片的运行。它还将发展到控制8到16个芯片。控制4个以上芯片的内核已经在试验，但还没布完全成功。目前如果你有4个以上的芯片，就相当于花钱医治一匹死马，当然这一点一定会得到改进。

但是对于64个芯片，就必须要有一个专门的内核版本了。如果还用常规的内核来控制系统的话，对于一般的用户来说，将会引起性能下降。

一些特殊的应用程序将继续促进内核的发展。Web服务一直是一个有趣的问题，因为它确实是一个与内核密切相关的应用程序。在某些方面，Web服务对我非常危险，因为我经常收到将Linux做为Web服务平台的社团的反馈，我可以很快就完成对Web服务的优化。但是，我得记住Web服务是一个重要的应用，但还不是全部。

当然，即使对于目前的Web服务器来说，Linux也没有发挥其全部的潜能。例如，Apache本身对于线程的处理就不算太好。

这类最优化工作由于受到网络带宽的限制而放慢了。当前我们处在10兆带宽的网络时代，没有理由过于乐观。现在唯一不使10兆带宽网络很容易出现饱和与堵塞的办法是增加越来越多的重型CGI（Common Gateway Interface，通用网关接口），但在这方面内核却帮不上什么忙。内核有潜力所做的是回答静态页面请求，并将复杂得多的请求传递给Apache，一旦更快的网络更加普及时，这将变得非常有吸引力。但目前我们还没有经得起挑剔的大量硬件来测试和开发它。

我希望，从以上这些在未来可能实现的方面，Linux能将其能量发挥到极致，甚至会稍微超越它的极限。因为今天所要跨跃的边界上的东西，可能就是你明天在桌面上就能得到的。

但Linux最令人激动的发展将出现在用户空间上，而不是在内核空间上。与系统上正在发生的变化相比，内核的变化似乎小得多。由此可以预料，Red Hat 17.5或者是Wine（Windows仿真器）几年后将会出现振奋人心的特性。

15年后，我希望有人来到这里并且对我说：“嘿！我能做Linux所能做到的一切，但我做得更加短小精悍，因为我的系统没有20年的历史包袱”。他会说Linux当初是为386设计的，而新的CPU正在以不同的方法做着真正有吸引力的事，他会劝我们扔掉Linux这个旧货。当我初创立Linux时基本上也是这样做的。将来，这些人可以查看我们的代码，使用我们的界面，提供二进制代码的兼容性，如果这一切能成为现实，那我将很欣慰。

作者简介

Linus Torvalds

当然是他创建了Linux。这就像人们说“Engelbart发明了鼠标”一样自然。我敢肯定像下面的电子邮件中所具有的深远含义：

From:torvalds@klaava.Helsinki.FI（LinusBenedictTorvalds）

Newsgroups:comp.os.minix

SUbject:Gcc-1.40 and a posix-question

Message-ID:<1991Jul3.100050.988@klaava.Helsinki.FI>

Date: 3 Jul 91 10:00:50 GMT

Hello net landers,

Due to a project I’m working on（in minix）, I'm interested in the posix standard definition. Could somebody point me to a（preferably）machine-readable format of the latest posix rules? Ftp-sites would be nice.

无人能与他相比。

Linus不曾预见到他的项目会从一个小小的业余爱好会成长为一个拥有从7百万激增到1千万追随者的主流操作系统，而且还成为世界上最大的软件公司的一个主要竞争者。

因为Linux被大众所使用，其势头如火如荼一般席卷了整个Internet——26%的Internet服务器上运行着Linux（而最接近的竞争者是Microsoft，其占有率仅为23%）——LinusTorvalds的生活被改变了。他从他的家乡芬兰迁居到加州的硅谷，在一家名为Transmeta的公司工作。关于他在Transmeta的工作，他只会告诉你它与Linux无关，并且这项工作“很cool”。

他有两个孩子和一项专利（Memory Controller for a Microprocessor for Detecting a Failure of Speculation on the Physical Nature of a Component being Addressed），并且曾经以贵宾身份参加了芬兰最有声望的活动——总统独立日舞会。

他的个性不允许他将不属于他自己的东西占为已有，并且Linus很快就指出如果没有其他人的帮助，他就不会有今天的成就。像David Miller, AlanCox和其他一些天才的程序员在Linux的成功中都扮演了极为重要的角色。如果没有他们和难以数计的人的帮助，Linux操作系统就不会有今天所占据的重要地位。