佳作之後

承蒙評審給予肯定，最直接的感謝方式就是狗尾續貂一番。

沈澱了一個多月，我時常咀嚼結語中故作輕鬆的豪語：

所以，就先抓 2025 Q4 釋出 Hoddarla 1.0 版吧！

鐵人賽畢、回歸日常之後，就像鬆開安全鎖之後走下大怒神或雲霄飛車座椅的感覺：方才的經歷在每一個瞬間都帶來極深刻的感官體驗，但又已經過去；日後是否能鼓起勇氣重新再挑戰，也沒有足夠把握。但，刺激的遊園設施經驗所能類比的部份，也就只到這裡了。

先前最後的規劃，2025 Q4？幾乎像時間的盡頭。但若時間真正到達了盡頭，又哪需要什麼作業系統、哪需要什麼典範、概念、工程原則、破壞或創新或沿襲？有太多矛盾本身隱式地存在在這個專案的宣言裡面。

要完成 side project，人們必須能從最原始的本能之中提取足夠的能量作為核心動力，而後才能夠啟動：設定目標與階段、一步步完成、回顧、改善、再前進。然而若這份能量突然空乏（也許是需挪作他途、也許是資源耗竭？），那無論進行到哪裏，都不會有達成目標的可能了。

Hoddarla 於我，是過去兩年的生命本身；然而類似向度的思考（大部分已總結在予焦啦！結論與展望（一）：Hoddarla 專案的過去、現在與未來一文之中），卻已經持續了很久，也非我所獨有。

但如果我只是繼續沉吟，這末篇將會連狗尾的等級也沒有；所以，另外引了 2 則來源，希望能夠與讀者諸君一同品味我將 Hoddarla 1.0 這個目標擱置的決定。也許酐醉到了深處的 underflow，是恰到好處的醒覺也說不定。

是時候讓作業系統重新認識它底下的硬體了

這場演講來自相當開放的系統架構論壇 USENIX 今年（2021）的技術年會（連動 OSDI 研討會）的 Key Note 講座。精彩的 Key Note 所需富含的領域深度與洞見，這場講座當然不缺；而論啟發性與娛樂性，更是這場講座為人津津樂道之處（這一兩個月，只要是 Hacker News 上稍微深入的作業系統主題，都會看到人們以這場講座為參照延伸討論）。

講者 Timothy Roscoe 是一位帶領 ETH Zurich 系統部門的業界先進。他一開場，就以雞蛋高牆式的高反差手法指出，OSDI 這個作業系統領域裡面影響力最高的一份刊物之中，作業系統本身的學術論文僅是少數；而且在這些論文之中，除了以 Linux 為實驗平臺之外的作業系統研究，已經稀缺到一年只有一兩篇的程度了。

於是下一個問題，思考過作業系統與相關哲學的人決不會陌生，那就是，**作業系統到底是什麼？**又，**為什麼是 Linux？**講者給出一個很強的斷言，我們若是只看到 Linux 在作業系統研究領域的高佔比，那就是見樹不見林；實際上，就算是 Linux 之外的那些作業系統設計與研究，也與 Linux 共享一項硬體假設： ccNUMA 架構，也就是對各個 CPU 叢集來說，記憶體存取有遠近親疏之別，但同時他們互相之間的 cache 是一致的（coherent）。於是，就此破題。

講者列舉了一些顯然一點都不 ccNUMA 的系統方塊圖，幾乎可以說，Linux 以及其他為 ccNUMA 架構而生的作業系統，實際上只是控制真實硬體的 CPU 與部分記憶體而已。真實的其他硬體元件因此需要自己處理這種被解離的情境，它們不過是作業系統透過 driver 去稍微接觸的邊疆民；有趣的是，這也催生的其他領域的一些研究機會，如安全領域的 cross-SoC 研究、或是各種計算機架構的研究（對他們來說，直接改架構比理解如何調整軟體層的東西簡單多了），因為那些領域的研究者沒有時間使用 Linux 之外的作業系統，所以勢必得讓周邊硬體元件去配合 Linux 存在的狀態。

講者也順便抱怨了一下 USENIX/OSDI 研討會，因為裡面大部分是機器學習、資料庫領域的研究，作業系統領域研究反而少不打緊，其它子領域都有專屬的高品質研討會，就只有作業系統沒有；不僅如此，如果硬是要研究作業系統的話，最好都選擇在 Linux 上進行；如果不是，也務必讓實驗 OS 盡量像 Linux（也就是運行在 ccNUMA 假設之下的意思）。

31 分鐘，也就是這場講座的中間點，講者做了最重的批判：現狀（作業系統設計之研究）為何如此遠離真實硬體？

1. 人們根本就不知道現代硬體長什麼樣子：這是無知。
2. 人們停留在舒適圈裡面，專注於那些 Linux 本來就擅長的部分：這是否認現狀。

作者之後語氣放緩，並開始提出一些建議的下一步作法，包含：

1. 寫系統以控制真實的 SoC。確實其中包含許多複雜的部分，但處理複雜、撰寫系統以降伏這些複雜度本來就是我們的天職。過程中講者也提出一篇他作為共同作者的論文：Mind the Gap: Reconnecting Architecture and OS Research，從 2011 年至今也沒什麼改變。以結果來說，以 Linux 為大宗的作業系統就這樣被排擠，孤立在僅僅佔據 CPU/Memory 的一小塊角落裡面，且有越來越多作業系統看不見的東西（延伸資料：Intel CPU 附贈的 Minix 作業系統），進而導致整體性的問題。
2. 打造自己的電腦（計算機）吧！講者儼然是個系統軟體禪師，大聲詰問：你們理解現在的電腦硬體嗎？你們根本不懂！至少從 2011 那篇論文之後，現在要自己制定規格以打造工業級電腦簡單多了。講者自己就簡單秀了一下規格與照片，然後描述一般作業系統研究者比較少關注的部分：BMC，也就是主機板上的基本控制器，它負責溫度與電量之類的、貼近原生硬體且的關鍵控制。回頭審視 ccNUMA 的假設的侷限性，講者認為安全領域與計算機架構領域的研究者關心的問題其實都非常關鍵，所以作業系統領域這邊也應該跟上才對。

結論也就理所當然了。硬體這些年來的變化非常巨大；工程界很多公司也關注到這個現象而開發了新的作業系統；其它子領域（反覆強調的兩個大宗：安全與架構）的關注項目需要作業系統研究者跟上。然而，這個社群（USENIX/OSDI）並不鼓勵類似的研究，大環境否認了有在 Linux 之外的其他大問題，並且對於真實硬體的樣貌呈現給軟體的現狀缺乏認知。不過也因此對於作業系統研究是嶄新的機會！

• 真的應該要為新的硬體們構思新的作業系統架構
• 現在的工具遠比以前好多了：新的正規方法、語言、新的硬體...

Hoddarla?

在賽期中接觸到這個講座帶來莫大的鼓舞。從結論就可以看到，講者鼓勵新的語言和新的概念，然而遺憾的是，筆者至今接觸過的 RISC-V 機器，要不是相當簡單的平臺，再不然就是模擬器，並沒有真正進行新機器的探索。

但是，講者在有頭有臉的研究單位裡面，又為居高職，他可以支配的資源量，才是支撐他作出這些乎告背後的靠山；現狀之所以如此，必有諸多原因，演化至今使然。

至於未來，我認為若要待在能夠盈利的主流當中，還是只有 Linux 可以考慮；非 Linux 已經是離經叛道，遑論是非 POSIX 甚至排除 C 語言。所以認真說這個部分的未來事項的話，我將會開始研究最近成形的 RISC-V 進階中斷架構（Advanced Interrupt Architecture），這個新機制應該在兩三年後會普及並取代現今的 PLIC 做法，或許在許多硬體本身的控制器也轉為 RISC-V 的情況下，更有望支援類似於講者期望的那種作業系統也不一定。

21 世紀了，作業系統架構呢？

相較於前篇講座佳評連連，這系列文（共四篇）的評論卻是稍微的負面，其中甚至也有評論說，作者點出一大堆他自己都沒有深入了解的問題。為此，我本身也是沒有了解任何主題到足以稱之為深入的人，所以就在旁邊看看熱鬧。也許眾人的評論自有道理，作者非常稀疏地更新，從 2020 二月之後就沒有後續了，將系列文停留在架構構想階段。

這個部落格中，作者只有部落格用的藝名 "No Bugs" Hare，行文是我行我素的美式口語幽默，完全不怕爭議處採他人痛點，與前一篇的講者在爭議處會放緩打預防針的做法完全不同。敢放話 No Bugs，對於技術當然是有一番見識的。

第一篇描述過去五十年的硬體與軟體生態系進展，為之後的論述打地基。硬體部分的改進或差異至少有以下數點：

1. 效能，無需多說
2. 不同元件的效能改進不同，CPU/Memory 之間處理資料的速度越差越大
3. context switch 變得相當昂貴
4. NUMA
5. Interrupt 的改進
6. 更深的 pipeline，分支預測等軟體看不到的 CPU 改良

軟體部分，大多與工具的功能增強有關：

1. 靜態分析工具
2. 公共簽署的實務：增加使用者對軟體的來源的信心
3. 應用程式層有更好的「不分享任何東西（Shared-Nothing）、訊息傳遞（Message-Passing）」式的 API 在不同的語言框架中供使用。作者也引述了 Golang 的 Channel 設計背後的核心精神：Do not communicate by sharing memory; instead, share memory by communicating。
4. 非同步的程式設計框架。

第二篇則是列舉作者希望能夠在現代作業系統中改良的八大項目：

1. 增加彈性：以佈署時的控制選項，取代現在主要是開發時或編譯時的控制選項。
2. 無論是低階的 MCU 或是高階 CPU，藉由一樣的作業系統介面，使得雙方可以共享應用程式與驅動程式，而非各自開發各自的。
3. 增加穩定度與可測試性，尤其是正式上線的生產環境的除錯經驗應有所提升。一例是，很多生產環境 crash 掉的問題根本很難解決，如果能夠有個監控機制，讓人們可以調度事發前一段時間的系統狀態，那顯然會更好。以我的認知，這當然現在很多工具能夠提供，但這裡是問，為何不能是作業系統提供的呢？
4. 內建容錯（Fault-tolerance）以及擴容（Scalibility）
5. （需要安全性的情境）增加安全性。
6. 解決公共財的悲劇（參見維基），作者應是意指多租戶或多使用者情境下的系統利用狀態。
7. 驅動程式開發應當被簡化
8. 增加效能，且須分開考慮 HPC（高效能運算，通常 CPU 負責絕大部分任務）與互動式工作。

我認為作者遭受到的批評多是，這些作者希望可以改進的面向，都有一些相對應的措施或工具，是作者沒有評估過的。這些批評本身有其道理，但顯然作者不僅僅是希望那些改進的做法存在，實際上他更希望的應該是在作業系統核心與應用程式之間重新設定邊界，否則無異於多出一個又一個的框架或是第三方函式庫。這些也有可能只是我自己內心想望的投射，但總之我是這麼解讀的。

第三篇比之前篇更進一步，從想要的功能到基本的想法。如果當初這個系列持續下去，那麼這篇應該就是最基本的藍圖。比之前篇描述的每個改良都只是小段落的撰寫，本篇提出五個功能且都是較長的段落，我直接做結論的話不免有點破壞性壓縮，這裡先行致歉；但讀者諸君應該可以感受到那份動能：

1. 原生支援事件驅動（Event-driven）式的程式設計模式，且支援手持裝置、桌面系統與伺服器。事件驅動模式通常是透過程式語言、框架或是函式庫來支援，為了支援這樣的方法給應用程式層，其實費了很多工夫；之所以需要費工夫，是因為底層系統本質上是中斷驅動（Interrupt-driven）式的。作者認為，如果大部分的事件處理都可以很快解決，那事件驅動模式不是很顯然優於中斷驅動模式嗎？考量到多執行緒的切換與維護在現代作業系統之中是何等的高成本（原文是 heavy-weighted），作者的出發點如此。更到細節處，他認為應該以有限狀態機（Finite state machine）作為執行的單元，事實上，很多現代的嵌入式作業系統或是即時作業系統也有類似的設計；作者在這一點上想要主張，就算是給高階處理器運行的作業系統，也應往這個方向靠攏才對。以網頁伺服器效能為例，non-blockng 的 nginx 能夠優於 apache。
2. 既然所有東西都是 FSM，那麼系統在執行時的行為就會是可決定（deterministic）的。這有助於檢驗生產環境上的 crash 事件。理論上，一臺機器上記錄下來的 log，應該也要能夠在其他運行相同系統的機器上重現出來。理想上，這也可以簡化遷移（migration）的流程。
3. 作者企圖重定義作業系統：它不應該只指涉核心，而應該指涉相同的 API、可提供相同的應用程式與驅動程式運行、但允許配備不同的核心。我認為這就是原系列作者最會被現實阻攔的一個設計原則。有個例子是網頁伺服器閱覽自己的組態檔的需求，在 Unix-like 系統你必須有個 open 系統呼叫來與檔案系統互動，也許有某個應用程式層的 API read_conf 使用到 open，可是如果這個伺服器想要運行在沒有檔案系統的微小系統上，這個 read_conf 就不堪使用了：為何不是定一個作業系統 API read_conf？
4. API 應該要分群，並且讓應用程式的設計者決定它需要用到哪些，於是就只使用那些就足夠。我的看法是，這點直接延伸第三點，完全從應用程式設計者的角度出發，並提出兼具「應用程式僅使用需要的 API」以及「高層級 API 允許底層作業系統核心的抽換」的解法。延續第三點的網頁伺服器案例，設計者就可以選擇使用 read_conf 與 sql_socket，而非限定 Unix-like kernel 的 open、read 與 socket API。
5. 這一點我不太能夠理解其中的精神旨趣，但作者倡議作業系統與程式語言的編譯器應該更緊密合作，以呼應第二篇當中援引現代程式語言的靜態分析工具的優勢。

第四篇名為第一份草稿，比前篇更接近實際的設計，這裡就先跳過吧。

Hoddarla?

我原本以為我是個反社會的恐怖主義者，但與作者 "No Bugs" Hare 相比，我根本是傳統價值的乖乖牌；以系列文相比，我單純以 Golang 這個語言，比照以往的作業系統，照顧貼近硬體的抽象層級，但這個 XXI 系列充滿了更多想像。原作者部落格下的留言大多不以為然、轉發至 Hacker News 之後眾人的評論也不太優；相較之下，Hoddarla 本身沒有獲得任何迴響，甚至不如驅車入巷時突然猛吠的狗那樣能夠引人一瞥。

真的要說這個系列文給了我什麼除了技術發想之外的點子，我覺得最接近第一時間感受的是這篇文章：你的高明點子毫無價值。

這是 Stonemaier 設計師 Jamey 的文章，是指引有志於桌遊設計的人們的一系列心法中的一篇。一言以蔽之，**你以為你的點子聰穎無比，但要是沒做出東西來，什麼都不是：那些實踐的過程與結果，遠遠比你構想出一個神妙點子困難得多！**呃，當初乍看也是一把無明火，要是沒有點子，人們能夠作出什麼東西？但事實是，儘管夢想家比例佔全人類是少數，但總數實際上也是不少，實踐者與協調者總是會有好點子可以做。以結果來說，當然就是沒有被實現的夢想與不存在或是爛主意並無二致。

甚至可以更極端的說，搞不好，實現率低的夢想家的價值更低也不一定。換個角度看比較容易理解，創業失敗的人受人景仰的程度，應該會遠大於一直在講自己要創業但什麼都沒做的人吧。這有點流於功利主義，但夢想的盡頭難道不是為這個世界帶來什麼更好的改變嗎？這不純然是結果論的，那些過程也是夢想兌現途中的一部分成果，重點是做，現在就做。這大概就是為什麼 Nike 品牌形象這個好的緣故。

本來期待這個系列最後會引導到某個比 Hoddarla 的尷尬小 console 更高明的東西，但看到一個系列停止更新在 First draft，難免惆悵。

永遠站在雞蛋的那一邊？

很遺憾，無論如何，高牆是正確的。

日前與同是晶心壯士的隊友 Quechuas 聊聊彼此在技術路上的夢想；知曉他的遠大夢想（這裡就不多泄漏他人祕密）之後，我追問：

「既然如此，你在做鐵人賽或是這些其他的事情的時候，不會覺得自己還是太循規蹈矩了嗎？」
「畢竟還是有很多要看要學習的事情，對我來說現在就是吸收養分的時候吧。」
「理解...但對我來說這是一個很煎熬的震盪。每當我覺得安排自己走在正軌上，想要好好吸收養分的時候，不由得會覺得自己太乖了；反過來，像這整個 Hoddarla project 做一做，又會一直覺得該學的東西都還學不夠。」

夢想、規劃、執行一年半、衝刺三五個月、沉澱、佳作、再沉澱、...我應該會選擇永遠讓 Hoddarla 停留在這個 0.1 的狀態，幾年內應該也不會再做作業系統專案的嘗試了。

典範之所以是典範，就是因為它經過歲月風沙淘洗，仍然與人們共存、共生、共演化。人類在這裡面並不是唯一的主體或是宰制者，至多是有腦細胞的 player。看看 C 語言，看看 Linux，看看 Linux Foundation（！），這些概念從某些前輩（們）的腦中躍出之後，不只是一本本長灰塵的書，而是以電流為血、以概念為肉的巨大神物。

要挑戰神獸？沒血沒魔沒裝沒天命，有何可戰？

作業系統專案的嘗試 == 自幹作業系統？

我的答案是否。這兩件事情應該區分開來看。先說第一件事，這比較接近 Hoddarla 或是 "No Bugs" Dare 想做的事情，這通常會被業界先進們歸類為經驗還不夠的那一群。

我傾向於認同 Timothy 先生在講座中提到的（以及引用的 2011 年論文）那個角度，你們這些夢想家，想要挑戰甚至改動的作業系統原則那麼多，那你們光從軟體層做，真的夠嗎？一樣的硬體假設之下，會不會到頭來就算給你做起來，也不會和現在差太多？

所以我覺得，反正之後 RISC-V 開源核心只會越來越多。應該把硬體的一些概念重新補回來，也許之後連同硬體層一起改，讓軟硬之間更能夠互補所需，應該會是更有趣的專案。這是從作業系統往下看去的角度。另一個角度是，Hoddarla 本身想要將 Golang 的執行期作為作業系統的一部分，但現在可以很直接地說，結果太醜陋了，沒有維護性。至少 Golang 直接套用，沒有可行性；若要維持在 Golang 裡面，至少要付出像是 TamaGo 專案那樣等級的心力才行，再不然就連程式語言也需要另外思考：語法簡潔、節省開發者認知資源、工具眾多...

另外一件事情，關於自幹作業系統，我的認知上，不管是作業系統課堂或深或淺的作業，或是技術狂人們的實作，本質上是使用手邊的工具重現實務上使用的作業系統的一小部分。這不是我想要走的路，儘管過程中一定可以學到我現在缺乏的某些技術或知識，但是結果仍然只是玩具，而我不希望我做出來的東西只是玩具。

話雖如此，光是這些駭客們能夠好好「自幹」並且做得出來的行為本身，就足以讓上述第一種人看起來像是逃避仔，關於這個看法我可以大方承認，對，我是想要逃避 C、POSIX、everything is a file、還有企鵝或是紅色惡魔。

關於玩具，當然也是有這種說法倡導它的價值，但影響力是一回事，創業營利又是另外一回事。

學習的面向或許是唯一一個創造玩具的好理由。如果直接讓學生潛入 Linux 或是任何大系統，並且要求他們在裡面找到痛點並修正，是的，聽起來需要很久的時間，而且如果學生的經驗都是 Input 而沒有 Output，效果不可能會好。如果是創造玩具的話，學習的認知上有進有出，可以預期這個方法的效果。

打造玩具學習法有一大原因是它可以節省日後接觸真實系統需要的上手時間，而花在了解玩具的複雜度上也不會花太多時間；也就是說，教學者的心智模型是直接深潛至真實系統中所需的時間遠遠大於打造玩具過程中理解系統基本元件所需要的時間加上有過玩具經驗之後上手真實系統的學習時間。

可是出了社會之後，我總覺得直接潛入真實世界也未必有什麼壞處。因為大部分人在就學時期連玩具都造不好甚至沒造過，工作之後能夠自由支配的時間更為稀缺，這時候再做玩具，對我來說毫無意義。

以 Side project 作為鐵人賽系列文在奪獎上的劣勢

最後聊聊這個劣勢。恭喜 Kuma 大大獲得 Software Development 組冠軍。整個系列文的節奏分配，確實有登樓梯的感覺。除了程式碼的實例也通常夾帶重構心法，目標讀者群大，也易受益。

反觀我過去的幾次嘗試大多非常自我中心。Side project 這種東西本來就只關乎自我成長，雖然 Hoddarla 是企圖讓 RISC-V 的一些面向透過實際操作的方式展露出來，也比我先前的幾次嘗試來得完整，但整體上對於學習來講還是略顯虛浮，沒有去蕪存菁的感覺。

當然，如果是僅僅以參加為目的，那就沒有所謂的優勢劣勢。但是除了興趣型專案，我也沒有什麼獨到的領域型專門知識可以整理並以教學為目的分享成系列文的料，所以未來如果會參賽，核心應該也都還是這種形式吧。不求扭轉劣勢，但是還是可以考慮些策略。如果有爭獎打算，下次就回避 Modern Web 和 Software Development 這兩個一級戰區吧。

給評審與主辦單位

如果可以的話，是否能夠公佈評量的一些向度，與得獎的系列文在那些向度獲得的分數或評語？如此一來，不但未獲獎的多數技術人能夠有個目標，得獎者也相當於是獲得了回饋以增進自己傳遞知識的能力。

由衷感謝！

給讀者

希望你不會因為我在這最末篇宣告 Hoddarla 1.0 永遠不會出現而感到閱讀這個系列是在浪費你的時間。

理論上，大部分的 RISC-V S-mode CSR 我全部都有說明並使用，儘管不是很有系統，但卻是在 Hoddarla 這個系統建構的脈絡之下有邏輯地進行的，所以至少這個部分可以作為一點學習的參考；事實上，過去一個多月，我自己已經拿出來參考過幾次 PLIC。

Golang 的系統面向則是非常偏門，也需要往復搭配我前年的系列才能夠比較清楚地閱讀。確實這個部分會非常難以入口吧，尤其是系統軟體圈多的是只知道 C 而不知道 Golang 的人們。

絕大部分我都採取最生硬且最形式化的方式來表達在文章上面，確實是我刻意為之的結果，因為我一直認為這是表達對於讀者的尊重的方法。若實際上的成效相反，那只能說我對這個世界的誤會大得讓所有人都會遺憾。

最後的結論以及本篇則是寬鬆之後的結果，更接近我日常行文的方式，讀來也許自溺，但我覺得這樣很有趣。我推薦讀者諸君也試著創作，我們可以在鐵人賽或是其他部落格相遇，更重要的是你自己也會在未來與先前寫作的自己重新相遇，那種經驗幾乎堪比接觸陌生人：舉例來說，我現在看自己先前的三個鐵人賽系列，我完全不認得那些筆調，精神與生命同等的隨著歲月遺失，留下來的則大部分是那些程式碼的概念與能夠讓我賴以為生的技術。

感謝你們的閱讀，如果不是閱讀，這些文字與程式碼的存在毫無意義。

請接受這過早的佳節祝福，也希望 2022 對所有人來說同樣是能夠帶來機會與成長的一年。