Monthly Archives: July 2010

又是一些胡思乱想

1、胡思乱想是个健康的运动,可以放松心情,活跃脑神经。 2、读多、看多或者听多了故事的时候,更加容易胡思乱想。 3、有一天忽然想到一个问题:为什么人们都喜欢听故事?无论是现实的还是虚幻的。 我想我知道这个问题的答案。 4、每个人从出生开始,就不停地质疑自己存在的意义,怀疑自己的存在是否虚幻。 我们既害怕与其他人一样,却又更加害怕这个“自己”并非真实。 所以,我们总是时刻想知道:别人在想什么? 值得欣慰的是,我们在各种现实和虚幻的故事中,看到了自己的影子,看到了我们自己与其他人的某种通性。 所以,故事让我们获得了被认同感,一种“自己也是真实存在着”的证明。 5、可惜,这种证明也仅仅是一种感觉。因为我们从来只能借由五六七八感来见证自己与外物,因此我们永远也无法查明“存在感”与“真实存在”到底是不是一回事。 6、说到生存的意义,相信每个人小时候都问过,而我也已经想不起来我的老妈老爸是怎么回答我的了。 大概是:“你长大了就知道了”? 7、小学的我曾经在一个怪圈中深陷许久。这是一个名叫“那又怎么样”的怪圈。 如果地球毁灭了,那又怎么样? 就算太阳系毁灭了,那又怎么样? 哪怕整个宇宙毁灭了,那又怎么样? 从因果律的角度,这是个永无止尽的怪圈;不过因为我们的想象力有限,最终总会终结在一个叫做“不怎么样”的终点。 大概因为我是个乖小孩,所以我既没有逃学,也没有在课堂中做过什么怪异的事情,仅仅是有段时间经常不做家庭作业而已。当时所困扰我的,主要是下面这个问题: 如果我死了,那又怎么样? 我忘了我是怎样找到这个问题的答案的了。有意思的是,我的小学生涯中曾经遇到过另外一位同学,也问过我这个问题。我答: “不怎么样。” “那我现在从这儿跳下去,怎么样?” 当时我们的教室在三楼,我们正在课间休息,站在走廊上望着楼下沙尘滚滚的操场。 “你的父母会伤心的。” 这就是“那又怎么样”的怪圈:一切都不怎么样,但如果你自己无法放开,便总会陷入中间的某个环节而跳不出来。 8、到了很久以后的后来,我发现这完全是自欺欺人,因为根本是我自己不想死而已。 9、霹雳布袋戏里面,六祸教主和佛公子都有提及到天命。“上天叫你做什么,你就做什么,这就是你的天命。”好比我们可以说爱因斯坦的天命就是物理学家,布袋戏编剧的天命就是布袋戏编剧,这就是他们生命的意义吧。不过有子曰,五十而知天命,看来我还有点遥远。 10、除了“那又怎么样”怪圈之外,还有另外一个十分困扰我的怪圈,那就是物质能量守恒定律。 “物质(能量)不能被创造也不能被消灭,它们只能从一种形式转化到另一种形式。” 所以这个世界的真相就是,我们身上的每一滴血,每一块肉,从某种程度上来说,都是从宇宙诞生之始便开始存在的(只是转换过无数次的形态而已)。 11、而因为物质能量的守恒,便意味着我们所有的工作,都不能算是创造。 画家只是把染料重新组合在画布上; 建筑师只是把各种材料按特定的方式拼接起来; 作曲家只是把天然存在的声音重新排列了一番。 上一篇文章有提到说编剧的工作就是剪刀浆糊活儿,编辑也是一样,现在看来这句话还没说到位。 应该说,这世界上所有的创造类工作都是剪刀浆糊活儿,就好像物理定律永远只能被发现而非被发明一样。 12、然而有一种工作,我无论如何都感觉它是一个例外。 那就是编程。 以编程为基础的IT技术搭建出来了一个如此缤纷的、介于现实与精神之间的另一个世界。 13、但是归根结底,这只是一个由0和1的排列组合所表演的一场无中生有的魔术。 … Continue reading

Posted in random | Tagged | Leave a comment

编辑与编剧

今天被问起说怎么很久没更新博客,想一想的确也是有上那么个把月了(其实文章似乎一直没少写,只是没往博客里面扔罢了)。回想大学时代,往往也是学期中间不写东西,一到了考试之前,就三天两头的往论坛里面跑动,搞各种活动和码各种文字;据我一个喜爱写同人文的死党描述,她也是闲的时候啥也不写,一到忙的焦头烂额时便一个坑接着一个坑的挖……难道正所谓忙里偷闲是人天生的爱好么?说来现下也是一个专题赶着上线,手底下还在做评测,却忽然想来更新博客,看来莫非真是平时不够忙么……? 嗯,上面最后一句当我没说。其实是最近的闲暇时间仍然在霹雳布袋戏中度过,刚看完了小一百四十多级串一起的霹雳神州三部,感觉精神和体力都消耗的极大,实在是没力气去更新我这边的一亩三分地。不过看戏之余,也看了不少编剧漫谈之类的记录,也算是有些意外的收获。 霹雳布袋戏最初就是一个编剧,号称“十车书”的黄强华。随着剧情铺的越来越大,霹雳的编剧队伍也逐渐壮大,现在大概也有了那么十多个了吧。这十多个编剧当中,有一位叫做三弦(韦三编)的,从07年开始开了博客(那边的习惯是叫做网志),断断续续更新到今天,讲的都是和霹雳相关的大小事。 这个网志的名称叫做“我在罪恶坑的日子(墙内的筒子们可能要费点功夫才能阅读)”,直译过来就是“我在霹雳布袋戏编剧组的日子”。罪恶坑这个势力在布袋戏的戏中也出现过,至于是在编剧组被冠名之前还是之后这就不大清楚了。的确这个名字安插在霹雳编剧组头上也的确很贴切:“编剧是个罪恶的职业,每个月至少要杀几个人到几百人;每隔一阵子,还要想办法毁掉一个派门甚至一个国家。”相信看过霹雳的都会认同三弦在自己博客门上留下的这句话。 处于霹雳中毒状态的本人自然是把这个博客的每一篇文章翻了个底朝天。本来只当是娱乐,却意外的收获了又一个我所喜爱的博客。这喜爱大概是出自某种共鸣:我们同样是理工科出身,入了笔杆子这行;我们同样认为自己的工作是做一个出色的厨师(编剧,编辑,嗯,单单是名字就有点殊途同归);我们同样在2002年开始真正的“看”了世界杯,并在那同一年成为了卡恩的崇拜者,德国队的支持者;我们同样认为给邓王爷配的那首“出巡”是一首贴切的不能再贴切的人物配乐……甚至于,我们同样有隔1、2个月才更新一次博客的习惯。 当然,我们还是有很大的不同:比如我的经历没有三弦那么传奇,我和机场也没什么冤仇,我也不是电脑杀手,似乎也没有他所患的那种生活机能不足的症状(其实我一直觉得我也是某种类型的生活机能不足症候群,不过我的问题和真正的生活相关,而不在电子产品这一块)。简单的说,似乎就是我的运气比三弦好-3- 言归正传。在三弦的博客上扒了三天,让我发现了一个困扰我许久的一个问题的解答。那个问题就是:如何才能把一个故事讲得好听? 编剧的工作就是创造故事,并把故事讲出来,讲得让人们喜欢听。让我很庆幸的一点是,对于故事存在的意义,我和韦三编的看法是一致的:故事不是用来歌颂或者诋毁什么价值观的;故事的价值就在于故事本身。对我来说,霹雳布袋戏的魅力就在于那些不同性格的人物,那些承载着各种欢喜与伤悲的故事。 可是虽然我很喜欢看故事,但我却从来编不出好故事,也讲不好故事,正如同我每次跟人讲笑话,除了我自己以外都没人笑一样。我曾经兴冲冲的想要把轩辕剑三中赛特在塔德莫尔古墓里的奇遇描述给我老妈听,结果愣是把她说的昏昏欲睡;后来老妈提出多种建议,包括应该多加一些场景描述,古墓是多么昏暗,眼前飞过的安卡是怎样华丽的一只黑猫等等,但是此时的我已经失去了信心,没有再做过更多的尝试了。 做了编辑之后,更发现“讲的故事不好听”是我的一处软肋。我在主站写文章,总是力求内容有技术含量,相关事件有所考据,文章条理清晰,并且最大程度的减少水分,让读者对整体内容架构一目了然,便于拓展思路。可是看过我文章的同事们都说,我的文章少了点吸引力,少了那种让人一读开头便欲罢不能,看了中间还想接着看结尾的那种诱惑力。我妈也总是说我(和我老爸),讲事情的时候总是要从头开始,按部就班的讲,无论别人如何急着想要了解后面发生了什么事,我们也一定仍然会一丝不苟的按照我们预先排设好的步调讲,所以什么事情讲起来,不好听也就罢了,往往还会把人急个半死。 看了这篇《剪刀与浆糊》之后,我终于明白我的问题在哪里了。 “所谓剪刀与浆糊,就是剪贴跟拼凑,也就是节奏感。” 节奏感。短短三字,如拨云见日。虽然IT技术类编辑相对其他领域的编辑而言有其特殊性,不过说到底,无非也就是多出技术类文章这一块。就算技术类文章占了一半,那我们也有一半的内容都是在讲故事:新闻,以及历史。甚至应该说,讲故事的这一半编辑实在要比发技术文章的这一半编辑来的更加重要,因为写技术文章的人是开发者,是网络管理员和系统管理员,是企业的CTO和CSO们;而为IT技术这个领域报道事件,记录历史的这项工作,我们是责无旁贷。 不过,虽然知道了症结所在,要真正掌握住节奏却也不是一天两天能够实现的,就好像我们可以简单的计算出刘翔跨栏跑110米需要多大的力量,耗费多少能量,但是要我们自己去跑出十几秒的成绩那是不可能在短期内实现的。 没别的,还是要多练,如此这般。据说要提升创作的能力,最简单的方法是强迫自己每天写个几千字。嗯……

Posted in editor | Tagged , , | Leave a comment

从开源的角度看RedOffice事件始末

骂街属于人的本能,但如果只会骂街,人永远也无法看到真实,而只是多浪费口水而已。 本文在51CTO发布地址:http://os.51cto.com/art/201007/212032.htm 【51CTO独家特稿】2010年5月初,“核高基”项目(核心电子器件、高端通用芯片及基础软件产品)基础软件测试工作结束,金山WPS和永中Office入围,可能分别获得5000万-6000万的中央财政资金资助,而红旗2000旗下的RedOffice则因为被定性为“非国产”而出局(详见51CTO之前的报道)。接下来有媒体消息进一步证实,原红旗2000总经理胡才勇已经离职,同时红旗2000也发表申明,所有公司的事务由其他人代理,其中时间上的巧合,引起多方猜疑纷纷。 此消息一出,业内各方登时哗然,有关国产、假国产、开源、版权等话题的讨论和口水战掀开了新的篇章。技术本无国界,做为一个纯IT媒体编辑,笔者对于“国产”或“假国产”的定义了解不多;但是有关开源与版权的问题,倒是不妨与大家一起讨论一二。 下面我们便从数个问题入手,从开源的角度来逐步探索RedOffice的事件始末(以下内容大多数收集自互联网,如有问题,欢迎纠正)。 问题1:RedOffice的代码从何而来? RedOffice是红旗2000的招牌产品。红旗2000公司在2000年创建,并在2001年发布了RedOffice 1.0。RedOffice从最开始便以国内首个基于开源OpenOffice.org(简称OpenOffice或OOo,不过由于OpenOffice这一商标有版权问题,所以正确的缩写应为OOo)的办公软件自居,其代码基于OOo的代码修改而来,修改内容包括控件、插件、中文化等方面,尤其在GUI(图形化界面)方面有极大的改进。 根据红旗2000官方发言人的说法,“OpenOffice的源代码有1000万行左右,而红旗贰仟改写的有几百万行”。据称,现在参与RedOffice开发的团队将近有200人。 目前,RedOffice的最新版本是5.0 Beta(最新稳定版为4.5)。 问题2:RedOffice的代码是否开放? 根据笔者的了解,RedOffice不提供源代码下载。对于这一点,OOo社区的普遍理解为:RedOffice是OpenOffice.org的核,带上一个具有商业性质(commercial)的GUI。 问题3:RedOffice对OpenOffice.org造成侵权了么? 事实上,RedOffice在2006年参与了那一年的OpenOffice.org大会,之后便开始与OOo社区分享代码,并积极参与OOo的年会和社区建设。之后在2007年5月份,Sun(当时OOo的所有者)与红旗2000签署了一份SCA合作协议,协议内容为OpenOffice.org接受红旗2000为合作伙伴,而红旗2000则帮助OOo的中文本地化,并向社区贡献代码(详见OpenOffice.org官网的版权认可合作伙伴页面)。 虽然现下Sun已经被Oracle收购,OOo已属Oracle下的项目,但之前的合作关系并未改变,RedOffice仍是OOo认可的衍生版本。除非Oracle提出异议,否则RedOffice并不构成侵权。 问题4:RedOffice是否违背了开源协议? 2000年OOo项目启动时,同时在LGPL和Sun的SISSL的双重许可协议下发布,源代码完全开放。Sun在2005年宣布要让SISSL退休,于是2008年3.0 Beta版本开始,OpenOffice.org开始采用单一的LGPL v3开源许可协议。 另一方面,RedOffice在早期也遵循SISSL协议,不开放源代码(当时的OOo处在LGPL和SISSL的双重许可协议下)。而根据红旗2000工作人员的说法以及其在2009年公布的一份白皮书,现在的RedOffice已在LGPL开源许可协议下发布。只不过,这则信息并没有在RedOffice的官网之上和RedOffice的软件中注明;而RedOffice安装过程中关于许可协议方面的说明则是“最终用户许可协议”,其中并没有提及LGPL的相关事宜。至于RedOffice的源代码,我们之前也提到了,那就是除了其分享在OOo社区的代码之外,我们是找不到RedOffice的源代码的。 我们先来了解一下上述的这两个许可协议。首先是SISSL:这是一个有点奇怪、自由度很大的许可协议。就以OOo为例,根据笔者对条文的理解,其大意就是,你可以把OOo的源代码拿来随便改,改了之后可以发布你自己的产品。只要在你的产品发布之前的120天内Sun没去踢你的场子,你要开源还是闭源都可以。 另一方面,LGPL v3则是GPL的修改版,强调了“库(Library)”和“应用程序(Application)”之间的区分。“库”所指的就是处于LGPL协议下的作品,而“应用程序”则是对“库”进行了引用,除此接口之外与库无关的作品。简单来说,就是如果你的应用只是对LGPL类库进行了引用,而没有修改库本身的内容,那么你的应用可以不开源,可以作为进行过二次开发的商业软件(参考阅读:四大开源协议比较:BSD、Apache、GPL、LGPL )发布。对LGPL感兴趣的51CTO读者们可以去阅读一下非官方的LGPL条例中文译文以及GPL条例的译文(繁体中文版,Chinese Translation Services翻译)。 所以,LGPL是一个比SISSL更为严格的协议。不过根据定义,如果衍生产品是OOo 3.0 Beta之前版本的代码修改而来,那么仍可遵照SISSL协议,针对库的修改也不用开源;一旦用了OOo 3.0 Beta之后版本的代码库,那么则针对库的代码必须公开,而引用库的二次开发部分则无需开源。 另外需要注意的是,开源许可协议规定的重点仅仅在于“源代码是否公开”以及“衍生产品是否需要遵循同样的开源条例(所谓开源许可的传染性)”,而与产品是收费还是免费毫无关系。收费的开源项目其实也很常见,红帽企业版Linux就是最大的例子。 所以,要明白RedOffice是否违背了开源协议,这有两个层面的意思: 1. RedOffice自称LGPL,可是它的代码公开了么? 2. RedOffice使用OOo代码的方式,是否违反了OOo上LGPL或SISSL许可的规定? 有关第一个问题,根据笔者目前的了解,RedOffice不提供源代码下载。也就是说,RedOffice不能被称之为基于LGPL发布的开源软件,而应被定义为专属软件。 而第二个问题就比较复杂了,即使我们手上有RedOffice的源代码,这也仍然是个十分困难的问题。回顾开源界的历史,曾经有Keith … Continue reading

Posted in open | Tagged , | Leave a comment

所谓快速的浏览器到底是什么意思?

最近在做一个浏览器相关的策划,找资料的时候发现了Evan博客上的一篇文章,就大致编译了一下。感觉还是挺有意思的:) 本文在51CTO的发布地址:http://os.51cto.com/art/201006/208453.htm 本文从技术和用户体验的角度,一一介绍了影响浏览器速度的因素,以及如何判定一个浏览器是否快速。本文作者Evan Martin是Google Chrome项目的开发者,文章来自他的个人博客,与Google官方并无关系。以下为原文编译: 所谓快速的浏览器,到底是什么意思?事实上这是个挺困难的问题。我在最近的Ubuntu开发者峰会上被邀请谈谈这方面的问题,并写下这篇文章进行补充。 基准测试 很多人会先想到基准测试。科技媒体喜爱基准测试,因为基准测试提供了数字,可以用来描绘美丽的对比图。然而从本质上而言,基准测试衡量的都是十分具体的参数,仅能用来模仿用户可能将经历的过程。浏览器最重要的基准测试就是JavaScript基准测试,然而虽然没人会否认JavaScript的重要性,但JavaScript毕竟不是大多数简单网页加载速度的决定性因素。我认为现在针对JavaScript引擎所作的改进主要是为了未来将被创建的站,比如这个JavaScript NES模拟器。当然了,像是Gmail这样大大得利于快速JS引擎的站也不算少了。 通过JavaScript基准测试得出的结论往往是令人乏味的,比如:“Wine实现的Mozilla比Linux编译的Mozilla快,所以Mozilla并不重视Linux”。JavaScript基准测试就是能够得出这样缺乏引导性的结论,而事实是,浏览器对于JavaScript的实现代码在各个平台上都是几乎完全一样的!上面这个测试的速度差很可能来自编译器质量的不同,所以Mozilla遇到的差别在其他跨平台浏览器上应该也能够看到。这样的评论从各个层面来看都是十分无聊的。第一,该结论毫无依据;第二,JavaScript基准测试从设计而言和平台毫无瓜葛;最后,这些基准测试甚至没有针对每个平台特有的代码进行测试。 新的基准测试正尝试覆盖JavaScript之外的内容。Dromaeo是个不错的例子,这个测试有一部分是针对DOM的。不过,我们要小心第三方的基准测试!对于Dromaeo还好,它的作者John比其他大多数浏览器开发者对Web开发的理解要来的更深入;但对其他人我就不怎么放心了。写一个看起来不错的性能测试并不难,但它测试的不一定是有用的东西。好比说,SunSpider 0.9.1发布声明中就有一段内容,有关测试框架与能源管理之间交互的一个bug。要知道,这个bug涉及到的作者是一个经验丰富的浏览器开发者,而不是随便哪个Web开发爱好者。 周期计时 一个更好的测量方法可能是观察浏览器从头至尾加载一个真实的网页的性能,这个过程包含了JavaScript引擎以及其他部件的工作:HTML解析,字体测量等等。我们和Mozilla(我想其他浏览器厂商应该也都有)都有针对本地页面的测试工具。对于第三方测试者而言,通过使用这些工具来测试比较浏览器的加载速度是很自然的选择,唯一的不同在于他们的测试对象是真实的网页(如Yahoo主页),其测试结果也往往是有版权而无法公开的(就我所知,我们的测试页都被设为隐私;而我在Mozilla也只找到这样一个页面)。 为了使测试数据可以重现,通常的测试方式都是从本地读取一个页面文件,而不是从网络上读取加载(51CTO编者注:记得Google那个切土豆的视频么?有细心的网友发现视频中的测试页面是本地地址,这实际上是浏览器速度测试的通用做法)。目前讨论的基准测试当中,还没有一个将网络速度包含在测试因素内。这是一个遗憾,因为这是个很有趣的领域。比如说,不同的浏览器如何使用不同的单个host连接限制,或者Chrome如何在启动时进行DNS预读取(这个DNS预读取的行为事实上比任何Web渲染或JS处理造成的影响都要大。你可以在Chrome中输入about:dns进行进一步了解)。 网速之外,仍然有其它影响浏览器性能的环节,比如网络协议层以及缓存。我记得在Chrome开发前期,Mike还是Nagle曾经发现过一个网络层的bug,这个bug造成Chrome读取网页的速度迟于IE。上面所有的这些测试都无法呈现出这个bug的效果。另外从某种角度而言,将像素呈现在屏幕之上所花费的时间也可以算作一个环节。Gmail的加载更是一个疯狂的多重过程,这个过程在例常的JavaScript和呈现的步骤之外还包含了好几次重新导向、进度条等部分;而就我所知,似乎还没有哪个测试是针对Gmail的加载速度而进行的。 秒表 所有的测试在本质上都是虚幻的,并不能代表真正的浏览过程。人们终于意识到这一点似乎是从微软发布IE8开始,当时微软的基准测试声称IE8是最快的浏览器。基准测试的某一项叫做“我们付钱雇了一些志愿者仔细的看,他们说我们是最快的”,然而不幸的是,而这一项测试的结果无论动机如何纯洁,都无法使大多数人接受。事实上,这样的测试比任何一种性能基准测试都更接近于我们的目标,但糟糕的是,这种测试的结果数据完全无法重现。也许浏览器开发者们会针对这点进行优化? 心理作用和Jank 人们称一个浏览器为快速的原因不仅是上面提到的这些。从可测量的数字到模糊的秒表测试,我可以确认一点:比测试性能更重要的是,用户感觉你快不快。下面我来讲讲这几个和网页无关的有趣因素。 其中一个叫做UI延迟(我们称之为jank)。当你在地址栏里输入的时候,浏览器的反应快么?创建新标签页的时候呢?Peter曾经就此做过一次演讲,虽然我没看,但应该是十分深入的一次课程。在对Ubuntu开发者演讲时我也十分希望强调此点,那就是即使你的应用能够在一秒之内呈现上千页面,一个小小的问题仍会让用户感觉你的应用很慢(比如Ubuntu的软件包更新工具在这方面我觉得就做的很糟)。我觉得这才是我们在性能上“超越”Mozilla,以及我们在Linux上日益流行的最大原因。当然,这是一个很难量化的因素。 减少jank的一个很好的例子就是Chrome中自动完成的实现。当你输入URL时,我们从您的浏览历史中提取URL的自动完成,以及相似地址的推荐。当你按下Enter键时,我们让Chrome进行了同步自动完成,以确保你进入的地址正是你所看到的地址。当然这也便意味着我们不能从磁盘读取数据,因为从磁盘读取的过程会令自动完成有所延时。因此我们的做法是,将整个自动完成的数据在浏览器启动时加载到内存当中(相比你的所有浏览历史,这部分数据并不是很大)。 启动 另一个有关性能的环节和上面所有的因素几乎完全没有关系,那就是启动速度。我在之前的演讲中提到了GNOME的计算器,不过他们现在已经修复了这个问题。好在类似的问题很多,比如Ubuntu的菜单也是,我每次都要数到5才能弹出菜单。对于Chrome的启动我写过十分详细的技术文档,从基准测试和适应低配系统等两个方面阐述。现在我们来看看为什么这十分重要。 我相信一个应用的启动速度确立了用户对其性能的期待。事情总是这样的:用户认为你很快总是要比你事实上快不快来的重要。当你的启动速度和轻量级应用一样快时,用户会觉得他们在使用一个轻量级应用,尽管事实并非如此(事实上,任何一个可以呈现页面的浏览器都是庞大的应用,包括我们的Chrome)。比如说,即使到今天我还是习惯时不时的使用vi编辑器,因为emacs启动实在太慢了。我甚至没有意识到我在下意识的拒绝使用emacs。 当然,快速的启动意味着在启动时做更少的工作,因此整个代码都需要进行仔细的工程。 结论 在Chrome工作三年,我从中学到的一大原则就是:如果你没有考虑某个性能,那么这项性能必然会退步。这是软件开发的一个自然现象,因为我们总是在为应用添加而非减少东西。因此,我们使用buildbots来为所有的性能测试创建图表(该页面巨大,当心浏览器崩溃)。每个退步的性能项都会变红,这事经常发生,然后我们就要修改代码。 总之一句话:基准测试仅仅在你了解该测试的技术细节时才有他的用处。如果你并非一个浏览器开发者,那么身为一个“专业人士”,我要说的是,自己打开网页尝试一下才是判断哪个浏览器最快的最佳方法。 原文:http://neugierig.org/software/chromium/notes/2010/05/fast.html

Posted in developer | Tagged | Leave a comment