1956 - GM-NAA I/O 批處理系統（第一個作業系統）#

案件摘要#

1956 年，通用汽車 (GM) 與 Northrop 航空的合作團隊為 IBM 704 寫出 GM-NAA I/O—— 公認史上第一個作業系統：把「載入程式、連結函式庫、執行、清理」自動化為批處理 (batch processing)。 電腦從「需要專業操作員手工伺候的機器」，變成「能自己按順序跑完一堆工作的系統」—— 作業系統偵探案的第一塊積木：讓機器自己管理自己。

前因 -- 為什麼會有這個案子#

• 手工操作的巨大浪費：1950 年代的電腦一次只跑一個程式。每個程式之間，操作員要：
• 手工載入卡片與磁帶；
• 手工連結副程式與 I/O 常式；
• 手工清除記憶體、設定暫存器。 昂貴的 CPU（每小時數百美元）大部分時間在等人——CPU 閒置是商業命案。
• 重複的苦工：每個使用者都要自己寫 I/O 常式——同樣的程式碼被寫了幾百遍。這正是「共用系統軟體」的原始動機。
• GM 的偵探直覺：GM 的 Robert Patrick 與 Northrop 的 Owen Mock 決定——把操作員的工作寫成程式。操作員自己革了自己的命。

線索與推理 -- 數學式、程式、理論#

第一條線索：批處理的數學#

設每個作業 (job) 的 CPU 時間 \(t_i\) 、人工設定時間 \(s\) 。手工模式下：

批處理模式下，設定只發生一次（或由監督程式自動完成）：

CPU 利用率：

吞吐量 (throughput) 的第一次工程最佳化。

第二條線索：監督程式 (monitor)#

GM-NAA I/O 的核心是一個常駐記憶體的監督程式： - 自動載入下一個作業（卡片→磁帶批次）。 - 提供共用 I/O 常式（函式庫的雛形）。 - 作業結束後自動清理、轉交控制權。

監督程式 = 作業系統的祖先——「常駐記憶體、管理其他程式」的架構思想沿用至今（今日的核心 kernel 正是它的後裔）。

Python：批處理 vs 手工的利用率模擬#

import numpy as np

np.random.seed(0)
n = 50                                    # 50 個作業
t = np.random.uniform(0.1, 2.0, n)        # 每個作業 CPU 時間（分鐘）
s = 5.0                                   # 人工設定時間（分鐘）

T_manual = (t + s).sum()
T_batch  = t.sum() + s
U_manual = t.sum() / T_manual
U_batch  = t.sum() / T_batch

print(f"手工模式: 總時間 {T_manual:.1f} 分, CPU 利用率 {U_manual:.1%}")
print(f"批處理  : 總時間 {T_batch:.1f} 分, CPU 利用率 {U_batch:.1%}")

手工模式: 總時間 170.2 分, CPU 利用率 48.7%
批處理  : 總時間 57.7 分, CPU 利用率 90.7%

結案 -- 後果與影響#

• 批處理成為標準：FMS（1957，MIT）、IBSYS（1959，IBM）等跟進——「監督程式 + 批次作業」成為 1950–60 年代的主流架構。
• 函式庫的制度化：共用 I/O 常式的思想，催生系統軟體的模組化——連結器、載入器成為標準工具。
• 作業系統的誕生宣言：「電腦的管理本身就是一門工程學」——通往 1961 年分時系統（見「1961-CTSS分時系統.md」）。
• 限制：批處理是互動的死亡——使用者交出卡片後要等數小時才能看結果，無法除錯互動。這個缺口正是分時系統要補的洞。
• 歷史定位：第一個 OS 不是出自大學或 IBM 總部，而是汽車公司的工程師——被 CPU 閒置成本逼出來的破案。

關鍵人物與文獻#

• R. Patrick & O. Mock：GM-NAA I/O (1956)，為 IBM 704 開發。
• 相關案件：1961-CTSS分時系統.md、1964-System360與OS360.md。