|
发表于 2004-3-24 11:02:12
|
显示全部楼层
(轉 貼)
文章选项:
xiaohuo
(enthusiast)
03/20/04 12:58
一点意见 [re: tar]
将草案公布出来,广泛征求意见,是件好事。现在正是大家一起挑毛病的最
好机会,如果现在不关心,不闻不问,等正式成为标准,那时再骂,也无济于
事。所以有话赶紧说。
粗看了一下,编写人干的很辛苦,这不是件容易事。但是也不能因此而降低
要求。Unix之类的标准,已有许多,足资借鉴,翻译好应该是第一步。现在
公布的这几个草案,在翻译上就有许多要改进的,以眼下的文字看,想“争取
尽早正式发布”,恐怕不那么乐观—当然就这样敷掩过去,也不是不可能,只
是那样的话,自己不把标准当回事,别人更不会当回事了。
很多人把标准当作所谓“技术壁垒”,实在是本末倒置,是短视的行为,挖得
深一点是没有自信心。标准首先要从使用者来考虑,在满足用户使用的情
况下,尽量给供应商提供方便,让供应商们在价钱上,在技术上,在服务去竟
争,为广大使用者争取最大的利益,也促进供应商不断改进,赚更多的钱,这
样大家都得利。如果制定标准时,让少数厂商劫持,为了一些少数人的利益,
有意提高“技术壁垒”,最后受害的还是自己;何况那些所谓“技术壁垒”,可
能根本就不是什么了不得的东西,没难倒别人,反而给自己惹麻烦。
其实不管什么事,中国人只要认真踏实地做,只有比外国人做得更好,何况
做给自己人用,价格、服务都有天然的优势,技术上再进一步,可以说是地
利人和,完全没必要那么没有自信心。
还有这类标准是不是得政府去做,很值得讨论。尤其动不动就用“强制”这
样的词:一一“强制”过来,得多少人来办,如同满大街的工商税务,就业是增
加了,可并未增加社会财富;如果睁只言闭只言,“强制”标准成为一句笑话,
到时真想强制什么,怕就没什么人理会了。
何况技术的发展那样快,有些东西在不成熟的时候硬要去标准,就显得很勉
强。这时既要定规矩,又要不管死,其间分寸,很费思量。
上面的都是一些空话。具体到比如《Linux应用程序编程界面规范》,就有
些很让我莫名其妙的地方。
该草案开宗明义,称“能通过LSB 2.0符合性测试的实现,即符合本规范。
本规范不要求进行单独的符合性测试。”既然如此,标准就可以结束,皆大
欢喜。如果意犹未尽,把LSB 2.0翻译出来,附于其后,也是好事一件。甚至
说中文处理有些特殊之处,LSB 2.0没有涉及,希望大家在实现时,能加以考
虑,也无不可。问题是这些LSB 2.0没论及的,如果某一实现中没有,虽然该
实现通过了LSB 2.0,到底他是符合还是不符合标准草案呢?
从标准测试角度看,应该是符合的。所以实质上,草案后面很长的篇幅提到
的东西都可以忽略不计。可是,那里的一些遣词造句,却又极力给人造成“强
制”的假象,不知道是要糊弄谁。
比如
符合本规范的实现应提供以下函数:
a) 把一个全角字符转换成对应的半角字符
名称
fctohc
格式
#include <stdlib.h>
int fctohc(int *pc,const char *s, size_t n);
注意“应提供”的说法。草案前解释说
提供的(Provided)
在本规格说明书中是强制的并在所有符合的实现中实现的一定的设施。
如果问不提供fctohc的实现,是否符合该标准(草案)?
我以为也可以符合,只要该实现通过了LSB 2.0。如果谁硬要说成不符合,
我认为那是受虐狂的解读。
假设fctohc,isfullc确实很有用,中文处理少了他们就不成,完全可以做个
libzw.so,定义在zw.h里,为什么偏要放在stdlib.h和ctype.h里呢?实在难
以理解。
还有更后面“16.4 输入法服务器与输入法的结口”,红旗Linux如果很为那
一套API自豪,不妨全都拿出来,给大家看看,而不应硬塞进草案中;或者作
为范例附录,给人参考,也不错—可现下这样,到底是“强制”还是不“强制”呢?
无论如何,关于Linux这一open source的草案能open开来讨论,很好。正如
高林说的,“不但要把国外标准引进来,还要把国内需求提出去”,这第一步
则是使有者把“国内需求”提出来,那可不仅是少数厂家和政府部门的事,而
是所有关心Linux的人的事。 |
|