貝爾實驗室九號計畫

title: 历史.
content: 九号计划在贝尔实验室中取代UNIX成为组织中主要的研究开发平台。与原先的UNIX模型相较,其发展出来的数种改变改善了系统的使用及程序开发,尤其是在分布式多使用者环境中。起先在1980年中期,九号计划只是贝尔实验室的内部计划。到了1992年,贝尔实验室提供第一个公开版本提供给学院使用。在1995年,商业化的第二版释出提供一般大众使用。1990年代后期,朗讯科技继承了贝尔实验室后,对商业化九号计划失去了兴趣。到了2000年释出了非商业化的第三版,采用开放源代码授权。而2002年的第四版更采用自由软件授权。  一个包括现任和前任贝尔实验室成员与麻省理工学院成员参与的使用者与开发人员社群,仍每天以光盘影像档的形式持续提供每日更新释出的档案。贝尔实验室也仍旧承续九号计划的开发。开发中的源代码档案可以透过9P及HTTP协定加以存取并用于既有安装档案的更新。除了光盘映像档中操作系统所包含的官方套件以外,贝尔实验室也架设了一个空间供外部开发的应用程序与工具存放。
title: 概观.
content: 贝尔实验室九号计划主要是由贝尔实验室计算科学研究中心(Computing Sciences Research Center)的成员所开发,该团体也曾开发UNIX及C语言。九号计划团队原先由罗勃·派克、肯·汤普逊、Dave Presotto及Phil Winterbottom所带领,及计算科学研究中心主管丹尼斯·里奇所支持。在多年的开发过程中,有许多开发人员对这项专案做出了不小的贡献,如布莱恩·柯林汉、Tom Duff、道格拉斯·麦克罗伊、比雅尼·斯特劳斯特鲁普、Bruce Ellis、Steve Simon等人。  九号计划是针对现代分布式环境而从开始就设计成一种网络操作系统并加以开发。不同于UNIX是在设计后才增加图形化使用者接口的功能,九号计划打一开始就内建了。虽然仍未成为大受欢迎的UNIX衍生系统,但仍有持续成长的开发者社群。  九号计划具备了分布式架构,它可以被安装并使用於单一自含系统上,也有能力把操作系统的功能套件散布于分散的硬件平台上。在标准的九号计划安装系统中,使用者会以一个轻量化的终端机执行Rio 图形化使用者接口透过网络连接到CPU服务器来处理计算密集型(computation-intensive)的程序,并借由额外的档案服务器及归档储存系统提供长期的资料储存。现有的台式电脑亦可以在内部使用多个虚拟机器重现此种架构。
title: 设计概念.
content: 九号计划的设计者对与微核心类似的目标感兴趣,但是以不同的架构与设计细节来达成这些目标。九号计划的设计目标如下:
title: 一体化的输入/输出模型.
content: 在UNIX之前,多数的操作系统都各自有不同的机制来存取不同类型的装置。举例来说,存取磁盘的API与自序列埠传送或接收的API、又或是操作打印机所使用的API,彼此之间都有所不同。  UNIX借由透过磁盘索引节点(disk inodes)执行所有输入/输出操作来尝试移除这些差异。每个装置都被要求必须要支援带有意义的"读取"和"写入"操作用以作为控制的手段。这也允许使用者无须了解底层的实作细节,便能利用如cp及dd等指令从任一装置送出资料给其他的装置。然而在此同时,许多关键的概念(如控制行程的状态)并没有一致地对应到档案系统上。如同柏克莱接口与X Window系统等的新功能被开发出来以后,以档案系统之外的方式实作。新的硬件功能(如在软件中使光驱退片的功能)也建议采用特定硬件(hardware-specific)控制的机制,如使用ioctl系统呼叫等。  九号计划不采用这些不同的实作,而且回归到以档案系统为中心(file system-centric)的系统观点。无论是网络或者使用者接口、甚至是视窗本身,所有可用资源对于每个九号计划的程序来说,都是阶层式档案系统的一部分,而非特定的接口。
title: 档案系统、档案与名称.
content: 九号计划扩充系统到超越档案的概念,来到了「名称」的层次。无论是电脑的档案、显示器、使用者或电脑本身,都是一个独一无二的路径名称。这些都是透过既有的UNIX标准来处理,并扩充至所有的物件皆可以用一致的方式来命名及寻址。这跟万维网所使用的URI的概念很相似。在UNIX中,像打印机这样的装置会透过软件转换的方式在codice_1以名称代表,但这种寻址方式只对实体连接到硬件上的装置有效,并不能套用到网络装置上。在九号计划系统中,所有的打印机都会以档案的方式呈现,而且可以透过网络被任何工作站存取。  九号计划的另一个创新点则是使用者可以对相同的「真实世界」物件各自分别取不同的名称。每个使用者都可以借由在他们的命名空间中收集各式各样不同的物件来创造属于他们自己的个人化环境。UNIX也有类似的观念,使用者可以复制其他使用者来获取权限。但是九号计划则把这种作法扩充到所有的物件,使用者可以轻易地产生自身的「复制品」,加以修改,就算移除这些复制品也不会影响他们创造过的资源。
title: 合并目录.
content: UNIX允许从不同的资源透过「连结」或档案系统「挂载」的观念来建立档案系统。这些功能会屏蔽掉原先的目录,如果有人在名为「net」的目录下挂载了新的档案系统,会导致无法存取先前可以在「net」目录下存取的内容,除非取消挂载的操作。  九号计划则采用"合并目录"的想法,从不同媒体或网络资源合并的目录会以透明(transparently)的方式系结。举例来说,可以把别台电脑的codice_2(应用程序)目录跟本机端系结,接下来这个目录就会同时有本地端以及远端的应用程序在里面,使用者可以无障碍的存取近端或是远端的程序。使用相同系统的情况下,九号计划所控制的外部装置与资源可以系结到codice_1目录下,这可以让装置不需要任何额外的程序,就可以透过网络进行分享。  现今有许多Linux发行版的Live CD,一定程度上的以合并挂载的方式实做了这个功能。
title: /proc.
content: 列出所有执行中行程的codice_4目录,描绘出这些功能是如何在共同运作时能够带来更好的整体结果。九号计划特别的"档案系统"也为Linux及其他之后的操作系统所采用。不同于其他核心资源的是,行程以codice_4目录下的命名物件(内含资讯与控制档案的子目录)的形式表现,并给予使用者一组动态的输入/输出通道来对行程传送指令及读取资料。使用者无须使用受限的系统呼叫来与编译过的程序核心互动,相反的,它可以使用如codice_6以及codice_7等指令来搜寻、查询、以及操作行程。  使用者也可以从其他的机器上将codice_4目录(以及任何其他特定的档案系统)挂载到自己的命名空间中,就如同这些程序是在本机端一般地与它们互动。结果就是利用个别的机器架构出一套分布式运算环境,这些机器可能是使用者桌上的终端机、储存长期资料的档案服务器、提供较快CPU及运算能力、使用者稽核、闸道器等服务之其他服务器,全部都采用为大多数电脑使用者所熟悉的既有的阶层式目录/命名系统。使用者可以借由终端机来收集档案服务器、服务器上所运行的应用程序、网络上的打印机等设备,系结进自己的命名空间进而"建构"出一套系统。
title: /net.
content: 九号计划并没有使用任何系统呼叫来处理众多的通讯协定或装置驱动程序的接口。举例来说,codice_9目录下包含了所有TCP/IP的API,并可借由使用脚本语言或命令列接口的工具来撰写可以控制档案对连线进行写入或读取的程序。底下的子目录如codice_10和codice_11等目录用来对应各种协定的接口。使用者可以借由挂载一台具有公开(public)IP地址的外部机器的codice_9目录,来让使用9P网络协定的内部网络私有(private)IP地址,能透过该外部机器进行连线的方式,进而达到实做NAT的效果。又或者使用者可以借由挂载远端闸道器的codice_9目录,在公开网络上使用加密(secured)的9P协定达成实做VPN的效果。  以下是在codice_9目录中采用合并(或称堆叠(stack))目录的例子:就像物件导向程序语言的继承观念一样,你可以把一个(可能是远端的)codice_15目录系结到其他的本地端特定目录下,增加一些控制档案以及是需要隐藏其他的档案。这个合并目录线再就像是原先目录的子物件一般,原先的功能可以仅更动一部分就好。对照到codice_9档案系统的情况,使用者可以借由更动或隐藏底下的codice_11子目录,增加本地端过滤程序来达成控制或扩充UDP接口的功能,而不会更动到原本正在运行的(可能是远端机器上的)codice_10子目录的资料。命名空间是针对每个行程来设定的,如果使用者更动对codice_9合并目录来一个不受信任的应用程序设定限制,就可以限制该程序存取网络的能力。  这让程序员很容易就可以在采用档案系统的标准命名格式、存取控制、安全机制的情况下,从不同的系统上使用不同的语言合并「物件」或档案系统,大大增加了使用上的透明度。  这也跟BSD的codice_20 的指令所提供的功能类似,只是挂载的目录不是codice_9而是codice_22,提供的网络协定也只有codice_23而已。
title: 网络与分布式运算.
content: 九号计划虽然是基于UNIX,但是设计上则是想达成运算系统核心功能间彼此沟通的观念。所有系统资源都被当成档案般地命名及存取,并提供可根据在特定机器上各个程序设定的多种分布式系统视图(view)。这种让服务器以类似传统档案的方式,把任何资讯都呈现给使用者及应用程序的实作方式,增进了应用程序设计上的一般化与模组化的能力。  九号计划支援网络通透性的关键在于采用一种新的底层网络协定9P。9P协定实作了连结到命名网络物件并以类档案(file-like)系统呈现的方式。借由快速的位元导向(而非区块导向),分布式档案系统可以把任何物件视觉化的呈现,而非透过远端机器上的一个NFS服务器再加以呈现。这个协定可以用来跟行程、程序、资料、以及包含使用者接口及网络以及彼此之间进行通讯。在第四版中,这个协定作了一些修改并且更名为9P2000。
title: Unicode.
content: 九号计划的系统采用Unicode作为编码机制。九号计划中运用由Ken Thompson提出重大修改的UTF-8作为整个系统中的原生编码,并在1992年将整个系统提供作一般使用。不过九号计划仅支援Unicode中基本多文种平面中有定义的部分。
title: 实作.
content: 除了x86架构下有可安装的实行环境之外、九号计划也移植到MIPS、DEC Alpha、SPARC、PowerPC、ARM及其他硬件平台上。系统以衍生自ISO/ANSI C的语言所编写。部分应用程序原先以Alef撰写,但目前皆以C语言改写。九号计划支援以POSIX应用程序透过APE来模拟柏克莱接口接口。近来有一套新的应用程序"linuxemu"被开发用来执行Linux的程序,目前仍有许多要改进的地方。  九号计划也被用在具代表性的超级电脑上,像是IBM BG/L Supercomputer以及Blue Gene。
title: 影响.
content: UNIX其中一个中心概念是所有系统接口皆可以一组档案的形式呈现,而九号计划成功地把这个概念以现代分布式系统实作出来。九号计划的一些功能,像是Unicode中的UTF-8编码,也被其他操作系统所实作。一些类UNIX操作系统,例如Linux,也实作9P、九号计划的档案系统,以及部分实作的类rfork指令的系统呼叫。除此之外,在Plan 9 from User Space中许多九号计划所采用的应用程序及工具,例如rc shell,也被移植到UNIX以及LINUX系统上,而且还有一定程度的人气。Glendix这个专案则尝试以GNU/Linux操作系统取代九号计划,或者是说,以Linux核心来取代九号计划的核心。  然而,九号计划并未能像UNIX一样热门,变成主要只是一种研究用的工具。九号计划被评为"作用看来不过是能在操作系统研究领域产生有趣论文的装置"。Eric S. Raymond在他的著作"The Art of Unix Programming"中则推测九号计划缺乏被接受度。"九号计划会失败单纯只是因为它的改进程度没大能取代Unix。与九号计划相较,虽然UNIX看来破破烂烂又有明显缺失,但是它还是能好好的把工作完成,这就足以保住它的地位了。这件事情给那些有雄心壮志的系统架构的一堂课是:比更佳解决方案相比之下来的最危险的敌人是那些能把事情已经做的够好的程序。"  对于九号计划的评论像是在操作系统设计中把九号计划列为糟糕的更好的典范,其他常见的评论则有九号计划操作系统中缺乏「优雅」(polish)及开发环境、九号计划中达到商业化程度的软件支援量不足。  九号计划的支持者和开发人员声称阻碍其发展的问题已被解决,原先作为分布式系统、开发环境、研究平台的目标也都已经达成,而且也慢慢地开始有人采用。可透过Inferno的托管能力将九号计划的技术带给其他系统,形成异构网格运算中的一部分。
title: 授权.
content: 完整的源代码可以免费的在朗讯公共许可证1.02版的授权之下取得,而且被开放源代码促进会认为是开放源代码软件及自由软件基金会认为是自由软件。它虽然有通过Debian Free Software Guidelines,不过不相容于GNU通用公共许可证。

Summary: 贝尔实验室九号计划(英语:Plan 9 from Bell Labs,常简称为Plan 9)是一个分布式操作系统,由贝尔实验室的计算科学研究中心在1980年代中期至2002年开发,以作为UNIX的后继者。它现在仍然被操作系统的研究者和爱好者开发使用。

Plan 9 from Bell Labs: Plan 9 from Bell Labs, habituellement appelé Plan 9, est un système d'exploitation expérimental développé par Bell Labs, le descendant de "Unix Time-Sharing System". Ce n'est cependant pas un Unix, malgré la ressemblance de nombreux éléments. Le développement d'un nouveau système d'exploitation a été lancé parce que les problèmes d'Unix étaient jugés trop profonds pour être corrigés (« The problems with Unix were too deep to fix »). Son développement commença vers 1987, alors qu'Unix Time-Sharing System 8 était encore en développement.