Log for Ubuntu 台灣社群
WireGuard 在微軟簽章問題解決後，釋出新版 Windows 版 （★ 131 分）
WireGuard 推出久違的 Windows 版更新，這次同時釋出低階核心驅動 WireGuardNT v0.11，以及較上層的管理軟體、命令列工具與使用者介面 WireGuard for Windows v0.6。作者 Jason A. Donenfeld 表示，他平常很少為 Windows 版另外發公告，因為內建更新程式通常會主動通知相關使用者；但由於這一版間隔特別久，外界又出現不少相關新聞，因此特地說明新版已正式上線。
功能面上，新版新增可單獨移除允許通過通道的 IP 規則 ( allowed IPs ) 而不必中斷封包傳輸，也能在 IPv4 連線上設定很低的 MTU ( Maximum Transmission Unit，最大傳輸單元 )。更重要的是，這次整併了長期累積的錯誤修正與效能改進，並在提高最低支援 Windows 版本後，刪除了大量為了相容舊版而存在的補丁、替代程式路徑與動態分派邏輯，讓整體基礎更單純也更穩固。開發工具鏈 ( toolchain，開發工具組合 ) 也一併更新，包括驅動程式使用的 EWDK ( Enterprise Windows Driver Kit，企業版 Windows 驅動開發工具 )、使用者空間工具採用的 Clang/LLVM/MingW 編譯工具、主要介面採用的 Go 程式語言，以及 EV 憑證 ( Extended Validation，延伸驗證 ) 與簽章流程，預期可帶來更好的效能與較現代化的程式架構。
由於這是相隔許久後的第一個 Windows 版發佈，Jason 也特別呼籲使用者多加測試，留意是否出現回歸問題。團隊表示，軟體已在 Windows 10 1507 Build 10240 這個仍列入 WireGuard 支援範圍、但已不再由 Microsoft 維護的舊版本上測試；一般使用者可透過內建更新程式驗證簽章後安全升級，也可直接下載安裝程式。對於先前外界關注的 Microsoft 簽章爭議，他補充說，問題出在新版 Windows NT 核心驅動送交 Microsoft 簽署時，開發者帳號一度被停權；消息在 Hacker News 與 X 擴散後，Microsoft 隔天就解除限制，因此新版才能順利釋出。他認為這比較像官僚流程失控，而不是針對 WireGuard 的蓄意打壓。
討論焦點隨後轉向平台治理，而不只是新版功能本身。一派人同意維護者的說法，認為這更像大型企業常見的官僚失誤，不宜直接上綱到陰謀；但更多高分留言認為，關鍵不在動機，而在結果：只要一套自動化與人工審核脫節的簽章制度，能讓開發者突然失去發佈更新的能力，卻又沒有可直接聯絡的人工處理窗口，最後只能靠社群媒體聲量或登上 Hacker News 首頁才獲得處理，那就已經足以傷害信任。留言者也擔心，當程式碼簽章幾乎成為 Windows 平台的必要門檻後，開放原始碼軟體 ( FOSS, Free and Open Source Software ) 的更新能力等於被單點控制。
也有人把這次事件與 VeraCrypt、LibreOffice、WinFsp 等專案相提並論，質疑這是否已成為可辨識的模式；其中一名 WinFsp 開發者表示自己也受到影響，另有工程師說公司帳號已被鎖超過一個月，Microsoft 支援人員只暗示可能是系統性錯誤。Jason 在留言中則補充，這次發佈除了簽章問題，還碰上最新驅動 SDK ( Software Development Kit，軟體開發工具組 ) 不再提供 x86 ( 32 位元 ) 驅動編譯支援等技術變動。整體而言，社群一方面肯定 WireGuard 的 Windows 版終於恢復更新，另一方面也把這件事視為對大型平台權力、人工申訴機制與軟體多樣性風險的一次警訊。
👥 54 則討論、評論 💬
https://news.ycombinator.com/item?id=47719942
WireGuard 推出久違的 Windows 版更新，這次同時釋出低階核心驅動 WireGuardNT v0.11，以及較上層的管理軟體、命令列工具與使用者介面 WireGuard for Windows v0.6。作者 Jason A. Donenfeld 表示，他平常很少為 Windows 版另外發公告，因為內建更新程式通常會主動通知相關使用者；但由於這一版間隔特別久，外界又出現不少相關新聞，因此特地說明新版已正式上線。
功能面上，新版新增可單獨移除允許通過通道的 IP 規則 ( allowed IPs ) 而不必中斷封包傳輸，也能在 IPv4 連線上設定很低的 MTU ( Maximum Transmission Unit，最大傳輸單元 )。更重要的是，這次整併了長期累積的錯誤修正與效能改進，並在提高最低支援 Windows 版本後，刪除了大量為了相容舊版而存在的補丁、替代程式路徑與動態分派邏輯，讓整體基礎更單純也更穩固。開發工具鏈 ( toolchain，開發工具組合 ) 也一併更新，包括驅動程式使用的 EWDK ( Enterprise Windows Driver Kit，企業版 Windows 驅動開發工具 )、使用者空間工具採用的 Clang/LLVM/MingW 編譯工具、主要介面採用的 Go 程式語言，以及 EV 憑證 ( Extended Validation，延伸驗證 ) 與簽章流程，預期可帶來更好的效能與較現代化的程式架構。
由於這是相隔許久後的第一個 Windows 版發佈，Jason 也特別呼籲使用者多加測試，留意是否出現回歸問題。團隊表示，軟體已在 Windows 10 1507 Build 10240 這個仍列入 WireGuard 支援範圍、但已不再由 Microsoft 維護的舊版本上測試；一般使用者可透過內建更新程式驗證簽章後安全升級，也可直接下載安裝程式。對於先前外界關注的 Microsoft 簽章爭議，他補充說，問題出在新版 Windows NT 核心驅動送交 Microsoft 簽署時，開發者帳號一度被停權；消息在 Hacker News 與 X 擴散後，Microsoft 隔天就解除限制，因此新版才能順利釋出。他認為這比較像官僚流程失控，而不是針對 WireGuard 的蓄意打壓。
討論焦點隨後轉向平台治理，而不只是新版功能本身。一派人同意維護者的說法，認為這更像大型企業常見的官僚失誤，不宜直接上綱到陰謀；但更多高分留言認為，關鍵不在動機，而在結果：只要一套自動化與人工審核脫節的簽章制度，能讓開發者突然失去發佈更新的能力，卻又沒有可直接聯絡的人工處理窗口，最後只能靠社群媒體聲量或登上 Hacker News 首頁才獲得處理，那就已經足以傷害信任。留言者也擔心，當程式碼簽章幾乎成為 Windows 平台的必要門檻後，開放原始碼軟體 ( FOSS, Free and Open Source Software ) 的更新能力等於被單點控制。
也有人把這次事件與 VeraCrypt、LibreOffice、WinFsp 等專案相提並論，質疑這是否已成為可辨識的模式；其中一名 WinFsp 開發者表示自己也受到影響，另有工程師說公司帳號已被鎖超過一個月，Microsoft 支援人員只暗示可能是系統性錯誤。Jason 在留言中則補充，這次發佈除了簽章問題，還碰上最新驅動 SDK ( Software Development Kit，軟體開發工具組 ) 不再提供 x86 ( 32 位元 ) 驅動編譯支援等技術變動。整體而言，社群一方面肯定 WireGuard 的 Windows 版終於恢復更新，另一方面也把這件事視為對大型平台權力、人工申訴機制與軟體多樣性風險的一次警訊。
👥 54 則討論、評論 💬
https://news.ycombinator.com/item?id=47719942
這聽起來很 ubuntu 問題，聽起來就 desktop mode 會把一些裝置當雜訊排除掉了，如果你在不能動之後進去把它 desktop mode 退出回到 tty 如果能恢復 virtual console 操作的話，那就是我說的問題，如果還是不能動的話，那應該是進去之後裝置就被排除且退出掉了我猜
貢獻 Linux 核心時的 AI 輔助規範 （★ 89 分）
Linux 核心最新納入一份關於 AI 程式撰寫助手的文件，重點不是全面禁止，而是把 AI 納入既有的核心開發流程管理。文件明定，任何使用 AI 協助的開發者與工具，都必須遵守 Linux 核心一貫的開發流程、程式風格與修補程式提交流程；換句話說，AI 不會降低審查標準，也不會改變可併入核心的基本門檻。
在授權與法律層面，文件要求所有貢獻都必須與 GPL-2.0-only 相容，也就是 GNU General Public License 第 2 版，且不含後續版本選項，並使用 SPDX ( Software Package Data Exchange，常用的授權識別格式 ) 標註。更關鍵的是，AI 代理不得自行加入 Signed-off-by 簽署註記，因為只有人類才能在法律上確認 DCO ( Developer Certificate of Origin，開發者原始聲明 )；實際送件的人必須逐一審閱 AI 產生的程式碼、確認授權無誤、補上自己的簽署註記，並對整份貢獻負完全責任。為了讓 AI 在開發流程中的角色可追溯，文件也建議新增 Assisted-by 欄位，寫明所用代理名稱、模型版本，以及 coccinelle、sparse、smatch、clang-tidy 等專門分析工具，但 git、gcc、make 或編輯器這類一般工具不必列出。
討論區多數人認為，這套規則的用意是把現實制度化：到了 2026 年，很難期待開發者完全不用 AI，因此與其一刀切，不如要求人類送件者承擔責任並清楚揭露 AI 參與情形。有些人甚至認為，BSD 等其他開放原始碼專案也可能跟進。也有人補充，核心維護者在意的不只是出了問題之後能不能究責，更重要的是送件者是否真的理解自己交出的程式碼，未來也願意持續維護；如果作者本來就能自己寫、只是拿 AI 當輔助，這份規則影響不大，但若是靠大型語言模型 ( LLM, Large Language Model ) 代寫自己根本不懂的內容，風險就高得多。幾位留言者也區分了讓 LLM 幫忙找漏洞，和讓它直接代寫修補程式：前者比較像提供線索，後者才會把維護負擔轉嫁給核心團隊。
反對聲音則集中在著作權與法律責任。質疑者指出，LLM 的訓練語料混有多種授權，甚至可能包含未經同意取得的封閉原始碼，因此人類送件者很難真正保證輸出內容完全符合 GPL 規範；若日後出現侵權爭議，責任未必只落在個別貢獻者身上，允許這類流程的基金會或維護體系也可能被追究。也有人反駁，侵權風險並非 AI 獨有，人類開發者本來就可能把不相容的程式碼帶進核心，現階段最務實的做法仍是由實際審閱並散布變更的人承擔後果。另一些人不滿 Assisted-by 這種寫法，認為它過度擬人化模型；但也有人回應，這個欄位同樣會記錄 coccinelle 或 clang-tidy 之類的工具，本質上是來源揭露與稽核線索，而不是承認 AI 具有人格。整體看來，較多意見不是把 AI 視為可靠作者，而是把它當成必須被揭露、被審閱、也可能在日後被全面清查的風險工具。
👥 74 則討論、評論 💬
https://news.ycombinator.com/item?id=47721953
Linux 核心最新納入一份關於 AI 程式撰寫助手的文件，重點不是全面禁止，而是把 AI 納入既有的核心開發流程管理。文件明定，任何使用 AI 協助的開發者與工具，都必須遵守 Linux 核心一貫的開發流程、程式風格與修補程式提交流程；換句話說，AI 不會降低審查標準，也不會改變可併入核心的基本門檻。
在授權與法律層面，文件要求所有貢獻都必須與 GPL-2.0-only 相容，也就是 GNU General Public License 第 2 版，且不含後續版本選項，並使用 SPDX ( Software Package Data Exchange，常用的授權識別格式 ) 標註。更關鍵的是，AI 代理不得自行加入 Signed-off-by 簽署註記，因為只有人類才能在法律上確認 DCO ( Developer Certificate of Origin，開發者原始聲明 )；實際送件的人必須逐一審閱 AI 產生的程式碼、確認授權無誤、補上自己的簽署註記，並對整份貢獻負完全責任。為了讓 AI 在開發流程中的角色可追溯，文件也建議新增 Assisted-by 欄位，寫明所用代理名稱、模型版本，以及 coccinelle、sparse、smatch、clang-tidy 等專門分析工具，但 git、gcc、make 或編輯器這類一般工具不必列出。
討論區多數人認為，這套規則的用意是把現實制度化：到了 2026 年，很難期待開發者完全不用 AI，因此與其一刀切，不如要求人類送件者承擔責任並清楚揭露 AI 參與情形。有些人甚至認為，BSD 等其他開放原始碼專案也可能跟進。也有人補充，核心維護者在意的不只是出了問題之後能不能究責，更重要的是送件者是否真的理解自己交出的程式碼，未來也願意持續維護；如果作者本來就能自己寫、只是拿 AI 當輔助，這份規則影響不大，但若是靠大型語言模型 ( LLM, Large Language Model ) 代寫自己根本不懂的內容，風險就高得多。幾位留言者也區分了讓 LLM 幫忙找漏洞，和讓它直接代寫修補程式：前者比較像提供線索，後者才會把維護負擔轉嫁給核心團隊。
反對聲音則集中在著作權與法律責任。質疑者指出，LLM 的訓練語料混有多種授權，甚至可能包含未經同意取得的封閉原始碼，因此人類送件者很難真正保證輸出內容完全符合 GPL 規範；若日後出現侵權爭議，責任未必只落在個別貢獻者身上，允許這類流程的基金會或維護體系也可能被追究。也有人反駁，侵權風險並非 AI 獨有，人類開發者本來就可能把不相容的程式碼帶進核心，現階段最務實的做法仍是由實際審閱並散布變更的人承擔後果。另一些人不滿 Assisted-by 這種寫法，認為它過度擬人化模型；但也有人回應，這個欄位同樣會記錄 coccinelle 或 clang-tidy 之類的工具，本質上是來源揭露與稽核線索，而不是承認 AI 具有人格。整體看來，較多意見不是把 AI 視為可靠作者，而是把它當成必須被揭露、被審閱、也可能在日後被全面清查的風險工具。
👥 74 則討論、評論 💬
https://news.ycombinator.com/item?id=47721953