00000029.htm

一份很好的linux入门资料

&nbsp;&nbsp;个假设都错了。&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;首先,编写用于出售的代码只是编程行业的冰山一角.在微机世界前期,大家普遍认&nbsp;<BR>
&nbsp;&nbsp;为世界上90%的代码在银行和保险公司内部编写.这虽然已经不再是事实--现在其&nbsp;<BR>
&nbsp;&nbsp;他行&nbsp;&nbsp;业也越来越加大了软件开发的力度,金融行业所占的比例从而下降--但是短&nbsp;<BR>
&nbsp;&nbsp;期内我们仍将会看到大约95%的代码是公司内部编写.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;这些代码包括大多数为中等或大规模公司所定制的MIS,金融和数据库软件.&nbsp;<BR>
&nbsp;&nbsp;包括象设备驱动这样的专业技术代码(几乎没有人靠卖设备驱动赚钱,这一点我&nbsp;<BR>
&nbsp;&nbsp;们将会在后面讨论);包括日益增长的数控机器的各种嵌入式代码--从机械工具&nbsp;<BR>
&nbsp;&nbsp;和喷气客机、汽车、微波炉甚至烤面包炉.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;大多数这种内部代码与其环境集成在一起，复制和再利用十分困难(不论环境是&nbsp;<BR>
&nbsp;&nbsp;商业办公室的程序套件还是联合收割机的加油系统)。因而一旦环境变化,需要做&nbsp;<BR>
&nbsp;&nbsp;许多工作使软件与之同步.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;这种工作称为&quot;维护&quot;.任何软件工程师或系统分析员都会告诉你这就是程序员的大&nbsp;<BR>
&nbsp;&nbsp;部分工资的来源(超过75%).因此,大多数程序员工时花费在编写和维护更本不能卖&nbsp;<BR>
&nbsp;&nbsp;的内部代码上(当然大多数程序员以此为生)--读者们也许乐意去查查报纸上的&quot;诚&nbsp;<BR>
&nbsp;&nbsp;聘信息&quot;部分的编程工作列表检验一下.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;我强烈的希望读者试试浏览本地报纸的招聘信息,看看编程.数据处理,和包含&nbsp;<BR>
&nbsp;&nbsp;软件开发工作的软件工程项目等等.将这些工作按照其目的是使用还是销售进&nbsp;<BR>
&nbsp;&nbsp;行分类,你将深受启发.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;很明显,即使为&quot;销售&quot;定义了最大范围,20人中还是至少有19个由使用价值资助&nbsp;<BR>
&nbsp;&nbsp;(作为产品中间价值).这就是为什么我们认为软件工业中以销售价值驱动的部&nbsp;<BR>
&nbsp;&nbsp;分只占5%原因.注意,本文中其他部分的分析并非完全倚赖于这个数;即使这个&nbsp;<BR>
&nbsp;&nbsp;数字达到15%甚至20%,在经济上的推论结果仍然八九不离十.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;(当我在技术讨论会上演讲时,我经常由讨论两个问题开始:听众为写软件付多&nbsp;<BR>
&nbsp;&nbsp;少钱,和有多少薪水是依赖于软件的销售价值的.第一个问题应者甚众,而第二&nbsp;<BR>
&nbsp;&nbsp;个问题则寥寥无几,大而且量的听众对这个问题十分诧异)&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;其次,经过对实际客户行为的调查,软件销售价值与其开发和升级成本相关的理&nbsp;<BR>
&nbsp;&nbsp;论很容易被推翻.开发和升级成本相关的商品(对打折之前来说)占很大比例--食品,&nbsp;<BR>
&nbsp;&nbsp;汽车,机械工具，甚至有许多无形的产品--例如,音乐、地图或数据库资料的复制&nbsp;<BR>
&nbsp;&nbsp;权.这产品在生产者倒闭后仍然能保持甚至增加其销售价值.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;与上述形成鲜明对比的是.当一个软件产品生产者歇业时(或者如果产品开发被终&nbsp;<BR>
&nbsp;&nbsp;止),几乎没有客户愿意为其花钱,而不管它理论上的使用价值或同样功能产品的开&nbsp;<BR>
&nbsp;&nbsp;发费用有多高.(要检验这个说法,去你附近的软件商店打折柜台看看吧:-))&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;在生产者失败时,零售商的行为很有启示.他们知道一些生产者不知道的东东.他&nbsp;<BR>
&nbsp;&nbsp;们深知:客户愿意花费的价格在很大程度上由卖主未来可以提供的服务决定.(这&nbsp;<BR>
&nbsp;&nbsp;里的'服务'被广义的理解为完善,升级和后续产品).&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;换句话说,软件主要是一个稳定的服务性行业,认为它是制造性行业是没有理由的&nbsp;<BR>
&nbsp;&nbsp;错觉.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;另外,检查一下我们为什么会有这些惯性思维也很有益处.它们也许来自于软件生&nbsp;<BR>
&nbsp;&nbsp;产者大力宣传的销售类产品,这些是的软件业一小部分,也是宣传的唯一的一部分,&nbsp;<BR>
&nbsp;&nbsp;大多数明显和重头的广告宣传的产品是昙花一现的短期产品,就像游戏,他们几乎&nbsp;<BR>
&nbsp;&nbsp;不需要提供后续服务(合同规定的除外)&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;另外,值得注意的是,制造业错觉所倡导的价格体系事实上会越过保持开发预算&nbsp;<BR>
&nbsp;&nbsp;不崩溃的底线.既然(像一般认为地)超过典型软件产品周期花费的75%在维护,&nbsp;<BR>
&nbsp;&nbsp;调试和扩展上,那么通常的那种只采用高额售价,极低相关服务费用的定价策略,&nbsp;<BR>
&nbsp;&nbsp;只会导致各方面都差的服务.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;用户的损失在于,即使软件是服务性行业,工厂模式促使生产者减低服务质量.如果&nbsp;<BR>
&nbsp;&nbsp;生产者靠出卖比特挣钱,大量的努力是制造比特并将它们推销出门;帮助服务部分,&nbsp;<BR>
&nbsp;&nbsp;因为不是利润的中心,将会成为只付出的一点点努力和资源,为了避免激怒用户所设&nbsp;<BR>
&nbsp;&nbsp;的垃圾站.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;另一方面是大多数生产者使用这种工厂模式会导致长远的失败.&nbsp;为满足无限的&nbsp;<BR>
&nbsp;&nbsp;售后服务和技术支持需要的固定价格产品提供资金,只有在那些膨胀足够迅速的&nbsp;<BR>
&nbsp;&nbsp;市场里&nbsp;&nbsp;--其过去的销售和未来的收入能够满足支持和生存周期的花费--才能存&nbsp;<BR>
&nbsp;&nbsp;活.一旦市场成熟和销量下降,维持生计,大多数生产者除了消减单独产品的开支&nbsp;<BR>
&nbsp;&nbsp;之外没有别的选择.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;不管是直接(废止产品)还是间接(支持很差),都会把客户推给竞争对手(因为这些&nbsp;<BR>
&nbsp;&nbsp;行为损害了依附于服务产品的期望值).短期来看,可以通过将修订过bug的版本发&nbsp;<BR>
&nbsp;&nbsp;布为新产品避免这个陷阱.而长远来看,避免陷阱的唯一可能是对行业进行有效的&nbsp;<BR>
&nbsp;&nbsp;市场垄断.最终,只有唯一的幸存.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;事实上,我们一再的看到这种缺乏支持的模式害死一些市场环境中很强大的竞争者,&nbsp;<BR>
&nbsp;&nbsp;(这种模式对那些那些经历过计算机发展史幸存下来的人尤其深刻,包括个人操作系&nbsp;<BR>
&nbsp;&nbsp;统,字处理,通用财务程序或商业软件).这种不正确的动机来自于工厂模式导致的&nbsp;<BR>
&nbsp;&nbsp;赢家通吃的态势,而且最后即使你是赢家的客户也会遭殃.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;如果不是工厂模式,那又是什么?为了有效的控制软件生存周期真实的花费体系&nbsp;<BR>
&nbsp;&nbsp;(同时在经济学和非正式场合的意义上的&quot;有效&quot;),我们需要一个建立于服务合同,合&nbsp;<BR>
&nbsp;&nbsp;约,和买卖双方持续交易基础上的价格体系.所以,在以效益为目的的自由市场条&nbsp;<BR>
&nbsp;&nbsp;件下,我们能管窥大多数成熟的软件工业最终遵循的价格体系.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;为什么说开放源码软件的地位日益增长,不仅仅是技术,也是经济上对主流秩序的&nbsp;<BR>
&nbsp;&nbsp;挑战?上述内容给我们一些启示.软件开发的&quot;free&quot;,会将我们推向以服务支配的&nbsp;<BR>
&nbsp;&nbsp;世界,同时暴露出一直依赖销售封闭源码产品的方式有多脆弱.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&quot;free&quot;的概念很容易被误解为其他含义。降低产品花费会导致支撑软件业的&nbsp;<BR>
&nbsp;&nbsp;整个基础投入增长,而不是降低。只有汽车的价格降低时,汽车的需求才会上&nbsp;<BR>
&nbsp;&nbsp;升--这也是为什么在开放源码世界中,另外那5%的根据销售价值付酬的程&nbsp;<BR>
&nbsp;&nbsp;序员不好受的原因.在free的变革中,有损失的不是程序员而是那些没看清形&nbsp;<BR>
&nbsp;&nbsp;势而将赌注押在封闭源码策略上的投资者。&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;4.&nbsp;&quot;信息应该免费&quot;的神话&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;与工厂模式错觉相呼应的是,思考开放源码经济的人们还常常被另外一个&nbsp;<BR>
&nbsp;&nbsp;神话搞糊涂.那就是&quot;信息应该免费&quot;.这常常以数字信息产品的复制边际&nbsp;<BR>
&nbsp;&nbsp;成本几乎为零来解释,这个解释暗示了其价格似乎就应该为零.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;其实你只要考虑一下诸如藏宝图,瑞士银行的账号口令,或计算机服务的确认口令,&nbsp;<BR>
&nbsp;&nbsp;等等信息的价值,就很容易看破这个神话.即使这些确认信息可以不用任何花费的&nbsp;<BR>
&nbsp;&nbsp;复制,但是被其确认的对象无法复制.也就是说,非零的边缘成本由被那些确认信&nbsp;<BR>
&nbsp;&nbsp;息继承下来.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;提到这个神话的主要目的是声明它与开放源码的经济价值的讨论无关;就象我&nbsp;<BR>
&nbsp;&nbsp;们在后面将会看到的,即使假设软件是符合制造业产品(非零)价值结构,仍是如此.&nbsp;<BR>
&nbsp;&nbsp;所以我们没必要钻软件是否应该免费的牛角尖.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;5.驳斥公用悲剧说&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;质疑主流模式,看看我们是否能建立另一种模式----对是支撑起开放源码协作的原&nbsp;<BR>
&nbsp;&nbsp;因作出有力的经济学解释.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;这个问题需要从两个不同的方面考查.一个方面是我们要解释那些为开放源码作出&nbsp;<BR>
&nbsp;&nbsp;贡献的人士的个体行为;另一方面,我们需要理解那种支撑象Linux和Apache这样的&nbsp;<BR>
&nbsp;&nbsp;开放源码项目的经济力量.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;Hardin的著名寓言告诉我们:设想一个乡村农夫们拥有一片公用绿地.他们&nbsp;<BR>
&nbsp;&nbsp;在那里放牧牲畜.但是放牧使公用性退化,撕裂草皮,留下泥泞,很难恢复.如&nbsp;<BR>
&nbsp;&nbsp;果没有对分配放牧的权利达成协议(或约定)以防止过度放牧;所有牧主都还&nbsp;<BR>
&nbsp;&nbsp;会赞成尽可能快的增加牲畜数量,以便在公共绿地变成泥潭之前榨取最大的&nbsp;<BR>
&nbsp;&nbsp;利润.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;大多数人使用象这样的直觉的合作模式.这事实上并不是对开放源码--他们是(供&nbsp;<BR>
&nbsp;&nbsp;不应求的)自由骑士,而不是(被过度使用的)过剩的公共货物--经济问题的正确判&nbsp;<BR>
&nbsp;&nbsp;断,不过,我在大多数未充分考虑的反对声后面都听到过类似的看法.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;公共拥有的悲剧预言只会出现三种结果.一种是泥潭;一种是为了村民的利益,强制&nbsp;<BR>
&nbsp;&nbsp;性的使用某种分配协定(共产主义的解决方案);第三种是公用被打破,村民各筑藩&nbsp;<BR>
&nbsp;&nbsp;篱,保护自己的一小块草地(私有制的解决方案).&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;当人们本能的的将这种模式应用于开放源码合作时,因此预计它只有很不稳&nbsp;<BR>
&nbsp;&nbsp;定的短暂的半衰期.因为没有明显的方法去强制在互联网上工作的程序员执行工&nbsp;<BR>
&nbsp;&nbsp;作时间分配策略,这种模式就断言公用将会打破,结果是出现各种各样的封闭代&nbsp;<BR>
&nbsp;&nbsp;码软件和反馈给公用的工作量迅速减少.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;事实上,经验清楚的显示出了与之相反的趋势.开放源码开发的广度和深度(由&nbsp;<BR>
&nbsp;&nbsp;Matalab和freshmeat.net的每日宣布的数据统计)在稳定增加.很明显,这些都得出&nbsp;<BR>
&nbsp;&nbsp;&quot;公用悲剧&quot;模式无法描述事态的发展.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;答案的一部分正是建立在软件使用并不降低其价值的事实基础之上.实际上,对&nbsp;<BR>
&nbsp;&nbsp;开放源码软件来说,当用户被其修正和特性(代码补丁)把握之后,软件的广泛使&nbsp;<BR>
&nbsp;&nbsp;用还会增加其价值.公用悲剧被颠覆了,越放牧,草长得越高.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;答案的另一部分是基于很难收取那些为公用源码基础所作的小补丁的市场价值.&nbsp;<BR>
&nbsp;&nbsp;假设我为一个恼人的bug写了个修正,而且有人认为这个修正值钱;我如何才能&nbsp;<BR>
&nbsp;&nbsp;从那些人手里拿到钱?对于这种小额的,通常也是适当的付款,常规的付费体系&nbsp;<BR>
&nbsp;&nbsp;如此昂贵竟成为真正的问题.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;比起价钱不仅仅很难收取,也许如何定价还要难得多.让我们想一想,假设互联网&nbsp;<BR>
&nbsp;&nbsp;上已经拥有理论上完美的小额付费系统--即安全,方便,又不需要更多手续费.而&nbsp;<BR>
&nbsp;&nbsp;你写了个补丁叫做&quot;Linux内核的某某修正&quot;.你该要价多少?在潜在购买者还没看&nbsp;<BR>
&nbsp;&nbsp;到补丁时,他们又该如何判断值不值得为它付费呢?&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;我们的问题就像F.A.Hayek的&quot;计算问题&quot;在哈哈镜中的变形--它就象个超市,即要&nbsp;<BR>
&nbsp;&nbsp;估价补丁的功能值多少,又要相信定价是合理的以促进交易.&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;不幸的是,超市方式有一系列的不足,所以补丁的作者----打补丁的黑客有两种选择:&nbsp;<BR>
&nbsp;&nbsp;躺在补丁上收钱,或免费扔出去.第一种选择将一无所获.第二种也可能如此,不过&nbsp;<BR>