服务器的文件不知不觉的被人动了

今天早上偶尔访问我的服务器上的文件时,发现当我访问一个 HTML 文件 时,Chrome 浏览器提醒我这个页面有不良程序。

Chrome 浏览器发出的警告
Chrome 浏览器发出的警告

我第一个反应是“怎么可能”,这明明是我自己的服务器,文件也是我几年前自己编辑放上去的,有了木马我自己怎么可能不知道。不过为了以防万一,我用 SSH 登陆了服务器检查了一下,没想到这个文件里确实有不明脚本。

不良脚本的内容截图
不良脚本的内容截图

这个文件很老旧了,早在我还在用 Dreamhost 共享空间的时候就已经存在了。中间我的帐号也被黑过,因此有些文件被加了木马也是有可能的。这次这个脚本是用 JavaScript 写的,放在了 </html> 的后面,用 DOM 语法在页面里插入一些内容。具体作用是什么我不清楚,因为脚本里加了一些乱码来变换真实内容,我也没有兴趣去仔细研究它。

我检查了一下其它文件,发现没有问题。

惊人的 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 有很多我不了解的地方,看来我在将来又可以学到新东西了。

本地的才最可靠

随着对计算机的使用时间越来越长,我对于信息的种种理解也在不断变化着。

开始的时候我受版权的思想很深刻,也把一切都想象的很美好,坚定的认为所有信息都应该有且仅有一份,我们的网络通过超链接把所有的信息给串联起来,我们可以在任何地方、任何时间找到我们想要的任何信息。在这种思想的影响下,我认为一切“转载”之类的活动都是邪恶的,这种冗余浪费资源,也浪费我们搜索信息的效率,因此发生了这篇文章中记录的事。后来我不再那么激进了,但我依然不认为网上有了重复的内容是一件好事。管不了别人,我自己都是尽量按照这种要求来做的。

不过最近我开始改变这种想法了。

起因是因为我发现一些网页已经消失了。本来我想的是这些信息随时都可以从网上找到,因此我一般就在 Del.icio.us 里加一个链接就可以了。我从 2005 年开始使用 Del.icio.us,总共记录了将近 500 个链接。最早我没有自己固定使用的电脑,因此随时可以访问的 Del.icio.us 就特别吸引我,后来有段时间我干脆把它与我的浏览器的收藏夹给结合了。虽然 500 个链接对于别人来说不过是沧海一粟,但我一直重用着 Del.icio.us,把自己认为重要的链接都交给它去保管。在这几年中也有别的网络书签服务,比方说 Mister Wong 和 Google Bookmarks,但我一直特别信赖 Del.icio.us,一直没有切换。结果 Del.icio.us 几经易手,最后还是稳定的坚持了下来。

不过 Del.icio.us 稳定,不代表里面的链接稳定。在 2005 年那阵子,blog 对我来说,还是一个非常新鲜的词汇,我也不看好 blog 这种服务,但 blog 确实是在国内蓬勃的发展着。那时候我自己不看好 blog 这个东西,因此自己没有使用,仅仅是一个观察者,对于任何 BSP 的服务我都没有尝试过。不过那时候有很多人就已经开始玩 blog 了,而且很多有经济能力的人不仅仅满足于使用免费的 BSP 提供的服务,而是开始自己买共享空间假设 WordPress 等程序。虽然很多人是合租的空间,但我在 2005 年至 2008 年之间看到过很多这样类似的 blog 网站,我也看到了很多给我印象深刻的文章。

后来我渐渐的会发现有些网站无法访问了,因为作者没有给自己的空间续费,因此服务器就给停了,点进域名后看到的也只是卖域名的网站的广告,看来那些人们放弃维护 blog 后连自己的域名也不要了。一开始发现这种问题的多数是一些无关紧要的 blog,我没有特别在意。不过前几天我心血来潮,整理了一下我的书签,发现有相当多的网站都关闭了,其中不乏一些技术 blog。也有一些网站虽然未必有很多技术内容,但里面有一些我喜欢读的文章,也都统统不见了,让我觉得非常遗憾。

大上个星期我一直比较关注啄木鸟社区这个 wiki,以及它的元老之一 Zoom Quiet。我从这个 wiki 上看到了一些 Zoom Quiet 的演讲,其中的一个《我的工具箱》的演讲中他提到了他用 ScrapBook 在几年中离线保存的很多网页,并把它们统一导出,组织在一起,共享在了他的主机上

我之前听说过 ScrapBook 和 Zotero 这些 Firefox 插件,但一直认为它们对我来说没什么用,结果这次看了 Zoom Quiet 整理的这些页面后才让我感觉非常震撼。Zoom Quiet 在演讲录音中得意的说在他用 ScrapyBook 来静态保存有价值的网页的这几年中,发生很多次他保存过的网页失效的情况,结果因为他把这些网页都保存了下来,他从来不怕这些网页失效。我听了不由的想,如果我几年前开始保存的不是网页的链接,而是网页本身,会不会就不会发生我今天这种保留了网址而网页却失效的尴尬事了。

过去我还用过 Evernote,但我只用它来保存过我不经常去的网站的内容。其实 Evernote 也可以很好的完成这种人物,但我过去一直没有强烈“网页”有可能会消失的意识,因此也一直没有关注这些东西。

在一些网站建站工具中,我特别喜欢 wiki 这种东西,原因之一就是因为它有版本控制的功能,可以保障我们在上面发布过的内容永远都不会消失。我曾经多次考虑过用 wiki 工具来管理我的网站,虽然由于种种原因一直没有实现,但我仍然喜欢在自己的主机上放上一个 wiki。我曾经幻想过,如果我们的互联网有一天有了版本控制功能,那么我们会不会方便许多。不过虽然愿望是美好的,但实现起来还要好几个技术阶段。看一看 MediaWiki 的历史就会理解要弄一个百科全书规模的网站会给服务器带来多么大的压力。

我曾经也盲目崇拜过一些大公司,认为它们永远都不会倒闭,把数据放在它们那里是非常可靠的。随着时间的发展,我渐渐的也改变了这种想法。“永恒”是人们的希望,但没有可以绝对永恒的东西。Google Wave 刚出来的时候我非常激动,结果一年左右它就被关闭了。我不知道哪一天也许 Google 就关门了。过去我认为这不可能,但现在我不 100% 期待了。虽然也许有点极端,但为了保证数据的安全性,我不觉得这样考虑非常过分。正好我今天看到一个运行在 Google App Engine 平台上的图片管理程序 FotoRatan,在它的 plans 页面 里列出的付费方案的时间限制写的是“till google die”。我过去会认为这表示这个服务是永久有效的,而现在我确定它的期限是 Google 关闭的那一天。

今天,我的数据很多都在各大网站上。比方说我的私人电子邮件都在 Gmail 里、照片都在 Flickr 里。我过去认为这样很可靠,不过后来我有点后悔。因为这样就表示我把一切都押在这些公司的生存上了,一旦它们倒闭,我的资料也许就全丢失了。因此当我有了自己的域名之后,我开通了 Google Apps 服务。最开始时时因为我觉得有个以自己域名为后缀的邮箱很酷,现在我觉得这样的好处是一旦 Gmail 坏掉了,我的邮箱地址还是有效的。自从我开始用 VPS 之后,我学会了把 Gmail 中的邮件备份到自己的服务器上,我还考虑过时不时自己运行个邮件服务器给自己用…… 直到我意识到这是一种强迫症为止。

Flickr 也是一样。我在很久之前分析过几个提供照片存储服务的网站,最后选择了 Flickr,并且用了 4 年的付费 pro 帐号。不过我不是那种喜欢没事拿个相机乱照的人,目前从设备上来说把照片从相机弄到电脑里也挺麻烦,因此我上传的照片都不多,加上 Flickr 在国内访问的问题,我在今年就没有继续付费,而是开始把照片放在自己的服务器上用 Gallery 程序来管理,这点我没有什么经验,正在实验中。

当然,个人在网络上的数据最多还是 blog。像微博那样的东西还没有成熟到我可以把它当作保存数据的东西,因此不予考虑。从 2005 年到现在,我发现有些商业的 BSP 都已经关门了,何况私人主机上的 blog。更多的情况是网站存在,但一年多都没有一点新内容发表了。到今天我自己决定要把自己的 blog 继续维护下去,但我实在是不能确定别人也会一样这样做,这实在是一个令人沮丧的问题。不过如何能重新调动起人们对自媒体的输出欲望,也许这是一个新的商机?

总之,对于网页,我希望它们不朽,但很多情况下事与愿违。如何更好的保存信息,让它们保持有效、保持有效率,互联网的演化仍然需要继续。

TechCrunch 与信息混乱

前天早上出门前的一段时间,我偶然间打开了著名的科技 blog TechCrunch。这个 blog 我很早之前就听说了,但我从来没有直接的阅读它。因为它的信息量非常大,而它的主题——一些新兴的计算机科技不是我特别关心的,因此我从来不订阅上面的文章,而是转而关注一些信息量稍微小一些的技术 blog。

虽然说我知道它的信息量大,但我从来没有想过它的信息量居然大到了令人发指的地步了。那天早上,我首先打开了 TechCrunch 的主页,然后又去别处做了点事情,不到 5 分钟后回来,刷新了一下页面,结果发现它竟然多出了 2 篇篇幅不小的文章。而这竟然不是偶然情况!在之后的几分钟之内,我有意识的刷新页面观察它,发现几乎每隔几分钟都回有新的文章发布,这实在是太惊人了!

首先,从技术上来说,这本身就是一个相当大的挑战。特别是这种多人协同书写的网站,在人数多的时候会有相当严重的效能问题。我那天早上正巧还读了 MediaWiki 的历史,里面举了维基百科在开始的几年遇到的访问量过大的问题。虽然我不知道维基百科目前的写入操作的频率是多少,但我在我观察 TechCrunch 的那一段时间内,感觉 TechCrunch 的写操作已经相当频繁了,毕竟一刷新就出来几篇新文章,太直观了。写操作尚且如此,读的人数应该更多。TechCrunch 使用 WordPress.com VIP 的服务,我对这个服务了解不多,只是知道它很贵,估计它会很好的解决这种高流量的问题吧。

更重要的是,我觉得从内容上来说,TechCrunch 的容量相当巨大。我数了一下,1 月 17 日总共发布了 56 篇文章。保守估计,如果每年 TechCrunch 都会发布 50 篇文章的话,那么它一个月的文章数量会有 1500 篇,一年的文章数目会有 18000 篇文章。这些文章不需要长篇大论,比方说每篇文章平均的字数是 150 个英文单词,那么一年下来 TechCrunch 相当于写了一部 2700000 字的书。这仅仅是一年的内容含量。

我在 2009 年写过两篇文章:《Web 2.0 和熵》和《互联网应用的趋势》,提出了互联网应用发展的两个方向——秩序和混乱。有些应用是给我们带来秩序的,也就是把信息的熵(混乱程度)降低的,比如 wiki;有些应用则恰恰相反,比如微博。宇宙的发展趋势是趋于混乱,互联网也是类似,因为制造混乱比制造秩序容易(想象你是发一条微博容易还是整理一篇 wiki 条目容易),但总体来说两者都在或快或慢的发展着,目前是维持了一个平衡。

前天我在惊讶于 TechCrunch 的更新速度的时候,突然想到了一个问题:TechCrunch 是创造了混乱还是创造了秩序?

从这个网站输出的信息量来看,它是制造了混乱。几篇文章是没法产生很强硬的秩序的,这样文章的频率多了,信息输出的就更加混乱了,估计没几个人不用做事把 TechCrunch 的每篇文章都通读一遍。但也不是绝对如此。把世界各地科技发展的新闻总结成文章,汇编到一个网站来发表,着其实也是产生了秩序。虽然说这些信息的时效性未必很强,但总归是被总结成了人类可以方便阅读吸收的形式。倒地是产生秩序还是产生混乱,从不同的角度会有不同的结论。

作为一个上世纪八十年代末出生的中国人,我家里有父母辈的亲戚于九十年代初期在机关里工作。在那里给我的一个很大的印象就是报纸。每个办公室里都有一个报架,用很长的一根木头把报纸都钉起来,人们日常的重大休闲活动之一就是读报。那些机关报纸在我小时候还没有懂很多事之前看起来要多枯燥有多枯燥,不过我的印象特别的深刻。

看了 TechCrunch 的网站,我觉得它其实就跟我们那时候的报纸一样。那时候报纸的主题是机关的文件、精神等等,而 TechCrunch 的主题则是科技产品。如果把 web 版的 TechCrunch 做成报纸,我觉得我就可以更加自然的去看待它了——其实它跟报纸也没什么不同么。我过去可以接受看报纸,我估计我应该也可以接受 TechCrunch 这种信息量,因为两者之间是非常相似的。

报纸呢?报纸又是创造秩序还是创造混乱的东西呢?或许两者都有。信息被编译成了文章,着创造了秩序,而每天的报纸的流量,又创造了混乱。我们看完报纸是不是就会扔掉而不再关心它了呢?还是说我们要把它们存档留待日后搜索?对于普通人来说我看机会大概不大吧。TechCrunch,或许就是在用做报纸的方法来做一个 web 2.0 网站,虽然我还没有从报纸的模式转换到网站的模式,但信息确实是足量了。不过我隐隐觉得把报纸放在网络上这种做法行不通,TechCrunch 目前的形式也不是我喜欢阅读的形式。虽然我还没有这方面的论证,但我觉得我们应该会发掘出更加适合报纸类站点的 web 2.0 模式。

能不能给我一个靠谱点的浏览器啊

前几个星期,我因为 Firefox 把我的系统拖的非常迟钝,我忍无可忍,于是把浏览器切换成了 Safari。

我在用 Firefox 打开一些标签页后,从 Activity Monitor 里 Firefox 占用的内存,基本上没有下来过 500M 的,经常还可以上 G。我的机器的内存一共才 2G,一个浏览器就给我占用一大半,这让我情何以堪啊。

当然,我承认我打开的标签页或许有点多了一些,但好歹也不应该这么糟蹋内存啊。而且浏览器的内存释放机制可能有点问题,当我把标签页一个一个的关闭后,内存还是没有被释放,于是我一气之下就换了浏览器。

我的想法是或许 Firefox 的代码里有内存泄露的地方,毕竟 Firefox 是跨平台软件,横跨 Windows / Linux / Mac OS X 三大平台,肯定在 Windows 平台上的开发力度最强,Linux 或许次之,而 Mac 平台,是不是亲妈还两说呢……既然这样,我觉得 Safari 作为苹果公司的产品,肯定应该侧重于 Mac 平台,那么它的内存管理应该非常出色吧。

打开了 Safari 没一会,我才意识到“天下乌鸦一般黑”。看来只要是浏览器,就都有内存管理方面的问题。Safari 在某些方面甚至还不如 Firefox。有些问题,我不知道苹果公司是怎么想的,相当的诡异。

比如说,Safari 一般会占用两个进程,一个是 Safari 自身,另一个是 Safari Web Content。Safari 进程占内存 50M 至 100M 之间,是 Safari 的主进程;Safari Web Content 占多少内存看你打开了多少网页,它是 Safari 占用内存的大户,在我这里常常上 600M。我估计双进程的作用是防止 Safari 因为网页内容而崩溃,当 Safari 解析一个网页发生了系统错误时,崩溃的是 Safari Web Content 进程,然后 Safari 进程会重启 Safari Web Content,页面会被重新载入。

问题就在这里,据我的观察,Safari 似乎有一种什么策略,每到固定的时间,会重新载入 Safari Web Content 进程,这样导致页面会被重新载入。又一次我在一个视频网站打开了一个视频,让他缓冲完毕后准备上床上去躺着看视频,结果等我躺下后这个页面开始重新载入,我之前缓冲的内容也全都丢失了,真让我大骂怎么会有这么弱智的策略。

除了这个问题,Safari 还有一些界面上的问题让我觉得非常难用,所以基于这两点问题,我昨天只好把浏览器又换回了 Firefox。

换回来之后其实跟 Safari 还是一个德行,经常我只是点了一下网页中的文本框,我的鼠标指针就会变成小球转上一会,Activity Monitor 里的 Firefox 后面的 (not responding) 也出现了不止一次了,而且频率还特别的高,搞得我经常有砸电脑的冲动。

我想,也许 2G 的内存已经没法应付 2012 年的日常生活了么?记得我家里的第一台台式机的内存只有 16M,我在家里还可以勉强的运行 Windows 97 + GoSuRF 来上网。那时候家里还是用的 56K 调制解调器拨号上网,速度非常慢,我也不敢开太多的标签页,也许这样子让我觉得其实操纵起来还挺流畅的。2008 年 4 月 1 日我买这台 MacBook 的时候,2G 内存算是主流配置了,或许比主流还稍微的高一点。那时候用这台机器来上网绝对没有今天这样那样的问题。那时候操作系统还是 Leopard,Safari 的版本好像还是 3,Firefox 到了 6 月份才发布版本 3,现在 Firefox 的版本已经窜到 10 了,结果反而我的机器带它有点吃力了。

前一阵子我知道了 Mac 有一个 purge 命令,可以清除 inactive 内存。Mac 下的程序在推出后并没有马上清空内存,这些数据就呆在 inactive 内存里,当你重新启动这个程序的时候,这个机制会让程序的启动变快。而常常这块内存被占用着并不是我们所希望的,于是可以用这个 purge 命令把这块内存给释放了。我知道了这个命令之后,发现我明显用这条命令的次数增多了。

我在 2008 年 4 月 1 日正式开始使用 Mac 之前,我还用了几个月的 Linux。虽说当时我觉得 Ubuntu 用一阵子后慢的跟蜗牛似的,但后来我用了 Gentoo 后就感觉速度像飞一样了。再加上我用的桌面管理器是 FVWM,占用资源非常低,我印象里那时候我跑 Firefox 从来没有遇到过这么卡的情况,也许 Mac 的内存管理机制有一定的问题?

几个月前我跟张昊聊天的时候,谈到他目前使用的电脑。他的 MacBook Pro 的内存好像就不小,然后他把硬盘换成了 SSD,据说速度飞快。看来我只好期待我的下一部电脑了。

海词迷你版

过去我经常在海词查单词。海词的内容挺不错,但是界面有些过于花哨了,看上去也很困难。我于是就想在终端里用一个简单的工具来从页面里提取我需要的单词释义,于是就写了一个 Perl 程序来完成这件事情。在 /usr/local/bin/ 里面做了一个名字为 d 的符号链接指向这个程序,在使用的时候只要在终端里输入 d 要查的单词 就好了。后来我还添加过一些功能,把查询过的单词都保存在一个文件中,可以在日后复习记忆。

今天从网上找 ERC 的资料的时候,看到了一个中国人的关于 Linux 等工具的网页,从里面转了转,看到了这篇文章,里面同样是用了海词,但是用的是我之前一直不知道的迷你版。

海词的迷你版的使用方式是 http://dict.cn/mini.php?q=单词,直接在浏览器中输入就可以,返回的是一个非常简单的释义界面,包含了例句等。那篇文章里是用的 w3m 来从终端访问的,我这里没安装 w3m,于是试验了 curl 也一样可以完成。迷你版的好处是结果就是最原始的释义、例句,没有任何花哨的、不实用的东西。直接把这一行命令写到脚本里去,就可以很方便的完成我之前那个程序的功能了。我那个 Perl 程序写了 25 行,我估计如果用迷你版的话,用不了 5 行就能完成了。

如果我们的网页是 PDF

在整个做网页的技术中,我唯一不在行的就是 CSS 了。严格来讲其它技术也不怎么在行,而我对于 CSS 则有种“畏惧”的心理,很长时间不敢动它。过去我同样有这种感觉的是 javascript,后来在今年暑假的学期中有一门课需要我们自己写 javascript 来做 AJAX 页面,那一阵子 firebug 和 Safari 的内建调试工具同时出动,虽然痛苦,也让我对 javascript 不那么恐惧了。而 CSS 则不然,我从头到尾一直都没有学过,因此虽然 CSS 不是一门很难的技术,我却一直感到恐惧。

今年初把 blog 程序转换到 Movable Type 中后,发觉所有的默认模板显式中文都很难看,用 Unstyled 这个没有任何 CSS 的模板后中文反倒更好看。之前用的 WordPress 的模板的 CSS 就写的不错,所以我一直都没考虑过这个问题。同样是今年暑假的某一天,我实在忍不了默认的恶心的字体设定,痛下决心,埋头研究了 Eric Raymond 的网页和蔡智浩的 Taiwan 2.0 部落格的 CSS 文件,把字体部分的设定挪到自己的 CSS 文件中来。当时为了弄明白 CSS 中每一部分对于页面的影响,我尝试了许多次,最终终于成功,整个 blog 顿时感觉清爽了许多。不过我对 CSS 的了解只限于那一部分,之后就再也没有动它。

这次我的 blog 更换地址后,我手动更新了新 blog 的 CSS,虽然学到了一些新的东西,但仍然感觉相当痛苦。而且做出的更改还是只限于正文,文章的标题的字体依旧还是很难看,很多字明显粗细不一,而且有一些特殊的字,比如“关”,看上去就明显比正常的字窄。有一部分我怀疑是 Mac 下的字体的原因,估计在 Windows 下可能会好一点,不过我没有查证。我试过几次,发现无论怎么改都还是那样,最终放弃。

这几天我还看了两篇讲述 CSS 字体设定的很好的文章。第一篇看到的是《再谈 Web 默认字体》。这篇文章开始时我匆匆浏览了一下,觉得非常不错,这天就一直在我的浏览器里开着。今天自习看了一下文章的留言,又找到了这一篇《默认Web字体样式》,看下来感觉更有帮助。他们页面的字体也很美观,不是我这个 MT4 站点可以比的。其实我觉得 WordPress 的很多模板的默认字体就已经很不错了,自己改改的意义也不是很大。可对于 MT4 站点来说,模板的字体就需要作者改动许多了,这两篇文章的意义也就大的多了。在 MT5 中的 Pico 风格对这一点有了很大的改善,但其它的一些之前就有的模板就还是有这个问题。

我这个学期的《密码学》这门课的笔记,我主要是用 ConTeXt 来记录的。其实不论是那个 TeX 分支,其基本的排版方式是相同的。也就是说,排出来的结果都是统一的。TeX 有个最大的特色,就是美观,生成的 PDF 的整个页面,无论中文还是英文,都显得落落大方。更厉害的是,做好了基础的配置后,这些几乎都是自动完成的,不用用户操心。所以我就想,因为网页的发布与普通的页面出版相当类似,所以如果我们的网页都是一个个 PDF 格式的页面,会不会让网页更美观呢?

结合这一观点,也和 Macintosh 系统有一定的关系。在 Mac 中,PDF 是基础的页面渲染格式之一,内嵌与系统之中。如果在 Safari 中点进去了一个指向 PDF 文件的链接,直接从 Safari 中就可以把文件显式出来。因为 PDF 是内建在系统之中的,所以显式的速度非常快。而且在 Mac 的基础打印功能中,它的预览功能其实就是把页面转换成 PDF,再从 Preview 里面显式的,生成的 PDF 文件还可以保存,这说明,PDF 文件格式已经被苹果接受作为其其本的页面渲染格式之一了。而现在的 PDF 文件中都可以内嵌链接、也支持 Form,所以就有了 HTML 的最基本的功能。更大的好处是,PDF 文件有点把整个文章当作画一样“画”出来,而描述这幅“画”的语言是通用的,这样在不同平台上就不用担心兼容问题了。坏处就是浏览的用户不能设定自己的格式,弹性方面打了折扣。

有一个网站基本就是这样子做的,就是 ConTeXt 的老家 ── PRAGMA-ADE。看看这个文件,它是一个所有示例的索引,从里面可以直接点击跳到不同的页面。我之前浏览这个网页的时候,也纳闷为什么好多说明文档他不用 HTML 来写,非要生成 PDF 的格式?但后来也觉得想通了:PRAGMA-ADE 就是一家推广排版的公司,自然要支持 PDF。

当然,PDF 文件做网页的缺陷也是很明显的。最主要的是文件的体积远大于普通的 HTML 文件,不利于网页传输。光是这一点就让近期实现变得不可能。将来网络更发达的时候,难保不会出现更先进的技术。所以,这一点也仅仅是我自己的幻想。不过说道 MT 的发布,其实与 TeX 文件的编译应该是有异曲同工之妙的。在后台写 TeX 格式的文件,让 MT 再编译成美观的网页,其实就是 MT 发布在做的事情,只是生成的结果不同罢了。

互联网应用的趋势

这篇文章是我之前的一篇文章《Web 2.0和熵》的延续和补充。

在那篇文章里,我说混乱是互联网的趋势,因为世界趋于混乱,人心也趋于混乱,混乱符合大众的要求,因此帮助人们制造混乱的工具会火。于是Facebook火了、Twitter火了,不止如此,他们的一众模仿者也都或多或少的火了。然而今天我突然意识到,这个观点只描述了事实的一半。世界趋于混乱是真的,但我们还是需要秩序的,只有两者在维持一定平衡的状态下,世界运转才正常。不止网络如此,这应该是普适的真理。

抛开宗教传说不谈,我感觉混乱始于秩序形成。自从人类进化成功,第一个状态就是蛮荒的原始人状态。那时候的人类更多的是遵守下一层次的秩序,也就是动物的秩序。人类混乱到一定程度后,秩序诞生,这就是母系社会的由来。相比之后的黄帝开启的时代,母系社会的秩序相对松散,因为如果没有秩序,母系社会的混乱度应该远不及黄帝的那个时代。后来人心渐渐复杂,混乱程度加深,于是出现了王法,由百姓对君主效忠的形式,维持了社会的秩序。如果没有秩序而一味追求混乱,我想人类也不能走到今天。

互联网就符合这个趋势,在上世纪90年代初期,万维网刚刚诞生,可以访问的网页屈指可数,人们没有想过需要一个工具,用户输入关键字后能返回包含关键字的网页。后来网页逐渐增多,记住所有网站成了不可能的任务,于是人们对于秩序的要求早就了斯坦福的两个年轻人──杨致远和David Filo。2000年之后,网络进入了高速发展期,Web2.0的诞生更导致了网络内容大爆炸,网络进一步陷入混乱之中。这时的雅虎已经无法完成对高速增长的网页进行索引的工作了,于是我们接受了Google。

因此我觉得,在将来,人么需要的互联网工具有两种:一是能帮助人们创造混乱的工具,另一种则是帮助人们从混乱中提取秩序的工具。

混乱是趋势,但混乱的信息对我们的帮助很小。我们喜欢不受限制的输出信息,也就是说,我们把输出的东西弄的越混乱越好,但我们只容易接受有秩序的信息。被秩序的总结起来的信息,不仅能被计算机正确处理,也能更容易的让人脑接受处理。因此Google在这几年发展迅速,正式由于网络的“混乱化”进程发展的非常迅速,给Google创造了更大的空间的缘故。

目前的情形,混乱还是占据了一些优势的。比方说Twitter,到今天为止,发布的每条消息,基本上就成了泼出去的水,再要找出来就困难了,更别说从中提取初什么有价值的信息了。Facebook之类的SNS服务也是如此。还有一个例子是微软的“大饼”,Google目前做了很多,但面对越来越混乱的信息,还有点力不从心的感觉,微软的“饼”标榜自己是个决策引擎,其实就是想在Google之上对混乱的信息进行进一步的整理与提取。

还有一点,对于制造混乱的工具,自然是越多越好;提取秩序的工具,我想在未来只需要一家就够了,这是混乱和秩序的定义决定了。制造混乱的工具多了,会让网络愈加混乱,而提取混乱的工具多了,本身就是一种混乱。比如先在对中国人来说的Google和Baidu,两者功能相近,两者结果的不同也给用户带来了一些困惑。

因此在将来,我们需要的是一系列制造混乱的工具,和一个最强的提取秩序的工具,我想这就是未来互联网应用的趋势。

Web 2.0 和熵

昨天从Google Reader上看到某人分享了一篇Solidot上的文章《大多数博客已放弃更新》,当时想想确实如此。我在2007年写过一篇文章,提到当时人们对blog并没有很大的热情。当时我希望在几年后这一情形会有所改善,结果没想到由于微博、Facebook之类的东西的逐渐强大,现在不光国内,国外的blogger也越来越少了。

当时有一种奇怪的感觉,一直想提炼出来写成一篇文章,一直到晚上躺到床上之后才和“熵”联系起来。我不是物理专业的,没有系统的学过“熵”有关的概念,不过也大体的了解作为热力学的单位之一的“熵”能度量“混乱程度”。因此“熵”在我的印象中就是来衡量“混乱程度的”。

之前听过一句话:“宇宙的自然趋势是越来越混乱的”。互联网的发展,现在想来,是相当符合这句话的。互联网的大规模兴盛始于万维网,也就是网页的增多。最早的网页都是些html代码,浏览器负责解释并渲染,信息的流动都是单向的,也是相对秩序的。后来Web 2.0的兴起,给了网络大众的用户改动网页的机会──页面有了交互系统。Blog相对于传统网页的优势之一就是读者也可以留言,这样也使得一个留言活跃的blog页面会相对于传统静态网页越来越“混乱”。混乱不是坏事。从某种角度上说,混乱是符合自然规律的,因为整个宇宙的大趋势就是混乱。所以blog自然而然的顺应人心,在前几年着实火了一把。

但这样似乎还不够,人们要求更低成本的制造混乱的方法,因此微博、SNS等系统就应运而生了。

从静态网页到微博一路看来,混乱的程度果然越来越高。静态网页一旦完成,信息就在那里,我们只要索引了就可以方便的找到信息;blog介于两者之间,正文部分很像静态网页,留言部分很像微博系统,因此我们在正文中找信息还算容易,在留言中找信息就要话很多功夫了;新一代动态系统则更为混乱,信息的搜索在目前的技术下很难实现。想想看,要从Twitter上找到2007年发布的一则tweet是多么的困难,从校内里面搜索之前看过的一篇文章,应该也相当麻烦,或者根本不可能。新一代动态页面有“即时”的特色,也就是说,我们关注的是近期发生的事情,过去了的就不再关心了,即使想关心都很难。

正因为“混乱”是自然、也是人类的天性,因此网络的潮流也朝着混乱发展。由此看来,blog的没落是必然的事情。如果有一天我们发明了更混乱的东西,今天流行的SNS也要被淘汰了。

从另一面说,在今天还在坚持写blog,甚至还在写静态页面的,基本上都算是“违反潮流”或“逆天”了吧。不过这也不是坏事,有个比较古老的关于修仙的观点是:修炼的过程其实就是逆天行事的过程。人类的“天命”就是出生、成长、衰老、死亡。而修炼让人返璞归真:胎息、先天呼吸什么的,就是人在出生前在母体中的呼吸方式。从一个人类修炼到子宫中去,可不是逆天么。逆天虽然艰苦,但确实修炼的大道。看到网络上,现在还在写blog的人,或者还在写静态网页的人,我觉得就有点违逆潮流,从混乱中提炼秩序,总结成文章。因此写一篇blog,比在Twitter、校内上扯几句淡容易多了。

结论怎么下,我也不知道。不过不管是混乱还是秩序,都是自然的。因此,我们不能让blog回复几年前的光景,也只好由他去了。不过也不需要对blog有所质疑,秩序比混乱要来得艰苦,但更有价值。如果能坚持写blog,哪怕更新频率为一年一篇,也相当有价值。