Shell's Home

北京,北京

Sep 13, 2011 - 1 minute read - Comments

怀念北京的话就不多说了,中国没有几个人不会故土难离。我直接上干货,说说北京的诸多问题。 1.北京杯具的排水系统 北京大型水上乐园今年两次开张,正式宣告了北京又回到了曾经是海的年代—— 好吧,这个玩笑不怎么好笑。 我小时候,北京基本不会积水,今年积水两次,而且是淹车丟人的积水——至于积水潭瀑布这种问题我们就不提了。为什么? 大概来说,原来的水系统是依照北京的边界在四环设计的,而现在北京的道路覆盖已经到了五环外。路程越长,运输积水的能力越差。北京在三到五年内爆发性的发展,这些不被人注意的非政绩工程就一下子爆发出来了。 而且,老北京有多少湖?昆明湖水系被填了多少?光一个中南海和北海,能容纳整个北京的雨水么? 内城雨水排不出城外,就只有在街面上汇集了。 2.北京的水资源问题 上文讲排水,这段就讲给水。北京的水一直是个严重问题。高中时,我们出学校去旁边树林玩。老师再三强调,树林属于顺义防护林体系,活动是学校担保的。绝对不要出现火灾,否则连老师带校长,人人倒霉。出了学校,我们玩渴了,到附近人家家里去讨水喝。附近人家从井里打上来的水是带农药味的,非常喝不惯。人家说我们已经喝习惯了。地呢?地早就不种了,菜价还比不上水价。后来学校老师说,学校的水是从地下深井打上来的,因为区里重点保教育(学校好,很多区里实权人物的子女都在),所以特批了学校打深井,给了一定的流量指标。 在这里首先要感谢我的老师和学校中的大部分工作人员,因为他们并没有将春游变成赚钱的活动和形象工程,而是承担着风险,让我们做我们自己选择的事情。这是第一次,我知道北京的水资源是如此匮乏,而不仅仅是书上的一段文字。当每次你拧开水龙头都有水流出的时候,水资源这个问题的严重性会被多少人记住呢?大部分人记住的只是水价而已。 最近几次回家的时候,潮白河里已经储满了水,和以前人可涉水而过形成了相当的对比。然而水从哪里来?我专门找了NHK相关的专题片看了一下,顺便感慨一下,这方面日本人做的都比我们好——当然,他们比我们更缺资源。根据NHK的采访,河北,山西,都在为了北京而供水。很多地方都出现了水库下降,农田抛荒,工厂停产。当时是奥运,叫做全国保奥。现在呢?看着潮白河的水位,我敢打赌调水仍没有停止。这些人,将来怎么生存呢?他们是否会因为政府做的这些事情而憎恨一无所知的北京人呢? 我不知道,也不敢知道。 3.北京的城市规划和堵车 这点TX同学和我的感觉一致,北京的行政划区问题导致了严重的交通压力。北京的城市规划,叫做功能分区。就是一个区域,里面全是住宅,另一个区域,就干CBD,再拉一个区域,专门做教育。。。 这样的分区对小城市没啥问题,在巨型城市上使用功能分区,尤其是大尺度功能分区简直就是脑残——哦,说错了,不需要简直。我们考虑这样一个问题。如果一个城市,有两个功能——住宅和工作。我们把住宅和工作单元1:1放在一起,那么城市内的交通模型应当是热随机的,主要由各种随机理由出行的人群组成。而如果我们把住宅放在城市东边,工作放在城市西边。好,每天上班高峰,城市凭空出现一个单向交通矢,从住宅区重心指向工作区重心,大小为全市人口。下班反向出现一个交通矢。每个矢量都是集峰,单向,很难化解,而且消耗巨量资源,浪费时间。 当然,从理想上说,如果中国的房屋出租再有保证一些,两个问题会更容易解决一些——一个是房价,一个就是交通会进一步减小。然而无论如何,功能分区、公车数量加上行政调控,形成了我们天下闻名的“首堵”。 4.沙尘暴和行政划区 沙尘暴就更跨出了北京的行政区域和地理区域,要讲到北京的地理环境了。北京目前离沙漠前锋,只有150-200公里的距离。而且是到沙漠的距离,不是沙化的距离。只要北京停止向张家口方向的供水和绿化资金,这个距离还可能会更短一些。当然,考虑各种作用,即使完全不管,在最疯狂的估量下,要沙漠蔓延到北京也至少需要20年的时间。何况在沙漠边上的城市很多,不缺北京一个。 然而离沙漠近到这个地步了,还如何指望没有沙尘暴呢?据说当年很多小日本跑到中国来种树——以为人家是为了战争做补偿的么?错了,沙尘暴都吹到日本了,没办法,只能跑到源头来种树了。 5.政令的得意者 北京的兴起,很大成都上是得益于首都的地位。包括庞大的公务员,驻京办,维稳体系。大量的行政资源,带动了相当的三产公司在北京成立总部——尤其是金融业和科技业。任何一个首都,都会得到行政上的好处,和相应的付出。然而很少有一个首都,会有北京这样特殊的地位,以扭曲的地位带来扭曲的利益。 这种利益,让北京成为全国人心中的迦南。但是这个迦南,是依靠没有进入的人的付出来支撑的。因此,全国无数人涌入北京,试图分一杯羹。因此,近些年的北漂一族已经非常庞大,北京的户口早就基本停止流动,下一步恐怕连人都要停止流动(有部分政策已经在实施这个思路了)。进入的人越多,留下的人越少,北京的人口压力越大,相应的,这个泡沫破灭的速度就越快。而没有人进入,就没办法让其他人为他工作,必须依靠行政强制。这个行政强制,又会加剧北京和其他地区的矛盾。 什么时候?我怎么知道,我又不是神仙。

悲崔的散热片改良

Sep 9, 2011 - 1 minute read - Comments

贝壳的新电脑出了点小问题,不过让贝壳郁闷了很长时间。 其实这个问题早就有,不过最初没当回事情。贝壳用的AMD X4 955黑盒芯片,设计热功耗(TDP)125W,整个一个电炉。不过由于有功率调节能力,大部分的时候功率只有20W,还是挺不错的。机箱不热,声音也不大。不过贝壳偶尔一次晚上用这货压个片子,天呐,大半夜的战斗机升空了。声音吵到死人跳起来不说,机箱电源那里一摸还烫手。这还了得,CPU散热器烫手就算了,机箱烫手——真要作成烧烤机箱不成? 第二天,跑到配机器的那里,要求换一个好点的散热器,声音别那么大。他拿过散热器转了一下,笑笑说,这玩意声音肯定大,随手一转就有声音,上6000转还了得。想想也是,换了一个大号风扇,声音果然是小多了。不过抱回家,发现问题又不对了。原来的风扇温度是60度多点,现在这个有75度了。 再抱回去,人家也傻眼了。这玩意正常用没听说有这问题阿。好吧,老吴,我是正常人么?恩,这个真不是—— 换了一个号称最强风扇,回家还是75度。怒了,回去好好研究了一下机箱散热的知识。 1.导热系数 什么叫导热系数[1]?一定厚度的材料,两端有温差,热就会从一端向另一端自动传导,这是基础热力学原理。导热系数的定义是,1m的材料,两端温差1度(同1开),在1秒内所传递的能密度。单位是W/mK(瓦每米开)。铜的导热率大概是400W/mK[1],铝大概是240W/mK[1]。具体情况会根据铜和铝的纯度,杂质种类,乃至合金特性而变化。所以以前常说,纯铜散热器如何高档。当然,根据数据,钻石会更高档一些…… 2.散热器 目前散热器种类很多,我着重说其中一种,热管[2]散热器。 自从迈入热管时代,全铜散热片就成渣了。为什么?热管的热传导系数是5000-40000W/mK。哪怕钻石都是渣阿….. 不过热管归热管,还是有点讲究的。6mm热管一根大约能“负责”15W,8mm一根大约25W。在这个功率下,两端温差基本可以接受。如果你要求一根6mm热管负担955的全部125W功耗,也不是不行,两端温差就不好说了。目前热管使用形式最多的是U型热管塔式散热器,就是一根热管中间和CPU接触,两端向上延伸,成为塔状的散热器。这样的话一根热管就可以当作两根用,成本低效果好。955的TDP是120W多点,4根6mm热管刚好负荷,所以目标就选用6mm四热管散热器。 热管解决了一个关键问题,如何将CPU核心的高热传导到空间中,而如何将热管上的温度散发到空气中,则要看散热片的质量。通常而言,使用了热管后,散热片的材质就不是关键,关键是表面积。所以热管散热器不要盲目迷信纯铜,那玩意未必比表面工艺良好的铝叶来的效果好。好一点的散热器表面积都要高达上万平方厘米,大概能合1坪的面积。差一点的也有5000以上。如果热管配合的叶面太小,那么散热效果也会大打折扣的。热管和散热片的接触工艺大致分为两种,焊接和扣FIN。焊接好一点,不过实话说,区别也不是特别大。 3.硅胶 原来的风扇拆下来一看,厚厚一层硅胶。兄弟阿,硅胶这玩意不但不是越多越好,反而是越少越好。 硅胶本身接近白色,按照用途分为普通胶,导电和导热胶,区别在于后者加入金属粉或者石墨粉,从而有黑色和银灰的色变。最好的硅胶,导热系数号称可达6W/mK。对比上面的数据可以看出,其实这个数字小的可怜。然而为什么CPU上还要涂硅胶呢?因为金属接触的时候,接触面其实是不平整的。由于不平整,导热面积会大幅减小。为了使用全部的导热面积,通常使用液态导热填充物进行填充。当然,如果要求只是液态的话,选择还有很多,例如[1]中提到的水银。但是要求不能蒸发和凝固,定型良好,无毒无害,成本低廉,那最佳选项只有硅胶了。因此,硅胶是属于接触导热用,一般来说,越薄越好,厚厚的一层硅胶只会降低导热特性。同时,硅胶涂抹的时候也要大致均匀。有一点不均匀的话,在散热片压上去的时候,硅胶会自动流到接触最差的地方进行填充。然而如果一半没涂的话,硅胶是没有这么良好的流动性的。 4.风扇 风扇是机箱另一个关键部件,AMD原始的风扇之所以能用一个很破的散热器将温度降低,关键就是高达6000RPM的超高速风扇,俗称暴力风扇流。当然,这个流派最大的问题是——音量也很暴力。 通常而言,风扇的两个关键指标是尺寸,轴承,还有转速。转速的单位是RPM,即每分钟多少转。1000-2500RPM属于低转速,2500RPM-4000RPM属于中转速,4000-6500RPM属于高转速,6500RPM以上就是超高转速了,每秒100转以上。甚至部分服务器风扇可以高达10000多RPM。不同转速,所选用的轴承也会有所区别,具体轴承区别可以参考[4]。大致来说,低速风扇都是使用含油或者液压轴承,音量比较小。而高速风扇大多是双滚珠轴承。液压轴承通常的噪声都在18db-24db之间,在安静的房间内可以忽略。而双滚珠在4000RPM级别噪音通常都在28-32db,在安静房间有明显噪音,但是可以忍受。至于6000RPM或者更高的双滚珠轴承——那TMD就是活生生的战斗机。 风扇另一个需要注意的问题就是PWM。以前的风扇是三线,VC(voltage control)控制。当转速低于一定水平,IC电路就无法工作,导致风扇有一定最低转速。而PWM风扇使用独立供电,方波周期控制,因此最低转速可以控制的更低。对于有些需要静音又不能关闭风扇的系统,更加省电安静。 关于风扇风量的问题,可以大致参考[3]。955的TDP120W,CPU和机箱温差控制在15度以内,通风量就需要21CFM。考虑到部分风损耗,风扇至少需要30CFM以上。这个数值很尴尬,因为90mm级别的风扇,能够产生这个风量的大部分都是3000RPM以上的中高转速风扇。中高转速很大可能使用双滚珠轴承,噪音比较大。最后,我选了一款2000RPM的风扇,液压轴承,号称风量是45CFM。其实大家心里清楚,这玩意能到30CFM就差不多了——也能够达到要求了。 5.机箱热系统 机箱热系统差不多就是上面几个的综合,不过散热器主要考虑CPU,机箱还得考虑其他部件和热流动问题。 除去CPU外,另外三个主要的发热点是:北桥,显卡,硬盘。显卡我使用了一块低功耗无风扇显卡,北桥上也没有主动风扇,因此都需要机箱辅助散热。原来的直吹暴力风扇将CPU热都吹到了CPU周边。北桥和内存刚好就在CPU周边,这直接导致了北桥温度在48度居高不下。目前的塔式散热器一个优点就是把热都吹到了主板后端接口的位置,因此没有向北桥和显卡位置传递热。但是CPU风扇是45CFM的,而机箱电源风扇只有30CFM。堆积的热空气会产生热回流,导致散热效率下降。同时也考虑到,所有热风都通过电源,会导致电源长期在高温下工作,对寿命不利。因此我买了一个80mm40CFM的机箱风扇,安装在主板后端口上方,将CPU散热器推过来的热空气直接排出机箱。加上电源本身30CFM的风量,机箱会从下方和左侧吸取大量冷空气补充,从而降低显卡和北桥温度。 OK,光说不练假把式。我们对比一下几个散热方案的情况。 1.原始散热方案,原装散热器+暴力风扇。满载北桥温度48,CPU核心温度65,噪音——吵死人。空载北桥温度45,CPU温度50,噪音小。 2.直吹方案,纯铜散热器+静音风扇。满载北桥50,CPU核心74,噪音无。空载北桥45,CPU核心50,噪音无。 3.热管散热侧吹+机箱风扇。满载北桥38,CPU核心51,噪音无。空载北桥35,CPU核心38,噪音无。 参考: [1].热导率http://zh.wikipedia.org/wiki/%E7%83%AD%E5%AF%BC%E7%8E%87 [2].热导管http://zh.wikipedia.org/wiki/%E7%86%B1%E5%B0%8E%E7%AE%A1 [3].如何计算产品所需风机的风量http://itbbs.pconline.com.cn/diy/10497307.html [4].风扇轴承http://detail.zol.com.cn/product_param/index651.html

gnupg密钥签署原理和过程

Sep 7, 2011 - 1 minute read - Comments

gnupg的密钥基础运用比较简单,有能力跑过来看我blog的应该都比较清楚了。不过最近接触了gnupg密钥的一些复杂运用,才发现——这玩意,居然能构造类似于PKI的复杂密码体系呢。 gnupg的密码体系和PKI类似,又有区别。PKI密码体系有数个根节点,负责验证服务。然而gnupg没有这种根节点,一切都是以社会关系网络运作的。更加复杂,也更加接近自然社会体系。 首先是gnupg的基本密码原理,公钥和私钥对。利用私钥签署,公钥验证。公钥加密,私钥解密。这是最基础的两种用法,我们略过不谈。密钥签署的问题提出来源于,我如何相信我得到的密钥,真的来自他所声称的这个人? 例如,我得到了来自Linus Benedict Torvalds的一封邮件,上面说blahblah。当然,听起来应当高兴,不过暂缓,这个信真的是linus本人写的么?这时候,我可以导入linus的公钥,验证签名——当然,如果有签名的话。不过问题又来了,你如何保证得到的是linus本人的公钥,而不是某个试图破坏系统的人伪造的呢? 好吧,为了解决这个问题,gnupg设计了互相签署机制。当我签署了某个人的公钥,并且将我的签署上传到公钥服务器(或者发送回给本人)的时候,我就为这个人的真实性做出了背书。例如,当我为thomas做了公钥签署,然后上传到了公钥服务器。然后thomas向某个他并不直接认识的我的朋友发送了一封邮件——例如发送给了julia。julia收到信的时候,会从服务器上下载thomas的公钥,然后看到我的背书。如果julia相信(trust)我,那么gnupg就会自动完成验证。当然,将公钥上传到服务器会略微降低安全性,所以如果限于安全考虑,我没有上传到公钥服务器,而是传回给本人。那么thomas就必须在给julia发送邮件的时候,附上公钥。julia一样能看到公钥上我的签名。 下面是如何操作。 首先你必须获得公钥,以下是从公钥服务器上下载的方法。 gpg --keyserver <keyserver> --recv-keys <Key\_ID> 而后,你需要看到这个公钥的fingerprint。 gpg --fingerprint <Key\_ID> 再然后,就是比较困难的部分。你需要和这个公钥的拥有者碰头,找个地方喝个咖啡,或者一起出来玩什么的。然后,查看他的有效证件,和本人对照,并且取得他本人认可的fingerprint。 这点非常重要,不要轻易的使用线上fingerprint交换来替代这个过程,也不要随意的为别人进行签署。你必须*确定*你签署了本人的密钥,线上获得的key,是完全可能被修改的,这是对所有信任你的人的负责。 再然后,就是简单的签署。 gpg --default-key <Key\_to\_use> --sign-key <Key\_ID> 最后,上传公钥,或者传回给本人。以下例子是上传到服务器的,不过记得先征求对方同意——除非你原本也是从服务器上取得的公钥。 gpg --keyserver <keyserver> --send-key <Key\_ID> 至于revoke什么的,暂且就不说了。 其中最麻烦的,就是上述过程中,两个人碰头的部分。为了简化这个部分,gnupg使用者经常有种gnupg keysigning party[2]的聚会,互相交换和签署密钥。 reference: [1].The GNU Privacy Handbookhttp://www.gnupg.org/gph/en/manual.html [2].GnuPG Keysigning Party HOWTOhttp://alfie.ist.org/projects/gpg-party/gpg-party.zh-tw.html

为什么恳谈行不通

Sep 6, 2011 - 1 minute read - Comments

几乎每个公司的老总都有“事到临头才发现自己是公司最后一个知道的人”的杯具经历,因此几乎没有例外的,每个公司基本都有所谓的“恳谈会”,或者叫做面谈。基本就是HR,或者行政,对职员进行一对一面谈,试图找出些什么东西来。不过就贝壳自己的经历来看,这种恳谈会的作用非常小。一个公司的所有员工,一年谈一次,能得到一个有用的信息,算是运气不错了。 为什么恳谈行不通呢?因为阶级。恳谈会首先就分了两个阶级——老板和员工。我们知道不是老板的问题,作为恳谈的受益人,他们没道理刻意阻止恳谈的效果。唯一的理由只有一个——职员不愿意告诉老板一些有用的事情,他们说的都是可有可无的废话。其实细细想想也是当然的,因为老板是受益人的话,员工多数就是受害人了。大部分老板感兴趣的事情——心不在焉的员工,心怀鬼胎的管理层——在被老板知道的同时,都会受到惩罚。因此,从心理上说,恳谈会给员工的感觉永远是出卖。 在这种心理的作用下,员工会很快的形成攻守同盟。他们不出卖别人的秘密,同时希望别人也不出卖他们的,即使他们没有秘密。在这种情况下,使用奖励是愚蠢的。被奖励者无疑会成为告密者,然后收到大家的歧视和排挤,迅速的消失。奖励与其说是鼓励恳谈,不如说是让员工坚定的不要开口——即使他们真的想说什么的话。即使是秘密的奖励,实际上也很难实行。如果真的有人做了,这个人你真的敢用么? 恳谈没用,那怎么办?基本是两个办法。一个是让部分员工以员工的身份收集信息,公布这件事情,同时不要公布他们的身份。这是一种古老的思路,其核心是威慑和平衡。员工而言,不知道这些人是否存在,他们会说什么,这会让他们不敢做一些太过明目张胆的事情。 当然,另一种更为有效同时也更为成功的思路是,取消老板和员工阶级。没有了老板和员工阶级,员工自然会说任何他们想说的事情。对公司不利,就是对他们自己不利,这样公司才不可阻挡。然而要达成这点,必须放弃很多东西。首先,作为老板,你再也不是公司的全权管理者。也就是说,你必须通过规则来控制每个人,而不是直接控制。而规则来自你和员工的商讨,而不是你的脑子。 区别?如果你看到一个上班打游戏的家伙,让他滚蛋了。你是对的,然而你是老板。如果你看到一个上班打游戏的家伙,你回去查了查,规则中并没有说不能打游戏。所以你在某个会议上说,我们最好不要这样,然后让员工讨论一下,什么时候可以打游戏,什么时候不可以。什么游戏是可以玩的,什么是不可以的,打游戏有哪些惩罚。那么你就是一个普通管理者。 听起来没有什么好处,而且罗嗦的要命?明明正确的事情,为什么不能直接做?可你知道,这只是把隐藏在台面下的东西端上来而已,管理者从来都不是神——甚至不是国王。你可以直接控制你的员工,也可以强行制定规则,大部分人也不会有反应。然而,当你的政策和现实差异越来越大的时候,你的员工离职率也会居高不下。过高的离职率会带来很多问题,当部门普通员工离职率小于10%每年的情况下,公司基本不会受到任何影响。当部门普通员工离职率超过20%每年的情况下,管理者的执行就会不太流畅,时断时续。当部门员工离职率超过50%每年,或者中级以上管理者每年离职超过10%的时候,公司大量资源会消耗在招聘,培训,交接等问题上,同时事务实行经常卡壳。当部门员工离职率超过100%(不要惊讶,这不是个铁道部的笑话),或者中层管理者离职超过50%每年的时候,公司基本失去功能。因此老外的罢工可不是闹着玩的。 和员工商讨规则,并且连自己也需要遵守规则,这在保证员工利益的同时,也让他们感到参与感。参与感会增加他们归属于这个集体的情感,从而帮助你发现和管理问题——一切都是自发的。更妙的是,即使薪水略低,员工也很少离职。当然,作为双刃剑,你要知道,有的时候员工会联合起来进行薪水谈判。如果双方都是理智的进行谈判的话,我相信对于一个健康的软件公司,这只会让他更健康。当然,更重要的是,你需要自己遵守自己的规则,让规则成为权威。

我有几台电脑

Sep 1, 2011 - 1 minute read - Comments

废话贴,数一下。 家里能正常工作的电脑四台,一台台式机,11年7月买的,一台笔记本,07年买的,一台上网本,09年买的,一台低功耗服务器,11年初买的。 两台租用设备,一个是空间,一个是vps。 公司一台电脑,10年换的。 两台嵌入设备,wince和android各一,还打算明年入个平板。 虚拟设备七到八个,常用的两个,一个xp一个debian。 差不多就这些。

汽车、苹果、人类的历史

Aug 30, 2011 - 1 minute read - Comments

Jobs辞职了。 好吧,这篇文章早在年初就想写了,不过经过漫长时间的沉淀,最终还是被忘记了。最后帮主的退出帮我想起了这个事情。 本文论述的其实很简单,是一个人类使用东西上再简单不过的常识。不过很可惜,几乎所有的程序员都会忘记这个事实——直到有一个正视事实的家伙赚了大钱——然后现在辞职了。 人在使用东西的时候,都会从简单的角度去理解,而不是从复杂的角度。而人在研究东西的时候,都会从复杂的角度去研究,而不是简单的角度。我们可以回想机械大爆炸的年代,今天能看到很多上世纪的笔记,里面记载了奇奇怪怪的机器——传说达芬奇还研究过直升机。不过今天能留下来的,都是最简单和基本的了。这并不是说这些机器不好,而是创意从研究者到使用者之间巨大的专业鸿沟所致。 举例来说,我们日常最常见的机械之一——汽车。汽车上有数千计的组件,随着我们对不同组件的定制和组合,我们能够组装出不同的车。越野的,城市行驶,大脚怪,等等。从设计角度说,车的操控界面其实过度简化了。理论上说,即使四个轮子的车,也可以考虑对每个轮子施加不同方向和大小的力矩。加上轮子的内弯和外弯角度参数。一个轮子上就有两个有向标量在控制,四个轮子组合起来,足足可以形成一个八维量——只比张量差一个维。然而我们在开车的时候,只会控制四件事情——方向盘角度,档位,油门,刹车。近些年的无级变速车还逐步合并了油门和档位,使得控制量还少了一个,只有一个有向标量,一个标量,一个布尔。 这些控制系统能够产生的控制精细程度,是远远比不上八维的控制的。例如,如果我们能精细控制每个轮胎,车可以做到原地旋转——两个前轮同向向前,两个后轮反向向后。或者可以保持方向的状态下斜侧移位,乃至于如果前轮内外弯角度比较大,还可以直接侧方移位——不用前后倒车进车。然而,一方面是复杂的控制系统会造成非常高的成本。另一方面,人类没有昆虫那样的复眼去同时盯着路面、后镜、还有诸多仪表,更没有那么多手去操纵那么多控制件——比这个更直观的,是人类根本不会想要把自己的神经训练成这种怪物的信号处理系统。 人类能够大规模使用的,都是自己简单能够理解的东西——这个简单的标准随着这个东西能做到的事情而不同。如果只是要帮自己晃动孩子的摇篮,那么通常而言,只要控制开关就好。如果晃动摇篮的机械需要你指定晃动输出是基于正弦波还是基于锯齿波,你一定会觉得不可思议,然后摇头走开。而如果这个“东西”,能够帮助诊断很多重症病人,并且让你获得一份高的离谱的合约。我想你不会介意花三到五年时间学习整套系统的使用方法。当然,即使在这种情况下,简化的系统仍然是一件让人开心的事情。 计算机发展到后期,已经远远超出了最聪明的人所能理解的范畴。app store上有十万多个程序,即使每个花5分钟浏览一下也需要6天。如果要一一玩过,基本会花去一个人的一生。windows下的各种程序更是数都不要数。在这种情况下,如果我们还是持续的曝露各种底层细节给用户——你的数据要存放到哪个文件夹?你的文件类型是什么?无疑,用户不会跑开,但是肯定会很恼怒——为什么我需要知道文件路径?我写下一个名字,下次你帮我找出来,不就好了? 类似的问题正是ipod, mac, ipad, 加上现在的android试图解决的。app的安装删除并不需要用户理解细节,android上调节参数比较多,最多也不过是指名安装到sd卡上还是内存中。数据保存也基本无须关心——其实这点上做的还并不足够。整个系统,就像一个封装在琥珀里面的,神奇的魔盒。你说出你的愿望,他就帮你实现,一切都是那么美好——除了这个魔盒可以买到,而且必须经常充电。 将来?将来的系统可能会重现工业时代的老路,有经验的程序员会逐渐变成工人,而不是城市里孤独的游侠。华而不实的设计被淘汰,有效的设计成为生活中的常识。电脑将变得越来越贴近生活——前所未有的近。而我们的历史,也会进入新的一页。

debian打包的一些细节补充

Aug 26, 2011 - 1 minute read - Comments

如果前面有人接手了,你最好和前任联系一下,看看是否可以获得他的帮助,或者跟着他的思路继续做下去。 debian有一个比较变态的规定,你的打包内容,必须遵循FHS。有些程序写的数据放到了程序路径下面,你需要进行人工分离(这个花了我整整两天)。 求RFS比ITP难多了… …. ……. 求RFS。

其实英文基本没必要学的

Aug 24, 2011 - 1 minute read - Comments

找个maillist实际跟老外一起交流干活。历经数次抓耳挠腮依旧词不达意,然后看到老外的标准回复后,有用的东西基本都留在脑子里了。 当然,坏处就是,很多非英系老外的错误(包括国人的错误)也会复制过来。

第一个debian官方包请求出来

Aug 23, 2011 - 1 minute read - Comments

贝壳的第一个为debian官方贡献的包出炉了,地址在这里。之前也发过一个ITP,结果发现莫名其妙有人在做了。不知道为什么没有在wnpp中发现,结果弄的好不尴尬。 大概说一下,为debian官方贡献打包,你需要了解这个包的基本情况。例如用哪种语言写的,有什么依赖关系,是什么授权,等等。尤其是授权,debian有所谓的dsfg方针(不知道的看这里,这里,这里)。如果你打出来的包包含dsfg不许可的内容,你的包会被紧急移除,直到修复这个问题。尤其值得注意的是,debian要求文件级的授权,就是说,即使有一个文件不符合授权要求,整个包也会不通过,哪怕包本身声明为开源授权。之前ibus还是fctix,因为用了拼音加加的词库,就享受了一把这个待遇。另外,如果可以的话,最好征求一下上游维护者的意见(一般就是作者)。因为debian的bug系统中的问题是你需要解决的,而这些问题通常没有上游维护者是很难搞定的。当然,如果你觉得自己搞的定,或者可以出了问题再联系,那也可以。 当你搞明白这些问题后,通常需要先发一个ITP(Intent To Adoption)出来,表示你要打包,别人不要抢。通常是用reportbug来进行提交,汇报wnpp(Work-Needing and Prospective Packages)这个包的bug。然后程序会问你确定?确定的话,会要求你选择是哪种报告,其中就有ITP。当你的ITP通过后,你会收到一个bugnumber,这个bugnumber会在changelog中用到。 另外说明一下bts(bug tracking system)的基本用法。你需要给control@bugs.debian.org发送一封邮件,内容是bts的控制指令,每行一条。碰到无法识别的指令时,bts停止解析。通常习惯在最后写一个thanks来停止解析,也表示礼貌。指令系统可以参考[3]。 然后开始干活。干活的方法参考Debian 新维护人员手册。其中注意在changelog中填入你刚刚申请到的ITP,这样当包通过后,会自动关闭你的ITP。提交的包需要是lintian clean的,即自动检查程序没有发现错误。通常你可以在本地系统安装lintian进行检查。 当你完成打包工作(没法详述,太复杂了,自己看文档吧),你需要上传到mentors系统,然后让DD审查你的包。你首先要在http://mentors.debian.net拥有一个账户,这个账户的email将来会用于给你发送bug通知之类的东西。当你完成账户创建,你会在页面上看到要求上传一个gpgkey。gpg创建key都会吧?记得做4096位密钥。另外填写姓名的时候,用最好真实姓名作为名称,网名进nickname,尤其是大部分中国人都有一个拼音姓名和一个英文姓名的时候。。。 然后,你的主页上有一个说明,会让你复制一些数据到你的~/.dput.cf中。dput是用来上传源码包的工具。如果你按照说明去复制,那么你就可以用dput debexpo.changes来上传你的包。其中有几点需要注意的,一个是debexpo不能丢,否则会默认传到ftp.debian.org上去,然后失败。另外changes和dsc必须经过你上传那个公钥对应的私钥的签署,否则签名验证失败,你的包上传行为就会失败。如果你的系统中有多个private key,那么dpkg-buildpackage会不知道如何打包。用-k参数加上你的私钥id,就可以指定使用哪个私钥进行签署。 当你的包完成上传后,你可以在my packages下面看到。注意服务器检查结果,本地通过lintian的包在远程还是可能爆出错误,所以再检查一下。 如果一切都没有问题。你可以将package中的Needs a sponsor改为Yes,然后等DD注意到你的包。当然,还可以向debian-mentors@lists.debian.org发送一封RFS(Request For Sponsor)的邮件,提醒DD的关注。具体的内容模板在成功上传的邮件中会提示你,一般是http://mentors.debian.net/package/rfs/[package name]这种格式。打开url,里面就是你的RFS邮件规范的目标地址,标题,还有内容。 OK,最后总结一下,整个过程中我们用到了三个系统。第一个是debian bts,通过提起bug来表示你准备打包。第二个是mentors.debian.net,通过注册来上传包。第三个是debian-mentors@lists.debian.org,通过maillist来提醒DD检查你的包。过程有一点小繁琐,不过熟悉之后还不算繁琐。如果真的觉得繁琐,debian在包检测和打包过程中的一堆事情更是会烦死人的。 Reference: [1].Debian 缩略语http://www.cnblogs.com/lidaobing/archive/2010/05/21/1740508.html [2].软件如何进入 Debianhttp://www.cnblogs.com/lidaobing/archive/2010/05/02/1726138.html [3].Introduction to the bug control and manipulation mailserverhttp://www.debian.org/Bugs/server-control

一次系统和数据迁移

Aug 18, 2011 - 1 minute read - Comments

在文件系统选型后,贝壳骤然发现用ext3保存媒体文件是一件很傻的事情。耗费空间多,性能差,安全性低。根据文章结论,其实最好的文件系统是xfs。同时,贝壳的mini-itx空间基本满了(/home分区75-80%)。所以,贝壳准备买一块新的硬盘,然后将数据迁移过去。 硬件选择上,贝壳询问了熟悉的硬件商。他说日立没货,WD的盘问题比较多,推荐希捷的。而且只有绿盘,具体型号是ST2000DL003-9VT166,SataIII,常规转速5900。ST的2T盘入手后,贝壳做了一下基础测试,hdparm分数是,原本的WD硬盘90M/s,新的ST硬盘70M/s,公司的硬盘99M/s。看来硬盘性能还是WD的比较好一点,当然,也可能是因为新硬盘本身就是低档硬盘。 贝壳的第一选择,是按照原本的U盘安装设置,安装debian系统。不过前后两次都可耻的失败了,主要原因是mini-itx对U盘启动的支持并不是很好。被迫,用新买的大型电脑安装,又失败。原因是6.0的安装镜像对boot.img.gz方式的U盘启动支持不良。算了,先装5.0升级。没想到,这个原因直接导致了贝壳两次系统安装完毕后无法引导升级。为什么?因为硬盘的尺寸刚刚好比2T大了点。gurb升级到grub2的时候,为了让你支持全部空间,很好心的帮你升级到了gpt。然而gpt需要一个分区来保存一些信息,新多出来的空间又刚好不足以保存这个数据。因此,grub-pc就升级失败,而且救都没法救——因为没空间了。 两次折腾下来,贝壳基本搞明白了为什么。然而要解决这个问题,就要手工分区,计算大小,产生lvm,设定,然后debootstrap,再设定。或者就直接使用debian 6.0的安装镜像。这个时候,悲崔的事情来了——U盘安装那篇文章的上一节,就说明了如何直接使用usb启动iso,直接cat iso > /dev/sdX就可以了。早知道这么简单,何必折腾那么一大套呢,哎。 debian 6.0的安装系统比5.0的好了很多,磁盘分区支持gpt,直接就生成了bios_grub分区。lvm2的支持增加了vg级别的控制,而不仅仅只能控制lv的生成和删除。同时增加了软raid的支持。这就很好的解决了贝壳当前的问题。 贝壳的分区方案是,gpt分区表,一个bios_grub分区,一个ext2的boot分区,一个lvm分区。lvm上面分8G的root,ext4格式。4G的swap,可以适应当前内存和升级到4G的内存(linux swap推荐是,4G以下两倍于内存,4G以上和内存一致)。1.7T的home,xfs格式。剩余268G。为什么要剩余?因为xfs只能扩展不能缩小,如果我需要扩展root和swap,或者需要产生新的lv来做虚拟机,不留下一定空间会出问题的。如果home不足,我再扩展150G基本可以解决问题。 分区和安装都很顺利,然而approx对新的系统基本没有缓冲作用。我略微想了一下,大概明白了为什么——原有系统是用i386架构和amd64内核,而新系统则是架构内核都是amd64。或者通俗来说,原系统是64位内核下的32位混合系统,而新系统是彻底的64位系统。32位的包对64位的系统一点用都没有,所以approx原有的包都白缓存了。 好吧,瑕不掩瑜,这次升级基本还是成功的。安装对应软件包,复制数据(推荐首次cp -a,速度快,后面用rsync保证同步),修改属主(否则很多程序无法启动)。尤其需要注意,mldonkey在downloads.ini中,不但保存了以哪个用户启动,同时也保存了用户id。新系统中用户名和id对应关系会发生变化,因此要修改正确。基本——事情就完了。 一个小细节是,uwsgi由于amd64升级,所以无法使用。贝壳解决了一下问题,重新编译这个包。另外,debian官方的包出来了,目前处于sid状态,大家可以等着什么时候进入testing状态了。