今天小編分享的科學經驗：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
— 完 —
點這裡關注我，記得标星哦～
一鍵三連「分享」、「點贊」和「在看」
科技前沿進展日日相見 ~
>
