林健的BLOG

　　海淀区著名水果粉 @heqian 据称是中国大陆第一个拿到 iPad 的用户（昨晚到京，今天中午到手）。据称而已，没有证据。但他即使不是第一个也是前十个，不是前十个也是前一百个，不是前一百个也是……今晚他特地来到中科院计算所，为广大革命群众展示资产阶级的享乐主义工具。广大革命群众纷纷表示△○□×……闲话少说，有图有真相——

→→→ 更多真机图点击这里 ←←←

　　有没有发现屏幕反光很厉害？其实这是因为 @heqian 爱护 iPad，还没有去除它的保护膜。在展示结束之后，@heqian 毅然决定对 iPad 去膜化，下面的无码视频记录了去膜的全过程，敬请观看——

　　我的新浪播客上有更多相关视频。也可在 YouTube 观看。

　　上午没有上网，中午和同学吃饭时得知，王江民先生昨天不幸病逝了。
　　我是 DOS 时代江民 KV 系列杀毒软件的老用户。我与王江民先生也算半个老乡，因为我们祖籍都在山东烟台，只不过我们都不是在烟台出生长大的。上个世纪末，王江民这个名字和诸多出现在各种国产软件界面上的中国软件先驱的名字一样，令我对背后的那个英雄级人物倍感崇拜。后来虽然不再使用江民的产品，但到了北京，发现江民公司所在的数码大厦居然离我们学校很近。于是趁同学找工作的机会，我也去江民公司参观过一回，印象深刻的是一只大“凯威”。
　　现在我手头还保存着 KV200 和 KV300+ 的软盘，放出来给大家看看吧。实验室的老机器有软驱，试试这张 KV200，居然还可以读出来。而下面的 KV300 和 KV300+ 则是虚拟机中的截图。




　　王江民先生因为一件事而引发过争议，这就是 1997 年轰动一时的“KV300L++ 逻辑锁”事件。我手头保存了他人整理的一些当年的网络评论和技术分析，有兴趣的朋友可以下载下来看看。王江民先生的所为有其时代局限性，但中国软件行业发展这二十多年来，又有多少这样或那样的锁，甚至是披着糖衣的锁层出不穷呢？
　　无论如何，王江民先生仍然是一个时代的传奇英雄。向前辈致敬！

　　受 @Sisyphusliu 师兄的启发，我最近决定试用 Amazon S3 来做个人数据同步与备份。初步计算发现这很可能比之前使用 VPS 或 Web 主机的方案要节约成本。我对三款面向 Amazon S3 的开源文件同步工具进行了对比，将其中部分细节说明如下，供有相同需求的朋友参考。
　　这三款工具分别是 jets3t、s3cmd 和 s3sync.rb。其主要特性和附加功能这里不再赘述，它们的官方主页都有详细说明。软件的稳定性还有待长时间使用的考验，但从网上没有发现用户反映太大的问题。我在这里强调它们存储文件元信息的差别，以及由此可能引发的问题。

　　由于 S3 基于 Key-Object 存储方式，与树型文件系统不同，因此如何将树型结构组织的文件及其元信息存储在 S3 中就是一个问题。这三款工具都将文件的全路径作为 Key，并把文件的元信息保存在 Object 的自定义属性中。
　　这样有什么后果呢？首先看目录。稍稍想想就会发现，像“a/b/c”这样的 Key 无法直接判定“c”是一个目录还是一个文件。s3cmd 的处理最简单，它的任何一个 Object 都是文件，不把目录作为 Object 保存。这样消除了歧义，但导致了目录的元信息无从保留，同时也无法保存空目录。而 jets3t 和 s3sync.rb 会保存目录的 Object，并通过元信息中的 Content-Type 来区别文件与目录。这样就保留了目录元信息，也允许空目录存在，但这影响了工具之间的互操作性。下载另一个工具上传的文件时，工具彼此不认识对方的目录 Object，就会将它们保存成普通文件，从而造成同名的目录无法创建。
　　再来看看文件的元信息。s3cmd 保存的 s3cmd-attrs 属性是一个包含了 uid、gid、uname、gname、mtime、atime、ctime 等信息的字符串，因此它保留了最完整的文件元信息。jets3t 只保存文件修改时间，无从得知属主与权限，不适合保存可执行程序的目录；s3sync.rb 只保存属主与权限，而且是数字 id 而非名字，在新系统中恢复数据时可能出现映射错误。
　　我个人倾向于选择 s3cmd。其一，文件修改时间和权限对于个人程序、文档来说是比较重要的信息。当然这不是技术问题，修改 jets3t 和 s3sync.rb 肯定也能做到。其二，不使用自定义的目录 Object 就允许一定程度的互操作，例如使用 jets3t 和 s3sync.rb 可以直接下载 s3cmd 上传的文件与目录结构（元信息丢失）。而 s3cmd 设计造成的目录元信息缺失、空目录消失等问题，对一般应用和文档来说不太重要、相对容易恢复。当然也可以使用额外的机制来记录目录元信息，但考虑 KISS 原则，s3cmd 目前的设计还是有道理的。要想同时解决元信息与目录问题，容易想到的办法是将目录打包或压缩再上传，这比较适于长周期的文件归档备份场景，但对于细粒度、短周期的日常数据同步场景并不适合。
　　至于云存储的信任问题，在现阶段我也只能选择折衷。一方面不要将鸡蛋放在一个篮子里，重要数据还是需要异地备份的。另一方面可以使用这些同步工具自带的安全机制，或自己稍加封装实现数据加密。
　　最后提醒大家，务必看看 Joel 的备份观。

　　今天有朋友向我询问在 SCIM 的五笔输入法下如何输入各种特殊符号。我们知道，SCIM 五笔所在的 scim-tables-zh 输入引擎功能并不强大，没有 Windows 下常见的软键盘等辅助功能。SCIM 五笔中也只对少数符号设置了编码，如“●”是编码是“pnll”（“实心圆圈”四字的编码），无法输入多数特殊符号。不过作为开源软件，SCIM 的码表扩展还是比较方便的。恰好我以前也被相同的问题困扰过，当时通过扩展编码的方式将区位码表加入了 SCIM 五笔码表。既然有人需要，那就把我修改过的码表略加完善，提供给需要的朋友使用。

　　从这里下载带有特殊符号的 SCIM 五笔码表：
　　http://files.linjian.org/c_cpp/Wubi-quwei.tar.gz 或
　　http://www.linjian.cn/files/c_cpp/Wubi-quwei.tar.gz

　　如果懒得研究，则直接用解压后的 Wubi.bin 替换系统原有的 /usr/share/scim/tables/Wubi.bin。重新加载 SCIM 之后，可用以下编码输入区位码表中的特殊符号：

　　第1区 符号 xxxf（“符”）
　　第2区 数字 xxxs（“数”）
　　第3区 英文字母 xxxy（“英”）
　　第4区 日文平假名 xxxp（“平”）
　　第5区 日文片假名 xxxq（与“p”相反的字母“q”）
　　第6区 希腊字母 xxxl（“腊”）
　　第7区 俄文字母 xxxe（“俄”）
　　第8区 拼音注音 xxxi（“音”的韵首）
　　第9区 制表符号 xxxb（“表”）
　　GBK扩展符号A8区 xxxu（代表符号“╙”、“〒”）
　　GBK扩展符号A9区 xxxo（代表符号“㊣”、“〇”）

　　这里没有像 Windows 下的很多五笔输入法那样用“z”作为特殊编码的首字母，目的是为了保留“z”的万能查询功能。scim-tables-zh 并不能做更高级的定制，使“z”在不同场合下发挥不同作用。我选择使用“xxx”开头的几个空的编码位置容纳特殊符号，并尽量保证编码的名称有易于记忆的含义。
　　如果想改变为其它编码方式，可以修改上面包中提供的 mkquwei.c 文件，并参考以下方式重新生成 Wubi.bin：

　　今天偶然看到，沉寂了五年多的 CCED 居然在上个月 18 日发新版本了。新版本为“CCED2000 发行版⑥号”，网页介绍称该版本是“应广大用户要求”，解决了前一版本在宽屏显示器上的一些问题。而 CCED 的前一个版本是 2004 年底发布的，其网站在五年间也没有任何更新。
　　这一事件首先打破了我对 CCED 及其网站已成为 abandonware、abandonweb 的定性。难以理解朱崇君先生在这五年多来对 CCED 的发展是怎样一个想法。
　　今天既然是 Pi day，我自然会有一些数学思维。有关新版 CCED 的重要发现不在于功能改进，而在这里——

　　看看我手头的这些 CCED2000 历史版本（注册版①、④、⑧；发行版①、③、⑤、⑥；Win95 附加包）安装界面中的发布日期，除了一个例外，其余均是在某月的 8 日或 18 日。看来朱崇君先生对“8”情有独钟呀。再回想起 DOS 版的 CCED，5.03 版之后紧接着就是 5.18 版，证据更加确凿。等等，不是说还有一个例外吗？这是 2000 年 5 月 1 日发布的注册版⑧号，连起来照样是“5-1-8”呀！朱崇君先生在这方面真是下了不少心思。
　　如果哪位朋友手头还有 CCED2000 的其它版本（包括 CCED98 试用版），请看看发布日期是否同样以“8”结尾。同时希望这些朋友能把我上面没有列出的版本发给我，仅供收藏。
　　希望这个发现不是火星，呵呵。