实在是忍不了了，我在创建了一个 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。之所以一直没有放首页，是因为我想找一种“完美”的方案，来自动管理这些页面。

最早的时候，我的首页是用 HTML 手写的。这样有优点也有缺点。优点是方便，不需要额外的工具，要加什么内容，直接 ssh 登录到服务器上修改文件就行了。缺点是不方便，虽然看上去与优点正好矛盾，但却是事实。时间长了之后，我也厌倦了手写重复的 HTML，所以很长时间我的首页上只有一个“首页”，基本上没有其它分页面。而且基本上也不更新，因为更新的话就要 ssh 登录，而且普遍的虚拟主机都对非英文字符支持的不好，修改页面当中的中文的时候，一不小心就会把页面弄乱。所以我很早之前就想改变这种维护的方式了。

之前我对 blog 做出了一个不小的改变──把 blog 子域名改成了 blog 子目录。原因是我当时看了 Movable Type 5 的说明之后，觉得既然有了 Website 概念，就可以用 Movable Type 来生成首页了。虽然目前的版本也可以做到，但毕竟把首页也当成一个 blog 感觉很不自然。而我尝试了几次，都无法让 MT 来正确的往子域名中发布网页，因此就一咬牙把子域名换成了子目录。结果改过来之后，却发现即使是到了正式版，MT 还是无法正确的发布我目前这个 blog 的导出数据，所以我也一直是没有升级。我本来以为是 MT5 对中文的支持问题，结果发现网上的一些中文用户都升级了，再自习排查发现错误出在 Markdown 上，我对比了 MT4 中的 Markdown 插件，也没找到什么不同，因此也无法修改，这让我很郁闷。

不过从想到用 MT 来管理我的首页时，我就觉得用 CMS 来发布首页应该是个好主意。除了 MT 之外，我首先想到的是 wiki。我于是在根目录下用 UseMod Wiki 搭建了一个 wiki，用英文在上面也写过一些东西，感觉还不错。除了系统本身简单方便外，可以在浏览器中直接编辑也很好。但毕竟它是一个 wiki，因此有 wiki 的规则。Wiki 本身的目的是多人合作写作，因此系统的安全性就非常重要了。所以基本上所有的 wiki 系统都禁止在页面中直接放入 HTML 代码。虽然这一点排除了有人插入不良脚本的可能性，但这对我想用作生成首页的人来说就非常不方便了。首先我的首页只有我自己能编辑，因此没有安全性的问题，更重要的是，我无法在里面添加 HTML 代码了。所以一些标签、Google Analytics 的统计代码、以及 OpenID 的代码我都无法添加进去了，前两点不行也就罢了，最后一点不能办到就非常恼人了。我几乎所有的用 OpenID 注册的网站，用的都是我自己的域名，一旦无法添加 OpenID 的代码，我的这些帐户就都无法登录了。所以，我从了解到这一点之后，就决定将来搬家之后一定要用一种新的方法。

今天在网上看到了有人又在讨论 Ramhost 的问题，我于是就去了 Ramhost 的管理员的网页上去看了看。从他的页面中，我看到了他曾经的项目有 ram-cms，而且 Ramhost 的页面也是用 ram-cms 生成的。我一看觉得不错，于是就上去试了试。现在我忘了当时是因为什么原因删除了的，虽然它总体上不错，但我还是想起了过去用过的 blosxom 来。

说道 blosxom，我顿时又想起了我过去几次安装 blosxom 的经验。第一次在国内的时候听说过了这个程序，觉得挺有意思，就从自己当时的虚拟主机上安装。那时候我的相关知识都很不充足，cgi 程序是怎么运作的我都不了解，于是很正常的就失败了。那一次的失败耗光了我当时的耐心，于是就回去用 WordPress 了。第二次的尝试印象里是在 2008 年底一次期末考试结束，我当时走出考场后突然感觉悟到了一些东西，于是就走到机房里实践，结果当时不知不觉中就成功了。我当时也不会调整 .htaccess 之类的设定，所以生成的路径也是 cgi-bin/blosxom.cgi?xxx 的一大串。后来我还是放弃了，因为觉得设定起来很麻烦，默认也没有留言之类的东西。

这次我想起 blosxom 后，觉得可以试试看用它来生成首页。于是下载了之后，顺水行舟的就装上了。我去年暑假里学了 Distributed Computing 课，里面用 Perl 写了很多 cgi 程序，因此对于这些都比较了解了。也没有死按照文档说的去设定，直接把 blosxom.cgi 改名成 index.cgi 放进根目录下，并在上层目录里建立几个目录放数据文件就可以了。其实配合 Emacs 的远程编辑，我感觉如果作为 blog 程序还是很方便的。它的 flavour 的设定也不难。生成的路径格式我没有改，不过有了之前的经验，设定起来应该不难。

不过最后我还是把它放弃了，因为我觉得很难把 blosxom 当作一个 CMS，它还是更偏向于 blog 系统的功能（虽然它默认上还缺很多部分）。我需要的是一个能够生成页面的 CMS，而不是一个 blog。像一些如日期、文章页面之类的东西，我还是不需要的。虽然通过修改了 flavour，我可以把这些给抹去，但毕竟用作生成页面还是不方便。

其实我现在觉得还是 wiki 更方便，如果它能够插入 HTML 就完美了。我找过很多 wiki 系统，基本上都有这方面的限制。我还想过自己结合 Markdown 写 cgi 程序，每次改动后发布也好，用 crontab 来定期执行也好，不过最后觉得这个程序不是一朝一夕能够完成的，我的 Perl 也荒废了很久了，像一些文件处理之类的地方，我都忘得差不多了。

之前我有提到过，我对网页设计方面没有什么研究，尤其是在美工方面是没有什么天赋的。

对于计算机的学习与了解，从小我一路上来，我身边的朋友，如果不是接触编程这方面的话，基本上就是制作网页了。那个时候买个盗版的 Microsoft Office 里面就有 FrontPage 软件，可以像制作 Word 文档那样子制作网页。而用到 DreamWeaver 已经是比较厉害的了。我只打开过 FrontPage 这个软件，而 DreamWeaver 需要单独买，那个时候也没有网络可以下载软件，所以我就从来没有打开过 DreamWeaver。现在不知道是因为我很少看面向大众的电脑报之类的东西的原因，我反而很少听到有人提起这两个软件了，也不知道它们都发展的怎么样。我在 Site5 上的空间上是有 FrontPage 扩展的，不过我不知道有什么具体的作用；而 Adobe 公司到现在还在买 DreamWeaver 也是事实。我觉得现在之所以人们都不大讨论这两个网页制作工具，应该跟目前比较红火的 blog 制做工具有关。几年前（大概有 10 年了吧）人们流行制作网页，其实那些人想要的只是一个 blog，这是我能想到的解释了。

我个人，至少是到目前位置，还是对于当年我没有沉醉于制作网页这件事上感觉比较庆幸的。我没有什么手工美术天分，从小对于需要自己动手画画的美术课就比较头疼，同样体现在我对电子的网页上的美学要求就没有什么具体的想法。我看到一个网页可以说出来我觉得它漂亮不漂亮，但让我凭空想出一个漂亮的网页，对我来说很难。而做一个 blog 的样式，基本上就属于这种类似的工作。我对于设计这方面也比较懒惰，我更喜欢有现成的东西可以套用，就像 TeX 那样子，标准的一些样式就已经非常漂亮了，基本不用自己设计宏包。

而偏偏事情不如意，Movable Type 平台上的主题还是太少了。先不说是否美观了，就是基本的主题数量就没有多少。我估计和 WordPress 的走红有很大的关系。我在刚开始用 WP 的时候，从来没有感觉到模板不够用，那时候发愁的是不知道选哪个好。我当时找到了一个 1024-px 的模板，自己略微改动了一下细节，用得就比较舒心了。而在 MT 领域就基本上是另外一个样子了，一个初级用户可以选择的也不过是系统自己提供的那几个。更夸张的是，MT 4 的默认字体显式中文实在是太恶心了，我其实觉得显式英文也没有非常好看。我估计是 6A 有一大部分股份是日本的缘故，所以很多默认的模板里面的字体设定都有很多是日文字体。这些模板显式中文，有的字竟然会比其它汉字窄（最明显的就是“关”子了），而且经常也一篇粗一片细的，非常不美观。

当然，MT 也有好看的模板，但是数量实在是太少了。比如 MT4 的 Mid-Century 和 MT5 的 Pico 都是相当不错的模板。Pico 走的是简洁风，Mid-Century 走的是“简约不简单”风，基本上很抓我的眼球。最基本的是，他们显式的中文都非常的漂亮。其实目前的网页环境下，中文已经比较漂亮了，但可惜 MT 的默认模板中有很多的 font-family 的设定都不利于中文的显示，所以过去很长一段时间中我都搞不定字体的设定，后来自己从头开始自己从零开始写样式，这样才算解决了这个字体的难题。

设计模板另一点对我不利的地方是，我没有系统的学过 CSS。今天我在外面的时候想了一下，总结出我目前和我小时候学习方法的不同。小时候也许是因为我看的所有计算机的资料都是课外的，所以我就特别的有兴趣。基本上所有的计算机书籍，我都是一字不落的从前言开始看。所有的东西就像是看故事一样，从头看到尾，这是我现在觉得“系统学习”的方法。而现在则有不同，由于时间的原因，我现在看的资料就非常的功利了，需要什么技术，就看相应技术的资料，现学现卖。所以我现在对于 CSS 的掌握是非常浅薄的，使用起来也没有什么信心，基本上是修改了一下 CSS 文件，然后就刷新一下浏览器看看有没有生效。

其实我觉得这种学习方法不是正确的学习方法。别人我不了解，我自己就是这样。举例来说，我现在感觉我真正对 Python 语言有了感觉是在我强迫自己安下心来从头看了一遍 Dive Into Python 之后。那个时候我已经不能像过去看 Learning Perl 一样可以静心的从头到尾的看一本技术书了，所以要强迫自己才能完成。而我在学习 Ruby 语言的时候就没有这么多时间了，所以学起来就很浅的看了看。再加上那时候 Ruby on Rails 已经流行起来了，所以学习 Ruby 的时候就有很大一部分心情是为了用 Rails 才学的。中间我们学校的面向对象这门课又用 Ruby 作为交作业用的三种语言之一，我又学了一下基本的语法。但我现在总结起来，我对 Ruby 还是没有什么感觉。目前写程序，我喜欢用的还是 Python。Perl 长时间不用，有些东西忘记了，Ruby 还需要查手册才能写下程序。

正因为没有系统的学过 CSS，我过去对于 CSS 的使用基本上就是现学现卖的水平。自己的网页需要一种功能，就去 Google 上查，找到 CSS 之后就放进自己的文件中去。或者就是看到别人的页面挺漂亮的，就去看他们的 CSS 是怎么写的，自己在吸收一些不错的东西到自己的网页中去。这种方式弄一些基础的东西还是够了，但要做一些高级的事情就不行，原因其实是对于那些复制的代码还是一知半解，比如说 id 和 class 的区别、什么时候用点开头什么时候用井号开头什么时候什么也不用之类的。

我在今年暑假的时候第一次自己做了一个模板，当时的目的是因为默认的页面实在是太丑了。字体已经说过了，简直是惨不忍睹，而页面配色本身也很难看，header 的血红色的背景色，加上小小的字体，给人一种头重脚轻的感觉，字符的颜色也淡，看上去很吃力。而系统提供的其它模板，基本上没有好看的。唯独有一个 Unstyled 模板还挺有意思的，就是把所有的 CSS 设定都清空，可以总结成只有 reset 功能的 CSS 模板，再加上侧边栏的感觉。我一看这个模板还不错，至少字体是正常了，于是我就在这个模板的基础上加上了一些其它的设定，以及从我之前照的照片中剪裁出来的 header 和 footer 背景，当时用的还不错。后来我受一些台湾的 MT 用户的影响，觉得把 blog 做成大杂烩的样子也不错，于是就在之后用了 cityscape-sf 模板，一直到大概一个星期之前，我才用了 Mid-Century 模板。

Mid-Century 模板算是一种对 MT 的显式系统本身的比较大的改动。也就是说它不能像普通模板一样把目录复制到 mt-static/themes 目录下面就行，而是要用 plugin 的形式，从 Templates 页面里把整个的模板组给换了。这样做了之后，widgets 这些东西就不归系统管了，而是要 Mid-Century 自己来管理，所以 Widgets 页面就失效了。现在说起来，我感觉它就像 WordPress 的 K2 模板一样。我过去对于这种模板是略微有点排斥的，主要是怕它把 blog 弄坏了，无法恢复，我的 blog 当然也是要以稳定为主的。后来我因为快要换主机了，早晚也要迁移 blog，于是就下定决心在旧的主机上尝试了一下，果然非常漂亮，但我能改动的也就不多了。在更换了主机之后，我还是没有使用 Mid-Century 模板，同样是之前的考虑，我觉得如果能不动那些基础的东西就不动。

其实从设计上来说，MT 的风格设计还是合理的。基本上一个标准风格的模板，就是在 mt-static/themes-base/blog.css 的基础上做一些设定。而这个 CSS 文件的作用，基本上就是网上的那种 reset 作用的 CSS，经过它之后，之前的一切设定都没有了，留下的只是边栏。有了它之后，在加上一些字体、链接风格之类的东西，页面就比较美观了。我的上一个模板和我今天做的这个新模板都是基于上面的这个 reset 文件的。我这次其实也是从过去的基础上，参考了冯大辉和阮一峰的 blog 的 CSS，加上了一些自己喜欢的设定。我的 CSS 文件还是非常简单，我测试了没有太明显的效果的，我统统的没有加上。

其实做来做去，我现在也是非常羡慕可以做出漂亮网页的人了。昨天我研究了一晚上的 VPS，看到了 iStef 制作的卖 VPS 的网页，佩服的不得了。那个网页使用的是 MT 5rc3，做出来的相当漂亮，有水准。

我目前做出来的东西主要就是我目前的 blog 的这种样子，没有什么特别的修饰，能不加的就不加。这次的改动主要有链接的修饰、字体默认换成了 Georgia 因为它的数字显式很有感觉，标题的字体字号之类的。其它的连 header 和 footer 的图片背景都没有加，倒不是因为载入速度的考虑，主要是因为我不知道上面弄上么好，我自己又没有合适的素材，目前的这种纯白的效果感觉上已经不错了。为了方便日后使用，我还是把它打了包，上传在这里。使用的时候把它解包后，放进 mt-static/themes/ 目录下就好了，然后从后台的 Styles 页面选中他就可以了。

换了虚拟空间之后，我昨天晚上重新安装了 Movable Type 4 Pro。

现在的我对于安装一个 MT 自然觉得没什么的，但我在第一次安装时也是走了一些弯路的。从那次之后，我知道了 MT 有自动帮忙设定文件的 mt-wizard.cgi，用它在浏览器里选择填写一些参数后就可以装好一个 MT。安装文件也没有必要把一些目录复制出来什么的，全都放在一个总的文件夹里面也可以运行。

后来在翻阅 MT 的文档的时候，我看到了一些用 ssh 的安装的方法。而且这次用了 Site5 的主机，我感觉我过去在 Dreamhost 上弄的那些东西都是不安全的。在那里 cgi-bin/ 就是一个普通的目录，从浏览器里面直接就可以访问。除了这个主要的 blog 之外，我还安装过一些其它版本的 MT，为了不干扰这个主要的 blog，我都是用的 SQLite3 数据库的。MT 的 SQLite3 数据库的默认路径是 ./db/mt.db，而这些竟然通通都是可读的。也就是说，外人完全可以下载到这个数据库文件，然后解析出我的密码来。而在 Site5 的空间上，cgi-bin/ 默认的权限就是无法读取的，所以更加安全一些。除了这个，在 MT 的安装文档上，也教了我通过软链接来保存多个办本的 MT 的用法。所以这次安装 MT，我就尝试使用了比较“正统”的方法。

而我说 6A 不负责任，是他们的文档实在是维护的太差了。作为一个软件，文档的第一步就是要教给人们安装。而在 MT 4 的安装文档上面竟然写着：“这是 MT 5 的安装文档，如果你用的是 MT 4 或者 MT 3，可以参考这篇文档，因为安装过程很相似”。但 MT 5 和 MT 4 的安装过程当然是有不同的！过去还好，我只是参考的这篇文档，但这次我要安装这个主 blog，自然要看得仔细一点了。但当中有个 themes/ 目录，我怎么也无法从文档的指定目录上找到，反而在上一级目录上能看到它。为此我下载了 MT 5rc3，果然找到了文档上的路径。原来这个路径是 MT 5 才有的。像这种东西，如何能让用户理解呢？

如果 MT 5 已经发布了，是 MT 的主要版本，这也就算了。可在 MT 5 正式版两次跳票之后，目前在日本之外，MT 的正式版本还是 MT 4。而 6A 匆匆忙忙的就把文档给换上去了，让人觉得比较莽撞了。而且，新的文档上去了，旧的文档能不能有个 archive 呢？

如果这事情只发生在 movabletype.org 上，也还算了。但我在找不到 MT 4 的安装文档之后，觉得 MT Pro 作为商业的版本，应该文档都比较正式，于是就去 movabletype.com 上去找了一找。结果发现 MT Pro 的安装文档直接指向的是 MTOS 的安装文档，也就是我之前看到的那一份。虽然 MT 的商业版本有针对个人用户的免费版，但 MT 的开源版本与商业版本面向毕竟不同。开源版的使用者可以钻研，所以给一份不完美的文档、甚至不给文档都可以，但商业版的文档竟也是这个样子，让我觉得 6A 是不是有点儿戏呢？

如果 6A 是一群爱好者组成的软件小组，这事也就罢了，但作为一家商业公司，6A 对待文档的态度，我觉得是不可以的。

我对 MT 和 6A 是很尊重的。虽然我不是像王建硕那样的早期用户，足以在 7 年多的时间里对 MT 不离不弃，但也是先用了 WordPress 再用到 MT 的。对于个人的 blog 工具来说，是否静态的影响并不是特别大，但对于后台的执行速度，MT 给我的冲击力实在是不小。虽然在换了新主机之后，这种速度的问题解决了，但我仍然对 MT 抱有谨慎的态度。

25 日中午一点多钟，我刚下床，看到 leeseon 从 Google Talk 上告诉我他已经买了 Site5 的虚拟主机了。我当时心想好日子终于来临了，就什么都不顾的去答复 leeseon 了，很快就在后台看到了 leeseon 已经为我添加了这个域名，因此我要做的就是更新这个域名的 DNS 解析了。

我在 24 日写完了上一篇文章之后，便迫不及待的开始备份在 Dreamhost 虚拟主机下资料了。虽然 leeseon 说 DH 主机明年二月份才到期，但在年终加上圣诞节的缘故，Site5 有折扣活动，因此他告诉我会在年底之前把主机买下来。到了 24 日，我觉得离年终应该没几天了，于是就备份资料，所以连 blog 也不再更新了。当时觉得这样做挺合适，但没想到更新 DNS 的速度实在是慢，所以我直到现在才写了新一篇的文章。

当我把资料备份好了之后，我就立刻上了 GoDaddy 的后台，修改了这个域名的 DNS 地址。我在测试 Site5 的主机的时候，用的是另外一个备用的域名，结果凌晨更新的设置，到了中午去了学校之后就生效了。所以说我觉得这次更新设定应该也不会慢才对。不过我那天从下午一直盼到晚上，当中不停的刷新，但看到的总是我的就的网页的地址。我中间又到过 GoDaddy 的后台里检查了一遍又一遍的设定，生怕是我输入错误，但总也找不出错来。我还试着把 DNS 弄到默认再弄回来，还是没有用。

当中有一阵子似乎是生效了，我的首页上显式的是淡淡的墨绿色背景的 cPanel 的 Apache 服务器设置成功的消息。偏偏这个时候我发现我无法从 Site5 的后台进入到设定了，也就是我的域名信息不见了，所以说我也不确定这个 cPanel 的消息是来自那个主机。当时 leeseon 不在线上，我也没法问，不过之前从来没有遇到过这个消息，所以我估计是 DNS 已经生效了。而且有人在 Twitter 上给我说我的 blog 进不去了，我也估计是 DNS 生效的原因。但郁闷的是我进入 blog/ 目录下之后，却依然看到的是我的 blog。到后来连首页也回去了过去的首页的样子，似乎 DNS 的更新又完全失效了。而我通过 DNS 工具查看我的域名，DNS 明明已经是 Site5 的了啊。没办法，所以我只有继续等待了。

到了今天，leeseon 在网上回复了我，并帮我重新设定了站点，于是后台的域名设定则又出来了。到了晚些时候，我终于发现域名打开后有变成了 cPanel 的消息。我在用测试帐号的时候，添加了域名并等 DNS 设定更新完毕之后，从浏览器里访问直接就是 public_html/ 里面的目录列表，可不是这个 cPanel 的提示信息。我通过 ssh 查看目录，也发现在 public_html/ 目录里面有些隐藏文件，于是我就打开两个帐号的后台一一比对。后来我看到正式的帐号里面的 FrontPage 扩展这个功能打开了，而在测试帐号里面这个功能是关闭着的。我看了介绍，这个功能似乎和微软的 FrontPage 这个软件有关，我又不用它，于是就把这个功能给关上了。果然关上之后 public_html/ 目录里面的一些隐藏文件就没有了，但浏览器里显式的还是 cPanel 的消息，无论我有没有在目录里面放上 index.html。

没办法，我只好仔细看看上面怎么说的。结果上面说如果这不是你预期的结果，就应该联系管理员。于是我就去找了 Site5 的客服。和上次一样，在线聊天的客服帮我创立了一个 ticket，然后我就等回复。回复说我的虚拟主机上的 DNS 设定有问题，帮我改过来之后，说是这个设定要 90 分钟才能生效，他们到时候会通知我。我于是觉得 Site5 的客服确实态度很不错，我接触过的虚拟主机公司的客服除了 Site5 外，就只有 iWeb 了，虽然没有什么发言权，但作为普通用户来说，这种服务算是很周到了。到了 90 分钟后，设定还没有生效，但对方已经发了邮件过来他们会继续观察。而又过了一会，他们给我发邮件说现在问题应该已经解决了，我看了一下果然已经可以显式我上传的测试网页了。Site5 客服还有一个比较贴心的内容就是交流的记录都可以保存下来。除了聊天记录在服务结束之后可以选择发送到邮箱外，我今天才发现在后台的 Support 标签下会记录你每一次通过 ticket 和客服交流的过程，这一点我过去从来没有遇到过。

这一点弄好之后，其它就基本上没有问题了。我于是就把 DH 主机上打的包放进公开的域名目录下，然后从 Site5 的 ssh 里面直接通过 wget 下载过来。我怀疑这两个公司用的机房是不是很近啊，我这种下载的最后平均速度竟然达到了 9 Mb/s。而我下载 6A 公司主机上的 Movable Type 的速度才只有 600 Kb/s。不过顾不上兴奋，我就想先把 blog 弄起来再说，因为测试时使用 MT 的速度实在是让我太爽了。

我用了 SSH 的方法安装了 MT 之后，就 import 了之前 export 下来的文本文件。一开始我用的是 restore 的，结果提示有错误发生。其实正确的做法是使用 backup/restore，这样在后台上传的图片之类的信息（不止是图片文件）都会备份下来。而我过去不知道应该这样，就一直 export/import，但这样转移的就仅仅是文章。过去已经这样弄了几次，很多附件的信息早就丢了，所以我也不在意这次是用的什么方法了。重新生成站点后，把过去的 uploads 目录和 asserts_c/ 目录都复制到新的域名下，站点看上去就正常了。MT 就是这点好，静态化的结果，无论后台是怎么样，生成的结果都是完美的。

等我把这一切搞定之后，我去了 phpMyAdmin 看一看 MySQL 数据库的效果如何。其实也就是瞎看看，基本上看不出什么道道来。但这次我却悲剧的发现，数据库的字符集设定竟然是 latin1！！！天杀的 Site5，我在用测试帐号的时候检查过 phpMyAdmin 的启示页面，那时的字符集明明就是 utf8 的，怎么这会一下子成了 latin1。我在 2007 年用 WordPress 的时候遇到过这么一遭，到后来一直没有遇到过这种问题，这下子一下出现我也有些措手不及。我试着从 Operation 里面直接修改数据库的字符集设定，然后数据库这边的内容变成了乱码，MT 后台的文章也全部变成了乱码。天杀的。

我没有仔细考虑解决方案，而是平感觉找了条最简单却未必简捷的方法，就是重新生成数据库。我 Drop 了所有的表，重新运行 mt.cgi 程序，然后重新进行各种设定。结果导入完毕之后，后台竟然直接就成了乱码。奶奶的，实在不行就删除了这个数据库，重新建立，然后马上修更改字符集的设定，然后再安装。结果还是一样。我觉得我可能要修改了全局的变量才行吧，但我似乎又没有这个权限，只好有时间找 leeseon 或客服帮忙了。

不过，我倒懒得再弄 phpMyAdmin 了。MySQL 不行，我就直接用 SQLite3。我在测试 MT5 的时候经常用它来做数据引擎，一点也不耽误正常的数据库服务器，是我的最爱，我日常写数据库相关的程序也用它。其实我觉得个人 blog 上用 SQLite3 和 MT 应该也算是绝配了，只是不明白为什么 MT5 要放弃它。不过我看 MT5rc3（目前日文版之外的最新 Release Candidate 版本）的 mt-wizard 里面的数据库设置的下拉菜单选项中，还能看到 SQLite3 的名字，希望 6A 能够回心转意吧。其实我这次首先选择 MySQL 就是因为 MT5 会把 MySQL 当作主要支持的引擎，因此才放弃 SQLite3。不过 6A 已经有转换方案，而且目前的 MT5 版本对我来说都有个致命的 bug，我也许会在刚发布一段时间之内无法使用这个版本，所以我这次用 SQLite3 也没有什么顾虑。

结果上传了现有的文章之后，得到一个 4.3Mb 的 SQLite3 数据库文件，我目前的 400 多篇文章的数量来说，数据库这方面我感觉不到会影响使用的速度。不过我目前也仍然在测试当中。

但至此，使用新服务器的幸福日子应该开始了吧。昨天和 leeseon 聊天的时候，他说 Site5 可能是他在换到 VPS 之前最后使用的虚拟主机了吧。我目前对 Site5 的虚拟主机感觉还不错，但我的心里还有一个 media temple。网上对它的评价是虚拟主机的终点站，也就是一旦用了它之后，在虚拟主机方面就不会考虑别家的了。不过它的价格比较高端，最基础的 plan 是 20 美元一个月，所以很多人都是一起合租的它的虚拟主机。不过我测试过那些用 mt 的人的网站，感觉速度上也一般，自己从心里比较一下，除了操纵的体验之外，想不出 mt 比 Site5 强很多的地方。也许某一天自己有钱了，会弄个 mt 的空间来满足一下这个“夙愿”吧。 :)

我在之前的文章里说过，我在 Site5 的实验用的主机上测试 Movable Type 发布时的 CPU 负载问题时，意外的发现在 MT 的 Dashboard 里面提示我说找不到 Image::Magick 模块，并且在 Site5 的论坛上没有找到答案。

我当时说应该不影响是用，但还是觉得如果能解决了最好，于是在晚上就在 Google 上搜索，找到了一篇文章。文章里说如果 ImageMagick 模块无法使用，可以在 mt-config.cgi 里面加上一句 ImageDriver NetPBM 来使用 NetPBM 来代替 ImageMagick。我测试了之后果然可以，可以正确的处理我的头像了。我没有测试在加上这一句之前有没有在发布文章时插入图像不成功的经历，反正加上后我测试发布一篇带图像的文章是没问题，包括生成缩略图、改变大小等操作。

然后我又在 Settings 里面随便点点，却发现在 Feedback 下面还有错误提示。原来是说，因为没有 ImageMagick 模块，所以 CAPTCHA 就无法使用了。我目前的 blog 也没有使用 CAPTCHA 来过滤垃圾留言，用 Typepad AntiSpam 就能过滤绝大多数留言了，而有些人工的弄一些英文的通用留言用语的，数量就不多，我手工过滤也能过滤出来。不过我想，虽然今天不用，难保哪一天会用到？总之如果能把事情解决是最好，于是抱着这种想法，我就去了 Site5 的首页找到在线的客服 livechat。

虽然我发信息过去的时候是半夜，不过 Site5 提供 24x7 的客服服务。我在输入自己的名字、邮箱地址、我的域名、以及问题之后，系统会把我的问题分配给一位客服，然后会在浏览器里出现一个对话窗口，我就在里面同他交谈。

客服首先问我我在上一步填写域名是不是指向我目前发生问题的主机，我说是，然后他进行了一些操作，估计是在后台重新安装了一下 ImageMagick，然后让我重试一下。我刷新了一下 MT，还是有问题。然后他问我是不是我需要的是个其它名字的模块，我于是提供给他这个网址，他在过了五、六分钟之后让我再试一次，如果不行的话就让我告诉他出问题的网址，他们好调查原因。我试过后问题依旧，于是就把 MT 我的帐户的名字和密码改了，告诉对方。结果对方却莫名奇妙的说需要 “submit a ticket to have this fixed for you”。我莫名其妙的想了一阵子，才觉得应该是这位客服没有权限来处理这种（或许是）涉及到客户提供的网址的问题，所以向上级提交了一个 “ticket” 来申请相关的权限。

我在等待的时候，却突然发现 chat 窗口变成了给这位客服评分的窗口，我也收到了一封措辞“冠冕堂皇”的来自 “Site5 Level 1 Support” 的感谢邮件。本来有些安心的我更加莫名其妙了。什么意思？问题就这样放着不管了吗？这样子就算解决了啊？我当下有点气愤，这算什么客服？于是我也在评分表上照实填写，服务态度、语言的语法、还有是否一直在问我相关的问题都给高分，至于是否给我提供了有用的信息和是否解决了问题嘛，低一点算了。

在提交了评分之后，我正在安慰自己没有 ImageMagick 一样用的时候，却发现我的邮箱里收到了 “Site5 Level 1 Support” 的又一封邮件，说他们已经安装了相关的 Perl 模块，让我试验一下。这时我才意识到我可能是错怪了刚才那位客服：他 “submit a ticket” 不是为了申请权限，而是直接把我的问题转移给了上一级的客服，由上一级的客服来帮助我。我于是又打开了一个 livechat，说我刚才不小心的关闭了 chat 窗口，问怎么回复问题。结果正巧碰到了同一位客服，他告诉我直接回复那封邮件就行了。我在这次评分时，全都给了高分，算是我刚才错误的补偿吧。不过 Site5 用了 “ticket” 这个莫名其妙的词来表示“问题（problem）”这个含义，并把假设询问的用户都知道这个词的含义，也算有一部分的责任吧。

我于是回复那封邮件说还是有问题，对方叫我清空 cache 再试一遍，我照做了之后自然还是不行。等我再次回复后过了一会，就收到了一封 Site5 自动发送的信，发信人是 “Site5 Level 2 Support”，说是因为我的情况复杂，这个 “ticket” 需要系统管理员的关注，因此被加入到 Level 2 的 queue 中了。果然 Site5 的客服是层级式的，这一级解决不了的问题就送给上一级。这个 Level 2 可能人手不多，我是在收到这封自动邮件之后大约四十分钟之后才收到进一步邮件，说是在看我的问题，等有结果后马上通知我。然后又过了将近三个半小时，我收到邮件说 ImageMagick 的 Perl 模块不支持 64 位环境，所以解决问题是一是我用一个替代品，二是把我的帐号转移到 32 位的服务器上。

到了这时我就觉得比较满意了。考虑到我对这个模块的需求状况，以及我这个帐号只是用来测试的，我就给对方回信说不用麻烦了，并客气的感谢对方。一会对方也回信说不客气之类的套话。

总之这是我在这两天之中遇到的第二次 64 位兼容性问题了。我在 07 年玩 Gentoo 的时候，其中有一个最关键的参数就是选择机器的 Arch。我当时的 CPU 好像是 T7300，好像是可以使用 x86_64 了，但我还是选择了 i386 架构，原因是从文档上看到还是 32 位上的软件多。当时我觉得自然而然，没有在意这个问题。结果两年后的今天，64 位大行其道，我却忽略了这个问题。不过这两个问题也给我上了印象深刻的两节课。

昨天早上，之前给我提供主机空间的 leeseon 在 Google Talk 上跟我说，他的 Dreamhost 快要到期了，他打算搬家到 Site5 的主机上，问我要不要一起合租。

我看了一下 Site5 的主机配置，感觉还不错。最主要的几点是有 SSH，PHP、MySQL、Perl、Python、Ruby 的版本也比较新，还预装 Rails。我最近主要在学 Django，预装 Rails 的话说明装 Django 应该也没什么问题。两人合租的价钱（hostPro 计划）也还可以接受，于是就答应了。当时最担心的还是 Movable Type 的问题。MT 在发布的时候会需要比较高的资源，整站生成的时候更是如此，我看过不少用 MT 的前辈，比如 Fenng，就抱怨过几次 MT 占用资源导致的 500 错误的问题。到时候搬过去了却无法生成 blog 网页就苦了。于是我马上就问 leeseon 主机的 CPU 资源有没有什么限制，对方也没有考虑过这个问题，但他从 Site5 的网页上找到了限制条款。我扫了一下，就是对 “Utilize in excess of 15 seconds of CPU time.” 这一条比较担心，是不是意思是一个进程如果运行超过 15 秒就有问题呢？后来想可能不是这样理解的，因为 httpd 之类的进程肯定会运行时间更长。所以我心里是挺担心的。好在 Site5 有 60 天退款的策略，我就跟 leeseon 说买来后先试试，不行的话就退掉。

然后 leeseon 告诉我说 Site5 有免费试用 30 天的 COUPON，我就赶紧注册了一个试试。开通网站是比较慢速的，我有一个备用域名，添加进了 Site5 的帐号中后一直说让我等待。由于 Site5 的页面上没有提示我，所以我过了一会才想到需要更改域名的 DNS 才对。Dreamhost 上添加域名后可马上会说的清清楚楚的。而且我还不知道 Site5 的 DNS 是什么，最后是从它们的 Wiki 上找到的，这也让我比较吃惊。我在 GoDaddy 那边修改 DNS 也挺慢的，修该完之后我一直刷新，一直是显式我过去在 Dreamhost 上的内容。

到了昨天晚上，我又刷新了一次，发现已经显式新的内容了。我在 Site5 的后台也可以操纵了。首先就是打开 SSH 访问，然后我还花了一阵子功夫来找我的密码和用户名。总之进去了之后，发现我的提示符竟然是 #，不知道是不是意味着我是 root 帐户。不过我没有多想，只是来回看来看去。我首先输入的是 “dja”，然后按 tab 键，果然出现了 “django-admin.py”，主机是预装了 Django 的，不错。我接着运行了 “django-admin.py --version” 查看版本，告知我是最新的 1.1.1 版本，心头不由一阵窃喜。然后就顺便看看其它工具的版本，gcc 是 4.1.2 的，挺新的，我在 Dreamhost 上才是 3.3.5 版本；Rails 是 2.3.5 的；Python 默认是 2.4.3 的，但也有 2.6 和 3.0 的版本的，都挺不错的，在 Dreamhost 上只有 2.4 的。运行 uname 得到内核版本是 2.6.27，是 x86_64 版本的。没有写是什么发行版本，但 gcc 给出版本的时候返回的是 “gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)”，所以我估计应该是 RadHat 吧。

看了一会之后，想到我的主要任务是测试 MT 的发布有没有问题，于是我就下载了 4.32 版本。下载之后我突然想测试一下访问的速度怎么样，就把这个 5.6M 的 MT 文件放到了 http 目录中，在浏览器里下载，看到速度慢慢的升到了 500K/s 多，也挺不错的。解开包之后，我按照 MT 的说明就装上了。装上 MT 后我第一个感觉就是“快”！在后台的设定什么的，都非常流畅，简直不是现在可以相比的。但是 MT 说找不到 ImageMagick 包，因此没法让我上传头像之类的。但我在 SSH 中确实看到了有 convert 之类的命令。我搜索了一下 Site5 的论坛，有人遇到过类似情况，但没有人给出解答。Site5 官方支持的 blog 程序列表里面没有 MT，所以我估计没有做相应的配置。不过我暂时估计问题不是很大，就先放一放，能否生成整个站点才是重点。

于是我从这边直接导出整站的文章，然后从那边导入。我的导出文章的文件有 1.8MB 大小，我从那边开始导入后，就看着 Chrome 左下角指示的上传进度。然后到 100% 之后几乎是一眨眼的功夫，就告诉我导入完毕了。我当时就有点震惊，这是真的假的啊？要知道我在 Dreamhost 上测试的时候，导入同样大小的文件至少要花费 5 分钟左右。该不会是导入出错吧？不过我在后台确实看到了有 400 多篇文章。然后我没怎么做其它设定，直接就点了 Publish 按钮，然后就在 SSH 中运行 top 命令，看看 mt.cgi 执行的情况。

其实我获得的信息不太多，只是看到 mt.cgi 的 %cpu 那一栏是 96.x 以上，因此挺担心的，会不会被系统给 kill 掉。我确实看到过几次有 mt.cgi 跑到列表的下面了，出现了一个新的什么程序，但一会 mt.cgi 有上去了。不过看 MT 的发布框的进度条就比较有意思了，基本上是呼呼的往前跑，我在 Dreamhost 发布的时候都几乎看不到进度条在动，特别是当发布单篇的时候。而我看了一会，就告诉我已经发布完毕了。我看了一下报告上说的时间，只有一分多钟而已！我目前的 blog 有 400 多篇，在 Dreamhost 上发布一次需要 45 分钟另几秒的时间！我看到这个结果，几乎马上就疯掉了，当时惊讶的都喊出声音来了。

然后我还测试了其它的地方，比如说在这里，用户能发现最慢的地方就是 tag 了。我在这个 blog 上用了 AnySql 的缓存，因此当第二次点击同一个 tag 时，会直接把缓存中的页面展示出来，缓存的有效期是 24 小时，但当没有这个 tag 的缓存或者缓存已经过期了时，速度就会特别的慢。而我在测试的 blog 上面做了个实验，单击一个 tag 后，几乎马上就出现了页面。搜索也是一样，留言的速度也不是这里可以比的。我目前的测试网址在这里，读者愿意的话，可以和我目前的 blog 比较一下速度，可以有很明显的感觉。

所以我在试用了 Site5 的虚拟主机之后，我才明白了一件事情：6A 之所以把 MT4 的速度弄成这样，其实不一定是故意的，而是在他们的主机那里，MT 跑的确实很快。我们买不起好的主机，用的都是 Dreamhost 这种廉价主机，所以才会有“MT 太慢了”这种想法。相同的，MT 目前已经不是一个最主流的 blog 系统了，它对主机的要求也较高，所以用 WordPress 会得到更好的速度，Site5 也官方支持 WordPress，这一点倒不是我非常想见到的。

不过，我也有点怀疑，有点卑鄙的想──可能 Site5 为了宣传，所以把这些免费的 30 天试用帐号都放在比较空余的主机上，这样速度就快了，而正式使用后速度就下来了。不过我是希望我想多了吧。

总之，在试用过 Site5 上面跑 MT 之后，我就像吃了美味大餐一样，就不想再回来嚼蜡了。我是希望可以尽快转移到 Site5 那边去，并且（有可能的话）就再也不用 Dreamhost 的虚拟主机了。

这个月初我发现我的 blog 有很多的坏链的问题。最主要的原因是我更换 blog 程序后导致链接的变动，还有 WordPress 和 Movable Type 的 Trackback 格式的差异也是个问题。文章本身的 URL 倒也罢了，我通过在 404 页面上加上了说明文字，勉强算解决了这个问题。但文章内的链接错误，就很让人讨厌了。我当时是通过 Google Webmasters Tools 发现这个问题的，当时也没有办法把它们一下子都找出来，更别提统一修改了。于是当时的策略是发现一个就改一个，一段时间后总会有所改观。

今天在网上搜索 Site5 的资料的时候，看到了有人说他的 blog 用 Xenu 来消除坏链，我当时想，Xenu 是不是也适用于我的情况呢？于是我就去了 Xenu 的网站，找到了这款软件。软件是 for Windows 的，不过也不怕，像这种小型的工具类软件，用 wine 模拟就可以了。我没有单独安装 wine，其实是直接从 WinApps 系列里面直接调用命令而已（WinApps 已收费，我是在收费前下载的）。进行一遍安装程序之后，就可以使用了。运行的结果如图：

除了窗口本身的提示外，Xenu 还问我关于我的服务器的 ftp 之类的问题。我填写了我的情况，可是没见到有什么效果。过了一会，它从我的浏览器里弹出了报告，我从报告里找到一我的 blog 的地址开头的链接，进去把相应的地方修改过来就行了，重复的 Trackback 也顺便清扫了一下。

这样一番下来，blog 内部的坏链应该少了很多，但其实我也怀疑并没有全部都解决，不过已经比之前好很多了。

这篇文章是我两天前就想写的，不过这几天实在没什么时间，所以拖到周末。

那时我在 RWW 上看到一篇文章，报道 Wolfram Alpha 的 iPhone App 程序下架的消息。Wolfram Alpha 本身是一个搜索类型的网站，用户在搜索框中输入数学公式，Wolfram Alpha 会给出各种样式的结果。由于 Wolfram 公司的主打产品是 Mathematica 这套计算机代数系统软件，因此 Wolfram 给人的感觉就像是在线板的 Mathematica 一样，尽管它在信息方面的功能应该更强大一些，比如如果搜 “gdp China versus gdp US”，就会告诉中国和美国的最新 GDP 数据，然后有两者之间的比较。我并没有用过 Mathematica 软件，因此不知道具体的情况是不是真的。

而这个程序的特别之处，是在与它那 50 美金的价格。我也是之前从 RWW 上的一篇文章看的。当时看那篇文章的时候，想写文章讲讲这事，但一来我没有用过 Mathematica，二来我没有 iPhone，三来我用 Wolfram Alpha 的次数也少，觉得没有太多可写的，于是就没有管它。没想到一个月不到就有了这个新闻。

当时我在看报道的时候，那篇文章里有在 iPhone 上运行 App 形式的程序与在 iPhone 上的浏览器中在线使用 Wolfram Alpha 的对比的截图，我当时看了，觉得其实程序做的是不错的，很漂亮：

从图上看，我感觉这个程序非常适合用作一个 iPhone 上面的高级计算器。不过，我不认为把一个免费的 B/S 程序改造成一个 C/S 程序，就可以卖 50 美金。如果它的价格可以限制在 5 美元之内，甚至 10 美元之内，我觉得都应该会借着 iPhone 和 iPod touch 赚一大笔。因为毕竟这个程序不是把整个运算系统都写在程序里卖给用户，也是需要连接到 Wolfram 的服务器上才行，Wolfram 只是给 iPhone 访问作了一些优化而已。所以哪怕是可以借着互联网让用户感觉不到在线与离线的区别，Wolfram 也不应该把一个客户端买到一台计算器甚至 Mathematica 软件的价格。

现在在线的应用给我的感觉是，只要能圈住大量的用户，就不愁赚不到钱。比如 Twitter，自始至终都是免费的，作为用户，我有时也不免疑问，创始人靠什么赚钱？结果还不是一直到现在还气势满满，投资者也信心十足。有了用户就有了赚钱的资本，像 Wolfram，借着自己的代数软件这么大的知名度，如果打免费牌肯定能圈起一大批用户。到时候随便出出主意，应该就能盈利。

其实我现在对其感兴趣，实际是因为我当中用了几次 Wolfram Alpha，感觉这个系统确实很棒。我上次的密码学作业，有道题需要做简易的 RSA 解密。我需要写程序把一个大数分解成两个素数的乘积。得到的结果是否正确呢？我就放进 Wolfram Alpha 里验证一下。速度快，而且也让我放心。特别还有设计到有限域，进行运算后都要对一个数取余数，手工做的话经常会搞错、迷糊，在 Wolfram Alpha 里，只需要简单的把方程告诉它，就可以得到结果。所以我觉得，如果能把这么个东西放在手机上随身携带，应该会方便不少人。

前两天看的文章里说，Wolfram 关闭了专门给 Mobile 优化的页面，理由是因为用的人太少了。这也符合了我之前的设想：别以为用 iPhone 的人都是有很多钱、可以动不动就花 50 元去买程序的人。事实上，很多 iPhone 用户都是追求时尚的年轻人，虽然这些人很多都是在校学生，对这种计算工具也很需要，但对于计算力的渴望并不能使他们毫不犹豫的花 50 元买个客户端程序，毕竟考试的时候是不允许用这种电子产品的。

写这篇文章之前，我特意去了 Wolfram 的网站，找到了 iPhone 应用程序在 iTunes 商店的链接，进去看了之后，发现现在这款程序只买 19.99 美金了，旁边写着十二月 11 日至 31 日假期促销：

而后面的评论里，看到有一位用户写道：

After using for a while found that is very limited in scope of words and practicality. Would benifit with much continual expansion as many common words are not found or useful such as green tea. Not worth 50 bucks unless this project grows.

看到一共有三则评论，另外两则评论则给出了还算不错的评论。只是不知道这三个人现在知道这个程序降价超过一半以上后会怎么想。

日子忙啊，调整页面的 CSS 竟然成了暂时的休闲活动，真是让人苦笑不已。

今天在写完前面那篇文章之后，有把讲 CSS 中文字体设定相关的几篇文章以及一些衍生的文章又看了一下，似乎若有所悟，于是就又打起了修改页面的 CSS 的主意。

之前我对页面不满意的地方主要是页面标题粗细不均匀，看上去粗一片细一片的；还有就是某些字（比如“关”），显式明显比其它字窄一些。之前试着修改过这些问题，后来一直没试成功，最后不了了之。

现在 Firebug 越用越熟练后，也越来越感觉到它的强大。用它的可视化工具来定位哪个部分归 CSS 当中的哪几行管十分方便。然后我有简单复习了一下 id 和 class 的区别，改了改字体，就好了。之前我一直用的是英文字体设定，结果因为没有设定默认的中文字体，所以导致一些中文字显式很难看。结果显式的把黑体、雅黑、宋体等一些中文字体加入到 font-family 当中去，就比较好看了。

定位文章的标题时花了一点功夫。在尝试了几组不同的组合之后，发觉设定了 .asset-name, .archive-title 之后就起作用了。同样修改的还有 widget 的字体，这样左下角“关于我”这三个字就显式正常了。

现在多数网页的链接已经不加下划线了，找了一组比较通用的设置，把默认下划线也给去掉了。

借着打开了 Firebug，我本来想顺便修修后台写文章时标题的字体太难看的问题。地方也找到了，从 Firebug 里面测试也 OK 了，但就是加在文件里面后就不起作用。之前我傻乎乎的以为后台的 CSS 设定和页面的放在一块，所以就一直改页面的 CSS 文件。最后看了看 header 才发觉后台的 CSS 是单独设定的。不过，到了最后我也没找到调整后台 CSS 的方法，反正觉得文章区域已经显示正常了，标题就暂时不管了。

MT4 的 CSS 设定还是很方便的，我这一切做的都是在后台 Design -> Templates 下面修改了 Stylesheet 而已。修改后的内容如下：styles.css。

这张图是我今天上午上Facebook上截下来的：

我觉得这是一个积极的网络环境。可惜在国内，Facebook会被校内代替，蔡智浩想在上面贴自己的Twitter或Plurk估计都很难。后面因为蔡智浩说Facebook没有备份机制，然后别人回复说Facebook的封闭性是它的缺点。当对岸嫌Facebook封闭的时候，我们还在校内上不亦乐乎。

到现在我好像很长时间没有登录校内了。过去经常登录的原因是害怕丢失了同学的消息，后来觉得没必要了，因为很多消息都属于八卦一类的，原创内容也少。我于是就想，能不能从此戒掉校内呢？没想到现在居然成功了，看来校内上的很多信息对我没有用。

昨天在查看blog的流量统计时，翻到了之前写的一篇文章。那时饭否刚刚开始自己停止了服务，官方上的说法还是几天后会重开。那个时候我也觉得饭否想避过那时的风头，等着过几天会重新开放，但没想到饭否会一直死到今天。

我在那篇文章里说，同样是无法访问，饭否是主动封锁，用户用什么方法都无法登录，而Twitter是被动封锁，只要能翻墙，还是可以使用的。当时我没有想到饭否会一直无法恢复，因此心里也没有现在这么肯定，也一直在担心。担心的点是Twitter在长期被封锁下，会导致中国用户的离开。我在Twitter上follow用户的原则是只follow我认识的，其它的一些名人什么的一概不管。确实名人们的Twitter会有丰富的信息，但也会让我的信息负载加重，反而影响了我对需要信息的获取。这个原则让我的follow列表长度保持在20之内，也就是说我经常交流的Twitter用户只限于不倒20人。而里面经常发言的又更少了。如果这些人之中有人离开了Twitter，我的交流渠道就会大大减少。

新浪微博发布时，我觉得可能会是一个冲击，不过并不十分担心。因为我一直觉得新浪对于blog、微博这些东西掌握的不好，做出来的东西华而不实，不会吸引Twitter用户，而国内微博服务的用户的去留与我无关。另外，新浪微博的封闭性也阻塞了它的流传。除了API方面的种种之外，首当其冲的是其封闭注册的性质。而更过分的是，不注册却无法浏览别人的页面（最近好像有改善），这直接阻止了我对其进行评估，也断掉了我使用的可能。而且邀请注册的吸引人的前提是别无分号的东西，gmail邀请的时期其成功是因为没有免费的1G邮箱，Google Wave邀请的抢手也是如此（顺便说一句，手里还有19个邀请，不过我谁也不给，哈哈）。新浪微博在这种情况下弄个邀请，如果除了对自己的服务确实没有信心，那就纯是在装逼作秀了。

真正让我担心的，其实还是像饭否这种国内的专注于微博服务的公司。首先是它们有口碑，对人的吸引力更大；其次是它们的服务，对于普通用户来说，确实也能与Twitter一拼，而且像客户端什么的也都挺火爆的。所以我那一阵子是挺怕那些公司把Twitter上的用户吸引过去的。不过它们自己本身也有问题，最大的问题是天生就有的。“合则力强、分则力弱”，本来在国内还算小众的微博用户群，被几家给瓜分了，就更加难与Twitter抗衡了。Twitter不像电子邮件，目前使用者被固定在一个公司的服务中，就很难和别的服务互通。什么时候这个问题被真正解决了（嘀咕那种的迂回同步不算真正解决问题），国内微博才有能力真正和Twitter一拼。不过就算这样，我也不希望我follow的Twitter用户离开。

而饭否的关闭，则帮了我一个忙。

首先是饭否用实际行动证明了微博服务在国内的不可控性。你的发言，可以在任何情况下，仅仅因为一个理由，就全都消失一空，朋友之间的联系也因此而丧失。饭否是国内微博服务的佼佼者，口碑数一数二，由“老大哥”来做示范确实很有效果。而且，饭否在这么长时间之后都没有兑现当初说的十几天之后恢复的承诺，反而积极删贴的新浪微博倒还好好的，这也告诉了用户──除非饭否做到新浪那个份上，否则饭否则很难继续下去。这也让用户知道了，真正能体验微博服务，只能找国外的公司，也就是Twitter。所以现在，尽管我的follow列表里在国内的同学都无法正常发推，但总有工具可以帮助他们和我完成Twitter上的交流，而且他们的发言频率也并没有因此而减少。

所以我昨天看到了之前写的文章，不由的觉得应该对饭否说声谢谢──你给国内的微博用户上了宝贵的一课。

另外，今天看到月光贴了篇文章，说百度发布了自己的微博产品──i贴吧。我过去看了一看，里面也有一些名人的头像。我点进去看看，感觉就像是一个论坛上的某位用户的发帖列表，里面没有几篇发言。不过每一篇下面的用户回复则几乎全是“沙发”、“留名”之类的东西，我于是知道了什么是中国特色，同时也完成了对于i贴吧这个产品的定位，并对Twitter的稳固地位更加放心了。

其实也不是最近，挺早之前就已经觉得时间不够用了。

小时候几乎没有这种感觉。我在小学阶段是以能熬夜闻名的，初中也是。小学起不知道怎么着，我写作业的速度特别慢。现在想来作业未必算很多（当然有很多例外情况），只是经常对写作业有种逆反心理，写作业时感觉不到快乐，反而书橱里的种种书籍，或者小时候对着台灯进行天马行空的幻想，则对我更有吸引力一些。

我第一次印象里睡觉很晚是小学一年级，当时在父母的卧室里床旁边的一个床头橱上写还是汉语拼音的作业。那时我对作业没什么概念，因此母亲总是陪着我写作业。什么时候她说行了，我也就放心的去睡觉了。我第二次熬夜写作业是在小学二、三年级的时候，第一节语文课学的是“安徽黄山”之类的名胜的名字。当时在课堂上老师就让我们把一些词语什么的抄写多少遍，我那个作业就没完成，于是晚上的作业就变成了白天的课堂作业+晚上的家庭作业。两个作业和着搞到我大概凌晨两点半才上床睡觉。当然类似的情况有很多，但这两项是我印象里最深刻的。我有时和同学聊天的时候，说起我的熬夜经历，都会让他们惊叹不已。

上初中后我对作业有了较强的控制能力了，晚上基本上都可以在11点前完成作业。不过那时起我更喜欢读文学或计算机方面的书，经常在睡觉前往枕头边上扔上这么一本，躺在床上看，大概到1点左右关灯睡觉，这或许是那时候我最惬意的时光了吧。这样的日子其实也不怎么影响我第二天的精力，有的时候第二天还能够神采奕奕的去上学。不过到了高中我的这项本领就丧失了，经常有这种情况：睡觉前往枕头边上扔一本书，等上床后盖上被子，知道书在枕头边上，但就是不愿去翻。也不甘心就这么关灯睡觉，于是不知不觉的睡到第二天，灯也没关。那时候我想我也许在高中前就把夜晚都给透支干净了吧，所以到了高中才无法熬夜。

现在想来，其实那种日子也还好。最近的几个学期，我经常感觉时间已经不够用了。我经常有个疑问：是不是年纪越大，对时间的“忍耐力”就越强？小时候人经常有“坐不住”的感觉，总觉得日子太长；而大了以后反而觉得时间过得太快，一眨眼一个小时就这么过去了，中间具体干了什么事？不知道。想象一天也就24小时，出去睡觉、吃饭等，真正能用的也不过12小时，而当中能利用起来的则更少，于是经常感到惶恐，也更能体会朱自清写《匆匆》的心态了。

我曾经思考过一个问题──为什么在国内上学很少有时间不够用的感觉，而在加拿大就这么明显呢？我后来得出的结论是可能我们的时间管理的能力没有培育好甚至根本没有被刻意的培育。

从小到大，我们有固定的教室、固定的座位、固定的课程表，每天有当天必须完成、第二天要交的作业。因此除非那种完成任务非常快的学生外，能有很多课余时间的同学并不多，再加上很多人又被家长报名了“课外兴趣班”，因此导致了真正可由我们自己支配的时间少之又少。总之每天老师、家长都给我们安排好了时间、安排好了任务，反正都要做完，因此怎么安排顺序都没有太大影响。而在国外上大学，课程的时间、地点、教师等都在学期前发布在选课系统上，每个学期学什么课都是学生自己选择。原则上是三到五门课，如果这个学期想轻松一些，就少选课；如果想多点负担，只要课程时间不冲突，就都可以选。作业也是一样，我现在的作业都不是当天布置第二天要交，而是有几个星期的时间让你做，有的甚至是整整一个学期的项目。而怎么来安排这些时间，我觉得这是导致我现在难受的一个根源。

我不知道国外的小朋友上的学是怎么样子的，反正从我自身来说，我觉得国内从小学上过来的同学，对时间的掌控能力都不怎么高明。义务教育的体系让我们没有机会也没有必要去管理自己的时间，因此一旦到了一个表面上宽松的环境，我们则很难正确的规划这些时间，因此导致了现在疲惫的状态。

往深层次去想，我觉得是中国在50年代至90年代的一种思想固化给我们整整几代人带来的根深蒂固的“服从”思想。不光是我们，前几年似乎是刹那间风靡网络的GTD，被很多人奉为圭臬，而这群人并不只是我们这一代的年轻人。其实在这个年代每天上网、“生活”在网络上的人或多或少都算是更加开明了，还有千千万万的人在过着每天朝九晚五的生活，而在九五之外，则难以称得上是生活。

尽管网络的流行吹开了我们的思维，但还是无法和我们的根深蒂固的传统思想抗衡。我看过很多人的例子，想用GTD来改善自己对时间的管理，结果没多久就弃置不用了。我本来觉得是不是东方人与西方人的本质上的生活以及思想有区别，后来才觉得很可能就是这种根深蒂固的想法在影响着我们。

不过话虽然这么说，真要我改变什么，我自问也没有这样的能力。去年暑假我曾坚持在iCal上把第二天几点到几点的日程安排好，并严格执行，结果没几个星期就没继续了。那时候我每天都能把TopLanguage讨论组上的文章都读完，结果记得从8月份的一次因为复习考试而没有读完开始，到了现在我已经有总共29365篇没有读了。现在再看这将近3万的文章，就觉得没有读下去的动力了，导致了恶性循环。事实上怎正能完全把握自己时间的人非常稀少了，平常人则很难有那种坚持的毅力。

其实不止是网上论坛，就连最普通的浏览网页也是如此。我经常看到有感兴趣的东西，就在后台打开一个新标签页，但经常没有机会来得及看。再加上我很长时间不关机，所以标签页越攒越多，经常会有我下定决心，斩断乱麻，把浏览器整个退出的情况。比如说刚才的截图，是我浏览器的标签列表的一半不到：

今天中午的时候看MT官网上在11月6日发布了一篇新文章，说是MT5发布了RC1版本。本来我是没什么兴趣的，但看到介绍说有了新的Theme──Pico，从截图上看也挺好看，于是就从另外一个域名上安装一下试试。

MT从3版本开始的安装程序就已经非常不错了，因此安装起来没有任何困难。但仍然是数据库的问题在困扰我：如果选择使用sqlite来做数据库，默认的数据库路径是Site Root/MT/db/mt.db，但默认情况下，MT目录下面并没有db目录。可如果没有db目录，安装程序在检测数据库的时候就会报错，因此必须手工创建db目录。我觉得程序应该可以做的更智能一点（或者说“不那么愚蠢”），解决这个不算是问题的问题应该不难。我印象里MT3没有这个问题，MT4就有了，现在MT5到了RC1版本还是有这个瑕疵。

MT5自从Alpha版本发布后，我就测试过，但因为不是正式版，因此我一直没有仔细研究。现在感觉我对MT真是搞不懂，website和page、blog的关系越来越复杂了。也许是我的观念没转过来的原因，总之安装好之后让我很困惑。

安装完毕后，我直接建立了一个blog，没想到pico这个新theme不是我想象的那样是之后选择，而是在创建的时候就要决定。我本来是以为pico就是一个普通的theme，可以随时替换的那样，结果实际上似乎比我想的更大。总之选定了之后，发布一看，效果确实不错。我导入了这个blog的导出内容，虽然等了大约5分多中，但最后没有什么问题。导入结束后我查看了一下mt.db文件的大小，3.7M，还可以。看来我的blog目前的规模，用sqlite应该是可以承受的。试着发布了一下，等了又5分多钟，竟然报错了：

我印象里我在尝试上一个版本的时候也发生过这种问题。我一直不清楚是什么原因，也没有去查，只是“祈祷”在MT5正式发布后会有所改善。

我比较喜欢简洁的观感，因此这次的新的pico主题让我比较喜欢，这是首页最上面的截图：

这是首页最下面的截图：

虽然简单，但别有风味，我觉得也是一个不错的选择。而且汉字的显式也很舒服，而不是像MT4的默认设定，让你看着就觉得别扭。在后台的Style设定下，Pico主题有自己的分栏，里面有深蓝、深灰、棕褐以及白色四种选择。我估计通过修改css文件，应该可以手动设定更多的风格：

安装后我一直挺纳闷，为什么主页上什么内容都没有呢？我用的是Classic的页面风格，就是那个枣红色的。我试着创建新page，但也没搞清楚page的设定关系。结果我创建了一个在打开页面后默认显式的page，想当然的把它的名称定义为index.html，结果页面还是空空如也，只是在右边栏上多了一个index.html的链接。点了之后依旧没有反应，我估计是和默认的页面文件名相冲突的原因。于是我在后台删除了我刚建立的index.html这个页面，结果竟然把本来的index.html也给删掉了，直接导致根目录下没有了index.html文件，直接把赤裸裸的目录结构给展示出来了。

我在重新生成了整个website后，发现了一个更让我困惑的地方──website居然就是我的blog在Classic风格下面的展示：

既然website和blog的内容一模一样，只是风格换了，那么website的意义何在呢？当然这也可能是我没有写任何page的缘故。不过website还没有pico风格，如何让website和blog的风格统一，也是一个问题。同样的，希望在正式版中会有所改进。

最后我还是没有搞定子域名的问题。这个问题来源于我想用MT来管理我的整个网站包括首页和blog。我目前首页的网址是http://www.cnliufeng.com/，MT5在新建blog的时候可以设定blog的URL地址，并且有“建立在子域名下”的选项。可当我选定了这个选项后，blog的网址就变成了“XXX.www.cnliufeng.com/”，而XXX就是我要填写的。即使这样设定了之后，子域名还是工作不正常，因此我只是把blog建立在了子目录下面，但我在子域名下写了将近三年blog，就这样切换URL肯定会导致链接问题。而且我也开始怀疑子域名的问题必须在服务器那边进行设置，通过MT来设定是没有办法的。

虽然我目前用UseMod Wiki来做首页感觉还不错，但有一个最关键的问题一直在困扰我──就是wiki不能插入纯HTML代码。目前情况下我在页面里插入HTML代码后都不能正常解析，而是直接把HTML代码输出出来。这样的问题就是我无法在wiki上放badge、也无法在页脚放置Google Analytics的javascript代码。所以我对用MT管理首页还是抱有希望的，同时我也在继续探索其它的wiki中。

PS：目前Six Apart似乎把更多的重点放在了blog之外的交流上。比如今天我在官方网页上看到了上面对于Motion的通告：

我之前讨论过motion，其实就是一个类似Twitter的让人们发布短小信息的社区工具，当然它对信息的格式更宽容一些，但毕竟没有一个很好的交互模式，让我感觉目前与主流社区（Twitter、Plurk）格格不入，所以还是有待观望。不过从上面那个宣传条上，居然看到了Zachary Quinto的名字，去了他的网页一看，果然很漂亮、很绚丽，不过对于个人用户来说，现在并没有看出什么实际用途。

今天在看fred的一篇文章的时候，被他的整个页面所吸引。当时正好又引起了整治一下我的首页的想法。不过与上次不同，这次我不是想用Movable Type来管理，而是用wiki。

当然Movable Type是第一选择，但要整治到我的首页上要做的实在太大，我之前没有这方面改动的经验。我也实在没有时间与精力来研究这些东西，而且我也不敢保证做了改动之后这个blog还能不能正常运转。而wiki则不同，它相对MT来说比较轻量。我之前也用过MediaWiki来建立过站点，对一些设定都比较了解。

不过这次我不希望再用MediaWiki了。MediaWiki是为了Wikipedia设计的，用来做个人的首页太大了，也不方便管理。很多相关的设置都是完全不必要的，比如用户的权限等级。我的首页当然只需要我自己来编辑，其他人能改动的地方应该不多，也没有必要多用户。再者对于个人的虚拟主机来说，MediaWiki的速度也挺让人头疼的。关键是，对于做首页来说，我其实是把wiki当作了出版工具来用，只是用来方便了书写而已，wiki的交互功能，则是越少越好。

其它的要求，主要就是尽量轻量。比如最好不要用Java的，最好不需要用数据库，或者支持sqlite也行。其实我在去年有想法是自己用Perl之类的语言写一个转换程序，我用wiki格式的文件来直接写页面的正文，保存在一个固定的文件夹里面，这个程序结合提前设定的模板，来生成html文件。其实就是不使用数据库的MT，或者blosxom。但后来没有时间来写，只好放弃。

我从Wikipedia上找到了一个wiki程序比较表，然后根据我的要求比对，第一个找到了UseMod Wiki。看Wikipedia的历史，早期就是用的这个wiki程序，后来由于负载的原因才又开发了MediaWiki。看来口碑还不错呢。正好晚上有点时间，就来研究一下。

其实当我第一眼看到它的网页的时候，我就喜欢上了。页面清晰，没有什么多余内容，体积也很小。这个程序，根据它的页面上说明，就是根据wiki概念的创始人Ward Cunningham的概念设计的，产生的结果也和Ward Cunningham做的世界上第一个wiki──WikiWikiWeb很像。它的安装也很简单，只有一个Perl程序就能运行。它需要建立一个文档目录，本来我还以为是往里面放文本文件，然后程序动态的生成html文件，结果运行了之后才发现，它完全是在浏览器里面书写wiki格式的文章的。可以在发布前预览，完全就跟MediaWiki、MT一个样子。

花了一点时间，把过去的首页上的内容手动移植到wiki上，便成了现在的样子。但我还不知道怎么在页面上插入纯HTML代码，所以原先首页上的一些标签什么的，现在通通不在了。等有机会再研究。

UseMod Wiki还有一个缺点（也是很多wiki程序共有的缺点），就是国内用的人不多，相关的中文文档很少。我从它的官方网页上的中文翻译的作者的页面上看到了有中文的一个小型的教程，地址在这里，已经写的相当不错了。可惜这位作者好像不再在这上面玩了，相关的翻译也没有更新。

最近由于用MT的关系，我似乎对静态页面有了依赖的心理，总觉得没有静态页面就不保险。ModUse Wiki把文档文件夹当作一个在文件系统上的数据库，我实在是害怕有一天这个文件夹出了什么问题，导致我的页面都丢掉了。只能但愿UseMod Wiki的程序写的够稳健了。

总之，在有更好的方案之前，我的首页就是这个样子的。

昨天看了蔡智浩的新文《中文網址的未來（在 ICANN 開放網域名稱使用非拉丁字母之後）》，提到了ICANN新通过的在域名中使用Unicode的草案。过去的非拉丁域名的标准，是把字符转换成拉丁字母，比如「中文」被转换成「xn—fiq228c」。而这次的新标准，算是一个进步──我们不需要那个没有任何信息的拉丁符号了。

虽然把计算机中文化是很多人的梦想，因此搞出了类似“中文内核”、“中文编程语言”之类的东西（或称为“闹剧”）。我觉得在域名中使用中文，至少在目前是没什么用。

域名的作用，是给数字形式的IP地址关联上一个容易记忆、方便使用的标志。在目前计算机里的一切都是用英文字母表示的时代（就连输入法也是），拉丁字母无疑是最方便使用的。如果域名里有了中文，我们输入的时候就要切换到中文输入法，多按了不知多少键盘。更麻烦的是，在一台没有中文输入法的机器上，就无法输入中文域名，直接打开网页。

确实，Unicode域名扩展了英文字母的域名。经过了互联网发展的几年，很多域名都不能用了。如果有了Unicode域名，我们确实可以缓解这一情况。不过，基于上述的困难，我觉得还是开发新的顶级域名稍微合理一些。

之前反波发布过一则播客，题目是域名贩子。内容大概是说一个韩裔美国人，通过抢注域名再贩卖发了财，被人们称为“那个掌控了因特网的人”。不过，播客最后提到了一点我很赞同，就是在Google等搜索引擎越来越火的时代，抢注域名的方法已经不管用了，因为很多人都是直接用搜索引擎搜索关键词，再点击进入网页，连域名都懒得记。而对于今天的Unicode域名扩展域名基础这一点，我觉得同样适用。如果没有好的域名，用一个不那么好的域名，如果把知名度打响，通过搜索引擎，也一样能正常发展。

前几天看蔡智浩的新文《Facebook 與我》，上来就看到了这么一句文字：

社群網站 Facebook 最近在台灣大受歡迎，大部分的人都是為了要玩社交遊戲「開心農場」才加入，種菜也因此成為人們閒聊的熱門話題。

我这才知道，在校内、开心等一些网站上流行的小游戏，已经进驻了Facebook上了。

我才惊叹到：原来台湾人也爱种菜啊！

我对与这上面的小游戏一直不屑一顾，一个SNS上的网页游戏能有什么玩头呢？而且SNS可不是游戏平台的简称。要是想玩游戏，玩专门的线下游戏或联机游戏岂不是更好。这种游戏，从标准角度上来看，简直毫无可玩性。不过，因为我一直不看好国内的网络，所以对一些国人迷恋这种游戏也能够理解。而由于台湾的互联网普及较早，环境也比大陆更好一些，所以我一直没想到人们会把开心农场搬到Facebook上，供台湾人民玩乐。

在台湾，可以无忧无虑的上Facebook、上Twitter和Plurk，还有无名、痞客交互平台，更有PTT这个大陆网民早已忘记或从未听起的BBS可以上。我过去一直以为，开心农场的火爆是因为大陆网民无法访问丰富的网络资源而导致的畸形现象，现在想来，我错了。开心农场在台湾的火爆即证明了这一点。

那么人们喜欢玩开心农场，会不会和文化传统有关呢？难道是中国几千年的封建社会、重农抑商策略给我们带来了天生喜欢农场的基因吗？

我从开心农场的Fans列表上看了一下，翻了几页都只能看到华人（中文用户名、亚洲人头像等），因此我猜目前开心农场的用户绝大多数都是华人。但我不知道这里面有没有香港人，毕竟在英占百年的期间，香港的文化与内地和台湾的文化发生了很大的不同。我在加拿大还没有发现当地人有玩这个游戏的，他们的Facebook还是社交用途居多。

这篇文章停留在我的浏览器中已经很久了，当第一遍看的时候就想写点什么，但由于忙一直没有总结出来。思路也不怎么清晰，不知道该怎么总结。到今天看到它还在浏览器中，遂决定不等了，脑中想到什么就写什么吧。

我在今年四月份，写了一篇文章《母体外的人》。文章来源于Kevin Kelly在TED的演讲，在web存在了5000天的时候，预测web在5000天之后的样子。我在看到《Twitter 大脑》这篇文章之后，马上就想到了我的那篇文章。

Kevin Kelly在演讲中的观点是，在5000天之后，我们只需要一台电脑。这台电脑是最稳定的，我们用的掌上设备，不过是这台电脑的一个终端，这台机器的操作系统就是网络。而从我们的角度上看来，这台电脑大约可以等同与我们的大脑。我们大脑由神经元组成，由神经连接，而网络由网页组成，由链接来链接起来。但不同的是，我们的大脑不会每年扩充一倍。也就是说，假以时日，我们的网络会在计算量和存储量上超越我们的想象。我们几乎就生活在这台电脑里，就像在电影《Matrix》一样。我们忘了朋友的手机号，我们不去找备忘录，只要在搜索引擎上搜索朋友就可以了。Kevin Kelly也讨论了连接Data而不是Page，这一点主要由HTML的创始人Tim Berners-Lee来讲述的，他为之起名Linked Data。

我在自己的blog上搜索了一下之前写过的此方面的文章，还找到了不少，比如这篇。也讲述了同样的道理。与apple4us上的文章一样，这些演讲讲的道理是同一个：当基数无限增大时，似乎一切的问题都将解决。《Twitter 大脑》上说，根据Twitter发展的速度，在2013年，Twitter网络就可以形成一个发育中的婴儿大脑了。

这是令人兴奋的。虽然靠基数来解决问题，有点作弊的感觉。但在我们无法在技术上再进一步的情况下，这也似乎是我们唯一的途径。不过我对由Twitter来完成这一个任务抱有怀疑，因为Twitter上几乎没有机器可以识别的Data可言，让机器来达到能提取Data的程度，又需要我们前面说的网络。这似乎是一个永动机一样的东西，是不可能完成的。不过这毕竟为我们的计算领域提供了希望。