标签 进化 下的文章

纵观现代计算机的历史，从与系统的交互方式方面，可以划分为数个进化阶段。而我更倾向于将之归类为以下几个阶段：

  1. 数字系统
  2. 专用应用系统
  3. 应用中心系统
  4. 信息中心系统
  5. 无应用系统

下面我们详细聊聊这几种分类。

数字系统

在我看来，早期计算机，只被设计用来处理数字。它们能够加、减、乘、除。在它们中有一些能够运行像是微分和积分之类的更复杂的数学操作。

当然，如果你把字符映射成数字，它们也可以计算字符串。但这多少有点“数字的创造性使用”的意思，而不是直接处理各种信息。

专用应用系统

对于更高层级的问题，纯粹的数字系统是不够的。专用应用系统被开发用来处理单一任务。它们和数字系统十分相似，但是，它们拥有足够的复杂数字计算能力。这些系统能够完成十分明确的高层级任务，像调度问题的相关计算或者其他优化问题。

这类系统为单一目的而搭建，它们解决的是单一明确的问题。

应用中心系统

应用中心系统是第一个真正的通用系统。它们的主要使用风格很像专用应用系统，但是它们拥有以时间片模式（一个接一个）或以多任务模式（多应用同时）运行的多个应用程序。

上世纪 70 年代的 早期的个人电脑是第一种受人们欢迎的应用中心系统。

如今的现在操作系统 —— Windows 、macOS 、大多数 GNU/Linux 桌面环境 —— 一直遵循相同的法则。

当然，应用中心系统还可以再细分为两种子类：

  1. 紧密型应用中心系统
  2. 松散型应用中心系统

紧密型应用中心系统像是 Windows 3.1 （拥有程序管理器和文件管理器）或者甚至 Windows 95 的最初版本都没有预定义的文件夹层次。用户启动文本处理程序（像 WinWord ）并且把文件保存在 WinWord 的程序文件夹中。在使用表格处理程序的时候，又把文件保存在表格处理工具的程序文件夹中。诸如此类。用户几乎不创建自己的文件层次结构，可能由于此举的不方便、用户单方面的懒惰，或者他们认为根本没有必要。那时，每个用户拥有几十个至多几百个文件。

为了访问文件中的信息，用户常常先打开一个应用程序，然后通过程序中的“文件/打开”功能来获取处理过的数据文件。

在 Windows 平台的 Windows 95 SP2 中，“我的文档”首次被使用。有了这样一个文件层次结构的样板，应用设计者开始把 “我的文档” 作为程序的默认的保存 / 打开目录，抛弃了原来将软件产品安装目录作为默认目录的做法。这样一来，用户渐渐适应了这种模式，并且开始自己维护文件夹层次。

松散型应用中心系统（通过文件管理器来提取文件）应运而生。在这种系统下，当打开一个文件的时候，操作系统会自动启动与之相关的应用程序。这是一次小而精妙的用法转变。这种应用中心系统的用法模式一直是个人电脑的主要用法模式。

然而，这种模式有很多的缺点。例如，为了防止数据提取出现问题，需要维护一个包含给定项目的所有相关文件的严格文件夹层次结构。不幸的是，人们并不总能这样做。更进一步说，这种模式不能很好的扩展。 桌面搜索引擎和高级数据组织工具（像 tagstore）可以起到一点改善作用。正如研究显示的那样，只有一少部分人正在使用那些高级文件提取工具。大多数的用户不使用替代提取工具或者辅助提取技术在文件系统中寻找文件。

信息中心系统

解决上述需要将所有文件都放到一个文件夹的问题的可行办法之一就是从应用中心系统转换到信息中心系统。

信息中心系统将项目的所有信息联合起来，放在一个地方，放在同一个应用程序里。因此，我们再也不需要计算项目预算时，打开表格处理程序；写工程报告时，打开文本处理程序；处理图片文件时，又打开另一个工具。

上个月的预算情况在客户会议笔记的右下方，客户会议笔记又在画板的右下方，而画板又在另一些要去完成的任务的右下方。在各个层之间没有文件或者应用程序来回切换的麻烦。

早期，IBM OS/2、 Microsoft OLE 和 NeXT 都做过类似的尝试。但都由于种种原因没有取得重大成功。从 Plan 9 发展而来的 ACme 是一个非常有趣的信息中心环境。它在一个应用程序中包含了多种应用程序。但是即时是它移植到了 Windows 和 GNU/Linux，也从来没有成为一个引起关注的软件。

信息中心系统的现代形式是高级 个人维基（像 TheBrain 和 Microsoft OneNote）。

我选择的个人工具是带 Org 模式 扩展的 GNU/Emacs 平台。在用电脑的时候，我几乎不能没有 Org 模式 。为了访问外部数据资源，我创建了一个可以将多种数据导入 Org 模式的插件 —— Memacs 。我喜欢将表格数据计算放到日程任务的右下方，然后是行内图片，内部和外部链接，等等。它是一个真正的用户不用必须操心程序或者严格的层次文件系统文件夹的信息中心系统。同时，用简单的或高级的标签也可以进行多分类。一个命令可以派生多种视图。比如，一个视图有日历，待办事项。另一个视图是租借事宜列表。等等。它对 Org 模式的用户没有限制。只有你想不到，没有它做不到。

进化结束了吗？ 当然没有。

无应用系统

我能想到这样一类操作系统，我称之为无应用系统。在下一步的发展中，系统将不需要单一领域的应用程序，即使它们能和 Org 模式一样出色。计算机直接提供一个处理信息和使用功能的友好用户接口，而不通过文件和程序。甚至连传统的操作系统也不需要。

无应用系统也可能和 人工智能 联系起来。把它想象成 2001 太空漫游 中的 HAL 9000 和星际迷航中的 LCARS 一类的东西就可以了。

从基于应用的、基于供应商的软件文化到无应用系统的转化让人很难相信。 或许，缓慢但却不断发展的开源环境，可以使一个由各种各样组织和人们贡献的真正无应用环境成型。

信息和提取、操作信息的功能，这是系统应该具有的，同时也是我们所需要的。其他的东西仅仅是为了使我们不至于分散注意力。

via: http://karl-voit.at/2017/02/10/evolution-of-systems/

作者：Karl Voit 译者：lontow 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

http://www.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-History/html/Spi15c.html

This is an HTML rendering of a working paper draft that led to a publication. The publication should always be cited in preference to this draft using the following reference:

This document is also available in PDF format.

The document's metadata is available in BibTeX format.

This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

Diomidis Spinellis Publications

© 2015 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

摘要

Unix 操作系统的进化历史，可以从一个版本控制仓库中窥见，时间跨度从 1972 年的 5000 行内核代码开始，到 2015 年成为一个含有 26,000,000 行代码的被广泛使用的系统。该仓库包含 659,000 条提交，和 2306 次合并。仓库部署了被普遍采用的 Git 系统用于储存其代码，并且在时下流行的 GitHub 上建立了存档。它由来自 贝尔实验室 （ Bell Labs ） ， 伯克利大学 （ Berkeley University ） ，386BSD 团队所开发的系统软件的 24 个快照综合定制而成，这包括两个老式仓库和一个开源 FreeBSD 系统的仓库。总的来说，可以确认其中的 850 位个人贡献者，更早些时候的一批人主要做基础研究。这些数据可以用于一些经验性的研究，在软件工程，信息系统和软件考古学领域。

1、介绍

Unix 操作系统作为一个主要的工程上的突破而脱颖而出，得益于其模范的设计、大量的技术贡献、它的开发模型及广泛的使用。Unix 编程环境的设计已经被视为一个提供非常简洁、强大而优雅的设计 [1] 。在技术方面，许多对 Unix 有直接贡献的，或者因 Unix 而流行的特性就包括 [2] ：用高级语言编写的可移植部署的内核；一个分层式设计的文件系统；兼容的文件，设备，网络和进程间 I/O；管道和过滤架构；虚拟文件系统；和作为普通进程的可由用户选择的不同 shell。很早的时候，就有一个庞大的社区为 Unix 贡献软件 [3] ，[4,pp. 65-72] 。随时间流逝，这个社区不断壮大，并且以现在称为开源软件开发的方式在工作着 [5,pp. 440-442] 。Unix 和其睿智的晚辈们也将 C 和 C++ 编程语言、分析程序和词法分析生成器（yacc，lex）、文档编制工具（troff，eqn，tbl）、脚本语言（awk，sed，Perl）、TCP/IP 网络、和 配置管理系统 （ configuration management system ） （SCSS，RCS，Subversion，Git）发扬广大了，同时也形成了现代互联网基础设施和网络的最大的部分。

幸运的是，一些重要的具有历史意义的 Unix 材料已经保存下来了，现在保持对外开放。尽管 Unix 最初是由相对严格的协议发行，但在早期的开发中，很多重要的部分是通过 Unix 的版权拥有者之一（Caldera International) （LCTT 译注：2002年改名为 SCO Group）以一个自由的协议发行。通过将这些部分再结合上由 加州大学伯克利分校 （ University of California, Berkeley ） 和 FreeBSD 项目组开发或发布的开源软件，贯穿了从 1972 年六月二十日开始到现在的整个系统的开发。

通过规划和处理这些可用的快照以及或旧或新的配置管理仓库，将这些可用数据的大部分重建到一个新合成的 Git 仓库之中。这个仓库以数字的形式记录了过去44年来最重要的数字时代产物的详细的进化。下列章节描述了该仓库的结构和内容（第2节）、创建方法（第3节）和该如何使用（第4节）。

2、数据概览

这 1GB 的 Unix 历史仓库可以从 GitHub 上克隆 1 。如今 2 ，这个仓库包含来自 850 个贡献者的 659,000 个提交和 2,306 个合并。贡献者有来自 贝尔实验室 （ Bell Labs ） 的 23 个员工， 伯克利大学 （ Berkeley University ） 的 计算机系统研究组 （ Computer Systems Research Group ） （CSRG）的 158 个人，和 FreeBSD 项目的 660 个成员。

这个仓库的生命始于一个 Epoch 的标签，这里面只包含了证书信息和现在的 README 文件。其后各种各样的标签和分支记录了很多重要的时刻。

  • Research-VX 标签对应来自 贝尔实验室 （ Bell Labs ） 六个研究版本。从 Research-V1 （4768 行 PDP-11 汇编代码）开始，到以 Research-V7 （大约 324,000 行代码，1820 个 C 文件）结束。
  • Bell-32V 是第七个版本 Unix 在 DEC/VAX 架构上的移植。
  • BSD-X 标签对应 伯克利大学 （ Berkeley University ） 释出的 15 个快照。
  • 386BSD-X 标签对应该系统的两个开源版本，主要是 Lynne 和 William Jolitz 写的适用于 Intel 386 架构的内核代码。
  • FreeBSD-release/X 标签和分支标记了来自 FreeBSD 项目的 116 个发行版。

另外，以 -Snapshot-Development 为后缀的分支，表示该提交由来自一个以时间排序的快照文件序列而合成；而以一个 -VCS-Development 为后缀的标签，标记了有特定发行版出现的历史分支的时刻。

仓库的历史包含从系统开发早期的一些提交，比如下面这些。

commit c9f643f59434f14f774d61ee3856972b8c3905b1
Author: Dennis Ritchie <research!dmr>
Date:   Mon Dec 2 18:18:02 1974 -0500
    Research V5 development
    Work on file usr/sys/dmr/kl.c

两个发布之间的合并代表着系统发生了进化，比如 BSD 3 的开发来自 BSD2 和 Unix 32/V，它在 Git 仓库里正是被表示为带两个父节点的图形节点。

更为重要的是，以这种方式构造的仓库允许 git blame，就是可以给源代码行加上注释，如版本、日期和它们第一次出现相关联的作者，这样可以知道任何代码的起源。比如说，检出 BSD-4 这个标签，并在内核的 pipe.c 文件上运行一下 git blame，就会显示出由 Ken Thompson 写于 1974，1975 和 1979年的代码行，和 Bill Joy 写于 1980 年的。这就可以自动（尽管计算上比较费事）检测出任何时刻出现的代码。

图1：各个重大 Unix 发行版的代码来源

如上图所示，现代版本的 Unix（FreeBSD 9）依然有相当部分的来自 BSD 4.3，BSD 4.3 Net/2 和 BSD 2.0 的代码块。有趣的是，这图片显示有部分代码好像没有保留下来，当时激进地要创造一个脱离于伯克利（386BSD 和 FreeBSD 1.0）所释出代码的开源操作系统。FreeBSD 9 中最古老的代码是一个 18 行的队列，在 C 库里面的 timezone.c 文件里，该文件也可以在第七版的 Unix 文件里找到，同样的名字，时间戳是 1979 年一月十日 - 36 年前。

3、数据收集和处理

这个项目的目的是以某种方式巩固从数据方面说明 Unix 的进化，通过将其并入一个现代的版本仓库，帮助人们对系统进化的研究。项目工作包括收录数据，分类并综合到一个单独的 Git 仓库里。

图2：导入 Unix 快照、仓库及其合并

项目以三种数据类型为基础（见图2）。首先，早期发布版本的快照，获取自 Unix 遗产社会归档 （ Unix Heritage Society archive ） 3 、包括了 CSRG 全部的源代码归档的 CD-ROM 镜像 4 ， Oldlinux 网站 5 和 FreeBSD 归档 6 。 其次，以前的和现在的仓库，即 CSRG SCCS [6] 仓库，FreeBSD 1 CVS 仓库，和现代 FreeBSD 开发的 Git 镜像 7 。前两个都是从和快照相同的来源获得的。

最后，也是最费力的数据源是 初步研究 （ primary research ） 。释出的快照并没有提供关于它们的源头和每个文件贡献者的信息。因此，这些信息片段需要通过 初步研究 （ primary research ） 验证。至于作者信息主要通过作者的自传，研究论文，内部备忘录和旧文档扫描件；通过阅读并且自动处理源代码和帮助页面补充；通过与那个年代的人用电子邮件交流；在 StackExchange 网站上贴出疑问；查看文件的位置（在早期的内核版本的源代码，分为 usr/sys/dmr 和 /usr/sys/ken 两个位置）；从研究论文和帮助手册披露的作者找到源代码，从一个又一个的发行版中获取。（有趣的是，第一和第二的 研究版 （ Research Edition ） 帮助页面都有一个 “owner” 部分，列出了作者（比如，Ken）及对应的系统命令、文件、系统调用或库函数。在第四版中这个部分就没了，而在 BSD 发行版中又浮现了 “Author” 部分。）关于作者信息更为详细地写在了项目的文件中，这些文件被用于匹配源代码文件和它们的作者和对应的提交信息。最后，关于源代码库之间的合并信息是获取自 NetBSD 项目所维护的 BSD 家族树 8 。

作为本项目的一部分而开发的软件和数据文件，现在可以在线获取 9 ，并且，如果有合适的网络环境，CPU 和磁盘资源，可以用来从头构建这样一个仓库。关于主要发行版的作者信息，都存储在本项目的 author-path 目录下的文件里。它们的内容中带有正则表达式的文件路径后面指出了相符的作者。可以指定多个作者。正则表达式是按线性处理的，所以一个文件末尾的匹配一切的表达式可以指定一个发行版的默认作者。为避免重复，一个以 .au 后缀的独立文件专门用于映射作者的 识别号 （ identifier ） 和他们的名字及 email。这样一个文件为每个与该系统进化相关的社区都建立了一个： 贝尔实验室 （ Bell Labs ） ， 伯克利大学 （ Berkeley University ） ，386BSD 和 FreeBSD。为了真实性的需要，早期 贝尔实验室 （ Bell Labs ） 发行版的 emails 都以 UUCP 注释 （ UUCP notation ） 方式列出（例如， research!ken)。FreeBSD 作者的识别映射，需要导入早期的 CVS 仓库，通过从如今项目的 Git 仓库里拆解对应的数据构建。总的来说，由 1107 行构成了注释作者信息的文件（828 个规则），并且另有 640 行用于映射作者的识别号到名字。

现在项目的数据源被编码成了一个 168 行的 Makefile。它包括下面的步骤。

Fetching 从远程站点复制和克隆大约 11GB 的镜像、归档和仓库。

Tooling 从 2.9 BSD 中为旧的 PDP-11 归档获取一个归档器，并调整它以在现代的 Unix 版本下编译；编译 4.3 BSD 的 compress 程序来解压 386BSD 发行版，这个程序不再是现代 Unix 系统的组成部分了。

Organizing 用 tar 和 cpio 解压缩包；合并第六个研究版的三个目录；用旧的 PDP-11 归档器解压全部一个 BSD 归档；挂载 CD-ROM 镜像，这样可以作为文件系统处理；合并第 8 和 62 的 386BSD 磁盘镜像为两个独立的文件。

Cleaning 恢复第一个研究版的内核源代码文件，这个可以通过 OCR 从打印件上得到近似其原始状态的的格式；给第七个研究版的源代码文件打补丁；移除发行后被添加进来的元数据和其他文件，为避免得到错误的时间戳信息；修复毁坏的 SCCS 文件；用一个定制的 Perl 脚本移除指定到多个版本的 CVS 符号、删除与现在冲突的 CVS Attr 文件、用 cvs2svn 将 CVS 仓库转换为 Git 仓库，以处理早期的 FreeBSD CVS 仓库。

在仓库 再现 （ representation ） 中有一个很有意思的部分就是，如何导入那些快照，并以一种方式联系起来，使得 git blame 可以发挥它的魔力。快照导入到仓库是基于每个文件的时间戳作为一系列的提交实现的。当所有文件导入后，就被用对应发行版的名字给标记了。然后，可以删除那些文件，并开始导入下一个快照。注意 git blame 命令是通过回溯一个仓库的历史来工作的，并使用 启发法 （ heuristics ） 来检测文件之间或文件内的代码移动和复制。因此，删除掉的快照间会产生中断，以防止它们之间的代码被追踪。

相反，在下一个快照导入之前，之前快照的所有文件都被移动到了一个隐藏的后备目录里，叫做 .ref（引用）。它们保存在那，直到下个快照的所有文件都被导入了，这时候它们就会被删掉。因为 .ref 目录下的每个文件都精确对应一个原始文件，git blame 可以知道多少源代码通过 .ref 文件从一个版本移到了下一个，而不用显示出 .ref 文件。为了更进一步帮助检测代码起源，同时增加 再现 （ representation ） 的真实性，每个发行版都被 再现 （ represented ） 为一个有增量文件的分支（-Development）与之前发行版之间的合并。

上世纪 80 年代时期，只有 伯克利大学 （ Berkeley University ） 开发的文件的一个子集是用 SCCS 版本控制的。在那个期间，我们的统一仓库里包含了来自 SCCS 的提交和快照的增量文件的导入数据。对于每个发行版，可用最近的时间戳找到该 SCCS 提交，并被标记为一个与发行版增量导入分支的合并。这些合并可以在图2 的中间看到。

将各种数据资源综合到一个仓库的工作，主要是用两个脚本来完成的。一个 780 行的 Perl 脚本（import-dir.pl）可以从一个单独的数据源（快照目录、SCCS 仓库，或者 Git 仓库）中，以 Git fast export 格式导出（真实的或者综合的）提交历史。输出是一个简单的文本格式，Git 工具用这个来导入和导出提交。其他方面，这个脚本以一些东西为参数，如文件到贡献者的映射、贡献者登录名和他们的全名间的映射、哪个导入的提交会被合并、哪些文件要处理和忽略、以及“引用”文件的处理。一个 450 行的 Shell 脚本创建 Git 仓库，并调用带适当参数的 Perl 脚本，来导入 27 个可用的历史数据资源。Shell 脚本也会运行 30 个测试，比较特定标签的仓库和对应的数据源，核对查看的目录中出现的和没出现的，并回溯查看分支树和合并的数量，git blame 和 git log 的输出。最后，调用 git 作垃圾收集和仓库压缩，从最初的 6GB 降到分发的 1GB 大小。

4、数据使用

该数据可以用于软件工程、信息系统和 软件考古学 （ software archeology ） 领域的经验性研究。鉴于它从不间断而独一无二的存在了超过了 40 年，可以供软件进化和跨代更迭参考。从那时以来，处理速度已经成千倍地增长、存储容量扩大了百万倍，该数据同样可以用于软件和硬件技术 交叉进化 （ co-evolution ） 的研究。软件开发从研究中心到大学，到开源社区的转移，可以用来研究组织文化对于软件开发的影响。该仓库也可以用于学习著名人物的实际编程，比如 Turing 奖获得者（Dennis Ritchie 和 Ken Thompson）和 IT 产业的大佬（Bill Joy 和 Eric Schmidt）。另一个值得学习的现象是代码的长寿，无论是单行的水平，或是作为那个时代随 Unix 发布的完整的系统（Ingres、 Lisp、 Pascal、 Ratfor、 Snobol、 TMP），和导致代码存活或消亡的因素。最后，因为该数据让 Git 感到了压力，底层的软件仓库存储技术达到了其极限，这会推动版本管理系统领域的工程进度。

图3：Unix 发行版的代码风格进化

图3 根据 36 个主要 Unix 发行版描述了一些有趣的代码统计的趋势线（用 R 语言的局部多项式回归拟合函数生成），验证了代码风格和编程语言的使用在很长的时间尺度上的进化。这种进化是软硬件技术的需求和支持、软件构筑理论，甚至社会力量所驱动的。图片中的日期计算了出现在一个给定发行版中的所有文件的平均日期。正如可以从中看到，在过去的 40 年中，标示符和文件名字的长度已经稳步从 4 到 6 个字符增长到 7 到 11 个字符。我们也可以看到注释数量的少量稳步增加，以及 goto 语句的使用量减少，同时 register 这个类型修饰符的消失。

5、未来的工作

可以做很多事情去提高仓库的正确性和有效性。创建过程以开源代码共享了，通过 GitHub 的 拉取请求 （ pull request ） ，可以很容易地贡献更多代码和修复。最有用的社区贡献将使得导入的快照文件的覆盖面增长，以便归属于某个具体的作者。现在，大约 90,000 个文件（在 160,000 总量之外）通过默认规则指定了作者。类似地，大约有 250 个作者（最初 FreeBSD 那些）仅知道其识别号。两个都列在了 build 仓库的 unmatched 目录里，欢迎贡献数据。进一步，BSD SCCS 和 FreeBSD CVS 的提交共享相同的作者和时间戳，这些可以结合成一个单独的 Git 提交。导入 SCCS 文件提交的支持会被添加进来，以便引入仓库对应的元数据。最后，也是最重要的，开源系统的更多分支会添加进来，比如 NetBSD、 OpenBSD、DragonFlyBSD 和 illumos。理想情况下，其他历史上重要的 Unix 发行版，如 System III、System V、 NeXTSTEP 和 SunOS 等的当前版权拥有者，也会在一个允许他们的合作伙伴使用仓库用于研究的协议下释出他们的系统。

鸣谢

本文作者感谢很多付出努力的人们。 Brian W. Kernighan, Doug McIlroy 和 Arnold D. Robbins 在贝尔实验室（Bell Labs）的登录识别号方面提供了帮助。 Clem Cole， Era Erikson， Mary Ann Horton, Kirk McKusick, Jeremy C. Reed, Ingo Schwarze 和 Anatole Shaw 在 BSD 的登录识别号方面提供了帮助。BSD SCCS 的导入代码是基于 H. Merijn Brand 和 Jonathan Gray 的工作。

这次研究由欧盟 ( 欧洲社会基金 （ European Social Fund，ESF ） ) 和 希腊国家基金 （ Greek national funds ） 通过 国家战略参考框架 （ National Strategic Reference Framework ，NSRF ） 的 Operational Program " Education and Lifelong Learning" - Research Funding Program: Thalis - Athens University of Economics and Business - Software Engineering Research Platform ，共同出资赞助。

引用

1 M. D. McIlroy, E. N. Pinson, and B. A. Tague, "UNIX time-sharing system: Foreword," The Bell System Technical Journal, vol. 57, no. 6, pp. 1899-1904, July-August 1978.

2 D. M. Ritchie and K. Thompson, "The UNIX time-sharing system," Bell System Technical Journal, vol. 57, no. 6, pp. 1905-1929, July-August 1978.

3 D. M. Ritchie, "The evolution of the UNIX time-sharing system," AT&T Bell Laboratories Technical Journal, vol. 63, no. 8, pp. 1577-1593, Oct. 1984.

4 P. H. Salus, A Quarter Century of UNIX. Boston, MA: Addison-Wesley, 1994.

5 E. S. Raymond, The Art of Unix Programming. Addison-Wesley, 2003.

6 M. J. Rochkind, "The source code control system," IEEE Transactions on Software Engineering, vol. SE-1, no. 4, pp. 255-265, 1975.

脚注

1 - https://github.com/dspinellis/unix-history-repo

2 - Updates may add or modify material. To ensure replicability the repository's users are encouraged to fork it or archive it.

3 - http://www.tuhs.org/archive_sites.html

4 - https://www.mckusick.com/csrg/

5 - http://www.oldlinux.org/Linux.old/distributions/386BSD

6 - http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/

7 - https://github.com/freebsd/freebsd

8 - http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/share/misc/bsd-family-tree

9 - https://github.com/dspinellis/unix-history-make

via: http://www.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-History/html/Spi15c.html

作者：Diomidis Spinellis译者：wi-cuckoo 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Mark Shuttleworth之前关闭了Ubuntu Linux的第一号bug（“微软拥有最高的市场占有率”），导致了一些争议，也引出了一些意味深长的讨论，讨论自从1991年Linus Torvalds以个人玩物项目发明Linux以来，Linux所走过的路。

微软也许不会那么快退出桌面系统的历史舞台，但是随着Linux逐渐成长成为IT行业的一块重要基石，计算机的本质也已经完全改变。如今，从云服务到手机操作系统，几乎行业内的所有领域都受到了Linux的直接推动或间接影响。

Linux体系：提交、审核、采纳

伴随着支持者的不断增加，Linux的开发进程也在不断加快。

但发展的方向又在何处？如果Linux的普及和开发程度正在接近顶峰，那接下来Linux将去往何方？因为Linux具有超高的定制性和超多的“分身”，也许没有哪一个单独的答案能够回答这个问题。

或许，更重要的，是快速成长中的Linux如何应对挑战，变得更加成熟稳定，成为在多个领域主导市场发展的领头羊。接下来，让我们分别从以下几个方面尝试预测一下Linux的未来：原材料、社区产品与企业贡献、其特质所面对的各种挑战、技术实力和成长方向。

Linux作为原材料：弯曲、塑形，你想让它是什么样都可以

如果用一个形容词来总结Linux独有的优点，那就是“可塑性(malleable)”。Linux是这样一种原材料，可以装订切割，也可以为任意场合量身定做，小到嵌入式设备，大到大规模并行超级计算机。

但同时，这也是Linux的缺点之一。它千变万化的特性使得它很少以“Linux”的本来面目出现 —— 相反，人们使用的是各种“基于Linux”的产品，例如Android、或家用路由器这样的硬件设备。桌面Linux的多个发行版（之间往往不相容）也把最忠实的用户群分割得七零八落。

Linux基金会执行董事Jim Zemlin承认，“Linux终端用户的体验的的确确是支离破碎的，但这也是Linux的一个强大之处。”

“它就像一块建筑地基，使得Google能建立Android和Chromebooks，Amazon建立Kindle，Canonical建立Ubuntu，等等这样的例子还有很多。所有这些产品对用户来说意味着不同的使用体验，而选择权完全在消费者自己手里。”

Mark Baker，Canonical公司的Ubuntu服务器产品经理，目前负责领导Ubuntu项目。他的话更加具体准确地表明了这一观点：“开源意味着选择的自由。”开源自然会促进模块化，因此，无论你是一个技术宅男还是正在开发数据中心的系统架构师，“通过开源，你可以选择最适合你的组件”。

但是IDC的操作环境分析师兼系统软件项目副经理 Al Gillen 却质疑这种完全放任自流的价值观。“Linux是开源的，由此，任何人都可以修改代码，把它变成别的什么东西。但是，现代工业已经表明，没有价值的产品会被淘汰，代码的发展主线应当始终紧靠主流价值观。”

Android用户对此有直接的深刻体会，诸多Android操作系统间存在着严重的碎片化问题。严格来说，尽管这并不都是Linux的责任，但是看看在Android之前就已经出现的无数五花八门的Linux桌面发行版吧，放任产品随意修改，差异化实现又造成更大的影响 —— Android碎片化只是将这些问题生动放大了而已。

讽刺的是，即使“可塑性”真的是Linux的最大优势，但过犹不及，Linux作为这样的原材料将会付出成倍的代价。

Cloudera的工程部经理 Eric Sammer 并没有孤立地看待这个问题，他认为Linux的用户群“与Firefox或Apache等产品的用户群并不一样”，Linux“面向的并不是终端用户，而是操作系统类工程师”，因此它需要与“很多其他软件一同建立一个完整的系统 —— 其中大部分软件是捆绑发布的，并对用户透明（例如boot loader）。”就如同Torvalds在Linux最初的内核发布日志中亲自写道，“只有内核，你什么也干不了。”

Android验证了Gillen和Sammer以上两人的观点，作为Linux最受欢迎的“衍生品”，Android所有的附加值都来自于Google以及Google专门为其开发的App生态系统。因此说，Linux的可塑性只是它成为真正产品的第一步，正如下文中这些最成功的Linux拥护者 —— 企业，所熟悉的一样。

企业的贡献：利还是弊？

Linux的另一个特点，它是一个合作产物，由众多贡献者共同努力缔造而成。那么，这些贡献者从何而来？

答案：企业。企业是最主要的贡献者，但是他们忠于利益，支持Linux只是为了自身的未来发展。除去Red Hat（不同于Canonical，RedHat是最为人所熟知的Linux解决方案供应商），排名前几位的贡献者主要包括Intel，IBM，德州仪器，甚至还有微软。

Linux的所谓“灵活性”，即能够运行在多个平台或设备上的能力，很大程度上来源于以上这些贡献者，而他们的主要动力则来自于不断萌发的自身需要：例如，微软为Linux内核添加的代码，大大改善了Linux在其产品Hyper-V下的运行状况。

Sammer相信企业背景的发行版之所以能够普及，是“因为Linux内核这样的项目其复杂程度和准入门槛太高，一般水平的C程序员很难在有限的业余时间内，仅凭个人能力，而不依靠企业的支持，跟上内核的更新进度、建立社区公信力，或者做出某些重大贡献”。在他看来，企业恰恰有能力有资源支持这样的努力，与之相比，高校和研究机构已被远远地抛在了后面。

但是企业发行版的普及就代表Linux已经陷入企业的控制了吗？难道这就是Linux的未来？沦为资本的玩物？

其实最重要的不是看谁对Linux的贡献最多，而是这种贡献所代表的企业精神。不管是纯粹为了圈钱，还是为了把挣来的钱都回馈于社区，无论这些企业最初的动机是什么，作为Linux的贡献者，它们始终对贡献本身坚信不疑。

Mark Coggin，Linux红帽企业版的市场高级总监，他坚信，“最佳的创新点是那些经过开源社区的无数参与者利用、改进后的方案。”

“我们所有的新点子都会先作为开源项目，寻求社区上游项目组的增益评估，然后才加入像红帽企业版这样的产品。我们希望那些为Linux内核及配套项目工作的每个人，也能拥有像我们一样的眼光。”

还有一小部分观点认为，企业发行版Linux其实是一种“被绑架的Linux”，正如Gillen所提倡的 —— 这是一种让Linux“稍稍不那么贴合主流用户群需求”的方法。他确信，对Linux的商业化支持与商业优化“对Linux的开发模式大有裨益，而不是相反。”

同样的，对Zenmlin来说，Linux开发“并不是一个零和游戏”

“如果移动领域的某位开发者改善了耗电量，另一位在数据中心工作的开发者会因此而受益，他可以使用前者的改进来确保自己的数据服务运行得更有效率，”Zemlin说道，“共享开发正是Linux如此强大的原因。”

同样，企业开发也并非敌人，“人们为Linux的开发工作付费从来都不是坏事；这些钱款可以让Linux的改善与创新变得更加迅捷快速。”

真正的问题是，Baker补充道，“一些超大型网络公司对Linux作出改进并上线应用，但是却为了保持自己的优势，而把这些改进捂在自家门里。”

GPL协议第三版 —— 从Linux发布协议的一个早期版本改进而来 —— 当初修改该协议的部分原因就是为了应对上述行为。尽管如此，协议只能防止获取他人代码后作为Web服务重新开发。除此以外，并没有什么固有的方法（或法律手段）能够禁止公司或个人在代码开发完成后封闭独占这些改进后的代码，也许，这就是Linux对全世界自由开放所不可避免的一部分社会成本吧。

Linux面临的最大威胁

感谢开源机制，Linux始终能够作为一个开源项目，企业才无法像以前那么独断专行。那除了企业，现在什么才是Linux所面临的最大威胁呢？

没人会真的认为Linux会被版权欺诈或诉讼所威胁，更不会因此从OS版图上消失。类似的最大一起诉讼案，SCO Group公司控告IBM案，被广泛解释为间接对Linux的攻击，也最终以悲惨的失败而告终（译者注，该案件间接导致了SCO Group的破产）。

Coggin也倾向于该观点：“依靠巨大的开发者网络和全球范围内的推广传播，Linux取得了巨大成功，这意味着它具有很强的韧性。尽管专利威胁一直都在增加，正如许多科技公司最近所做的那样，但是看起来专利诉讼并不会对Linux产生任何实质性的威胁。”

除此以外，其他类似开源产品的竞争，甚至更加自由化的协议（例如各式各样的BSD们），目前为止，都没有真正达到能够危及淘汰Linux的程度。

Sammer用一个单词总结出了，在合法范围内，Linux面临的最大威胁：自满！ —— 自满地认为已经成为所有领域的市场领导者。

他说，“如果你正在竞争第一名的位置，你常常愿意更开放地做出改变，无论是过程上的、心态上的，还是有关发展路线的，甚至维持现状本身。想想Firefox被Chrome以如此快的速度抢走了如此多的份额，再想想当年的商业化Unix们被Linux抢占江山，这样的例子还有很多很多。”

大致根据同样的思路，Zemlin看到了这样一种威胁，面对日益增长的需求，Linux的天才开发者们才气有余，但经验不足，因此这才有了Linux培训项目。

Gillen发现的威胁来自于社区的变化，“随着时间推移，Linux的主流用户群 —— 社区，正在从企业的客户（服务的消费者）转变为服务的提供者。”

这样一种变化可能会导致Linux用户被迫作为Linux服务提供者的同时，却完全无法将自己的智慧和创新回馈社区。这种变化也许会持续十几年甚至更长，但它“对整个Linux世界都具有深远的消极影响，包括各个Linux商业发行商在内。”

Linux所要面对的另外一个潜在威胁是公司兼并 —— 这并不会威胁到Linux本身，但它可能会间接导致各种各样的可能性。Baker担心移动设备的快速增长，除了受Linux自身的发展影响外，更多的会受到来自企业施加的影响。

他说，“这就是为什么我们需要诸如Ubuntu和Firefox这样的第二选择，目的就是为那些上网时不愿受Apple和Google摆布的人们提供真正的替代品。”

说到Google，Google是Android的发展道路上最坚定的捍卫者。围绕Android作为Linux发展而来这一话题，有许多反对意见的争论，这样的争论对于Google的世界观来说，就像与它的首页相比较一样，稍显多余，同时它们也不符合Linux（自由开放）的精神。

简而言之，目前Linux面临的最大威胁来自于它自身 —— 无意中，衡量Linux产品的第一标准已经变成了如何让它看起来更吸引人。一直以来，Linux所固有的灵活性和可塑性帮助它战胜自满和企业兼并，克服重重困难，但如今还能否一如既往，情况并不明朗。

路在何方？

毫无疑问，无论从哪个层面来看，Linux现在都正处在关键的岔路口，它将去往何方，又将付出怎样的代价，都值得探讨。

Linux最明显的未来之路，首先，它不仅仅是一块基石，或者说不仅仅是一种建立基础设施的途径；其次，它应当减少过多的产品形式；最后，真正的革新，不仅仅是拓展Linux本身，还要拓展其作为发现问题解决问题的创新办法。目前还很少有人如此对待Linux，要想真正做到这一点，除了呼吁更多的人改变对Linux的看法，还必须打破技术壁垒，将眼光放得更长远。

对此，Coggin说道：“Linux正在逐渐成为一个更加成套或灵活的操作系统，进而超越其作为一个基础设施平台的作用。我们看到，开发者和架构师们正在使用Linux建立新一代解决方案，创造出新一代的企业架构。”这些工作中的大部分已经开始付诸实施，他说道，包括“云计算、大数据、移动领域以及社交网络等多个方面”。

Gillen也同意上述观点，Linux“即将成为公共云基础设施中非常关键的一个部分，由此，Linux确保了它在现代工业中能够长期发挥作用。”

Baker说道，“Linux已经在运行着云业务，这是毫无疑问的，它需要巩固自己作为基础设施平台的位置 —— 这意味着它需要时刻保持最新的技术领先优势，例如ARM服务芯片、超大规模集成电路、网络设计，以及所有的软件设计数据中心。”上述这些工作应当可以作为开源系统硬件设计（例如开源计算机项目）的有效补充。

Linux体系：提交、审核、采纳

伴随着正面需求不断增长，Linux的开发进程也在不断加快。

Linux作为普遍存在的基础设施元素，其中一个潜在的缺点就是它有可能成为商业化的制度产物，正如曾经它所取代的闭源Unix们。但是Zemlin认为，Linux极大的灵活性在这方面发挥了作用：“十几年前，如果你问到Linus Torvalds或其他社区成员，Linux是否会比其他任何平台都要更多的装到移动电话里，他们当然会说‘不会’。所以，我们要做的只是注视Linux的发展，不要尝试去预测它，因为所有的预测几乎都会是错误的。”

另一个重要的未来发展方向，就像上面提到的，“独立于Google之外，在移动领域有更大的发展，”Baker如此预测道。像Mozilla专门针对移动电话的Firefox操作系统项目，就是这样一种典型的尝试，尽管在Google的存在下，以及Android如此巨大的市场份额面前，其成功的几率并不明朗。

最后，最关键的问题，谁将担负起指引Linux未来之路的责任。因为Linux可以由其他人任意复制(fork)并开发，历史证明，拥有单一核心开发团队对于Linux来说是最好的，同时要求基于该团队的所有项目，其核心都能贯穿始终。

这样核心团队能够承担更多的责任，以推动Linux弥补现有或将来可能出现的不足，避免闭门造车式的技术封锁，最终使Linux成为它最应该成为的样子。

如果Linux的未来真的无处不在，现在没有人能够想象得到它会是什么样子 —— 这是一件好事，难道不是吗？

via: http://www.networkworld.com/news/2013/101513-the-future-of-linux-evolving-274829.html

译者：Mr小眼儿 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出