Shell's Home

uwsgi under debian

Sep 27, 2011 - 1 minute read - Comments

好了,debian官方的uwsgi总算出来了。包已经到了testing,stable暂时别指望了,等下一次release吧。这次打的包,比贝壳打的复杂多了。贝壳自己只打了python专用的包,debian官方的包将多个语言分别打成了plugins。 下面说说,使用debian官方的包如何做uwsgi发布,还是vhost模式哦。 首先安装uwsgi,uwsgi-plugin-python这两个包。uwsgi-plugin-greenlet-python也可以考虑,装不装看你的需求。 然后在/etc/uwsgi/apps-available/sites.xml下面写一个文本文件,内容如下: <uwsgi> <vhost/> <no-site/> </uwsgi> 再从/etc/uwsgi/apps-enabled/sites.xml链接过去,重启uwsgi服务,事情就搞定了。 默认的配置在/usr/share/uwsgi/conf/default.ini,可以看看是否都满意了。一般来说,master和no-orphans都建议打开,chmod-socket最高660,改成600应该也可以工作。贝壳的机器负载小,只用一个worker就够了,所以完整的配置是这样的: <uwsgi> <plugins>greenlet,ugreen</plugins> <workers>1</workers> <reload-on-as>128</reload-on-as> <vhost/> <no-site/> </uwsgi> nginx里面如此设定: location /asdf { include uwsgi\_params; uwsgi\_param UWSGI\_PYHOME /usr; uwsgi\_param UWSGI\_CHDIR /var/web/hosts; uwsgi\_param UWSGI\_SCRIPT main; uwsgi\_pass unix:/run/uwsgi/sites/socket; } 其中,我的程序放在/var/web/hosts底下,使用系统环境来运行(而不是virtualenv),主脚本(带applications那个)是main.py。unix socket和上文default.ini里面的socket正好对应上。 同理,我们其实还可以开多个uwsgi应用,只要放置多个xml配置就好。不过既然都采用了vhost模式,何必还开多个呢?这毕竟不是虚拟网站,要给其他人使用的。

合用两个路由器的几种方案

Sep 26, 2011 - 1 minute read - Comments

为什么用两个路由器?最常见的理由是延长信号。在超级大的场地中,中间放一个路由器,用四根线连接到周围的几个路由器上面,信号覆盖整个场地。这是最常见的理由。也有可能是因为你的主路由器LAN接口不足了。当然,也可能是因为蛋疼,或者其他原因。不论如何,为了在多个路由器上达到同时上网的目的,你有以下几个选项。桥接模式,路由模式,双层NAT模式。 我先解说一下一些基础的环境。我假定你有一个互联网线,有一个路由器的WAN口接到了互联网上面,这个路由器称为M。其他路由器分别称为S1,S2…。直接连接到M的LAN口的电脑称为ML1,ML2…,通过无线连接的就称为MW1,MW1…。同样,连接到路由器S1的LAN和无线的分别叫做S1L1,S1W1,类推。 1.桥接模式 这是你第一个应当尝试的模式,连接方法是路由器S1的LAN口直接连接路由器M的LAN口。这个模式不一定能够配通,原因是因为要求路由器S必须支持桥接模式。基于某些理由,很多路由器并不支持桥接。一般来说,有可能LAN口支持桥接而WIFI不支持。因此S1L1支持桥接成功的概率比S1W1支持桥接成功的概率高。如果你需要一台支持桥接的路由器,TP-LINK的TL-WR*系列路由器好像大多支持。希望大家补充哪款路由器支持桥接或者不支持。 桥接是将路由器S完全的作为一个交换机使用,所以你的ML1和S1L1在同一个网段,两者可以互相ping通,发送各种包,也可以看到对方的广播。这种模式一旦连接成功,连接模式是透明的。因此,应当关闭DHCP,只启用一台路由器的DHCP功能。或者最好手工分配IP。 严格来说,只有S是一个无线路由的时候,这个模式才叫做桥接。如果只做有线连接,这个模式应当叫做交换模式。 2.路由模式 路由模式,是一个比桥接复杂,效果好,但是用途相对比较窄的方案。接法是路由器S1的WAN口连接路由器M的LAN口,并且为S手工指定IP,再关闭S的NAT功能。M的网段和S的网段必须不为同一个网段,例如M配置为192.168.0.0/24网段,S配置为192.168.1.0/24网段。S的WAN口手工指定为192.168.0.2。然后在M1上配置人工路由,将192.168.1.0的所有包交由路由器192.168.0.2处理。并在S1上配置默认路由为192.168.0.1(M的地址)。 这个模式是将路由器S和M作为路由器使用。当S1L1发送包时,会被S1转发到M去处理。而M收到要发送给S1L1的包时,会交由S1处理。这一模式能够工作的基础是你能够控制M的路由表,并且S可以关闭NAT。通常情况下,这个S最好是OpenWRT/DDWRT。这也是为什么用途比较窄的原因,毕竟支持桥接的路由器好找,OpenWRT/DDWRT就相对小众了。 当这个模式连接完成后,ML1和S1L1在不同网段,但是两者可以互相ping通,发送各种包,却无法看到对方的广播。因此这种模式的效果比桥接好一些,因为地址范围更大,而且很容易隔离广播风暴。这种模式一旦连接成功,连接模式是透明的。 3.双层NAT模式 如果上两种模式都不工作,你就必须使用双层NAT模式。这种模式保证一定工作,但是在使用上比较麻烦,需要用户自行计算访问规则。 接法是路由器S1的WAN口连接路由器M的LAN口,并且将S配置为DHCP。M的网段和S的网段必须不为同一个网段,例如M配置为192.168.0.0/24网段,S配置为192.168.1.0/24网段。 S的数据包会被NAT两次再发到互联网上,要进行端口转发也必须配置两次。性能相对比较差,而且无法做NAT穿透。 当这个模式连接完成后,ML1和S1L1在不同网段,S1L1可以ping通ML1,但是反过来不行。因此,S1L1可以主动连接上ML1,而反过来不行。这种模式不是透明的,两者进行连接时必须考虑网络转换和端口转发。

密码管理规范

Sep 22, 2011 - 1 minute read - Comments

下面是贝壳自己总结的密码管理规范,大家可以参考一下。 概念解说 网络密码和本地密码。网络密码通常很难暴力攻击,尝试速度受到网络限制,而且尝试一定次数后还可能被管理员发现。而本地密码则相对比较容易攻击,我假定本地密码攻击可以达到每秒测试2\^30个密码。 密码长度推定使用如下计算方式。使用年数乘以攻击频率,得出攻击者在密钥使用期限内能尝试的最大次数。为了安全起见,尝试范围不应当超过总体密码空间的一定比例。以此推算出密码空间大小,进而推算出信息位数,然后还原为密码位数。 数字密码,字母密码,数字字母混合密码,大小写数字混合密码。数字密码的信息量是3.3bit/位,字母为4.7bit/位,混合为5.17bit/位,全混合5.96bit/位。 密码原则 一次一密。除了零级密码,不要为多个系统设定一样的密码。有些系统并不像我们想像的安全,一旦这个系统出问题,被还原原始密码,就会牵连到其他系统。 定期更换。没有什么密码能用一辈子。 写下来。因为一次一密,所以我们会有大量的散碎密码。不写下来是不保险的,写下来是不安全的。折衷一下,还是写下来,保存好吧。推荐用高级密码加密低级密码的方法,例如keepass。 生成型密码。用一个特定字符串+网站名,做sha-1然后取最后8位。这样的密码满足一次一密,不容易破解,不需要写下来,唯一的问题是你要现算… 零级密码 零级密码是有些不需要保护的情况下,又非设定密码不可。对于这种情况,你只能设定一个不算密码的密码。例如常用机器的用户密码。这些密码可以通过livecd/liveusb轻易修改,因此没有一点保密价值。 零级密码不需要安全性和保密性,因此好记就行。例如111,222,选一个常用的,爱用多久用多久。 低级密码 低级密码是用于保护一些你不希望别人看到,然而别人看到并没有直接损失的内容。例如家里机器的性能数据,普通相册的访问密码。这些内容被别人看到不会产生伤害,然而无成本的放出这些内容有潜在的风险,或是你自己主观意愿希望保护,内容安全性要求又不特别高。 我假定低级密码在网络上会受到100次/年的攻击,本地密码会受到1小时/年的攻击,可用时间五年,穷举空间不超过总密码空间的1/1000。 网络密码的攻击信息量为log2(100 * 5 * 1000) = 18.93bit。使用数字密码应在6位以上,字母,混合,全混合应在4位以上。 本地密码的攻击信息量为log2(2\^30 * 3600 * 5 * 1000) = 54.10bit。使用数字密码在17位以上,字母在12位以上,混合在11位以上,全混合在9位以上。 结论,低等级的密码长度小,使用数字也并不难记。推荐使用4位以上字母(反正混合使用长度也没有下降),不要使用常见组合还有单词。推荐方式是将自己喜欢的一句英文首字母简写前后颠倒使用。例如:I will be back,对应密码bbwi。 中级密码 中级密码用于保护一些你不希望别人看到,别人看到会对你产生损失的内容。例如你的帐薄,日记等等。中级密码使用时,最主要的风险已经不来自于密码本身,而是使用密码的环境。包括电脑是否安全,中途网络是否安全,旁边人的肩窥攻击。 我假定中级密码在网络上可能会受到10000次/年的攻击,本地密码会受到100小时/年的攻击,可用时间1年,穷举空间不超过总密码空间的1/100000。 网络密码的攻击信息量为log2(10000 * 1 *100000) = 29.90bit。使用数字密码应在9位以上,字母在7位以上,混合应在6位以上,全混合应当在4位以上。 本地密码的攻击信息量为log2(2\^30 * 3600 * 100 * 1 *100000) = 65.07。使用数字密码在20位以上,字母在14位以上,混合在13位以上,全混合应当在11位以上。 结论,中级密码开始,数字密码的位数就太长了,人类记忆很难记得。推荐使用8位以上字母密码,产生方式同上。 高级密码 高级密码用于保护一些有价内容,例如公司标书,银行账户。高级密码要注意更换,最长不要超过半年。 我假定中级密码在网络上可能受到1000000次/年的攻击,本地密码会受到8700小时/年的攻击,可用时间0.5年,穷举空间不超过总密码空间的1/10000000。 网络密码的攻击信息量为log2(1000000* 0.5 *10000000) = 42.19bit。使用数字密码应在12位以上,字母和混合应在9位以上上,全混合应当在8位以上。 本地密码的攻击信息量为log2(2\^30 * 3600 *8700* 0.5 *10000000)

悲崔的六类线

Sep 21, 2011 - 1 minute read - Comments

大家知道,贝壳家里用的是千兆交换机对吧?最近贝壳在装修(好吧,回头看情况,也许有装修手册出来),所以——布线的时候打算用六类线。 先普及一下常识,六类线和超五类的区别在哪里? 百兆网使用的是五类和超五类线,最大长度100m,接线规范使用EIA-768B,实际使用1236四根线进行通讯,频率100MHz。考虑双工后,可以在整根线上提供100Mbps的速率。而千兆网使用六类线,接线规范也是EIA-768B,但是实际使用了12364578全部接线(所以六类线必须全部连通,否则掉速,不要用五类的经验想当然)。频率250MHz,在整根线上可以提供1000Mbps的速率(别看我,我也觉得有点问题,资料来源wikiCAT-5CAT-6)。 为了在中间没有四根地线作为缓冲的情况下支持高速的数据传输,六类线通常使用22-23AWG的铜芯制作。尽管标准上允许24AWG的六类线出现,但是这通常是不堪使用的。而五类线和超五类大部分都是24AWG的线芯,粗细是0.51mm。23AWG线芯粗细0.57mm,22AWG粗细0.64mm。而为了隔离串扰,六类线中心通常有旋转的十字龙骨,将四对缠绕线分割在四个区域,防止电容效应干扰。 OK,有了基础常识,我们可以讲一下京东的问题了。他们提供的线问题其实很简单。有一箱线在中间有部分区域十字龙骨缺失。 如果我买的是普通线就算了,5元多一米的秋叶原线,在京东这种商城,居然会在中心位置龙骨缺失。我很怀疑我埋下去的另一箱是否也有类似问题呢。 更郁闷的是,我打给京东,他们的客服不道歉就算了,也没个活人出面解释一下这个是什么问题。就只有“你可以退货阿”,“你这样就可以退货拉”,的提示。退退退退你妹阿,尼玛另一根线回头出了问题我得重新埋线呐。更可气的是有个客服脑子堪比芙蓉姐姐,给我一个厂家电话,让我打给厂家。我说如果厂家不予解决呢?她说,你可以再打4006065500转3。我说那不就是你们的电话么?她说,你可以再打4006065500转3。我说是不是再打到你们这里?她说,你可以再打4006065500转3。。。尼玛你是鹦鹉阿,直接说再打我们电话不就完了么。再说了,你给我的方案就是打给厂家,厂家不解决,再打给你,你再咋办?哦,对了,这时候就不是你办了。真是好办法。 可见在天朝这种地方,产品质量是完全不用关心的,有退货就是最大的慈悲了。至于产品造成了后果,赔偿什么的。售后经理笑脸迎人,可以阿,有检验结果我们就赔。问题是TMD国家质检中心不给力阿,不但价格贵,而且很多事情根本不检。你不信在07年拿瓶三聚氰胺奶过去,就算清清楚楚的告诉他们有什么问题,得到的答复还是——抱歉,我们没这个检验项目。再说检验通过,厂家立刻变脸,抱歉,这个我们有规定,只能赔偿多少。然后你只能进行漫长的“调解-仲裁-一审-二审”过程。厂家有的是时间精力,不怕玩不残你。就算你侥幸通过,终于能获得赔偿,听上去天价的赔偿还不够你的时间成本。更不谈有些事情,损失十多万,按国家规定赔偿只有不足千元——“因为国家就是这么规定的”。

给初创小公司的几句话(四)

Sep 16, 2011 - 1 minute read - Comments

第四个故事来自一个朋友的笑话。说某人从一家公司辞职了,朋友问说什么情况。某人说,和老板相处不来。老板看到有人上班看网页,就出了条规定,不许上班时间看网页,否则罚款。看到有人带朋友进办公室,就出条规定,不许上班时带朋友进办公室,否则罚款。上个月老婆出差,没人照顾家里的仓鼠,带去两天,出条规定,不得带宠物上班。某人情感受到了强烈的伤害,所以愤而辞职。 其实说起来,这些事情都不是什么大事,鸡毛蒜皮到了我们可以当笑话说的地步。细究起来也确实是员工应当执行的,属于正常雇员的基本素养。不过如果您自己开家公司,照着上面的做,搞不好手下还真就一堆辞职的。 从某种意义上说,这是一个心理问题。在IBM,或者Oracle这种大公司,出现这些条款没人觉得有什么不对,关键在于两点。一方面,大公司本身就给人一种正儿八经,板着个脸的印象。员工进公司的时候,就知道自己随时会碰到各种狗屁倒灶的规定,有一定的心理准备。小公司通常老总天天见,搞不好下班还一起吃饭喝酒,上班的时候板起脸来做规矩,情感上受得了受不了就不好说了。另一方面,大公司的规定相对完备,什么可以什么不可以都规定的非常详细。小公司难免挂一漏万,天天改规矩,确实不怎么好看。 反过来说,这也是初创公司对大公司的优势。在大公司里,管理层显然不会留意到每个人的特性,并且针对性的管理。然而初创公司就那么几号人,大部分都是熟人。要针对管理不是一件不可能的事情。老婆出差,家里仓鼠可以带到公司,顺便睡在公司做程序得了,反正家里也没人。诸如此类的事情并不怎么难做。当然,当初创公司上了一定规模(推荐大概是10-30人)后,管理转换必然要产生阵痛。然而也远好过在三两个人的公司里面规定四五十条的规范。

gnupg的基础概念

Sep 15, 2011 - 1 minute read - Comments

上次gnupg签名写完后,雨苍跑过来问我gnupg里面的一些细节,讲,为什么不写清楚呢?我说不是写过一篇gnupg基础么?回去翻blog,居然没有!好吧,那就现场写一篇gnupg的基础概念。 非对称密钥 gnupg是一种签名/加密系统,通常而言,多数被用在mail和deb包签署上。普通加密程序的最大区别在于,gnupg是一种公钥/私钥结构。 我们简单点说,你可以用gpg --gen-key生成一个密钥对(是的,一次一对密钥),一个密钥对包含一个公钥和一个私钥。公钥是公布在网络上的,私钥自己持有,并且可以加一个密码,以防私钥泄漏。学过非对称密码体系的同学应该知道,公钥加密,私钥解密,私钥加密,公钥解密。因此,这个密钥对可以用于签署。方法是,对你的目标数据进行哈希,然后使用私钥加密这个哈希,得到签名数据。如果别人可以用你的公钥解密这个签名数据,然后和目标数据的哈希对比,那么这个数据就一定是私钥签署的。 附加资源 下面是最精彩的地方。一个密钥对里面,其实不仅包含一对密钥,而是包含多对。刚刚生成的公钥(pub)和私钥(sec)这对,被称为主密钥。而除去主密钥外,还可以加入三种资源,子密钥,uid,签名。 子密钥是另一个合法的对称或者非对称密钥。子密钥的常见用途是延长密钥的可用期,或者提供不同强度的加密(通常是减弱)。 密钥长期被用于加密数据后,可能会被已知明文攻击,因此一般密钥都有一个合理的使用周期。对于大量加密数据的人来说,这个合理使用周期可能比较短。看过上一篇互相签署的应当知道,对一个密钥每三四年乃至一年就签署一遍太麻烦了。因此,你可以使用子密钥。这个密钥的使用和吊销就比主密钥更加方便,生成一个,用六个月,然后废弃。而使用主密钥签署过的子密钥,同样可以认证该密钥属于某人。 uid则是认证这个人的合理名字,主要是姓名,昵称,邮箱。通过主密钥签署,别人可以认可这个网络身份真实的属于你。 签名则是别人对你的uid的认可。一般一个uid上可以有一个或者多个签名(至少需要自己主密钥的签名)。 常见参数选择 主密钥过期时间,建议选择5-10年,推荐10年。因为主密钥过期后需要重新签署,每三四年就重新签署一遍你的密钥实在是太麻烦了。 主密钥长度,我建议选择你能选择的最长长度。因为主密钥有相当长的过期时间,过短的密钥很快就不实用了。在2000年的时候,1024位还是比较安全的,但是2009年,RSA-768被成功破解,威胁到了1024位密钥的安全性。目前debian推荐密钥都是4096位长。至于对此造成的计算压力增加,你可以通过子密钥来解决。 主密钥一般是RSA的,gpg -k可以看到4096R之类的标示。 公钥的网络管理 上面说到,公钥需要公布在网络上。现在网络上就有一种专门的服务器,用于提供公钥的上传和管理。我用的是pgp.mit.edu,很有名(主要是比较短,好记)。你可以在上面放置一个你的公钥,里面附加各种uid和签名,吊销凭证,等等。 文件签名 密钥对可以对文件进行签署,生成分离的(.sig文件)或者内含的签名。签名方法是gpg -s,你可以用gpg --verify来验证。 FAQ: Q: 有什么机构对gpg进行认证么? A: 这个真没有,虽然你可以从公钥服务器上获得很多人的公钥,但你无法确认他们的身份。确认身份唯一可靠的办法就是线下交换fingerprint并且签署。作为替代,完全信任和勉强信任也部分的可靠。 Q: 签署和加密有什么区别? A: 签署表示这个内容是被你确认过的(由你发出或者经你许可),所有人都能看到。加密表示这个内容只有你能看到,所有人都能发出。如果你打算给一个人发送一个内容,内容是经你确认的,并且只想被他看到。你可以同时签名和加密。 Q: 签名可以伪造么? A: 这个应该不行,如果可以,你可以写个paper,全球奖金就数百万美元,更不提领域上的名声。 Q: 国家可以调动专用服务器来进行破解。 A: 目前已知破解的最长的密钥是RSA-768,长度768bit,因此1024位密钥有可能被政府机关破解。然而破解难度随着位数增加以几何级数增长,因此2048位的破解目前还遥遥无期。目前而言,2048以上长度的密钥还是无解的。 Q: 真的不行么?我知道各国军队都有保密的研究成果。 A: 如果你相信所谓的“秘密成果”,我也无话可说。仅公共领域流通的成果而言,离可接受的破解方法还差很远。目前已知最好的算法是普通数域筛选法,有希望成为可接受的破解方法的是基于量子计算机的Shor算法——不过量子计算机还没有制造出来。 Q: 既然2048位密钥不可破解,为什么还要选择4096位? A: 一个不幸的事实是,虽然破解难度随着位数增加几何级数增长,然而破解速度随着时间流逝也在几何级数增长。如果你打算长期使用,还是使用4096位的比较保险。

北京,北京

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%每年的时候,公司基本失去功能。因此老外的罢工可不是闹着玩的。 和员工商讨规则,并且连自己也需要遵守规则,这在保证员工利益的同时,也让他们感到参与感。参与感会增加他们归属于这个集体的情感,从而帮助你发现和管理问题——一切都是自发的。更妙的是,即使薪水略低,员工也很少离职。当然,作为双刃剑,你要知道,有的时候员工会联合起来进行薪水谈判。如果双方都是理智的进行谈判的话,我相信对于一个健康的软件公司,这只会让他更健康。当然,更重要的是,你需要自己遵守自己的规则,让规则成为权威。