Recently in Internet Category

今天在 comp.emacs 新闻组扫文章时，看到里面的一位大神 Xah Lee 的文章 death of newsgroups (Microsoft closing their newsgroups)，讲了一些比较著名的新闻组的人气渐渐低落以及经常被 spam 影响的事实。在文章后面还讨论了一些基于 web 的论坛和 wiki 等“新媒体”。

文章下面有两人参与探讨了这个问题。其中一位人提出说新闻组已经落伍了，如果新闻组被网页论坛取代，是一种进步；如果新闻组被邮件列表取代，则是一种退步。其中也提到了各种观点。最后一人提出了不同的想法，提出网页论坛有限制阅读的情形，其实想对于新闻组并不领先。

相对于中文新闻组来说，英文的新闻组可以说是非常活跃、令人羡慕了。以我过去的印象来看，我觉得中文新闻组可以说从来没有发展起来。可能相对于上个世纪 70 年代，今天有了太多的在线交互工具，所以对于新闻组这种古老的媒介，可能也仅仅适用于交流一下技术问题吧。我在上初中那时候（2000 年左右）还有千帆之类的服务器提供中文新闻组，到现在这些服务器早就不干了。在那个时期，针对于技术上的讨论似乎没有形成主流，那些中文新闻组里充斥着一些闲聊话题。如果中文新闻组里面主流的话题是休闲而非技术的话，新闻组相比起一些新兴的媒介来说是没有什么吸引力的。所以到后来中文新闻组里面就没有什么讨论了，自然无法逃脱关闭的命运。

英文新闻组，据我的观察，比较能形成讨论规模的，也仅仅是一些著名的技术频道。记得我第一次上新闻组时（那是在 Windows 下用 xnews），看到机器呼哧呼哧的下载那长长的新闻组频道列表时的兴奋劲是难以形容的。那种感觉就像是一扇巨大的门被推开了，门后有无数的资源等待你去探索。可当我进入一些新闻组后，却发现里面根本没有有价值的讨论，常见的只是一些 spam 了。到最后发现讨论比较活跃的也仅仅是那么几个新闻组罢了。

在我目前的大学里，有一个针对学生开放的新闻组服务器，可惜使用的人很少。我身处的计算机系理论上说是有最多的学生有可能使用新闻组的，可我在周围没有见到一个。仅有的使用着可能就是一些比较年长的教授了吧。上个学期我有一门课是一个老教授教的，他在过去教课的时候会建立一个新闻组供大家提问，我那个学期时老师统计了一下好像没有人上新闻组，于是就和其他老师一样用 nTreePoint 的网页论坛了。

我在 2008 年初的时候知道了学校的新闻组服务器，配置了 Gnus 可以登陆上去后，兴冲冲的扫描了一下新闻组列表，却找不到任何 cn.* 的新闻组。上网查了一下原因，才知道新闻组服务器在同步的时候可以设定同步哪些新闻组，北美大学的新闻组服务器大概不大需要同步中文的新闻组了，而且中文的新闻组也实在没有什么正规的讨论有同步的价值的。后来我只好四处找免费的同步中文新闻组的服务器，最后找到了 freenews.netfront.net 这个服务器，虽然说它会在你发送信息的后面加上它们的广告签名，倒是可以接受。

找到了提供中文新闻组的服务器之后，我又发现了一个问题，就是这些新闻组已经没有什么有价值的中文讨论了。后来我发现稍微比较活跃的是 cn.bbs.* 之类的新闻组，经过搜索发现是同步的 SMTH 的一些房间的讨论，而真正的在 USENET 的服务器上的中文讨论已经不存在了。而 SMTH 这个中文 Telnet BBS，它的存在我感觉有些反常，当然我不了解清华内部是如何宣传的，不过我觉得和这类 BBS 的 web 化和校内讨论媒介的单一性有一定的关系，不然怎么可能向非计算机专业的学生来介绍新闻组使用方法呢。

今天网页论坛渐渐取代了我们过去的新闻组、邮件列表等交互方式。它有它的长处，简单、管理成本低廉、更加现代。相比起新闻组，它的话题更加分布，而不是像新闻组服务器那样把无数个新闻组一网打尽。不过网页论坛也有很多地方我不喜欢，相比起新闻组来说，它在策略上更加复杂，不如新闻组那么“纯”。新闻组在贯彻“内容与格式分离”上来说更加彻底一些，而网页论坛则又各种各样的版本，相对来说更加不统一。而且最令人讨厌的是，一些不那么严肃的网页论坛的管理者喜欢弄一些分级策略，发贴攒一定积分才能浏览一些帖子，这在技术讨论上也格格不入。

另一种形式的网页论坛与新闻组更像，就是 Google Groups，因为它本身就来源于新闻组。从某方面来说，Google Groups 挽救了新闻组，它让新闻组文化更加流行。从另一方面，Google Groups 也极大的分流了新闻组的访问量，这也确实令人苦恼。Google Groups 让人人都可以创立一个自己的“新闻组”，但不能与传统的新闻组同步。有很多非常不错的中文技术讨论组，非常活跃，但可以都不是传统的新闻组。相反的，Google Groups 的邮件提醒策略可以让 Google Groups 与邮件列表更为接近。

我的 Gnus 的固定新闻组只有 4、5 个，常常访问的也只有 2 个而已。或许这方面的讨论的活跃度确实在渐渐降低，但我还是希望它能够保留，我觉得在技术讨论上它是更好的形式。

帮别人倒腾电脑真是个累活，昨天下午同学请我帮忙设定一下 Windows 的网络。他在国内买了一台新的 DELL 笔记本，装的系统是 Windows 7。

我过去帮别的朋友在 Vista 下设定网络的时候就觉得很有有心无力的感觉了。可能是因为是自从 Windows XP 之后，我很长时间没有使用 Windows 了原因，很多参数的设定都没有什么印象了。所以那次我就搞了一下午，最后也不知道是怎么弄好的。弄完了之后的感觉是想吐，恶心的要命。这次感觉也是这样。

这次的问题是我第一次遇到的，很诡异。首先是不管是有线网络还是无线网络，都无法连上。理论上来说，有线网络只要是把 cable 插上就可以直接正常联网了。可在 Windows 7 里面竟然总是说“无 Internet 访问权限”，这是我从来没有遇到过的。有线网络也是同样的情况，不管是不是手动设置 IP 地址、DNS 地址、网管，总是一句“无 Internet 访问权限”。

在网络设置中心里面找了半天，总是也无法找到相关的地方。我怀疑过和 McAfee 的防火墙有关，但那台电脑的 McAfee 安装的有问题，无法打开界面，也无法卸载。这给排查的工作带来了很大的麻烦。结果弄到最后也没有弄好，从网上搜索了一些案例也没有什么帮助。

Windows 的网络设定的设计策略让我很迷惑，从 Windows XP 到 Windows 7，我感觉这方面的设定是越来越复杂了。真不知道 Windows 到现在还是不是面对着个人电脑，一个网络设定，还弄出个什么区域的东西，实在是有些超出了普通用户的承受范围了。很多东西都不直观，如果没有经验的人估计很容易失败。

相反，在对比了 Mac OS X 的网络设置后，Windows 这方面的设计缺陷就越发明显了。我一度以为是微软的设计人员有意的往复杂化方面来引导用户，我觉得这是完全没有必要的，更是一条歧路。

都说 Windows 简单、“傻瓜”，但在网络设定这一方面，我觉得 Windows 7 走向了相反的方向。事实上，对比起我过去的 Linux 的使用经验来，当代的 Linux 发行版的网络设定也远比 Windows 7 的网络设定方便直观。有人说微软在让 Windows 的用户“上瘾”了之后，就可以对他们予取予求了。不知道现在的设计方向，是不是有这么一点意味:)

最后说句题外话，最近的计算机水平发展的真快啊。从 Vista 开始，Windows 系统就给我一种缓慢的感觉。所以我本来以为笔记本电脑上跑 Windows 7 应该会很慢的。结果看了一下那台电脑的配置，竟然是 8 核处理器、4GB 内存，跑 Windows 7 这种规模的系统已经游刃有余了，真不知道在上面弄个 Gentoo 出来会有多快。

MT5 有非常不错的主题，名为 pico，很符合我一贯喜爱的简约风格。我从 MT4 的时候看到介绍后就很像用了。

升级到 MT5 之后，虽然我之前做了一个三栏的白色模板，用起来一直也不错，不过在看了 pico 的缩略图之后，还是觉得想试一试。于是我就在升级不久就把主题换到了 pico。

pico 看起来一切都很不错，当然不能说是完美，但比起 MT4 之前的那些默认主题可是漂亮太多了。但它有一些我不喜欢的地方是挺致命的，其中之一就是布局有些不合理。也许是过于追求表面美感了，pico 主题的搜索框竟然在页面的下方，文章结尾的后面！

我觉得搜索框这种东西，要是方便的话，一定要放在页面的最上方，调入页面后第一眼就可以看到才好。如果要像 pico 那样，就放在页面的最下方也可以，毕竟方便人们寻找。而目前的情况是，pico 中的搜索框有些上不上下不下的。由于搜索况的下面是评论汇总，因此会把搜索框顶到最下面那一屏的上面。这样给人的第一感觉就是这个页面没有搜索功能！

我前几天看页面，觉得如果能把搜索框放在导航条上，说不定能解决问题。今天晚上有点时间，就试着捣鼓了一下。没有深入研究，只是把搜索 widget 里的代码复制到导航条里的相应位置，结果弄出了这么个东西：

尝试了一下，是可以使用的。不过我看来看去，总觉得相当不协调。如果把按钮去掉应该能好一些，但我又不会（HTML 没怎么研究过），而且也不是很完美。总的来说，我的图形设计能力是相当的差的，只能在以后看看别人的页面设计，能不能有所启发了。

由于 MT 的效率是一个比较严重的问题，因此人们找了各种方法来提升 MT 的性能。在 MT4 中，我用了 AnySQL 的方法来缓存了搜索结果。因为 MT 的 tag 是基于搜索动态生成的，所以这个方法在第一次访问一个 tag 的时候会在硬盘上生成缓存，在一段时间之内再次访问这个 tag 时，直接从硬盘上的缓存来输出页面，速度自然就上去了。

这个方法的效果非常明显，尤其是在资源比较枯竭的主机上。我过去的 blog 在 Dreamhost 上，MT 运行的就特别缓慢，搜索更是如此。我在过去用 WP 的时候，动态的搜索完全没有这么慢，这让我非常惊讶两者之间的性能差距。而用了上面的缓存方法后，这个问题基本上立马解决了。后来我切换到了 Site5 的主机上，这个主机的资源比 DH 的好了不是一星半点，过去需要 45 分钟多才能重建全站，现在只需要 2 分钟多一点。虽然性能上有了巨大的提升，但我还是保留了搜索的缓存，毕竟能快一点是一点嘛。

升级了 MT5 之后，我发现这个方法不能用了，使用的话搜索什么的都出问题。开来 MT5 和 MT4 在一些基础的地方还是有一些不同的。这个方法的作者 AnySQL 切换到 WP 上去了，因此他没有继续更新 for MT5 的版本，所以貌似这个方法在近期就成了“绝响”。

本来我还妄想着随便改改，看看能不能凑合用着。可惜我的 Perl 荒废的实在太久了，也没有用 Perl 来写大程序的经历，所以在 debug mode 下试了半天，到最后还是抓瞎。好在现在的主机快了，影响也不是很大，也就先这么放下了。

最近上网感觉很不爽，因为突然觉得浏览器都不大好用了。

我目前机器上安装的浏览器有三个：Safari、Firefox 和 Chrome。其中时间用的最久的是 Firefox，在目前对我来说是排在第一位的。过去我一直用 Safari，因为这是系统自带的，过去用着也还不错。但自从升级到版本 4 之后，新东西倒是有一些，但效率就不敢让人恭维了。过去我的首页还是默认的 top sites，每次启动 Safari 的时候系统生成首页上的那些缩略图就足以让我的机器卡一阵子了，后来我忍无可忍把首页设定成空白了。之后发现效率越来越差，就改用了 Firefox。Chrome 是最后开始用的，自从出了 for Mac 的 beta 版我就开始试用了，因为在 Windows 下用着感觉不错，所以就希望也在 Mac 上用。但那时 Chrome for Mac 的实现还相当不完善（其实到今天我也觉得缺少一些功能），而且不能安装扩展，这让习惯了 Firefox 下的 AdBlock 之类的插件的我很不适应，所以就放弃了。

几个星期前我听说 Chrome for Mac 也支持安装扩展了，就装了那么几个，感觉好用多了。但用了一阵子之后就感觉到了很严重的效率问题，速度变得特别慢！有时候会出来一个小窗口说是某个标签没有反应，问我是把页面给 kill 掉还是继续等待。有时在我切换标签页之后要等上那么几秒钟页面内容才会出来，这让人很不爽。不知道是不是因为我的浏览方式太过另类，开了太多的标签页的缘故。

过去在用 Firefox 的时候我很少感觉我开的标签页太多了，因为它的标签栏是可以左右滚动的，每一个标签最窄也是三厘米左右。而在 Chrome 下，所有标签页都挤在标签栏里，标签多了以后标签上有什么内容也无法看到了。我在安装扩展的时候看到了一个名为 Too Many Tabs 的扩展，是用来管理标签栏的。在这个扩展在地址栏右侧的图标上会显式目前有多少标签，我经常看到上面 4、50 的数字就觉得一阵心惊肉跳，觉得 Chrome 大概不堪重负了吧。另外，这个 Too Many Tabs 的扩展是为了管理标签的，可以在里面用关键字搜索，可是往搜索框里输入中文的速度是个问题；而且在我的机器上它的速度很慢，这就太有杀伤力了，切换标签这个常用的动作有效率问题可是不可饶恕的致命伤。所以到后来我觉得这个扩展算是一个鸡肋扩展。

在使用了这么一段时间之后，我越发的觉得 Chrome 的效率不行了。我觉得应该是程序里面有 bug 的原因吧，因为我有时会发现整个标签页是卡死了的，完全不能动弹。幸好 Chrome 有多进程这个特性，我把地址复制下来再重新建立一个标签也就解决了，但这总是让人觉得不痛快。另一方面，我对 Chrome 的所谓“多进程”也感觉与我预期的有一些距离。我过去以为每个页面是严格的放进每一个进程的，这样通过 Chrome 的 Task Manager 就可以管理这些进程里面的页面，那个页面耗费了过多的资源就可以一目了然的看出来了。但几次经验告诉我这不是真得。很多时候我看到几个页面是挤在一个进程里面的，根本就无法区分，更加不可能只杀死其中的一个页面。这样这个功能就大打折扣了。

Firefox 在 Mac 下我感觉就很完善了。它除了功能齐全以外，最大的好处是稳定。我在用 Chrome 这段时间内遇到的一些问题，在 Firefox 下基本上不会出现。我现在觉得 Chrome 比较可取的地方之一就是它的多进程，如果可以把这个功能放到 Firefox 上就好了。因为我有时会发现 Firefox 的 CPU 使用比例不正常的高，有时会到 90% 以上，这时候我的 MacBook 的风扇就讨厌的响起来了。而整个 Firefox 是一个大进程，我也无法判断其中的“老鼠屎”是那个页面，因此也无法调整。但瑕不掩瑜，我之前也说过稳定是最重要的，在 Firefox 中我基本上没有遇到过像 Chrome 那样切换了标签后要等上几秒钟后才能阅读的情况。

Chrome 的另一个可取之处是它的标签的界面比较好。当然这不是说外观，之前我也写文讨论过，而是说标签拖动方面更直观、更符合 Mac 系统用户的审美观。而在 Firefox 里，拖动标签时看到的就是一个蓝色的只是条下面跟着一个模糊的缩略图，让我每次拖动的时候都小心翼翼的，需要自习看看鼠标的位置是不是放对了。

至于说 Safari，我很久之前就不用了。主要是它没有扩展的功能，有些除广告的功能就没有了。而国内网站有很多就是有很讨厌的广告在骚扰读者。我的 AdBlock 的名单已经比较符合我的日常习惯了。Chrome 下的 AdBlock 插件虽然不如 Firefox 下那么直观方便，但也勉强可以使用了。可惜 Chrome 下还没有 NoScripts 插件，所以有些站点之内的音乐自动播放就无法控制了，我只能麻烦的在选项里设定 Javascript 的页面过滤条件，也将就了。而 Safari 则这两种东西都没有，遇到这种页面也就只好抓瞎了。再加上 Safari 的效率问题也给了我一些阴影，所以我很久没有用 Safari 了。

=========

昨天我终于无法忍受 Chrome 的垃圾性能了，于是又切换到了 Firefox 下。但这次不知道为什么，Firefox 的行为让我感觉很奇怪。有时让我很抓狂的情况是：打开一个页面，鼠标就变成了小彩球转个不停，我这时候也只能 Force Quit 了。而这些页面包括阿 Gmail、VeryCD……这种情况已经发生了两次了，让我都有阴影了。

Chrome 和 Safari 慢，Firefox 会卡，真让我不知道这些浏览器还怎么用下去。

有时候我想这些现代的图形浏览器是不是太不稳定了，是不是字符界面的浏览器会好一些呢？我过去在 Emacs 里面用 view-mode 来读文档就感觉很爽。Lynx 我用着不惯，我希望可以在 Emacs 里面用，毕竟页面操作起来也方便么。可惜 W3M 不支持新版本的 Emacs，只好作罢。

自从 Movable Type 5 的测试版本发布以来，我就一直希望可以用在自己的 blog 上。MT5 有一些新功能，不过我最喜欢的一点是它后台的编辑器不错。用 MT4 的后台编辑器来编辑中文简直侮辱了汉字的美感。当时费了很大的力气才把后台中文字体给整治的可以入眼，并写文记之。

但当我把这个 blog 的所有文章从 MT4 导出再在 MT5 中导入后，重新发布站点时，MT5 会报告 “Wide character in subroutine entry” 错误。这个问题困扰了我很长时间，从 RC1 到 RC3 版本都一直存在。本来我想这么重大的问题到了正式版应该就没了吧，于是我那几天就天天盼望着正式版的发布，结果却又一次让我失望了。这让我迟迟无法升级到 MT5，也让我对 MT5 正式版发布跳票又没有解决问题的 6A 非常不满。

我估计 6A 不会主动修正这个问题了，也许是他们根本没有意识到这个问题，我于是就在官方的论坛上发布了一个帖子。然后 6A 的 Beau Smith 和我一起测试了几种情况，但一直也没有找到产生问题的原因，到最后也就不了了之了。后来我看到网上的一些其它的中文 MT 用户都升级了，也没有发生我的问题，就推测应该是 Markdown 的问题。后来通过 debug mode 也证实了问题出自 Markdown。但 Markdown 在 MT5 和 MT4 中几乎没有差别，在 MT4 中用着好好的，到了 MT5 中就有问题，所以我觉得应该是 MT 自身有了变动，我也无计可施。

前几个月实在太忙，也没有写 blog 的心情，于是这里就荒废了 4 个月。昨天突然觉得很久没有去 MT 的官方网站上看看了，于是就看到了 MT 5.02 版本发布的消息。我一直不甘心用不上 MT5，就又安装了一次，结果问题依旧。这次我有些时间，于是就发狠手动测试了一下。因为在发布失败后，我看到系统其实是生成了一些文章的，所以我猜应该是我中间有哪一篇文章里有些非法字符导致了这个问题，就想试着把它找出来。我每格大约 20 篇文章就发布一次这个文章，结果大概找到了那个临界点。但看了半天也没有找出问题所在。

然后我想时间隔了那么久，中间不应该只有我一个人使用 Markdown 并遇到这种问题吧，于是就再次去 Google 搜索了一下。似乎现在用 MT 并同时使用 Markdown 的人真得不多了，我上次搜索一个结果都没有，这次找到了两个。我先看的一个是一篇日文文章。我看不懂日文，但根据文章中穿插的英文，我猜测估计是和我同样的问题。描述解决方案的日文不难，“冒頭部分に”、“追加”、“に書き換える”我大体能猜出什么意思。按照他的方法试了一次，果然整个站点毫无问题的发布成功了。再看我搜索到的第二条结果，竟然是在 MT 的官方论坛上的一个帖子，里面竟然引用了我之前发的那个帖子，说他遇到了同样的问题，并通过以下方法解决了。我看了一下他给的方法，竟然和那篇日文文章里的方法一模一样。可惜这个帖子的作者没有在我那个帖子里说一句，所以我一直也没有看到。这个帖子是在今年年初发布的，但似乎一直没有人关注，所以到今天 MT5 还是有这个 bug。我提交了一个 patch，也不知道能不能在下一个版本中改进。

6A 在日本开了分公司，我觉得充分说明了 MT 在日本的流行。其实不止是 MT，Perl 也是一样。我感觉中国程序员更偏爱 PHP，因此 WordPress 在中国基本上完全压过 MT。我在网上很少见到过有 Perl 开发者，似乎人们的精力更多的投入到 Python / PHP / Ruby 上了。相反在日本有很多 Perl 黑客，比如我上一篇文章里提到的给 Cocoa Emacs 23 做全屏补丁的 Daisuke Murase，我在他的 github repo 里看到了很多 Perl 的代码。另外，很多 MT 的资料都是日文的，可惜我看不懂，但 MT 在日本的流行是确定的。

最后我把这个 bug 的解决方案列在这里（假设 MT 安装在 mt5/ 目录里）：

1. 在 mt5/plugins/Markdown/Makrdown.pl 文件的开头部分的 use 区域加上一行 “use Encode qw(encode_utf8);”
2. 在 mt5/plugins/Markdown/Makrdown.pl 文件里找到 “my $key = md5_hex($1);” 一行（280行左右），替换成 “my $key = md5_hex(encode_utf8($1));”。

实在是忍不了了，我在创建了一个 wiki 来做日常的记录之后，经常用它来记笔记什么的。Wiki 的便捷性就不用说了，只需要浏览器，不需要其余设施。内容放在服务器上，也不怕丢失。但最让我头疼的是 MediaWiki 的快捷键的问题。

我之前提到过这个问题。不知道从那个版本开始，MediaWiki 的开发者加上了快捷键。这个决定看上去聪明，解脱了鼠标，让人们可以更快捷的使用 MediaWiki 和 Wikipedia，但实际上糟糕透了。原因是这些快捷键和很多传统快捷键冲突──当你习惯了 Emacs 风格的光标移动方式（也就是 Mac 系统的快捷键移动光标的方式）之后，再在 MediaWiki 中操作一会，一定会大骂添加快捷键功能的开发者灭绝人性的。

虽然那时候发现了问题，但我那一阵子还没想到会用 MediaWiki 来创建 wiki。我本来打算的是用 wiki 系统来生成主页，而不是想要一个 wiki。我在别的地方写到，我考虑过用 MediaWiki，但是我不需要这么个庞然大物，所以我选择了 UseMod Wiki。而且我长时间没有关注 MediaWiki，也不知道它已经支持了 SQLite 数据库──Site 5 的 MySQL 数据库默认的字符编码是该死的 swedish，我的 blog 已经转移到了 SQLite 上了，因此也就一直懒得找把编码设定为 UTF-8 的方法。而我也不想弄的我的 wiki 的数据库里都是乱码，所以我找 wiki 系统当中的一条标准就是支持纯文本或者 SQLite 数据库。后来找了半天也没有合适的，再查看了一下 MediaWiki 的文档，发现它支持 SQLite，顿时喜出望外，于是就装了。

安装了 MediaWiki 之后，我查阅了一些文档，总算回忆起了之前的知识，也把它调适的比较合适日常使用了，我平时的一些信息，比如想看但来不及看的网页地址、一些旧文章、任务列表、还有一些 tip、以及某些课堂笔记，只要是不怕公开的，我都记在上面。从内容上来看，它大概更像是一个 PIM 系统。几天用下来，还是相当满意的，当然其它的 wiki 系统也并不是差到不能用的地步，而是我的心境变了。我这次没有想着用 wiki 系统来做页面，只是把它当作 wiki 来使用，自然觉得一切顺手。

但唯一的一点缺陷（虽然也不算唯一，因为有些 64 位不兼容的问题也挺讨厌，但我能忍受）就是这个快捷键了。我目前的主要浏览器是 Firefox，我日常也一直在 Firefox 里面使用这个 wiki，我开始的时候估计这些快捷键应该是 JavaScript 实现的，但 NoScript 插件并没有提示，我一时间也无从下手。本来我觉得像这种切换功能是应该在设定里面有选项的，但我找了几遍也找不到。后来想想既然别人设计了这个功能，Wikipedia 上也是这样运作的，我就忍了，于是就这么磕磕绊绊的用了这么一段时间。

后来 Google Chrome for Mac 发布了新版本，支持书签同步和插件，我就下载下来试试，用了几天 Chrome。在 Chrome 中我惊奇的发现这些该死的快捷键都失灵了，不错。而且在 Firefox 中看着平平淡淡的页面，在 Chrome 中竟然显得层次分明，相当漂亮。本来我觉得我找到了完美的解决方案，就是用 Chrome 代替 Firefox。但用了一段时间之后，我还是把 Chrome 给退出了。说不上具体的原因，我总是觉得 Chrome 用着还不是很顺手，应该是还不太成熟，Firefox 中的一些插件我也放不下，于是还是回到 Firefox 里来用 wiki。

今天下午上课的时候，照样用 wiki 来记笔记，但记着记着就忍不住了，我估计我要一直用下去，非得心理扭曲了不可。好在我分析 MediaWiki 上传数据用得应该不是简单的 HTTP POST，否则我辛辛苦苦编辑的文档，在误按了某个快捷键而导致更新了页面而彻底丢失的话，我简直就欲哭无泪了。而目前 MediaWiki 的这种方式，哪怕是页面更新了，我从浏览器里后退一步，那文档还是存在，这也是我之前说的可以磕磕绊绊的用了 MediaWiki 这么一段时间的原因。

不过今天觉得不行了，说什么也要把这个问题解决掉。长痛不如短痛，今天废点力气把它彻底的解决，之后就爽了。我于是就搜索 MediaWiki 的 short key 相关的页面，觉得 MediaWiki 的文档设计的似乎也不太方便查找。最后发现在 MediaWiki 里面，快捷键的学名叫做 access key，正是我之前忽略了好几次的东西。

最后我在 Wikipedia 的一个讨论页上看到了一些人针对这些问题的讨论。我发现原来不止是我一个人有这个问题啊，很多人都说他 hate 这个东西。有位名叫 Matt B. 的人给出了一种解决方案，算是一种以毒攻毒了，就是添加一些自定义的 JavaScript 脚本，把原先的设定给覆盖掉。Matt 是只修改 Monobook 这一个模板的脚本，我直接修改了 Common.js 这个脚本，其它的模板是不是有同样的快捷键设置，我不管，反正我之后是再也不想见到它。

总结的方法是，编辑 wiki 的 MediaWiki:Common.js 页面，放上我这个页面里面的代码，刷新一下系统就可以了。我是粗暴的禁用了所有的快捷键，一个没留，如果只是想禁用某个快捷键的话，可以参考这个页面的方法。想在 Wikipedia 里面而不是自己的 MediaWiki 系统里禁用快捷键的同学也请参考这个页面。

在尝试的过程中，我感觉 MediaWiki 的一些设计还是有可取之处的。比如这个添加自定义脚本，我一开始想的是 SSH 到服务器上去修改某个 .js 文件，但一直也没找到这个 Common.js 文件在什么地方。后来看看它其实就像一个 wiki 页面，所以我才猜到可能就是直接编辑这个 wiki 页面添加脚本的代码。我还去参考了一下中文维基百科上面的相关页面，他们也确实是在里面直接添加脚本代码的，我这才放心的在自己的 wiki 页面里面添加代码。这样的方式让日常维护操作更加方便，而且这些设定就直接当作普通的 wiki 页面被保存在数据库里面了，备份起来也方便。把所有的设定都视为可编辑的文件，大有 UNIX、Emacs 这样的“化繁为简”的风范啊。

9、10 号的时候从 Twitter 上看到有人说 Google Buzz，简单的了解了一下，说是 Google 的微博服务，与 Gmail 集成的。我那时候还没有见到过 Buzz 的页面，只是从 Twitter 上看别人在讨论。有人说他不会用 Buzz，有人说可以把 Twitter 同步到 Buzz 上云云。

10 号晚些时候，我进 Gmail 的时候，发现 Buzz 也开通了。上来先“假惺惺”的问我要不要开通，这种免费的新鲜服务还有选不开通的吗？开通了之后，印象里第一步就是选 follow 的人。Google 通过通讯录里的信息，筛选出同样开通了 Buzz 的人让我选。我忘了之前的选择是什么了，反正有些比较有名的人物，比如月光、keso 等我都选了。或者是我当时就觉得我在近期不大会用 Buzz，所以就把人物都选中了，话多的也没什么影响。

不过没用一会，我就感觉：我不会喜欢 Buzz。

上来后发现的第一个问题就是所谓的“话唠”。这话唠和 Twitter 上的不同，Twitter 上是一个人呼哧呼哧的说，而在 Buzz 上，如果一个人的通讯录比较发达，默认 follow 他的就有很多人。经常是他随便在 Buzz 上说点话，就有一大群人跟着回复。而且这种回复不是那种论坛中探讨问题的回复，而是不折不扣的“唠嗑”，闲话家常那种。但这又不像是真正的闲聊，很多人都不认识，没有聊天的气氛，更重要的是，没有上下文、不了解谈话的背景，很容易几个人就一个鸡毛蒜皮的小问题就争论起来了。没意义，看着也烦。别说中国人挺含蓄，在网上可一点都不含蓄，我估计也是日常憋得。我刚刚和一位同学在 Buzz 上说话，就看到有个陌生人插了一句“路过”。要不是之前没发现，Buzz 好像也不能回复中间的条目，我真想像王小峰那样说一句“路你妈屄过”。试想你和朋友说话的时候有陌生人在旁边说句“路过”你什么感觉，我一直认为“互联网即生活”，互联网上的活动应该反映人们的日常生活，所以这种情况我是不喜欢发生的。我印象里上来就 mute 了月光的一条，忘了是什么内容了，反正已经把我的 Buzz 页面拖得老长了。还有 keso 的也是，都不是原张贴者的问题，都是留言太多导致的。尤其是可能是因为 Buzz 刚开通，人们都有好奇心，什么都想试一试。这一试就水了很多楼层。

前几天无论是在 Twitter 上还是在 Buzz 上，有很多人说 Buzz 像这个像那个。我当时就问了一句：“难道没有人觉得 Buzz 像 Plurk 的吗？”当时确实是没看到有任何 Buzz 和 Plurk 相像的说法，不过我觉得两者太像了，Buzz 就像是未完工的 Plurk，当然这也符合 Google 一贯的 beta 风格。

我在之前写文章讨论过 Twitter 和 Plurk 对于信息管理方式的优缺点。Twitter 是朴素的线性，而 Plurk 则是树形。两者之间那种好，我在那篇文章里已经讨论过了。那篇文章的结论，现在我感觉同样适用于 Buzz。比如说用 Buzz 的时候，我想过好几次，如果能只显式我 follow 的人的条目就好了，把那些条目的回复都折叠起来，看上去就很清晰。Plurk 默认是这么做的，而 Buzz 不是。看上去 Buzz 里面“一片繁荣”，但实际上有用的没有多少，用户还是被淹没在了信息洪潮当中。所以我觉得 Buzz 是未完工的 Plurk。

但 Buzz 在这一点上又有比 Plurk 更好的地方，虽然这个好可能不是 Google 主动做到的。那就是 Buzz 条目的字数限制很宽。刚才我测试了一下，把我目前 Blog 首页的所有正文文字复制下来粘帖到 Buzz 的发布框中，Buzz 倒也都能吞下，但点击了发布按钮之后会提示错误，但也不说明是为什么出错。然后我只复制了上一篇文章的文字，贴了上去，就成功了。我上一篇文章有 2000 多字，远远超过了 Plurk 的 140 个字的限制。这样的好处就是想说一句话的时候，可以尽情的说，而不用绞尽脑汁删减字数。在 Twitter 上，我有时候因为实在删减不了了，只好发两条的情况。这在 Twitter 上无所谓，因为条目是线性显式的，所有东西都堆在一堆，回复了也不知道是针对哪条回复的。而在 Plurk 上如果这样做，回复的时候就要考虑一下，“我到底是要回复第一条呢？还是第二条呢？”。如果回复了第一条，就导致对话的逻辑混乱；如果回复了最后一条，旁观者又可能会看不明白两者的“对牛弹琴”，因为要回复的重点在另外一条里呢。当然，这种情况下，Plurk 用户可以自己回复自己，应该也算是一种解决方法。Google Buzz 的这种“超级”条目，自然就没有这种问题了。谁一句话要 2000 多字还解释不完，那可要重新去小学里“回炉”了。

而这种情况，在 Twitter 同步下就成了悲剧了。就在刚才，我发现我之前在 Twitter 上发的一句话分成两条的条目，在同步到了 Buzz 上，被显式成了两个不同的条目。结果导致我的朋友回复了其中一条而没有把两条关联起来看。我问他为什么，他说同步过来的条目都乱序了，他也不容易分清楚。我目前常用（确切的说是“唯一使用”）的微博工具就是 Twitter，其它的地方，能同步的话我就同步过去，毕竟也算是扩大影响力吧。但这也带来了一个情况，就是别人在 Buzz 上回复我，回复的是我在 Twitter 同步过去的条目，我几天上一次 Buzz 的情况看，我经常会没有及时回复别人的回复，这也导致了讨论的断层。

另外，关于条目的长度，我一直觉得对于中文来说，Twitter 的 140 个字的限制是“神来之笔”。至于英文，可能是我的驾驭能力不够吧，经常说着说着就说超了。对于中文来说，绝大多数情况下，对于绝大多数完成了中等教育的中国人来说，是绝对的够用了。Buzz 目前可以说是不限制字数，反而会有人网上贴长文的情况。不过目前已经可以把 Blog 的文章同步到 Buzz 上了，这样也说不上好不好。好处是浏览者不需要跳转过去看 blog 了，坏处是我担心会分流留言，导致回复不及时。

最后一点，还是用户使用习惯的问题。如果 Buzz 做的很优秀也就罢了，但目前这种程度的产品，想要和 Twitter 分流用户，我觉得很难。我在 Twitter 上 follow 的人都是我认识的，这些人当中只有一个人选择了同步 Twitter 到 Buzz。他们多数人日常都使用 Gmail，但 Buzz 的使用量则少的可怜。我个人也觉得人们目前阶段用 Buzz 也只是玩玩而已，而不会真正的转向使用 Buzz。换句话说，我觉得 Buzz 其实就是另一个 Google Wave。Wave 发布的时候，我感觉很惊艳，写了篇文章来总结它的优点。但 Wave 是邀请机制的，而且与日常使用的产品（Gmail）不挂钩，再加上 Wave 本身的效率问题，在公开几天后，出乎我意料的是 Wave 并没有火起来。很多人四面八方的讨要来一个邀请，注册之后，新鲜了几天，就荒废了，这也是我虽然有邀请，但拒绝给任何人的原因。我觉得如果 Wave 不需要邀请注册，再跟 Gmail 联系起来的话，估计也就是 Buzz 的水平。

基于以上几点，我在使用 Buzz 的第一天就感觉，就觉得 Buzz 应该不适合我，至少我觉得 UI 方面的表示层应该要重新设计，否则使用起来会非常的不方便，难受。其它的一些小问题也值得重新思考一下。说到这里，我觉得 Buzz 应该是几个人一时间的冲动，我不觉得在这个产品的设计方面有很多精深的思考，只是把 Twitter 的思想与 Google 的一贯模式浅层的结合一下而已。也就是说，我觉得 Buzz 还不成熟，在将来应该也会有很大的变动，因此我在近期里是不会重点使用 Buzz 的。

最近一段时间，我一直断断续续的研究 wiki。主要的目的是想用 wiki 来做首页，因为我厌倦了一直依赖手写 HTML 代码来更新首页。因为这样弄起来麻烦，所以过去我的首页基本上都是常年不变的。我一直觉得首页应该是一个站点的门户，所以我在 2007 年第一次建立这个站点的时候就决定把 blog 分离出来。那时候有很多人的首页上来就是自己的 blog，我觉得作为一个学计算机的，网站应该保留一些传统，所以尽管我的主页常年不动，几乎是个废物，我还是一直留着它。

直到我忍不了了，心想应该需要大修一下，最起码要做到内容和格式分离。开始的时候我想的是用 MT 来一并管理了，后来总是不得法，一直没有成功。然后就决定用 wiki 来做，也能达到一个 CMS 的要求了。我当时想的是首页不需要多少功能，就选了个最简单的 wiki 程序──UseMod Wiki。它不使用数据库，所有数据用纯文件保存。后来觉得首页全用 wiki 写有很大限制，比方说不能插入 javascript 代码，这样我就不能在页面上放一些贴纸（比如 Ubuntu 发布倒计时什么的）。我试验了好几个 wiki 程序，他们的设计方向都是多人共同编辑，因此在插入可执行代码方面的政策相当保守。最后只好作罢。后来想起了之前用过的 Blosxom，它可以在文章中放置任何代码，但我最后还是觉得 Blosxom 主要还是为 Blog 系统设计的，要想让它编程首页的样子，就要重新设计模板，而这正式我最不擅长的。

前几个星期我在看 Ramhost 的消息的时候，看到它的老板曾经写过一个叫 Ram-CMS 的项目。它很类似 Blosxom，也是手动把页面写在纯文本文件里，放在一个目录中，系统会通过链接找到文件，显式出来。我把在首页上放了几天，觉得还算不错，不过也有部分问题，就是这个项目的开发还不够成熟，用它来做很多事都挺麻烦。虽然能够完成，但我毕竟是不想再手写 HTML 代码，要是能有类似 Markdown 那样的抽象机制就好了。同样的，那个项目不是一个产品项目，而是作者给自己开发的小玩意。我要对模板做一些改动才能使用。我于是一遍慢慢进行，一遍在寻找其它产品。

我前几天又上了 Zoom.Quiet 的页面，他们一帮人组织的致力于 Python 的推广学习的啄木鸟社区，用的是 MoinMoin 做的 wiki。而那个社区里的一些看上去杂乱的页面风格挺符合我的胃口，我那时候有正在考虑 CMS 的问题，就想试试 MoinMoin。后来看了半天文档、又实践，却发现 MoinMoin 很难安装在共享虚拟主机上。最后也不得不放弃，同时发现，Python 程序和 Ruby 写的 CMS 往我的 Site5 主机上放都不太容易。Perl 写的 CGI 已经就差不多了，当然最方便的还是 PHP。

后来由于怀念起很早之前用 MediaWiki 搭建的一个歌词为主题的 wiki 了，于是就又装了一个 MediaWiki。我印象里一直以为 MediaWiki 只支持 MySQL 的，结果查了一下发现 MediaWiki 同样支持 SQLite。我目前觉得 SQLite 数据库比纯文本文件数据库还要方便，毕竟一个目录和一个文件的便宜程度是没法比的。Site5 主机上的 MySQL 默认的字符编码是 Swedish，很讨厌，我一直也没有成功的弄到 UTF-8 上，于是我没有在主机上建立一个数据库，全部用的 SQLite。不过装上 MediaWiki 后却发现不会用了。我过去为了管那个站点，还研究过一段时间，但将近两年的时间没有再管理了，再次见到一头瞎。最后觉得也不甚理想，于是就删除。

昨天看到 TualatriX 写的文章《摆脱信息爆炸，开启个人Wiki的时代》，提到他用 MoinMoin 建立了一个 wiki。我看了之后也挺羡慕的，只谈自己没有 VPS 啊。不过文章却启发了我，之前一直想用 wiki 做首页，但其实真正弄一个私人的 wiki 还真是个不错的主意。日常里有些信息还真得需要用 wiki 来维护。

我最头疼的首先是打开的网页。我的习惯是看到好页面，如果不是特别想看的话，而且还有别的页面也想看时，就把它的标签留着，以后再看。反正我平时的本子基本上不管，移动的话直接一扣，Mac OS X 的电源管理还是做得很好的。这样时间长了我的 Firefox 就积攒很多标签，既影响速度，又让我觉得很难看完，而关掉有觉得不甘心。最后要么把所有标签收藏起来，好么就把链接保存在文件里，等将来再看（虽然绝大多数情况是将来再也没有看过）。我曾经写过一个 Google App Engine 上运行的程序，名叫 URL-Basket，专门收集临时链接的。跨年的时候写的，但不能处理非英文的字符，后来事情多了也没有再修改。现在觉得而这些东西放进 wiki 里应该也不错。同样因为是放在网上，移动的问题也解决了，远比在硬盘上建立文件方便。

我心中理想的产品，是一个 wiki 为基础的大杂烩，可以进行普通的编辑，也可以在上面加各种各样的应用，最好它本身就是一种语言的解释器，可以运行自己的语言。所有的东西可以放在一个页面里，也可以进入不同的目录。程序也即文本，也就是那些小程序模块可以像文字一样复制粘帖。其实这个东西就相当于一个在线版的 Emacs，我这想法也没有任何依据表明它一定会有用，不过我空想中觉得应该是挺好玩的。目前的 wiki 程序算是完成了一半的要求，不过毕竟发展的思路不同，或许将来会有类似的东西吧。

既然自己要弄一个 wiki 系统，我还是选择了 MediaWiki。因为不是想用它做首页了，所以复杂一些也没关系。过去在 Dreamhost 上运行 MediaWiki 要忍受它的龟速，但在 Site5 的共享主机上就完全没有速度的问题了。我试过一些其它的 PHP 写的 wiki 程序，很多都只支持 MySQL 数据库，这是我不想要的。MediaWiki 支持 SQLite，也被 Wikipedia 证明了它的稳定性，所以我也就义无反顾的选择了它。安装好了还是想不起来怎么用，只好查文档看各种资料，折腾了一会好歹把之前的数据都放进去了。

目前来看，我对这个 wiki 还是比较满意的。本着能用就好的原则，我也没有进行过多的设置。把自己的 favicon 和 MediaWiki 的 logo 合并，作为了 wiki 的 logo，虽然觉得那粗线挺丑的，但也算到了我设计能力的“极限”了，也只好将就了。

弄了 wiki 后，首页我就不打算放 wiki 了。之前那些杂货也都挪到 wiki 上了，首页就让我设计成几个指向我几个不同帐户的图标组合了。目前看起来一切都还好。

昨天我照例去老袁的 blog 上找乐子，看到他新写了一篇文章《谷歌Android被Linux内核除名》，讲到了 Linux 把 Android 的代码树删除这件事，并借这件事，引申到了自己对 Google 的挞伐之中，并再次吹捧了 Windows。

老袁写的文章，我都是当笑话看的。看了以后就不管了，不过刚才翻 Google Reader 的时候，看到了阮一峰新写了一篇文章《Android，开源还是封闭？》。老袁写的笑话我可以不管，但阮一峰认真的写了这么一篇文章，我倒是对文章中的观点有些不认同。本来想在他的 blog 上留言的，但写着写着就觉得太长了，干脆总结成文章放在这里。

我觉得现在人们谈及 Google 必提“不作恶”，用这个词来规约 Google 的行为。这本身没什么问题，但我觉得这个词现在被过于“滥用”了。有时候众口难调，Google 不能满足所有人的时候，批判者就经常用“不作恶”来评判 Google。不同的人有不同的观点，所以事事都往"作恶"上面靠，让目前的讨论变得很空泛了，当然这只是题外话。

这篇文章里说的意思是，Google 的 Android 使用的是部分 Linux 的代码，按照 GPL 协议，Google 应该把所有的改动同样用 GPL 发布，以贡献开源社区。但事实是，Google 让硬件驱动运行在 userspace，这样这些驱动程序就不是 Android 的一部分，就不需要回馈给社区。Google 给硬件厂商提供了方便，使得他们写的驱动可以不用共享给社区，所以 Android 是个封闭的系统。

我觉得这样就有诡辩的成分在了。首先 Google 的做法是合法的。Android 本身是开源的，所以它没有违反协议。而硬件厂商给 Android 开发的驱动，版权并不属于 Google，因此 Google 自然也没有权利拿它们来回馈社区做好人。如果 Google 这样做了，岂不是和海盗湾的那帮传播盗版的人一样了么。当然，阮一峰是支持海盗湾的，可能他认为 Google 不这样做才是作恶吧。

文章中有一点挺有意思，还有些技术成分。Greg Kroah-Hartman 的文章里说 Android 为手机实现了一个统一的虚拟机，解决了程序的移植问题。阮一峰认为这是 Google 为了不贡献那些驱动而耍的小把戏，他说:"且慢，这真的是理由吗？传统的Linux系统，也并不依赖特定的硬件啊！只要把源代码根据不同的平台，分别编译一下，同一个程序不也照样可以在不同的硬件架构、不同的Linux发行版中使用吗？"

我觉得阮一峰可能对"平台"这一词并没有弄清除，或者是故意曲解了这个词。过去人们所说的 "C 语言具有良好的移植性"，"换一个平台，在那个平台上编译一次代码就可以了"，这里面说的平台，可不是目前人们说的 32 位平台、64 位平台那么简单。平台之间的差异基本上到了 CISC、RISC 的差异那种程度上了，和目前我们想象的地址总线的数量不同了相比，显得更复杂。很多软件，在不同平台上移植，也不只是重新编译那么简单。比如说 Endian 的问题，光是要修改这一部分就要花费很大的功夫去修改。Mac 系统从 Power PC 平台迁移到 Intel 平台上的时候，发布过 Rosetta 程序，就是一个 Intel 平台上运行的 Power PC 虚拟机。很多软件，如 Adobe 的那些程序(印象里是 Photoshop，我们在 Computer Organization 课上讲过，现在记不清了)，到最后也不是修改过去的，而是重头写起。像 Adobe 这样的大公司都是如此，手机上的软件开发着常常都是小团队甚至是一个人，要独立完成不同平台的移植工作，显然也是不容易的。哪怕是现在我们从 32 位往 64 位上过渡，经过了这几年都还没有搞完呢，更别提那些架构级别的移植了。

而 Java 通过虚拟机，算是彻底的解决了这个问题。如果像阮一峰想象的那样，重新编译就可以完成移植，那么当年 Java 还搞什么噱头?由于 Android 本身是开源的，而且手机硬件的生产成本又低于计算机，现在也没有统一的标准，所以在将来，我认为必然会出现千奇百怪的硬件。这些肯定不能通过简单的编译就解决问题。阮一峰的意思是为不同的硬件架构都做一个二进制包，这样一个软件，开发者就要为多个平台维护不同的二进制包，阮一峰总不会指望作者发布软件代码让用户自己编译安装吧?而如果 Android 想成为一个像 iPhone 那样的严肃作品的话，必然要有针对普通用户的一键式安装软件的机制。Apple 的 App Store 是一个很成功的先行者，而 Google 目前搞的 Android Market 也是在像这个方向努力着。而按照阮一峰的想法，当一个用户在安装软件的时候，被告知如果是 HTC 生产的硬件，就下载为 HTC 编译的包；如果是摩托罗拉的硬件，就下载为摩托罗拉编译的包。这样的手机，在普通用户眼里，也只能是"小打小闹"，根本成不了气候。由于手机产生的平台可能会比计算机更多，那样的话后果说不定更严重。目前 Linux 在桌面领域已经是这个样子了，如果 Google 按照同样的策略去运作 Android，将来在市场上 Android 很可能表现还不如 Linux。面对 iPhone 平台，那样的 Android 只能是沦为几个黑客的玩具而已。

同样说道了市场，我的前提假设是 Google 做 Android 不是玩票，不是搅浑水，而是严肃的想涉足移动计算这一块。那么硬件的支持就是至关紧要的了。阮一峰的文章里也说明了，硬件厂商开放了自己的驱动的后果是什么。让那些硬件厂商把驱动吐出来显然是不可能的，所以迎合硬件厂商的要求也就是必要的了。其实仔细想想，这样的做法也并不算过分。对于用户来说，我们获得的还是一个开放的 Android，只是硬件的驱动是封闭的。开发者照样可以为 Android 平台开发软件。其实就算是桌面 Linux 用户，除了像 RMS 那样固执的人外，有几个会选择开源的显卡驱动呢?

所以，无论是从法理还是从情理上，我都觉得 Google 在这件事上没什么错。合理怀疑也是不错的，但把什么事都说成阴谋论就让人觉得不好了。尽管 Google 有"不作恶"这一说，但如果 Android 真得发展成了桌面领域的 Linux，那么它做不做恶都没有人关心了。

阮一峰在最后说：“Android必须变成一个真正的开源系统。如果像现在这样封闭下去，就会被开源社区抛弃，就一定不会成功，即使有Google的支持。”这口气让我觉得和老袁挺相似了。如果 Android 作为一个系统，这话还有可能说的过去，但作为一个商业产品的一部分，如此断言还是太过武断。