Always Be Blaming：以 git blame 的時序維度建立程式碼理解的三維工作流
matklad.github.io · 2026-05-18
rust-analyzer 的前主要維護者 matklad（Aleksey Kladov）發表文章，提出一個透過 git blame 將程式碼理解從「靜態快照閱讀」提升到「時序演進追蹤」的工作流框架，並描述了他為此開發的本地快捷鍵系統。文章在 Lobsters 上引發活躍討論，觸及版本控制工具設計與程式碼理解深度的核心張力。
2D / 3D / 4D 理解框架
作者以維度比喻建立理解層次：
- 2D：閱讀當前程式碼快照——理解「現在的程式碼是什麼」
- 3D：透過 git blame 追蹤程式碼如何演進——理解「這段程式碼為什麼變成現在這樣」
- 4D：透過 theory of mind 理解原作者的推理過程——理解「作者當時在想什麼問題」
4D 理解是作者最重視的層次。要達到 4D，需要在 blame 指向的提交點「穿越回去」，以當時的程式碼狀態和上下文理解整個 diff，而非只看孤立的變更。
工作流設計
網頁工作流：GitHub blame 介面的 y 快捷鍵將符號引用轉換為提交固定 URL，讓 blame 跳轉不會因分支更新而失效。
本地工作流：作者開發了一組鍵盤快捷鍵在單一工作樹中就地執行 blame：
, b l：找出引入當前游標行的提交並 checkout 到那個時間點, b p：切換到父提交（往回走一步）, b u：還原最後一次 blame 操作, b w：複製對應的 GitHub 連結以在瀏覽器中查看
這個設計的取捨是「接受破壞性地變更單一工作樹的 HEAD」，換取能在本地利用所有現有工具（LSP 跳轉、建置系統、ripgrep 等）的能力，避免在多個瀏覽器分頁或 worktree 之間切換上下文。
未解決的問題
作者坦承一個根本限制：程式碼審查留言不屬於 git repository，被鎖在 GitHub、GitLab 等平台的專有系統中。要達到完整的 4D 理解，有時需要切換到瀏覽器查看對應提交的 PR 討論，破壞了本地工作流的完整性。這個問題目前沒有乾淨的解決方案。
原始來源：matklad.github.io
Haiku OS ARM64 移植里程碑：在 Apple M1 Mac 上成功啟動至桌面環境
Haiku OS Forums · 2026-05-19
開發者 smrobtzz 在 Haiku OS 官方論壇記錄了 ARM64 移植的進度，確認 Haiku 已能在 QEMU 模擬下於 Apple M 系列 MacBook 上啟動至桌面環境（版本號 hrev59669），並附有截圖為證。這是 BeOS 精神繼承者 Haiku 向現代 ARM 硬體擴展的重要里程碑，在 Hacker News 上引發社群熱議。
技術成果
目前可運作的功能：
- 桌面環境完整啟動，多位貢獻者確認複現
- 多核心 SMP 支援，最多 8 核心正常運作
- 標準 QEMU 裝置：virtio SCSI、virtio net、xHCI USB
- 顯示：ramfb（RAM-based framebuffer）模式運作正常
已知問題：至少一個核心崩潰（kernel crash）與若干 double free 問題尚待除錯，部分軟體相容性問題仍需處理。
技術障礙與解法
移植過程的主要技術挑戰集中在韌體相容性：
- UEFI 韌體：EDK II（Tianocore）韌體相容；標準 UTM 附帶的韌體不相容
- 儲存裝置：需使用 USB 配置；virtio-blk 替代方案失敗
- 顯示：使用 ramfb 模式（透過 QEMU 的 RAM-based framebuffer 機制提供）
ARM64 支援已包含在 Haiku 上游程式碼庫中，每夜 ARM64 映像已可下載測試。這意味著這個移植不是分支（fork），而是即將合流主線的官方支援目標。Haiku 在 x86_64 已穩定運作多年；ARM64/Apple Silicon 移植讓它得以在目前最廣泛的個人電腦架構上運行。
原始來源：Haiku OS Discourse