# 为什么是 Unix

让我们暂停一下，回顾这六年的实验，思考为什么 Unix 能如此受国际学术界的欢迎。Unix 究竟有什么东西让这么多人喜欢？

在 CACM 论文的开头，Ritchie 和 Thompson 列出了系统提供的六个特性：

> * (i) 包含可拆卸卷的层次文件系统，
> * (ii) 兼容的文件、设备和进程间输入输出，
> * (iii) 启动异步进程的能力，
> * (iv) 可按用户选择的系统命令语言，
> * (v) 一百多款子系统，包括十几种语言，
> * (vi) 高度的可移植性。

让我列举一些我喜欢的 Unix 特点：

* 可在多种平台上使用
* 多用户支持
* 提供目录层次结构
* 合理共享计算机资源
* 支持文件、进程和程序的操作
* 支持进程间及机器间通信
* 能访问其操作功能

Rudd Canaday 简单地说过：“Unix 在贝尔实验室传播开来，是因为人们喜欢使用它。”最近，Armando Stettner 说：“它不会妨碍自己，也不会妨碍我。”

在 1976 年和 1977 年，Tom Lyon 使得 Unix 的部分功能能够在普林斯顿大学的一台 IBM 360 上运行的 VM/360 系统下运行。1977 年和 1978 年期间，Ritchie 和 Steve Johnson 将 Unix 移植到 Interdata 8/32，同时 Richard Miller 和他的同事们也将 Unix 移植到澳大利亚卧龙岗大学的 Interdata 7/32。Ritchie 曾说，将 Unix 移植到 Interdata 是他最引以为豪的编程工作之一。它证明了 Unix 确实可以被移植到一台非 DEC 生产的机器上。对此我稍后会回到。

简单地说 Unix 有这个功能或那个功能，或者它可以运行在一个某个部门（而非计算中心）负担得起的机器上，是太表面化了。让我来讲讲 Mike O'Dell 的回忆，他现在是 UUNET Technologies 的副总裁，回忆的是 1974 年夏天。当时，O'Dell 还是俄克拉荷马大学的本科生。

> 当著名的 1974 年 ACM 通讯期刊发布时，我正在俄克拉荷马大学计算机中心工作。我们有一个叫 ITF（间歇终端设施）的东西，它拥有世界上最烂的 BASIC 实现，其中一个人写了一些例程，能让你在终端上进行输入输出——这是一个不小的成就。所以我们一群人坐下来，试图弄清楚是否能做些有趣的事，比如用 IBM 2741 终端作为打孔机来编辑。这样你就可以编辑作业并提交，诸如此类。我当时正全身心投入这件事——我记得我的黑板上满是数据结构，因为我们把所有东西都建进了文件里，因为我们当时还不知道更好的方法。
>
> 那期关于 Unix 的期刊来了。我记得走在走廊上，从我的信箱里拿出它，心里想着：“哦，ACM 出了一些关于操作系统的东西，或许值得一读。”（那期是“第四届 ACM 操作系统原理研讨会论文集”）。我开始翻阅那期杂志，里面确实还有一些其他不错的论文。但我记得自己坐下来通读了那篇关于 Unix 分时系统的论文。那感觉就像是被石头猛击了一下脑袋。我又读了一遍。然后我站起来，走出办公室，转过拐角去找乔治·梅布里，他是我们当中参与那件事的另一个人。我把那期杂志甩在他桌子上，说：“怎么会有这么多人，这么久以来都错得这么离谱？”
>
> 他问我：“你在说什么？”
>
> 我说：“你读读这个，然后试着告诉我我们一直在干的事不荒唐。我们简直疯了。这才是我们真正想要的。”就在那一刻，我下定决心，无论如何我们都得搞到一个这样的系统。

事实上，O'Dell 之所以对此着迷，其中一个原因是，在俄克拉荷马大学电气工程实验室的一个角落里，有一台 PDP-9，这是一台与 PDP-7 关系密切的机器。O'Dell 读到 Ritchie 和 Thompson 最初是在 PDP-7 上完成他们工作的消息后，便开始思考是否可以在 PDP-9 上运行这个神奇的系统。O'Dell 告诉我：

> 我说我们没有 PDP-11，但我们有一台 PDP-9，能不能搞到 PDP-7 的版本然后移植一下？Dennis 说他觉得那不是个好主意（在那时候，他们可能已经觉得电话那头是个疯小子了）。但他们态度非常友好，所以我备受鼓舞。我下定决心，我们一定得搞到这样一台机器。
>
> 于是我就这么一边天真一边厚脸皮，打电话联系了 DEC 在塔尔萨的销售办公室——俄克拉荷马城还没有销售处——请求和某位负责 PDP-11 的人谈谈。我联系上了一个叫 Stan Bartel 的家伙，他是销售员。
>
> Stan 是那种脚踏实地的人，他明白自己从来没能把一台迷你计算机卖进 OU——“蓝色死神”对一切掌控太严了——但他也知道让计算中心有个狂热分子也许不失为一个机会。而那时候 DEC 的销售员拿的是工资不是提成，所以对他来说没什么损失（现在他们也还是不拿提成）。正好他过几周要来我们这边出差，就中午顺便过来，带了一整摞手册来：处理器手册和外设手册。我从未见过这种文档。于是我通读了这些手册——我那时是个相当不错的程序员——读完指令集后我说：“这些家伙真懂行，这真是太酷了。”从那时开始，一切就这样开始了，我彻底入坑了。

正如我先前提到的，《C 程序设计语言》直到 1978 年才出版。那时候，身在俄克拉荷马州这类“边缘地带”的人该怎么办？我还是让 O'Dell 来讲述吧，因为他的经历与 1974 到 1978 年间许多其他人的故事非常相似。

> 我初次接触 C 语言，其实是通过伊利诺伊大学。Steve Bunch 从 OU 转到了 UIUC（伊利诺伊大学厄本那 - 香槟分校）。我们去那儿朝圣了一趟，也见识了 Unix……Steve Bunch、Steve Holmgren 和 Mike Mullen……就是那批把 Unix 接入 ARPANET 的人。总之，Steve（Bunch）给我寄了一份智能终端内核的清单，内容包括上下文切换器、控制信号量的键值代码、进程间通信机制，以及一两个其他片段。总共大概五六张纸。他还在边上写了点注释，因为我从来没见过这种编程语言，他解释了像“++”这种奇怪的操作符是干什么的。他说：“你看看能不能搞懂这些东西是怎么工作的。”我记得那个上下文切换器大概只有六行汇编代码，他把它寄给我，基本上就是想看看我能不能弄懂。而我确实搞懂了。
>
> 后来，我想更深入了解这些东西，于是他给我做了一卷 tp 磁带——那是 tar 诞生之前的事——用的是旧的 tp 格式的磁带，里面是以 nroff 输出形式保存的 man 手册页。他把这卷磁带寄给我，还说：“这里面有些有趣的东西，如果你能搞清楚怎么把它打印出来的话。”他还把真正的 tp 的 man 手册页也寄给我了。
>
> 于是我坐下来，基本上用了一个长周末，写了一款……程序来解析那个格式，正确显示下划线，并打印出 Unix 的 man 手册页。那就是我第一次接触的 man 手册页。我估计现在某个箱子里还留着它们，因为我从未像这么努力地去获取过什么东西。
>
> 然后我们开始传阅这些 man 手册页：虽然我们拿不到系统，但我们能看到它的功能。就是在那个时候，我真正被吸引住了。

自学。自己弄明白。你觉得它应该怎么工作？Mike 并不是孤单一人。RAND 编辑器的创造者之一 Dave Yost 告诉我他是如何看一段代码的（在七十年代中期）：

> 于是我坐下来仔细看，看到那些花括号 `[{` 和 `}]`，我心想，“哇！”

在 C 语言中，`{` 和 `}` 包围构成函数的语句块。C 语言没有 PL/I 的 DO-END，也没有 Algol 或 Pascal 的 begin-end。在很多方面它是一种更简单的语言，更像一种自然语言（比如英语）。它并不是一种“非常高级的语言”。正如 Thompson 和 Ritchie 所说：“C 语言是一种通用编程语言，具有表达简洁、现代的控制流和数据结构，以及丰富的运算符集合……根据我们的经验，C 语言被证明是一种愉快、富有表现力且多才多艺的语言……”根据我的经验，C 语言也适合写出风格优雅的程序。

USENIX 技术会议上，他谈到了“简单、连贯且强大的计算模型”；“工具箱的隐喻”；以及可移植性。

其中第一个和最后一个尤为重要：Unix 和 C 语言在多个平台上的可用性以及其优雅性，是系统流行的重要原因。风格和工具则是系统的其他重要组成部分。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://book.bsdcn.org/unix-si-fen-zhi-yi-shi-ji/shi-shen-me-rang-unix-cheng-wei-unix/11-why_unix.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.