Planet of Woodpecker.org.cn for CPUG

March 24, 2015

@shell909090

EFI和GPT的研究

EFI和GPT的关系 关于EFI和GPT的解释我就不说了,相信来看我blog的人 … 继续阅读

by shell909090 at March 24, 2015 08:04 AM

March 17, 2015

@khsing

debian locales错误

某台debian机器的locale执行出现如下错误

locale: Cannot set LC_CTYPE to default locale: No such file or directory

出现这个一般是locale文件缺失,需要重新生成

dpkg-reconfigure locales

选中需要的locale就可以了

by Guixing at March 17, 2015 07:53 AM

March 10, 2015

@delphij

OpenBSD的spamd

许久不碰反垃圾邮件的事情了,一来前段时间垃圾邮件确实也没有那么多,加上spamassassin确实相当有效,二来也是因为犯懒。

不过,最近几天垃圾邮件明显比平时多了许多,所以决定坐下来仔细处理一下。

OpenBSD 的 spamd 是一个反垃圾邮件陷阱软件,它的主要功能是灰名单(SMTP协议要求客户端在一段时间之内重试投递),但又有一个个人很喜欢的特性:以极慢的速度回应发送垃圾邮件的服务器(默认配置为1秒一个字符,最高可以到10秒一个字符)。对发送垃圾邮件的人来说,这样做会显著地降低他们发出垃圾邮件的能力。

结构上,spamd 会修改服务器上的防火墙的转发规则中的地址,简而言之,是维持一份动态的白名单(由通过了灰名单测试的IP形成),所有不符合白名单的IP都转到 spamd 处理。如果符合白名单,则直接正常转到MTA去处理。

简单记一笔配置。

由于我的机器内存够用,所以将 spamd 配置为最大拖住1024个连接。灰名单最短等待期设置为 1 分钟,灰名单过期时间设置为 4 小时;白名单过期时间设置为 36 天。

选择的黑名单是uatraps和nixspam,各自用本地白名单做补。此外,本地另设一黑名单。

启动spamd服务并更新pf规则。接下来用:

grep 'Passed CLEAN {AcceptedInbound}' maillog* | \
cut -f3 -d[ | cut -f1 -d] | grep -v : | sort | uniq -c | \
sort -n | awk '{ if ($1 > 20) print $2; }' | sort -n | \
xargs spamdb -a

来将过去几天的 Amavisd 认为没问题的地址加入本地白名单。

最后可以用 spamdb -Ta 来添加一些陷阱地址。陷阱地址是那种故意流出,但绝不应该收到邮件的地址。

by Xin LI at March 10, 2015 11:49 PM

March 08, 2015

@delphij

逗死我了......

对口相声选段:Node.js Is Bad Ass Rock Star Tech。视频:

p1: And in conclusion we have found Apache to be an excellent server for our web applications. Any questions?

p2: Yes, I have a question. Why didn't you use node.js? node.js is an event driven, non-blocking IO server that can be used to build high-performance web applications.

p1: That is an excellent question. We evaluated several alternative web servers and concluded, that while options like node.js are very interesting, Apache meets our needs and has a solid track record.

p2: But it doesn't have performance. Everybody knows that Apache applications are slow because they use blocking IO and have context switches.

p1: That's a commonly held belief that threaded web servers are somehow less performant or as scalable than event based servers. In fact, if you measure carefully, you will find that both models have similar performance characteristics.

p2: Threads don't scale. Simple as that.

p1: That may have been true 10 years ago. Its not true today.

p2: node.js will run circles around Apache because Apache was built before asynchronous was discovered.

p1: This is where I typically stab myself repeatedly in the ears with a fork until I stop hearing you. I've looked at node. It uses a single threaded loop that dispatches events to handlers. Its a proven model that solves some concurrency problems but at the cost of code complexity.

p2: It gives techies like me the control to wring every last CPU cycle out of our servers.

p1: It must feel empowering to be totally responsible for the performance of your application. To be always on the lookout for blocking operations that should be split into little pieces each perfectly tailored for concurrent throughput. All the complexities of assembler with all the speed of JavaScript.

p2: I'm a total speed junkie

p1: Do you know what this reminds me of?

p2: The invention of the transistor.

p1: It reminds me of the invention of threads. Threading libraries do exactly what your doing manually. They break up pieces of code to be executed intermittently, switching from instructions that are waiting on IO to instructions that are ready to run, but your sequential code stays intact. You may recall sequential code. Its the code that you can read.

p2: But its slow as a dog

p1: Your asynchronous program is like something from a 19th century Gothic horror story. Drunk with your own sense of power, you reassemble pieces of code that were once coherent, stitching them together with event loops and callback functions, until your monster, grotesque and menacing, is ready to be brought to life in a JavaScript VM. You throw the switch and the hideous creature awakes, rises, and lurches forward. you're simultaneously elated and terrified that something so unnatural code work at all. When you realize what you've unleashed, the pure immorality of it, your creation reaches out with its bloody, mangled arms, and strangles you.

p2: But its fast as hell

p1: If your willing to suffer complex code for performance, why not write an nginx module and see?

p2: node.js is the most bad-ass rock-star tech to come out since Ruby On Rails.

p1: As much as I want to be an optimist and look forward to human progress, people like you make stop me dead in my tracks. Your a fanatic in the church of technology fashion. I could present you with fact after fact after fact of why your thinking of asynchronous programming is completely wrong. But why bother when you equate technology to rock bands, and fancy yourself a software hipster by wearing your node.js t-shirt and celebrate horrible code. Maybe your cool, hell, maybe you have groupies. But when it comes to knowing what the f*ck you're talking about, you have the facilities of a parrot who says "non-blocking" over and over again.

p2: Non-blocking is the secret in the asynchronous sauce. With it, you go fast. Without it, you go slow.

p1: Do you know when humans discovered that the world was round?

p2: 1492. Columbus sailed the ocean blue.

p1: It was 240 BC by a Greek mathematician named Eratosthenes. He conducted a simple experiment using the length of shadows and the distance between cities to not only prove the earth is round, but to also calculate its circumference.

p2: Sounds low-tech.

p1: It was utterly brilliant. But somehow, for one and a half millenia, it was common knowledge that the earth was flat. Hundreds and hundreds and hundreds of years in daft ignorance. How in mother-f*cking hell does this happen?

p1: It was you. You who makes claims about thread performance without measuring. You who claim hacking your code with a machete, turning it inside out into a twisted, unrecognizable mess will somehow make it go faster. You, who spend your time alternating between problems that are already solved and problems that don't actually exist. You are the reason science was set back 1,000 years. The reason we have not cured cancer. The reason we have not solved world hunger.

p1: Its because of you, mother f*cker, that we are not all using Lisp.

p2: I'm sorry, what was that last part again?

p1: Never mind.

p2: Did you just say Lisp?

p1: You misheard me.

p2: I could've sworn you just said lisp.

p1: If there are no other questions, this concludes my presentation.

by Xin LI at March 08, 2015 04:43 PM

February 26, 2015

@shell909090

FIN-WAIT-1的问题一例

这是一个早应该知道的事情。但是还是被整了半天。 引子 tcp关闭时有多少个状态? … 继续阅读

by shell909090 at February 26, 2015 08:52 AM

February 23, 2015

@delphij

苏局语录之今儿咱聊聊电梯的事儿......

我有一心得和大家分享一下,话说三个人一起坐一电梯上,其中一个一直跳一直跳,一个蹲在角上一直祈祷,一个满地打滚手脚抽搐,最后都到了十二楼,若干年以后有人问为什么您能到楼上啊?第一个人说,我坚持不懈的努力,和大自然对抗,力竭也不放弃,最终达到了这个巅峰,第二个人说,我真诚而且坚持,我坚持自己的信仰从未忘记初心,第三个人说,我反直觉反传统反对一切,于是创造了完全不可思议的结果。我看很多商业书籍就这感觉,你们几位不聊聊电梯这事到底几个意思?

by Xin LI at February 23, 2015 08:47 PM

February 17, 2015

@delphij

FreeBSD -CURRENT随机数发生器问题

今天 John-Mark Gurney 修正了一个影响过去4个月左右的 FreeBSD -CURRENT 的随机数发生器问题,具体受影响的版本是 r273872(引入问题)到 r278907 (修正)。

由于问题只影响 -CURRENT,因此我们不会就此发表安全公告。

问题的影响:在对随机数发生器 (/dev/random)进行重构的过程中,原先为内核 arc4random(9) API 进行初始化(seeding)的部分没有正确地在新的随机数处理器上线(randomdev_init_reader)时进行配置,导致内核一直使用 dummy RNG 来生成 arc4random(9) 的种子。由于 dummy RNG 的输出范围有限(大约 2^30),导致 arc4random(9) 的输出容易预测。

由于 arc4random(9) 同时也用来在用户态代码中产生随机数种子,因此这个问题也连带影响了用户态的随机数生成(由于 arc4random(9) 在内核中被广泛使用,因此或多或少地减弱了这个问题的实际影响,但我们建议用户不要因此而产生侥幸心理)。

我们建议使用这些版本的 FreeBSD -CURRENT 的用户 立即 升级到最新的 -CURRENT,同时销毁并重新生成在这段时间内生成的全部私钥。

by Xin LI at February 17, 2015 06:52 PM

February 12, 2015

@delphij

假设 3721 = x * y,其中x, y 均为整数,则 x+y 最大是多少?

翻了个船,记一笔。题目如题。

已知 x、y 为整数,由于 3721 是正整数,因此 x、y 符号相同且均不为0。又,题目所求是 x+y 的最大值,故只需考虑 x、y 的正整数解情形。

由 x * y = 3721,令 y = 3721 / x,则 x + y = x + 3721/x。由于 x > 0 且为整数,可知所求为符合条件的 max(x2 + 3721),或 max(x)。

将 3721 开方得到正整数 61。由此可知 x = y = 61 是 xy=3721 的一个整数解。61 是质数,于是很想当然地得到了错误答案 = 61+61 = 122。掉到这个坑里的主要原因是想太多了,实际上题目最终要求的是 x 的最大正整数解,换言之,此类问题:已知C为正整数,C = x*y,求 max(x+y) 的结果应该是 (C+1),不需要任何超出小学算术的计算。本题中的正确答案为3722。

by Xin LI at February 12, 2015 01:01 AM

February 09, 2015

@shell909090

p2p vpn的部署方法

p2p vpn的基本概念 p2p vpn这个概念的提出,是因为openvpn在数 … 继续阅读

by shell909090 at February 09, 2015 03:06 AM

February 06, 2015

@khsing

重新使用Trello

知道Trello这个服务真是时间不短了,但是一直没有怎么用这个东西,最近的事情多到脑子里装不下了,自己的OmniFocus只能给自己看,协同的事情还真是不太好做,所以呢这个Trello就重新用起来了。

他的官方有一个板子叫trello resources,翻了一下确实有不少东西。

比如,在User case里有一些有趣的用法

by Guixing at February 06, 2015 05:48 PM

February 04, 2015

@shell909090

openvpn的几种基本模式

vpn的原始模式 vpn的最简模型,相当于在两台机器上插一块虚拟网卡,然后中间连 … 继续阅读

by shell909090 at February 04, 2015 07:07 AM

February 02, 2015

@shell909090

vpn不要走tcp协议

和大家唠叨一件小事。 vpn不要走tcp协议。 我原本以为这是个常识。因为当网络 … 继续阅读

by shell909090 at February 02, 2015 03:43 AM

January 30, 2015

@delphij

India NIC签发未经授权的 Google SSL证书事件

详情参见 Google Online Security Blog

说两个我认为比较有意思的事情:

第一个是 Google 并没有公布作为证据的证书。由于证书是以 CA 的私钥签署,因此这类未经授权的证书本身就可以作为证据。但是,Google这样做(不公布证书)意味着签发者不得不销毁全部签发的证书,而不仅仅是被公布的那些。

第二个是 Google 在 Chrome 中限制,而不是直接删除或禁止了负有责任的根CA: India CCA 的许可范围。我认为这是远比禁止使用或删除根CA更好的做法(同样的原则也适用于几年前 Mozilla 基金会决定接纳 CNNIC 证书),原因如下:

  1. 在攻击者使用未经授权证书的同时,他们也将自己的身份(持有私钥)暴露在了阳光下,从而使检测和指证变得容易
  2. 加密通讯要比不加密好。鼓励所有人加密通讯,有助于提高攻击所需的代价。
  3. 限制使用范围削弱了CA的权力,阻止了恶意CA对用户的影响,同时对正常证书持有者的影响又不大,降低他们的迁移成本。

by Xin LI at January 30, 2015 04:24 PM

January 27, 2015

@shell909090

Charlie and Dave

公司希望弄一套双授权的安全系统,老大提供了一套算法,求大家review。如果这个 … 继续阅读

by shell909090 at January 27, 2015 02:19 PM

January 12, 2015

@delphij

Google Compute Engine

初步尝试了一下 Google Compute Engine(G社类似 Amazon EC2的产品,基于 Linux/KVM)。确认 FreeBSD 可用(在家里用qemu建一个image出来,装好,然后打包扔到 Google 的系统上,然后用这个包建一个image,再用image起个instance)。

几个比较显著的坑:

  • Google Cloud SDK假定bash位于/bin/bash。这个很容易patch。
  • 如果是在远程的 FreeBSD 系统上使用 Google Cloud SDK,它默认会起 links 作为浏览器。由于 links 不支持 JavaScript,因此会导致 Google Cloud API 授权失败。解决方法是关闭浏览器,然后通过 X forwarding 起一个 Chromium (我估计 Firefox 也没问题)来操作。
  • GCE的系统只支持GNU tar格式的文件,使用 FreeBSD 的 bsdtar 时必须指定用 gnutar 格式,或者用 GNU tar(bsdtar默认采用的是 pax interchange 格式,而 libarchive 目前并不支持 GNU tar 的 sparse 模式;具有讽刺意义的是 Tim 其实应该是在 Google? xz 支持未测,我觉得以只支持 GNU tar 的劲头应该是不支持 xz 的)。
  • 预设的防火墙规则基本只允许 ssh。
  • 系统内建 禁止任何发到标准SMTP端口 (25, 465, 587)的请求。可以理解禁止25,但是不太理解禁止465和587,意义何在?是为了推广 SendGrid 吗?
  • 初始的qemu镜像文件必须是10240MB。
  • 上传 qemu 打包之后,建立 image 后其实可以直接删除原包。

存到盘上的数据据说是加密的,不过个人认为扔到 Internet 上的数据基本就没有隐私可言了,有加密自然可以阻止一些泄密(例如如果一家创业公司想要保存一些患者信息,那么在 Google 本身不被黑掉且他们遵守一系列安全设计准则的前提下,他们至少不用担心由于硬盘坏掉,替换硬盘时这些数据被第三方厂商偶然得到),但基本上跟家里的门窗结实程度一样,你懂的。

实际测试,虚拟网络至少可以做到 100Mbps 跑满(对 Internet)。我认为对大部分普通应用而言应该是够用了。比较遗憾的是本地读写性能忘记测试了,等有时间再研究一下(看 这里 估计太快不了;可靠性方面,据说有内建冗余和校验和检查,不知道实际情况如何,个人感觉可靠性应该还不错)。

现在有个比较邪恶的想法是跑个定制的 FreeBSD 系统:以 64-bit FreeBSD 为主体,大部分系统工具替换为 32-bit 的,削去不必要的元件如 APM、电源管理、无线等等,同时安装 64-bit 和 32-bit 的库。这样的好处有:1) 可以充分利用内存和 long mode 的一些优势; 2) 大部分应用程序并不真的需要使用 2GB 以上内存(除非出了问题),跑 32-bit 的版本作为副作用恰好可以阻止它们疯长(一旦发生这种情况直接就被内核干掉了),而另一个副作用则是 32-bit 的代码本身比较小,因而可以节省内存和磁盘空间从而降低使用成本; 3) 64-bit FreeBSD 上的 32-bit 兼容库是采用最新 CPU 指令集编译的,而直接安装的 32-bit 版本 FreeBSD 则不具备这一特性。

by Xin LI at January 12, 2015 02:40 AM

January 05, 2015

@shell909090

无题

路过南京,突然想起前几年在狮子桥吃的鸭血粉丝汤。什么味道其实已经忘了,只是在干完 … 继续阅读

by shell909090 at January 05, 2015 07:46 AM

December 24, 2014

@shell909090

北海道之行的感想

礼貌的老奶奶 这次去日本,让我最受震动的是一位老奶奶。 大家知道我们的日语很差。 … 继续阅读

by shell909090 at December 24, 2014 09:23 AM

December 19, 2014

@delphij

三星滚筒洗衣机门锁的更换

将近三年前搬家的时候买了一台三星 WF350ANW/XAA 洗衣机,结果上周发现门合不上了。上网找到了 这个视频,发现更换并不麻烦,打电话给三星,对方说已经过保,于是决定自己动手修理一下。

首先是断开电源和水源。

拆解比较简单:首先用尖嘴钳从洗衣机下部胶皮中将弹簧拽出(这是一个细金属丝+弹簧构成的圈,用来箍住橡胶皮隔水圈),然后小心将橡胶隔水圈拆开。接下来把门锁的螺丝拧掉,然后把它取出(有连接线)。

首先将外面的塑料外壳卸下(有两个比较重要的塑料卡隼)。接下来将连接的线断开。

拆下来以后,发现最下面的螺丝所在的位置的塑料裂开了,同时在这个地方发生了比较严重的开裂。

由于是受力的地方,而采用的材料是较为廉价的塑料,因此可以预见这个部件在未来还是会发生问题。

安装过程基本是拆解过程反过来,其中比较费力的部分是将金属圈装回的部分,基本上要把圈上到3/5左右,剩下的部分用 iFixIt 套件中的 Spudger 在两侧同时用力来装上。

by Xin LI at December 19, 2014 05:50 AM

December 17, 2014

@delphij

The TIDE

The tide recedes, but leaves behind bright seashells on the sand.

The sun goes down, but gentle warmth still lingers on the land.

The music stops, yet echoes on in sweet, soulful refrains.

For every joy that passes, something beautiful remains.

-- Hardin Marshall via

by Xin LI at December 17, 2014 06:50 PM

December 16, 2014

@shell909090

北海道旅游——札幌附近地区攻略

札幌 白色恋人巧克力工坊 在宫の沢站,从大通坐东西线,340就可达。 工坊庭院非 … 继续阅读

by shell909090 at December 16, 2014 03:52 AM

December 08, 2014

@khsing

在OS X里不同域名用不同的域名解析器

由于公司内网的特殊原因,github.com以及pypi.python.org甚至gmail.com和google.com等网站被IT给劫持到了一个代理上去,本来是好事帮助大家翻墙了,但是这是实现我就不吐槽了。

带来的问题是这些网站都会有https的访问,尤其是以下客户端和命令行,证书是内网下发的假证书(听到这里,是不是很熟悉呢,没错这就是man-in-the-middle attack,#此处可以有呵呵

曾经反应过这样的问题总是不能奏效,只能自己动手了,Mac下可以这么搞

/etc/resolver/目录下放上域名为名的文件,比如/etc/resolver/python.org内容如下

nameserver 8.8.8.8
nameserver 8.8.4.4

by Guixing at December 08, 2014 09:37 AM

December 01, 2014

@khsing

命令行下的代理设置

为了科学上网,访问github之类的快一些,总要在命令行工具下用代理,于是就有了如下设定

# Setup commandline proxy
_proxy="http://127.0.0.1:16888"
_noproxy="localhost,.sina.com.cn,.weibo.com"
alias proxyon="export http_proxy=${_proxy} https_proxy=${_proxy} no_proxy=${_noproxy}"
alias proxyoff="unset http_proxy https_proxy no_proxy"

这个no_proxy是为了让本地内网的repo不要走代理.sina.com.cn代表了该域名下的内容都不走代理。

sudoers里写上环境变量的保持,

Defaults    env_keep += "http_proxy https_proxy no_proxy"

by Guixing at December 01, 2014 12:55 PM

November 29, 2014

@khsing

启用Akismet

趁着收拾blog系统的时候,升级到了MovableType 6,同时也好好处理了一下之前的comments,发现即便是在启用验证码的情况下,依旧有不少Spam。

于是就启用了Akismet,不过我是下载回来之后些许改动,都放在了github/mt-plugin-akismet.

安装很简单,

  1. 建立一个软链接到mt-plugin-akismet/plugins/akismet
  2. 进入 System Overview -> Tools -> Plugins -> MT-Akismet -> Settings
  3. 在API Key的位置上写上在http://akismet.com申请的API Key就好了。

自己试一下,看看Activelog有没有报错,如果没有点进新的Comments应该可以看到如下界面

另外也可以在akismet站上看得到统计信息。

by Guixing at November 29, 2014 05:00 PM

干干净净重装Mac OS X 10.10

重装Mac OS X 10.10

最近很是悲催,家里虽然添置了新的NAS,但是在导数据的时候移动硬盘挂了,这个硬盘了有一部分数据是没有备份的,这是最糟心的了。真是应了墨菲定律,也真是应了那句话"备份不做,日子甭过。"

俗话说的好"祸不单行",就在那个硬盘挂掉的时候我也发现了我的 Macbook Pro 的硬盘分区很不对劲,用Disk Utility并不能修复,即使使用CMD+R启动到Recovery Mode依然不行,HFS+不是一般的渣啊。备份数据,重装系统。

这次要来一个全新的安装,硬盘还要格式化。

  1. 制作一个USB安装盘, 具体参考How to Make an OS X Yosemite Boot Installer USB Drive, 简概之 $ sudo /Applications/Install\ OS\ X\ Yosemite.app/Contents/Resources/createinstallmedia --volume /Volumes/Untitled --applicationpath /Applications/Install\ OS\ X\ Yosemite.app --nointeraction

  2. 用这个U盘启动

  3. 重置硬盘,打开Terminal.app, 执行 $ diskutil eraseDisk JHFS+ OSX disk0

  4. 重置结束之后,检查磁盘应该如下

    $ diskutil list disk0 /dev/disk0 #: TYPE NAME SIZE IDENTIFIER 0: GUIDpartitionscheme *251.0 GB disk0 1: EFI EFI 209.7 MB disk0s1 2: AppleCoreStorage 250.1 GB disk0s2 3: AppleBoot Recovery HD 650.0 MB disk0s3

  5. 退出之后重新安装整个系统。

经验教训还是,经常备份,尤其是重要的数据,电影音乐之类的东西都还好说,最重要的就是拍摄的照片和视频了。

by Guixing at November 29, 2014 03:29 PM

用https代替git-ssh来push

最近发现推送代码到github总是要账户名和密码,大多给出的解决办法是用ssh代替https就解决了,而且说是just simply。鄙人觉的这简直就是不负责任的解决办法(虽然之前我也是这么解决的),我忍你很久了。正确的方法是在家目录放一个.netrc的文件(win用户自动绕开,我不会告诉你们是在家目录放_netrc的),内容如下

machine github.com
   login <user>
   password <password>

REF: StackOverflow:Git push requires username and password

Update: 前面的方法请绕行,目前的做法是git config --global credential.helper osxkeychain.

by Guixing at November 29, 2014 05:42 AM

November 24, 2014

@khsing

打开spdy支持

把自己的站都给放到SSL下也有一阵子了,以前用startssl,头几天更新证书的时候StartSSL宕机了,索性就买了ssl。

今天打开了nginx 1.6的spdy支持,非常简单。

listen 443 ssl spdy;

by Guixing at November 24, 2014 04:07 AM

November 20, 2014

@shell909090

上下文切换技术

上下文切换技术 简述 在进一步之前,让我们先回顾一下各种上下文切换技术。 不过首 … 继续阅读

by shell909090 at November 20, 2014 02:38 AM

November 19, 2014

@khsing

手机和桌面的数据分享

苹果的订单发货了,给邮箱里来了一个链接,点开了就是跳转到EMS相应的快递追踪上去了。我习惯这个东西在手机上用「快递100」来管理,问题来了,怎么把这个快递单号扔给手机。之前的方法是放到evernote、Notes之类的云笔记本里,然后拷贝过来。

今天我尝试了一下用Chrome插件直接生成一个QR Code用快递100的App扫描一下就好了。

by Guixing at November 19, 2014 10:20 AM

November 18, 2014

@shell909090

上下文切换测试总结报告

效率测试 测试环境 Intel(R) Pentium(R) CPU G2030 … 继续阅读

by shell909090 at November 18, 2014 08:15 AM

@delphij

FreeBSD基金会收到史上最大一笔捐款

WhatsApp CEO及创始人 Jan Koum 宣布捐出一百万美元给 FreeBSD基金会。这是 FreeBSD 基金会成立十五年以来收到的 最大一笔捐款

Jan Koum 在他的 Facebook 页面上写道:

Last week, I donated one million dollars to the FreeBSD Foundation, which supports the open source operating system that has helped millions of programmers pursue their passions and bring their ideas to life.

I'm actually one of those people. I started using FreeBSD in the late 90s, when I didn't have much money and was living in government housing. In a way, FreeBSD helped lift me out of poverty - one of the main reasons I got a job at Yahoo! is because they were using FreeBSD, and it was my operating system of choice. Years later, when Brian and I set out to build WhatsApp, we used FreeBSD to keep our servers running. We still do.

I'm announcing this donation to shine a light on the good work being done by the FreeBSD Foundation, with the hope that others will also help move this project forward. We'll all benefit if FreeBSD can continue to give people the same opportunity it gave me - if it can lift more immigrant kids out of poverty, and help more startups build something successful, and even transformative.

by Xin LI at November 18, 2014 01:02 AM

November 12, 2014

@khsing

家庭无线打印搞定

最近给家里添了几个物件,基本实现了在家的无线打印需求。

关于佳能CP910,使用的感觉很不错,属于是热升华技术,相纸的成本比较高,但是家庭使用,也不是大批量打印,成本忽略了吧,打印出照片的喜悦完全淹没了成本问题,而且在TB还可以买到日本代购的相纸,相对稍便宜些。所以家里还缺了一个东西就是照片墙。

拿910配合来打印很方便,需要注意的就是它的dpi是300,在通过Aperture之类的打印的时候一定要选好了DPI,否则默认可是按72dpi打印的,那就糟烂透了。

Airport Express有点问题了,本想拿它作Wifi Repeater,但是这货只能和水果的东西做Repeater,一下子就变成了只和HP 1020打印机配合的AirPrint服务器了,功能减半啊,有点亏,现在开始考虑要不要给家里添一个水果的高端路由器(麻痹啊,苹果毁一生啊

其实CP910就是因为Ricoh GR买的,很不错的相机,成像很好,28mm定焦,有乐趣。不过我拍的比较差。

by Guixing at November 12, 2014 04:03 AM

November 07, 2014

@shell909090

手机上app的权限对比和分析

简述 今天看到这篇文章,勾起了我的好奇。我的手机里有多少app有安全隐患呢?当然 … 继续阅读

by shell909090 at November 07, 2014 08:16 AM

November 06, 2014

@shell909090

October 31, 2014

@shell909090

context切换测试——线程创建有关部分请求review

线程模式开销 使用t_thread程序,循环1M次,重复6次,原始数据如下: 9 … 继续阅读

by shell909090 at October 31, 2014 06:49 AM

October 30, 2014

@shell909090

context切换测试——调用开销有关部分请求review

函数调用开销 使用s_call来测试性能,循环1G次。 2.35,0.00,17 … 继续阅读

by shell909090 at October 30, 2014 08:10 AM

October 29, 2014

@shell909090

context切换测试——python有关部分请求review

python yield模式性能测试 python下的测试就不用time了,我们 … 继续阅读

by shell909090 at October 29, 2014 02:30 AM

October 28, 2014

@shell909090

September 25, 2014

@shell909090

bash严重漏洞

今天估计各大消息都在报这个漏洞,可能有些人看到有修复就放松了。目前来看,事情没那 … 继续阅读

by shell909090 at September 25, 2014 06:36 AM

September 04, 2014

@shell909090

送书

最近清理家中藏书,打算送掉一部分纸质书。于是顺手列了一批自己需要,但是可以外借的 … 继续阅读

by shell909090 at September 04, 2014 03:32 AM

August 19, 2014

@shell909090

如何分辨网站真假

老婆想去新疆玩,结果她居然从百度上搜了一下新疆国旅就联系开了。我一直不知道,直到 … 继续阅读

by shell909090 at August 19, 2014 03:44 AM

August 14, 2014

@shell909090

服务器操作系统的选择

今天被LTN问了一下怎么看一个知乎问题: 服务器操作系统应该选择 Debian/ … 继续阅读

by shell909090 at August 14, 2014 08:25 AM

August 13, 2014

@shell909090

架构师

一个好的架构师至少要做到四点: 识别甚至提前预测到程序不同阶段的性能瓶颈,并以合 … 继续阅读

by shell909090 at August 13, 2014 02:16 AM

July 30, 2014

@shell909090

14年7月,无甚大事

这个月比较忙,啥都没说。堆月底做个总结吧。 空难 一个月三起,马航又来一次。我都 … 继续阅读

by shell909090 at July 30, 2014 03:45 AM

July 02, 2014

@shell909090

July 01, 2014

@shell909090

狗肉节

吃没吃过狗肉 吃过,还不止一次,不过自己没点过。没特别觉得好吃,也没觉得难吃—— … 继续阅读

by shell909090 at July 01, 2014 02:44 AM

June 30, 2014

@shell909090

docker的原理和类比

从虚拟化的种类和层级说起 cpu虚拟化:可以模拟不同CPU,例如bochs 完全 … 继续阅读

by shell909090 at June 30, 2014 04:32 AM

June 26, 2014

@shell909090

核聚变?

最近看到一篇文章極限DIY之核融合反應爐。昨天和朋友吐了不少槽,我总结一下。 真 … 继续阅读

by shell909090 at June 26, 2014 05:34 AM

June 19, 2014

@delphij

Windows 2003笔记补遗

接上回书。

启用 virt-net 支持。采用 RedHat 的 virtio-win-0.1-52.iso 版本驱动,这是最后一个可以在 Windows 2003 上安装的版本,之后(0.1-59 及以上)的版本均有问题,这里先记一笔,等有空的时候再看看到底 KVM 把哪儿改错了。换网卡的过程中需要重新激活 Windows,直接网上激活即可。

将原有的 IDE 控制器换成 AHCI 控制器。这个其实主要是体力活:先切换芯片组并增加一个 AHCI 控制器,启动 Windows,然后在 Intel 网站找到 AHCI Windows 2003 的驱动(F6那款,以前装 Windows NT 时代插软盘的那种),那个未知设备就是虚拟出来的 Intel AHCI 控制器,选中刷掉驱动。重启后可摘除 IDE 控制器,并将磁盘挂到 AHCI 控制器上。

然后注意在 Windows 2003 中启用磁盘的 Advanced Performance,在换控制器的时候会需要。

by Xin LI at June 19, 2014 08:24 AM

June 18, 2014

@delphij

如何:将现有的 Windows 2003 单处理器实例转换成多处理器

我知道这是个十分蛋疼的需求。

这篇 介绍了如何转换,但是实际情况是进 Device Manager,打开 Computer,只会看到两个适用于单处理器的选项(一个ACPI,一个非ACPI)。

仔细查资料发现需要使用一个叫 DevCon 的工具。Q311272 可以下载这个工具。DevCon 可以绕开 Device Manager 的一些限制。

接下来是暗黑科技:

SET HAL=ACPIAPIC_MP
devcon.exe sethwid @ROOT\ACPI_HAL\0000 := !E_ISA_UP !ACPIPIC_UP !ACPIAPIC_UP !ACPIAPIC_MP !MPS_UP !MPS_MP !SGI_MPS_MP !SYSPRO_MP !SGI_MPS_MP
devcon.exe sethwid @ROOT\ACPI_HAL\0000 := +%HAL%
devcon.exe update %windir%\inf\hal.inf %HAL%
devcon.exe ReScan

然后重启即可。这一操作适用于在虚拟机中安装了Windows 2003,然后主机升级,增加内存及CPU数量之后的情形。

by Xin LI at June 18, 2014 11:48 PM

June 09, 2014

@shell909090

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

事情

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。既然无法驳斥,索性跟他说我会打回法兰红,就这样吧。然后挂了电话打回法兰红。

值得玩味的事在后面。法兰红的人听完整个流程,一言不发,给了我上海市运管处的电话。照理说作为管理母公司,你觉得我不对应当直接告诉我“师傅是对的”。如果你觉得我对就应该直接处理。运管处电话可能把没事的事惹出事来。给我运管处电话,基本只有两种可能:

  1. 运管处肯定会打太极,或者什么都不做。所以拿运管处当挡箭牌。
  2. 这件事我们也有难处。索性简单点,你有本事再往上面投诉。投诉出了结果,也没人有话说。但总之我们这里我没法帮你处理掉。

我打给运管处,他们说接受投诉。然后又是一通车号证号的,然后等回复。

分析

无论如何,宫霄出租车公司在管理上至少有以下几个瑕疵:

  1. 七天内不回复。没什么好多废话的。
  2. 根本没给乘客选项。在整个乘车过程中,出租车司机就没提供过“大连路隧道”和“杨浦大桥”这两个选项。如果你要用一个绕路的方案,至少要告诉乘客,可以走大连路,但是会堵。最后“大连路隧道”是我和宫霄的运管人员争论的时候出现的。

我有次曾经坐过一辆大众的车,从曹河泾回家。问说回浦东能不能更快点什么的,例如走徐浦大桥。司机马上跟我说那样会绕路,起码绕10公里。如果一趟车,乘客自己要绕过50%以上,哪怕是乘客自己要求的,也会要求乘客签单子避免责任。我当然不指望每个公司都有这个水准,但是至少说明“绕路一半以上”并不是什么常见选项,更不会是唯一选项。

其实我在坐车的时候,经常会和司机聊聊天。虽然大部分的司机都很油滑(上海话讲“老油条”),但是其中碰到的大部分人不坏。我见到过因为我身体不适,不能吹空调。大夏天关着空调开车子,开的自己一身大汗的师傅。我见到过不小心东西掉在车上,不要额外收费给我送回来的师傅。我见到更多的师傅,冷淡,油滑,事不关己高高挂起。但是基本上,大部分人都不坏。靠自己的本事吃饭,不会恶意绕路,或者拿着乘客的财物不还(要乘客出送还时的车费我觉得是合理的行规)。

但是,这一情况,在这几年,是越来越差而不是越来越好。

这一问题,我碰到一位师傅,他的分析让我觉得有几分道理。一辆车,一天24小时管理费300-400,油费300-400,一天要做到傍晚,挣的才是自己的钱。15天做一休一,才能挣到6000-7000元上下。有路道的做做私人司机,虽然只能挣个4000,但是工作强度只有三分之一不到。剩下的时间陪陪家里人,炒炒股票,上网卖点东西,日子也过的去。照他们那个强度推算,我们应该挣12000的。所以现在越来越没人要做出租车了。有本事的开开大车,有路道的当私人司机,或者做做小生意也行,只有其他什么都做不了的才做出租车。

我说所以出租车司机的素质越来越差么?

他说还不止。很多时候运管处要管,又没法管。管多了,司机不做了,运管处还要费心找人补上。出租车在上海是属于公众交通而不是私人企业,不能说不做就不做的,不做就大事件了。但是要做,又没有人,只能对一些事情眼开眼闭。对着乘客说,我们已经严肃处理了。对着司机口头警告警告算了——反正他们这辈子没那么巧刚好碰上。

他一说我顿时觉得确实是这样。07年的时候我投诉过一次拒载。当时公司运管核对了事情就和我说,要师傅打给你道歉还是怎么处理。我说还能怎么处理。他说扣师傅一天工资(好像是一天,还是多少),给我100元举报奖金。我想想算了,不是那么大的事,不结那么大的仇。师傅真给我打过来道歉了(虽然听着心不甘情不愿的)。12还是13年我投诉机场有人拒载的时候,公司运管给我打了个电话。“我们感谢您对公司的支持,如果没有您的举报,我们肯定无法发现这些败类。对于这次的事情,我们会严肃处理,以敬效尤。”听着很爽,不过注意到了没,既没说当事人的处理,举报奖金什么的也只字不提——而且关键是这个说辞很流利,我感觉这哥们的工作就是复读机。

这次,个人觉得,法兰红的运管对下属小公司也没有办法了——乘客你要来自己来吧。

建议

下面主要是给台湾朋友的建议了。我的外地朋友里面北京和台湾人比较多,如果是欧美——大概也看不懂中文吧。

不要随意打车。

如果你真的需要打车的话,先确定这不是一辆套牌车。套牌车运管是处理不了的,有什么问题自己倒霉。套牌有点像天灾,很少碰到,但是一旦碰到就是自己倒霉。你最好先看一下出租车的内装,如果不对的话就不要上车。

再确定这不是一辆小公司的车。哪些是大公司?巴士,大众,锦江,强生,海博,海虹,农工商。至少这些牌子我还叫的上来。其他公司的车子,一般也不会碰到问题。但是一旦碰到就很难处理。

注意,这不是说小公司没什么好人。我在小公司的车里面,碰到过很多很好的师傅。只是说,这些公司的投诉管理机制不给力——你得祈祷你没有用到这些机制的机会。

上海出租最重要一个特点是,属于公众交通而不是私人服务。因此有一条很特殊的规定——拒载投诉。主要是针对司机一听你这个地方,觉得不合算就不去了,你可以投诉他。

所以上车前先问师傅做不做生意。等师傅说做,上车后他问你去哪里再说。千万不要当街就把自己的目的地大声说出来。如果出租车司机没有主动询问你目的地,或者确定表明自己做你这单生意,你是不能投诉拒载的。也就是说,如果你一喊,我就去个隔壁。得一堆师傅纷纷表示不做你这个生意了——这是你自己问题,无法投诉。

而且如果你扬招车的时候,师傅当着你的面把出租车运营灯关了——也无法投诉。你自己拉开门坐进去,师傅关掉运营灯——无法投诉。你主动跑上去告诉他去哪里,他关掉运营灯——也无法投诉。

上海出租的一大奇观,就是在下午4-5点的下班高峰。你招手的时候,一堆车纷纷关掉运营灯——这是他们到了交班的时间,只能去特定的方向。如果你的方向不对他们是不会问的,省得给自己找麻烦。对了,如果上车前师傅已经说了只去哪里——也无法投诉。

另一个就是记得收好发票了。上海出租的乘车凭证就是车票,没有车票是不能投诉或者报销的。如果出现东西丢在车上也是要凭车票找人的。所以下车记得拿票。

至于东西忘在车上——抱歉不要指望。如果你有确定的证据证明是司机拿的,你可以投诉,或者卯起来告他到死。但是司机没有义务保管你的财务,或者在你下车时确定东西都拿上了。所以如果不能排除后面的乘客拿走的财务——事实上很难排除——那么几乎找不回来,而且你也不能投诉他。

哪种情况是可以比较完美的排除的?如果你的电话过去的时候,司机的第二个乘客还没有下车。这时候,还没有人离开过出租车,所以不是司机就是乘客拿了你的东西。但是比较悲剧的是,司机是没有权力搜查乘客的。所以如果乘客坚持没有看到,你还是没办法。

所以?要养成一个习惯。离开车前慢悠悠的搜一遍,确定东西都拿了,再下车。你搜的再慢,司机也不能赶你下车——你也不会真的搜上半天吧。

by shell909090 at June 09, 2014 09:46 AM

June 06, 2014

@shell909090

cgroup限定内存

机器配置

ubuntu 12.04

内核版本:3.11.0-20-generic

ulimit的限制效果

  1. ulimit -m 8192
    当内存突破8M时,什么事情都没有发生。直到38M都没任何反应。

  2. ulimit -v 65536
    python抛出MemoryError

cgroup的限制效果

  1. 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.6)

/proc/[pid]/status

statm的size和resident分别乘以pagesize等于VmSize和VmRSS。

pmap

pmap -p [pid]

可以看到某个进程内部,用户地址空间分配情况。

pmap -d [pid] | grep 'rw' | awk '{a += $2} END {print a}'

可以看到所有可写入的内存大小,应当正好等于正常显示的writeable/private。

这个值,应当等于status的VmHWM+VmStk。不知为何,VmStk和pmap里面显示的stack正好差了一个4k。怀疑是关于目前在正在使用的页的计算差异。

而high water mark,从分析上说,即是某个进程内部,不是stack的,所有可写的地址空间。当然,这些页并不一定立刻映射了物理内存。因此VmHWM > VmRSS应当没什么问题。

ps

ps和top都是读的status,不废话。

资源限制实践

准备

安装cgroup-bin

aptitude install cgroup-bin

setup cgroup-bin

修改/etc/cgconfig.conf:

mount {
        cpu = /sys/fs/cgroup/cpu;
        cpuacct = /sys/fs/cgroup/cpuacct;
        devices = /sys/fs/cgroup/devices;
        memory = /sys/fs/cgroup/memory;
        freezer = /sys/fs/cgroup/freezer;
}

group memimage {
        perm {
                admin {
                        gid = root;
                }
                task {
                        uid = user;
                }
        }
        memory {
                memory.swappiness = 0;
                memory.limit_in_bytes = 2048000000;
        }
}

限定内存用量2G。

service cgconfig start

执行效果

头部加入nice -n 19 cgexec -g memory:memimage

注意:使用内存限制,务必配置OOM日志告警通知。当重启时,管理者必须知道。当重复发生时,必须重新考虑内存限制问题。

监测

查看group内存状态

watch cat /sys/fs/cgroup/memory/memimage/memory.stat

by shell909090 at June 06, 2014 06:34 AM

@delphij

OpenSSL 的新一批漏洞

今天早上4点多就爬起来准备发安全公告(友商约的是早上5点发),一刷,OpenSSL官方已经正式发表了(时间大约是4点30),于是立即开始相关手续,commit修正,发公告,通知CERT,这些不表。

总体来说,这次安全公告比之前 Heartbleed 那回要有序的多,这主要归功于上回大家的声讨以及 Solar Designer 同学做的友商提前告知列表。大致时间线如下:

  1. 6月2日凌晨: OpenSSL 通知友商列表存在问题,要求同意 TLP:Amber 之后才告知具体细节。签署后约1小时得到了具体说明及补丁。
  2. 6月2日-3日:各友商各自修补,发现及反馈补丁问题。由于 TLP:Amber, FreeBSD 只有我和 des@ 及一位 OpenSSL 核心成员看到了公告草稿及补丁。
  3. 6月3日:FreeBSD 发表了本月第一批安全公告(这是更早前计划的周二批次)。此后立即开始着手联编 OpenSSL 特别更新。

本次问题可分成两类:SSL/TLS 和 DTLS。DTLS 常见于采用 UDP/SCTP 等 datagram 协议的应用,实际影响范围较小。

SSL/TLS 方面,CVE-2014-0224 CCS协议可在任意状态下使用的问题,可导致中间人攻击,后果严重,利用容易(可改变网络数据即可)但实际影响面较小,因为大部分人使用的浏览器并不是用 OpenSSL 来实现 SSL/TLS 支持的。但对邮件本身未做加密的邮件来说,基本等于是全军覆没了。这个漏洞存在了约16年,是的,十六年。发现者blog [英文]。我想,可能搞个可以形式证明的描述语言来重写SSL/TLS的实现才是正路?

另一个 CVE-2014-3470 可导致崩溃,影响较小一些。

值得一提的是,这次的一个 DTLS 问题 CVE-2014-0195 (可有任意代码执行之虞)也是上回引入 Heartbleed 的 Robin Seggelmann 引入的,呵呵。


总体来说,我觉得这批漏洞让人觉得有些绝望。 OpenSSL 有非常多的问题,但其中有很多必须对协议十分理解才能看出来,而另一方面看出来了报告给开发者也无非是得到几句赞扬而已。在现在这个年代,有能力看出来问题的人未必不会选择找个好的买家把漏洞卖掉。这种趋势十分危险,而最近几年有愈演愈烈的趋势。

by Xin LI at June 06, 2014 01:16 AM

June 03, 2014

@shell909090

为什么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个执行中线程(R),207个uninterruptible。

——所有的谜都解开了。

by shell909090 at June 03, 2014 06:43 AM

May 25, 2014

@shell909090

台北地铁砍人事件

哪里都有疯子

其实并没有疯,只是不论理由,就是要杀人而已——就是所谓的反社会人格。理论上心理咨询是可以发现的。但是台湾的经验告诉我们——目前的心理咨询密度不足,敏感度不足。而要维持足够的敏感度,不仅费用成问题,而且还会有很多啼笑皆非的情况。

社会压力?北欧够没压力了吧。2011年挪威发生爆炸和枪击。

废除死刑?

我不赞成废除死刑。当然,这和捷运杀人案本身并没有什么关系。他杀人的时候就知道自己会被判死刑。人不畏死,奈何以死惧之,死刑对凶手是没什么阻止力的。所以废除死刑还是保留死刑,都不能阻止凶案的发生。

但是死刑还是能阻止一些东西的。例如本次事件,死者中有两位20出头的年轻人。如果没有死刑,他们的父母会不会试着杀了凶手呢?反正活着也没什么意思,而且很讽刺的——我们也不能判这些人死刑。更进一步的,每次杀人案,我们需要严密保护的想必不是受害人,而是加害人——因为加害人不能死。而我们的法律为了保护加害人而存在,受害人遗族如果心理难以平复,只有自己动手,同时把自己变成受法律保护的人——就是加害人——才行。这样的逻辑不荒谬么?

死刑这事原本就没什么意思——我们已经遭到了损失,却还要用杀人来扩大损失。从这个意义来说,如果真是很久都没有恶性事件了——例如2011年挪威枪击和爆炸事件那样。这样的情况下,要不要废除死刑还真的可以商量。只是真的如此,我们应当判处什么人的死刑呢?长着野百合的绞刑架大概会成为城市最美丽的徽章。

死刑的意义在于,在无法无天的地方,我们有一种廉价的方法,可以永远的不用看到这个人。

和太阳花连结

咳,要认真论关系,马总统和杀人犯的关系绝对比太阳花近——这人的衣食住行,哪个不是受到政府政策的影响?是为期一个月的太阳花运动,还是持续执政数年的政府,更有可能造就一个杀手?两者哪个和凶犯的联系更多?持太阳花论的人认真想过这个问题么?

还有。包围行政院的年轻人去哪了?大概正在被各种凶案发生时的警察逮捕吧——你不觉得换个说法”凶案发生时,警察去哪了?“,这个质疑也能成立么?而且大部分凶案发生时都看不到警察啊,明明总统府门口一大堆的说。

也不要以为持这种论点的人是傻瓜。你讨论了这个问题,哪怕是否定,也达到了他们的目地——没有关系也是一种关系啊。我们不断讨论,有没有关系,有没有关系。不断得出结论,没有关系,没有关系——届时只要轻轻反问一句,真没有关系为何要讨论这么久,有人讨论过西瓜和美国国旗的关系么?没人讨论,是因为真的真的,一点点关系都想不到啊。

从这个角度来说,这种问题居然还需要讨论本身就很反常,你我都是网里的一个飞虫而已。

玩游戏和杀人的关系

比”吃饭和杀人的关系“近,比”没有女朋友和杀人的关系“远。从这个意义上说——难道政府要强制所有人谈恋爱?

by shell909090 at May 25, 2014 03:12 AM

May 21, 2014

@delphij

精生大法讨论:信用卡的 Balance Transfer

大通银行最近经常发一些其信用卡的 balance transfer 的活动。这种 offer 的特点是提供两张支票(一般来说有效期在2个月左右),通常提供18个月的免息期。

由于这种 offer 要收 2% 或 $5(以两者中较高者为准),所以我之前基本是直接碎掉的。今天和一位同学讨论了一下,发现似乎不是完全不存在合理价值,当然这次这份我还是要碎掉,但先把这个观点记下来,等以后有机会再做评估。

想要充分利用这种 offer,需要满足下面全部条件:

  1. 能够在18个月之内完全不使用这张信用卡。(使用条款规定,尽管 Balance Transfer 本身是18个月内 0% APR,算上 2% 的手续费不妨看做收 2 个点预付利息的小额贷款,也就是大约 1% APR,但此后新买的产品是按标准利率收取利息的。后者的利率通常在十几到二十几个百分点)。
    假如能封存这张卡18个月不用,好,这是一个 1% APR 的小额贷款,接着:
  2. 使用这些钱足以在18个月内产生至少2个点的税后收益。可能有同学说好,我去买 SPY,或者另类投资如 Lending Club,确实可以,但是这收益是没有保障的,而如果无法持有超过 1 年,又有可能按照短期资本利得来缴税,导致收益减少。
    购买能够免税的本州内城市债券基金可能可以。

我个人认为意义不太大:现金流不足的时候似乎应该采取更稳健的投资策略而不是继续举债?而如果现金流充足的话,为什么要举债投资呢?(毕竟信用卡的额度通常不会让一个人的现金流增加数倍,吧?)但是假如有很可靠的高收益投资机会,似乎并不是太坏的选择,只是在充分竞争的市场中出现这种投资机会应该不太常见就是了。

by Xin LI at May 21, 2014 05:41 PM

May 19, 2014

@delphij

Intel RDSEED指令

今天看到 John Baldwin commit 的这个 r266391 增加了相关支持。

RDSEED 和 RDRAND 的区别是 RDRAND 采用的是 128-bit AES 密钥的 CTR-DRBG,而 RDSEED 则是直接从真随机数发生器中获得输出(两者并不是直接使用真随机发生器的输出,这些输出是做过 AES-CBC-MAC 处理的,防止外界通过观测输出了解内部运行的细节),较慢,后者具备 multiplicative prediction resistance 特性。

具体细节可以参考 Intel® Digital Random Number Generator (DRNG) Software Implementation GuideThe Difference Between RDRAND and RDSEED

Intel 的后一份文档中建议实现 PRNG 时使用 RDSEED,不太清楚这样做是否会同时复位 RDRAND 的状态?假如不复位的话,这样做似乎也意义不太大?(PRNG 的实现者应该从更多的地方收集 entropy 而不是假定真随机发生器的输出可信)。

此外, DRNG 用的 AES-CBC-MAC 这个事情,我认为是一把双刃剑(虽然用比不用要好),因为这样一来便很难验证来自硬件的随机数是否具有某些特性了(此外我找到的文档也没有具体描述如何 AES-CBC-MAC 是如何使用的)。

by Xin LI at May 19, 2014 05:20 AM

May 08, 2014

@shell909090

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很类似,主要修改是以下两点:

  1. 使用一个可靠链接(这里是经过加密的TCP),在这个链接里面封装多对传输。
  2. 每个链接只要一次验证。

这样做,首先减少了一次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列表相对来说固定)。

问题是DNS解析过程。msocks内置了DNS能力,可以帮助做DNS。但是实践下来发现这样做效果并不很好。而原本是采用直接DNS,丢弃特定的报文。这样可以过滤防火墙污染。

原因很简单。原本的模式会让DNS服务器感知到查询者位于中国,于是给出中国可以访问的最快地址。而新的模式则会将DNS请求者搬到美国——这无故加重了代理的负担。例如www.qq.com,原本只需要请求得到一台深圳的服务器即可,现在则需要让DNS绕出去,再回来。如果不幸,QQ有一台位于美国的服务器,那么我的访问都会通过这台服务器——这可比深圳的服务器慢多了。

地址

抱歉刚刚忘记写地址了:

goproxy

debian/ubuntu安装包:amd64 i386

by shell909090 at May 08, 2014 08:41 AM

May 04, 2014

@delphij

记一笔关于iPad的DFU mode

由于送修 iPad 最终没有修好,因此店家给提供了一台二手的 iPad。作为不折腾就会死星人我觉得显然应该重刷一遍固件(卖家已经重新清空了数据),因此做了一次 DFU mode 固件更新。

具体做法是先把 iPad 接在 Macbook 上,同时按住 power 和 Home。等待大约10秒后屏幕變黑,此时按住 Home,等到 iTunes 上可以看到 Recovery 为止。

然后就是刷 iOS 和恢复数据了,此前过程中在网关听包未见明显异常。

by Xin LI at May 04, 2014 09:23 AM

April 19, 2014

@delphij

Heartbleed之危机公关处理

这次 Heartbleed 安全漏洞之后,阿里巴巴集团的多个产品均迅速修复了漏洞(好事),但事后的公关处理做的却有待改进。

我在微博上看到有人转发 阿里安全 在4月9日13:01发表的一篇微博,内容如下:

关于OpenSSL某些版本存在基于基础协议的通用漏洞,阿里各网站已经在第一时间进行了修复处理,目前已经处理完毕,包括淘宝、天猫、支付宝等各大网站都确认可以放心使用。

紧接着, 支付宝 转发了 这条微博:

大家可以放心了!

我并不是阿里巴巴/支付宝的客户,不过看到有人转发这条消息,我半开玩笑地 回了一句:

冲这句"大家可以放心了"就没法放心了......

有疑似工作人员的同学在我这条微博下面发表了评论,并指出真实情况可能会吓到用户。但坦率地说,我还是认为这样的公关做法是不对的,公众在发生这类重大安全问题的时候,了解全部事实有助于消除他们的恐惧心理。

我为什么说冲这句"大家可以放心了"就没法放心了呢?原因很简单,一句简单的"大家可以放心了"给我的第一印象是相关的工作人员并没有向公司的公关部门交代清楚到底发生了什么,以及它的影响是什么:给服务器运行的软件升级只是万里长征的第一步而已,而假如公关部门认为这件事只要升级之后就可以忽略全部其他问题的影响,并且向公众如此宣示,那么公众很可能就不会再继续关注这起事件,而忽略了必要的自我保护的措施。

这种忽视对于用户和支付宝都是不利的。在用户方面,由于缺乏必要的保护措施,很可能导致不必要的损失,而由于这种损失并不完全是用户的问题,用户很可能进一步向支付宝求偿。假如发生这种情况,除了双方会有经济损失之外,也会对支付宝产品的声誉以及用户信心发生影响。

我认为PR部门应该根据初步的评估做出:"我们的系统未受影响。""我们的系统受影响,但问题已经修复,我们将会通知所有受影响的用户。"这样的的宣布。具体到 Heartbleed 这个问题上,仅仅修补软件漏洞是远远不够的,由于攻击者有可能已经窃取了证书的私钥(透过简单的如架设假基站、开放wifi热点,或较为复杂的、配合DNS投毒的攻击手段,攻击者可以架设和真正网站一模一样的网站而不被用户发现),因此作为补救措施,网站的运营者只有在先修补了软件问题,并更换了所有证书并撤销旧证书(这是很容易忽略的一步)之后,才可以认为问题已经完成了"修复处理"。

在用户方面,则需要对自己所受的影响做出一定的评估。例如,网站运营者至少应根据运营日志给出一个大致的时间点:某年月日(升级到受影响的 OpenSSL 1.0.1)到某年月日(完成修复处理)之间登录的用户,其信息存在失窃之虞。由于这本质上是一个缓冲区过读问题,攻击者可以完美地伪装请求(没有有效的方法知道攻击者在什么时候进行了攻击:系统日志中不会记录什么时候收到了来自谁的心跳信号;即使知道,也没有有效的方法知道到底哪些内存内容遭到了泄密),除了根据运营日志的记录来查询用户的登录日志之外,事实上没有很好的办法知道哪些用户受到了影响。对于一个安全性非常重要的网站而言,此时最稳妥的做法就是首先假定所有用户都受到了影响,然后尽量找到那些一定没有受到影响的用户,然后通知两者的差集。

作为电子商务网站,由于用户在使用过程中可能会输入信用卡号,因此这些信用卡号也同样有泄露的风险。网站方面可以做的事情不多,但应在用户登录后明确告知用户哪些信用卡信息有可能发生泄露,应关注账单异常等等。

当然,我没有支付宝账户,而且即使在平时我也有经常改密码和查看信用卡对帐单的习惯,因此我确实是可以放心的。

by Xin LI at April 19, 2014 12:31 AM

April 18, 2014

@delphij

OpenBSD fork 了 OpenSSL

OpenBSD [捐款链接] 又一次出手为民除害了! Undeadly报道: OpenBSD has started a massive strip-down and cleanup of OpenSSL

这次 Heartbleed 的事情搞的我十分不爽,这事固然不能全怪 OpenSSL 的开发者,但是整个过程非常的让人不舒服,具体的就不多说了。等过个几十年再回头看看这次这件事情再说吧。

OpenBSD 目前对 OpenSSL fork 的改进主要包括:

  • 修正了一处释放后还在使用内存的问题
  • 清理了一系列在 OpenBSD 上不需要的垃圾代码
  • 删除了绝大多数后端引擎(VIA padlock、Intel AES-NI支持除外)
  • 去掉了一系列用于移植的函数封装。
  • 使用了易读的 KNF (BSD的代码风格)取代坑爹+反人类的 GNU C 风格
  • 去掉了可能弱化随机数的代码
  • 砍掉了 Heartbeat 功能作者所写的全部代码

我个人非常希望 OpenBSD 的 fork 能够成功,那样的话我们就可以在几年以后(已经发布的版本还需要继续支持一段时间)彻底从 FreeBSD 基本系统中砍掉 OpenSSL 了。

by Xin LI at April 18, 2014 07:25 PM