云风的buzz中提到了coolshell.cn的一篇文章Linux 2.6.39-rc3的一个插曲有感，看过之后，有两个感受：
（1）Linus 提出的 ‘think and analyze’的解决方式。
对于bug，从我解读Linus和Cloud的buzz回复来看，他们对于bug的方式都是知其然也知其所以然，即要么不去改bug，要么就把bug想清楚了从系统上改好。就像给一个人看病，要是治胃疼，不是说你少吃点，或者是来几片止疼药，而是调查清楚为什么得了胃病。要是长期不规律吃饭得的胃病，恐怕最好的解决方法是养成按时吃饭的习惯。这样做会增加改一个bug的时间。但从长远来看，我们有可能节省时间。比如：如果我们引入magic number之后，一个星期之后，又有类似的bug发现了，如果我们每个bug都是通过仔细思考，而且系统构建有足够的正交性的话，我们会很自然的想到，这个bug肯定发生在其他部位，而不太可能是刚修复bug的变体，这就减少了解决问题时的思考路径，节省了时间。这个时候，我们应该对自己说Good job，给自己多一点鼓励。
而有时，我们可能在别人的代码里发现了bug，这种情况下同样适用Linus的建议，即‘think and analyze’或者是’years and years of testing on thousands of machines’。要不能通过思考和分析解决问题，要么就用历史证明过的已经work的代码。这样即使不能fix 这个bug，也不会造成fix bug的假象，从而避免以后有的版本work，有的版本不work的现象。读通别人的代码并不简单，这个’think and analyze‘的过程也许要很多天，因为这个过程强迫我们用别人的思维结果来思考，而我们很难知道为什么别人这样做。个人认为，如果有足够的单元测试和高质量的文档，这个思考分析的时间并不是浪费，而是学习其他人编程思路和技巧的机会。同时，我们应该让老板知道，我们需要时间来读代码，我们在解决问题，但是的确需要时间。如果一个系统的核心部分很难读懂，而bug并不关键，不妨告诉自己不要太完美主义（想想iphone，没有多任务，电池续航有限，价格高，但仍然一个好产品）。
总而言之，Linus的观点就是每看到一个bug，问一下你确实了解这个bug的原理么？
如果Yes: （think and analyze之后），准备重组的理由，用别人可以理解的方式改（少用magic number）。
如果No： (‘years and years of testing on thousands of machines’) 回到以前测试好的版本，并且注明这个bug没有被fix。
这就是Linus认为的： It really is that simple. It’s _always_ that simple.
（2）对Yinghai Lu的评价
首先Yinghai Lu是一个kernel开发者，我认为他是有足够的相关经验的：很快发现了问题，提出了一种解决方法
陈皓认为“我没有想到Linux 内核组会有像Yinghai这样工作的方式，毕竟这是一个黑客级的开发团队。” 我认为言之过甚。
Yinghai 的 email 中说：” can you try following change ? it will push gart to 0x80000000″ （你能不能试试这个？）
而陈皓说“给出了个fix”，他认为Yinghai提出的是会加入到kernel code中的patch，我想这不一定是Yinghai的本意。
以我的理解来看，Linus一直负责code review，他希望code的质量高，有注释，不能随意fix bug （改一两个数）。因此他非常反感code中的magic number，以及只改code不管背后的逻辑；而Yinghai Lu做为开发者，首先想到的是找到问题的原因。他自己的电脑里没法重复这个bug，因此他需要把patch交给别人来测试。在不同的立场下，Linus生气 和 Yinghai的解释 就容易理解了。
我不清楚kernel开发的具体流程是怎样的。但我认为Yinghai 试图做的是在top down这个框架下做修补，他不想或者不能够对整个top down的机制做出修补，特别是这个机制下已经有垃圾代码的情况下（见HPA的回信）。在Linus看来，他是不希望看到top down这种新尝试（相对于bottom up)缺乏足够的调研支持的。至于未来Linux kernel的采用机制，将要由kernel 开发者们和Code reviewer之间做出协调，也要和以往的低质量代码做出协调。我会拭目以待。