Read Sean

大胃眼中的.NET和其他
posts - 139, comments - 122, trackbacks - 1, articles - 0

2006年12月8日


http://www.blogjava.net/sean/archive/2006/12/15/87874.html

上一篇提到NAnt 0.85的两个bug,经过一番折腾,发现问题其实出在它bundle的sharpcvslib(scvs.exe),我的解决步骤如下:

1- 安装CVSNT,并在编译脚本加入
<property name="sourcecontrol.usesharpcvslib" value="false"/>
让NAnt不要使用那个bundle的sharpcvslib(scvs.exe),而是使用CVSNT的cvs.exe;

2- 去掉先前由NAnt建议的<cvs-pass>这个Task,以及<cvs-checkout>中的passfile属性;

3- 指定cvsroot中直接包含密码,格式
:pserver:username:password:@xxx.xxx.xxx.xxx:/your/cvs/path

前面提到的文件编码以及用户密码验证等问题均不复存在。

以下谈一谈我的观感:

.NET的开源项目,就NAnt和sharpcvslib来说,不论是代码质量、文档、社区活跃程度、更新/反馈周期,都还有很大的改进和提高的空间,从实际效果来看,感觉.NET部分开源项目的定位和初衷也很值得思考,究竟一个.NET开源项目的存在更多的是要证明.NET/C#也可以做到xxxx,还是要解决实际问题?这背后的价值观到底是什么?

如果是解决实际问题,那么为什么有现成的Win32环境下成熟的、完整的CVSNT可用,却一定要自己搞一套cvs库,而且还要默认使用这个相较而言颇为不成熟的库?如果你跟我说这样是需要对CVS访问有更精细的控制,那我想还不如在CVS的命令行参数上多下些功夫来得实际。

其实CVS已经存在很久,对于基本的协议、标准,现有的不少CVS客户端都实现的比较到位,sharpcvslib不知何故进展如此缓慢,官方站点 sharpcvslib.sourceforge.net最后更新时间是今年2月,上一个发布版本0.35是2004年,开发版本0.36是2005年1 月,NAnt也好不到哪里去,0.85的RC1版本2004年11月就出来了,正式的0.85到今年10月才放出,如果你看看它的bug database,很多bug都石沉大海。

这个版本的NAnt在使用中的一些细节的处理个人感觉也有些欠缺的地方:比如:使用<cvs-checkout>,password属性被deprecated,直接就不支持了,没办法,“官方”建议使用<cvs-pass>那我们就用吧,但是<cvs-pass>和<cvs-checkout>就目前看来,配合的并不默契(详见上一篇随笔bug ID 1616136)。

相比之下,生活在Java以及GNU/Linux/BSD下的朋友们,在上述这些方面就要幸运的多。




大胃 2006-12-17 22:49 发表评论

文章来源:http://www.blogjava.net/sean/archive/2006/12/17/88383.html

posted @ 2006-12-17 22:49 大胃 阅读(274) | 评论 (0)编辑


由于是从Java转做.NET项目,在考虑SCM和自动编译时,自然而然想到NAnt,不过0.85的RC版本出来很久,一直没有正式release,直到最近一次偶然的机会我才得知正式版已经出来,虽然不支持Visual Studio 2005的解决方案/项目文件,但至少支持.NET 2.0,正好项目整个框架和模块清单基本定型,遂决定下点功夫把我们的构建过程脚本化、自动化。

经过些磕磕绊绊,总算是跑起来了,但还是有不够完美的地方,发现2个bug,提交到NAnt在SF.net上的bug database:

[1614467] NAnt自带的scvs.exe(<cvs-checkout>)从CVS拿文件时会忽略文件的原始编码,如UTF-8。
[1616136] NAnt的<cvs-pass>和<cvs-checkout>两个task对passfile属性的处理不一致,<cvs-pass>创建密码文件在指定位置,<cvs-checkout>却不从那里拿。

不知大家有没有遇到类似的问题。如果有时间,我倒是很想把源码拿下来看个究竟。




大胃 2006-12-15 10:14 发表评论

文章来源:http://www.blogjava.net/sean/archive/2006/12/15/87874.html

posted @ 2006-12-15 10:14 大胃 阅读(87) | 评论 (0)编辑


参考上一篇(Second zero-day flaw):
http://www.blogjava.net/sean/archive/2006/12/06/85968.html

以下是来自CNET News.com的报道:
http://news.com.com/2100-1002_3-6143853.html




大胃 2006-12-15 08:58 发表评论

文章来源:http://www.blogjava.net/sean/archive/2006/12/15/87846.html

posted @ 2006-12-15 08:58 大胃 阅读(49) | 评论 (0)编辑


在Google正式加入Eclipse Foundation后不到一周,又传来好消息:GWT开源了!GWT是Google重量级的Ajax开发框架,使得广大开发者可以使用熟悉的Java语法实现Ajax,这次GWT开源选择的是Apache License, version 2.0。详情:

http://code.google.com/webtoolkit/




大胃 2006-12-14 18:52 发表评论

文章来源:http://www.blogjava.net/sean/archive/2006/12/14/87775.html

posted @ 2006-12-14 18:52 大胃 阅读(62) | 评论 (0)编辑


http://blogs.msdn.com/bclteam/archive/2006/12/07/introducing-pipes-justin-van-patten.aspx




大胃 2006-12-09 00:57 发表评论

文章来源:http://www.blogjava.net/sean/archive/2006/12/09/86485.html

posted @ 2006-12-09 00:57 大胃 阅读(45) | 评论 (0)编辑


http://blogs.zdnet.com/Burnette/?p=214




大胃 2006-12-09 00:35 发表评论

文章来源:http://www.blogjava.net/sean/archive/2006/12/09/86480.html

posted @ 2006-12-09 00:35 大胃 阅读(40) | 评论 (0)编辑


http://www.sutor.com/newsite/blog-open/?p=1264

注:
[1] Open XML是微软基于MS Office文档格式提交ECMA审核表决的文档格式标准
[2] Bob Sutor是IBM负责标准和开源的VP
[3] 目前已经存在同类标准 - ODF (Open Document Format),OpenOffice.org支持ODF标准。




大胃 2006-12-09 00:08 发表评论

文章来源:http://www.blogjava.net/sean/archive/2006/12/09/86478.html

posted @ 2006-12-09 00:08 大胃 阅读(48) | 评论 (0)编辑


昨天刚刚向大家推荐了一个关于Trusted Computing的短片,今天继续沿着这个话题往前走,读一篇来自InformationWeek的文章:

How Vista Lets Microsoft Lock User In

通过在Vista中真正融入所谓的DRM/IRM(Digital/Information Rights Management)技术,微软可以有效地在"开放和标准化Office文件格式"的同时,通过加密、数字签名和数字授权等方式控制文件的打开、打印、修改、保存、转发,渗透到文档的整个生命周期,甚至文档发出去之后,还能亡羊补牢,收回授权!表面上这当然是在提高安全性,事实上这也是在打压Google、OpenOffice.org等MS Office之外的MS Office格式文件阅读/编辑器,使得它们不再能够在没有微软授权的情况下合法的打开MS Office文档,或者至少会让这个过程变得极端复杂。故事的另一头,在最终用户对安全都十二分的敏感的大前提下,典型的Office用户当然会遵从微软的官方建议或者许多媒体推荐的安全建议,把安全级别提高,乃至采取严格的加密授权这样的极端措施,因为MS Office给他/提供了这样的便利。到最后,要想得到加密的内容,光有key还不行,还必须使用MS Office,因为IRM理论上可以阻止其他阅读/编辑器得到认证。

举个例子,如果我的PC装的是Windows和Linux双系统,那么当我使用Linux并试图申请授权,尽管我的机器配置不变,IRM仍然可以认为我是不可信赖的接收者,因为OS也会参与IRM认证计算,甚至有可能当我升级我自己的硬件,会造成先前运行良好的应用程序或服务突然变得无法使用,同理,同样是Windows环境,如果使用非MS Office的编辑器,那么计算出的序号也将不同,无法获得密钥,从而也无法打开文档,这就事实上把用户,把用户的数据,和MS Windows、MS Office绑在了一起。我们有理由置疑这背后的动机,TC/DRM/IRM是不是有点管得太宽了呢?

如果我们日常工作和生活的文件编辑、交换、共享,甚至是官方公文的流转,都采用MS的格式和MS的工具,一旦微软成功实现了Lock-in,想想都觉得可怕。

TC/DRM/IRM背后最大的利益推动者就是微软,纵观微软TC/IRM/DRM的渗透过程,大致可以分为三个阶段:第一个阶段是硬件支持,目前市场上相当数量的主板,都已经集成了TCM(Trusted Computing Module)模块,只是没有被很好的利用;第二个阶段实现软件、服务平台、乃至操作系统级别的支持,初步实现远程认证,这个在微软的Genuine Advantage实施中收到了实际效果;第三个阶段当所有人都更新到最新的支持TC/DRM/IRM的Windows和MS Office,微软就可以从容的使用他们精心部署的"秘密武器"来实现垄断了。

近一段时间以来我时常对同事朋友们说,MS的世界是封闭的,为了达到所谓的"Openness",它要求所有人都使用MS Windows,进入这个封闭的世界,而且总是列举各式各样冠冕堂皇的理由。如果有一天,MS占据了我们整个生产链条的每个环节,并且有效的控制了盗版,我们每做一件事,哪怕是买一份早点,都在给MS上税,因为为我们提供早点的整个流水线的成本中包含了MS软件的成本,因为找不到合适的替代品,或者寻找替代品代价高昂(也许通过FUD造成这样的假象)。这就是垄断的危害,这就是为什么我主张大家更多的了解、学习和使用那些更开放的,甚至开源的操作系统、服务器和应用软件。

别小看了微软,尽管这两年.NET喜忧参半,Vista发布一再推迟,开源风头正进,微软也一度被很多置疑和负面消息笼罩,似乎正在逐渐失去它以往的光环,现如今Vista已经正式发布,微软这个昔日软件帝国新一轮的战斗野心正蓄势待发。

除了我自己,我无法阻止任何人使用Windows、MS Office,也无法阻止他们使用盗版软件,但是,我可以以自己的实际行动避免把自己反锁在微软的乌托邦,希望你也可以。




大胃 2006-12-08 21:16 发表评论

文章来源:http://www.blogjava.net/sean/archive/2006/12/08/86450.html

posted @ 2006-12-08 21:16 大胃 阅读(65) | 评论 (0)编辑