技术奇异点

睡眠这个功能在计算机上出现很久了。我第一次和『睡眠』打交道是 96 年 —— 那年高考结束买了第一台能运行 Windows 95 的机器。遗憾的是，这台机器睡眠再被唤醒之后所有窗口的滚动条（scrollbar）都行为怪异 —— 只能支持拖动，不能支持在空白处点击来翻页。

这以后我发现『睡眠』实在是一个名存实亡的功能。总是有那么一些必用的软件在睡眠唤醒之后行为怪异。用了 Linux，睡眠更是不用想了 —— 平平常常的对硬件的支持还磕磕绊绊的呢。再说我用 Linux 是为了 hack kernel，自己编译的 kernel 这方面的问题更多。所以每次装完系统，不论是 Windows 还是 Linux，第一件事情就是把硬盘休眠和计算机休眠关掉（屏幕休眠还勉强可以保留）。

用 MacBook (Pro) 有一年多的时间了，最近开始不时尝试把屏幕合上享受一下为地球减少二氧化碳排放的感觉。因为硬件和操作系统都是 Apple 一家控制，还真没发现什么功能上的问题。不过今天在咖啡厅着实又麻烦了一把。每次休眠唤醒之后，都要重新输入一遍咖啡厅网络的密码（那个密码是用 Web 页面输入的，不是 Wifi 的密码，所以还没法保存）。然后就是 Tor 也要重新连接一遍（这几天 60 大庆，Tor 的连接也是磕磕绊绊，本来就心惊胆战。我本来就对 Tor 的重联功能不放心，先在又和咖啡厅的网络密码验证有竞争，结果是 Tor 的出错信息一团糟）。

看来工作的时候打盹确实不是什么提高效率的好办法。

这篇文章让我不得不摘录下来：

Steve Jobs 第一次见到 Don Knuth，热情洋溢的说『您的大作我都拜读过。』Knuth 当头一棒『胡扯！（full of shit）』

入手 MacBook Pro 整两周了。这段时间，尤其是这周，几乎所有的时间都花在技术以外的事务上。当然每天读的新闻里还是 IT 新闻占绝大多数，不过除此之外新机器几乎没有用来研究技术。这也不算背离我买机器的初衷 —— 购买之初就已经知道近期花在技术上的时间不会太多。当初买第一台 MacBook 的时候，也是因为非技术的原因 —— 读二战史的时候查阅 Wikipedia 发现 OS X 显示的 Wiki 页面比 Windows 好看好多。

使用 15 寸的高配 MacBook Pro 来做非技术的事务是很舒适的。第一点就是『快』。机器的速度由硬件和软件共同决定。MacBook Pro 15 寸高配的硬件规格是不错的。这倒也不值得特别夸耀，毕竟是将近一万八的机器。市面上相同规格的 PC 笔记本要便宜不少。不过要注意的是，规格相同的 PC 比 Mac 价格便宜的例子不少，而相对的例子——价格相同的 PC 规格更高——是很少的。个人认为原因是按照 PC 的硬件规格/价格比线性发展的话，一万八的机器肯定过于变态，普通用户根本用不上，作为移动设备就更离谱，只会出现如联想双屏笔记本这样的鸡肋怪物 —— 用户对电脑的要求不是简单的硬件功率的堆砌。从这方面说，PC 笔记本只能突出自己价格便宜，但是没办法超越这个硬件档次了。虽然高配的硬件不值得过分夸耀，不过 Mac 的价格也毕竟不是全算在硬件上，而且全铝机身这类噱头也还令人满意，所以硬件方面还是物有所值。

软件方面，Snow Leopard 号称很多操作都比 Leopard 性能提高20% – 50%。最近在新 MacBook Pro 的 Safari 上使用 Net App 比较多（主要是 JavaScript 实现），感觉比在 Dell 390 上的 FireFox 流畅不少（主观感觉似乎比办公室里跑 Leopard 的四核 Mac Pro 还好，这个只能等抽空把 Mac Pro 也 upgrade to Snow Leopard 之后再客观评判了）。加上独立显卡，Expose 和其它窗口管理效果都流畅不少，多个程序之间切换的感觉也很舒服。

第二点是易用性。值得一提的是新的 Expose。作为为数不多的 UI 改进里最明显的一个，Expose 是彻底阻止我返回 Leopard 的决定性因素。新的 Grid 排列在美感上不如原来的按比例随意排列，不过确实让查找程序窗口更容易了。真正使用 Snow Leopard 之前我认为自己肯定会怀念按比例随意排列，用了 Grid 排列之后也只能说舍弃按比例排列的美学享受也算是必要的代价，算是在不能兼得的二者里选了稍强的一个。另外把最小化的窗口和普通窗口同时排列在一起，让用户终于在一个地方就能浏览所有打开的窗口了。其实 Expose 和 Dock 的集成，配合上原来的窗口 hide 功能，可以比较方便的找到各个窗口，也不会让桌面过于凌乱，让窗口最小化这个功能都几乎可以不用了。

Stack 的改进也正在点子上。首先是不论 stack 里有多少 item，stack 展开的时候都不会变成 Leopard 里那种普通 menu 的形式，而是保持一个比较大的图标。这样对 Application 这样的 folder 来说，查找图标更容易了。而且，进入 stack 里的下一级 folder 也不会离开 stack 状态，对于拥有一到两级 sub-folder 的 stack 来说，再也不会打开一堆 Finder 窗口的。原来在 Leopard 里，对于 Application/Utilities 下的应用我一般都借助系统菜单里的『Recent Items』打开 —— 副作用就是必须把 maximum recent item number 从缺省的 10 调大。在 Snow Leopard 下我很少用『Recent Items』了。新的 Expose 和 Stack 让 Dock 的使用频率更高，一个副作用让 Dock 的放大效果的实用价值显得低了一些。打开放大效果之后， Dock 总是晃来晃去，在 Leopard 下不觉得，在 Snow Leopard 里 Dock 的使用更频繁，加上展开后的 stack 和 menu 也跟着晃，弄的我第三天就把放大效果关掉了。

昨天注意了一下 OS X 上的 PC Server 图标，是一个 blue-screen-death。很有趣。

64 位支持是 Mac OS X Snow Leopard 操作系统最重要的新特性之一。这往往让人以为 Apple 是初次提供 64 位支持。其实 OS X 的 64 位支持从 Tiger 开始就默默存在了。Apple 一贯的风格是做得多说的少 —— 能把 x86 架构的 OS X 研发保密达 5 年之久，它最喜欢在发布会上宣布的消息是『available now』。

64 位支持并非从 Tiger 开始就一步到位。否则的话，Leopard 和 Snow Leopard 有固步不前之嫌，Apple 对 64 位支持保持 4 年的市场宣传沉默也显得毫无必要。下面这幅图说明了 OS X 系统 64 位支持的发展路径。Tiger 仅仅支持没有 GUI 的 64 位应用，Leopard 仅仅在 user space 提供 Cocoa 的 64 位支持，没有 64 位 kernel。而且这两者都仅仅提供系统级的支持，附带的应用仍然都是 32 位。Snow Leopard 的 64 位达到成熟，附带的应用几乎全部为 64 位，并且提供 64 位 kernel（尽管不是缺省设置）。

有意思的是，OS X 系统在 64 位上循序渐进的发展策略，正好有意无意的遵循了 UNIX 的设计文化关于 GUI 的设计的原则。《The Art of UNIX Programming》在第 11.6 章讨论 UI 设计之前就开宗明义地宣布『UNIX 没有发展出本土的 GUI 设计模式』。确实，UNIX 在这点上保持谦逊，向 MacOS（这里指classic）、NeXTStep和其它 GUI 的先行者借鉴了许多经验（以及后来的 OS X 与 UNIX 的相互借鉴）。不过随后在第 11.6.8 节指出了 UNIX 在 GUI 方面还是发展出了一个最基本的准则 —— 『界面和引擎的分离』。UNIX 提倡把尽可能多的代码放到没有可见 GUI 的进程中（即引擎进程），提供 GUI 的进程和引擎进程通过 Application Protocol 通信。引擎进程一般不与用户直接交互，但是很多引擎程序也提供让高级用户直接调用的接口（比如 CLI 命令）。这样做既符合 UNIX 通过协作的多个进程来降低整体复杂度的原则，还让程序能够同时满足初级用户和高级用户的不同使用习惯。甚至程序本身的自动化测试也更为方便。现实中很多程序都在实践这一原则，比如我们每天都用的 P4V，它本身的 GUI 并不实现和 Perforce server 的通信，而是调用 Perforce 的命令行客户端程序。这样即满足了初级用户，也让高级用户了解 GUI 操作对应的都是哪些命令，方便了 trouble shooting 和重复操作的自动化。设计良好的引擎进程还允许第三方开发更好的或者满足特殊用户需求的 GUI。

如果一个系统无法在一个 release 中实现完全的 64 位支持，那么应该如何决定模块 64 位化的先后顺序呢？以上面的 UNIX 原则为依据来决定的话，就正好是 OS X 系统对 64 位支持的实现顺序（尽管也许是无意的，但是我相信 Apple 内部的 UNIX 大牛们有此特意的考虑）。首先提供对 GUI-less 进程的 64 位支持。这样在界面引擎分离的系统中，引擎部分可以首先 64 位化。其实 64 位化带来的性能和可扩展性（scalability）的改进对于界面进程并没有太大影响，而急需此类提升的引擎进程正好可以先一步利用系统的优势。

到了今天的全 64 位 Snow Leopard 系统，除了安全和整体复杂度的考虑，界面引擎分离的原则是否在 32/64 位架构方面还有作用？仍然有。比如，Dropbox 是一个保证文件在多台机器上同步的程序。它由一个提供同步功能的进程和一个 Finder plug-in 构成。Finder 由 Cocoa 重写并且升级为 64 位之后，plug-in 停止工作，所以无法使用 Finder 右键菜单中的 Dropbox 功能，但是提供同步功能的进程仍然可以工作。Dropbox 的引擎界面分离让失败降低到最小的程度。Safari 升级到 64 位之后，很多第三方的 plug-in 仍然没有来得及跟进。但是这些 plug-in 的重要性让 Apple 没有办法说服用户以抛弃它们为代价享用 64 位。所以 Safari 采取了一种特殊的界面引擎分离。把 32 位的 plug-in 放置在单独的、32 位的虚拟 Safari hosting 环境的进程中运行。这些 32 位虚拟 Safari hosting 进程和 64 位的 Safari 通过 application protocol 通信 —— 称之为 out-of-process plug-in。即便如 Flash 视频这样的应用，以今天的硬件性能来通过 IPC 在两个进程间传输数据也无损用户体验。这样做在满足了 32/64 位架构兼容的同时也提供了进程协作的一贯好处 —— 安全、稳定（单个 plug-in 崩溃不会影响整个浏览器）和易于维护（容易定位 bug）。即便今后有 64 位 plug-in 出现，这些好处仍然会促使 Safari 和其它应用采用 out-of-process plug-in 技术。

Snow Leopard 引入 64 位 kernel 也让另一个利用普通进程技术的优势体现出来。TOR（洋葱路由）基于 SOCKS Proxy 技术，所以它的 client 端实现是一个监听特定端口（一般是 9050）并提供 SOCKS 服务的普通进程。Cisco VPN 基于虚拟以太网技术，所以它的 client 端实现是一个虚拟的网卡驱动，运行在 kernel space。当 kernel 升级为 64 位而 Cisco VPN client 无法跟进的时候，用户只好放弃使用其一 —— 退回 32 位 kernel 或者不使用 VPN。而基于普通进程的 TOR 则不受影响。同样，基于普通进程的 SSH tunnel 技术也不受 kernel 64 位升级的影响。同样是提供加密的传输功能，基于普通进程的技术显示了灵活性。

计算机系统各个部分的发展永远呈现不同步的状态。OS X 的 64 位化过程清晰而富有趣味性的重申了这一点。软件应对这一永恒趋势的唯一手段就是把自己分割成一个个功能简单，可以独立替换，甚至在某些其它模块缺失的时候仍然可以正常工作的模块。这是 UNIX 的基本设计原则之一，利用 application protocol 进行协作的进程就是 UNIX 实践这个原则的工程传统。那些在 Tiger 上就利用了 GUI-less 64 位支持的程序、那些在 Leopard 上来不及把 GUI 升级为 Cocoa 的程序、还有 Snow Leopard 上的各种成功和失败的例子都在重申这一原则的重要性。UNIX 诞生于资源奇缺的计算环境。因此演化出『沉默是金』这样的传统（尽管今日沉默是金是因为有了其它的优势而被遵守）。但是同时也顽强的保留了多进程协作这样看似『奢侈』的传统。不能不惊叹于 UNIX 文化的预见性和适应性。

今天在 MacBook Pro 上检查以前备份在光盘上的数据，发现有些明明有数据的盘放进光驱之后 OS X 就报告『插入新盘，刻录、弹出、还是忽略』。大惊失色！但是同时期刻录的盘里大多数还是能读的。而且被错认成空白盘的光盘无论放进去多少次都是一样失败。想想不可能人品这么差，新买的硬件就出问题。而且就那么几张稳定的被错认，更像是光盘格式的问题。

仔细想想到底自己做过什么离经叛道的事情。于是把 Boot.plist 里的『arch=x86_64』删掉（见《终于 Pro 了》）。重启之后，被认错的盘又被正确读出了。看来问题在于 DVD 光驱的 64-bit driver。检查了 DVD 光盘，发现在 64-bit kernel 状态下错认的盘和能读出的盘都有 DVD+R 格式的。本来怀疑是 DVD+R 和 DVD-R 的差异，现在被排除了。可能是 64-bit DVD driver 不支持一些更细微的格式差异，比如一次写入和多次写入，不过已经没有时间细察了。

Apple 的 64-bit kernel 支持确实还没有成熟。所以 Apple 把 Snow Leopard 的缺省启动设置成 32-bit kernel。希望 Apple 能在以后的 update 中赶紧完善。不过总的说来我大概两三天才用一次光驱，所以把还是可以把缺省 arch 定为 x86_64 —— 除非又发现了别的 break。

从三里屯 Apple Store 把15寸高配的 MacBook Pro 买回来了。

因为新系统刚刚发布，硬盘上还没有来得及预装 Snow Leopard，所以开机还是 Leopard。第一件事情是把包装里附带的 Snow Leopard 装上。启动之后按住『6』和『4』。进入命令行，运行『uname -a』，终于看到期盼已久的『x86_64』。

大部分程序运行得还好。少数几个底层的应用挂了。Dropbox 的 Finder plug-in 挂了，不过目录同步功能还正常。Cisco VPN 在 64-bit kernel 下挂了（不过还能在 32-bit kernel 下运行）。基于 socks proxy 的 TOR 运行的不错，幸亏翻墙没有只靠 VPN。看来还要有段时间工具的开发者们才能完全释放 64-bit 的功能。

值得一提的是音响。我有一对『看起来像木头外壳』的有源音箱，跟了我八、九年。在家用 MacBook 的时候还是每次都要插上，因为明显比 MacBook 自己的喇叭好听。换成 MacBook Pro 之后已经感觉后者自带的喇叭音质和前者没什么区别了。甚至连音量都不逊色。

Update: 09-03

启动进入 64-bit kernel 应该不需要每次按住『6』和『4』了。修改 /Library/Preferences/SystemConfiguration/com.apple.Boot.plist，加入

Kernel Flags

arch=x86_64