注意文明

我在出国前上新东方的托福课时听过很多中国人在外国的笑话,其中有几则时这样的:

许轶在美国留学时,当地的中国人发现洗衣机认的硬币和中国的几分钱硬币很像,投入中国硬币可以代替美元级的硬币使用,后来洗衣机管理员回收硬币时造成了不好的影响,于是这帮人找了日本类似大小的硬币,并且还打磨的可以投入洗衣机使用,来栽赃日本人。

一个忘了名字的老师讲过在美国犯了错误被人发现后假装自己时日本人。

当然,这些故事到底有几分真实性值得怀疑,不过作为参考放在这里也不坏。

中国传统文化有好的,也有坏的东西。比如说的不吃亏这一点,很多人认为要获利,厚黑很重要。有俗话说“怕死的害怕不要命的,不要命的害怕不要脸的”、“撑死胆大的,饿死胆小的”。生活在国外的留学生,很多人抱有这类思想。因为相对于其它比较老实的国人,外国人在国人严重已经到了“傻”的等级了。因此如果你能在国外做到不要脸的话,通常就会比当地人获得更大的利益。

前几天和室友去超市的时候,听他说起我们在语言班上课的一个同学的事。她在上课的时候不好找停车位,于是把车停在教学楼门口不允许停车的地方,打开双闪去上课。巡警看到了以为是车有问题在那里临时放着就没管,其实她要在楼里至少呆一个小时的时间。几次下来后终于被发现了猫腻,贴上了罚单。

结果是:在西方国家中,日本人常常比中国人受欢迎、台湾人也常常比大陆人受欢迎。有些中国人觉得不服气,认为是社会制度和意识形态的冲突问题。或许有这方面的道理,但个别中国人在外国不恰当的行为也有很大的因素。

用 MoinMoin 做首页

我最早接触的 wiki 系统是 MediaWiki,带我进入 wiki 这扇大门的正是维基百科。我读过一些文章描写过有些人第一次听说一种新技术而激动不已,我当时对 wiki 没有这种感觉。事实上,我那时也不理解 wiki 的作用是什么。为了尝试,我在维基百科上建立了一个 “Gnu 宣言”页面,然后把那篇文章给复制了上去。结果没一会儿,我就发现我建立的页面不见了,然后我的 talk 页面上多了这么一条消息:

欢迎加入Wikipedia大家庭!在动手之前,请先抽出时间阅读Wikipedia:版权信息、Wikipedia:如何编辑页面及Wikipedia:帮助。您也可以到Wikipedia:沙盒中实验一下,有什么问题请到Wikipedia:互助客栈提出,或者直接与我联系。请注意Wikipedia并不收入原始资料。例如“GNU宣言”一文,应当加入介绍GNU宣言的文章,而不是原文。谢谢!–Formulax 2003年8月9日 02:42 (UTC)

这是我第一次的 wiki 的体验。这之后,我陆续在维基百科上进行过数次编辑,渐渐的了解了 wiki 是什么东西。不过,真正让我体会到 wiki 可以用来生成网站的页面是后来的事情了。

当我意识到 wiki 可以用来生成首页时,我已经用一个手写的 HTML 静态页面来做我的首页几年时间了。因为时我随意手写的,因此那个网页非常简单,上面除了我的名字之外,就只有一些我别的网页的链接,比如说 blog、相册等等。之前我还在上面放过我写的论文、我的头像等等,不过靠手动来管理这些东西,实在是太麻烦了,我渐渐的就把它简化成了像这样最最基础的页面了: My homepage until Feb 11, 2012

我过去是通过 ssh 登陆到主机上,用 vim 来编辑 index.html 文件来制作首页。有时候要往上面放中文时而终端不支持中文字符的话,就用 Emacs 远程编辑这个文件。我也考虑过在本地写好了所有的东西后再同步到服务器上,但这些页面保存在本地上,我又不能随时带着电脑,没法做到随地修改,还是太麻烦。正因为没有一种非常方便的编辑页面的方法,所以我的首页都是万年一个样,我都想考虑过要不要把我的 blog 直接放在根目录下呢。直到后来我想到了 wiki 可以帮我完成这一切。

其实,我最早想用到的工具不是 wiki,而是 Movable Type。MT 5 出来之后,我发现它在过去的基础上添加了 website 这个概念。经过尝试,我觉得 website 就是用来放 blog,这其实不就是一个网页么。而 MT 的后台编辑也勉强可以达到我的要求了。把 blog 和首页一起生成,不但让首页的风格跟 blog 统一,而且还可以让首页趁此机会丰富一下内容。可惜到后来我失败了。当我对 MT 5 的了解加深之后,我才发现 website 并不是我要的东西,中间有些东西要配置起来实在是太复杂了。

MT 不行,我之后才选择了 wiki。出于我个人对于简洁的喜好,我选择了相当简单的 wiki 系统——UseMod Wiki。安装它特别容易,我很快用它生成了一个比较不错的页面。但是当我往页面上添加东西时,我发现这个 wiki 系统不让我在页面里添加 HTML 代码,而它本身的格式功能也比较弱,这就让我感觉很不爽。比方说我想在页面上放几个贴纸,人家给出的代码我复制过来就没有用。我找过不少资料想解决这个问题,结果发现原来时出于安全的考虑,它禁止在页面里插入一些 HTML 代码。不仅仅是 UseMod Wiki,我找了一些其它的 wiki 系统,都禁止你这么做。如果一个 wiki 是给一个团队用来统一管理文档的,那么这种安全措施非常必要,但对于一个把 wiki 自己用的用户来说,这样就非常不方便了,尤其是我还希望可以用它来生成我的首页。

在尝试了一些其它的 wiki 之后,我渐渐的开始怀疑我这样做是否正确,是不是也有其它人和我一样用 wiki 来生成自己的首页。当中我早就听说过 MoinMoin,但我一直没有成功的安装。原因是那时我对于 FastCGI、WSGI 之类的没有任何经验,因此对这类程序完全不开窍,所以我那时选择的 wiki 基本上是 PHP 写的或者是 Perl CGI 的。到后来我渐渐的对这一点死心了,觉得或许用 wiki 来做首页有点不太实际,于是在 2010 年 2 月,我在空间上用 MediaWiki 单独搭建了一个 wiki

从那时候开始,我也尝试并转换使用了一些其它 wiki 工具。当然 MediaWiki 用的时间最长,后来我换成了 DokuWiki,然后是 MoinMoin。每换用一个 wiki,我都想过如何用它来管理首页。当中我也做过尝试,比如说把 DokuWiki 放在根目录下,把命名空间的分隔符由默认的冒号换成斜杠,结果页面没法显示了。我还考虑过在根目录下搭建 MoinMoin,然后 blog 之类的其它域名指向它们的子目录。结果这样我的 blog 就没法访问了,链接全被 MoinMoin 给拦截了。要让子目录可以访问,只好在 Apache 的配置文件里给它们添加 Alias,实在是太麻烦了。

不过几天早上我突然想到,MoinMoin 不是有用户页面么?在一个团队中,每个人都有自己的页面非常正常,那么私人的 wiki 呢?个人页面不是和我的首页用途重复了么?既然这样,我就用 Apache 的 rewrite 模块来把根域名转向到我的 MoinMoin 的用户页面上不就行了么?经过尝试,我发现这样做确实可以。我很愉快的在我的个人页面里加上了很多东西,编辑完毕后点一下保存,页面马上就生成了,非常方便。而且完全没有字符编码的问题,因为一切都可以在浏览器中完成,我也可以随地编辑我的页面。要在页面上放插图什么的,也不需要我手动用 FTP 来搞来搞去了,都交给 wiki 来管理,太方便了。

虽然我不知道这样做是不是一个好的主意,但至少现在它满足了我一直以来的愿望,现在看来它完全满足我的要求吧。

Wiki 和 Blog 对我来说本质上不同

我最早用 MediaWiki 在自己的共享空间里搭建了一个 wiki 之后,曾经有过不知所措的感觉。在用之前觉得自己有一个 wiki 来说应该会很方便,但有了 wiki 之后又不晓得改往上放什么东西。

我在考虑了之后,发现在我原先的想象中,wiki 与 blog 的职能有很大一部分是重叠的。因为这两者都是我的思维的一个输出端口,那么当我有了东西要写时,我是把它放在 blog 上呢、还是 wiki 上呢?我在建立 wiki 前已经用了很长时间的 blog 了,那么我为什么还要再建立一个新的输出渠道呢?

在我接触过的 wiki 中,有许多都是多人共同维护的 wiki。这些 wiki 有一个主题,只要有了跟主题有关的内容,都适合往 wiki 上面去放。而对于一个个人的 wiki,这就有点行不通了,因为个人是一个既大又小的主题。往大里说,所有与“我”相关的东西都可以算作个人这个主题的内容;往小里说,个人的事情太琐碎了一些,没有往 wiki 上整理的价值。而 blog 就非常适合这个方面,不管有的没的都是一篇文章,而一个 blog 都跟个人有关,这样的信息整理就显得非常自然了。

所以在一段时间内,我甚至仅是把我的 wiki 当作一个收藏夹来用。在里面建立一个页面,把我想收藏的链接分短期和中期写在页面里。因为经常有一种情况发生:我在浏览器里打开了许多标签页,在我没有把它们都看完的时候,我想关闭浏览器或者把这些页面都放到一个更安全的地方去。直接用收藏夹不是很合适,因为有些不是我想要收藏的,只是想有个临时的容器把它们放一放,而我的 wiki 页面就做了这样一件事。后来我为了挖掘 wiki 更多的用处,我还用它来记过课堂笔记。到后来我渐渐的才开辟了一些如口琴、VPS、Emacs等话题,把日常遇到的一些琐碎的信息放在里面。

直到上个月,我在买了两个新的 512M 的 VPS 之后,发生了一件事让我对 wiki 有了更加清晰的认识。话说在我第一次使用 VPS 之前,我对自己管理一个服务器一直处于一种比较惧怕的状态。后来当我有机会使用 VPS 并自己操作过一次之后,我发现其实 VPS 不是那么的令人恐惧的,于是我的意识里对于我对 VPS 的知识设定变成了“会了”。但当我这次买了新 VPS 之后,我本来以为我可以很容易的把所有的安装、设定都很快独立的完成,结果我发现我错了。服务器这东西就是你做完一遍就不想再触摸的东西,如果你天天配置自己的服务器,那么你基本上就没有在做正事了。所以,在我把 VPS 设定好后,我就没有再摸过这方面的东西,因此这次需要我来配置 VPS 了,我给抓瞎了。所以我只好从往上找别人写的流程,一点一点的按照自己的需求配置。

当我配置好了 KVM 这台 VPS 后,我又买了 XEN 服务器。这次配置的时候,我决定把我的配置过程在我的 wiki 上记录下来,特别是配置文件,那个文件改了那里,这些都是非常琐碎的东西。把它们记录下来,之后再遇到类似的情况,就可以按照我的记录,很快的完成配置。

于是我在安装、配置的同时,也把中间的操作详细的记录了下来。在这个过程中,我多次有过想要放弃的想法,因为太麻烦了——毕竟当你在键盘上操作了一会,还要再在另一个地方把你自己的操作记录下来,这不是一件轻松愉快的事情。不过把所有事情做完之后,我觉得付出是值得的。看我写的流程,之后配置服务器就可以按照这一套来,完全不用担心中间漏掉了什么东西。

在这次经历之后,我渐渐的发觉对我来说,写 blog 和写 wiki 是两种完全不同的体验。写 wiki 有的时候很痛苦,因为我需要把我脑中想的给整理出来。这里的“整理”不仅仅是把思想给转化成文字后书面化,而是要把琐碎的思想给分清条理,中间有几个章节,哪些内容该放到哪个章节里去,这些都是需要考虑的。而写 blog 相对而言就轻松多了,只要把我脑中想好的话敲下来就好了,不需要进行过度的整理。也许有人会把自己的 blog 弄成一个知识库,给自己和别人浏览。我在配置自己的 VPS 时也参考过很多 blog 文章,它们对我很有帮助,但我自己写不出这样的 blog 文章来。虽然我也有这方面的文章,但它们都在 wiki 里,而不在 blog 中。

总体来看,我觉得 blog 对于我来说就是纯粹的输出,而 wiki 对我来说时整理。Blog 的内容时未经整理的,我常常时想到什么就写什么,虽然常常会想如果把文章重新整理一下会更好读,但我实在时没有这个耐心。我现在要找过去 blog 文章里的信息,需要搜索,而 blog 现有的分类体系实在时不适于信息的整理。而且,blog 对我最大的作用时日后可以回顾从前发生的事情于我自己的想法,未经整理的信息输出就已经完全足够了。而 wiki 由于自己的格式的原因,给我了一个整理自己的信息的地方于机会,从而弥补了我的 blog 的不足。所以,笼统来说,blog 承载着我的思想的感性的一面;而 wiki 承载着的则时我的思想的理性的那一面了。

惊人的 PyBlosxom

好像在 2007 年初那会我对 blog 刚刚开始感兴趣的时候,就听说过 Blosxom 了。它是个非常简洁的 blog 发布软件。其核心程序只有一个 cgi 文件,里面是 Perl 代码。它的功能也十分简陋,连最基本的评论功能都没有。而这些功能都使通过插件来完成的,页面的样式通过 flavours 来安装。我曾经在自己的共享空间里实验过,比较麻烦,不符合我的要求,于是我就没有再管它。

后来我在 blog 上写过一篇文章,提到过我安装 Blosxom 的事,之后 Zoom Quiet 给我留言,说他在用 PyBlosxom,是用 Python 语言写的 Blosxom,而且他的 blog 就是用 PyBlosxom 支持的。我去了他的 blog看了一下,功能上确实和 Blosxom 很像,但他的 flavour 设计的非常漂亮,不过也没有安装评论等插件。当时我对 Python 还没有什么兴趣,因此就没有再关注 PyBlosxom 程序。

今天我在配置 MoinMoin 的时候,想过用 MoinMoin 等 Python 程序来管理我的整个网站,blog 方面我自然就想起了 PyBlosxom。我去了它的网页上看了看,它的首页跟 Blosxom 没什么两样,不过它的文档让我很惊讶。这些文档完全已经 Python 化了,和其它 Python 工具的文档风格,以及 Python 自身的文档风格,完全统一了起来。我在实验用的主机上尝试安装了一下,同时参考了一下文档,结果 PyBlosxom 给我感觉变化很大,安装了程序文件之后会用一个脚本文件自动创建 instance,跟 MoinMoin 非常类似,帮你建立好了插件和 flavours 的目录,而配置的内容也被分离到单独的文件中去。不光是原始的 CGI,PyBlosxom 也支持了静态输出、WSGI 等发布运行模式了。同时,URL 等设计,都可以看出和原始的 Blosxom 有非常明显的不同,相当不错。

我在想,也许这就是社区的力量之一吧。与此相比,Blosxom 的网页在这几年中的基本上没有什么变化,还是原先那样的简陋,而它的文档系统也比较原始,更别提它的程序本身的安装和配置还是跟过去一样的原始与晦涩了。是什么原因造成了两者之间那么大的差异呢?我觉得关键就是社区。目前 Perl 社区虽然早已发展成熟,但不可避免的是社区本身的年龄过大,已经有了苍老的态势了。虽然 CPAN 为 Perler 们津津乐道,但要是想要自动安装一个包,它的命令行远不如 RubyGems 和 Python 的 setup-tools 方便。关于 Perl 的语法,我觉得也在一定程度上阻碍了社区化的进程,主要是它在维护方面不如 Python 等新兴语言程序来的方便。

总之,作为一个商业语言,有一个强健的公司对它维护才是正道,这时 VC 笑到最后的关键;而作为一个开源的语言,有一个稳定、有活力的社区才是关键。

终于开始使用 MoinMoin

今天我终于把自己的 wiki 系统换成了 MoinMoin。

我对 MoinMoin 算是觊觎已久了,我的 blog 上关于 MoinMoin 最早的一篇文章是两年前的《还是建了一个 wiki》,那也是我在自己的网站上搭建 wiki 的开始。本来我用 wiki 是像用它来管理我的网页,因为这样可以在浏览器里用方便的结构化文本来生成页面,而不用我麻烦的手写 HTML,当时我试用了几个 wiki 程序都不符合我的要求。主要原因是 wiki 的内容限制有些死板,我不想把我的首页弄得像一个 wiki,我想让它像一个网页。而那些 wiki 程序都以安全为由把用户可以输入的内容限制的死死的,令我非常不爽。后来我放弃了用 wiki 来管理整个网站的想法,转而建立一个单独的 wiki,于是我在当时用的 Site5 共享空间上用 MediaWiki 搭建了一个 wiki。当时我已经想用 MoinMoin 了,可惜用共享空间来搭建 MoinMoin 太麻烦,我最后放弃了。

到了 2010 年的 10 月,我自己开始试用了 VPS,当时也尝试过安装 MoinMoin,不过失败了。虽然现在看来我觉得安装 MoinMoin 不难,但对我来说有些事情是必须要经历过一次才能理解的,在这之前我没有成功的在远程主机上安装成功过 MoinMoin。

2011 年 7 月 2 日我第一次在自己的 VPS 成功安装了 MoinMoin,用 Nginx + FastCGI 来运行,感觉不错。不过由于中文文件名等原因,我到了第二天就放弃了

今年年初我第一次给自己买了 512M 内存的 VPS,有很大的资源可以让我稍微挥霍一下,不用严格计算内存的用量了。本着学习的想法,我在这个 VPS 上装上了 Apache 服务器。在稍微熟悉了一下 Apache 的配置之后,我尝试着在上面跑 MoinMoin。MoinMoin 的文档上说用 WSGI 来运行 MoinMoin 是推荐的方法,但我就是没办法让 MoinMoin 在 Apache + mod_wsgi 模式下正常运行,于是我的尝试又一次失败了。那时我把 wiki 程序换成了 DokuWiki,用起来感觉很不错,当时我基本上都决定了之后就一直用 DokuWiki 下去了,结果命运弄人,偏偏我这时候瞎猫碰上死耗子一般的成功把 MoinMoin 在 Apache + mod_wsgi 模式下给跑起来了。

我今年初在买 VPS 的时候,因为 Ramhost 的 512M OpenVZ VPS 断货,于是我就买了 KVM 的。后来我又找到了 YardVPS 的更廉价的 512M Xen VPS,于是我最终把我的网站放到了 Xen 上。而 KVM 在这一个月内就被我用作了实验的机器。在把可以安装的操作系统装了个遍后,空余下来的我又尝试了一次安装 MoinMoin。这次我按照这篇文章中的讲解做了一遍,结果就成功了。对比这次和我之前的安装方法,我发现很大一部分原因是我中间少了给 moin.wsgi 文件添加查找路径那一步,还有就是我对 WSGIScriptAlias 要放在什么位置有困惑,这次上我试验了一下就给成了。

我是在实验用的 KVM 主机上安装的 MoinMoin,但要不要用它来替换我正在使用的 DokuWiki,我还拿不准。我稍微的在实验用的主机上用 MoinMoin 添加了几篇文章看了看,发现 MoinMoin 和 DokuWiki 的 wiki 语法在有些方面正好相反,需要转换一下;后台文字界面的编辑器没有乱七八糟的多余功能,其它方面的差距并不是特别明显。相比较而言,DokuWiki 更加方便一些,功能都被配置到了最好,安装上去后几乎不用改什么地方就可以很好的使用,而 MoinMoin 的配置性更高一些,看了一下帮助文档,我也学到了很多东西。

我之后打算把实验用的 MoinMoin 给搬到我的工作主机上来,先放在不同的目录下,同时运行,在转移数据的同时也好做对比。不过这时,发生了一个小意外。

我原本的 DokuWiki 是放在 /public_html/wiki 下面的,为了把 wiki 这个名字让给 MoinMoin,我在 ssh 里执行了 mv wiki doku 命令,之后进去 doku 目录找我过去的页面,发现我原先的页面都不见了。大惊之下我仔细检查,发现我原先在安装 DokuWiki 的时候就在 /public_html/doku 下面安装过一个 DokuWiki 来做实验,确定它运行正常之后才在 wiki 下面重新装了一个新的 DokuWiki。而原先的目录没有删除,结果这次出了问题。

我当时脑子不清晰,觉得这有些出乎我的意料,因为我印象里是如果 mv 命令的目标目录已经存在的话,是会覆盖目标目录的,结果这次却是把原始目录给丢掉了。虽然很不解,但我并没有太过担心,因为网页在 Google 上还有缓存,我可以用搜索出过去被缓存的页面,再从上面把内容转移到新的 wiki 中去,虽然有些私有页面和孤立页面没有被缓存很可惜,但我的损失并不大。这也让我下定决心转移到 MoinMoin 上来——因为 DokuWiki 已经被我给弄丢了。结果当我慢悠悠的转移了一个页面之后,再从 Google 搜索里打开其它的页面缓存的时候,我发现那些缓存竟然失效了。看来是在我编辑那个页面的时候,Google 访问了我的主机,发现原先的页面不存在了,于是就把缓存设定成失效了。我抱着试一试的心情去 web.archive.org 看了下,它根本没有收录我的 wiki,我这时才真的急了。

之后我发现我在换到 DokuWiki 之前用的 MediaWiki 还在,我没有删除它,只是给它变了个域名,而里面还有一些早期版本的文章。这让我心情稍微平复了一点,我毕竟没有失去一切,虽然在这一个月内我往 wiki 里添加了很多内容,这些内容的丢失还是让我心疼的想砸电脑来泄愤。话虽如此,这毕竟是我自己的所作所为,也怨不得别人,我也只好接受现实,默默的把文章从 MediaWiki 往 MoinMoin 上转。结果在转移的途中,我竟然看到了 /public_html/doku/wiki/ 这个目录,进去一看这不就是我之前的 DokuWiki 吗,原来我之前的数据还没有丢。静下心来回想了一下,我在执行 mv 命令的时候,目标目录 doku 已经存在了,结果不就是把原始目录给移动到 doku 下面吗。想到这里,我不禁想抽自己一耳光,惩罚自己犯下了如此低级的错误,白惊慌了一场。

之后就好说了,我把过去的数据下载下来,自己一篇一篇的添加进了 MoinMoin 中。文章不算太多,我手动修改添加也没有费多少功夫。当然,在做这些的同时我也学到了不少东西。比如说过去我以为 MoinMoin 没有最近更改这项功能,结果发现这是需要在 RecentChanges 页面下面添加一个 macro 才能搬到的,虽然我很奇怪为什么 MoinMoin 不直接把这个 macro 加到 RecentChanges 里去,不过这样也是 MoinMoin 定制性高的一种体现,毕竟易用性与定制性算是零和博弈的关系。

从两年前到现在,我的主机上的 wiki 系统终于演化到了我的目标 MoinMoin,让我有了一种两年的长跑结束了的感觉。当然,我对于 MoinMoin 的接触才刚刚开始,我已经发现 MoinMoin 有很多我不了解的地方,看来我在将来又可以学到新东西了。