技术奇异点

睡眠这个功能在计算机上出现很久了。我第一次和『睡眠』打交道是 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

最近常用 proxy。不过 proxy 的速度比较慢，所以经常要在用和不用之间切换。FireFox 有些组件能做到快速切换，不过用起来也不太方便。而且我发现有些网站用 FireFox 显示的不如 Safari 效果好，比如《华尔街日报中文》和《牛博》。

好在 OS X 秉承了 UNIX 的优良传统，事事都有命令行操作：

设置 proxy：
networksetup -setsocksfirewallproxy <service> <proxy> <proxy_port>

取消 proxy：
networksetup -setsocksfirewallproxystate off

开一个 terminal 在旁边，切换速度比 FireFox 插件还快。

Xcode 缺省使用系统所有的 CPU 来编译，也就是说，会最多同时启用和系统中 CPU core 数量相同的进程来编译。如果希望限制 Xcode 使用的并发进程数，可以如下修改配置：

defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 4

看来 Xcode 使用的最大进程数是安装的时候由 installer 计算的。

《Mac OS X的字体》发布之后，甫鸼提出了一系列质疑。当然他没有否认很多人认为《Vista puts Mac OS X font rendering to shame》的作者是微软的枪手（不过修辞十分诡异），但是回避了自己对该文的看法。

我对Mac OS X的字体确实有所偏爱，周围的很多人此的看法与我不同。其实当下有多少人与我感觉异同的重要性在其次，我更希望搞明白的是人们做出偏爱Windows的判断有多少成分是出于习惯，有多少是出于（潜意识中的）深层次原因。但是这个问题并不那么好回答。

《Vista puts Mac OS X font rendering to shame》（并非原文，而是附带的评论和调查）的意义在于给这个问题添加了一个可信度很高的旁证（尽管由此得出确定性的结论还显轻率）——62%的参与投票的人更欣赏Mac OS X的字体渲染效果，也许可以一定程度上说明身边人的不同看法在于这些人群接触Mac的比例还是不如北美高；及评论中给出的各方面解释，很大程度上说明从深层次原因看还是Mac OS X的方式更有优势；综合说来，很多偏爱Windows的判断中武断的习惯的成分更高一些。搞清楚这个一方面满足了我的好奇心，一方面也是对未来的一种预测——基于习惯的选择往往会逐渐让位给基于其它本质原因的选择。（当然有些习惯的力量是巨大到无法改变的，比如键盘的QWERT排列。不过Mac OS X已经取得的9%的份额让我相信关于字体渲染的习惯没有巨大到无法改变。）

下面讨论一下甫鸼的疑问。第一是显示器分辨率的提高能否“自动”减轻Mac OS X字体边缘发虚的问题。首先说明，这里的分辨率不是像素数，而是每英寸像素数。所以iPhone的屏幕虽小，分辨率却高于大多数LCD的分辨率。在解释“能”与“不能”之前，重申一点，边缘发虚是一个缺点，但是在无法达到完美的计算机方案中称其为代价更加合适，而《Mac OS X的字体》已经解释了这种代价是合理并且值得的。也就是说，即使这个问题还停留在今天的程度，对于字体渲染的整体优劣也并无影响。

下面说说这个问题能否被“自动”减轻，首先举两个例子，第一是《Vista puts Mac OS X font rendering to shame》的评论2.2.1.1.4，在评论者的旧CRT显示器坏掉之后，他为自己的旧Mac接上了新的LCD，同样的硬件（除了显示器），同样的渲染算法（苹果从Mac OS 9就采用的），在接上新LCD之后字体的效果焕然一新；第二是很多人使用了iPhone之后，都感觉iPhone的显示效果比LCD要好；而且当整个大页面缩小到小于iPhone屏幕的时候，虽然不适合阅读，但是页面的布局和整体效果是不错的，而且很多情况下单个字体仍然可以分辨，而基于Windows CE的设备在相同的比例下字体已经完全不可辨认。

例子就是例子，我不想用两个例子就粗暴的泛化到一般情况，但是实例也有其独特的说服力。另外从推理的角度看，重视准确度的渲染方案和一般图形的渲染方案相比原则上更为一致。一般图形的反走样算法也是重视准确度的。也就是说，在Mac OS X上对一条普通贝塞尔曲线的反走样（anti-alias）算法基本上与Mac OS X上一个字型上的贝塞尔曲线的渲染方法是一致的。而Windows上对字型的处理是区别于一般图形的，你不可能把Windows对字型的那种强行修改以适应显示器像素的做法应用到普通的斜线或是曲线的反走样上，所以Windows的字型渲染在Windows的整体图形方案中是ad-hoc的（从《Mac OS X的字体》的截图中，IE对于日文字体中的斜线的处理可以看出，如果真的把Windows的字型渲染方式应用到斜线上是多么恐怖——因为日文假名中存在比较明显的斜线，而拉丁字母中比较少见长斜线，所以这一现象对于英语使用者并不熟悉）。

总的说来，实例说明Mac OS X的方式不经太多调整就能很好的适应显示器分辨率的提高。而推理说明，即使Mac OS X的字体渲染真的需要调整，只要借鉴普通图形方案的调整经验就好。另外，苹果始终坚持同时控制软硬件最后把关的做法也能占到先机，可以比较严格的控制Mac OS X运行的硬件平台，从而选择适合Mac OS X的显示器材。

对于字体选择的问题，很高兴Windows缺省自带的文本编辑器采用了两级管理的方式。不过Word 2007和很多其它更专业的应用似乎没有这样做：

基本上似乎是因为Windows APIs主要还是用font face来列出字体。文本编辑器自己做了归类管理。但是很多功能更全的应用似乎把精力花在了别处。高兴的是，Office 2008 for Mac的字体管理是两级的。另外在《Mac OS X的字体》中有一点没有提到，Mac OS X的字体既可以在系统级别安装，也可以为用户单独安装，这一点似乎也是Windows没有的。（由此也一窥Mac OS X的Unix血统让其多用户风格自然呈现，而Windows的单用户风格难以在短期内消除。）

接着是Safari在Windows上的字体问题。严格的说，这个不算是字体渲染的问题，因为很明显是字体的选择出现了问题。（OK，我承认我也引入了字体管理这个和渲染不相关的问题。）这个问题我得研究一下，因为手头没有在用Windows，而且还要下载Safari for Windows。不过，Mac OS X本身的字体渲染体验仍然是完美的。而且字体选择的问题终究没有字体渲染的问题那么难以修改。 🙂

最后是关于苹果软件的字体渲染功能的提供问题。上面说的字体渲染策略都是指Windows平台上和在Mac OS X上由操作系统提供的方案，准确的说在Windows平台上是GDI，在Mac OS X上是Quartz。当然一个在Windows平台上的应用选择不使用GDI的字体渲染方案也可以，那就是用GDI的低级原语（如像素）来自行渲染，Adobe Acrobat for Windows和Safari for Windows基本上就是这样做的典型例子。不用Quartz提供的字型渲染也可以，但是似乎没有Mac OS X的应用这么做。FireFox、Opera在每个平台上都是直接使用平台本身的渲染的，Microsoft Office也是如此。所以看看他们的渲染效果更有代表性。