我印象中的江民

2010/04/05 | 20:14 | 分类:IT杂谈 | 标签: | 752次阅读

  上午没有上网,中午和同学吃饭时得知,王江民先生昨天不幸病逝了。
  我是 DOS 时代江民 KV 系列杀毒软件的老用户。我与王江民先生也算半个老乡,因为我们祖籍都在山东烟台,只不过我们都不是在烟台出生长大的。上个世纪末,王江民这个名字和诸多出现在各种国产软件界面上的中国软件先驱的名字一样,令我对背后的那个英雄级人物倍感崇拜。后来虽然不再使用江民的产品,但到了北京,发现江民公司所在的数码大厦居然离我们学校很近。于是趁同学找工作的机会,我也去江民公司参观过一回,印象深刻的是一只大“凯威”。
  现在我手头还保存着 KV200 和 KV300+ 的软盘,放出来给大家看看吧。实验室的老机器有软驱,试试这张 KV200,居然还可以读出来。而下面的 KV300 和 KV300+ 则是虚拟机中的截图。
我印象中的江民
我印象中的江民
我印象中的江民
我印象中的江民
  王江民先生因为一件事而引发过争议,这就是 1997 年轰动一时的“KV300L++ 逻辑锁”事件。我手头保存了他人整理的一些当年的网络评论和技术分析,有兴趣的朋友可以下载下来看看。王江民先生的所为有其时代局限性,但中国软件行业发展这二十多年来,又有多少这样或那样的锁,甚至是披着糖衣的锁层出不穷呢?
  无论如何,王江民先生仍然是一个时代的传奇英雄。向前辈致敬!

三款面向 Amazon S3 的开源文件同步工具之对比

2010/03/28 | 00:02 | 分类:Linux与开源 | 标签: | 794次阅读

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

  jets3t s3cmd s3sync.rb
打包大小 12M 50k 30k
开发语言 Java Python Ruby
官方主页 http://bitbucket.org/jmurty/jets3t/ http://s3tools.org/ http://s3sync.net/
最后更新 2010-3 2009-10 2008-6
功能定位 综合工具集+文件管理GUI 命令行工具集 命令行工具集
文件元信息 Content-Type
jets3t-original-file-date-iso8601
md5-hash
Content-Type
s3cmd-attrs
Content-Type
group
owner
permissions
目录元信息 Content-Type
jets3t-original-file-date-iso8601
Content-Type
group
owner
permissions

  由于 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 的备份观

CCED2000 发行版⑥惊现江湖,发布日期暗藏玄机

2010/03/14 | 23:55 | 分类:IT杂谈 | 标签: | 1,522次阅读

  今天偶然看到,沉寂了五年多的 CCED 居然在上个月 18 日发新版本了。新版本为“CCED2000 发行版⑥号”,网页介绍称该版本是“应广大用户要求”,解决了前一版本在宽屏显示器上的一些问题。而 CCED 的前一个版本是 2004 年底发布的,其网站在五年间也没有任何更新。
  这一事件首先打破了我对 CCED 及其网站已成为 abandonwareabandonweb 的定性。难以理解朱崇君先生在这五年多来对 CCED 的发展是怎样一个想法。
  今天既然是 Pi day,我自然会有一些数学思维。有关新版 CCED 的重要发现不在于功能改进,而在这里——
CCED2000 发行版⑥惊现江湖,发布日期暗藏玄机
  看看我手头的这些 CCED2000 历史版本(注册版①、④、⑧;发行版①、③、⑤、⑥;Win95 附加包)安装界面中的发布日期,除了一个例外,其余均是在某月的 8 日或 18 日。看来朱崇君先生对“8”情有独钟呀。再回想起 DOS 版的 CCED,5.03 版之后紧接着就是 5.18 版,证据更加确凿。等等,不是说还有一个例外吗?这是 2000 年 5 月 1 日发布的注册版⑧号,连起来照样是“5-1-8”呀!朱崇君先生在这方面真是下了不少心思。
  如果哪位朋友手头还有 CCED2000 的其它版本(包括 CCED98 试用版),请看看发布日期是否同样以“8”结尾。同时希望这些朋友能把我上面没有列出的版本发给我,仅供收藏。
  希望这个发现不是火星,呵呵。


Update 2010-3-20:已验证“CCED2000 注册版⑥圣诞号”发布日期为 1999-9-8,符合规律。但是,这个版本为什么叫“圣诞号”呢?

消除 koomail 的“余孽”

2009/08/27 | 22:55 | 分类:Windows应用 | 标签: | 737次阅读

  koomail 曾是一个简洁小巧的 Windows 邮件客户端,是抵制 Foxmail 的良好选择,我使用它大约有两年了。但自从某个版本开始,koomail 界面变得花哨,不断增加一些华而不实的功能,还在主界面弄出了“山寨酷友”之类的 SNS 广告。相反地,我发现并上报的一些 bugs(涉及远程邮箱管理、RSS 阅读等)它却迟迟没有修复;我在其论坛提出的一些建议(诸如回复邮件时给原文前加上“>”这样的基本功能)也没有得到过作者的重视。于是,今天决定抛弃 koomail,在 Wikipedia 上另找一些优秀的邮件客户端。
  在研究这些客户端的过程中,发现老外们整出来的 mboxMaildirMH 等一系列邮件存储格式还是比较有用的。使用这些规范的格式毕竟有助于软件更替和数据移植,因此格式支持成为我考虑的重要因素。在将 koomail 的邮件导入其它客户端时,我发现部分邮件会被报告 MIME 错误,或者只能看到邮件头而看不到正文。经查这是因为 koomail 保存邮件时,将 SMTP(RFC 2821)中表示通信结束的“.”也存入了邮件文件,还在后面追加了一行不知做什么用的“k[0x01]m”。而 mbox 等格式规定文件只需存储 RFC 2822 消息本身。明白了原因,就可以写一个 bash 脚本来处理所有的邮件,消除 koomail 留下的两行“余孽”,让其它客户端可以正常读取:

  1. #!/bin/bash
  2.  
  3. for file in *; do
  4.     echo "$file"
  5.     sed -i 's/^k\x01m\x0d$/\x0d/g' "$file"
  6.     sed -i 's/^\.\x0d$/\x0d/g' "$file"
  7. done

  这时使用 Claws-Mail 客户端读入邮件(因为它和 koomail 一样,每封邮件是一个独立的文件),导出为 mbox 之后再在 Thunderbird 等其它客户端中阅读也是正常的。

软件功能行为的“中国特色”

2009/07/03 | 21:02 | 分类:IT杂谈 | 标签: | 1,117次阅读

  当我把 Firefox 升级到 3.5 版以后,发现一个问题:Tab Mix Plus 插件被报告不兼容。我原先为什么要安装这个插件呢?其实我想使用的只是其中一个功能:双击关闭标签页,我并没有使用 Tab Mix Plus 的其它高级功能。双击关闭标签页,这是我以前使用 Maxthon 的习惯,所以为方便起见我在 Firefox 中也通过插件实现了这个功能。不过随着对 Chrome 使用的增多,我也习惯通过快捷键或者点击标签右边的“×”来关闭标签页了。有关标签页,有一个细节不知道大家有没有注意过:IE 7/8、Firefox、Safari、Chrome、Opera 这几个国外主流的浏览器默认都是不支持双击关闭的;而国产的 Maxthon、搜狗浏览器、世界之窗、GreenBrowser 以及某三流公司的 TT 浏览器却都默认支持双击关闭。“双击关闭标签页”似乎是一个中国特色的功能。
  这两天又在 twitter 上看到 Fenng云风等人有关 IM“群”问题的讨论。这个“群”似乎也是一个中国特色的东西。从低俗至极的 QQ,到新浪 UC、百度 Hi、网易泡泡,甚至以辅助交易为主要功能的淘宝旺旺,都把“群”作为标配功能,好像比别人少个什么功能就会低人一等似的。而看看国外的 IM 们,它们多数都没有像国产 IM 那样的固定群组。老牌的 ICQ、AIM 不支持多人会话,只能通过 Miranda IM 等工具建立临时多人会话;Yahoo! Messenger、Jabber(包括 web 版的 Gtalk)原生支持临时多人会话,但没有固定群组;唯独 MSN(Windows Live Messenger)在支持临时多人会话的同时,也于今年推出了固定的“群”业务。像赢思之类的公司很早就看到了 MSN 在中国市场的这一空缺,率先推出了“小 i 群”那种基于机器人的第三方群组服务,这家公司对 MSN 的本土化也算是有点贡献吧。当然外国人也不笨,在多人交流方面,IRC 就有相当的用户群,ICQ 也有类似 Google Groups 的服务,只不过它们没有像中国 IM 的“群”那样扎堆。
  不仅软件如此,网站也没有摆脱中国特色的一窝蜂。这两年 SNS 火起来了,不要说各大门户,只要是原来有个社区、论坛什么的,统统要弄个 SNS 上线,反正已经有现成产品可以用。而且像什么农场、车位之类的网页游戏也是清一色的,大有让“偷菜”成为吸引流量的必要工具之势。刚刚还说小 i 呢,它不知什么时候把自己的主页都变成 SNS 了,这算不算不务正业呀?
  这些中国特色的软件功能和行为是缘何而生呢?我不敢去扯什么民族的性格,因为我压根不懂这个。但我相信云风和 keso 的观点:产品部门的人不要太听信用户的。很多情况下,所谓的“用户”只不过是他们自己意念中构造出来的形象,用户的需求是对既有市场的重述,而不是对潜在需求的反映。产品部门可以声称用归一化的功能满足大众用户就能够迅速占领市场,进而用自己的特色服务来创造价值。但革命性的市场往往是由小众用户的需求引发的,一味地模仿、追求“人有我也有”,只能在同质化的过程中丧失创新的勇气,创造一个又一个没有实质进步的中国特色软件基因。

页面存档: 上页 1 2 下页