誠實的代價：用 LLM 寫 Emacs GPU 後端，坦白後補丁遭拒
xlii.space · 2026-06-26
2026 年 6 月，開發者 Andros Fenollosa 向 emacs-devel 郵件列表提交了一份 RFC PATCH，為 GNU Emacs 實作 GPU 加速的顯示後端。補丁引發了超過百則訊息的討論，技術評價相當正面——然而當有人追問程式碼來源，Fenollosa 坦承全程以 LLM 為協作工具，補丁就此宣告無法合併。
從週末實驗到完整顯示後端
這個計畫最初只是一個週末的即興嘗試，最終演變成一套完整的架構。Fenollosa 採用三層設計：Emacs 核心的重顯引擎 xdisp.c 完全不動，中間層 gfxterm.c 以純 C 實作平台無關的繪圖策略，最底層的 gfxdrv.h 定義約 25 個基礎繪圖操作，再由各平台驅動程式實作。macOS 採用 Metal，GNU/Linux 採用 OpenGL ES 3 搭配 EGL。
這套分層設計在開發第二個驅動程式時展現了它的價值：中間的中立層完全不需修改就能重用。功能面上，這個後端除了基本渲染之外，還支援 buffer 內的影片播放、著色器驅動的動態游標效果，以及 buffer 切換時的淡入淡出動畫。
效能數字：靜態文字輸，動態場景贏
Fenollosa 對自己設了一個嚴苛的標準：渲染結果必須與原本的 Cairo CPU 後端「逐像素相同」。這迫使他深入處理抗鋸齒、Relief 顏色計算，以及字形定位的細微偏差。效能測試則揭示了一個有趣的模式：
- 在 1616×912 解析度下打字，GPU 後端速度僅有 Cairo 的 0.71x，略慢
- 同解析度的全畫面重繪，GPU 達到 1.19x 加速
- 在 4K（3760×2210）下打字，速度提升至 7.4x
- 4K 下的圖片捲動，加速達到 11.5x
這組數字說明了一個現實：GPU 後端在靜態文字場景打不過成熟的 CPU 光柵化器，但一旦涉及動態效果或高像素密度，優勢就相當明顯。
坦承 LLM，觸碰 GNU 紅線
技術討論吸引了包含 Eli Zaretskii、Dmitry Gutov、Stefan Monnier 在內的多位核心開發者參與。然而，當有人在討論串中詢問程式碼是否由 LLM 生成，Fenollosa 直接承認：整個專案從頭到尾都以 LLM 作為協作工具。這句坦誠的回答，宣告了補丁的命運。
GNU Emacs 的政策明確不接受 LLM 生成的貢獻，而這項政策在 Richard Stallman 同月於 emacs-devel 發起的「NonGNU ELPA and LLM output」討論串中也再次得到確認。除了 AI 政策問題，開發者還指出補丁與進行中的 Canvas patch（bug #80281）存在功能重疊，後者以跨平台方式整合了現有的 Emacs Image API。
留在 fork 裡繼續活著
Fenollosa 表示自己尊重 GNU 計畫的決定，並無意爭辯。這個 GPU 後端目前以個人 fork 的形式公開在 github.com/tanrax/emacs-gpu，可透過 --with-gpu 編譯旗標啟用，並能以環境變數關閉，作者本人也持續在日常工作中使用。
這整件事的反諷之處，正是 xlii.space 文章標題所點出的：如果 Fenollosa 什麼都不說，沒有人知道這些程式碼是怎麼寫出來的。正是「誠實」本身，成了這份技術貢獻被拒的唯一理由。這讓整個事件遠不只是一場關於 AI 生成程式碼的政策討論，更像是一次對自由軟體社群價值觀的壓力測試。
我為 Emacs 打造了 GPU 後端：Metal、OpenGL、還有一段無法進入 upstream 的旅程
andros.dev · 2026-06-26
Andros Fenollosa 在 2026 年 6 月完整記錄了他為 GNU Emacs 建立 GPU 加速顯示後端的歷程。這個計畫從一個週末的實驗出發，最終完成了 macOS Metal 驅動、GNU/Linux OpenGL 驅動、緩衝區內影片播放，以及著色器動態游標效果——然後因為他在 emacs-devel 上誠實說明了開發方式，整份工作成了一個永遠不會進入 upstream 的個人 fork。
設計原則：絕不碰 xdisp.c
Fenollosa 的架構決策從一開始就清晰：Emacs 核心的重顯引擎 xdisp.c 完全不動。在這層之上，他建立了平台無關的繪圖策略層 gfxterm.c，以純 C 實作；再下一層是驅動介面 gfxdrv.h，定義了約 25 個基礎繪圖操作；最底層才是各平台的具體驅動程式。
這套分層設計的實際效益，在開發第二套驅動程式時得到了驗證：中間的中立層完全不需修改就能被新驅動重用。如果未來有人想加入 Vulkan 或 WebGPU 後端，只需撰寫最底層的驅動實作即可。
三個讓人頭痛的技術問題
開發過程中有幾個值得記錄的具體障礙。第一個是「像素完美」的標準：作者要求 GPU 渲染結果必須與 Cairo 後端逐像素一致，因此必須細心對齊抗鋸齒行為、Relief 顏色計算，以及字形的亞像素定位。
第二個問題出在 Apple 的 CADisplayLink 同步機制——畫面靜止時它會自動暫停，導致動畫凍結。解決方式是將所有連續動畫移交給 Lisp timer 驅動，以 60 Hz 或 30 Hz 的頻率維持更新。第三個問題出現在 X11：切換 buffer 時出現殘影，原因是 XDBE 的後備緩衝區沒有被明確清除。
效能測試：解析度越高，GPU 優勢越明顯
實測數據呈現出強烈的解析度依賴性。在一般筆電螢幕（1616×912）上，打字速度 GPU 後端是 Cairo 的 0.71 倍，略輸；但到了 4K（3760×2210），打字速度提升到 7.4 倍，圖片捲動更達到 11.5 倍加速。全畫面重繪在一般解析度下已有 1.19 倍的小幅提升。
這組數字的解讀方式是：Emacs 日常使用以靜態文字為主，Cairo 這樣成熟的 CPU 光柵化器在小螢幕上難以撼動；但 GPU 後端在高解析度顯示器、動態效果（游標動畫、buffer 淡入淡出）以及影片播放這類場景中，有顯著的實用價值。
LLM 協作、誠實揭露，然後補丁被拒
這個專案技術面的完整度相當高，卻面臨了一個非技術的障礙。Fenollosa 從頭到尾都以 LLM 作為開發夥伴，並在 emacs-devel 討論串被問及時直接說明了這件事。GNU Emacs 的政策不接受 LLM 生成的貢獻，補丁因此無法合併進 upstream。此外，開發者也指出它與 Canvas patch（bug #80281）有功能上的重疊。
Fenollosa 對這個結果表示接受，並以平靜的語氣描述了整件事的意義：這是一個技術上完整、卻永遠只能活在 fork 裡的作品。專案目前以 github.com/tanrax/emacs-gpu 公開，透過 --with-gpu 旗標啟用，標注為 Beta 狀態，作者本人每天使用。
原始來源：Andros Fenollosa — How I built a GPU backend for Emacs、github.com/tanrax/emacs-gpu
1996 年那次斷線 19 小時：AOL 全面當機事件的三十年後回顧
ngrok.com · 2026-06-26
1996 年 8 月 7 日，America Online 發生了一次持續 19 小時的全面斷線，超過 630 萬名用戶無法連線。三十年後，ngrok 在官方部落格發表回顧文，重新審視這段網路早期的關鍵事故——技術原因之外，這篇文章更著眼於那一天被切斷連線的人，究竟失去了什麼。
例行維護，意外釀成歷史性災難
這次斷線的起點是一次本應無害的例行維護。AOL 計畫在 8 月 7 日安裝新版網路作業系統軟體，卻因為自家網路部門與骨幹服務供應商 ANS Communications 之間的計算錯誤與溝通失誤，導致整個系統癱瘓，服務一直到 8 月 8 日晚間 8 時 45 分才恢復。
1996 年的 AOL 正處於用戶爆炸性增長的頂點。在斷線前八個月，公司就新增了超過 130 萬名用戶，基礎設施的擴張速度遠遠跟不上業務成長。Jupiter Communications 的分析師事後直言：這次長達 19 小時的停機，正是 AOL 無法管理自身快速成長的體現。
藏在 DNS 裡的連鎖效應
技術層面有一個細節值得關注。AOL 為處理龐大的電子郵件流量，建立了一套複雜的 MX 記錄架構：九個子網域（a.mx.aol.com 到 i.mx.aol.com），各對應五個 IP，共計 45 台郵件伺服器。當這些伺服器全部離線，全球各地嘗試傳信給 AOL 用戶的郵件伺服器，會依標準協定逐一嘗試每個 IP，每次逾時等待兩分鐘。
這意味著：傳送一封郵件最多需要等待整整 90 分鐘。在這段時間裡，郵件伺服器的佇列處理器持續阻塞、耗盡系統資源、當機重啟，進而衝擊其他服務——形成全球範圍的連鎖反應。AOL 恢復服務後，全球電子郵件系統又花了將近一週才消化完積壓的訊息佇列。這次事故也間接推動了 qmail 和 Postfix 等更具韌性的郵件傳輸代理程式的發展。
六百萬人的一天：失單、失戀、失聯
ngrok 這篇回顧文的核心視角，是人而非系統。透過 CBS News 當年的採訪影像，幾個截然不同的故事被重新呈現出來：
- 加州 Scotts Valley 的 Starfish Software 正準備發布新產品，行銷管道瞬間中斷。公司代表 Gregg Armstrong 回憶：「我們只是面面相覷，說——好吧，現在怎麼辦？」
- 一位在紐約電腦咖啡廳上網的物理系學生，形容那一天是他的「黑色的一天」——他在斷線中失去了一段可能的網路戀情。
- 更多普通用戶被迫重新拿起電話和傳真機，回到比網路更古老的溝通方式。
AOL 的正式回應是每位受影響用戶獲得一天的免費服務補償，執行長 Steve Case 公開道歉。以當時的定價計算，19 小時的服務大約值月費的一天份，約 41 美元。AOL 股票在 Nasdaq 下跌 25 美分，收於 34.62 美元。
集中化的代價：從 3,840 家到屈指可數
ngrok 的文章從現代基礎設施的視角，提出了一個跨越三十年的對比。1996 年，美國擁有 3,840 家網路服務供應商，光是加州就有 63 家。選擇多元使得單一節點故障的社會衝擊相對有限。三十年後的今天，多數地區的消費者能選擇的 ISP 不超過兩三家，市場集中化意味著任何一次重大服務中斷，都可能波及數以億計的用戶。
ngrok 本身是一家以安全隧道服務為核心的公司，產品設計的前提正是「任何服務都可能當機」。這篇回顧文的言下之意不言而喻：1996 年的 AOL 以為例行維護是小事，結果讓六百萬人的一天化為烏有。三十年前的教訓並沒有過時——冗餘設計、透明度，以及對失敗的誠實預估，是現代網路基礎設施的真正支柱。