日志分类:Linux与开源

解决 Eclipse SVN 插件(Subversive)内存不足的问题

2010/08/21 | 13:55 | 分类:Linux与开源 | 标签: | 163次阅读

  最近的一个项目有点夸张,SVN 上的源代码量超过 1G(事实上是出于种种原因,将很多第三方 jar 之类提交到了 SVN 上)。项目初创到不断壮大的过程中,持续参与的开发人员并没有发现什么问题。但后期新加入的开发人员则发现使用 Eclipse SVN 插件(Subversive)无法完成从无到有的 Check out 操作,Eclipse 总是出现 Java heap space 错误。这很可能是由于 Subversive 实现的问题,在处理庞大的代码库时将堆内存耗尽。根据经验,我们可以修改 eclipse.ini 中的 Java 内存限制,但部分开发人员发现在自己的机器上即使修改到极限,Subversive 仍会报错。于是只能另想办法。
  经测试,在命令行下使用 svn co 是可以正常 Check out 该项目的。但如果把 Check out 出来的项目 Import 到 Eclipse 中,则会发现其缺少 SVN 的相关属性,看不到 Subversive 的上下文菜单。经查,项目的属性并不在项目目录中,而保存在 [WORKSPACE]/.metadata/.plugins/org.eclipse.core.resources/.projects/[PROJECT]/.indexes/properties.index 文件中,这个文件是文本与二进制夹杂的,不便理解与编辑,因此不太容易通过它来添加 SVN 属性。
  最后,我们找到了以下可行的操作路径:
  1、在 Eclipse 中 Check out 项目,Check Out As 对话框的 Depth 选项选择 Only a folder,目标目录为假设 A,完成后关闭 Eclipse;
  2、使用 svn co 命令把项目 Check out 到另一个目录,假设为 B;
  3、把 A 改名为 C;把 B 改名为 A;把 C 中的 .project 复制到 B(因为 .project 通常在 SVN 的 ignore 列表中)。
  4、打开 Eclipse,刷新 A 项目目录。
  这时,带有 SVN 属性的项目就完整地出现在 Eclipse 中了。
  我不是专业 Java 开发人员或专业 Eclipse 用户,因此并不知有没有更好的解决方案。但这也从一个侧面反映了代码管理中存在的问题。另外,负载规模的增长导致 Subversive 内存耗尽,也反映出 Subversive 实现的不周。有兴趣的朋友不妨去帮 Subversive 修正这个 bug。

将海峰五笔码表转换到 iBus 下使用

2010/05/13 | 23:09 | 分类:Linux与开源 | 标签: | 683次阅读

  Ubuntu 早已使用 iBus 取代 SCIM 作为默认的输入平台了。但我一直还在用 SCIM,原因就是 iBus 的五笔码表实在有些问题:生僻字或繁体字常常排在常用的简体字前面。它默认会自动调节词频,虽说调节词频是解决上述问题的办法,但这与很多五笔用户的习惯不符。不过其实 SCIM 也有几处用得不爽,例如不方便输入书名号、破折号等。
  我今天简单研究了一下 iBus,发现自动调节词频是可以关闭的(在码表中,而不在界面或配置文件中);而它的标点符号输入也相对自然。因此,决定找一套好用的码表替代原有码表,进而尝试用 iBus 取代 SCIM。我选择了 Windows 下的海峰五笔(86版)码表:其一,它的词库规模适中,我在 Windows 下用过感觉不错;其二,它使用标准的 Windows 码表格式,便于提取数据;其三,作者在主页上宣布“鼓励大家反编译,定制自己的专用输入法”,这种开放的态度让我选择了它。
  将海峰五笔码表转换到 iBus 下,步骤如下:
  1.在 Windows 下使用海峰五笔自带的 ImegenU.exe 工具将编译过的 Sun86.mb 码表逆转换为文本码表 Sun86.txt。不要用 Windows 自带的 Imegen.exe,在实验时发现 Imegen.exe 会产生部分错误的编码,比如“跑”字,暂不知其中原因。
  2.将基于 UTF16LE.DOS.BOM 编码的 Sun86.txt 转换为 UTF8.UNIX.NON-BOM 编码,命名为 Sun86-u.txt。在 Linux 下可使用以下命令:

  1. iconv --from-code=utf16 --to-code=utf8 --output=Sun86-u.txt Sun86.txt
  2. fromdos Sun86-u.txt

  3.编辑 Sun86-u.txt,删除头信息,只保留码表。
  4.编写一个小程序(trans),将 Windows 文本码表转换为 iBus 文本码表,命名为 Sun86-i.txt。

  1. ./trans Sun86-u.txt > Sun86-i.txt

  5.下载 iBus 码表源代码(ibus-table-xingyin),从中提取出原版五笔的文本码表 wubi.txt。
  6.使用 Sun86-i.txt 中的内容覆盖 wubi.txt 的 Table 段。可保留 wubi.txt 中以 zz 开头的一系列非汉字符号的编码定义。
  7.修改 wubi.txt,禁用词频调整:

  1. DYNAMIC_ADJUST = FALSE

  8.编译并覆盖码表:

  1. bus-table-createdb -s wubi86.txt
  2. sudo cp wubi86.db /usr/share/ibus-table/tables

  9.重新登录桌面环境,新的码表即可生效。

  另外,在使用中发现 iBus 默认没有启用无重码自动上屏的选项。Google 了一下,可参考这篇的方法。直接修改 /usr/share/ibus-table/engine/table.py,找到:

  1. self._auto_commit = self.db.get_ime_property('auto_commit').lower() == u'true'

修改为:

  1. self._auto_commit = False

然后使用以下 python 程序:

  1. import py_compile
  2. py_compile.compile(r'table.py')

将其 table.py 编译为字节码文件 table.pyc 即可。

  编译好的海峰五笔(86版)for iBus 码表以及上面提到的 trans 程序源代码可在以下位置下载:
  http://files.linjian.org/c_cpp/SunWB-iBus.tar.gz
  http://www.linjian.cn/files/c_cpp/SunWB-iBus.tar.gz

三款面向 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 的备份观

带有特殊符号的 SCIM 五笔码表

2010/03/17 | 22:23 | 分类:Linux与开源 | 标签: | 640次阅读

  今天有朋友向我询问在 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:

  1. gcc mkquwei.c -o mkquwei
  2. ./mkquwei > quwei.txt
  3. iconv -f=gbk -t=utf8 -c -o quwei-u.txt quwei.txt
  4. grep -v -P '\t\t' quwei-u.txt > quwei-f.txt
  5.  
  6. scim-make-table /usr/share/scim/tables/Wubi.bin -o Wubi.txt
  7. sed -i '$d' Wubi.txt
  8. cat quwei-f.txt >> Wubi.txt
  9. echo 'END_TABLE' >> Wubi.txt
  10. scim-make-table Wubi.txt -b -o Wubi.bin
  11. sudo cp Wubi.bin /usr/share/scim/tables/Wubi.bin

还记得这些老 Linux 发行版吗?

2010/02/11 | 18:37 | 分类:Linux与开源 | 标签: | 1,321次阅读

  回家秀收藏。

还记得这些老 Linux 发行版吗?
  Turbo Linux 可谓让 Linux 走进中国的功臣之一。Turbolinux 公司较早地致力于 Linux 的国际化,并推出了包括简繁体中文在内的多种语言发行版。早期的中文 Linux 教程,无论大陆版还是港台版,几乎是言必称 Turbo。作为一家老牌国际公司,Turbolinux 至今仍在维护其发行版(目前最新版本为兼容 RHEL 5.4 的 GreatTurbo Enterprise Server 11.3),其在中国的部门则偏重于行业应用与教育培训,而桌面市场风光不再。无论如何,Turbolinux 公司相比诸多乘 Linux 之风而起的公司来说,其转型是平稳而成功的。

还记得这些老 Linux 发行版吗?
  蓝点 Linux(BluePoint Linux)曾是几个年轻的创业者打造的中文 Linux 传奇。上个世纪末,它凭借着“内核中文化”的理念,与 Turbo Linux 在中文市场一决高下,曾一度拿下大量国产品牌机的 OEM 订单。可惜蓝点的中文化方案最终没有与标准的 i18n 走到一起,创新的思路反而成了技术骂战的导火索。在历经了一系列技术与市场的变故之后,这个曾在 NASDAQ 上市的小公司先是放弃了 Linux 转做嵌入式,继而光环褪去,从人们的视野中逐渐消失。纪念蓝点,纪念那些执着的技术开拓者们。

还记得这些老 Linux 发行版吗?
  国内涉水 Linux 发行版的大型通用 IT 厂商中,最有名的当数联想了。2000 年,原联想软件事业部一度推出了幸福 Linux(Happy Linux)家用版、服务器版、嵌入式版全线产品,并在自己的部分 PC 产品中预装,以平衡品牌机操作系统的成本与版权。其重要特色之一是将其在 Windows 平台的代表作——“幸福之家”移植到了 Linux 平台。然而已经广泛接受盗版 Windows 的消费市场并不买联想的账,这个幸福 Linux 连同 Linux 版的幸福之家,很快便为 Windows XP 的登台让了路。

还记得这些老 Linux 发行版吗?
  世纪之交,国家开始重视国产核心软件的研发,一系列项目基金投向了基于开源代码的操作系统。这的确催生了红旗等几个掌握某些领域核心技术、推出了市场认可产品的 *NIX 厂商。而更多的厂商,如中标普华,则依赖于政府和相关行业的订单。还有一些发行版则是昙花一现,比如共创 Linux。在这种大环境下也难免出现少数涉嫌抄袭造假的尴尬案例。国产 *NIX 发行版最终谁主沉浮?技术因素(特别是中文化)早已不是核心问题,大众消费市场的神话也不复存在。这些挂靠国家科研项目发行版,恐怕比拼的是在中国特色软件环境下的做事能力了。

还记得这些老 Linux 发行版吗?
  其实当年想借 Linux 发家的不只是这些背景各异的厂商,一些盗版者也动起了 Linux 的脑筋。尽管开源且免费,但对于那个时期的国内互联网,速度和费用的劣势还是让盗版光盘抢占了自由软件发行渠道的一席之地。看看手头这张《PC 软件全接触——Linux 工具集》,涵盖了多少你似曾相识的软件呢?

  历史,就是在这样大浪淘沙。


  补遗(2010-2-25):

还记得这些老 Linux 发行版吗?
  今天幸运地淘到了这款号称是“首套中文 Linux 操作系统”的 Xteam Linux 1.0(中文名为“冲浪平台”)。成立于 1998 年的冲浪平台公司可以说是国内第一家专业 Linux 开发商,其名称显然来源于互联网刚刚进入中国时所流行的“网上冲浪”的说法。Xteam Linux 早已无人问津,不过转型之后的冲浪平台公司目前作为某香港上市企业的子公司,至今仍然存在。这好歹让 Xteam 的名字成为了“先驱”而非“先烈”的代名词。

页面存档: 上页 1 2 3 4 5 下页