Web

和菜头说的太对了!

今天(2023 年 6 月 28 日)晚上看到这篇和菜头的文章《重开博客》,实话说还是挺吃惊的。确切的说是看到和菜头的博客竟然还在,让我很吃惊。我原本以为像他那一批人,已经过了写博客的阶段了,比如李笑来、罗永浩、洪波他们。

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

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

Chrome 浏览器发出的警告

Chrome 浏览器发出的警告

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

不良脚本的内容截图

不良脚本的内容截图

这个文件很老旧了,早在我还在用 Dreamhost 共享空间的时候就已经存在了。中间我的帐号也被黑过,因此有些文件被加了木马也是有可能的。这次这个脚本是用 JavaScript 写的,放在了 的后面,用 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 有非常明显的不同,相当不错。

终于开始使用 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 模式下给跑起来了。

本地的才最可靠

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

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

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

起因是因为我发现一些网页已经消失了。本来我想的是这些信息随时都可以从网上找到,因此我一般就在 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 来静态保存有价值的网页的这几年中,发生很多次他保存过的网页失效的情况,结果因为他把这些网页都保存了下来,他从来不怕这些网页失效。我听了不由的想,如果我几年前开始保存的不是网页的链接,而是网页本身,会不会就不会发生我今天这种保留了网址而网页却失效的尴尬事了。

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 这种信息量,因为两者之间是非常相似的。

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

前几个星期,我因为 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,页面会被重新载入。

海词迷你版

过去我经常在海词查单词。海词的内容挺不错,但是界面有些过于花哨了,看上去也很困难。我于是就想在终端里用一个简单的工具来从页面里提取我需要的单词释义,于是就写了一个 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 风格对这一点有了很大的改善,但其它的一些之前就有的模板就还是有这个问题。

互联网应用的趋势

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

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

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

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

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

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

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

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

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