Mac中文输入法FIT开源

对中文输入法,一直没有什么特殊的要求.刚上网那阵,用Windows 3.1系统自带的拼音输入,在聊天室里也能行云流水,甚至从来in-ing不分的我,一度也强记了部分常用字的前后鼻音. 用mac后,被人诟病的中文输入法在我看来也凑合了,不过难免觉得这个确实是”不懂中文”的人做出来的.后来试过QIM,用着用着突然就收起费来,感觉好像没有那么迫切的需要,也就作罢. 然后就看到人推荐Fun Input Toy,试用之后,感觉虽然没有QIM那么强大的词库和智能,但相当稳定,不会突然就需要切换两次回到中文,与Firefox和TextMate配合的也相当好,又是免费,就一直用它了. 这两天看到FIT开放源码的消息.一个优秀的软件,在越来越被人接受的时候,没有选择收费而选择了开源,也算是一件相当有魄力的事情了.

如果麒麟真的抄袭BSD

刚刚看到随行记闻:未能发表的国产麒麟造假案,学术腐败真是到了无耻的地步。BSD版权协议可能是世界上最没什么要求的开放源码协议之一了,只要你发行时带上Berkley的名字,其它别无所求,闭源、买钱全由你。以至于Richard Stallman曾有很长一段时间不能接受这种“无原则”的开放而不承认它是一种自由软件协议。如果这样一种协议都不能遵守,除了无耻就没有别的词可以形容了。

国产Linux企业的问题到底出在哪里

最近国产Linux/操作系统又变成热点,“至今国际正式发布的Linux内核文件中,尚没有中国人开发的一行代码。”这句话刺激了不少对国产Linux曾经报过希望的人。 可国产Linux的问题就在于没有为中国人民在Linux内核里加入一行代码么?如果国内Linux企业真的往Linux核心里check in了几千行代码,就可以心安理得了么? 开源/自由软件的特点使得软件的开发和商品化可以由不同的组织来完成,不贡献代码也可以制作发行版。但另一方面,所有商业公司对开源/自由软件的参与支持都是和自己利益挂钩的。Intel公司为Linux开发驱动程序或者参与gcc的开发一定不会去为AMD芯片做优化。RedHat供养Linux开发核心人员是为了加强自己对Linux的控制。Google供养Firefox核心开发人员是为了它的互联网蓝图。一旦这些利益不存在了,这种关系就会解除。AOL当年为什么解散Netscape,HP为什么解雇Keith Packard,Sun为什么在德国的OpenOffice裁员(Update:Sun对OpenOffice部门的裁员主要在爱尔兰,谢谢Hercule的提醒),就是这个道理。当RedHat宣布不再把重点放在Linux桌面系统后,其下的Gtk/Gnome部门的工程师心里一定在打鼓。 那么对于我们的Linux企业,他们需要做些什么?当然,如果能往Linux核心或者重要模块中check in代码甚至成为module owner是再好不过的事情。但作为一个企业,在你还没有能力或者没有足够的reputation来check in代码的时候,最起码你应该能够做好Linux商业化的工作,你们找到了除了靠政府支持以外的商业模式了么?你们能够满足哪种客户的商业需求?针对这些需求,你们需要对你们的Linux发行版做怎样的修改?如果现在又一味地开始追求往Linux核心提交代码,我相信,对于这样一个单纯目标,我们中国人民一定很快就能完成(人家还没毕业的学生都能做到的事情我们有什么不能做到的?),但是这样就国内Linux企业的问题就得到解决了么?

仓廪实,知开源

从keso的blog上看到 中国软件协会发布了《有关开放源代码软件与商业软件知识产权的研究报告》,认为选择商业软件或者开源软件主要应该由市场来决定,由企业和用户根据自己的需要和各种因素决定,“偏爱”和“过度的倾向性支持”开源软件,由于不符合市场经济的规则,结果往往适得其反。倪光南发文回击,认为这个报告是针对开源的新的FUD,是阴谋。 上大学的时候和别人一起推崇非主流音乐,独立制片,工作后参与了三年的开放源码社区。其实很多东西都一样,没有主流音乐就没有非主流音乐,没有好莱务大片就没有独立制片,没有商业软件,开放源码也是掰扯。 过分的强调开源软件实际上就是在软件业里玩意识形态。如果没有健康的商业软件市场,开放源码就不可能良性发展。我亲眼见过一个国内开源软件的评比是如何迫使各厂家将他们的代码深深的隐藏起来。国内这么多打着开源旗号做着闭源软件的公司,怪不得他们,怪就怪我们根本没有良好的商业软件市场。但如果还要继续做违背市场规律的事情,就是把开源软件送入坟墓,是真正的FUD。 在中国,需要扶植开源软件的地方是学校,要鼓励学生参与开源软件社区,在那里他们能够得到最好的锻炼。软件行业里,还是让市场经济说话好了。真要是为了中国软件行业好,还是多写点代码,少谈点主义。

GORM – desktop开发的新选择

GORM 1.0的发布在slashdot引起了不小的争论,原因是发布信息的人给出了这样的评论 with its release, comes the obsolesence of the GNOME and KDE projects 这让一些GNOME和KDE的爱好者很是不忿. 我不敢预言GNUStep的前途会如何,但不管怎么说,他们至少选对了语言. 如果你学了C++,刚好又读了Inside C++ Object Model之类的书,那么GNOME环境下的glib和gtk可能会让你兴奋一阵子.完全用C语言来完成的面向对象编程,可以给你一种low level的快感.继承,多态,RTTI,每一个被其他面向对象编程语言所隐藏的特性都不过是语法糖衣,每一个实现细节都摆在你的眼前.也许你很快就能习惯这种方式,就像很多GNOME社区的geek们一样,对他们来说,用C来OOP没什么,家常便饭.但这并不能掩盖C语言在OOP编程中的弱势.你的类需要使用大量的宏来维护继承关系和动态绑定,你用gdb中断你的程序时会发现50%的call stack都被查找一个消息的传递对象消耗了,你必须把函数名取得老长,就像这样– gtk_entry_completion_set_popup_single_match,因为mangling全靠自己.这种方式很难再保持C语言的高效,同时又增加了程序的复杂度,更给每一个想进入社区参与开发的人设置了一道不低的门槛. 而对于桌面应用,object-c显然更加胜任.在面向对象的一些特性上,它比C++甚至Java都来得更彻底.一些在C++里一些必须通过复杂多重继承来实现的模式,用object-c水到渠成.这里有一篇文章解释了为什么GORM无法用C++来完成. “use the right tool for the job”.我不能说GNOME错或者对,不过每当我想到我再不用做gtk编程了,都会发自内心的长舒一口气.