February 2010 Archives

实在是忍不了了，我在创建了一个 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:55，我在床上觉得躺不下去了，于是起床。看了一下手机的时间，突然觉得生物钟真是神奇如斯啊。

由于这前几天的作息规律相当混乱，尤其是有几次为了完成第二天要交的作业，整个一晚上都没睡（在家里存了咖啡就是不一样啊），所以放假前的那几天我一直觉得没有完全休息好。我每次这种情况的症状是，眼睛感觉特别疲劳，揉眼睛也觉得疲劳没有丝毫改善；脸部肌肉僵硬（让我想到了“面瘫”一词）；身体说不出是什么感觉，但如果用手掌干搓一下身上的大片皮肤（就像是给猫狗顺毛一样）就会觉得特别爽，总之就是一种全身不得劲的感觉。这种情况下，由于我每天早上的提神咖啡的影响，通常是连锁反应，第一天没休息好，之后连续几天都会如此。因为如果我前一天晚上没睡觉的话，第二天下午的五点到六点的时候就特别困，但我那时候通常都会在机房上自习；而八点到十点回家后又觉得不怎么困了，经常能坚持到凌晨十二点到一点，自然无法好好休息。

放假之后，甚至是周末，我都会发生这种情况，就是前几天就睡个昏天暗地，把生物钟给睡紊乱了为止。有时候到了第二天不想下床，就在床上抱着电脑看点文字或者视频，也常常能在床上呆一天。自这开始，第二天的作息就不正常了。

这次的放假也是一样。我们学校的每年的二月份都有一个星期的 reading week 假期，说是让我们在家里读书的。但假期结束之后通常都是大大小小的期中考试，所以这个 reading week 也有让我们复习的意思。正巧今年的 reading week 赶上农历年，与国内一起放假也是不错的感觉。放假前那个周末我为了赶第二天的两门作业，通宵未睡。那一个星期一直感觉没有休息过来，这次也顺便补上。因此到了上周五的下午，我就觉得不行了。那天下午我们要在 5:00 之前给老师交上《计算机网络2》课的项目 proposal，我在小组里的工作是整合另外三个人的工作，用 LaTeX 排版，生成 PDF 文件交上去。所以我一直撑到 4:30 才完事。交上之后我同学又找我一起购买“年货”，我们又驱车去了两个地点，买了肉类和蔬菜、水果之类的东西。在回家的路上我在车里一个劲的打哈欠，倒并不觉得困，就是感觉乏，没有精神。

那一阵子由于太忙碌，我对日期也没有什么关注。再加上我们在这边也不是很关注国内的农历年，对于过年也没有什么感觉。所以我对于阴历也没有什么敏感，在回家的车上和同学聊天才知道马上就是春节了。本来想着忍到国内初一的凌晨给家里打电话拜年，可回家后吃过晚饭（五花肉）之后过了一会就觉得困了，在床上躺躺就睡过去了。这一觉睡得是天昏地暗，等到醒了之后好像就到了第二天下午了。但那时还不想起，磨蹭了一会，下床下了点速冻水饺吃了，印象里到了晚上六点多就又忍不住了，上床睡到了凌晨才起来。

浑浑沌沌的我，印象里看了一部电影，又干了些别的事情，然后到了早上的六点多，我觉得受不了了，就又上床睡觉。之后我就一点时间观念都没有了，总体的感觉就是白天睡，晚上起来做事。中间也做了好几个梦，有很多在我突然惊醒后就瞬间忘了。到现在唯一记得的一个是我在国外上中学，入学第一天下课后在学校外面坐公交车回家。在公交车上与座位前面的一个男生和座位后面的一个女生认识了，交了朋友。其余的都没有印象了。

昨天晚上我照样也是不困，但觉得这一个 reading week 也不能浪费过去，应该要倒倒时差了。不过到底是晚上也不大困，我好像是两、三点才睡过去的。睡之前我看了 Google 的 HTML5 讲座，听这种东西最容易催眠了，我也就成功的睡过去了。

我日常在周一早上的作息是这样的。10:30 第一堂课，因此我要 9:55 从家里走，乘坐那趟应该是 9:59 到我家楼下车站的公交车去学校。但由于目前还是冬天，路上有积雪，所以这公交车经常晚点，实际上的到站时间都在 10:05 左右。所以我如果 9:55 下床的话，放弃刷牙、洗澡的工作，动作麻利点还是能赶上公交车的。

而让我感到惊奇的是，我在周六、周日都睡得昏天暗地，本来也没有指望周一就能起床，但却是在日常该起床的时刻左右起来了，难道生物钟也可以跨天运作了？之前只知道每天定时起床可以培养生物钟。建立起规律之后，每天都会在同一时刻起床。但很少听过双休日可以让生物钟暂停运作的。不过日常这种情况也有很多，可能只是没有这么明显罢了。

起床后，我坚持到中午 12:00 左右，去超市买了一杯 Starbucks 的超大号拿铁喝了，坚持到晚上，自我感觉不错。

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 的。

过去我上课的时候总喜欢坐在第一排，因为那时觉得自己英文可能还不够正常理解老师说的每句话，坐在第一排可以帮助我集中精力听清楚。这个学期以来，由于心态的变化，我开始喜欢坐在后面。这样的好处是有更多的自由度，听起课来也更轻松一些。当然，需要记很多课堂笔记的《数据结构和算法分析》课我依旧是坐在前排。

坐在后排还有一个“好处”，就是可以“窥屏”。教室里很多人都带着计算机去记笔记，我在无聊的时候，就会看看他们在干什么，用的什么软件之类的。看了几次，让我感到有一个很深刻的印象，关于软件使用的。

Windows 下的软件就不用说了，一来我基本上不熟悉，二来多数人记笔记用的就是 OneNote（我从这边帮同学挑过电脑，一般买了都会带 OEM 版本的 Office 的一些软件），少数人用记事本，另外我见过一个 jerk 用的是 TextPad。关于 TextPad，我觉得只是一个比记事本稍微稍微强那么一点点的东西，在我看来它的优势只是大一老师教编程时推荐的编辑器。所以现在有同学编程甚至记录课堂笔记都用它，让我觉得实在是讶异。长期用这种编辑器，我觉得我会得抑郁症。当然，如果此人从来没有见过外面的世界，就不那么好说了，虽然这种情况的几率不大。

我们这边课堂上用 Mac 的人数与用 PC 的人数基本上持平，有时候还会超过。用 Linux 的我也见过至少 10 个。由于 Mac 和 Linux 都是以 UNIX 基础的系统，所以把它们放在一块讨论也算说得过去。虽然当中有些小的差异。

在 Linux 下，我见过的用来记笔记的工具，好像只有 oowriter。顺便说一句，我看见过的 Linux 发行版都比较基础。不知道是这帮老外的水平还在入门阶段还是已经“看破红尘”，用得基本上都是 Ubuntu 系列的系统。喜欢 GNOME 的就用基本的 Ubuntu，喜欢 KDE 的就用 Kubuntu。别说 Gentoo 了，我连个 Arch 都没见到过。用这些 Ubuntu 之外的发行版不是为了耍酷什么的，而是根据我的经验，Ubuntu 系统用一段时间之后，速度确实是像蜗牛一样，特别是我用了 Gentoo 之后，这种感觉尤其强烈。言归正传，用 oowriter 的大多数人都是普通的记录而已，而在《数据结构与算法分析》课上坐在我旁边的一个同学，我曾经瞟过他的屏幕，看到他就在课堂上用 oowriter 的画图工具在画 heap 等结构。看了之后我大感惊艳，时间长了不用 OpenOffice，我也不知道里面的画图工具进化到什么地步了，如果在课堂上来画这些数据结构图能赶上手画的速度，已经可以算是“泣鬼神”了。

在 Mac 下，我见过同学使用过的记笔记软件占多数的是 Pages。与 Linux 下的 oowriter 的情况差不多，当然也有不想掏钱购买 iWork 的而选择使用免费的 OpenOffice for Mac。少数人使用 Microsoft Office 2008 for Mac，也在情理之中。而我亲眼看到有人用 TextEdit.app 来记笔记，也算是相当奇特的了。更“厉害”的是我们《操作系统》课程的老师，一个资历比较老的教授，用 TextEdit.app 来维护一个挺长的 ToDo list。做得特别工整，左边是事件的描述，右边有耗时的估算。但愿是我无知，不知道 TextEdit.app 可以使用插件，难道要手动维护一个 ToDo list？按理说那一代的教授应该对 Emacs 比较了解的。

就我观察的这些人来说，绝大多数人喜欢用系统自带的或者是默认推荐的主流软件（当然，这不包括 IE。Firefox 在加拿大已经是标准的浏览器，哪怕是在 Mac 上，我也看到很多人使用 Firefox 而不是 Safari。）。这让我感到挺奇怪，人们选择使用最“流行”的而不是最优秀的软件来使用。虽然说不同人对“优秀”有不同的定义，但我想在计算机系，在判断软件的优秀程度上应该是比较统一的吧。但人们还是不大用 Emacs，用 Vim 略多一些，多数人喜欢用标准的图形软件。也许是大二老师讲 C 语言的时候在实验课上指定的标准软件是 Xcode，所以多数人对 IDE 情有独钟。Java 自然是 Eclipse 了，毕竟它自己也已经有了很大的名头了。

目前来看，相比起国内来说，Linux 在加拿大的计算机系课堂上已经不算“小众”了。根据我的观察，Emacs 才是真正的小众。在这里流行的似乎不是 Emacs 这种“用统一的工具来编辑不同的文档”的政策，而是用不同的工具针对性的编辑不同的文档。写 Java 程序有 Java 编辑器，写报告有文字处理工具，等等。我在这些年来，在自己的计算机上使用 Emacs 的，我是一个都没见到过。

我想过，一个普通的大学生使用计算机按照“潮流”来选择软件是正常的，而一个计算机系的大学生使用的软件，为什么还在这种基础的层次上呢？有很多软件，虽然古老，但绝对比那些东西优秀。前几天我们要交项目的 proposal，我负责合并小组其余三位成员的工作，完成排版工作后交给老师。老师的 proposal guide 上说如果 proposal 是用 LaTeX 编辑的，可以有加分。当时我就想，如果不让我用 TeX，我还能拿什么来排版呢？到今天来说，文字处理工具已经越来越不适合我了，我对它们也越来越生疏了。让我用文字处理工具来排版，想象就有很多困难。

我至今还记得引导我进入 Linux 大门的王垠的一篇文章（这篇文章被王垠改了，之前的观点性的论述被删除了）。里面有一节好像就是说使用这些看上去“老掉牙”的但绝对优秀、稳定的程序，而不是用像 OpenOffice 这样“新潮”（五、六年前了，那时候 OOo 确实新潮）却不稳定的程序。我觉得到今天来看，这话还是对的。OOo 虽然发展了这么多年，但我觉得从文档编辑的角度来看，包括 OOo、包括 Word，出发的方向就错了。我到今天也无法接受这个方向，因为按照这个方向走，对一个文档进行排版实在是太难受了。直观的来看，这些所见即所得的软件满足了初学者，似乎也很简单，但确是在要求用户来符合计算机的思想。而 TeX 这种“所想即所得”的软件，用一些简单的符号来表示文档的样式，是相当符合人类的思维方式的。

有时候我想，我身边的这帮人用 Linux 是为什么呢？觉得 Linux 很稳定？其实近几年来 Windows 已经很稳定了，从 Windows 2000 之后就很少有蓝屏等状况发生了。觉得 Linux 很酷？也许吧。我的理由是 Linux 下的软件是无法移植的，所以我希望使用 Linux。为了某些原因而为了用 Linux 而用 Linux，我觉得是一种“买椟还珠”的行为。我一直在推崇 Linus 对于操作系统的看法──操作系统的任务是帮助软件来运行，一个用户应当永远看不到操作系统。目前的很多发行版，为了推广 Linux，让 Linux 看上去简单，集成了很多入门级的软件（如 OOo），这些软件实在不是我心目中不可替代的软件。

有些时候最可气的是，明明有个东西你知道见过，但用的时候就是找不到了。

我这学期网络课的项目要求在明天之前交 Proposal，要求中说如果是用 LaTeX 排版的可以有加分。我这学期之前一直在用 ConTeXt，这学期一直在用 Emace Muse 和 org-mode，感觉很长时间没有用过 LaTeX 了。开始的时候我想接着用 ConTeXt，毕竟感觉熟悉一些，但在 Emacs 中打开一个 .tex 文件却提示错误。我才想起我这个自己编译的 Emacs里面还没有安装任何 ConTeXt 的支持。后来为了方便大家一起工作，决定用 LaTeX。之前加上 AUXTeX 插件的 Emacs 也用惯了，于是我就自己装一次 AUCTeX，既为了这次使用，也为了将来编辑 ConTeXt 时用。

AUCTeX 支持通过快捷键来编译文档。我过去用的应该也是 AUCTeX，但一直没有用过快捷键，因为一直不知道有这个功能。我一般都是或者用 compile 命令，或者按 M-! 来执行 pdflatex 命令。而 AUCTeX 的快捷键的好处就是编译完成后，有没有问题都在 mini-buffer 里面告诉你，而不会把窗口切成两半再出来一个新的 buffer。按 C-c C-l 之后才会调出编译的结果，所以我就一直在用快捷键。

但它有个问题，就是 Emacs 找不到 latex 命令。我用 (getenv "HOME") 检查了一下，发现 Emacs 并没有载入我在 .profile 文件里面设置的 PATH 变量。这样的后果是，AUCTeX 找不到 latex 命令，因为它们都不是安装在默认的 /usr/bin 和 /usr/sbin 目录里面。这让我相当苦恼，不仅 AUCTeX 没法用，原先我的那种 M-! 调用外部命令的方法也不行了。

我印象里之前看过让 Emacs 识别 .profile 文件里的 PATH 设定，但从来没有想到自己也有用到的一天。这次我从网上用各种关键字搜索了很长时间，还是没有找到。CarbonEmacs 在这方面工作是正常的，不过我也没有仔细研究过 CarbonEmacs 的目录分配，不知道相关的设定文件在什么位置，一时间也找不到。

后来我想过一个折衷方法，把 AUCTeX 的 latex 命令设定成绝对路径，也就是在 .emacs 文件里面加上这么一行 (custom-set-variables '(LaTeX-command "/usr/local/texlive/2009/bin/universal-darwin/latex"))。但我发先这样的话，单纯用 latex 是没问题了，但要想用 PDFLaTeX 直接生成 PDF 文件，而不是生成 DVI 文件后再转换成 PDF 文件的话，这样做就没用了。原来是 AUCTeX 没有给每个编译命令设定不同的命令行，而是直接偷懒，如果是想调用 PDFLaTeX 的话，就直接在 LaTeX 的命令行前面加上 pdf。这样的话，AUCTeX 生成的 PDFLaTeX 命令行就成了 pdf/usr/local/texlive/2009/bin/universal-darwin/latex，自然找不到相关的程序了。

后来我没办法，直接用笨办法，在 .emacs 里面设定 PATH 变量。也就是加上这么一段：

(setenv "PATH"
        (concat
         "/opt/local/bin" ":"
         "/opt/local/sbin" ":" 
         "/usr/bin" ":"
         "/bin" ":"
         "/usr/sbin" ":"
         "/sbin" ":" 
         "/usr/local/bin" ":"
         "/usr/texbin" ":"
         "/usr/X11/bin"
         (getenv "PATH")
         )
        )

这种方法，我参考了 Xah Lee 的文章。

不知道是不是心理作用，我试验了这种方法之后，总是觉得启动的速度变慢似地。不过这样确实是在设定程序里面加了一些不应该添加的东西，因为他们降低了 .emacs 文件的“可移植性”。所以我又在找其它的办法，于是我找到了这篇文章。文章介绍了通过设定 Mac OS X 本身的 plist 来让 Emacs 获取设定的路径。方法是在终端里面运行 defaults write $HOME/.MacOSX/environment PATH “$PATH” 这么一行。我试验了之后，手动观察了一下 ~/.MacOSX/environment.plist 文件，发现里面是乱码。我对 plist 文件的格式不了解，以为是系统给编码了。文章中说执行完这行命令后，要重启一下计算机才行，我也乖乖重启。但重启之后却发现 Emacs 中根本还是老样子。

印象里 Mac 自带了一个程序，可以编辑 plist 文件的。我于是找了一下，发现了 Property List Editor.app 程序。进去后打开了 ~/.MacOSX/environment.plist 文件，试着把乱码改成了 PATH 变量里的内容，再重启之后就好了。不过这样也不是很完美，我查了一下系统的 PATH 变量，有些路径出现了两次，不过不影响使用。

这件事给了我又一个 Mac OS X 系统与 UNIX 系统之间的不同的地方。可能是为了兼容旧程序，Mac 没有统一实行一个策略。既然已经有了 PATH 方式，为什么还要弄个 plist 让某些程序读取呢？我觉得 UNIX 传统的路径政策是非常好的，通用、设定起来也方便。Mac 的很多这策是只给用户提供一种最通用的办法，而这种情况下，一个简单的路径就有了不同的设定方案，两者还不统一，确实给用户带来了麻烦。

最近一段时间，我一直断断续续的研究 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 上了，首页就让我设计成几个指向我几个不同帐户的图标组合了。目前看起来一切都还好。

我之前写过我找室友的经历，当时我之前的室友毕业回过，我要给客厅找个室友跟我合租。

我首先想到 A 同学，我在读语言的时候和他一个班，关系一直不错。之前听说他住在一套两室一厅的客厅里，合租的是两个陌生人，于是就想把他“勾引”过来──与其与陌生人合租，不如和熟人合租更好说话。不过问他的时候，他说其中的一个室友搬出了，他从客厅升级到卧室去了。而且他住在另一处公寓的女友（也是我语言班的同学）搬去和他一块了。不过他的女友之前是和我国内来的同学 B 合租的，我可以问问他们那间卧室还在不在，如果找室友困难的话，我就搬过去。不过我先问了 C 同学，同样是之前语言班的同学，不知道他有没有搬出来的意思。我问他的时候比较隐晦，没有直接问他要不要来，而是问他有没有朋友要找房子的，原因是他那时和别人合租一套两室一厅，虽然是和陌生人合租的，不过好好的干嘛要来我这里住客厅呢。他没有意思之后，我就问我国内的同学，他之前和女朋友与 A 的女友合租一套两室一厅，我问了后结果我那同学回国了，那间卧室也已经租出去了，于是最后一条找熟人合租的路也没了，我只好从论坛上发帖子。

本来我的打算是找房子难但有房子就不愁租不出去，结果发帖之后几天都没有信。平安夜那天我和另外两个同学去老外家聚餐，和他们谈起这件事，但他们却觉得不大乐观。因为我要出租的是客厅，除了熟人以外，如果有卧室的，肯定不会租客厅。冬季也不是留学生初次出国的旺季，因此找房子的人就不会很多。我听了之后，想想也有道理，就有些担心了。不过按照我那性格，以及那几天我那什么都提不起劲精神状态，我也没有进一步的行动，只是看了看我那帖子在论坛里不知道沉到多少页了，一个回复的也没有。现在想来，我也对我那时候的行动有些不解。本来找不到室友的话，我就要自己一个人承担每月 651 加元的房租和 50 加元的网费，是很麻烦的，不过我那时的心情是隐隐有点担忧而已，知道后果，但就是不想行动。现在说那时候有潜意识预知到今天的结果是有“事后诸葛”的感觉，但我当时确实是那么希望的，并也想到我之前的种种经历都是如此的──自己不用花心思去想解决方法，总会有方法水到渠成的找上我的。

后来的情况就和我那篇文章里说的一样了。C 同学在一天晚上 7 点左右给我打电话说想过来看房子。我问他为什么要搬，他说他们的合约三月份到期，他们公寓的管理员不咋地，他想换个地方住。我一厅这送上门来的好事，自然是乐得答应了。他说他二月份搬进来。

C 同学看完房子后没两天，在一个周末我接到 B 同学的电话，问我知不知道有睡在出租房子。我问他怎么了，他说和女友分了，刚从国内回来，正急着找房子，听他说这时候房子也不好找。我一合计，一月份还有半个月的房租要我自己承担，不如把他拉进来暂住，算是一举两得。于是就把他拉进来了，让他有半个月时间找房子。最终他找到房子后，就帮他搬家，而我在中间也成功的让他跟我合租我和之前的室友在健身房合租的储藏柜了，事情得到了圆满的解决了。

今天晚上我正在写作业，突然接到一个电话，是 A 同学打来的。他上来问我那客厅租出去了吗，我听了之后隐约感觉到了什么，告诉他已经出租给 C 了，但他还没有搬进来，然后问了他原因。果然如我所料，他这几天一直和女朋友吵架，想找地方搬出来。我心里想着“果然如我预料一般”，一面表示遗憾，一面说“过几天可能还有转机”，同时想到了和之前的室友的讨论。

我之前的室友和女朋友在国内认识的，一起来这边的，中间分分合合好几次，最后我室友毕业回国，他女朋友留在这里。他女朋友从来这里之后一直住在老外家里，我室友和我在语言班毕业之后一起租的房子。他说他一直没有和他女朋友一块住，就是因为当中的麻烦事太多，多数情况下都会闹翻。也确实，他在这两年之中，和他女朋友分分合合好几次，但到最后也算是在一块的。我们当时讨论这个话题，就是因为听说 A 同学和他女朋友搬到一块去了才开始的。B 同学的经历验证了这一点，今天 A 同学同样验证了它。

接连发生同样的事，让我有些好笑。更好笑的是我当初在找室友的时候都问过他们但都没有成功，结果现在他们又反过来问我，真是有些“沧海桑田”的感觉。我当时找不到室友的时候脑中隐隐的幻想可能是有熟人会来找我一起住，因为我之前几乎每件类似的经历都是这么顺其自然的完成的，在完成之前我固然也感觉过一些恐慌，但事实却就那么的发生了，那么的顺其自然。这次我也感觉到了恐慌，而且似乎这恐慌也比之前的每一次更剧烈一些。我甚至想到了“我之前每一次类似的事情都是顺其自然完成的，我感到很幸运，因为我不需要自己出力去选择或者去争取，事情的结果也都不错，我懒懒的就获得了好处，难道我一辈子都会这样幸运？这次会不会就是一次‘人生转折点’？从这次开始我要自己努力去获得我必须要的东西了？”结果事情依然是这样“顺其自然”的发生了，显然我又幸运了一次。不过我在写这些字的时候，也没有什么自信了，不知道下一次事情是不是还会像这次一样幸运的解决。

现在的整体社会导致我以及周围的年轻人的心智有低龄化的现象。我经常听到有人戏言“如果我们如果在旧社会的话，孩子都会打酱油了”，因为听过很多人说那时候人们十六、七岁就结婚生子了。哪怕是今天，我也经常听说“某某的小学同学已经结婚（甚至有孩子）了”的话，在感慨时间流逝的同时，也想过如果结婚或者生子的是自己，自己会是什么感觉。当事人可能会感觉很自然，但如果是我的话，心里想的肯定是“别开玩笑了，自己还是个孩子呢”，尽管经常从大人那里听到“你以为你还小啊”之类的话。

在国外，很多人都总结出男女没有真感情之类的话。尤其是我们这个地方，平日里给人的感觉远不如国内的一些大中城市那么有“都市感”，平均楼层的高度也不过两三层。生活本来就比国内冷清，再加上我们这些外乡人，就更冷清了。因此这边的一些“小两口”，基本上都是欲望的结合，因为一个人在这边太寂寞了，很容易“干柴见到烈火，天雷勾动地火”，两个人就好上了；但同时也经常听到某某和某某又分了。当然了，本来在一起就是为了泄欲的，结果两人低头不见抬头见，在异国一起生活其实就和国内的两口子一个小家庭差不了多少，而由于心智的低龄化，心理也远达不到长久过日子的程度，不久就分手也是正常的。

分分合合原本正常，不过在近期内就接连看到了两起，还都是自己身边的朋友，因为毕竟我周围的人平时也很少发生这种情况，所以感觉也有些奇特的。我身边还有比较尊敬的学长，同期的同学也有一起住的，我也不禁为他们感到有点担心。其实想象一颗不怕寂寞、自得其乐的心在异国他乡学习生活还是挺好的，虽然在外人眼里或许少了很多人生乐趣，但也少了很多红尘世俗中的烦恼。

昨天我照例去老袁的 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 作为一个系统，这话还有可能说的过去，但作为一个商业产品的一部分，如此断言还是太过武断。

周日晚上开始，大概是 11 点多以后了，我开始写这学期的《数据结构与算法分析》课程的第一次作业的倒数第二道题。题目要求是用 C 语言或者 Java 语言实现 Binary Heap、Ternary Heap、Quaternary Heap、LB-Tree、Skew Tree、 Binomial Queue 这几个数据结构，在程序开始的时候随机生成一个包含 10000 个正整数元素的数组，把这些数据存到这些数据结构中，然后把这写数从小到达取出来，统计进行内存操作的次数，来得到这几个数据结构的性能对比。

我之前和同学讨论过这个题目，对方说他花了不少时间，不过他是用 C 来实现的。我由于这次作业第二天早上就要交了，所以也就没有跟自己较劲，非要用 C 写。基于之前用 Java 的经历，我如果要从 C 和 Java 当中选一个语言来写这个程序，我毫不由于的选择了 Java。

我曾经一度非常讨厌用 Java，因为觉得语法太繁琐，要读取文件都很麻烦。在 C 之类的语言中几行就 OK 了。另外的原因大概是有些审美疲劳，虽然本事不怎么样，但那时却好高骛远，想接触一下 C++ 之类的语言以及 Ruby 之类的新型语言。Java 写多了，那时后的课程又没有什么难度，就有些小看了 Java。后来我的一下比较大的“项目”都是用 Java 完成的，我学了面向对象课程之后，对 Java 也算是有了新的尊敬。

我最近的几次大项目有点不大在状态。每次在截止日期之前都提不起兴致来，非要等到第二天就要交了，前一天晚上才用咖啡顶着，熬夜把项目不紧不慢的写完。每次大概花上夜里 8 个小时，也算是一鼓作气了。上学期《专家系统》课的学期项目是如此，这学期的面向对象的第一次作业飞机座位模拟也是这样，这次的数据结构也是一样的情况。每个程序的规模基本上在 2000 行代码左右。后来我总结了一下，发现 Java 实在是功不可没。要是让我用 C 语言或者 C++ 来在 8 个小时内写这么多代码，我中间的空指针就够我受的了。

我另外用 Java 写的项目是去年暑假上《软件工程》课的时候和另外四个人组成的小组做的学期作业，是一个自动生成歌曲列表的软件。我所在的小组完成的是底层的逻辑部分，似乎和对象的交互没什么关系。我在上学期也和另外一个人用 C 语言写过《计算机网络》课的学期项目，我之前也写过文章讲过相关的故事。那和 Java 比就完全不是一个级别的了，开始时我写 concurrency 的时候简直是一筹莫展。后来我是用的 C 写的游戏的逻辑部分，对方写了服务器和客户端的界面与交互，总算是完成了。不过在演示的时候还是出现了字符串的乱码，估计是一个某个地方有了一个“野指针”。不过打分的助教说这不是重点，于是我们也没有找具体是哪里有问题。

之所以把 C++ 排除在外，是因为我目前的 C++ 水平很弱。我曾经在 STL 流行之前觉得我对 C++ 掌握的差不多了，那时候我还在中学时期，现在想起来也是狂妄的可以。过去只知道有个 class 关键字，底层是怎么回事我是一点都不了解。现在学了面向对象课程，学到了 C++ 中的类不仅可以放在堆里面，也可以放在栈里面。这让我困惑了许久，两着之间的区别是怎么样我也考虑过很久。还有，过去光记得用 class 关键字来定义类，使用的时候也没记得要用指针。现在基本上在定义的时候前面加星号成了标准写法，也让我着实愣了一阵。我还没有用 C++ 写上几个 2000 行左右的程序，因此对于语言本身的掌控没有什么感觉。我用 Java 写这种东西，只要把题目搞清除了，从纸上设计好，就可以开始写了。类之间的组合什么的基本上不会有什么问题，顶多在检查空指针的时候查一些粗心错误。C++ 我就还没有这个底气。

我考虑了一下我为什么感觉喜欢 Java，我喜欢的到底是 Java 的什么东西？最后得到的结论大概还是自动垃圾回收以及隐藏指针吧。C++ 和 C 里面的指针分配，不管是 new/delete 还是 malloc/free 都要小心意义的，这些东西又不能自动递归执行，稍微有点嵌套的数据结构在释放内存的时候就要自己做许多事。Java 的自动垃圾回收虽然从效率上不如 C/C++，但以目前的机能来说，差距也不大，而节省下来的人力时间则不是机器执行时间可以比的。而指针隐藏和垃圾回收也有一定的关系，不用手动维护指针总是好的。虽然指针给了更灵活的操作，但也容易让人写出有隐患的代码。

总结出了这两点，我又检查了一遍，似乎还真没有别的我喜欢的地方了。相反倒是有我不喜欢的地方，就是 Java 没有一个好的调试器，或者说我还没有掌握一个 Java 调试器。我在上学期用 C 写项目的时候，终于对 GDB 有些开窍了，突然觉得它真是一个好工具。尽管我只会用它的很小一部分功能，但已经基本上可以满足我的需要了。我用 GDB 主要是程序有了 Seg Fault 的时候，进 GDB 运行一下看看空指针在哪里。或者就是程序有了奇怪的行为，去设个断点，分布执行一下，跟踪一下变量的变化。虽然不像我过去用的那种 FreePascal IDE 之类的调试器一样可以即时的显式监控变量的列表，但我也习惯了用 p 来查看变量的值。Java 的 SDK 里面有 JDB 这个 GDB 的模拟，我用过几次总是一头雾水。说是 GDB 的模拟，但指令基本上全都变了模样。也没有缩写了，指令本身也变了好多。我反正是一次也没有成功的用起来 JDB 过，所以到目前位置我还是在代码里面插入“人肉”断言来输出变量的值的。

基于上面说的那两点，我觉得应该有不少语言都满足这些要求，但我基本上都没有熟练到像 Java 那样子。而且 Java 也算是最流行的一个，我们老师课不让我们随便用 Ruby 写作业。或者我听说 Objective C 也不错，在 C 的语法基础上加上了自动垃圾回收什么的。不过对于他我还是一点没有入门，语法上也觉得颇为奇怪。就算是之前最熟悉的 Python，拿来让我写这种大项目我也是要愣一阵子的。

想到了这一点，我觉得应该可以找到一种适合自己的编程模式，来发挥我需要语言的特性。通晓了这一点之后，应该写千百个项目都不成问题了吧。

几天前就知道了 Emacs 的代码仓库已经从 CVS 转到 BZR 上来了，但一直没有多像。今天突然想看看 BZR 里的 trunk 版本和 CVS 里的有没有什么不同。因为我目前用的 Emacs 是用的 CVS 里的代码编译的，不知道在 BZR 中的 Emacs 代码有什么更新呢？

我第一次听说 BZR 是在 2007 年下旬，中间一直没有实际 checkout 过 BZR 仓库里的代码。我平时自己的代码喜欢用 Git，与别人合作用的多数是 SVN，这两样基本上已经足够满足我的要求，也足够流行，所以我一直没有花时间去弄清楚 BZR 相对于这两个来说有什么不同。由于平时很少 checkout BZR 仓库里的代码，所以我连 BZR 客户端都没有装。今天想去下 Emacs 的代码，之后现下了一个客户端。

我首先下载的是 BZR 的源代码，需要用 Python 安装。不过我看里面有直接可以运行的可执行文件，就先用它试试。不知道是不是 Emacs 的 savannah 仓库的连接速度慢，还是 BZR 本身就慢，代码一直在下载中。说它奇怪是我看到下载的目录里面只有一个 .bzr 文件夹，而代码却不曾看见。我才应该是被放到什么地方缓存起来了吧。后来突然本子的风扇开始转了起来，我看了一下果然是 BZR 的这个 Python 进程的 CPU 使用百分比已经高了，由于正在上课，所以我只好杀死了这个进程。

中午的时候，我下载了 pkg 安装包，直接安装了二进制的 BZR，主要是想确保万无一失。于是又一次运行了 checkout 命令。当中经过了漫长的等待，终于风扇又开始转了。我这是查看了一下本地目录，还是一个文件没有。我猜是不是就在最后会把所有的缓冲的代码复制到本地目录里去啊。过了一会程序就运行完毕，果然文件都在本地目录里面，风扇自然也就不转了。看来我的猜测是正确的。

对于 BZR 的这种方式，我觉得不是很好。首先是界面太不友好了，命令行只提示了下载速度，而进度什么的都没有告诉。SVN 等工具会明确的显式正在下载的文件,这样下载是否正常也就一目了然了。而 BZR 的这种方式，在 checkout 像 Emacs 这种规模的代码时，就会让人觉得非常奇怪，也不知道下载是否顺利。而且在最后也会引起 CPU 使用过高的情况。

这是我自己做饭半个月后的感受。

之前由于家里那哥们好把厨房弄的很乱，我平时又喜欢在学校的实验室里泡着，所以我很少在家里做饭。平时的三餐基本上是这样安排的：早餐不吃（既没有时间也觉得不饿）；午餐在学校里一杯大咖啡两个蓝莓 Bagel（每天都是，弄的那里的店员每次都先问我一句是不是一样的）；晚餐或者在学校的餐厅里吃汉堡，或者在回家路上去超市买熟肉。一个学期这样吃下来也觉得没什么。

上个月上旬我室友回国了，我之前预定的下个室友要这个月才能搬过来。正在考虑怎么消化这半个月的房租的时候，突然有朋友急着要找房子，我便“勾引”他在我这里暂住一阵子，边住着边找房子，半个月找房子应该够了。在这个朋友来了之后，我又开始了自己做饭的日子。我们去超市买了菜和肉，回家后发现我之前的室友在冰箱里还留了一下还能吃的肉，我们于是就先把它们做了。

前一阵子我们经常去做运动，回家以后就累的要命，也觉得饿。我做完饭之后就赶紧吃了，也没觉得有什么。这些天开始忙了起来，回家之后就不怎么想做饭了。有些时候到了吃饭的时间，但并不怎么饿，这种事情也是常有的，周末尤其是如此。不过既然已经决定要按时吃饭了，我也就自己做了。

之前的室友留下了一些鸡翅，我之前的几顿饭就是在炖鸡翅。做饭的时间都很长，主要是后期方料后要等很长时间，这样就导致我做完饭后就觉得不大饿了，也没有了做饭前那种期待的心情，吃起来很勉强。这事也发生了很多次了。我在 Twitter 上也抱怨过，有人回复说可能是我做饭做的太艺术了。我不确定对方是不是在说反话，是在说我做的饭太过艺术以至于时间很长还是说我做的饭其实是太难吃所以自己也吃不下。难吃是不至于的，我自己也比较喜欢吃，但主要是做的时间要很长，那段时间过后基本上就是“饿过劲儿”的状态了。

之后我就在考虑，怎么样才能摆脱这种状态。自己花时间做完饭之后，还能保持想吃的心态。在国内的时候，在家里基本上都是大人做饭，有时候就算是做饭之前就饿了，等到做饭之后还是觉得想吃。自己做饭如何能保证这种状态呢？后来得到的结论就是本文的标题。

答案就是自己做饭给别人吃。第一次做完饭的话或许自己并不想吃，但再做几次总会有想吃的时候。一个厨师身边总有吃到的机会，比方说总要常常味道如何的情况呀。或者到了正常吃饭的时间，吃一些之前做好的饭应该也不错。这样的话问题不就是解决了吗？

当然，因为我没有做过厨师，不知道做一天的饭会是什么感觉。上述都是空想。：）

这是上周一发生的事情。那天由于下雪，一天当中的第二节课取消了，我那阵子没事做。正好想到好久没有去书店翻书看杂志了，正好新学期开始，也去看看要不要买新学期的教科书。

我们这边的教科书都是老师推荐的，买不买在同学。不同的老师推荐的程度也不一样，有的老师就在第一节课提一下子，说这是本好书就完了；我这学期有位教数据结构和算法分析的课，好像挺有资历的样子，我曾经在图书馆借阅过他写的图论算法书，在这学期他推荐的书是 Mark Allen Weiss 写的《Data Structures and Algorithm Analysis in Java》。关于作者我好像有点印象，似乎书在网络上的评价也不错，不过我一直印象里算法方面的书应该是 Knuth 的嫡传弟子 Robert Sedgewick 写的 《Algorithms in C》更出众一些。我在国内几年前就买过它的影印版的，当时虽然英语不行，但也感觉从中领悟了不少东西，书中的一些插图更是点睛之作。而我们的这位老师在课堂上就一个劲的推荐 Weiss 写的那本书。不过推荐也就罢了，让我们买的话好歹给各样张看看吧？结果可能是因为他之前在与学校书店沟通上发生了问题，导致书店一直没有进这本书，我们想买的话只有去亚马逊了。加拿大这边的书动辄上百，买书之前不让我拿在手里仔细翻一翻我课不安心。

在书店的计算机专业课本的书架前转了一转，依旧是没有老师推荐的那本书。另一门计算机网络课和网络安全课倒是有课本。网络课是和上学期的同一本书，我因为它太厚，觉得自己也很难看很多，因此就一直没买。网络安全的课本上讲的知识上学期学的密码学已经完全涵盖了，因此也不用买。

不用买书，我转身又去了新到杂志的书架那边去翻翻。那天书架上的 Linux Journal 竟然没有了，可能是卖完了？Wired 杂志也不在上面。我一般去那边看杂志主要就是看这两种，它们没有了，我就只能去旁边的计算机课外书那边看看了。计算机课外书就两个小架子，还有很多入门书，因此好书不多，我主要是注意在开发类的那些书上。有些书倒真是不错，不过买了来估计我也没时间看，于是就没动心思。不过我从中间看到夹着一本 《Coders At Wrok》。之前我从网上看过有人介绍好像是相同系列的，不过讲的是创业者的故事，而我对开发者的经历更感兴趣一些。书皮上印了好多名人的名字，都是如雷贯耳的“巨擘”啊。我拿下来坐在旁边的椅子上翻了翻，上来看了一会对 Jamie Zawinski 的采访，看了他对 C 语言、Perl 语言之类的评价。当场觉得这本书应该是本相当不错的消遣读物。看了下价格，似乎也不是很贵，二、三十的样子，这样的厚度和其它类似书比起来已经相当实惠了。当时就有把它拿下来回家躺在床上看的冲动。

不过犹豫再三，还是把书放回去了。主要是考虑到这学期应该也没有什么时间看消遣的读物。书价虽然不是很贵，但总是一笔钱。等回去去网上搜搜，说不定能下载下来，甚至可能能找到中文版呢。于是我最终还是不舍的离开了书店。

回去后，我又开始了新一轮的图书搜索风潮。除了找到了 Coders At Works 这本书之外，另外两门课的书也下载到了，算法的那本书还是中文版的。虽然说看起来不是很方便，但想想为了省钱，应该是可以忍受的吧。毕竟在这边和国内没法比啊（在国内前几年我买书很少犹豫的，结果买回了一堆现在看来没什么用的书）。