2026.08.07 —— 今日 10 則
TODAY'S THREAD 今天的線索是「以為守住的那條線，其實沒人檢查」：schrödinger's TOCTOU 展示編譯器可以在你快照之後再讀一次原記憶體，讓「先複製再驗證」這個防 TOCTOU 的標準寫法失效；tl;dv 的 meetings collection 少了一道租戶檢查，181,874 筆會議記錄對任何已認證使用者敞開；LuaJIT 把 empty_fn 的 bytecode 列入黑名單之後，代價由另一個從未碰過 pcall 的熱迴圈支付。另一側是把邊界寫明白的人——Agent Plugins 1.0.0 把自己不定義的部分（安裝、散布、權限、sandbox）列進 future considerations，而 rust-lang/rust 的 LLM 政策直接畫線：可以拿來檢查與建議，不能拿來創造。
一個目錄結構，讓 skill 與 MCP server 換家不用改寫
Agent Plugins 1.0.0 把 Agent Skills 與 MCP server 收進同一個可攜單元：一個 plugin.json、一個 skills/ 目錄、一個 mcp.json，MCP server 在裡面明確標出 stdio、HTTP 或 HTTP+SSE 的 transport。這份規格的 Technical Steering Committee 已有 Amazon、Cursor、Microsoft、OpenAI、Vercel，Google 這次以 Kevin Hou 為代表加入。真正值得看的是它刻意不定義的部分——安裝機制、散布協定、權限模型、sandbox 要求全部留給 client 自己決定，並且寫進 future considerations 而不是悄悄略過。
效率翻倍拆成兩個乘數：單卡利用率與擴張保留率
Meta 說廣告推薦基礎模型 GEM 的端到端訓練效率翻倍，MFU 來到 20% 到 25%，同時在十二個月內把訓練算力放大四倍，跑在數千張最新世代 GPU 上。他們把效率寫成 local MFU 乘上 scaling ratio 兩項：前者靠自製 kernel 與低精度，Jagged Flash Attention 吃掉變長序列最多 50% 的 padding 浪費，v4 相對 v2 的 TFLOPS 高出 40% 到 140%，換算成 18.5% 的相對 local MFU 增益。後者靠 5D 平行策略對齊 NVLink、區內 RoCE、跨區 RoCE 三層網路，再把 all-gather 佔用的 SM 從 24 個降到 1 個，換得約 5% 的端到端 QPS。
可以拿來檢查，不能拿來創造
rust-lang/rust 有了 LLM 政策，8 月 5 日公布，由五個 team 近期採納，範圍只涵蓋這一個 repo 而不是整個 Rust 專案。政策的核心是一句分界：LLM 可以用來回答問題、分析、提煉、檢查、建議、審閱，但不能用來創造。落到條款上，LLM 產出的內容一律要揭露、程式碼要附測試也要事先講好，soundness-critical 的修改除了領域專家之外禁止（就算是專家也強烈不建議），reviewer 可以不附理由直接關掉不合規的 PR。文中列出的背景數字是當時 1,281 個開著的 PR——這份政策要保護的與其說是程式碼品質，不如說是 review 頻寬。
一個 unpack，讓另一個迴圈掉回直譯器
LuaJIT 把 unpack 標為 stitch 類 NYI：trace 錄到它就先中斷、執行、再重新錄一條 root trace。問題是重新錄的那條不記得自己進過 FRAME_PCALL，回程撞上「NYI: return to lower frame」，反覆失敗之後，LuaJIT 把 empty_fn 的 bytecode 列入黑名單。付出代價的卻是呼叫它的那個熱迴圈——那段迴圈自己從沒碰過 pcall 或 unpack，卻因此整段編不起來、掉回直譯器，同一份程式碼就從 0.050325 秒變成 0.725689 秒。
你寫了一次讀取，編譯器幫你讀了第二次
「先把不可信的資料複製到本地、驗證那份副本、再使用」是防 TOCTOU 的標準寫法，而這個 repo 展示 C 標準允許編譯器改回去重讀原記憶體，讓這套寫法失效。示範是 ARM gcc 14.2.0 -O2 下的一行 short t = *p，編出 ldrh 與 ldrsh 兩道 load，第二道是編譯器自己發明的。作者強調這不是單一編譯器的 bug，而是 rematerialization、寬度不符的重載、bulk 與 scalar 拷貝重疊這幾類最佳化在 GCC、Clang、MSVC、ICC 上共同浮現的性質。
十倍不是來自演算法，是來自不再複製字串
GreptimeDB 重寫了 Prometheus 讀路徑上的 recordbatches_to_timeseries，在 dictionary 編碼欄位、且 series 連續排列的情況下量到 12.4 到 16.5 倍。原本的寫法有三件事貴：所有欄位先用 to_string() 展開成字串、dictionary 欄位被拆成獨立的 owned string 把上游省下的記憶體吐回去、每一列各配一個 Vec<Label>。新版用一個 LabelValues<'a> 直接借用 Arrow array，把字串配置從每列搬到每個 series 第一次出現時，吞吐從約 2M 上到 10 至 35M rows/second；文中也註明分組是逐 batch 進行，跨 batch 的同一條 series 不會被合併。
控制平面掛了，跑著的機器還得活著
這篇把控制平面與資料平面的分界講得很實在：資料平面是機器、網路、原始算力，控制平面是把這些能力接到使用者手上的那條路，而且像恆溫器一樣持續比對現況與目標狀態、不斷把系統推回去。文章以 Zak van der Merwe 在 EC2 控制平面約十年的第一手經驗展開（Werner Vogels 只寫引言）——把 region 切成各自擁有獨立控制平面與獨立 MySQL 的 AZ 來縮小 blast radius、再往內做 cell 分片、read replica 換來的 eventual consistency 取捨，以及早年沒有安全速率更新機制時全隊分班手動 patch 整個 fleet 的往事。貫穿全文的原則是 static stability：不論控制平面出什麼事，已經在跑的 VM 必須繼續運作。
在 data lake 上查一列，不必先排一個 job
Spotify 的 Random Access Parquet 在不改動標準 Parquet 檔的前提下，外掛一份 multimap 索引把 key 直接對到檔案識別與 row number，再用精準的 ranged read 只取需要的 bytes。他們拒絕 Trino、BigQuery 這條路的理由很直接：那些引擎為分析吞吐而生，即使只查一列也得先付 job scheduling 與 query planning 的秒級成本；而 Parquet 內建的 PageIndex 與 Bloom filter 是機率性的、只能縮小掃描範圍，外部索引才是確定的。規模比例大致是索引 terabytes 產生 gigabytes、索引 petabytes 產生 terabytes，而 GCS 每次請求約 30 到 100 毫秒。
先寫沒有 htmx 的版本，再把 htmx 疊上去
作者的順序是先用伺服器渲染與傳統表單送出把整個功能寫完，再疊 htmx 上去，理由是這樣才不會把自己架進死角。文章的重點不在 hx-target 怎麼寫，而在暫存狀態該放哪裡：放在表單值裡撐得過一次來回、伺服器可以連同輸入內容一起回驗證錯誤，但重新整理就沒了；編進 query string 才活得過 reload 與書籤，而 submit 按鈕的 formaction 可以逐顆改變送出目標。作者傾向整頁 swap 而不是只換一小塊，理由是避免殘留舊資料，代價是偶爾吃掉使用者正在輸入的內容，他認為這種情況少見且通常可以接受。
181,874 場會議，少了一道租戶檢查
會議錄製平台 tl;dv 的 meetings collection 少了一道租戶隔離檢查，任何一個已認證的 tl;dv 使用者都能查到平台上其他帳號的會議記錄。同一個 Firestore 資料庫裡的 users、chats、transcripts、recordings 都會正確回 403，唯獨 meetings 沒有那道檢查——所以這是授權失效，不是認證失效。研究者統計曝光範圍為 181,874 筆會議記錄、84,312 個唯一使用者、35,003 個 email 網域，並記述從 2026 年 1 月 28 日通報起反覆追蹤，到 2026 年 7 月仍未修復。