林健的BLOG

　　几年前我从《The Art of Unix Programming》上听说过 Plan 9 from Bell Labs 这个概念操作系统，当时也没有太在意这东西。最近又在组里的讨论中偶然听到了它，于是决定一试。从官方下载了 LiveCD，在 QEMU on Ubuntu 和 VMware Player on Windows 下跑起来都是顺畅的，安装过程也比较简单。

　　基本命令不用多说，只是它的 rc shell 在 GUI 下用起来挺不爽的，鼠标和光标定位烦琐。比较有趣的是它的两个文本编辑器：Sam 和 Acme，它们也是 Plan 9 的推动者 Rob Pike 大牛亲自打造的。通过 TAOUP 的介绍得知这两个工具都比较强调鼠标的使用。不看手册，凭借已知的 ed 命令，我还是基本明白了 Sam 的使用。不过这个 Acme 还是有点诡异，仅仅是保存文件就让我折腾了半天。尤其是它对鼠标中键（滚轮）的使用还真能让人练脑子。
　　至于 Plan 9 上的 C 开发，我满以为和一般的 *nix 系统完全一样，然而写了一个 Hello World 之后才发现找不到编译器，查了一下在线的 man，原来 cc 根据机器体系结构的不同细分为了 2c、7c、8c、kc 等，在 x86 下应该使用 8c。然后编译时 printf 函数竟然也能报错，google 了一下才找到了 Rob Pike 的这篇说明。阅读后得知目前在 Plan 9 下写程序还是有一些讲究的，语言、库和系统调用都与现行标准有一些差异。
　　我下一步可能会看看 Plan 9 的统一文件接口、全局资源命名机制和标准通信协议，这些可能是同我的研究方向相关的，毕竟它们都是服务于网络计算环境的。
　　Plan 9 目前的活跃度似乎不是很高了。已经它出现多年，但网上相关的中文文献还是凤毛麟角。正如 ESR 所说，Plan 9 作为一个产品，其革命性是不足的，因为现在的 *nix 已经“足够好”了。但 Plan 9 提出的各种思想正在被其它 *nix 所融合。在网络计算的时代，网络元素应不应该、应该如何原生地融入计算机体系结构和操作系统，这是一个值得探讨的方向。

　　以前研究Windows的基本概念时，我就知道它有一个POSIX子系统，可以在Windows下编译运行使用了POSIX库的程序。但这一直停留在书本概念层面，直到昨天看到Jeep同学的Windows系统上安装了一个Subsystem for UNIX-based Applications时，我便决定也安装试用一下。
　　有关Windows的POSIX子系统是什么、怎么用的问题，可以参考Wikipedia或Microsoft TechNet [英文][中文]上的介绍。它历经了NT时代的Microsoft POSIX subsystem、XP/2000时代的Microsoft Windows Services for UNIX (SFU)以及2003 R2/Vista/2008时代的Subsystem for UNIX-based Applications (SUA)等版本，对POSIX标准的支持日臻完善。我的系统是来自MSDNAA/IEEE的Windows Server 2008，自然要使用最新版的SUA。至于SUA和cygwin在实现机理和功能性能上有什么区别，我还没有仔细研究。但从直观感觉上，Windows原生支持的SUA是比cygwin快一点儿；按照Wikipedia上的这个说法，cygwin是对POSIX是“partial”兼容，而SFU/SUA则是“full”兼容。
　　很多人安装SUA的目的并不是要向Windows移植什么重要的UNIX/Linux应用，有时候我们仅仅是为了在Windows中使用一个类UNIX的Shell以及丰富的GNU utilities，毕竟这类久经考验的命令行工具比Windows Command Prompt的那些命令好使很多。对于工作环境要求在Windows和Linux间来来回回切换的人们，也省得敲错命令。安装SUA之后，预装的Shell是C Shell和Korn Shell，还安装了包括vi、gcc在内的300多个命令行工具。同时，Windows的Path环境变量中自动添加了SUA相关目录，这样在Windows Command Prompt和Power Shell中也可以使用很多GNU utilities了。当然，UNIX Shell的内部命令是不可以在这里使用的。此外，在Power Shell中，Power Shell命令别名（如ls、cp）会优先于同名的GNU utilities调用。总之，使用SUA或cygwin这类UNIX Shell+GNU utilities的模拟环境，相比手工添加的“容错”命令或者GnuWin32这类独立命令级的移植要“真实”和顺手得多，但缺点就是体积庞大。
　　为了检验SUA的能力，我拿我相对熟悉的GNU bash做了实验。从官方下载bash-4.0版源代码，在SUA的C Shell环境中解压，运行./configure通过。但在make时报错：

　　查看execute_cmd.c源代码，发现这句代码有注释：

　　看来这个struct timezone不是POSIX标准的东西。通过上下文，我发现这里是处理time（计时）关键字的函数。于是查看configure的帮助，得知只要加一个“--disable-command-timing”参数即可禁用time关键字（这时输入time将改用/bin/time程序做计时）。再次make，execute_cmd.c通过，但又出现以下错误：

　　查看./lib/sh/getcwd.c的源代码，果然没有找到MP_RMDOT宏的定义。在全部源代码中搜索，发现这一定义在externs.h中，在./lib/sh/makepath.c中也有使用，唯独在./lib/sh/getcwd.c中使用了却没有引用其定义。也许这是bash-4.0的一个bug？使用Linux下的gcc编译连接是通过的，但SUA下的gcc版本也许有更严格的名字连接策略，导致无法编译通过。于是我将“#define MP_RMDOT 0x04”的定义手工加入./lib/sh/getcwd.c，再次make，全部通过。实验运行无误！
　　需要注意的是，SUA提供的是编译和运行使用了POSIX库的程序的环境，并不提供UNIX二进制文件的运行支持。它编译生成和支持运行的可执行文件仍然是Windows的PE格式，而不是ELF之类。SUA支持的只是仅使用了标准库和POSIX库的程序的源代码级移植，对于使用了Linux等环境特有的系统调用的程序，也不可能不加修改地编译运行。
　　有空再研究一下SUA在我们的工程中能有什么实际点的应用。

　　下午参加了在我们研究生院举办的龙芯 & Linux周日体验活动。说实话，收益不大。本来想多了解一些龙芯的东西，去了才发现演讲成了几家赞助商的秀场。几个演讲的主题相对分散，一些演讲者事先准备并不充分，有效信息不多。
　　活动中得到的最有意义的信息是：我用了两年的Unix-Center.Net原来是蒋清野先生一手创办的，并由他个人承担其每月数万元的机器托管和网络流量成本。我们不得不佩服蒋先生的做事风格。实现*NIX与开源技术平民化是他的理想。在具备了一定的经济实力之后，又有多少人能够真正实践这种公益的、不图回报的理想呢？况且推广*NIX技术本身不是一项面向弱势群众的、能直接带来社会效应的工作。然而蒋先生觉得只要能为*NIX与开源技术的初学者和爱好者们提供这样一种零成本的实验环境，就是在为这个领域尽己所能地添砖加瓦，这项工作就是有意义的。是的，我们看看开源与自由软件领域的诸位前辈，他们不都在通过无私的奉献来实现自己的梦想吗？我们需要那些为一个领域的发展提供基石的科研人员，同时也需要这些通过各种渠道使技术走出实验室、将理念变成现实、推动生产力发展的奉献者们。
　　尽管Unix-Center.Net是一个沙盘，像一个游乐场（蒋先生的比喻），不能为生产性应用产带来直接的价值。但它为计算机专业学生、程序开发者和相关技术人员开辟了一条基于*NIX和开源技术的新思路，其潜在的、间接的影响力是不可估量的。