Show HN：一個僅 301 位元組且具備基本功能的 x86-64 ELF 執行檔

背景

這篇討論源於開發者 meribold 在 GitHub 上發布的開源專案「btry」，這是一個專為 x86-64 Linux 筆記型電腦設計的電池資訊查詢程式。該程式最引人注目之處在於其極致的體積優化，整個 ELF 執行檔僅佔用 301 位元組（機器碼部分為 298 位元組），能讀取系統中的電池電量與容量資訊，並根據硬體環境自動切換顯示瓦時（Watt hours）或安培小時（Ampere hours）。

社群觀點

這項專案在 Hacker News 上引發了關於「極限編程」與「程式碼高爾夫」（Code Golf）精神的熱烈討論。許多開發者對這種追求極致精簡的技術表示讚賞，認為這體現了 80 與 90 年代程式設計的純粹精神，當時每一位元組的節省都至關重要。有評論者指出，這種手寫組合語言的實踐，正好對比了現代軟體開發中普遍存在的效能冗餘與編譯器產生的臃腫代碼。更有使用者表示，這種輕量級的單行安裝指令（Base64 格式）非常適合整合進 Waybar 或 i3 等極簡桌面環境的配置中。

然而，這種極致的體積優化也伴隨著功能上的妥協。討論中提到，該程式為了節省空間，在找不到特定電池檔案時會陷入無限迴圈，而非提供友善的錯誤提示。部分開發者認為，雖然這在「代碼高爾夫」的邏輯下是合理的，但若能多花約 100 位元組來增加錯誤處理機制，會讓程式更具實用性。此外，關於這是否能被定義為標準的「ELF 執行檔」也產生了技術爭議。有觀點認為，這類程式透過濫用 ELF 標頭欄位來存放指令或數據，雖然能欺騙 Linux 核心成功載入並執行，但在嚴格定義下更像是一種利用核心特性的「漏洞利用」（Exploit），而非規範的執行檔格式。

在技術細節的攻防上，有經驗的開發者試圖尋找進一步縮減空間的可能性，質疑某些暫存器操作是否仍有優化空間。作者 meribold 則親自回應，解釋了某些看似多餘的指令其實是為了避開 ELF 標頭中必須為零的特定欄位。此外，也有使用者在特定硬體（如 Dell 5440）上測試時遇到了段錯誤（Segmentation fault）或記憶體分配錯誤，這反映出這類高度依賴特定核心行為與硬體路徑的微型程式，在相容性上確實存在挑戰。

延伸閱讀

• btry GitHub 原始碼與提交紀錄：文中討論了作者如何透過特定的提交（Commit 8ef5a4c）利用 ELF 標頭空間來優化指令存放。
• DOS .COM 格式對比：留言中提到早期 DOS 環境下無標頭、純機器碼的執行檔格式，作為微型程式開發的歷史對照。