Log for Ubuntu 台灣社群
Linux 核心 7.2 的開發統計資料 （★ 70 分）
Linux 核心 7.2 於 8 月 17 日釋出，Linus Torvalds 指出修正數量仍高於預期。本版納入 16,418 筆非合併提交紀錄，新增近 60 萬行程式碼，是歷來第二繁忙的開發週期，僅次於因併入 bcachefs 完整開發歷程而異常龐大的 6.7。共有 2,652 名開發者參與，刷新 7.1 的紀錄，且變更來源分布廣泛，而非集中於單一大型專案。以提交數計，Uwe Kleine-König、Rosen Penev 與 Ian Rogers 最活躍；以變更行數計，AMD（超微）圖形驅動程式的大型自動產生標頭檔占了顯著比重，Rust 的 zerocopy 程式庫也首度納入核心原始碼。
本版僅略高於 8% 的提交附有 Tested-by 測試標記，48% 附有 Reviewed-by 審查標記，後者近幾版呈現溫和下滑，但未必代表實際審查量減少。可辨識的雇主共有 249 家，以提交數計，Intel、Google、Red Hat、AMD 與 Qualcomm 居前；若以變更行數計，AMD 占 22.4%，明顯領先。值得注意的是，未能辨識雇主身分的開發者大增，可能反映大量新進參與者湧入。7.2 有 613 名首次出現的貢獻者，再度打破紀錄；其中 Bryam Vargas 在單一週期橫跨許多子系統提出 43 項修正，廣度之大引發作者對其是否真正掌握程式內容的疑問。
大型語言模型（LLM, Large Language Model）已明顯改變核心開發。7.2 有 1,111 筆提交附上 Assisted-by 標記，不到總數 7%，但遠高於 7.1 的 301 筆；實際受 LLM 協助的數量可能更多，因為不少人未標示，部分維護者也不會追問。Sashiko 自動審查系統獲列為問題回報來源的提交有 252 筆，另有 568 筆提交在變更說明中提及它。帶有 Fixes 標記、用以指出修正既有錯誤的提交達 4,830 筆，近幾版急升，文章認為這與大量開發者用 LLM 搜尋既有缺陷有關。不過，作者警告，若 LLM 讓不完全理解程式的人也能大量提交修正，核心可能累積難以維護、無人真正理解的程式碼；而 linux-next（整合下個版本候選變更的樹）已有近 1.4 萬筆變更等待納入 7.3，其中逾 1,100 筆帶有 Assisted-by 標記。
Hacker News 討論主要圍繞 LLM 是提高效率還是加劇維護負擔。有維護者表示，代理工具可協助重現錯誤、除錯與提出修正，大幅加快處理速度；但外部貢獻者的代理工具也會送來龐大的拉取請求（PR, pull request），使人工審查難度升高。支持者認為，LLM 能協助熟悉技術細節卻不熟核心投稿規範的人處理繁瑣程序，能力與是否使用工具不必然相關，正如編譯器並未使開發者失去理解能力。反對者則指出，Linux 核心原本並不缺乏貢獻者，更在意的是可審查與可維護的品質；LLM 產生的大量修補可能讓審查成為瓶頸，甚至引入難以察覺的錯誤。討論也批評原先 Hacker News 投稿標題過度強調「錯誤修正數倍增」，忽略文章對 LLM 風險的審慎立場，後來已改回原始標題。
👥 27 則討論、評論 💬
https://news.ycombinator.com/item?id=50132950
Linux 核心 7.2 於 8 月 17 日釋出，Linus Torvalds 指出修正數量仍高於預期。本版納入 16,418 筆非合併提交紀錄，新增近 60 萬行程式碼，是歷來第二繁忙的開發週期，僅次於因併入 bcachefs 完整開發歷程而異常龐大的 6.7。共有 2,652 名開發者參與，刷新 7.1 的紀錄，且變更來源分布廣泛，而非集中於單一大型專案。以提交數計，Uwe Kleine-König、Rosen Penev 與 Ian Rogers 最活躍；以變更行數計，AMD（超微）圖形驅動程式的大型自動產生標頭檔占了顯著比重，Rust 的 zerocopy 程式庫也首度納入核心原始碼。
本版僅略高於 8% 的提交附有 Tested-by 測試標記，48% 附有 Reviewed-by 審查標記，後者近幾版呈現溫和下滑，但未必代表實際審查量減少。可辨識的雇主共有 249 家，以提交數計，Intel、Google、Red Hat、AMD 與 Qualcomm 居前；若以變更行數計，AMD 占 22.4%，明顯領先。值得注意的是，未能辨識雇主身分的開發者大增，可能反映大量新進參與者湧入。7.2 有 613 名首次出現的貢獻者，再度打破紀錄；其中 Bryam Vargas 在單一週期橫跨許多子系統提出 43 項修正，廣度之大引發作者對其是否真正掌握程式內容的疑問。
大型語言模型（LLM, Large Language Model）已明顯改變核心開發。7.2 有 1,111 筆提交附上 Assisted-by 標記，不到總數 7%，但遠高於 7.1 的 301 筆；實際受 LLM 協助的數量可能更多，因為不少人未標示，部分維護者也不會追問。Sashiko 自動審查系統獲列為問題回報來源的提交有 252 筆，另有 568 筆提交在變更說明中提及它。帶有 Fixes 標記、用以指出修正既有錯誤的提交達 4,830 筆，近幾版急升，文章認為這與大量開發者用 LLM 搜尋既有缺陷有關。不過，作者警告，若 LLM 讓不完全理解程式的人也能大量提交修正，核心可能累積難以維護、無人真正理解的程式碼；而 linux-next（整合下個版本候選變更的樹）已有近 1.4 萬筆變更等待納入 7.3，其中逾 1,100 筆帶有 Assisted-by 標記。
Hacker News 討論主要圍繞 LLM 是提高效率還是加劇維護負擔。有維護者表示，代理工具可協助重現錯誤、除錯與提出修正，大幅加快處理速度；但外部貢獻者的代理工具也會送來龐大的拉取請求（PR, pull request），使人工審查難度升高。支持者認為，LLM 能協助熟悉技術細節卻不熟核心投稿規範的人處理繁瑣程序，能力與是否使用工具不必然相關，正如編譯器並未使開發者失去理解能力。反對者則指出，Linux 核心原本並不缺乏貢獻者，更在意的是可審查與可維護的品質；LLM 產生的大量修補可能讓審查成為瓶頸，甚至引入難以察覺的錯誤。討論也批評原先 Hacker News 投稿標題過度強調「錯誤修正數倍增」，忽略文章對 LLM 風險的審慎立場，後來已改回原始標題。
👥 27 則討論、評論 💬
https://news.ycombinator.com/item?id=50132950
而且還成功，讓他可以跑docker
我知道那台型號其實有支援docker 但是實際上他docker是執行，在他另外單獨的SL的那個板子上
而我是讓他也能夠執行docker在BCM上面
我知道那台型號其實有支援docker 但是實際上他docker是執行，在他另外單獨的SL的那個板子上
而我是讓他也能夠執行docker在BCM上面