深入了解 Linus 如何、何时以及为何在内核邮件列表中发帖。

Linus Torvalds 有时因粗暴地斥责内核开发者而受到批评。他确实会这样做，但这并非他的默认行为，而且我认为他何时以及如何在邮件列表中发帖的真实性质很有趣。例如，他长期置身事外，没有参与关于如何替换 BitKeeper 版本控制系统的整个讨论，让各种项目令人沮丧地猜测他的意愿，然后他最终从 Linux 开发工作中抽身出来，设计并实现了 git。

在其他情况下，他允许开发者就内核的关键要素或新硬件外围设备的行为互相猛烈抨击数天或更长时间，之后才介入辩论，通常是提出一个双方阵营都没有想到的更简单的解决方案。

有时他参与讨论显然仅仅是因为某个特定的错误或一段代码引起了他的兴趣，并且他与发布特定补丁的人合作，以解决缺陷或追踪潜在问题。

总的来说，Linus 倾向于不参与大多数讨论，主要只在有争议的问题上在他形成自己的立场之后才介入。

但是，是的，有时他对开发者非常严厉，通常说他们应该已经知道不应该做某件事，或者当他觉得开发者在推销某种违背开源开发精神的企业目标时——尽管我怀疑他自己是否会这样表达。他似乎不喜欢发表公开的布道式声明，并且倾向于坚持他在采用 BitKeeper 时所采取的“如果它有效，我就喜欢它”的态度。

偶尔，Linus 会在技术问题上犯错——他会声称关于内核的某些事情是真实的，但实际上并非如此。最近就发生了一个例子，当时 Amir Goldstein 发布了一个补丁来修改字符串哈希函数。这是一个小补丁，在 64 位情况下保留了一些丢弃的位，并使 32 位情况几乎没有改变。Amir 征求 Linus 的建议，因为他找不到该文件的维护者，而 Linus 是最近修改该代码的人之一。

Linus 不同意 Amir 的代码使 32 位情况保持不变。并且他特别指出调用 __hash_32() 函数尤其耗时。他拒绝了 Amir 的补丁，说：“就目前而言，这个补丁似乎没有任何好处，只会增加成本。”

但是当 Amir 指出他的补丁实际上并没有添加对 __hash_32() 的调用，而是调用已经存在时，Linus 重新看了一下并回复说：“哦，duh。我的错。它确实已经在那里了。让我回去看看这东西的历史记录。”

他后来回复了自己的帖子，说

在更仔细地查看之后，我收回我对这个补丁的所有抱怨，你是对的，而我误读了内容或者只是犯傻了。

我也不太担心这在 64 位上可能造成的性能影响，因为大多数真正关心性能的架构最终都不会经常使用它（dcache 代码是最注重性能的，但是逐字情况无论如何都使用自己的哈希）。

因此，这最终主要用于执行自己的降级哈希的文件系统（通常是因为他们想要一个不区分大小写的比较函数）。

仍然存在一个 _很小_ 的担忧，即并非每个人都使用 DCACHE_WORD_ACCESS，那么这可能会使在 64 位架构上，即使对于正常情况，multiplier 较慢或缺失的情况下，事情变得更加昂贵。

也就是说，实际上我能想到的唯一这样的架构是 PA-RISC。没有人真正在乎它上面的性能，它更像是一个“看妈，我有疣^W一台奇怪的机器”平台。

所以我认为你的补丁很好，我最初的所有担忧都只是因为没有正确看待这个问题而产生的误判。

抱歉。

对我来说，这种帖子的有趣细节在于，Linus 似乎从不拖延承认错误。他不会因为尴尬而固执于一个错误的观点；他也会避免为自己犯错找借口，或者将对方视为不重要。在意识到自己犯了错误之后，他似乎也投入了真正的工作来正确理解情况，并直接着手处理任何新的技术细节。

我个人很喜欢所有这些。对我来说，这为他何时对开发者生气增加了背景。这种情况似乎主要——或仅在——当他觉得开发者应该在某个时间点之前看到并承认自己的错误时才会发生。