Shell's Home

为什么恳谈行不通

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状态了。

除虫故事(三)

Aug 17, 2011 - 1 minute read - Comments

第三个bug是刚出的,贝壳刚刚从现场回来,提交了bug系统关闭申请。 问题是这样的,我们有一套系统,为客户提供从web访问某台windows的能力,作为管理系统使用。这个系统的后台使用了三四个不同的程序,通过管道通讯。目标设备上有一个组件,要适应2000/2003/2008的32位和64位环境,非常复杂。最近,贝壳将这套系统的目标设备的组件进行了重编译,提供了64位版本。然后测试发现,32位系统不工作了,64位系统正常。 第一反应是什么?一定是组件有问题?贝壳在服务器上,直接使用连接程序去连接,结果是成功的。这个表明组件应当是正常的,或者部分正常。问题就在web页面到连接程序的过程中某处。 负责web界面到连接程序的工程师同事接手了下一步排查,他也是一头雾水。系统看来一切正常,连接程序明明可以工作,为什么从web页面调用就会失败呢?而且只有32位会失败。web页面对CPU字长(而且是目标设备的CPU字长)并不敏感阿,这个听起来不合理。 测试过程中,测试部门的同事偶然的看了一下日志系统,发现了问题。我们的连接程序会写出日志,默认情况下这个日志的属主应当是web.web的,而当时的日志是root.root的,而且权限是644。所以当连接程序被直接调用,当前id是root,就可以连接成功。而连接程序被web调用,当前id是apache,日志写出就会失败,程序就挂了,目标设备会失去反应。 出现这个错误的原因也很直观,在某次调试后,有人删除了原始的日志,并且直接执行了连接程序。但奇怪的是,同样是连接程序挂掉,为什么64位就可以继续执行呢?我们讨论不出为什么,只有基本猜测,64位设备是2008,rdp服务版本比较高,所以相对健壮。 所以,实际的错误是两个。一个是日志权限导致的连接程序不工作。另一个是64位下不正常的连接程序依旧可以工作。 好吧,总结一下这个奇怪的问题中的教训。 1.隔离最小差异。要验证是否是组件升级导致问题,一定要进行旧组件测试,然后再测试新组件。万不可假定旧组件可以正常运行,直接测试新组件,从而将非组件问题带入排查。 2.单元测试隔离。每个部分都要做单元测试,如果测试通过却无法连接,那就是环境问题。再查不出,再检查通讯/调用记录。 3.通讯系统关联错误。当两个程序通过通讯工作,其中一个程序死亡时。另一个程序应当能够检测并且报错退出,而不是出现各种异常反应。 4.日志底线设计。程序一定要写日志,如果日志写不出,就写系统日志,再写不出,设法报全局错误。

ACC lead to no core temp reading?

Aug 16, 2011 - 1 minute read - Comments

I bought a Phenom II X4 955 CPU month ago, recently I find that HWMonitor can’t read core temp, just motherboard temp. I googled it and find this article. This article said that ACC is a tech will make AMD X3 work like X4 byunlock cores in BIOS. But CPU core temp sensors will not work, even use a real four cores CPU. 贝壳一个月前买了一块羿龙IIX4955(黑盒),但是最近发现HWMonitor读不出核心温度,只有主板温度。放狗搜了一下,找到这篇文章。根据这篇文章说,ACC是一种能够让AMD三核CPU像四核一样工作的技术,只要在BIOS中打开unlock cores选项就好。但是这个会使得CPU的核心温度传感器不工作,即使你真的有四个核,而不是仿冒四核。

linux下的文件系统选型

Aug 15, 2011 - 2 minute read - Comments

贝壳原来一直认为文件系统可以随便选,结果最近吃了两次苦头。一个是btrfs对虚拟机支持不良,另一个是特定情况下xfs性能比ext3高20倍。痛定思痛,打算列一下文件系统选型的方法和依据,欢迎拍砖。  下面我列一下纳入参考的文件系统,当然,ntfs就不要出来搞基了,玩嵌入式/光盘live之类的朋友也不要来凑热闹了阿。btrfs(简介), ext3, ext4(简介), jfs(简介), reiserfs, xfs,基本涵盖常用文件系统。最下面加入ntfs和zfs对比,实际上不参与选型。以下进制换算为1024,大小依次为KB,MB,GB,TB,PB,EB,ZB。 --------------- --------- -------------- ---------------- ---------------- ---------------- ------------------ --------- ----------- ------------ 文件系统 btrfs ext3 ext4 jfs reiserfs reiser4 xfs ntfs zfs 最大卷容量 16 EB 32 TB 1 EB (16TB) 32 PB 16 TB ?? 16 EB 256 TB 16 EB 最大文件容量 16 EB 2 TB 16 TB 4 PB 8TB 8TB 8 EB 16 TB 16 EB 目录结构 B tree list/tree list/Htree B tree B+ tree dancing B\* tree B+ tree B+ tree hash table 文件分配 extents bitmap/table bitmap/extents bitmap/extents bitmap ?