Feb 26
以下是转自我同事(dorisbhwang)的一片文章,凤凰项目读后感在发此博客前我本人还没有看,但在看了她读后感后更有兴趣来读一读这本书。



凤凰涅槃,浴火重生
正文之前,一个职场老司机的困惑…..
作为一个在职场上混迹长达14年的老司机,从制造业的咨询顾问转变为互联网行业运维质量管理人员(QA),对于我来说可谓是破釜沉舟,从零开始。理想是丰满的,现实是残酷的,投入到具体的运维质量管理工作后,发现我无法再以这么多年沉淀的方法论,以体系化、职业化的姿态来开展工作,尤其是对互联网行业运维体系的生疏,技术上的空白,简直就是致命的…
在困惑无助的瓶颈期,偶然机会运维界男神梁爷推荐看《凤凰项目》这本书,凤凰二字不禁让我想到了凤凰涅磐,浴火重生,自己此时需要的不就是重生吗?既然从零开始,放手一搏,学习吧!
言归正准,此书与各种介绍技术或方法论的书不同,以一个故事的形式讲述了一个IT项目从即将“流产“、IT运维部门面临被拆分的囧境到逐步的通过一系列举措取得项目成功并实现业务价值的过程,浅显易懂,结合自己曾经经历的“难产”的项目(广东电信管线投资管理系统建设项目、HW配置器项目、HW PIA项目),仿佛身临其境,触动了身体上的多根神经,将触动我的几点总结下:

1、  变更管理
提到“变更”,我为之色变,变更无处不在,毫不夸张的说,我曾经被“变更”伤的很深,这是个忧伤的往事,此处省去一万字…首先为愿意正视在变更上存在的问题,并且愿意去为改变这种现状做出努力的管理者或决策者致敬,书中IT运维总裁比尔如是乎,接任总裁一职后,意识到IT变更中的问题,马上对变更流程做了梳理,
采取了如下的措施:
1)  梳理什么是变更,明确变更的范围(这与我想做的工作不谋而合)
附书中定义:变更就是对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作,并且这样的操作可能对相关服务产生影响。
2)  执行变更审核流程,加大变更门槛,适当控制变更节奏;
说到这点,不得不提任何流程及工具的推行都会遇到各种阻碍,有些员工乃至管理者甚至可能认为引入流程阻碍了效率,如果再碰到了不好用的工具,那简直炸天了,所以引入流程和推行工具之前必须根据实际情况做深入的调研,多方面平衡,力求流程简化,工作易用,当然这事说起来容易,做起来难,也只能是智者见智了。
3)  变更可视化
做好变更记录,明确变更计划的制定者、变更对象、变更内容;
做好变更计划安排,发布审批通过的变更执行的日程表。
这一点其实没什么好说的,既定的工作如果都不做好安排,随着性子想怎么玩就怎么玩,活该你一天到晚忙到死,还没干成几件事情。
总之,我们避免不了变更,但我们要想办法避免紧急变更。
说到此处,我脑中呈现了一个变更管理的框架:
点击在新窗口中浏览此图片
首先从业务层面要确定变更的痛点,想要如何管理,以上内容不需要面面俱到,可以根据痛点有重点的进行梳理,如果有条件,落地到工具中自然更好。

2、  工作类型梳理
记得我当初刚接手运维部门的QA工作之后,为深入了解运维工作,曾问过几个运维同事的日常工作分类和职责是什么,小伙伴们给的答案居然是含糊不清的,我不知道他们是真的不清楚,还是不善于总结说不出来,抑或是不想告诉我,囧…书中对IT运维部门的工作类型分为:业务项目、IT运维项目、变更及计划外的工作。人的精力是有限的,当各类工作一窝蜂的摆到眼前,谁也不能面面俱到,必要时必须要有取舍,确定不同时期的重心工作,正确的时间做正确的事情。结合实际的工作,身边运维同学对于业务项目和IT运维项目这两类一般能按照项目节奏按部就班的走,但一旦引入了变更和计划外的工作,往往会打乱既定的计划,承诺给业务部门的服务无法完成,所以工作的安排要留一定的buffer,以支持没完没了的变更和计划外的工作(如业务各种突发事件,各类运营系统的bug) 。希望这个工作类型的划分也能够触动身边运维同学的神经。

3、  开发运维模式下的实践
1)标准化
“IT工作不仅是无形的,因此更难追踪,而且可能出错的地方也要多得多。“
因此为了避免出错,需要更严格和守纪律,把运营环境标准化,并把这些标准应用于开发和运维的日常使用。写到这里,情不自禁叹口气,这是我目前的重点工作,曾经为这个目标迷茫过、困惑过,此书看完,坚定了我做运营标准化工作的决心。
2)持续优化
作为质量部过程改进中心的一员,持续优化天然是QA的职责,如何防止问题再次发生,一旦发生了问题如何更快的发现和修复问题,建立完善的问题管理机制的重要性由此可见。
3)营造一种工作文化
鼓励探索和尝试,从失败中吸取教训,反复实践,至于如何落实,我想是团队管理者仁者见仁智者见智了。  

4、  工作约束点
在书中,一个运维工程师是工作约束点,任何工作少了他都无法正常开展…我表示无语,居然会有这样的事发生!在我的经历中,某个人成为工作瓶颈的情况真不多见,不会说少了哪个人天能塌下来。我想团队分工、团队共享和人力储备这些是人员管理的根本吧(纯属个人意见)。 诚然,除了人这个因素,工作中会有各种障碍,反思下我们是否主动识别过约束点,如数据质量差、信息不同步、流程混乱等,识别到之后是否尝试去打破它?至于How,以后再深入学习探讨吧(偷个懒)。

Ok, 到这心得就完了,对于如何继续开展接下来的运营质量工作,我经历了从混沌状态到逐步清晰的过程,可谓是“凤凰浴火,涅槃重生”,路漫漫其修远兮,希望通过我的努力,能够看到质量上的不断的改进和优化,哪怕是一点点。



Jan 19
作者:研究僧
文章地址:http://blog.puppeter.com/read.php?52

项目时间:201603-201608

通常做项目标方向和理想是非常好的,但现实总有这样那样的问题,如以下截图。 所以引出本文在做项目中发现的一些问题:
点击在新窗口中浏览此图片

开篇
      腾讯SNG(社交网络事业群,后简称“SNG”)事业群担负着QQ、Qzone、QQ音乐和相册等核心社交产品运营,从运营的这些产品就能看出部门的历史。笔者没有进入腾讯前在北京工作过多年,记得在2010左右北京的各种IT大会风起云涌当时可以看到各大公司分享自己的架构与运维理念但很少能看见腾讯的分享,当时很纳闷为什么看不到腾讯分享,多年后走进腾讯当年很多疑惑慢慢揭开了神秘的面纱。  
      从架构层级上腾讯和很多公司相同即接入、逻辑和存储但腾讯BG(Bussiness Group 事业群,后简称“BG”)制,外人可以理解BG为腾讯内部子公司,彼此有独立的方向、业务与架构,不同的BG架构不同(接入、逻辑和存储), 与其他公司不同的是,腾讯在各BG架构上又多了一层“大存储”,这里大存储指各BG数据最终落到统一的BG下,即TEG(技术工程事业群)。以SNG为例接入使用qzhttp(web服务)逻辑之间调用关系用了l5(名字服务),程序开发有spp框架, 数据间传输使用了私有协议,存储使用了MySQL和一些自研的数据存储,可以看到腾讯这里走出了一条有自己特色的道路,它更多使用的是自研组件和私有协议,这也就解释了之前笔者的疑惑为什么很少看见腾讯的分享原因。相比很多公司使用开源组建在基础上做二次开发,但腾讯更多是学习开源组建再开发,区别是后者配置文件些许区别维护学习上有一定成本,但优势更加适合业务使用,足够的轻量级和安全,但问题是业务的需求量有限很多自研组建放慢迭代脚步,甚至停滞迭代为业务发展埋下隐患。
     那为什么腾讯内部的工具不走开源路线呢? 开源接受的市场更多的需求,需要持续的打磨与迭代, 这问题也是笔者在入职腾讯后一直的疑惑 直到一次公司技术分享A同事的一个问题,A同事大概问的意思是腾讯现在在互联网行业内有一定的影响力与同等公司相比开源做的并不是很好,这是为什么? 当时公司CTO(首席技术官,英文Chief Technology Officer,即企业内负责技术的最高负责人)张志东是这样回答的。首先对A同事问题的肯定,也介绍了这里的背景,早年腾讯业务爆发式增长工程师更多的精力是应对需求以及当业务发生故障时去救火,再者考虑的就是开源软件对数据安全的问题,如果本身能力未达到应用开源软件后遇到风险不能快速解决结果是致命性的。 这两点笔者身有体会特别是随着互联快速发展,网络安全很重要网各种暴库(csdn 索尼)等事件,做过一个公司的CTO需要更加关注用户数据的安全,这也是我们公司的底线用户安全置上。但Tony也说随着腾讯各个业务步入正轨、技术的沉淀和人才的储备,我们也逐渐考虑去做一开源的工作,鼓励各BG开源。老板的一句话给我们带来更多的思考是如何去开源? 而开源的前题也是如何更好的使用开源的工具在基础上有机会再开源,所以当时笔者也在想自己的业务上去寻找一些场景适合开源工具的解决方案。

Docker缘
    2014年什么最火,相信很多人会说是Docker ,它诞生于2013年,感觉它的诞生就是一鸣惊人且有不断蔓延趋势,国内很多技术分享也谈了很多Docker的发展趋势应用案例等。2014年底笔者接手了一些长尾业务,由于部门对机器低负载考核比较严格,所以当时也试着将一些高负载业务与低负载业务进行混合部署,混合部署、虚拟化是很多公司解决成本问题的一些手段,像网上经常看到Google很早之前就在用容器技术来实现业务间的混合部署, 当时公司也有很多BG以各种方式实现了不同业务间的混合部署,而由于SNG历史背景的原因很多业务还没有实现混合部署。笔者当时负责系统运营情况,在没有隔离情况下的这种混合部署方案并不好,因为高负载与低负载的业务混部在一起特别是晚高峰期一个大CPU毛刺就会影响到低负载业务从而导致线上投诉,所以在2014底和2015年初借鉴了其他BG的玩法,在部分场景下我们开始通过Docker来实现我们业务间的混合部署,实践证明这种混部要比前者更好,经过2015年一整年系统的开发与迭代初见规模,我们内部称呼为“琥珀离线系统”把高负载业务与低负载业务混部同时,也将高负载业务部署到了部门与公司的Buffer、数据库备机和低负载等资源上,如果业务使用Buffer资源系统,通过建设的系统能力可以将业务请求迅速的从Buffer上调走, 就这样我们把部分业务迁移到了Docker上。
   2015年下半年到2016上半年社交类业务出现了很多转码的需求,转码是用户从PC上传视频通过服务器进行格式与码率的转换在其他终端(ipad,手机)上都能看到,通过我们Docker + Buffer 、低负载形式再次解决了这类业务的需求,为部门解决了大量的成本,Docker离线再一次进入应用的小高峰。
  这时老板们也提出了更高的要求,是否可以实现在线的Docker化,毕竟离线底层用的是Buffer 、低负载资源是有一定天花板的,因为在海量运维中这些资源占比可能连10%都不到,2016年上半年我们开始做在线Docker研究。
   我们做了内部的研究与需求调研,在过程中也经过N轮的PK有人同意有人反对,记得有次一位同事说我们的运营效率可以在分分钟扩容千台机器,什么上Docker?
   答:因为,Docker宣称(Build, Ship and Run Any App, Anywhere!) 它通过镜像串联了开发的整个路径,并保障线上的一致性,你可以把镜像看作App,它可以运行在内部云和公有云上,方便业务以后在各种云上快速的拓展。
   同事:那织云(内部运营系统)在打磨一下也可以实现类似的这功能,为什么还要上Docker?
   答: 额。。。。
   其实当时笔者心里的想法是,是啊其实我们早实现这功能再稍改造就可以,但为什么火的不是腾讯SNG的织云而是Docker呢? 值得思考。。。
   最终还是决定试探性的来用Docker管理在线服务,Docker这么火而且已经有成功的内部案例,但为什么是试探性这么没底气?
   开篇的时候讲过我们有很重的历史背景,在这种历史背景下没有最牛逼的工具,只有最适合我们的工具,很多创业公司把Docker玩得转因为没有任何历史的包袱,所以这里我们只能说是试探性来玩Docker,看它是否符合业务需求,还有另外还有一些原因:
          1. 刚的对话中已经说明了,内部运营系统早就支持了类似镜像功能,为什么还火的不是织云而是Docker ? 3分产品7分也运营,我想这也是Daocloud(Docker母公司)把Docker当作产品去做,所以这是我们值得学习的。
          2. 很多公司都在搞Docker,当一个新员工入职,你和他说织云,他会问什么是织云,但你说docker很多人会知道,所以不管什么技术,如果他能形成一套“协议”就会让彼此间更好的去沟通。
          3. 内部虚拟化也应用了Kvm,做弹性扩缩容Docker比Kvm更加的轻量级,在社交类业务中镜像有突发流量增长和计算的场景都很适合用Docker。
          4. 部门的运维的质量、效率、成本和安全都做的非常好,如果能以得分衡量应该是98分,但是对追求极致的我们需要的是100分,所以我们要关注开源产品、使用开源产品来寻找自研产品的不足
          5.  笔者曾经看过一篇文章《 为什么要探索宇宙》 文章大意(文章地址见参考):
          1970年,赞比亚修女 Mary Jucunda 给 Ernst Stuhlinger 博士写了一封信,他因在火星之旅工程中的原创性研究,成为 NASA(美国航空航天局)Marshall 太空航行中心的科学副总监。信中,Mary Jucunda 修女问道:目前地球上还有这么多小孩子吃不上饭,他怎么能舍得为远在火星的项目花费数十亿美元。结论是探索宇宙可以带来相关产业的发展,太空探索就像一面人类审视自己的镜子,利远大于弊。
   相信探索在线Docker与为什么要探索宇宙是一样的,我们他做整个过程当作我们的镜子审视自己系统的不足,并推动改进。

探索在线Docker起航
     从中心下各组抽了一些热心同事,2016年4月份开工在线Docker。 作为运维最不好管控的就是时间前一秒在做项目,突然一个故障立即处理,处理完回过来忘记从哪开始做起刚有头绪又收到新的需求,所以我们需要一套管控手段来保证项目的目标与进度。首先,时间上每个人每天拿出30%来搞项目,其次我们引入了Scrum(敏捷开发框架) 来管理项目, 它的好处就是能在一段时间内,有一个共同目标,大家向着目标不断的跟进持续打磨,信息尽量的彼此间透明,最终保障短期目标与质量。
    前期很多事物在探索阶段整体看Scrum带来的收益还是不错的,我们发现了很多问题,这里有Docker本身问题、还有也有部门运营系统问题低层系统的问题,在线系统上线了300+ 容器运行过程中Docker本身并没有太大的问题。 一个小插曲一台母机上运行了多个容器,其中有的容器是测试机有的容器是在线服务器,某工程师登录测试容器修改了系统时间,由于Docker隔离型不是十分的好,导致整个母机时间都被更改影响各业务,这并不影响在线Docker持续探索,但也提醒我们如果拿整套在线Docker技术方案来做一个产品的化,我们需要一个产品的准入的规则,譬如小明家买了一个洗衣机,洗衣机对小明来说是一个产品,小明并没有看洗衣机的说明说就把衣服放入洗衣机,最终衣服大于洗衣机承载重量导致洗衣机的报废,同样在线Docker也需要一套说明书即准入规则、注意事项、测试过程中发现的问题、案例和潜在风险等,如果超出了准入规则的不准许接如,否则与洗衣机的结局是差不多的。
    运营了一段时间Scrum我们也发现了一些问题, Scrum可以解决一个小团队的问题,但我们需要依赖其他团队时从效率上看就没那么好了,如果Scrum两周为一周期,小团队在一周期内可以解决10件事,而涉及到依赖就只可能解决一件事,因为每个团队有自己的重点及KPI,遇到这种情况Scrum也是无能为力 。

小团队作战
      像Scrum应用中发现他解决不了的问题的案例,在一个大的公司中更多的讲究是团队作战群策群力一个需求来了后对他做需求分析,并拆分需求分给不同团队提升需求的效率和质量。每个部门,每个团队,每个人都是有KPI (关键绩效指标 ,英文全称 “Key Performance Indicator”),KPI的优势是不同环节认同一个目标并持续推进保证收益, 团队与团队之前的协作如果KPI是一致的那事情推进会非常顺利反之只能像Linux进程一样陷入中断状态。
      在这样背景下Scrum可以很好的解决小团队KPI目标、进度、质量,但与其他部门或组交集太多就无能为力了。在线Docker正是这样情况,当你申请其他团队资源时,在KPI的背景下首先被问的目标与收益是否明确,也正因为是探索型项目这些问题很容易被挑战,更多的时间在PK目标与收益。但要知道Google的GFS最初也只有三个人设计开发出来的,所以这种探索型产品前期需尽量少的人参与,与其他团队尽量的解耦 ,短期带来的问题可能是系统的重复建设,长期的收益是整个生态链质量的提升是值得的。笔者也在想Docker离线为什么会成功? 原因也是开始团队比较小很多问题在内部可以很快的解决,时间上保障项目进度,同时也令大家的成就感更愿意去投入。

设立项目标及流程负责人
    经过一个月的试探,到5月底我们大概掌握了业务Docker在线相关系统的一些问题,解决问题同时也在并行实现Docker在线系统的产品化。 开始讲过参与Docker在线同学来自不同组,结合自己的业务大家从不同的视角希望Docker能带来更多的改善。其实大家的目标是一致的做Docker在线,但过抵达目标的过程却有很多分歧,有分歧是好事做一个产品如果连分歧都不没有就太没成就感了,但此项目就是分歧太多了且都有道理,怎么办?
   解决分歧更好的方式是拿案例来表明自己的想法正确的。PK案例:
   现有流程 : 测试-> pkg (软件包管理系统) ->预发布 -> 线上系统
   改造流程:  测试机-> pkg ->预发布 (构建镜像机) -> 镜像仓库 -> 线上系统
   旧系统问题:历史原因导致 od未分离,开发可以任意登录线上系统导致系统配置不一致,当预发布环境有问题时,可以任意选择线上机器配置反录入到pkg系统再次发布,相当于给od为分离打了一个补丁。
   改造后流程 : 预发布构建镜像后,由镜像保持整体链条环境一致性 。但历史原因导致我们的用户(运维/开发)习惯,扩容时是任意选择一台参考机来发布的,分歧就是改造后流程省略了选择这一步,而且首次选预发布机器后为了保障镜像里垃圾信息最少,后续不可以更改预发布机器, 有的同学就会疑问为什么不保持原有习惯?预发布机故障怎么办? 就这样一个案例PK了多次,最终还是保持改造后的流程方案。
    PK是有必要的,但多次PK就会拉长战线和时间,再加上各种需求就会导致小团队每天很忙接需求,PK需求一段时间过去并没有什么起色,大家对项目的成就感也会打折。Docker在线项目成员来自不同的组,大家一起搞Docker在线形成了虚拟组,其实开始我们就忽略了虚拟组的技术负责,经常出现意见不一致开会PK没有结果再PK浪费时间的情况。有了技术负责人后,它来帮我们屏蔽不合理需求,当遇到问题不断PK时能及时站出给出方向加以解决,保障短期目标,同时提升大家项目中的成就感。
   每天晚上5:00大家都需要碰头沟通Docker在线的进度与问题,有意思的是经过一段时间大家都认为自己负责的环节已经OK了,但整体串联起来就有问题。我们分析了一下原因原来是这样,我们每个人负责的是在线Docker生产链上的一个环节如图1,一个在线Docker包含了多个环节,当自己负责的环节流程1没有问题也就确认自己是没有问题的,结合之前的结果看并没有什么问题。 但成功并仅仅需要自己的成功还要确保自己下游、下游的下游全部成功才可以,所以需要每个人对系统的流程负责,当自己的环节或自己下游环节出现问题需要主动把问题抛出来,同时尽快推进问题的解决。
点击在新窗口中浏览此图片
图1,生产链

用数据来证明
     5-6月底我们通过运营系统在逐步小规模上量验证Docker玩法的可行性,但是随着时间推移发现量并没有快速的上升,原因是资源有限每天在串行的上量,系统的扩容流程一旦发生问题只能停滞待问题解决后再继续。开始感觉经过一段时间量没有上去,没有上去的原因自己也说不清楚,所以当时一直在思考为什么自己也说不清楚,因为流程不稳定错误每天都在发生,每天发生完当时解决完就完了,没有沉淀数据也看不到全局数据能看到哪里的问题比较多。 邮件是一个很好的工具针对这种情况,我们沉淀了所有的日问题数据,并在每周5进行分类汇总,对分类后的结果进行排序,并根据排序的原因设定负责人推进。 经过一段时间数据的沉淀大概能分析出一些问题主要分两类:
1. 运营系统设计的目标和准入标准
     1.1 部门之前一直在提一键运维,从这个目标上看运营系统确实已经达到了,但Docker的扩缩容目标更多的是无人值守运维,目标显然是与目前项目不契合的导致在上量过程中遇到了很多问题。
     1.2 我们运营系统设计过程中的一个重要环节借鉴了Unix设计哲学中的思路,即一切接文件,通过管道来串联文件的输入和输出关系,这也说的是我们运营系统中的流程系统。由于历史原因导致流程系统的环节很长通常扩容一批机器需要16+以上步骤,而流程长就会间接导致成功率的低,从Docker小规模上量过程中期表象更多是运营系统的问题因为他直接暴露给用户,但实际更多是后端错综复杂的逻辑没有接入标准导致流程系统的不稳定。在一个大的系统中需要保证自己成功率的同时,依赖系统也要有严格的准入标准,并通过数据来找出问题,设定责任人并推进优化改善,同时尽量的减少流程环节。
2. 是业务符合架构还是架构符合业务
    笔者时常在思考这个问题,有意思的是笔者在部门中两个角色都做,相信站在不同的角度的答案也是不一样的,笔者之前做过业务所以站在业务的角度希望更多的是架构来符合业务,因为部门负责业务产品比较多每个产品都有快速发展的时候,如果跟不上发展将会被淘汰所以更希望架构来符合业务,实际上从运营系统发展历程上也能看到很多历史的影子 。 而目前笔者从事的是架构,更多希望是业务来符合架构,原因是在实际运营过程中发现运营系统和架构在符合各自产品标准上已经慢慢没有了自己的标准,导致系统臃肿与效率的下降, 另外很多人已经习惯了这种架构符合业务的方式,而最难改变的就是用户习惯,我们能做到的只能是增加架构与业务间彼此沟通,制定架构的准入标准,尽量满足业务的需求,并持续的完善与迭代。这里有一个模式可以借鉴就是微软的windows系列,推翻老的系统不断的更新操作系统的大版本,在实际运营过程中,发现问题再打补丁,同时系统尽量向下兼容,满足客户的需要。

end..



参考文章
1)Docker历史 http://www.oschina.net/news/57838/docker-dotcloud
2) 为什么要探索宇宙 https://www.douban.com/note/321442729/
3)Google 全球研发总监访谈 http://news.cnblogs.com/n/542090/

Nov 21
经常看到网上有人说把一个重要的文件删除了,而恢复成本很高,所以一直在想Linux终端中为什么没有像Windows下的回收站这样的设计,直到看到Unix编程艺术上的一段解释。 其实,Linux世袭了Unix的设计理念与传统,而Unix本身并没有这样的设计并延续到了Linux。

Unix面向更加专业的用户 ,Unix的开发者喜欢清晰、简单的操作,用户告诉做什么就做什么,即便用户使用的命令等价于“向我开枪”的命令。而这样做Unix的开发本能辩解的就是:保护用户避免自我损害,应该是GUI或应用程序级别的事,而非操作系统:)。

这就解释了Linux终端为什么没有类似Windows回收站的设计,当然我们也可以通过Shell方式自己来实现一个类似回收站的功能,以下是笔者在2007年与2008年时写的shell回收站,供参考:
1.第一版本(http://bbs.chinaunix.net/thread-1034672-1-1.html
2. 第二版本http://m.blog.chinaunix.net/uid-7176662-id-2068124.html

第二版本原始链接已经找不到了,在网上搜索半天才找到,估计是CU数据迁移时导致丢失,所以为防止再次丢失把版本二贴到本博客一份。


#!/bin/bash
#-----------------------------------------------------------------
#     filename:                                                                    
#       author: wds                                                                
#        begin:2008.1.27                                                                    
#          end:2008.2.1                                                                    
#      version: v.2      
# script address: http://blog.chinaunix.net/u1/40306/index.html
#-----------------------------------------------------------------
from1=$1
from2=$2
garbage=$HOME/.garbage
mvlog=$garbage/mv.log
if [ ! -e $garbage ]
then
    mkdir -p $garbage
    chmod 777 $garbage
fi
function rand
{
a=(0 1 2 3 4 5 6 7 8 9 a b c d e A B C D E F )
for ((i=0;i<7;i++));do
        echo -n ${a[$RANDOM % ${#a[*]}]}
done
}
random=$(rand)
function rm1
{
if [ -d "$from1" ]
then
   echo "rm: cannot remove '$from1/' : Is a directory"
else
   echo "`pwd`/:$from1:$random:`date`" >> $mvlog
   mv "$from1"  "$garbage/$from1:$random"
fi
}
function more
{
for file in *
do
echo "`pwd`/:$file:$random:`date`" >> $mvlog
mv $file "$garbage/$file:$random"
done 2> /dev/null
}
function rmi
{
if [ ! -d "$from2" ]
then
   echo -n "rm:remove regular empty file '$from2'?" ; read answer;
    if [ "$answer" = 'y' -o "$answer" = 'Y' ]
     then
        echo "`pwd`/:$from2:$random:`date`" >> $mvlog
         mv "$from2" "$garbage/$from2:$random"
    fi
else
   echo "rm: cannot remove directory '$from2': Is a directory"  
fi

}
function rmf
{
if [ ! -d "$from2" ]
then
        echo "`pwd`/:$from2:$random:`date`" >> $mvlog
         mv "$from2" "$garbage/$from2:$random"
else
   echo "rm: cannot remove directory '$from2': Is a directory"
fi
}
function rmr
{
if [ -e "$from2" ]
then
        result=$(echo $from2 | sed 's/\///g')
        echo "`pwd`/:$result:$random:`date`" >> $mvlog
         mv "$result" "$garbage/$result:$random"
fi

}
function rml
{
while :
do
clear
line=$(cat -n $mvlog | awk -F : '{print $1,"FileName:"$2,    "Time:"$4}')
linecount=$(cat $mvlog | wc -l)
echo -e "$line\c"
echo
echo
echo "Please input number you want revent(line count:$linecount)--exit(e)"
read answer
if [ "$answer" = e -o "$answer" = E ]
  then
    break
else
    (
     echo "please input y(sure:)"
       read answer1
       if [ "$answer1" = y -o "$answer" = Y ]
        then
          address=$(sed -n "$answer""p" $mvlog | awk -F : '{print $1}')
          filename=$(sed -n "$answer""p" $mvlog | awk -F : '{print $2}')
          filerand=$(sed -n "$answer""p" $mvlog | awk -F : '{print $3}')
          fullname=$address$filename
           if [ -e "$fullname" ]
            then
               echo "The file exist!"
               sleep 1
           else
               old="$garbage/$filename:$filerand"
               new="$address$filename"
               mv "$old" "$new"
               delline=$( cat $mvlog | sed "$answer""d" | sort -o $mvlog)
               echo "update ok!!!"
               sleep 1
           fi
       fi
    )
  fi
done

}
function help
{
echo "
-i)  If you wants delete some file , this function is confirm you want,the same as old rm.
-f)  If you wants delete some directory ,you can use this function ,the same as old rm.
-r)  If you wants delete some directory of file ,this function can use , the same as old rm.
-l)  This is new function,is you wants resume some file or directory you can use this function,
     first this function can list some file in you garbage , these have some number ,if you
     wants resume 1,you can input 1 and then input y to confirm.
If you want add some function or some new idear please contact me...
     author:wds
      email:7717060@sina.com
      
"
}

case "$1"
  in
[a-z]) : ;;
[0-9]) : ;;
[A-Z]) : ;;
    ?) more ;;
    *) :;;
esac
if [ "$#" -eq 0 ]
then
   echo -n "rm: missing operand
Try 'rm --help' for more informaction.
"
fi
if [ "$#" -eq 1 ]
then
   case "$from1"
      in
       -i) echo "Try 'rm --help' for more informaction."; break ;;
       -f) echo "Try 'rm --help' for more informaction."; break ;;
       -r) echo "Try 'rm --help' for more informaction."; break ;;
      
       -l) rml ;;
   --help) help;;
        *) rm1;;
   esac
fi

if [ "$#" -eq 2 ]
then
    case "$from1"
      in
       -i) rmi ;;
       -f) rmf ;;
       -r) rmr ;;
       -l) rml ;;
      -rf) rmr ;;
   --help) help ;;
    esac
fi

  if [ "$#" -gt 2 ]
         then
           for file in $*
             do
               mv $file "$home/"
           done 2> /dev/null
        fi
Tags:
Nov 7
1972 – C语言的先驱——B语言,被贝尔实验室开发。B语言是一个很快速的,容易维护的,而且对于从系统到应用开发是很好用的。设计这门语言的整个团队被马上解雇了,因为他们干了一件和电话通讯不相干的事情。最后这个项目转给了 Dennis Ritchie。他把这个语言变得不容易理解,很难维护,而且,只能用于系统方面的编程。而且,他还设计了一个指针系统,保让每一个程序都超过500行,并可以使用操作系统的指针。

1982 – 大家发现有97% 的C程序调用产生了“缓冲区溢出”问题。于是,C 程序员们开始意识到,就算是不必要也必需要初始化变量。然而,强制性的变量初始化这个明智的决定,很难影响了当时已经写成了的97%的C程序,所以结果什么也没有发生。

1984 – 操作系统出现了“错误指针”的问题数量开始戏剧性地增涨。

1985 – 一系列的让C语言有面向对象能力的解决方法出现了,一个叫“C With Classes”正准备商业化。然而,大家觉得名字“C With Classes”太清楚和容易被理解了,所以,最终的商业版本叫做—— C++。


1986 – C语言成为最流行的语句,其被很多业界分析师推荐于业务应用。他们向全世界宣称——由C语言写成的应用将可以运行在很多不同的平台上的,是跨平台的。目前看来,这些众多的分析者在当时有可能是因为某种迷幻而导致其大脑被所蛊惑了。

1988 – 业界的这些分析家们因为“摇头丸”吃完了。所以,在他们的幻觉过去以后,他们注意到,使用C语言来开发业务应用会增加5倍以上的开发时间,并且程序也不具备可移植性。他们开始停止向大众推荐使用C语言来开发业务应用了,只能很少一部服用可卡因的人开始转向推荐大众使用C++语言写业务应用程序,他们说,“那是面向对象的,所以,代码是很容易重用的”。

1990 – 在这个时候,所有的C编译器都转到了C++编译器上。但是,因为大多数的C++程序员并没有使用C++中那些面向对象的语言特性。也就是说,在实际上来说,那种浮肿的代码结构加上操作系统指针的代码被一种叫面向对象的编译器编译。

1990 – 在雇佣了一些转向“吸胶毒”的分析师后,Sun决定要创造一种叫Oak的语言,这种语言主要用于电视的机顶盒。因为当时几乎所有的程序员的DNA中都有C语的基因,所以,这个语言向C和C++中大量地借鉴了很多它们的语法和编程思路。然而,机顶盒上没有操作系统,也就不存在指针,所以,他们把指针从这门语言里给去掉了。

1994 – Sun公司里的某个人意识到为一个机顶盒开发一个语言是多么愚蠢的事情。于是,这个语言更名为Java,并且为其注入了“Internet”的特征,从而让其成为一个真正可以被移植的语言。其市场营销上相当成功,而那时有3%的业内人士开始明白什么是Internet,同时,那些精神不正常的分析师们还在不停地嗑药并向大众鼓吹他们的神话——“跨平台移植性”。

1995 – Sun 向业界的分析师们提供了免费蘑菇迷魂汤,导致那些分析师在喝下汤后,马上开始写下“Java是一门未来的可移植的和Ineternet高度可集成的语言”。

1996 中 – 17,468,972 篇文章出现,描述了Java是怎么一门未来的语言。这也是Java Applet开始进入Web页的时代。

1996 末– 程序员开始使用Java applet创建他们的Web页面,然后他们开始因为挫折和沮丧开始集体自杀。此时,那些分析师开始增大蘑菇迷魂汤的剂量。

1997 – 因为接受了产生幻觉分析师的建议,Corel 决定重写他们的应用,包括 WordPerfect,当然,是用Java写的。最终的结果是,这是迄今为止比“打字机”还慢的字处理软件。

1998 –  在意识到applet已在快速枯萎,Sun又一次的重新配置了Java,这次,他们叫Severlet,这是一个服务器的程序语言。这个设计在抄袭了Microsoft Transaction Server ,并且,他们说服所有人这个设计是他们创造的。

1999 – 业内那些喝多了的分析师们用一种咆哮的方式向大众介绍了Java 2 Enterprise Edition 。 21,499,512 文章被写出来。但是,实际上并没有人使用,因为J2EE太不成熟,而又太贵了。

2000 – J2EE 最终还是运转起来了(一点点)。而且,所有的Java卖主们开始准备向其砸钱,与此同时,Microsoft 宣布了.NET,这是一个包括了所有的J2EE功能但没那么贵的产品。实际上来说, Microsoft 决定让Windows的用户免费使用.NET 。 Scott McNealy 很愤怒,其对Microsoft开展了相关的法律诉讼。

.NET 包括了最新的C家族语言,叫C#,发音是“C-pound”,继承最家族的传统,使用着一个愚蠢的名字。

2001 – Microsoft 的市场部意识到,在市面上没有人谈论他们的产品,他们找了其中一个程序员一起吃中饭,才发现,他们把C#叫做 “C sharp”。

2002 – C# 成为 Microsoft .NET的一部分。 C++ 的开发者在 Microsoft 平台上为 “managed code”而欢呼雀跃,也就是说,他们最终得到了一个内存自动管理的功能,这一功能正是1991年的Visual Basic 及1995年的Java所创建的 。

copyright (C) 1996-2006 by Billy S. Hollis, originally posted on dotnetmasters.com 13 January 2006
Nov 7
Unix是目前还在存活的操作系统的元老了,走过了40年的历程(参看《Unix 40年:Unix年鉴》、《Unix 40年:昨天,今天和明天》)。由它引发的思想变革,对当今计算机文化造成的深远影响。这是一段所有从事计算机行业人员尤其是软件开发人员需要了解的历史。Unix的传奇历史是整个计算机世界文化最具代表性的,它对整个计算机世界文化的影响也是最巨大,最深远的。他给人带来的不单单的对过去的回味,更为我们带来了计算机世界的新思潮。

下篇

  • Unix与黑客文化
  • Unix的历史教训
  • Unix 家族谱
  • Unix的特点
  • Unix的影响和哲学
  • Unix痛恨者手册

上篇

  • Unix起源
  • Unix分裂
  • Unix的法律纠纷
  • GNU开源组织
  • Linux横空出世
  • Linux今天的领袖

Unix与黑客文化

黑客的文化和Unix的商业化存在着必然的联系。自从Unix出现,黑客文化就与之而来。

1993初,一个悲观的观察家撰文指出,已经有理由认为Unix的传奇故事连同他带有黑客文明将一同破产。许多人预测,从那时起Unix将在六月内死亡。他们很清楚,十年的Unix商业化,使自由跨平台的Unix梦以失败告终。Unix允诺的跨平台可移植性,在一打大公司专有的Unix版本之间不停地斗嘴中丢失,一个完美的操作系统最终沦为多种版本的一团乱麻,这应该说是人类文明史上的一个重大悲剧。

在专有软件社会中,只有像微软一样的“集权制,大教堂”生产方式才能成功。那个时代的人悲观地相信,技术世界的个人英雄主义时代已经结束,软件工业和发展中的互联网络将逐渐地由像微软一样的巨型企业支配,再也没有“佐罗”,世界是恺撒大帝的世界,计算机文明将进入黑暗的帝国时代。黑客已经死了,自由不付存在。

自从Unix出现以来,第一代的Unix黑客似乎垂垂老矣,衣食不饱( Berkeley计算机科学研究组在1994丢失了自己基金)。这是一个抑压的时代。专有的商业Unix的结果证明那么沉重、那么盲目、那么不适当,以致微软能够用那次等技术的Windows抢走他们生存的空间,拿走他们的干粮。黑客世界的残余力量被逼到了世界上的角落里,苟延残喘。

就在黑客文化日渐衰落之时,美国新闻周刊的资深记者Steven Levy完成了著名的《黑客列传》一书,书中着力介绍了一个人物:Richard M. Stallman的故事,他是麻省理工学院(MIT)人工智能实验室领袖人物,坚决反对实验室的研究成果商业化。他是商业软件社会中坚强的一员,决不随波逐流,建立了全新的黑客文化。

Richard M. Stallman(他的登陆名RMS更为人熟知)早在1970年代晚期就已经证明他是当时最有能力的程序员之一。Emacs编辑器就是他众多发明中的一项。RMS的目标是将后1980的松散黑客社群变成一台有组织的社会化机器以达到一个单纯的革命目标。也许他未意识到,他的言行与当年卡尔·马克思号召产业无产阶级反抗工作的努力如出一辙。RMS宣言引发的争论至今仍存于黑客文化中。他的纲要远不止于维护一个代码库,已经暗含了废除软件知识产权主张的精髓。RMS通过“自由软件(free software)”让黑客文化更加有自我意识。当然,这个充满魅力又具争议的人物本身已经成为了一个黑客文化英雄。

只有痴迷的“黑客”和具有创造力的怪人结成的反叛联盟才能把我们从愚蠢中拯救出来——他们接着教导我们,真正的专业和奉献精神,正是我们在屈服于世俗观念的“合理商业做法”之前的所作所为。 ——The Art of Unix Programming

RMS让世界上所有的人都知道,入侵电脑系统只是低级不入流的黑客干的事,真正的黑客,是为了自由,为了软件的自由,为了挑战计算机世界中的霸权主义而斗争。他们不是街头小混混,他们更像是绿林好汉,更像是罗宾汉,更像是佐罗。就像渴望民主的人民同专制的政府斗争一样。RMS领导着许多的黑客通过互联网向专有软件发出宣战。

X Windows是首批由服务于全球各地不同组织的许多个人以团队形式开发的大规模开源项目之一。电子邮件使创意得以在这个群体中快速传播,问题由此得以快速解决,而开发者可以人尽其才。软件更新可以在数小时之内发送到位,使得每个节点在整个开发过程中步调一致。网络改变了软件的开发模式。

另一方面,RMS的理论体系有许多东西非常有争议,他的GPL被认为是一种“病毒式”的协议,BSD的fans和老牌Unix黑客们认为,他们编写Unix的年头都比GPL声明要长得多,GPL依然有太多的限制,而BSD协议则比GPL更加的自由。另一方面,RMS走向了另一个极端,他是完全反版权的,反商业化的。把软件产品从强制收费推向了强制免费、共享和开源,这也为他带来了许多许多的争议。

在RMS组织黑客闹革命的年代里,没有多少黑客认同于RMS的理论体系,更多的他们参与GNU只是为了体现那种在互联网上协同工作,令人激动的工作模式。自从GNU设立以来,争议不断,而黑客文化却从未有统一在他的理想体系之下。

自从Linux出现以后,一个新的黑客领袖出现了,Linus Torvalds的中庸态度网聚了世界上顶尖的黑客,其绕过了GPL和反GPL的派系之争,他使用GNU的工具从而以GPL的“传染性”保护了Linux,但他同时也不承认RMS的理论思想体系,他即开源,又支持商业化。虽然,他没有带给黑客们什么重要的思想体系或统一的价值观,但他整合了全世界黑客的阵营,让所有的黑客的行为都围绕着Linux这一事物进行。他以“用自由软件是因为它运行得更好”轻而易举地盖过了“用自由软件是因为所有软件都该是自由的”。

1998年初,这种新思潮促使网景公司(Netscape Communications)公布了其Mozilla浏览器的源码。媒体对此事件的关注促成了Linux在华尔街的上市,推动了1999-2001年间科技股的繁荣。事实证明,此事无论对黑客文化的历史还是对Unix的历史都是一个转折点。

Unix的历史教训

下面的文字出自《The Art of Unix Programming》(Unix编程艺术)。令今天我们所有人所反思。

在Unix历史中,最大的规律就是: (看看《谁写了Linux》你就会知道这一规律)

距开源越近就越繁荣。任何将Unix专有化的企图,只能陷入停滞和衰败。

回顾过去,我们早该认识到这一点。1984年至今,我们浪费了十年时间才学到这个教训。如果我们日后不思悔改,可能还得大吃苦头。

虽然我们在软件设计这个重要但狭窄的领域比其他人聪明,但这不能使我们摆脱对技术与经济相互作用影响的茫然,而这些就发生在我们的眼皮底下。即使Unix社区中最具洞察力、最具远见卓识的思想家,他们的眼光终究有限。对今后的教训就是:过度依赖任何一种技术或者商业模式都是错误的——相反,保持软件及其设计传统的的灵活性才是长存之道。

另一个教训是:别和低价而灵活的方案较劲。或者,换句话说,低档的硬件只要数量足够,就能爬上性能曲线而最终获胜。经济学家Clayton Christensen称之为“破坏性技术”,他在《创新者窘境》(The Innovator’s Dilemma)[Christensen]一书中以磁盘驱动器、蒸汽挖土机和摩托车为例阐明了这种现象的发生。当小型机取代大型机、工作站和服务器取代小型机以及日用Intel机器又取代工作站和服务器时,我们也看到了这种现象。开源运动获得成功正是由于软件的大众化。Unix要繁荣,就必须继续采用吸纳低价而灵活的方案的诀窍,而不是去反对它们。

最后,旧学派的Unix社区因采用了传统的公司组织、财务和市场等命令机制而最终未能实现“职业化”。只有痴迷的“黑客”和具有创造力的怪人结成的反叛联盟才能把我们从愚蠢中拯救出来——他们接着教导我们,真正的专业和奉献精神,正是我们在屈服于世俗观念的“合理商业做法”之前的所作所为。

Unix族谱

Unix的故事仍旧延续着……,许多网站也为这段历史留下记录。一个详细记录Unix历史的网站(http://www.levenez.com/unix/),这个网站忠实记载着1969~2005 年Unix发展的大事,而且还有 PDF 档案可供下载,上面有一个庞大的UNIX家族版本树,让人叹为观止。网站的首页陈列每个时期Unix的历史,也代表着无数工程师的心血与努力。

下面是一个简单的Unix的族谱:

   |--AT&T (1969)-----\
     |                  |
     |              V6 (1976)
     |                  |
     |              V7 (1979)
     |                  |
     |   Novell owns AT&T's Unix (by 1994)
     |     _____________|____________________
     |     |       |      |        |         |
     |    AIX    IRIX    SCO   HP-UX   Solaris 2.X
     |   (IBM)   (SGI)          (HP)     (Sun)
     |
     |
     |--Berkley (1977)-----\
     |                     |
     |                  1BSD (1977)
UNIX-|                     |
     |                4.4BSD (1993)
     |                     |
     |                   Net/2
     |                     |
     |               4.4BSD-Lite (by 1995)
     |     ________________|____________________________________
     |     |       |          |         |          |            |
     |   SunOS   Ultrix   NetBSD    OSF/1   NeXTSTEP   Mac OS X
     |   (Sun)   (DEC)   (Various)  (DEC)    (NeXT)    (Apple)
     |                   (FreeBSD)
     |
     |
     |--Hybrids----\
                   |
                Linux (Various)
                   |
                   |____________________________________________
                   |    |      |          |              |      |
                   | RedHat  Debian  Mandrake   Slackware    S.u.S.E.
                   |                          (Walnut Creek)
                   |
                   |_____________________________________________
                       |        |           |          |        |
                    MkLinux  LinuxPPC  TurboLinux  OpenLinux  CorelLinux
                    (Apple)                        (Caldera)   (Corel)

Unix的特点

现在的文献中提到Unix基本上是说,由Ken Thompson和Dennis Ritchie共同开发的。而通过历史我们也能发现,Unix的主要是由Ken Thompson写下的。但在学术界,Dennis Ritchie的名字往往被排在了Ken Thompson前面的。这就是因为,Dennis Ritchie不但发明了C语言,而且当时他设计Unix操作系统的设计思想,影响了整个世界,直到今天。

当时,他们开发UNIX,没有正式立项,是Ken Thompson和Dennis Ritchie等少数几个人偷偷干的,如果一切都要从头从新设计,那几乎是不可能的。所以,Unix吸取与借鉴了Multics的经验,如内核,进程,层次式目录,面向流的I/O,把设备当作文件,……等等。但是Unix在继承中又有创新,比如Unix采用一种无格式的文件结构,文件由字节串加\0组成。这带来两大好处:一是在说明文件时不必加进许多无关的“填充物”,二是任何程序的输出可直接用作其他任何程序的输入,不必经过转换。后面这一点叫做“管道”(piping),这就是Unix首创的。此外,像把设备当作文件,从而简化了设备管理这一操作系统设计中的难题,虽然不是UNIX的发明,但是实现上它采用了一些新方法,比Multics更高明一些。

下面是Unix的特点:(30多年过去了,这些东西早已变成经典)

  • Everything (including hardware) is a file
    所有的事物(甚至硬件本身)都是一个的文件。
  • Configuration data stored in text
    以文本形式储存配置数据。
  • Small, single-purpose program
    程序尽量朝向小而单一的目标设计
  • Avoid captive user interfaces
    尽量避免令人困惑的用户接口
  • Ability to chain program together to perform complex tasks
    将几个程序连结起来,处理大而复杂的工作。

Unix的影响和哲学

Unix是第三次工业革命中计算机软件领域最具代表性的产物。在这近40年中,由Unix造成的影响是最有深远意义的。就我看来,Unix为软件领域带来了至少以下有积极的东西,由这些东西所引发的直接或间接的事物更是举不胜数。

  1. 软件开发的若干哲学和思想。
  2. 全民参与推动软件,代码共享的模式。
  3. 开启了黑客文化和开源项目。
  4. 免费和商业的完美结合的Linux。
  5. C语言,而后发展的C++,Java等等类C的语言和脚本。(参看《C语言的演变史》)
  6. TCP/IP,其的Socket编程已成为今天通用的网络编程主流。(参看《到处都是Unix的胎记》)

不能不说,AT&T虽然发展了Unix,但今天Unix的混乱的局面也和AT&T 有着直接原因。但反过来说,如果没有AT&T的反面教材,今天的GNU/Linux很有可能也不会出现。AT&T究竟是限制了Unix的发展,还是以反面示例促进了Unix社区,已不好评说。今天,软件是商业化好还是开源好的争论还在继续,纵观这几十年来Unix的历史,Linux的划时代地出现。相信你会得出自己的结论。不管怎么样,Unix的经历对计算机领域贡献的不单单是技术,他给我们提供了丰富而生动的教材。特别是Unix引发的哲学,让今天的我们依然受益不浅。

说到Unix为我们所带来的软件开发的哲学,我必需要说一说。Unix遵循的原则是KISS(Keep it simple, stupid)。在http://en.wikipedia.org/wiki/Unix_philosophy 上有很多的基本上大同小异的Unix哲学,都是很经典的。

Doug McIlroy 是认为UNIX的哲学是这样的:三条哲学,简明扼要,就是这三条哲学贯穿着整个Unix世界。尤其是第一条“do one thing and do it well”真是相当精彩!

  • Write programs that do one thing and do it well.
  • Write programs to work together.
  • Write programs to handle text streams, because that is a universal interface.

只要是Unix的程序员,他们会比别的程序员在任何时候都会不停地强调着这三条哲学。

而《The Art of Unix Programming》总结了下面这些哲学,都是至理名言啊。

  • Rule of Modularity: Write simple parts connected by clean interfaces.
  • Rule of Clarity: Clarity is better than cleverness.
  • Rule of Composition: Design programs to be connected to other programs.
  • Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
  • Rule of Simplicity: Design for simplicity; add complexity only where you must.
  • Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
  • Rule of Transparency: Design for visibility to make inspection and debugging easier.
  • Rule of Robustness: Robustness is the child of transparency and simplicity.
  • Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
  • Rule of Least Surprise: In interface design, always do the least surprising thing.
  • Rule of Silence: When a program has nothing surprising to say, it should say nothing.
  • Rule of Repair: When you must fail, fail noisily and as soon as possible.
  • Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
  • Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
  • Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
  • Rule of Diversity: Distrust all claims for “one true way”.
  • Rule of Extensibility: Design for the future, because it will be here sooner than you think.

X Windows 的设计者 Mike Gancarz 给出了下面九条哲学思想

  1. Small is beautiful.
  2. Make each program do one thing well.
  3. Build a prototype as soon as possible.
  4. Choose portability over efficiency.
  5. Store data in flat text files.
  6. Use software leverage to your advantage.
  7. Use shell scripts to increase leverage and portability.
  8. Avoid captive user interfaces.
  9. Make every program a filter.

在今天,这种思想依然被传承着,在影响着世界上各个角落的每一个程序员。

Unix痛恨者手册

这里还需要值得一提的是一本叫《The Unix-Haters Handbook》,中文译做《Unix痛恨者手册》。可以在这里下载:http://research.microsoft.com/~daniel/uhh-download.html。其中以调侃的语气声讨了Unix的种种不是。虽然这是十年前的一本书了,但还是值得一读。这本书指出了许多Unix的设计错误,指出了种种看起来很合理的设计走向了荒谬,还这样调侃了C语言——“如果说C语言给足了让你上吊的绳子,那么,C++在给了你足够的绳子把你的邻居全部捆起来之后,还给了你足够的绳子让你为一艘小帆船装上帆,最后你还有足够的绳子把自己吊死在帆船的桅杆上”。呵呵,相当的尖酸刻薄吧。里面有一句对操作系统的评价是这样的:“The fundamental difference between Unix and the Macintosh operating system is that Unix was designed to please programmers, whereas the Mac was designed to please users. (Windows, on the other hand, was designed to please accountants.”(Windows设计给会计人员?!连计算机用户都不是了,呵呵)

不过,我可以感觉得到这本书的作者在书中对Unix的感情是比较复杂的,爱恨交加,在书的最后有这样一句话“would anyone have spent this much time and effort writing about how much they hated Unix if they didn’t secretly love it? I’ll leave that to the readers to judge, but in the end, it really doesn’t matter: If this book doesn’t kill Unix, nothing will”。是的,如果Unix能够存活这么长的时间,那么,不会有什么东西可以把他消灭了。

从《Unix痛恨者手册》这本书,再加上Unix的历史,我们可以感到Unix的经历的风风雨雨,在Unix上面出现有种种教训,近40年的历程,Unix历经磨难,几近夭折,一路走来的确很不容易,让人由衷感叹。今天的Unix,今天的软件工业和以前相比已是不可同日而语。很大程度上,这些都要归功于这个充满苍桑的Unix。

后记

在中国我们开始学习计算机的时候,我们被Microsoft所创造的文化所笼罩里。就在Unix出现革命性的转变,在Unix影响计算机世界文化的那几年里,科班出生专业开发人员学习的是MS-DOS和微软的文化,我们犹如一个井底之蛙一样,对外面的翻天覆地的变化无动于衷。微软创造的文化在我们这里尤其地根深蒂固,我们几乎忘记了另外一边的Unix(参看《Unix 40年:Unix年鉴》、《Unix 40年:昨天,今天和明天》)。

在那充满激情的Unix的岁月里,大伙为了科研目的或个人兴趣在Unix上进行各种开发,并且不计较金钱利益,将这些源码公开,互相共享。在那里,开发和自由成为主题,正因为如此,当今的世界才如此丰富多采。在40年Unix文化和技术积淀的里面,蕴涵着比较纯正的计算机文化和思想。

纵观整个Unix的历史过程中,许许多多的程序员、工程师前辈们在Unix中所摸爬滚打,他们的辛勤地、他们呕心沥血地跟随Unix,努力建立一个繁荣的计算机世界的文明。Unix不是一个简简单单的操作系统。有人说,Unix是程序员设计给程序员的,一点没错。Unix的近40年历史造就了它的博大精深,它给程序员们带来的绝不仅仅只是技术上的知识。它的失误,它的无奈,它的精神,它的荣耀,它从技术和思想上都启迪着我们。对于程序员来说,学习Unix就等同于向前辈程序学习。无论你是什么样的程序员,你都应该了解Unix,这是开发人员的根,前面的开发者造就了它,而它又在引领后面的开发人员,它是前辈程序员们交给我们的一份礼物,一个接力棒,它是开发人员赖以生存的土壤,是上一辈程序员留给我们这一代程序员开启未来的钥匙。Unix就像一个程序员教父一样,理当受到我们的尊敬和崇拜。

分页: 4/7 第一页 上页 1 2 3 4 5 6 7 下页 最后页 [ 显示模式: 摘要 | 列表 ]