Shell's Home

Jul 1, 2014 - 1 minute read - Comments

狗肉节

吃没吃过狗肉 吃过,还不止一次,不过自己没点过。没特别觉得好吃,也没觉得难吃——我始终觉得我的味觉不算很灵敏。有次吃河豚也是完全没吃出来,一直以为是别的。别人告诉我了,我还奇怪这东西为什么被称作天下至鲜。 如果是我点菜我会选择鸡,味道好又没有什么奇奇怪怪的麻烦。不过已经点了狗肉拿上来了,我也不会有特别的避讳。大部分的食物,只要没有违法,对健康无害,我都没什么忌讳。反倒是猪脑什么的不大敢吃——神经节太密集了往往会想到朊病毒,心理有障碍。 我觉得都已经做成食物了,就别矫情了。浪费了才是不好的事。 不吃狗肉的理由 说不吃狗肉的,往往是几个理由。 萌。 屠宰方法太残忍。 狂犬病问题。 当然,不吃猫肉的理由也大同小异。 我们首先说狂犬病。狂犬病毒加热后会迅速死亡。别说煮熟,就是加热到90度,基本也会全部失活。吃狗肉会感染狂犬病毒唯一地点,就是在狗贩子身上。可身为一个狗贩子连狂犬疫苗都不打,这纯属no zuo no die。以危害狗贩子的安全制止吃狗肉不合理。后面会说有一种和狂犬病有关的理由,阻止随意购买狗肉是合理的——当然不是吃狗肉本身。 其次是屠宰方法太残忍。那后面问一句,如果我们用一些比较文明的屠宰方式。例如单独带到隔间,一板砖拍晕,然后再下手,行不行?爱狗人士又往往会摇头,不行不行,太不文明了。我了个去,菜市场当街杀鸡杀了多少年,也没见谁有意见,轮到狗身上就太残忍? 其实说穿到底一句话,萌才是一切的根源。 狗是否特殊 我认为即使是人都不特殊。人是万物之灵这种话,基本就是骗骗自己满足人类自己的自大心理的。 之所以我拒绝认为人是一种食物,主要是出于伦理考虑——如果人可以作为食物,那么人和人相残的世界未免太残酷了。 所以你问我,狗作为一种经常和人类相伴的生物。让孩子知道狗也会被端上餐桌是否太残酷了?我觉得你说的有道理。 但是。 你可以请求别人不吃狗,但是你不能强迫别人不吃狗 关于不吃某种东西,我觉得这应当成为一个最简单的共识。我不吃/别让我吃/别让我看到你吃,这没问题。你告诉我,我也会配合你尽力避免。你要吃,我不强迫,这是底线。在此基础上,你可以劝说。对食品的偏好是每个人的事情,只要不吃人都好商量。更没必要为了这种事情,弄出种种奇怪(甚至违法)的手段来。甚至有时候,吃不吃没什么,手法惹人厌。 当然,最后我得说。这种奇奇怪怪的爱狗人士是少数。谢天谢地。多数的人只是在网络上声讨“狗狗那么可爱你还要吃它,有没有天理良心啊”。现实中他们既不吃素,也不一定会跑去做什么实际性的事情。只是简单的在网络上抒发自己的观点而已。如果我要表达一下自己的观点,告诉她我觉得牛和羊很萌能不能请你不要吃牛羊肉了—— ——你神经病吧。 虐狗逼迫爱狗者买下的事,你怎么看? 很明显,那不是吃狗肉的人干的事,这是狗贩子干的,而且很下三烂。也只有买卖狗肉不当回事的人,才能想出这种抬价的办法。 那反对吃狗肉的也许说了,没吃狗肉的人,也就没有这种事了。问题是这个逻辑,没有爱狗的人好像也成立。 至于有人说这是爱狗者找托来做秀,我只能说,没看到只能当没有。 我始终反对拿着钱来做出一些开外挂一样的解决方法——千年之前就有子贡赎人的故事了。国宝回归如此,吃狗肉也如此。他们知道有你们这群冤大头,东西就会越卖越贵了。你要是觉得,贵就可以阻止人吃狗肉了。呵呵,别忘了贵了偷狗的生意也会好。 吃狗肉和虐狗是两码事 不只是狗,包括牛羊,猪鸡。我都觉得,吃是一回事,虐待是另一回。我吃猪肉,但是如果说养猪的每天都对着猪一通抽——我觉得这个叫虐待。很奇怪对吧。宰都宰了,吃都吃了,还觉得抽一顿是虐待。 关于虐待,有一个很重要的区别是——不杀不食,不造成不必要的痛苦。我们感谢所有为了我们口腹之欲牺牲的生物,但是还是会毫不犹豫的吃掉他们。我觉得仅此而已的话,不算虐待。 农业虐心的地方在于,你对你的产品有感情,而生产他的目地就是牺牲。你养了一头可爱的小羊,每天照顾,很有感情。过了两年,一刀杀了吃肉。虐不虐心? 但这是必要的。农业中很多行为,都是很残忍但是必须的。包括阉割,密集养殖,屠宰。在整个过程中,我们提倡尽量简单无痛。但除此之外,我真的没法赞同把屠宰作为一种虐待的看法。更无法赞同的是,认为屠宰是一种虐待的同时,还在吃肉。 如果你认为,屠宰本身就是一种无法容忍的暴行,而非仅仅对狗成立。那么最起码的,请素食。 是否赞同动物保护立法 我很同意针对动物保护立法,尤其关于吃狗肉这块。主要目标到不是狗很萌——而是是否能有效控制狂犬病。 流动的狗贩,往往会偷狗,随意捕捉,野蛮宰杀。中间还有狗丢了之类的事情,往往会引起疫情转移,对于狂犬病控制不利。即使是街头上的野狗,如果做过防疫措施,能够增加免疫基数,也不应当被捕杀。为了控制这点,就不能随意在狗贩子那里购买食用狗肉。而理所当然,在街头购买饲养用犬也应当受到控制——原因相同。但是动物管理单位的捕捉甚至捕杀,应当受到保护,而不是阻挠。而城市中饲养大型犬,那是另外一个话题,此处不展开。 相比个人喜好,狂犬病控制是更加关系到民众生命和每个人的税收使用的事情。为这样的事情立法配合,我觉得是值得的。但是我想这样的说法,对爱狗者来说未必能完全赞同吧——不能随意买狗,要上牌照,动物管理单位还是能够捕杀,而且还可能有人合法的养肉用狗。如果你对这些事情感到不快,不妨反思一下。困扰你的,究竟是“只是我个人想轻松的爱狗而已”,还是“为了能让狗狗和大多数人相处的更自在”。 当然,就我个人的了解。这样的理论在农村地区是很难得到实现的。因为农村地区人多,狗也多。要捕捉-免疫-放回,没钱。控制狗贩子,没动力。所以往往是考虑的很好的动物保护立法,到了农村以后立刻变了味。往往就容易变成抓到狗贩子-罚款的生财之道。至于提供捕捉-免疫的事情,就当没听过。 让爱狗人士去农村免疫-放生?后面又会被捕捉。实话说我一直很困扰,爱狗者拦下来的贩卖狗肉的卡车,上面的狗都怎么处理了?都被领养消化掉了?还是放生了?放生后有没有再被抓? 归根到底,狗狗的问题不仅仅是狗自己而已。 不负责的养狗人比狗贩子更可恶 不服来辩。

Jun 30, 2014 - 1 minute read - Comments

docker的原理和类比

从虚拟化的种类和层级说起 cpu虚拟化:可以模拟不同CPU,例如bochs 完全虚拟化:只能模拟同样CPU,但是可以执行不同系统,例如vmware 半虚拟化:guest必须打补丁,例如Xen 硬件虚拟化:可以当作获得硬件加速的完全虚拟化 系统虚拟化:host和guest共享一样的内核,例如Openvz 语言沙盒:只能在语言的范围内使用 虚拟化的级别越偏底层,速度越慢,用户越难察觉到虚拟化的存在。 虚拟化的级别越偏上层,速度越快,用户越容易感知。 cpu虚拟化和完全虚拟化时,用户几乎可以不察觉到虚拟化的存在 半虚拟化时,guest内核必须存在补丁 系统虚拟化时,用户不能控制自己的内核 语言沙盒时,用户没有使用api的自由 docker的实现结构 docker lxc namespace: 仅沙盒隔离,不限制资源。 cgroup: 仅限制资源,不沙盒隔离。 aufs image管理 当然,还有很多细节的东西,里面就不一一列举了。例如veth。 docker不是虚拟机 docker不是虚拟机,因为lxc已经是虚拟机。如果两者功能一样,那么docker就没有存在的必要。 你可以把docker当虚拟机用,但是当虚拟机用的话,他的完备程度远远不及现在的种种虚拟机。相比之下,就会觉得很不好用。这不是docker的错,只能说被不正确的使用了。 docker是什么 docker就是环境。 docker实际上只做了一件事情——镜像管理。负责将可执行的镜像导入导出,在不同设备上迁移。 原本我们发布软件有两种方法,源码发布和二进制发布。二进制发布又有两种方案,静态链接和动态链接。最早的时候,我们发布软件都喜欢动态链接,因为小。但是随着网络和存储的升级,软件越来越喜欢静态链接,或者把动态库打包到发布里。因为系统情况越来越复杂,依赖关系一旦出错,系统就无法启动。 将这个思路推到极限,就是虚拟机发布。早些年有人发过一些Oracle的linux安装镜像,算的上是先驱。因为Oracle早些年的安装程序很难用,对系统的依赖复杂。公司做测试用装一套Oracle还不够麻烦的。相比起来,下载一个虚拟机直接跑起来就可以用就方便了很多。即使性能差一些,测试而已也不是特别在意。 docker再进了一步。不但提供一个镜像,可以在系统间方便的迁移。而且连镜像的升级都能做掉。更爽的是,升级只用传输差量数据。当然,有好处就有牺牲。 docker的镜像是只读的 其实不是,docker的镜像当然可以写入。但是写的时候有几个问题。 如果对镜像进行写入,aufs会将原始文件复制一次,再进行写入。这样性能比较低。 更直接的问题是,一旦对镜像做了写入,就无法从docker这里获得更新支持——docker不能将你的写入和上游的更新合并。因此,整个系统就退化成了一个完全的虚拟机。 所以,我个人认为,docker的镜像本身应当是只读的——如同EC2里面一样。数据的写入应当通过远程文件系统或者数据库服务来解决。 vagrant 提到镜像管理,我们可以提一下同样属于镜像管理的一个软件——vagrant。 可以将vbox的镜像打包导入导出 提供了一个cloud,允许镜像的分享/更新 为什么vagrant不如docker出名 快,系统级虚拟化使得docker的虚拟化开销降低到百分级别以下。 可以在虚拟机内使用的虚拟机,例如云主机内。 资源调度灵活,不需要将资源预先划定给不同的实例,在不同资源的机器上也不用调整参数。 成功案例 编译系统/打包系统/集成测试环境 典型的搭建一次,执行一次,销毁一次。不需要对image做更改(准确说的需要做更改,但是不需要保存)。 公司内部应用 在IaaS的比拼中,以Openvz为代表的系统化虚拟化方案几乎完败于完全虚拟化/半虚拟化系列技术。就我和朋友的讨论,这里面最主要的因素在于。完全虚拟化技术可以比较好的隔离实例和实例间的资源使用,而系统虚拟化技术更偏向于将资源充分利用。这使得系统虚拟化更容易超售。 然而,在公司内部应用中,这一缺陷就变成了优势。企业的诸多系统,只要在同一个优先级,其可用性应当是一致的。几个联动系统中,一个资源不足陷于濒死的情况下,保持其他几个系统资源充足并无意义。而且总资源是否足够应当是得到充分保证的事情,企业自己“超售”自己的资源,使得业务系统陷入运行缓慢的境地一点意义都没有。 因此,系统虚拟化可以为企业级云计算提供可以灵活调度的资源,和非常低的额外开销。 当然,云计算在企业化中原本就面临一些问题。原本提供软-硬件统一解决方案的集成商,需要如何重新组织解决方案。如何协调节约资源和高性能,高可用。云计算在企业级应用中还有很长的路要走。 短板 太新。目前成功案例还是不足,而且围绕docker的工具链还不完备。 适用范围比较窄。需求需要集中在“环境迁移”领域,而且image本身不应被写入。 生不逢时。rvm和virtualenv已经在前面了。

Jun 26, 2014 - 1 minute read - Comments

核聚变?

最近看到一篇文章極限DIY之核融合反應爐。昨天和朋友吐了不少槽,我总结一下。 真实性 首先,我不会质疑这篇文章的真实性。因为如果要评价一个实验的话,最基础的,这个实验的基础原理必须公开以供复现。他的基础原理是什么?聚变反应方程是什么?是否能够复现?文章本身,一点细节都没说,发布者也不是什么国际知名单位。这种情况下,质疑这篇文章的真实性是徒劳的——因为你都不知道从哪里入手。 先说明一点。我对核物理完全一窍不通。如果以下有错误,请指出。 按照原料为重水,没有提到氚,我推测聚变是D-D反应。D-D是经典的聚变方程,但是其反应式有两个,产物分别是32He + 10n和31H + 11p,分别放出质子和中子。但是两者的反应条件,质量损失均有不同。 由于不知道聚变原理(作者说是电场陷阱,但是不知道如何产生的,强度多大),所以这个系统的基本特性无法评价——就算不要求输出大于输入,最起码输出/输入比,反应速率是必须的。而且正常来说,做了实验,最起码测试一下质子和中子强度。对比装置对质子和中子的吸收水平,推断原本的辐射强度,倒过来计算两个反应的反应速率。这应当是一个完整实验必须做的。 有了放射强度的测定(完善的还得计算测定精度),计算出来的反应速率,就可以推算出理论输出值。配合上输入值(这个计算需要了解作者的电场陷阱原理),大概就能推算出理论输入/输出比。然后对比实际的输入/输出比,能够对装置运作的基本情况给出一个评价。 是否因为知识产权保护所以封闭细节 他又没做到输出大于输入,有什么知识产权保护的必要呢?写成paper发才是正常的做法吧。 为什么这么罗嗦 因为科学的基础必须是严谨,可复现。 很多人以为万有引力就是牛顿头上砸了一个苹果,然后感慨自己为啥没这个运气。当然有不少人脑子还比较清楚,小时候脑袋上砸了不少东西也没想出什么来,改为感慨自己为啥没这个天分。其实苹果的故事最多只能作为传说而已。 万有引力的基石,是第谷(1546-1601)的海量天文学观测数据。有了这些观测数据,开普勒(1571-1630)的行星运动定律才站的住脚。有了开普勒的行星运动定律,万有引力(牛顿,1643-1727)才能作为一种学说被提出来,并且有机会得到验证。否则要凭借想象想到,物质间实际上是具有非常微弱但是强大的引力的——对人类的想像力实在是太大的挑战了。即便有人能想到,也绝无可能说服大多数的人。甚至有机会进入实证。 当然,万有引力最具说服力的支持,是卡文迪什(1731-1810)的引力常数测试实验。卡文迪什以那个年代近乎艺术性的测量精度,将这一量精确的测定了出来——顺带一提,即便在现代,万有引力常数的精确度依然是所有物理常数里面最差的。 所以呢?我想说什么? 高精度的定量测量,才是物理学的生命。物理学家毕竟不是在玩弄数学技巧,整出一个漂亮好看的方程,就完事了。 我在感慨什么 我不知道作者是天才还是民科。但是我看到无数人在那里叫好——你在叫好之前,难道就不知道简单看一下作者讲的细节么?他又不是没贴。 如果看了一下仍然叫好,我觉得纯属一点科学精神都没有了。上来就酸“怎么可能”,“你算老几”我觉得到也不必——毕竟作者也没有公布细节,就凭作者个人能力否定成果未免鲁莽。但是我绝对不认同,仅仅因为“精神可嘉”,就无视物理学基本精神,在没有技术支持和复现前,对一项实验大加赞赏。 我也顺带吐槽一下作者的文,说这是实验文不如说这是软文。通篇到头就在讲装置怎么难做,自己怎么困难。一没说基本原理,二没计算过程,三没测试数据,四没装置的设计制造图。说国外看到类似的设计,可是reference完全看不到。这些都算了——连装置的设计目的和输入输出功率都没有。你真的是在说技术么? 下面会发生什么 如果是正常情况,大概会有同行复现。能复现的发文说OK我复现了,不能的就开始联系和质疑。 以作者的名望,大概不会有学者认真的想去复现。不知道作者有没有意思主动联系同行做复现。如果有的话,同行复现一下结果就出来。如果没有的话,大概会变成主流学界不搭理,作者感慨自己受到冷遇,然后网友们就是就是两句——这样子。 参考 核聚变 第谷·布拉赫 约翰内斯·开普勒 亨利·卡文迪什 艾萨克·牛顿

Jun 9, 2014 - 1 minute read - Comments

上海的出租车越来越不像话了

事情 5月24日,我乘一辆出租车从玉兰路杜鹃路到纪念路汶水路。上车第一时间,我报了目的地,然后脱口而出的是走外环。司机纠正了我这点——外环太绕路了。我说对对,您怎么走。他说南浦大桥。南浦大桥能走么?我说不知道,您走吧。 OK,30分钟后,我就发觉好像不对。计价器已经高达了50,而目的地还没有影。我没和司机说,我岳母家就在旁边,这两个地点我经常来返,一般都是40-50之间。 到地方一看,80。我擦。。。算了,公司有事,回头再处理。 办好事情,回头打电话给法兰红,报上车号证号,上车下车时间地点。完了回复我说,7个工作日之内给回复。我说OK。 过了几天,等等不来电话,我再去打了一次。法兰红接电话的人也很奇怪,已经转给他们了,怎么还不回复呢? 今天(6月6号),实在忍不住了,再打了一次。法兰红的人直接给了宫霄的电话。打到宫霄去,差点没把我气死。 他首先慢悠悠的说,上车你怎么和师傅说的?我说外环。他说你都要走外环了,还指责师傅绕路? 我了个去,我要去北京路不小心说了个北京,然后说不对不对。师傅真给我开北京去也合理?何况当初师傅已经说了,外环太绕,走法不对。这明显是口误还拿来说事。 然后他说,师傅这个不算绕路。你上车时让师傅随便走的,师傅按照自己的判断走的。 我当场就骂娘了。我XX你个女性直系亲属的,说了随便走就可以随便走啊。你让客人到你家随意,是不是他XXXX你个女性直系亲属你也随意啊。当晚我反向打回来,大众的车,只走了14公里。你的师傅走了23.3公里,这叫判断?是判断能多赚我多少钱么? 他又慢条斯理的说,师傅开的时候说了往南浦大桥走的啊。 我擦,我上海盲,去那里只知道一条道——大连路。还有好像内环也行(这就是口误成外环的原因)。师傅说哪里更快,我就说跟着走啊。不是这次我哪里会去查“从玉兰路杜鹃路到纪念路汶水路”的路里面“是不是走南浦大桥不合适”呢? 电话对面的沉默了一会,又说,按照师傅的判断,在那个点走大众那条路会堵的更厉害。你上车的时候也说快一点的,现在不认了? 我OO你个XX,..你个**。绕路不往市郊绕,绕到市中心去了?你说大连路隧道会堵车,杨浦大桥会堵车,我不敢说不会。你说从南浦大桥开过市中心比他们更空,我还真不信了。何况这条路一绕就是10公里,本来一个14公里的路,总共24公里你能开到25分钟以内?我TMD的老老实实走预期也就是半个小时而已。为了省5分钟(还没准),多花60%的车费?你脑残还是我脑残?而且从结果来说,更快了么?结果还是半个小时开到。 更何况,公司的同事从张江打车到同一地点,47元,半个小时多点。充分证明当时事实上就没有堵车,唯一对堵车的判断只来自于驾驶员的内心。 对面沉默了一会,又和我扯师傅当时自己的判断。我懒得和他罗嗦。“自己内心的判断”用在每个绕路案例上都是一个无法驳斥的东西——你不能指着一个人说,我知道你内心里明知道这是绕路的,You know it。既然无法驳斥,索性跟他说我会打回法兰红,就这样吧。然后挂了电话打回法兰红。 值得玩味的事在后面。法兰红的人听完整个流程,一言不发,给了我上海市运管处的电话。照理说作为管理母公司,你觉得我不对应当直接告诉我“师傅是对的”。如果你觉得我对就应该直接处理。运管处电话可能把没事的事惹出事来。给我运管处电话,基本只有两种可能: 运管处肯定会打太极,或者什么都不做。所以拿运管处当挡箭牌。 这件事我们也有难处。索性简单点,你有本事再往上面投诉。投诉出了结果,也没人有话说。但总之我们这里我没法帮你处理掉。 我打给运管处,他们说接受投诉。然后又是一通车号证号的,然后等回复。 分析 无论如何,宫霄出租车公司在管理上至少有以下几个瑕疵: 七天内不回复。没什么好多废话的。 根本没给乘客选项。在整个乘车过程中,出租车司机就没提供过“大连路隧道”和“杨浦大桥”这两个选项。如果你要用一个绕路的方案,至少要告诉乘客,可以走大连路,但是会堵。最后“大连路隧道”是我和宫霄的运管人员争论的时候出现的。 我有次曾经坐过一辆大众的车,从曹河泾回家。问说回浦东能不能更快点什么的,例如走徐浦大桥。司机马上跟我说那样会绕路,起码绕10公里。如果一趟车,乘客自己要绕过50%以上,哪怕是乘客自己要求的,也会要求乘客签单子避免责任。我当然不指望每个公司都有这个水准,但是至少说明“绕路一半以上”并不是什么常见选项,更不会是唯一选项。 其实我在坐车的时候,经常会和司机聊聊天。虽然大部分的司机都很油滑(上海话讲“老油条”),但是其中碰到的大部分人不坏。我见到过因为我身体不适,不能吹空调。大夏天关着空调开车子,开的自己一身大汗的师傅。我见到过不小心东西掉在车上,不要额外收费给我送回来的师傅。我见到更多的师傅,冷淡,油滑,事不关己高高挂起。但是基本上,大部分人都不坏。靠自己的本事吃饭,不会恶意绕路,或者拿着乘客的财物不还(要乘客出送还时的车费我觉得是合理的行规)。 但是,这一情况,在这几年,是越来越差而不是越来越好。 这一问题,我碰到一位师傅,他的分析让我觉得有几分道理。一辆车,一天24小时管理费300-400,油费300-400,一天要做到傍晚,挣的才是自己的钱。15天做一休一,才能挣到6000-7000元上下。有路道的做做私人司机,虽然只能挣个4000,但是工作强度只有三分之一不到。剩下的时间陪陪家里人,炒炒股票,上网卖点东西,日子也过的去。照他们那个强度推算,我们应该挣12000的。所以现在越来越没人要做出租车了。有本事的开开大车,有路道的当私人司机,或者做做小生意也行,只有其他什么都做不了的才做出租车。 我说所以出租车司机的素质越来越差么? 他说还不止。很多时候运管处要管,又没法管。管多了,司机不做了,运管处还要费心找人补上。出租车在上海是属于公众交通而不是私人企业,不能说不做就不做的,不做就大事件了。但是要做,又没有人,只能对一些事情眼开眼闭。对着乘客说,我们已经严肃处理了。对着司机口头警告警告算了——反正他们这辈子没那么巧刚好碰上。 他一说我顿时觉得确实是这样。07年的时候我投诉过一次拒载。当时公司运管核对了事情就和我说,要师傅打给你道歉还是怎么处理。我说还能怎么处理。他说扣师傅一天工资(好像是一天,还是多少),给我100元举报奖金。我想想算了,不是那么大的事,不结那么大的仇。师傅真给我打过来道歉了(虽然听着心不甘情不愿的)。12还是13年我投诉机场有人拒载的时候,公司运管给我打了个电话。“我们感谢您对公司的支持,如果没有您的举报,我们肯定无法发现这些败类。对于这次的事情,我们会严肃处理,以敬效尤。”听着很爽,不过注意到了没,既没说当事人的处理,举报奖金什么的也只字不提——而且关键是这个说辞很流利,我感觉这哥们的工作就是复读机。 这次,个人觉得,法兰红的运管对下属小公司也没有办法了——乘客你要来自己来吧。 建议 下面主要是给台湾朋友的建议了。我的外地朋友里面北京和台湾人比较多,如果是欧美——大概也看不懂中文吧。 不要随意打车。 如果你真的需要打车的话,先确定这不是一辆套牌车。套牌车运管是处理不了的,有什么问题自己倒霉。套牌有点像天灾,很少碰到,但是一旦碰到就是自己倒霉。你最好先看一下出租车的内装,如果不对的话就不要上车。 再确定这不是一辆小公司的车。哪些是大公司?巴士,大众,锦江,强生,海博,海虹,农工商。至少这些牌子我还叫的上来。其他公司的车子,一般也不会碰到问题。但是一旦碰到就很难处理。 注意,这不是说小公司没什么好人。我在小公司的车里面,碰到过很多很好的师傅。只是说,这些公司的投诉管理机制不给力——你得祈祷你没有用到这些机制的机会。 上海出租最重要一个特点是,属于公众交通而不是私人服务。因此有一条很特殊的规定——拒载投诉。主要是针对司机一听你这个地方,觉得不合算就不去了,你可以投诉他。 所以上车前先问师傅做不做生意。等师傅说做,上车后他问你去哪里再说。千万不要当街就把自己的目的地大声说出来。如果出租车司机没有主动询问你目的地,或者确定表明自己做你这单生意,你是不能投诉拒载的。也就是说,如果你一喊,我就去个隔壁。得一堆师傅纷纷表示不做你这个生意了——这是你自己问题,无法投诉。 而且如果你扬招车的时候,师傅当着你的面把出租车运营灯关了——也无法投诉。你自己拉开门坐进去,师傅关掉运营灯——无法投诉。你主动跑上去告诉他去哪里,他关掉运营灯——也无法投诉。 上海出租的一大奇观,就是在下午4-5点的下班高峰。你招手的时候,一堆车纷纷关掉运营灯——这是他们到了交班的时间,只能去特定的方向。如果你的方向不对他们是不会问的,省得给自己找麻烦。对了,如果上车前师傅已经说了只去哪里——也无法投诉。 另一个就是记得收好发票了。上海出租的乘车凭证就是车票,没有车票是不能投诉或者报销的。如果出现东西丢在车上也是要凭车票找人的。所以下车记得拿票。 至于东西忘在车上——抱歉不要指望。如果你有确定的证据证明是司机拿的,你可以投诉,或者卯起来告他到死。但是司机没有义务保管你的财务,或者在你下车时确定东西都拿上了。所以如果不能排除后面的乘客拿走的财务——事实上很难排除——那么几乎找不回来,而且你也不能投诉他。 哪种情况是可以比较完美的排除的?如果你的电话过去的时候,司机的第二个乘客还没有下车。这时候,还没有人离开过出租车,所以不是司机就是乘客拿了你的东西。但是比较悲剧的是,司机是没有权力搜查乘客的。所以如果乘客坚持没有看到,你还是没办法。 所以?要养成一个习惯。离开车前慢悠悠的搜一遍,确定东西都拿了,再下车。你搜的再慢,司机也不能赶你下车——你也不会真的搜上半天吧。

Jun 6, 2014 - 1 minute read - Comments

cgroup限定内存

机器配置 ubuntu 12.04 内核版本:3.11.0-20-generic ulimit的限制效果 ulimit -m 8192 当内存突破8M时,什么事情都没有发生。直到38M都没任何反应。 ulimit -v 65536 python抛出MemoryError cgroup的限制效果 echo 8388608 > memory.limit_in_bytes 大小不对,cgroup的内存量计算方法和ps/status不一致。因此限制计数需要根据具体情况调整。 内核计数 /proc/[pid]/statm size (1) total program size (same as VmSize in /proc/[pid]/status) resident (2) resident set size (same as VmRSS in /proc/[pid]/status) share (3) shared pages (i.e., backed by a file) text (4) text (code) lib (5) library (unused in Linux 2.6) data (6) data + stack dt (7) dirty pages (unused in Linux 2.

Jun 3, 2014 - 1 minute read - Comments

为什么running不高但是load很高

很多初学者会混淆几个概念。CPU繁忙程度,load。两者的区别在于,一个秘书是真的忙着抄抄写写,另一个么,反正领导只检查桌子上堆的文件数。只要桌子上准备一堆文件,在文件里换来换去就好了,没必要真的很忙。当然,大多数时候桌子上堆着很多文件的理由还是因为秘书手不够了,不过少数时候也有例外。例如fork boom,CPU很空但是load奇高。 我们就遇到了一个例外的例外。 症状是这样的。系统经常出现偶发性的load过高。例如有那么几分钟,load会高到100-200,然后就快速下降。但是检查后发现,即使在load极高的时候,cpu占用率也并不高,大概在10-20左右。磁盘吞吐也一般。那么load为什么会这么高呢? 我的第一怀疑当然是超多数量的小线程,在那里搞切换调度。所以我第一反应就是看了/proc/loadavg的当前活跃线程数——结果居然只有1-5。为了确认,我特意的持续观察了数次,在我观测期间load的1分钟计数还升高了——这说明当前实际队列比1分钟平均还要高,而活跃线程却是3。 怎么可能?交通系统报警说北三环大赛车,平均堵塞长度500辆。去一辆警车到现场回报说只看到塞了两辆,再去一辆说算上我们自己三辆。去了十多次都如此。任何脑子清楚的人都会毫无疑问的喊出——黑箱政治,政府不作为,我们要占领国会——不好意思,我们好像没有这个东西。 OK,言归正转。为了解释这个疑惑,我特意的去看了一下内核源码——我擦,loadavg的平均值计算中,是把uninterruptible算在一起的。而活跃上下文中,只算了nr_running! ——你丫敢再精神分裂点么? 为了确认,我还特意man proc,结果发现里面确实有说,平均值是R和D两者去算的。但是在活跃上下文那里,只说了the number of currently runnable kernel scheduling entities——看看清楚,这里可从没有说有D。脑子清楚的仔细想想就知道,D是不可调度的。 ——问题是咱脑子不清不楚的就没想这差异,而且咱连man proc都没查。。。 另外顺便说一句,内核也告诉了我们一点东西——load计算的时候是连内核线程一起算的。 清楚这点差异后,问题的原因也很清楚了——肯定是哪里有很高的D。用ps -e Hl | grep -e R -e D扫了一下,再用wc -l做了一下统计。214个线程在D(或者R,或者只是不小心被grep到,但是实际上大部分都是D)。系统当前的loadavg正好长这样: 214.12 156.63 82.25 7/4629 10027 7个执行中线程®,207个uninterruptible。 ——所有的谜都解开了。

May 25, 2014 - 1 minute read - Comments

台北地铁砍人事件

哪里都有疯子 其实并没有疯,只是不论理由,就是要杀人而已——就是所谓的反社会人格。理论上心理咨询是可以发现的。但是台湾的经验告诉我们——目前的心理咨询密度不足,敏感度不足。而要维持足够的敏感度,不仅费用成问题,而且还会有很多啼笑皆非的情况。 社会压力?北欧够没压力了吧。2011年挪威发生爆炸和枪击。 废除死刑? 我不赞成废除死刑。当然,这和捷运杀人案本身并没有什么关系。他杀人的时候就知道自己会被判死刑。人不畏死,奈何以死惧之,死刑对凶手是没什么阻止力的。所以废除死刑还是保留死刑,都不能阻止凶案的发生。 但是死刑还是能阻止一些东西的。例如本次事件,死者中有两位20出头的年轻人。如果没有死刑,他们的父母会不会试着杀了凶手呢?反正活着也没什么意思,而且很讽刺的——我们也不能判这些人死刑。更进一步的,每次杀人案,我们需要严密保护的想必不是受害人,而是加害人——因为加害人不能死。而我们的法律为了保护加害人而存在,受害人遗族如果心理难以平复,只有自己动手,同时把自己变成受法律保护的人——就是加害人——才行。这样的逻辑不荒谬么? 死刑这事原本就没什么意思——我们已经遭到了损失,却还要用杀人来扩大损失。从这个意义来说,如果真是很久都没有恶性事件了——例如2011年挪威枪击和爆炸事件那样。这样的情况下,要不要废除死刑还真的可以商量。只是真的如此,我们应当判处什么人的死刑呢?长着野百合的绞刑架大概会成为城市最美丽的徽章。 死刑的意义在于,在无法无天的地方,我们有一种廉价的方法,可以永远的不用看到这个人。 和太阳花连结 咳,要认真论关系,马总统和杀人犯的关系绝对比太阳花近——这人的衣食住行,哪个不是受到政府政策的影响?是为期一个月的太阳花运动,还是持续执政数年的政府,更有可能造就一个杀手?两者哪个和凶犯的联系更多?持太阳花论的人认真想过这个问题么? 还有。包围行政院的年轻人去哪了?大概正在被各种凶案发生时的警察逮捕吧——你不觉得换个说法”凶案发生时,警察去哪了?“,这个质疑也能成立么?而且大部分凶案发生时都看不到警察啊,明明总统府门口一大堆的说。 也不要以为持这种论点的人是傻瓜。你讨论了这个问题,哪怕是否定,也达到了他们的目地——没有关系也是一种关系啊。我们不断讨论,有没有关系,有没有关系。不断得出结论,没有关系,没有关系——届时只要轻轻反问一句,真没有关系为何要讨论这么久,有人讨论过西瓜和美国国旗的关系么?没人讨论,是因为真的真的,一点点关系都想不到啊。 从这个角度来说,这种问题居然还需要讨论本身就很反常,你我都是网里的一个飞虫而已。 玩游戏和杀人的关系 比”吃饭和杀人的关系“近,比”没有女朋友和杀人的关系“远。从这个意义上说——难道政府要强制所有人谈恋爱?

May 8, 2014 - 1 minute read - Comments

goproxy和msocks简介

goproxy是我个人写的,和shadowsocks同类的软件。当然,在设计之初我完全不知道shadowsocks的存在,goproxy的最初目标也不是成为shadowsocks的同类。只是我一直无法实现一个可靠的,能够达成目标的系统。最后想,那这样吧,我找一个跳一跳能够够到的苹果。大幅简化的结果就是goproxy——后来我才知道shadowsocks。 shadowsocks的基本原理 shadowsocks的基本概念,就是利用某种不同于SSL的协议,将本地的socks数据流转发到远程。这个协议,在默认版本中是一个凯撒变换,后来有了aes等加密算法。goproxy也采用了类似的做法,同样支持aes等加密算法。在每次连接时,客户端先用加密通道连接服务器端,然后完成整个连接通路。这样的设计鲁棒性相当好,但是作为代价的,也有不少缺陷。 首先,goproxy和shadowsocks不约而同的采用了自己的协议,而非将socks5透明的转发到远程的服务器端。为什么?因为socksv5协议中,握手过程是三次交互。客户发送握手包,服务器响应允许的握手验证方法。客户发送验证报文,服务器端返回是否成功,客户发送要连接的目标,服务器端返回是否成功。细节我记得不是很清楚,但是2-3次往返是必须的。 这种工作机制需要client -> proxy-client -> proxy-server -> server的一个链条,本身就比直连多了两次TCP握手。加上上述的往返过程,更加耗时。而且这个消耗在每次建立链接时都要来一次,而HTTP是一种短连接协议——这就更加无法容忍了。因此改用自有协议,一次交互完成握手,就会更加快速。 更根本的原因在于,这两个系统都需要越过IDS,而三次交互的报文大小是几乎固定的——就算加密也无法改变报文大小。不但大小一样,而且由于用户名密码相同,起始加密过程和IV一致,因此采用socks协议的话,每个链接开始都有相同的来返数据。 我不知道shadowsocks怎么处理的这个问题。qsocks协议(msocks)的前身规定,每次握手时客户端提供一组IV,然后发送一个头部变长的字符串(256字符以内),在远程丢弃同样长度的随机字符。经过这样的处理,每次链接时的报文长度和内容序列都不一样,增加了破译难度。至于多出来的几十个字节,和验证报文在一个报文内,开销相比一次RTO几乎可以忽略不计。 但是还是有一点无法避免的问题。如果你看到某个服务器上有一个端口,频繁的被一个或多个IP链接。每个链接都不长,每次都是客户端吐一堆数据,服务器返回一堆,然后关闭链接。尽管协议无法破解,但是基本可以肯定这就是shadowsocks。根据这个特性,可以有效的阻挡服务——这也是我最近碰到的问题。 而且每个链接都需要验证和TCP握手太慢了。 msocks的改进 所以,我参考SPDY协议,做了msocks。msocks的核心思路和qsocks很类似,主要修改是以下两点: 使用一个可靠链接(这里是经过加密的TCP),在这个链接里面封装多对传输。 每个链接只要一次验证。 这样做,首先减少了一次TCP握手和一次身份验证,工作速度更加快。其次多个传输叠加在一个流里面,流特征更加变化莫测。最后,无论是服务器端还是客户端的开销都小了很多。 当然,这也带来不少问题。例如TCP原本的拥塞控制窗口是为了一对传输序列设计的。当很多传输序列在一对TCP上传递的时候,丢报文造成的影响会作用作用在全体传输序列上。包括丢了一个报文重传的时候,所有序列都必须阻塞。还有基础的TCP被施加了丢包,导致全体序列共享5k带宽。当然,经过评估后,我觉得这些问题比频繁握手更加轻,所以就设计了msocks协议。 协议设计的时候,有几个细节问题。 多对复用 我采用了一个map,来记录某个id是否对应到了一个控制结构。这个映射只能被客户端更改,并且有个专门的函数负责查找空闲的id,每次生成的id都是递增的,如果碰到最大值则绕回。 id的大小是16位,足够容纳65536对同时链接。其实不修改内核的话,500对代理就会导致too many files。 实际上一般到id达到400后,单一的tcp就断线重连了。目前我还没见过上千的数字呢。 连接状态 连接一般情况下可以看到5种状态,连接请求发送,连接请求接收,连接建立,主动关闭连接中,被动关闭连接中。 当客户端请求代理连接一个远程服务器时,进入连接请求发送。代理远程端接受后在连接目标服务器的过程中,进入连接请求接收。当成功后,双方进入连接建立。 当关闭时,主动发起关闭一端进入主动关闭,另一端进入被动关闭。当被动关闭端调用close,或者主动关闭端收到对方关闭,整个链接就销毁。 由于tcp是可靠传输,因此三次握手和四次关闭都是不必须的。 简单吧。 拥塞控制 TCP原本是带有拥塞控制的——借助SSN双序列和窗口机制。但是在多路复用的时候,我们需要自行控制拥塞——而且不能采用会和机制。会和会导致后续已经到达的其他链接的报文被一个没人接收的报文阻挡。所以必须采用带拥塞控制的缓存队列机制。 不过幸好,TCP本身是可靠传输协议,所以我不用担心丢包重发之类的问题。我需要做的,就是把对方读取的字节数传递回来,减在控制器上,即可。 不过,我没有做对应于silly window syndrome的优化,在每次读取小数据量后,这个读取造成的window扩张都会被传回。当然,这么设计是有原因的。我默认采用了8K的buffer进行fd间拷贝,所以一般碰不到SWS。 为了解决tcp链接复用造成的单连接带宽问题,我强烈的建议你做以下的设定: net.ipv4.tcp_congestion_control = htcp net.core.rmem_default = 2621440 net.core.rmem_max = 16777216 net.core.wmem_default = 655360 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 2621440 16777216 net.ipv4.tcp_wmem = 4096 655360 16777216 ip选择算法和DNS 在goproxy中,我沿用了一个做法。通过DNS获得请求的目标IP,和中国IP范围核对。如果在国内则直接访问,否则透过代理。这个方法能够极快的加速访问,而且几乎不依赖于需要更新的列表(中国IP列表相对来说固定)。

Apr 8, 2014 - 1 minute read - Comments

CVE-2014-0160(openssl)严重漏洞及其对应

描述 openssl 1.0.1系列中,1.0.1f以前的版本在实现上存在漏洞,未正确处理Heartbeat扩展,导致攻击者可以窃取服务器端敏感数据。 对应 请立刻升级openssl到1.0.1g版以上,并重启整个系统,以保证不会遗漏某些已经启动的进程。 如果有自行编译的程序使用了openssl。当这些程序静态链接或链接了自定义的openssl时,需要重新编译。 在有问题的设备上使用过的key,需要升级私钥。 openssh不受影响,openvpn受影响。 作为证明,请执行以下语句自行检查。 ldd /usr/sbin/sshd | grep ssl ldd /usr/sbin/openvpn | grep ssl ldd /usr/sbin/nginx | grep ssl for i in $(ps aux | awk '{print $2}'); do echo $i; ldd /proc/$i/exe | grep ssl; done 其他 根据昨晚看到的信息,这个漏洞会泄漏服务器端的通讯数据。因此请将所有session清空,在受影响期间使用过的用户名和密码请务必在3-5天后再修改一次(具体看服务商什么时候补掉漏洞)。 参考 nvd debian ubuntu openssl Is OpenSSH affected by this as well?

Mar 25, 2014 - 1 minute read - Comments

安全的几点快速说明

这篇文章谨献给某些特殊环境下奋斗的人士。其他人参考使用。 物理设备 物理设备上存储着相当多的个人资讯,所以所有的机密资讯要保密这是常识。 物理设备上可能拥有的机密资料: 各大站点的session token。借助这些,虽然不能抢走帐号,但是可以仿冒身份,发出假消息,或者诈骗。 浏览器启用了“保存密码”选项后,所有的密码都半明文存储在硬盘上。这些信息可以被用来抢走帐号。 个人的文档,照片,私密视频。万一笔电丢失就够倒霉了,再变陈老师岂不更痛苦? 浏览某些特别站点的记录。咳咳,大家懂。 之所以要设备加密,是因为有一种破解方法是将你的设备存储拆下来,接到独立的读写设备上,直接读取数据。无论系统密码设定多强,也无法防范。 如果是mac,有一个选项叫做全盘加密。ubuntu有home分区加密的选项。启用这两项可以有效加密你的电脑。windows也有个类似的功能叫做EFS,但是据说不少国家级单位有解密权限。 Windows Mac Linux android上有加密系统的选项。但是要注意,如果启用会消耗大量电力,而且必须擦除整个设备才能解除。iphone我没用过,据一位挺熟悉的朋友说,只要设定了pin码,整个手机就会被加密。 加密只是第一步。对于经常保持开机的系统,如果能够轻易的进入系统,那么磁盘加密也形同虚设。所以,请给你的系统加上一个足够强的登录密码。 最低强度: 磁盘加密8位以上,系统登录6位以上,包含小写和数字。 推荐强度: 磁盘加密10位以上,系统登录8位以上,包含大小写和数字。 网络安全 首先,请把系统的防火墙开到最大: Windows Linux Mac 基本原则是,只许出不许进。如果需要可以开放特定端口。 然后,如果在不安全的环境下使用网络,请使用vpn。这里请允许我广告一把朋友的网站云梯。一般是用来大陆翻墙的,不过要用来绕过不安全的环境也可以。 有时间有条件的朋友可以自行架设vpn服务器,这里给出linux下架设pptp vpn的方法。客户端使用方法可以参考云梯的说明。 How to Setup a VPN (PPTP) Server on Debian Linux PPTP Server linux pptp vpn服务器的架设 Debian系统快速搭建pptp VPN 注意加密一定要使用128位,不要使用56位。 网站访问 如果可以选择,尽量使用https。下面有一些插件,使你可以尽可能的使用https访问站点。当然,如果站点没有https则无效。 Chromium Firefox 在https访问的时候,如果跳出证书是伪造的之类的警告,请千万不要确定。这是有人在man-in-middle的信号。正确的做法是使用vpn,看看问题是否消失。如果消失,上报给工程师。如果没有消失,请找可信的工程师来排查。千万不要轻易认可未经鉴定的证书(实际上不建议自行接受任何证书——除非那是你自己配出来的)。 另外,请关注证书的签署者。在我这里看到的信息如下: google的证书签署者是GeoTrust facebook的签署者是VeriSign twitter的签署者是VeriSign 如果签署者有异,请上报工程师。这可能是有人获得了某个根证书机构的密钥来做的签署(例如CNNIC之类)。原则上这样的man-in-middle可以攻击任何网站。