本期 Tempest Rust Daily 整理 2026 年 5 月 28 日的 Rust 技術情報，從 24 篇來源中精選 12 則訊號，可歸納為四條主線：第一，系統級改寫持續推進——Flatpak 2 確定以 Rust 重寫並強制 Wayland 與 systemd，Greg Kroah-Hartman 進一步把 Rust 定位成 Linux kernel 面對 AI 規模化漏洞挖掘時的關鍵防線；第二，安全議題同時從正反兩面出現，一邊是 servo smallbitvec 出現 heap-based overflow CVE，提醒「Rust ≠ 全自動安全」，另一邊則是 Zscaler 等廠商把 Rust 推進到雲端安全核心；第三，新工具與專案呈現多元樣貌：7MB 記憶體的終端 IDE、瀏覽器內離線路徑計算、瀏覽器檔案分享、Pitivi 時間軸 Rust 改寫等；第四，語言觀察與工程文章則回到實務心得層面，包含 Edition vs Version 設計、monorepo 取捨、Rust 與 vibe-coding 的契合度，乃至於「從 Rust 走回 Ruby」的反向觀察。以下逐則說明。
Linux 生態與系統級 Rust 改寫
1. Flatpak 2 全面以 Rust 改寫，要求 Wayland 與 systemd Linux Foundation 旗下的 Flatpak 套件系統將在 2.0 版進行 Rust 重寫，同步拋棄 X11 支援，並把 systemd 與 Wayland 列為硬性需求。對台灣維護 Linux 桌面應用的工程師，這條的衝擊有兩層：一是依賴 X11 的舊有 Flatpak 應用必須儘早規劃遷移路徑；二是 Flatpak 作為跨發行版分發核心元件選擇 Rust，等於替整條 Linux 桌面工具鏈把「Rust = 預設選項」這件事再往前推一格。原文連結：[https://www.youtube.com/watch?v=vCwxmSRsr5M]
2. Greg Kroah-Hartman：Rust 將拯救 Linux 免於 AI 帶來的漏洞洪流 Linux stable kernel 維護者 Greg Kroah-Hartman 在 Rust Week 2026 主題演講指出，當 AI 工具開始大規模自動挖掘 kernel 漏洞（如報導中提到的 Dirty Frag、Copy Fail、Fragnesia 等），C 語言在記憶體、鎖定、錯誤處理與不可信資料處理上的常見錯誤都會被快速放大；改用 Rust 能在編譯期就阻擋掉多數此類錯誤，而不必等到人工 code review 才發現。對台灣 kernel 與系統程式工程師，這條的意義是：Rust for Linux 不再只是社群實驗，而是被 stable 維護者明確背書為「面對 AI 自動化攻擊的防線」。原文連結：[https://ift.tt/gn2tiZw]、[https://ift.tt/4ygORWC]
安全議題：CVE 與企業導入
3. CVE-2026-44983：servo smallbitvec 出現 heap-based overflow（GHSA-97wc-2hqc-cjgr） Servo 專案維護的 smallbitvec crate 2.6.0 以下版本被識別出一個「critical」等級漏洞，問題位於未明確邊界檢查的位元操作路徑，可造成 heap-based buffer overflow。對台灣的 Rust 工程師，這條的提醒非常實際：smallbitvec 屬於 Servo 邊界生態中被多個 crate 依賴的小型工具庫，請用 cargo tree 掃描專案是否間接引入並升級至已修補版本。同時也是一個鮮明的反例——Rust 的安全性建立在「不寫 unsafe 或正確使用 unsafe」之上，crate 內部仍可能有邏輯漏洞。原文連結：[https://ift.tt/YD85hw0]
4. Zscaler 用 Rust 推動下一代雲端安全平台 Zscaler 工程主管 Srinivas 在訪談中說明，Zscaler Private Access（ZPA）這條主力產品線正在把核心元件遷移至 Rust，目標是同時取得記憶體安全、長期可維護性，以及高並發環境下的穩定延遲。對台灣資安與雲端基礎建設團隊，這條的觀察價值是：當 ZTNA／SASE 級別的廠商把 Rust 推到產線核心，意味著 Rust 在「需要強隔離、長時間運行、且效能與安全同時關鍵」的工作負載上，已被視為合格的主力語言。原文連結：[https://ift.tt/tyFvkGO]
用 Rust 打造的新工具與專案
5. Evcode 1.0.0：跑在 7MB 記憶體上的 Rust 終端 IDE 作者起因於厭倦透過 SSH 開啟 VS Code 等待 Electron 啟動，寫了一個用 Rust 實作的終端 IDE Evcode，並釋出 1.0.0；標榜在 7MB RAM 內就能完整運作。對台灣經常以低資源 VPS、嵌入式機器或遠端開發為主的工程師，這條值得關注：它示範了 Rust 在 TUI 編輯器領域的競爭力，並提供一個與 helix、zed-tui 等專案路線不同的設計樣本——把「冷啟動與佔用」放到第一順位。原文連結：[https://ift.tt/2zOl3y7]
6. Current：以 Rust + WASM 打造的瀏覽器檔案分享工具 作者公開「current」這個瀏覽器端檔案分享專案的設計筆記，明確指出網站邏輯是 Rust + WASM 撰寫、未來會推出 macOS／iOS 原生應用；同時揭露 LLM 並未參與這篇 blog 的撰寫，但有參與軟體本身的開發。對台灣關注 WASM 應用場景的工程師，這條提供了一個「端對端瀏覽器內計算」的具體範例：把加密、分塊與傳輸協定都放在 WASM 中處理，能在不依賴後端的前提下達到可審計的隱私模型。原文連結：[https://ift.tt/tbU9jx1]
7. MPEE：用 Rust + WASM 在瀏覽器內完成舊金山離線路徑規劃 MPEE 由兩個 Rust crate 組成——dijeng 負責收縮階層（contraction hierarchy）路由、brooom 負責 VRP（vehicle routing problem）求解；專案宣稱可在不展開完整距離矩陣的情況下，於筆電上解決包含 50,000 客戶的 VRP，並提供舊金山地區的線上 demo 以 MIT 授權釋出。對台灣做物流、外送、車隊調度的後端工程師，這條的價值在於：它示範 Rust 編譯到 WASM 後仍能勝任演算法密集的離線運算，是評估「客戶端直接跑路徑規劃」可行性的好參考。原文連結：[https://punnerud.github.io/mpee/]
8. Pitivi 時間軸改寫：以 Rust 同步 GES 影格率與 UI tick GSoC 學生 Michael Calabrese 分享將 Pitivi 時間軸改寫為 Rust 的過程中，遇到「需精確對應到 GStreamer Editing Services（GES）絕對奈秒時戳的 UI tick」這個難題；初版直接寫死 NTSC 24000/1001 分數運算的方式碰到精度問題，後續改以 GES 框架原生 API 取得真實影格率。對台灣做影音剪輯、播放器或同步控制的工程師，這條的具體收穫是：不要在客戶端硬寫常見格率分數，應該透過 GES API 取得精確的框架邊界，避免長時間累積誤差。原文連結：[https://mccalabrese.github.io/gnome-blog/posts/ges-sync/]
語言設計與工程實務評論
9. Rust Editions vs Versions：讓 Rust 不必為了演進而自我崩壞的設計 Medium 上的 Rustaceans 專欄整理 Rust「Edition」與「Version」的分野：Version 是編譯器與標準庫的滾動更新，Edition 則用三年一次的節奏引入會影響語法／預設行為的破壞性變更，並透過 cargo 機制讓不同 Edition 的 crate 能在同一個專案內共存。對台灣維護長期 Rust 程式碼庫的團隊，這條值得回頭重讀：理解 Edition 機制，能讓「升級 Rust 版本」與「升級語言行為」這兩件事分開規劃，避免一次性 big bang migration 的痛苦。原文連結：[https://ift.tt/yaIBwhs]
10. Keep calm and use (Rust) monorepos 作者觀察 Rust 生態中相當比例的開發者把過多時間花在套件切分與依賴版本協調上，提出「使用 monorepo」作為更務實的解法：Cargo workspace 配合內部 crate 版本同步，能讓相依關係穩定可預期，重構成本顯著降低。對台灣的 Rust 後端與 SDK 團隊，這條的觀點值得對照當前實踐：若團隊正在維護 10 個以上的內部 crate，monorepo + workspace 通常比多 repo 更能降低長期維護成本，惟需配套設計好 CI 的選擇性建置策略。原文連結：[https://ift.tt/uFsDNKp]
11. Sentry：為什麼 Rust 是 Vibe-Coding 的理想語言 Sentry 的 Daniel Szoke 在演講中指出，TypeScript 對 LLM 寫程式相對「友善」，是因為它不強制太多約束——但這些少掉的約束也讓模型寫出能編譯、能跑、只在偶爾出問題的資料競爭與型別錯誤。Rust 則把這些錯誤推到編譯期，模型若寫錯，編譯器會明確指出哪個型別不安全與為何不安全。對台灣正在大量使用 AI 輔助寫程式的團隊，這條提供了一個有意思的反直覺結論：選 Rust 不只為了人類安全感，也是為了讓 LLM 的輸出能被工具鏈第一時間擋下。原文連結：[https://www.youtube.com/watch?v=ugUeZ8-b-u0]
12. From Rust to Ruby：一位 Rust 開發者寫下「為什麼我把 30k 行專案搬回 Ruby」 作者描述自己有一個約 30,000 行 Rust 程式碼的個人專案，擱置一段時間後在本地推論／實驗的脈絡下，重新思考是否該回到 Ruby。文章並非否定 Rust，而是從「個人專案的迭代速度 vs 維護成本」這個切角，整理出 Ruby 仍能勝過 Rust 的場景。對台灣的 Rust 工程師，這條值得當作對照閱讀：選語言不該只看效能與安全的優勢，迭代節奏、生態完整度、個人單兵作戰的舒適度同樣重要，尤其在原型階段。原文連結：[https://xlii.space/eng/from-rust-to-ruby/]
結語
綜觀 2026 年 5 月 28 日的訊號，本日 Rust 生態呈現三個值得記下的轉折：第一，「Rust 成為 Linux 系統層的預設選項」已不再是社群口號——Flatpak 2 的全面重寫與 Greg Kroah-Hartman 對 kernel Rust 的明確背書同時出現，方向高度一致；第二，「Rust 不是免費的安全」，servo smallbitvec 的 CVE 提醒所有 Rust 工程師，crate 內部的邏輯錯誤與 unsafe 使用仍會帶來 heap overflow，依賴掃描與安全公告訂閱仍是必要工程紀律；第三，「Rust 在工具與 WASM 領域持續開新場域」，從 7MB RAM 的終端 IDE、瀏覽器內 VRP 求解器、瀏覽器檔案分享，到 Pitivi 時間軸改寫，呈現 Rust 在「資源受限」與「需高度可移植」兩條場景上的滲透速度。對台灣的工程團隊，本週可推進三件事：一是排程一次 cargo tree + cargo audit 巡檢，確認專案是否間接引入 smallbitvec 受影響版本；二是若團隊維護多個內部 crate，評估是否將其整合進 Cargo workspace monorepo，並把 Edition 升級節奏寫入長期維運規劃；三是把「Rust + WASM」放進前端／瀏覽器運算的候選技術，特別是涉及加密、路徑規劃、影像處理等運算密集場景。