孙秀楠的网站

分类： tech

  • Open Source开源软件的授权问题

    最近公司里面经常会提到开源（open source）这个名词，很让人感觉新奇。开源与Free并不完全等同，开源也不是没有限制，今天秀楠爸爸就聊聊开源软件的授权问题（license）。

    开源要什么授权，代码都放出来了用就是了，这是我们国内不少linux从业者的言论行为，包装了或者使用了Linux的代码，却不开放自己的代码，殊不知，这是违法的，如果LInux的相关代码拥有人对中国公司进行法律诉讼，保证这帮无知法盲全部完蛋。

    为何呢？Linux使用的是GPL授权，这种授权充分保证了Open Source不被商业公司进行滥用，它的授权是具有强传染性和强迫性的，任何使用了GPL授权源代码的软件，也就是承认了自己软件遵循GPL授权（这个是很容易理解的，没有人强迫你用，但使用了就代表使用者承认授权），然后，必须开放自己使用了GPL授权源代码的那部分源代码。所以，大部分的商业公司对于GPL授权是敬而远之的，如果被人发现自己使用了GPL授权，那就只有开源一条路可以走。简单而言，大部分软件公司都喜欢copyright版权协议，而GPL这种授权是copyleft，恰恰相反。

    当然，世界上并不是只有GPL这一种授权，虽然它是现在开源世界使用最广泛的。如果商业用户想选择，BSD授权或者MIT、Apache授权都是比较合适的选择。他们都可以允许不开放使用一方的源代码，这对于商业公司的保密想法是一种最佳选择。

    关于授权的问题，比较经典的例子就是一些黑客程序员因为不满KDE使用了商业授权协议，而自行组织起来开发了GNome。黑客好像多少都有些浪漫气息，对于一点点地不完美都不允许。KDE的基础是QT跨平台GUI库，虽然开发QT的公司最后以双重授权解决了这个争端，保证对于开源软件的使用永远免费，而且有linus这个linux上帝的力挺，GNome还是越来越完善，占据了Linux桌面环境的大部分市场。

  • 跟人找事挑刺，关于“C++开源程序库评话”的回复

    在孟岩的blog上看到这篇文章，一时心痒，就写了回复，然后就有了下面这些话。实话实说，我眼高手低，技术水平不高，也不可能写出孟岩这样有文采的文章的。

    ****所有这些文字都是对文不对人，请勿误解。****

    sunxiunan 发表于2006-04-27 11:09 AM

    不知道有没有数据上的比较，比如说c++多少开源项目，c多少开源项目。这样空口白说，没有说服力。

    说的这些观点，哪些是有“典”的，哪些是自己的，应该说清楚一点。

    立论不坚实，煽动性感性的词汇太多，文章总体感觉一般。

    myan 发表于2006-04-27 11:33 AM

    to sunxiunan:

    得出数据很容易，到sourceforge上搜一下就行了，得出观点就难了，因为你从搜到的数据中根本看不出问题。跟在数据后头永远都是迟钝的。你要立论坚实，不过坚实的立论基本上都是马后炮。

    文章是我写的，观点当然是我自己的。

    风格问题，尊重你的个人的感觉。写东西表达观点而已，风格只是装饰，不求讨天下人喜欢。

    sunxiunan 发表于2006-04-29 3:08 PM

    十年磨一剑，对于一篇blog来说当然不必如此。

    不过，对于一些基本的数据还是应该有一个说明的，我做研究生论文的时候就受过老师的此类批评，比如是否借鉴了别人的观点，不可能都是全新的，整篇文章都是观点未免有些不通，怎么也是有前言、现状、观点、结论这样的一些大结构。

    或许我说的有些刻薄，不过既然是一篇稿件，自然要求和blog文章应该有所不同，是要读者花钱的，自己写着爽和让读者有收获还是有区别的吧。

    sunxiunan 发表于2006-04-29 3:19 PM

    挑一挑刺，我认为应该有论据的地方，

    1）如果说在2000年以前，由于C++在工业界的统治地位，这种差距对C++的影响还不大的话，今天，C++在开源领域里薄弱的基础就非常要命了。

    sunxiunan:应该有具体数据对比，怎么就要命了？

    2）大量的C++开源项目质量不佳，而且经常以一种粗暴的方式要求使用者改变自己程序的风格

    sunxiunan:是否有相关的数据评估，这个不佳是从何而来？

    3）因为实践证明，没有良好的基础设施支持，C++开发成功的可能性异乎寻常的低。

    sunxiunan:这个是最应该有数据证明的地方。

    4）在Java、C、Perl、Python、Ruby中，一个优秀的应用程序开发者在积累一定经验之后，不难写出高质量的可复用代码。而在C+
    +中，这种事情是非常罕见的，即使是天资卓越、经验丰富的大师级人物，也需要花费多年的打磨，历经几次反复，才能够最终推出受到一致认可的可复用程序库。

    sunxiunan:抱歉，这里我并不同意这种观点，说得太过煽情，缺少说服力，难道C++就是一种不同星球的编程语言？程序质量的好坏还是在于写程序的人吧？语言只是工具。

    5）以至于Andrei Alexandrescu感叹道，十几岁的少年天才满目皆是，满鬓斑白的优秀程序库设计者凤毛麟角。而在另一个地方，一本C++可复用技术图书的作者总结道，所谓可复用的C++程序库，不可能是设计出来的，只可能是复用出来的。

    sunxiunan:我真的想知道大师在哪篇文章里说的这个话。

    6）这也就是为什么在2000年后，Bjarne Stroustrup无数次地呼吁社群专注程序库的开发。

    sunxiunan:要是有大师说话的原文链接或者书籍页码就更爽了。

    抱歉我这样苛刻，或许这些都没有必要，但是如果有这些说明的话，这篇文章会更有说服力，现在网络如此发达，作者搜索原文应该要方便很多。

    文章链接在此：

    C++开源程序库评话（节选） – 孟岩

    C++开源程序库评话（节选）

    （本文是即将发表于2006年第6期《程序员》杂志的同名文章的节选。全文请见杂志）

    C语言天生就与开放结缘。C最初是作为UNIX的系统编程语言而流行起来的，而UNIX可以被认为是第一个产生重大影响的“开源”软件。随着UNIX的流行，C语言逐渐被人们认识和喜爱。很快的，在各个平台上C语言都成为了流行的甚至是统治性的程序设计语言。大约到1980年代中期，C已经成为人类历史上第一种工业级程序设计世界语。很多人都知道，正是C这样一种世界语的出现，才使开源运动的出现和最初发展成为可能，从这个意义上讲，说C语言是开源运动之母并不十分过分。
    但人们不太能够认识到的是，事实上C语言统治地位的获得，却也是早期开放软件运动的直接结果。多数人在回顾这段历史的时候，经常会感染中国文人的不严肃的浪漫主义史观，喜欢把C语言的成功归结为汉高祖斩白蛇般的天赋神格，描述为遥想公瑾当年，谈笑间樯橹灰飞烟灭的轻飘飘。然而如果我们对历史作一些细致的调查，我们会发现C语言绝非有什么天命，而只不过是幸运地扒上了早期开放运动的快车而已。在C语言“小人乍富”的那几年，也还有其它不少程序设计语言具有高性能、可移植、系统开发能力强的特点，决不是只有C骨骼特异，貌若天仙。如果Pascal也能借助一个像UNIX那样的开放的幽灵在欧美大学校园里徘徊，那么我们今天很可能要把begin和end直接映射到键盘上。
    如果IBM不是在1970年代极端保守地把一种叫做PL/X的语言牢牢地限定在自己的研究所里，也许整个程序员社群的图腾就不是贝尔试验室的那两个大胡子，而是小沃森实验室里的IBM某院士。事实上，C语言的成功，更须拜开放软件运动之时势所赐，或者更确切地说，C与开放软件是一对共生体，它们相互扶持，相互成就，共同成长兴旺，共同创造历史。

  • 在c++项目中使用opensource library

    前两天，cleveland的开发组发来一封群信，意思是说公司的法律顾问已经研究通过了，允许在公司产品中使用boost库。

    对于这件事当然是高兴加上赞成。不过也有一些个人看法。

    boost号称是c++标准库的预备役，因为里面不少library的质量相当高，比如正则表达式和智能指针，还有线程库socket库等等。不过强大的武器需要操作它的人更加有能力，也就是说，如果不十分熟悉这些库的优点缺点局限性，到时候会出大问题的。

    我就在工作中遇到过很搞笑的设计。一个读取配置controllogix gateway信息的dll，将底层通讯部分剥离到另一个dll中，这种设计本身没有大问题，关键是使用了COM的连接点connection point技术，但是数据却使用内存指针直接传递。我只能对设计这种方案的人举双手赞成，实在是高，真没有想到COM技术与内存直接共享都能放到一起。

    当初的设计方案毫无疑问是只能启动一个dialog，这时候负责界面的dll和负责通讯的dll都活的好好的，可是总有不如意的地方，有的用户发现竟然能同时启动多个对话框，还认为这是应该的，于是我的噩梦就来了，修改这个设计方案费了我好大的劲，其实可以做的很简单，使用一个线程去进行通讯工作，去掉所有不必要的COM设计，保证稳定。

    从DDE到COM技术，到现在的DotNET Platform，我都无法信任它们，能不用就不用。最根本的原因是这些库或框架的代码不开放，出现问题以后，在COM与调用代码之间就形成了无法跨越的障碍。到底是COM的局限？还是我们代码写的有问题？无法进一步跟踪下去，只能想方设法的查找MSDN或者修改COM相关的代码。我就遇到过COM延迟二十几秒的恶心问题，频繁的调用接口的初始化就会导致COM初始化的失败，大约要停止20多秒。这应该是类似于内存碎片这样的问题，就是不能频繁调用new/delete申请释放小块内存，具体原因应该是操作系统自身的毛病，可是不能修改COM方面的代码，只能想法修改自己的。

    有人看过Windows2000泄漏出来的代码，里面大多数都是用c写就。也就是说，没有c++的继承多态，当然更不可能有什么COM了。主要的原因应该不难猜测，C++与COM不可控制的东西太多了，而对于操作系统来说，不可控制因素的存在是致命的。当然，对于应用软件来说，这些就不太算是问题，不过用的不熟练的，还是不如不用。（我也见过用的相当熟练的设计方案，简直是帅呆了，自叹不如啊，比如custom moniker，没听说谁用过，潘爱民的书里介绍的也是简单，但是我们一个组件里就大量的使用了这些高级的COM概念，而且设计相当稳定）

    回到boost这个话题，如果大连campus有C++标准库的大牛，使用boost肯定会提高代码质量，提高开发水平。但是现状是大家对STL用的都不熟，如果加上Boost，那只能是另一个噩梦的开始。另外，boost毕竟不是标准，稳定性和向后兼容性要差一些，这对于商业软件来说，都是值得仔细考虑的地方。

    我的建议是用熟STL，在熟练的基础上再去尝试Loki或者Boost，但是不要将其引入legacy project，可以把它用在一些单独组件中，将其不可预知的风险降低到最小。

    这也只是想想而已，就如郭德纲说的那样，谁认识我呀。

  • 宝宝网站更新记录

    删掉了某些链接，因为对等原则。
    另外，移动了部分链接到“友情链接”页面。

    加入“最新更新”功能，大家可以到这里来看
    友情链接的最新更新

    有些朋友没有列在里面，那是因为没找到RSS Feed链接，如果您有这个链接，请回复通知我，一定加上。像是菲菲妈妈放在了iyaya主页，我也没有找到，真是抱歉了，希望以后有机会开发一个专门的程序。

    下一步打算还是丰富宝宝主页的内容，适当地做一些搜索引擎优化（SEO）。因为现在看统计，大部分还是从baidu或者google来的。

    因为流量并不大，所以爸爸的技术笔记和妈妈的育儿日记还是会间杂在一起，或许合适的时候还是要另开blog的好，那样结构更清晰，现在日平均独立ip大概一百至二百左右，暂时还不动。

    妈妈没有时间写，其实现在关于育婴方面的文章很受欢迎，她写的关于如何让宝宝晚上睡得好，带来了不少访问量呢。

  • 周杰伦真tmd火啊

    今天收到了网站服务商的邮件，说我网站上某个目录的访问导致了服务器的崩溃，然后把我这个目录给停掉了。
    于是登陆上去找原因，主要就是查流量，一看周杰伦《霍元甲》的下载两天竟然达到了20多G，幸好现在流量足够。
    没法，删掉这首歌。