Ken Thompson 如何重塑系統程式設計？Unix、B、Plan 9、trusting trust 與 Go

讀者問題與人物定位

Ken Thompson 的名字經常只和 Unix 綁在一起，但他的系統觀其實跨過語言、作業系統、工具鏈、分散式環境與供應鏈信任。讀者若只背誦「Unix 共同發明者」，就看不到他反覆處理的核心問題：如何用小而可組合的機制建立可理解的系統，並讓程式設計師能檢查工具本身是否值得信任。

Unix 的早期建造於 Bell Labs，Thompson 與 Dennis Ritchie 及其他同事共同工作。這個合作背景不能被個人傳記抹掉；Thompson 的特色在於提出和實作許多關鍵機制，同時把它們放進可以每日使用的環境。從 PDP-7 上的早期系統，到後來的 Plan 9 和 Go，他都在硬體限制、開發效率與抽象邊界之間做具體取捨。

本文的主線不是把所有作品列成履歷，而是追蹤一種設計方法。先用最小核心和文字介面把工作拆開，再以管線、檔案描述元和程序組合複雜行為；當分散式或多核心需求出現時，重新檢查名稱空間、並行模型和工具鏈。這條路線能解釋為何 Unix、B、Plan 9、trusting trust 和 Go 彼此相關，卻又不能互相替代。

還要先區分歷史貢獻和後來的神話。早期 Unix 原始碼公開片段、Computer History Museum 的人物資料與 Go 官方 FAQ 各自證明不同主張；本文不把一份來源延伸成全部結論，也不把 Thompson 的合作成果寫成單人奇蹟。技術史的準確度，正取決於知道哪一個人、哪一個版本和哪一個時間點正在被描述。

技術如何運作：Unix、B 與可組合工具

早期 Unix 在 1969 年於 Bell Labs 的 PDP-7 上展開。這台機器的記憶體和輸入輸出都很有限，因此系統不能靠龐大框架掩蓋設計問題。核心提供程序、檔案和基本輸入輸出，外圍工具各自完成編輯、搜尋、組譯或列印；程式以文字串流連接，複雜任務便由簡單部件組合而成。

shell 是這種組合哲學的可見介面。它解析命令列，建立管線，將一個程序的標準輸出接到下一個程序的標準輸入，並處理檔案重導向。由於工具只需要遵守穩定的文字介面，使用者可以用未預先設計的方式組合它們。這不是把所有功能塞進一個命令，而是把控制流程交給能讀懂狀態的使用者和腳本。

早期檔案工具同樣體現小部件思維。搜尋工具只處理匹配規則，排序工具只處理順序，文字轉換工具只處理字元或欄位；它們透過串流交換資料，避免互相知道內部資料結構。這種低耦合讓每個部件容易以小輸入測試，也讓錯誤能沿著管線被定位。今日的命令列、容器管線和資料處理作業仍在使用這個模式。

B 語言是把系統實作問題提升到可攜式表示的嘗試。與直接寫 PDP-7 指令相比，B 讓程式以運算式、控制結構和記憶體操作描述意圖，再交由編譯器產生目標碼。它受限於早期機器的字長與型別能力，卻說明了語言、編譯器和作業系統可以互相推動：更好的語言讓系統易寫，系統需求又迫使語言補足抽象。

從 B 到 C 的歷史也提醒我們不要把名稱當成單一步驟。Ritchie 等同事後來擴充型別和資料模型，形成更適合 Unix 的 C；Thompson 的 B 工作則是這條演進鏈的重要節點。語言的成功取決於編譯器、函式庫、除錯工具和實際程式的共同適配，而不只取決於語法是否漂亮。

Unix 的檔案描述元把裝置、檔案和管線端點統一成可讀寫的抽象。程序不必知道輸入來自終端機、磁碟還是另一個工具，只需透過相同的介面取得位元組。這個設計減少了分支條件，也使測試能以臨時檔案或管線替代真實裝置。抽象不是把差異藏起來，而是選擇一個足以支撐組合的共同契約。

原始程式、專案脈絡與信任問題

Computer History Museum 保存的早期 Unix 程式碼能看到 shell、檔案工具和文字處理部件如何並列。這些片段不是完整現代作業系統，也不應被當成所有版本的唯一真相；它們的價值在於展示最小系統如何以可讀原始碼維持工作流程。讀者可以追蹤一個命令如何讀取輸入、呼叫系統服務、輸出結果，再與其他命令連接。

研究早期程式碼時，版本和機器條件非常重要。PDP-7 的字長、磁帶格式和組譯器約束會影響指標、字元處理和檔案布局。若把後來 C 版本的習慣直接套回早期 B 或組合語言，會錯過當時的資料表示。精確的分析應同時記錄來源版本、目標硬體、編譯方式和哪些行為是由環境提供。

Thompson 在 Unix 之外參與 Plan 9，重新思考分散式系統的名稱空間。Plan 9 以每個程序可見的檔案樹和網路資源表示服務，讓遠端裝置能以接近本地檔案的方式使用。這不是宣稱網路延遲不存在；相反地，設計把連線失敗、權限和資源邊界放進可觀察的操作。名稱空間成為組合服務的工具，也成為隔離故障的界線。

「Reflections on Trusting Trust」處理的是編譯器供應鏈的遞迴信任。若攻擊者在編譯器中植入規則，編譯器能在編譯另一個編譯器時重新植入自己，即使原始碼看起來乾淨，產出的二進位檔仍可能含有後門。這個例子不是教人懷疑所有工具，而是指出可重現建置、獨立編譯器、二進位比對和簽章驗證為何必要。

信任問題的技術重點是引導程式與編譯器的自我宿主。當工具鏈能編譯自己，它獲得便利和效能，卻也讓驗證變得循環。現代供應鏈會用多個來源重建、固定版本、雜湊鎖定和可追溯產物打破部分循環。這些控制不能保證數學上的絕對安全，但能把「相信某個檔案」轉為可重現、可比較的證據。

現代開發與今日影響

Go FAQ 記錄 Griesemer、Rob Pike 和 Thompson 在 2007 年開始設計 Go。這個團隊面對的是大型程式、漫長編譯、多核心硬體和複雜工具鏈，而不是重造 Unix 的檔案系統。Go 的設計因此保留清楚的編譯和格式化工具，並以較簡單的語言結構減少團隊協作時的歧義。

Go 的並行模型把 goroutine、channel 和排程器放在語言與執行期的共同邊界。goroutine 讓大量工作以較低成本建立，channel 提供傳遞資料和同步的明確路徑，但它們不會自動消除競爭條件、死鎖或資料競爭。工程師仍須設計所有權、取消、錯誤傳播和關閉順序，這與 Unix 管線需要清楚處理程序生命週期是同一種紀律。

Go 的工具鏈也延續小而一致的系統觀。gofmt 固定程式格式，go test 把測試命名和執行方式統一，模組與依賴命令提供可追蹤版本。這些工具不只是便利功能，而是降低團隊中「每個人有一套做法」的協調成本。當工具輸出可重現，程式碼審查可以專注在行為和邊界，而不是無休止的格式爭論。

微服務和容器環境常重新使用 Unix 的管線思想，只是資料介面從純文字擴展為結構化訊息、HTTP 或 RPC。每個服務若保持單一責任、清楚輸入輸出和可觀察錯誤，就能像命令列工具一樣組合；若服務共享隱藏狀態或把所有功能塞在一處，部署規模變大後便難以測試。Thompson 的遺產在此不是某個命令名稱，而是對邊界和組合的持續要求。

供應鏈安全則把 trusting trust 變成日常工程。團隊可以固定編譯器和基底映像版本，記錄來源雜湊，使用隔離建置和簽章，並讓獨立環境重新生成產物。每項控制都有成本和盲點，但它們讓審計者能回答「這個二進位檔由哪一份來源、哪一個工具、哪一次建置產生」，而不是只說「我們相信 CI」。

爭議、限制與常見誤讀

把 Unix 說成 Thompson 一人作品是不正確的。Ritchie、Brian Kernighan 及 Bell Labs 其他同事共同形成語言、工具、文件和文化；早期系統也吸收了更早的作業系統研究。寫作時應明確指出 Thompson 負責或參與的設計，再以來源說明哪些部分是團隊成果，這比用一個英雄名字代替全部作者更可靠。

「小工具」不等於每個程式都應該拆得越細越好。過度拆分會增加網路往返、序列化、部署和監控成本；共享資料若沒有契約，也可能在服務邊界造成脆弱耦合。Unix 的可組合性依賴穩定的文字介面和明確錯誤處理，現代系統必須把這些條件轉化為版本化 API、逾時、重試與可觀察性。

Plan 9 的檔案式名稱空間也不能被誤讀成分散式透明。遠端資源仍有延遲、斷線、快取失效和權限問題；把它呈現為一致的檔案樹，是為了讓程式以共同抽象工作，同時要求系統暴露失敗。設計抽象時，必須測試最壞情況，而不能只展示網路順利時的漂亮路徑。

Trusting trust 論文提出的是威脅模型與驗證難題，不是說原始碼審查完全無用。來源審查、靜態分析、簽章和重現建置各自捕捉不同風險；若把其中一項當成萬靈丹，反而會放大盲點。最實際的做法是根據資產重要性建立多層證據，並在工具鏈或依賴變更時重新驗證。

Go 也不是 Unix 哲學的完美終點。垃圾回收、介面設計、錯誤值、模組版本和並行抽象都有取捨，某些高效能或特殊領域需要別的語言。理解 Thompson 的工作不代表要選擇同一套工具，而是學會把問題、約束、抽象和驗證證據寫清楚，讓選擇能被團隊檢查。

Unix 的程序生命週期也值得單獨注意。shell 建立子程序後，父程序要等待、收集狀態碼，並在管線某一段失敗時決定是否繼續。這些看似低階的規則讓腳本能組成可靠批次，也揭示了抽象的代價：若只看最後一個輸出而忽略中間退出狀態，錯誤就會被靜默吞掉。現代工作流引擎和服務編排仍需面對同一種問題。

在 B 和早期 C 的轉譯中，指標與位元組布局直接連到硬體。這種能力使作業系統能管理裝置和記憶體，卻也要求開發者理解未對齊存取、整數大小和編譯器假設。今日使用更安全的型別或封裝介面，不是背叛系統程式設計，而是把原本由每位工程師手工維護的不變量交給工具檢查，再在必要處保留低階控制。

Plan 9 對名稱空間的實驗還能用於權限設計。若每個程序只看到完成任務所需的檔案樹，服務就不必取得整台主機的全域權限；資源掛載和撤銷也能成為部署步驟的一部分。這種最小可見範圍與今日容器、沙箱和 capability 設計相呼應，但仍須測試符號連結、快取和斷線後的行為，不能只靠名稱看似隔離。

Go 的設計討論同樣把編譯時間視為團隊成本。大型專案若每次變更都要重建無關模組，開發者會延後測試，錯誤便更晚暴露；清楚的套件依賴與增量編譯則縮短回饋迴圈。這延續 Thompson 對工具可用性的關注：語言特性、編譯器資料結構和命令列介面必須一起設計，才能讓抽象真正提升整體生產力。

若要先理解同一條系統軟體演進脈絡，可延伸閱讀Dennis Ritchie 對 C 與 Unix 基礎設計的整理。

資料來源與閱讀邊界

• https://computerhistory.org/profile/kenneth-thompson/
• https://computerhistory.org/blog/the-earliest-unix-code-an-anniversary-source-code-release/
• https://go.dev/doc/faq

增量：系統工具的力量來自小介面與可檢驗的信任邊界

Ken Thompson 的脈絡可以再分成兩種影響：Unix、B 與 Go 展示如何用小而可組合的工具降低系統程式設計成本；Plan 9 與「Trusting Trust」則提醒我們，名稱簡潔不代表系統自動可信。真正的安全邊界要落在編譯器、建置流程、權限、依賴、更新與可重現驗證上。

• 可組合：工具輸入／輸出清楚，能被管線與其他程式重用。
• 可重建：原始碼、編譯器、依賴與產物能被重新檢查。
• 可隔離：名稱空間、權限、容器或沙箱的行為要用測試確認。
• 可追責：更新、簽章、部署與例外能留下證據。

這個增量讓系統程式設計史與今日供應鏈安全接上：簡潔的介面可以提升生產力，但信任必須由可驗證的建置與執行邊界支撐。