2026.05.31 —— 今日 10 則
TODAY'S THREAD 今天三條 deep 從三個角度試「把基礎重做」：pye 在 Rust 把 Wadler-Leijen pretty printer 的 group decision 攤分掉、LinkedIn 把 generative recommender 的訓練吞吐沿著瓶頸一段一段拆、Python 維護者把 CVE-2026-48710 的揭露流程從 PSRT 到公告攤成時間軸。其餘七則順著兩條線：agent 在工程流程裡愈進愈深（LinkedIn Liger Kernel 直接派 agent 寫 Triton、Notion 替 Custom Agents 蓋安全圍籬、MiniCPM5-1B 把 1B 模型推到能在端側跑），以及底座的世代交替（NixOS 26.05、Flutter desktop 從 Google 交給 Canonical、Stripe 公開 Ledger 系統、Ken Shirriff 從顯微鏡拍 8087 拆 microcode）。
Faster than Light——LinkedIn 把 generative recommender 的訓練吞吐沿著瓶頸一段一段拆
LinkedIn 把推薦系統從 two-tower 改成 generative recommender 之後，訓練吞吐立刻成了新瓶頸——同樣的硬體上掛同樣的資料，卻只跑得到舊系統的 30% 速度。Engineering 團隊不是先換 GPU，而是先把訓練分成 batch shape、attention pattern、optimizer step 三段獨立量測，再逐段把假設驗到，最後合起來得到 3.4× 的速度提升。對任何正準備從 dense embedding 模型往 generative recommender 路線轉的隊伍，這是一份「先量再改」的劇本。
AI 寫 AI kernel——LinkedIn 把 agent 接進 Liger Kernel 的 Triton 開發
Liger Kernel 是 LinkedIn 開源的 Triton GPU kernel 集合，主用途是 LLM 訓練的算子加速。團隊把 Claude / GPT 寫的 agent 直接接到 kernel 開發流程裡：從 baseline 量測、kernel 變體生成、microbench、到回填 PR，全交給 agent；結果是新 kernel 從 idea 到合併的時間從原本的 3-5 天壓到一天內，但仍需要人類在 numeric stability 與 edge case 上做最後驗收。「能寫但不會 debug」的當代 agent 限制被攤得很清楚。
MiniCPM5-1B 釋出——OpenBMB 把 1B 級小模型推到「能在端側真的跑」的目標
OpenBMB 在 Hugging Face 上線 MiniCPM5-1B，定位是給邊緣裝置實際跑的 1B-class text-generation 模型，幾天內 28k+ 下載、trending score 527。對「LLM 在手機上跑」這條路線，與 Liquid AI、Phi 等小尺寸模型形成正面對比；MiniCPM 系列強調的是「pretraining data 篩過再上的單純 dense 模型」，不走 MoE 路線——對推理棧簡化的需求是利多。
pye 在 Rust 把 Wadler-Leijen pretty printer 重新拆過——document IR + 攤分的 group 決策
Wadler-Leijen pretty printer 的「group 要 flat 還是 broken」決策在最壞情況是 O(n²)，這就是 Hackage 上 prettyprinter、Rust 上幾個 port 的延遲尖刺來源。pye 換了一條路：把 document IR、measure、render 三段解耦，並把 group 選擇分攤到一個小型狀態機，邊 walk 邊決定。Rust 端的 type system 也被利用——unbroken / broken 的 type-level state 把錯誤組合直接擋在編譯期。對寫 codegen / formatter / log printer 的人，是少數真正把 prettyprinter 演算法重做的設計。
Intel 8087 microcode——Ken Shirriff 用顯微鏡拍 die，反推 fxch 怎麼換暫存器
Ken Shirriff 拆 8087——1980 年配 8086 的 x87 浮點協處理器——並把 fxch（floating-point exchange）這條指令的內部 microcode 拆給你看。fxch 不真的搬資料：8087 內部用一張 tag 表把「邏輯暫存器 ST(0)/ST(1)」對應到「實體暫存器 0..7」，所以 fxch 只是改 tag-bit 對映，零 cycle 完成。文章順帶說明為什麼當年 8087 的 transistor budget 不允許做傳統 register file swap、以及這個設計怎麼影響到後代 x87 / SSE 程式設計。
NixOS 26.05 釋出——systemd 257、Linux 6.12 LTS、Nix 2.30 帶來 flake config 改動
NixOS 26.05 是新的 stable 分支：systemd 升到 257、kernel 預設 6.12 LTS、Nix 本體升到 2.30 並把 flake config 從實驗 flag 收成 default-on。對既有 NixOS 部署者最值得注意的是兩處 breaking：services.nginx 預設 SSL preset 跟著 Mozilla 2026 表更新（移除 TLS 1.2 中的部分 cipher），以及 systemd 257 把 user-session bus 預設改成 dbus-broker，與 GNOME 47 配合更穩。release notes 同時列出 41 個值得照表升級的 module。
Canonical 接手 Flutter desktop 的維護與 roadmap——Google 把治理權交出
Google 把 Flutter desktop（Linux / macOS / Windows）的維護權交給 Canonical，後續 roadmap 與 release cadence 由 Ubuntu 那邊推。對在桌面端押 Flutter 的團隊，這是治理層的重大變化：Google 不再保證 desktop 跟 mobile 同步發版，但 Canonical 同時承諾把 Wayland 與 GTK4 整合放進首要 milestone。Flutter 行動端的維護路線不變，desktop 變成獨立的「community-led with corporate backing」分支。對選 framework 的 CTO 是該重新評估「Flutter desktop 是不是已經到 production-ready」的時點。
CVE-2026-48710——Python 維護者把揭露時間軸從 PSRT 收件到正式公告整段攤開
Marcelo Tryle 公開揭露自家 Python 套件中 CVE-2026-48710 的處理過程：從 PSRT 通報、找 reproducer、跟 distros@ 協調 embargo、CVE 申請、到正式公告，30 天內的每一步都記錄在案。對 OSS 維護者是現成的劇本——MITRE CVE 表單怎麼填、embargo 期間能說與不能說的界線、要不要寫 PoC——對使用該套件的 backend 工程師是「我什麼時候會看到 patch」的具體答案。沒有戲劇張力，只有流程清單。
Stripe Ledger——把每一分錢的移動寫成可被驗證的紀錄
Stripe 公開 Ledger 系統的結構：用 double-entry 會計式 IO 把每一筆 money movement 紀錄成 from / to 兩條，搭配 invariant validator 在 commit 之前確認 ledger 平衡。文章解釋為什麼 OLTP database 的 ACID 還不夠——payment 系統需要的是「即使 DB 寫成功，業務邏輯也要算過一次」的雙保險。對任何要把資金或庫存當「不可丟」資料來處理的系統，這套 ledger-as-source-of-truth 模式值得抄。
Notion 怎麼幫 Custom Agents 蓋一層安全圍籬——權限邊界、prompt injection、tool 隔離
Notion 推出 Custom Agents 前，先把安全模型寫清楚：每個 agent 跑在 per-tenant sandbox 內、tool call 要過 ACL gate、prompt injection 用 system message 加 tool 結果 quoting 阻斷、長 running agent 還要過 budget gate。對自己上線 agent 平台的人，這份「我已經想過了」的清單是少有的完整列舉：哪些攻擊 surface 默認被堵住、哪些需要操作者額外設定、哪些目前還是 known limitation。
today's deep reads
pye 把 Wadler-Leijen pretty printer 重新拆過——Rust 上怎麼把 O(n²) 的 group decision 攤分掉
pretty printer 的「group 該 flat 還是 broken」決策一直是 prettyprinter 家族的延遲尖刺來源。pye 把 document IR、measure、render 三段解耦，並用一個小型狀態機把選擇邊 walk 邊決定。Rust 的型別系統怎麼把 unbroken / broken 的狀態做成 type-level 不變式？跟 Hackage prettyprinter 的 micro-benchmark 對得起來嗎？為什麼這個設計能順帶把 reflow 的對齊 bug 一起解掉？
Faster than Light——LinkedIn 怎麼沿著 batch shape、attention pattern、optimizer step 三段拆訓練吞吐
把推薦系統從 two-tower 換成 generative recommender 之後，訓練吞吐只剩舊系統的 30%。LinkedIn 沒急著換 GPU，而是先把訓練分段量測，每一段都先給假設、再做實驗、最後存留有效的修改。每一段的 bottleneck 分別是什麼？哪一段的 fix 最反直覺？最後 3.4× 的提升怎麼歸因？對正準備走 generative recommender 的隊伍，這份劇本能省下幾個月的瞎調。
CVE-2026-48710 從 PSRT 收件到正式公告——一條 Python OSS 維護者真實走過的 30 天揭露時間軸
Marcelo Tryle 把自家 Python 套件 CVE-2026-48710 的處理流程一天天記錄下來：PSRT 收件、reproducer、跟 distros@ 協調 embargo、MITRE 申請、CVE 公告。每一步的時程怎麼分配？哪些訊息能在 embargo 期間透露給誰？申請 CVE 那一份表單到底要填什麼？對任何收過 security@ 信箱、卻不確定下一步怎麼走的 OSS 維護者，這是現成的 30-day 劇本。