Log for Ubuntu 台灣社群

Linux 的多路徑 TCP（MPTCP） （★ 100 分）

多路徑傳輸控制協定（Multipath TCP，簡稱 MPTCP）是標準 TCP（傳輸控制協定）的延伸，由 RFC 8684 所定義。它的核心概念是允許裝置同時透過多個介面進行資料傳輸，將多條網路路徑組合為單一 MPTCP 連線。這不僅能聚合不同連線的頻寬以提升總傳輸速率，還能根據延遲或穩定度自動選擇最佳路徑，並在任一路徑中斷時無縫轉移，保持連線不中斷。Apple 自 2013 年起便在 iPhone 中導入此技術，以確保 Wi‑Fi 和行動網路間的平滑切換。其應用場景包括無縫切換連線、依條件選擇最優路徑、以及多網路併用以提升傳輸效率。

在技術實作層面，MPTCP 的運作依賴「子流」（subflow）的概念，每個子流是一個普通的 TCP 連線，用以承載其中一條介面的資料。當建立使用 `IPPROTO_MPTCP` 參數的 socket 時，系統會建立初始的子流，並可在之後與遠端主機協商新增其他子流。若遠端主機或中間的中繼設備（middlebox）不支援 MPTCP，回應的 `SYN+ACK` 封包將不會包含 MPTCP 特定選項，連線便會自動降階為傳統單一路徑的 TCP。這項行為仰賴兩個核心元件：路徑管理器（Path Manager）與封包排程器（Packet Scheduler）。前者負責子流的建立與刪除、以及可用位址的公告；後者則決定下一個封包應該經由哪一條路徑發送，可依配置策略選擇最大化頻寬或最小延遲。Linux 系統在 v5.19 後內建兩種路徑管理方式：核心內部型與使用者空間型（由 `mptcpd` 守護程式控制），而至 v6.8 僅保留一種封包排程策略可透過 sysctl 參數調整。

截至 Linux v6.10，MPTCP 已具備完整支援，包括系統呼叫中對 `IPPROTO_MPTCP` 的 socket 支援、在對端不支援時自動回落至 TCP、可選擇內核或使用者空間的路徑管理機制、典型 TCP socket 選項整合、以及偵錯功能如 MIB 計數器與 tracepoints。該網站同時列出主要專案，例如核心開發倉庫、`mptcpd` 守護程式及 `mptcpize` 工具、支援 MPTCP 的 Packetdrill 測試套件，以及 NetworkManager 自 v1.40 起增添的原生整合，顯示這項協定在 Linux 生態系中已逐步成熟。

在 Hacker News 的討論中，許多開發者肯定了 MPTCP 在整合進 Linux 內核後的成熟度與可用性，認為它能顯著提升連線穩定性與頻寬運用。一些留言指出，過去 MPTCP 在 API 層面存在不足，但近期已獲改善。也有使用者提到如 Tailscale 等現代工具已降低對 MPTCP 的需求，但仍承認其在無縫切換及多路傳輸場景中的獨特價值。部分技術討論延伸比較舊有協定 SCTP（串流控制傳輸協定），探討為何 SCTP 當年未能普及。意見多指出其難以穿越各種中間設備、防火牆與 NAT（網路位址轉譯），加上 Windows 與家用路由器支援不足，使 SCTP 難以在公共網路上廣泛使用。相較之下，MPTCP 採用 TCP 兼容設計，能在現有基礎架構中直接運作，因此更具實際部署可行性。

另有工程師討論 MPTCP 在特定情境下的限制，例如筆電休眠後改用新 Wi‑Fi 時無法自動續用原 TCP 連線，或單一連線進行多介面負載平衡時可能因封包順序錯亂而降低效能。不過，也有專業人員回應指出這些超時行為可透過參數調整改善。整體而言，社群共識是 MPTCP 雖非解決所有網路傳輸問題的萬靈丹，但在當前網際網路結構已固化的情況下，它提供了一條務實且兼容現有環境的技術路徑，讓多介面設備能有效提升連線品質與彈性。

👥 18 則討論、評論 💬
https://news.ycombinator.com/item?id=45566441

我看好多package都釘在3.12

因為3.13 buildtool 的 change 一堆 build 不起來

終於被我找到 double free 的問題

這個 ai 一定找不到

KDE 歡慶成立 29 週年並啟動年度募款活動 （★ 106 分）

KDE 專案今年慶祝成立 29 週年，雖然這個數字並非什麼周年大關，但對於一個長期由全球貢獻者與使用者社群所支撐的獨立自由軟體計畫而言，能維持將近三十年的穩定發展確實相當不易。今年 KDE 的慶祝方式是啟動一年一度的募款行動，目標是在年底前籌募至少 5 萬歐元，用以持續支撐核心軟體的研發與維護。官方強調，KDE 提供高品質、注重隱私的自由軟體，並希望使用者的捐款能維持其財務獨立性，避免過度依賴任何單一金主。

KDE 指出，隨著其自由桌面環境與應用程式越來越受玩家、藝術家、專業人士與公部門採用，維護成本也不斷上升。募款所得將用於持續開發與最佳化 KDE 生態系，確保其軟體能在多種硬體環境下運作良好，並為未來的使用者世代奠定穩固基礎。同時，KDE 也以「讓你掌控自己的數位生活」為核心理念，認為使用自由軟體是維護個人自主權與資料隱私的重要途徑；募款行動因此不只是資金需求，更是捍衛開放生態自主發展的一種宣示。

今年的活動也呼應了「國際電子廢棄物日（International E‑Waste Day）」，KDE 透過「End of 10」行動倡議減少電子垃圾對環境的危害，批評大型科技公司藉由停止支援如 Windows 10 這類仍能運作的舊系統，迫使使用者淘汰硬體，加劇污染問題。KDE 強調他們的軟體可延長舊硬體的使用壽命，幫助那些無法頻繁更換設備或沒有高速網路的人維持數位生活。自由軟體的普及亦有助於讓更多被主流科技產業忽視的使用群體重回數位社群，並促進公部門採用開放原始碼（open‑source）解決方案，以確保政府資訊系統的主權與安全。

Hacker News 上的討論整體氣氛相當積極，許多長期使用 KDE 的開發者及愛好者紛紛分享他們的經驗。多數使用者讚揚 KDE Plasma 桌面環境的穩定性、完整功能與可高度自訂的設計，認為它比 GNOME 更靈活，且內建許多日常功能，不必倚賴不穩定的擴充套件。一些留言指出 KDE 提供的操作體驗貼近 Windows，對初次轉用 Linux 的使用者更為親切，並能同時滿足高階使用者深度調整的需求。不少人提到 KDE Connect 讓多台設備之間檔案分享變得輕鬆順暢，Dolphin 檔案管理器與 kwin 視窗管理工具也被評為優秀的開放原始碼作品。

討論中也出現對 GNOME 的設計路線與使用限制的比較，不少人認為 GNOME 對使用習慣要求過於單一，而 KDE 的「可塑性」讓使用者能依個人偏好調整按鍵、快捷方式與介面配置。此外，有人感嘆 KDE 雖可媲美商業系統，但多數大型 Linux 發行版仍未將其列為預設桌面環境；也有人提到 Wayland（新一代圖形顯示協定）尚未完全成熟，希望 KDE 不要太快放棄 X11。整體而言，多數留言都流露出對 KDE 團隊多年來堅持自由軟體理念與高品質開發的敬意，並表示樂於持續捐款支持這項長青的開放原始碼計畫。

👥 42 則討論、評論 💬
https://news.ycombinator.com/item?id=45578117

別使用 Let's Encrypt (2019) （★ 83 分）

Michael Orlitzky 在「Let's Not Encrypt」一文中，質疑 Let's Encrypt (LE) 與其他憑證授權中心 (Certificate Authority, CA) 一樣，僅透過在網頁根目錄放置驗證檔案，藉由 HTTP (超文本傳輸協定) 存取確認網站所有權；若真有中間人攻擊 (Man-in-the-Middle, MITM) 即可攔截此驗證，讓攻擊者自行簽發憑證。作者強調 LE 憑證無法阻擋最關鍵的攻擊，且從全球百餘家信任 CA 中，任何一方都可冒名頂替，所謂安全保證形同虛設。

他進一步抨擊 LE 的自動化更新機制：官方工具 certbot 必須以 root 權限下載陌生主機簽發的憑證並安裝進伺服器，恐將惡意或錯誤內容推入，甚至癱瘓服務；而手動更新雖可避此風險，短至三個月的憑證有效期卻讓網站營運者終身被迫持續投入時間。更甚者，一旦切換到 HTTPS (超文本傳輸安全協定)，搜尋引擎僅收錄 https 網址，無法回溯至 HTTP，猶如綁上倒數計時炸彈，難以解除。LE 本身每年營運經費高達 360 萬美元，由競爭者捐助，且可隨時被瀏覽器移出信任名單，網站將面臨斷線或高額支出風險。

Hacker News 討論中，部分網管者分享因憑證更新失敗，遠端管理介面如 iDRAC、iLO 在新瀏覽器上無法存取，只好維持舊版憑證或過時瀏覽器。也有評論指出，SSL / TLS 推廣主要解決公共 Wi-Fi 與 ISP 廣告攔截問題，保障機密登入與資料完整性；隨著真實攻擊案例稀少，憑證透明度 (Certificate Transparency, CT) 日誌與多視點驗證可進一步降低中間人攻擊風險。另有人建議結合網域名稱系統安全擴充 (DNSSEC) 與基於 DNS 的命名實體驗證 (DANE) 來加強網域驗證。

反對者認為，與其追求所謂完美的自簽憑證或首次使用信任 (Trust On First Use, TOFU) 模式，不如承認自動化短生命週期憑證在減少金鑰外洩風險、強制測試更新流程與改善作業可觀測性上的優勢；憑證私鑰從不離開伺服器，撤銷機制與線上憑證狀態協定 (OCSP) 訂書亦提高安全性。若再搭配監控憑證透明度 (CT) 日誌與憑證授權機構授權 (Certification Authority Authorization, CAA) 記錄，惡意簽發將被迅速偵測並移出根憑證。入門者還可選擇 ZeroSSL、Buypass 等免費自動憑證管理環境 (ACME) 服務，獲得與 LE 相當的便利。許多網管者認同，現今網站普遍採用 HTTPS 已成共識，實務上已無退路。

👥 160 則討論、評論 💬
https://news.ycombinator.com/item?id=45579968