今天小编分享的科学经验：Linus新年首骂：和谷歌大佬大吵4天，“你的代码就是垃圾”，欢迎阅读。
风风火火的Linux 之父，Linus Torvalds，他又跃入公众的视线。
" 打开方式 " 依旧是熟悉的配方——骂人。
我们先来看下 Linus 怒怼的名场面：
你的代码就是垃圾。
我要把你丢进垃圾邮件一周。
而这一次的 " 受害者 "，是来自谷歌的一位程式员，Steven Rostedt。
而且他并非是随随便便的一位开发者，用网友的话来说 " 也算是大佬了 "。
△图源："OSC 开源社区 " 评论区
不仅如此，从时间线上来看，双方已经交锋了足足有4 天之久……
那么这到底是怎么一回事？
一个 "inodes"，吵了四天
这场激辩是发生在 Linux 内核邮件列表。
Steven 起初是发了个帖子，主题是关于 eventfs（事件檔案系统）的补丁。
具体而言，就是想探讨一下 inodes（索引节点）是否应该保持唯一性的问题。
（注：inodes 是 Linux 檔案系统中的一个核心概念。它是一个数据结构，用于存储檔案或目录的元数据，而不是檔案的实际内容。）
Steven 认为：
Linus 之前建议在 eventfs 中使用相同的 inode 来简化 getdents ( ) 的实现，这意味着所有檔案和目录都将使用相同的 inode。
然而，这种做法后来被发现会导致 "find" 命令出现问题，因为目录和檔案的 inode 相同。
Linus 随后发现在 64 位机器上，eventfs_inode 结构中存在一个由于对齐而产生的空洞，可以用来存储目录的 inode，这解决了目录的问题，但檔案仍然保留了自己的 inode。
在 Steven 看来，由于 tar 命令依赖于 inode 来确定檔案的唯一性，这种做法会破坏 tar 命令的功能：
目前，tar 命令在 tracefs（事件檔案系统的一个变体）中已经出现问题，因为它显示所有檔案的大小为零，导致 tar 不复制任何内容。
除此之外，Steven 也给出了自己想到的解决办法——建议将 VFS 层的 get_next_ino ( ) 函数复制到 tracefs 的 tracefs_get_next_ino ( ) 函数中，并添加一个 "files" 参数。
这样，当创建 eventfs 目录时，就可以预先知道所需的 inode 数量。tracefs_get_next_ino ( ) 将返回一个新的 inode，并预留下一个 "files" 个 inode 供调用者使用。
当创建檔案的 inode 时，其 inode 将是其父目录的 inode 加上在该目录檔案数组中的索引，从而为每个檔案提供一个唯一的 inode。
然而，如此提案却被 Linus 强烈反对。
Linus 的核心观点是"inode 已经不再是唯一的描述符，我们不应该继续依赖于这种旧有的机制 "。
不过对于 Linus 的回复，Steven 并没有买账，他坚持认为：
所有的檔案和目录应该有唯一的 inode，这样做可以对檔案系统的某些方面起到简化的作用。
然而在几轮探讨过后，Linus 就坐不住了，随即就出现了刚才怒怼的名场面：
不要把事情变得那么复杂。
你没有充分理解这些函数的用途和必要性
双方似乎都是各执己见，来来回回博弈了良久，从 1 月 26 日一直 battle 到了 1 月 29 日……
不过戏剧性的一点是，Linus 在争吵之余，后来还发布了 Linux 内核 6.8-rc2 版本。
他希望这个版本能够解决之前版本中发现的问题，并鼓励用户进行测试。
并非第一次公开 " 交锋 "
其实在此之前，Steven 也曾在 2020 年初之际，在一场活动演讲中，公开与 Linus" 交锋 " 过。
他甚至直接将演讲的主题定位"Arguing with Linus Torvalds"，内容依旧是围绕着如何让 Linux 效率得到改善而做出的建议。
不过对于这次最新的 battle，网友们也是各抒己见。
有认为应该抛弃历史包袱的，有认为只是二人设计理念的差距：
△图源："OSC 开源社区 " 评论区
你觉得呢？
参考链接：
[ 1 ] https://lkml.iu.edu/hypermail/linux/kernel/2401.3/04208.html
[ 2 ] https://www.youtube.com/watch?v=0pHImHVrI2I
[ 3 ] https://mp.weixin.qq.com/s/S0R_5OBSiSbDnl1-U6I4wg
— 完 —
点这里关注我，记得标星哦～
一键三连「分享」、「点赞」和「在看」
科技前沿进展日日相见 ~
>
