Linux kernel 歷史：哪些決策影響至今

Linux kernel 歷史簡介

Linux kernel 的歷史始於 1991 年 9 月的 0.01 版，延續至目前已在伺服器上啟動的 7.x 系列。版本發布清單並不是最重要的部分。少數幾項決策塑造了 Linux kernel 的架構，而這些決策至今仍會影響你今天租用的伺服器。

本文的日期與版本號來自 kernel.org 及其發布的版本歷史。截至 2026 年 8 月，7.0 已於 2026 年 4 月 12 日發布，7.1 已於 2026 年 6 月 14 日發布，7.2 目前處於 release candidate 階段。

1992 年選擇 GPL 為何至今仍然重要

Version 0.01 於 17 September 1991 以 Torvalds 自行撰寫的授權條款發布。該條款要求散布原始碼，並加入了一句更重要的規定：「不得收費散布本軟體，連『處理』費用也不行。」1991 年，軟體透過軟碟發布，而複製及寄送軟碟都需要成本。這項條款使商業 Linux 發行版無法成立。

他後來修改了授權條款。改用 GNU General Public License (GPL) 的決定，於 January 1992 的 0.12 release notes 中宣布，並在 1 February 1992 生效。March 1992 的 Version 0.95 是第一個依 GPL 發布的版本。之後建立在 Linux 上的每一項業務，都以這項變更為基礎。

Kernel 僅採用 GPL version 2，從未改用 version 3。Torvalds 在 2007 年拒絕升級，主要原因是 GPLv3 的 anti-tivoisation 規則。該規則要求搭載 GPL code 的裝置，也必須允許使用該 code 的修改版本。他認為鎖定硬體屬於製造商自身的業務決定。2017 年，kernel developers 發布 Kernel Enforcement Statement，但仍採用 GPLv3 的其中一項原則：收到違規通知後修正問題的人，可以保留其授權，而不會在首次違規時永久失去授權。

在伺服器上，這會帶來兩項結果。你啟動的 kernel binary 附帶取得相應原始碼的權利，因此任何人都不能交付一個你無法檢視或重新建置的 Linux kernel。Kernel 上的著作權聲明也指出，該授權不涵蓋透過一般 system call 使用 kernel 服務的 user program。因此，專有資料庫與 monitoring agent 可以針對 Linux 發布，而不會因此違反授權。Permissive licence 會產生相反的約束。在選擇平台前，應先了解這項差異：請參閱 Linux 與 FreeBSD 作為伺服器平台。

實務上單體核心為何勝出

1992 年 1 月 29 日，Andrew Tanenbaum 在 comp.os.minix newsgroup 張貼了一則標題為「LINUX is obsolete」的訊息。他提出兩項主張。單體核心讓驅動程式與檔案系統在同一個具特權的位址空間內執行，是 1970 年代的設計；微核心則讓這些元件以一般程序執行，才是未來的方向。Linux 也與 Intel 386 緊密綁定，因此永遠無法移植到其他平台。

移植工作回應了可攜性主張。1995 年 3 月的 Version 1.2 加入 Alpha、SPARC 與 MIPS。1996 年 6 月的 Version 2.0 加入 64-bit Alpha 移植版本。

折衷方案回應了設計主張。Linux 從未成為微核心。它改為支援可載入核心模組：這些是可插入執行中核心、也可再次移除的 object files，因此驅動程式能與核心 binary 分開發布。

lsmod | head
modinfo virtio_net | head -5

lsmod 會列出目前已載入的項目。modinfo 會顯示模組來源檔案及其接受的參數。在 virtual server 上，磁碟與網路路徑中的大部分元件都是模組，因此同一個核心映像檔可以在從未接觸過的硬體上開機。

模組提供了這種彈性，同時避免微核心設計帶來的成本。將驅動程式隔離在自己的程序中，代表每次呼叫都必須支付 context switch 與 message 傳遞的成本；在 1992 年，這項成本相當高。

Linux 保留的成本才是規劃時必須考量的部分：模組以完整的核心權限執行，因此錯誤的模組會讓整台機器停止運作，而不只是單一程序失效。Out-of-tree modules 最容易造成這個問題。未納入 mainline 的 vendor driver 必須針對每個新核心重新建置；升級期間由 DKMS 執行這項工作。若建置失敗，裝置在重新開機後就會消失。

SMP 花了 15 年才完成的原因

1996 年 6 月發布的 Linux 2.0，是第一個支援對稱多處理（SMP）的 kernel，也就是讓多個 CPU 執行同一個 kernel。第一個實作使用單一鎖定，即 big kernel lock（BKL），因此同一時間只有一個處理器能進入 kernel 程式碼。第二個 CPU 因此能協助主要在 user space 中運算的工作負載；但對主要由 system call 組成的工作負載幫助很小，因為這些呼叫都會在同一把鎖後排隊。

移除這把鎖花了 15 年。剩餘的使用點改為細粒度鎖定，主要由 Arnd Bergmann 完成；BKL 最終在 2.6.39 中刪除，該版本於 2011 年 5 月 18 日發布。scheduler 也以相同的緩慢速度演進：2.6.0 引入 O(1) scheduler，2007 年從 2.6.23 開始使用 Completely Fair Scheduler（CFS），而 EEVDF 在 2023 年 10 月的 6.6 中取代 CFS。

這些工作使得現在選擇 4 vCPU 方案已十分普遍。這也說明了一項值得了解的限制。在共用的虛擬伺服器上，你的 kernel 會排程你的執行緒，而 hypervisor 會排程你的 kernel。執行 top，然後讀取 %st 欄位。Steal time 是你的 kernel 已準備使用、但主機交給另一個 guest 的 CPU 時間，因此無法透過 kernel 內部的調校取回這些時間。

2.6 系列為何改變核心的建置方式

在 2.6 之前，版本號由兩部分組成。第二個數字為偶數時，表示穩定系列（2.4）；為奇數時，表示開發系列（2.5）。2.4 於 2001 年 1 月 4 日發布，2.6 於 2003 年 12 月 17 日發布，因此使用者等了將近 3 年才迎來下一個穩定系列。發行版無法等待，所以會回移植修補程式。兩家廠商即使都發布「2.4」，其核心也可能相差數千個修補程式。

2.6 之後取消了這種分流方式。主線核心現在會開放約 2 週的合併窗口，接收新的開發內容，接著持續發布候選版本，直到變更趨於穩定，並每 9 到 10 週發布一個版本；這仍是 kernel.org 記載的發布週期。模型的另一半於 2005 年 3 月 4 日形成，當時首次發布穩定樹，作為 2.6.11 的修正專用更新，由 Greg Kroah-Hartman 和 Chris Wright 維護。穩定樹只接收修正，不接受新功能。

這帶來的一項影響是：版本號不再代表承諾。3.0、4.0、5.0 和 7.0 都不是重新撰寫的版本。當第二個數字變大到令 Torvalds 感到困擾時，他就會提高第一個數字；因此 7.0 於 2026 年 4 月接續 6.19 發布。對伺服器而言，重要的是發行版追蹤哪個分支，以及該分支是否仍會取得修正。

BitKeeper 爭議如何在 2005 年 4 月促成 git

從 2002 年 2 月開始，kernel 以 BitKeeper 開發 2.5 系列。BitKeeper 是 Larry McVoy 的公司 BitMover 所有的專有分散式版本控制系統。BitMover 提供 kernel 開發者免費授權，但附帶條件：不得開發競爭性的版本控制工具，也不得對 BitKeeper 進行逆向工程。許多開發者不願使用無法閱讀原始碼的工具來開發自由 kernel。

2005 年 4 月，Andrew Tridgell 示範了一個可與 BitKeeper repository 通訊的程式後，這項合作破局。BitMover 認定這屬於逆向工程，因而撤回免費授權。kernel 在開發週期中途失去了版本控制系統。

git 於 2005 年 4 月 3 日開始開發。Torvalds 於 4 月 6 日宣布這項計畫。4 月 7 日，git 已能自行管理其原始碼，表示 git 自身的歷史已經儲存在 git 中。第一個合併多個分支的操作於 4 月 18 日完成。2005 年 6 月，git 已用於管理 2.6.12 的發布。Torvalds 不久後將維護工作交給 Junio Hamano，自己回到 kernel 開發。

這套設計直接源自當時的問題：有數千名貢獻者，以及彼此透過不受信任的網路互相拉取變更的維護者。每個物件都以其內容的 hash 命名，因此舊歷史只要變更 1 個 byte，之後每個 commit 的名稱都會改變。這就是 clone 能提供證據，而不只是聲稱的原因。每個部署 pipeline、每個設定 repository、多數團隊推送程式碼的 code host，以及 你可以自行執行的 git server，都源自一場圍繞 kernel 授權問題的爭議。

LTS 模型承諾的內容，以及不承諾的內容

Mainline 並不是實際執行的版本。Mainline release 會在 9 到 10 週後被後續版本取代。Stable tree 會在每次 release 後持續提供幾週的修正。Longterm branch 通常標示為 LTS，會持續提供多年的修正，而各 Linux distribution 會以這些分支為基礎建置。

2009 年 12 月發布的 2.6.32，證明了這套模型可行。RHEL 6、Debian 6、SUSE Linux Enterprise 11 SP1 和 Ubuntu 10.04 LTS 都採用這個版本，而該分支持續維護至 2016 年 2 月，也就是發布後超過 6 年。

這項承諾曾多次調整。維護期限起初是 2 年，部分分支後來延長至 6 年。2023 年，stable 維護者將預設期限縮短回 2 年，因為將修正 backport 到舊 tree 需要維護者投入時間，而舊分支也很少接受實際測試。2026 年 2 月 25 日，Greg Kroah-Hartman 與依賴這些分支的公司討論後，再次公布較長的預估期限。目前的架構涵蓋 3 到 6 年。

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

截至 2026 年 8 月，kernel.org 列出 6 個 longterm 分支。最舊的分支 5.10 結束維護時，將已提供 6.0 年的修正，預計結束日期為 Dec 2026。最新的分支 6.18 預計維護至 Dec 2028，也就是提供 3.1 年的修正。

請將這些日期視為最低期限，而不是合約承諾。6.6 和 6.12 的預估期限都在 2026 年 2 月延後；相反地，若某個分支無人使用，也可能提前停止維護。通常由你的 distribution 替你做出選擇：Debian 13 採用 6.12，Ubuntu 26.04 LTS 採用 7.0。這項差異就是伺服器上 LTS 與 interim release 的實際問題的具體內容，也是將 Ubuntu 24.04 升級至 26.04時底層真正發生的變化。

這會導致一個常見陷阱。uname -r 在 Ubuntu 24.04 上會輸出類似 6.8.0-51-generic 的內容。這表示它是 upstream 基礎版本加上 distribution 自行 backport 的修正，因此版本號只能告訴你該分支從哪個版本開始，不能說明其中包含哪些修正。掃描工具根據 kernel 版本字串判斷是否存在問題時，正因如此會對 distribution kernel 產生誤報。

核心目前正在爭論的事項

目前有兩項爭論，兩者都涉及工作應由誰負責。

Rust 在 2022 年 12 月的 6.1 版納入基礎架構。在 7.0 版中移除了實驗性標籤，因此核心使用的語言包括 C、組合語言與 Rust，建置也不再需要 nightly compiler。爭論焦點在於維護工作。C 維護者修改介面時，可能會破壞自己不熟悉的 Rust bindings；目前爭論的是，修復這些問題應由誰負責。

第二項爭論是 AI 產生的貢獻。Sasha Levin 在 2025 年 7 月提出一項政策，原因是愈來愈多 machine-assisted patches 進入 mailing lists。該文件於 2025 年 12 月 23 日提交，現在位於 kernel 自身的流程文件 docs.kernel.org/process/coding-assistants.html 中。AI agent 不得加入 Signed-off-by tag，因為該行代表 Developer Certificate of Origin (DCO)，而且只有人員可以進行認證。使用協助時，應以 Assisted-by: tag 宣告；該 tag 在審查期間由 Co-developed-by: 變更而來，因為工具不是作者。產生的程式碼必須與 GPL-2.0-only 相容。提交 patch 的人員必須審查該 patch，並對其負責。

這項政策背後的壓力來自審查時間。產生 patch 只需數秒，但審查 patch 可能占用維護者一個下午。Tag 無法消除這種不平衡，但能保留來源資訊：歷史記錄會持續記載每項變更由誰簽署，這正是 DCO 在 2004 年推出時要保護的內容。

這段歷史對您租用的伺服器代表什麼

• 授權條款讓您能讀取並重新建置供應商啟動的 kernel，也讓專有軟體能在其上執行。
• 單體式設計使單一 driver 的錯誤可能重新啟動整台機器，也使 out-of-tree module 必須在每次 kernel 升級時重新建置。
• 發行模式使版本號提供的資訊有限；相較之下，branch 及其 end-of-life 日期幾乎能說明所有重要事項。
• virtualisation 類型決定您能執行的操作：在 KVM 上，您可以啟動自己的 kernel 並載入 module；在共用 host kernel 的 container virtualisation 上，uname -r 會顯示 host 的版本，modprobe 會失敗，且數個 sysctl 只能讀取。

FAQ

為什麼 Linux kernel 仍採用 GPLv2，而不是 GPLv3？

Torvalds 在 2007 年決定不採用 GPLv3，主要原因是反對其中的 anti-tivoisation 要求。這項要求會強制散布 GPL 程式碼的裝置同時接受該程式碼的修改版本。他認為鎖定硬體屬於製造商的業務決策。實務上，重新授權也幾乎不可能，因為 kernel 的著作權由數千名貢獻者持有，而且沒有可供依循的著作權讓與協議。kernel 採用 GPL-2.0-only，因此僅以 GPLv3 授權的程式碼無法合併。

Linux kernel 是單體式 kernel 還是微核心？

Linux kernel 是具備可載入模組的單體式 kernel。驅動程式和檔案系統都在 kernel 的位址空間中執行，而 lsmod 會顯示目前已載入的項目。這種設計一方面提供速度，另一方面也擴大故障影響範圍：錯誤的模組可能使整台機器發生 kernel panic；微核心則通常只會失去一個程序。自 1992 年起，使用者空間中的 FUSE 檔案系統，以及 kernel 在執行前會先驗證的 eBPF 程式，已使兩者的差異縮小。

mainline、stable 與 longterm kernel 有何差異？

mainline 是 Torvalds 維護的程式碼樹，每 9 到 10 週發布一次，新功能會先合併到此處。stable 取自最新的 mainline 版本，並在數週內持續接收錯誤修正。longterm 分支會持續接收多年的修正，發行版通常以這些分支建置 kernel。kernel.org 會列出目前的 longterm 分支，以及各分支預計的終止維護日期。

Linux kernel 接受 AI 撰寫的程式碼嗎？

接受，依據 2025 年 12 月承諾遵循的政策，工具必須在 Assisted-by: 標籤中列出名稱，AI agent 不得新增 Signed-off-by 行，且產生的程式碼必須相容於 GPL-2.0-only。提交者必須簽署確認，表示已檢閱該修補程式，並依據 Developer Certificate of Origin 對其負責。

伺服器應執行哪個 kernel 版本？

幾乎所有情況下，都應執行發行版維護的版本。發行版 kernel 是 longterm 分支、回移植的修正，以及供應商測試的組合；供應商提供的映像檔和支援安排也都以此為前提。只有在需要特定驅動程式或功能時，才應建置較新的 mainline kernel；在決定使用前，先確認準備切換到的分支終止維護日期。