Linux 發行版歷史：Slackware、Debian 與 Red Hat 家族

Linux 發行版實際上是什麼

Linux 發行版的歷史始於一個缺口：Linux kernel 本身無法執行使用者能直接使用的任何功能。它會開機並偵測硬體，然後就停止。有人必須加入 userland、決定軟體的安裝與更新方式，並承諾在未來數年持續修正問題。發行版就是這些選擇，加上後續持續維護它的人員與團隊。

它由 5 個部分組成。只要變更其中任何一項，就會形成不同的發行版，即使大多數 binary 都相同：

• kernel：使用專案選定的版本，並包含專案加入的 patches 與 drivers。
• userland：C library、shell、init system 及標準指令。
• package format，以及負責安裝該格式的工具。
• release policy：哪些內容可以變更、變更頻率，以及每個版本的維護期限。
• 人員：package maintainers、security team，以及套件發生問題時負責回應的人員。

kernel 是共用部分，因此兩個 Linux 發行版彼此之間的相似程度，遠高於其中任一者與其他 Unix 的相似程度。比較 Linux 與 FreeBSD 作為伺服器平台 時，這一點值得記住；在 FreeBSD 中，kernel 與基礎 userland 由同一個專案建置並一同發布。在 Linux 中，這些元件來自不同的 upstream，而發行版負責讓它們彼此配合。

Linux 發行版在 3 個家族中的歷史

3 個專案在 1993 和 1994 年啟動，後來發展成 3 個家族：Slackware、Debian 和 Red Hat。如今 VPS 控制面板中的幾乎每個映像檔，都是其中之一或其衍生版本。衍生版本會繼承套件格式、檔案配置，通常也會沿用版本發布習慣。因此，即使移除品牌標識，Debian 衍生版使用起來仍然像 Debian。

獨立發行版應該另外說明，因為它們沒有從其他發行版分支而來。Arch、Gentoo、Alpine、NixOS 和 Void 都自行開發套件管理員與規則。其中 2 個發行版 Arch 和 Alpine，最後仍出現在供應商的映像檔清單中，原因與桌面環境無關。

1992：家族出現前的發行版

MCC Interim Linux 於 1992 年 2 月問世，由 Manchester Computing Centre 的 Owen Le Blanc 組裝。它以一組由選單操作的安裝程式，將 kernel 與 GNU（GNU's not Unix）工具放入兩張軟碟映像檔。它之所以存在，是因為手動完成這些工作需要一整天。

Peter MacDonald 於 1992 年發布 SLS（Softlanding Linux System），功能更進一步，加入 X（X Window System）與 TCP/IP 網路。SLS 讓 distribution 一詞具備今日的意義。不過，SLS 充滿錯誤，維護速度也很慢。1993 年，兩個人分別決定修正這些問題。其中一人重新建置了它。另一人則依照書面規則重新開始。

Slackware，1993：仍在發布版本的最古老家族

Patrick Volkerding 在 1993 年 7 月 16 日發布 Slackware 1.00。該版本以 SLS 為基礎，並修正其中的錯誤。Slackware 至今仍有人維護，因此成為現存最古老的 Linux 發行版。

Slackware 套件是壓縮的 tar 封存檔，內含安裝指令碼。它不會解析相依性：沒有任何機制會檢查新套件所需的函式庫是否已存在於磁碟上。這項單一決策影響了其他所有設計。如果工具不會解析相依性，發布的套件集合就必須在設計上保持一致，因此版本發布較少且較為保守。Slackware 15.0 在 2022 年 2 月推出，距離 14.2 已有 6 年。

這個家族規模不大。SUSE 在 1990 年代中期的早期版本以 Slackware 為基礎，之後透過 YaST，以及後來的 RPM 套件格式，走上自己的發展道路。最後這一點常讓人混淆。SUSE 與 openSUSE 使用 RPM 套件，但它們不是 Red Hat 的衍生版本。套件格式可以流通，系譜則不會因此改變。

Debian，1993：社會契約與三套件庫發布流程

Ian Murdock 在 1993 年 8 月 16 日宣布 Debian，時間比 Slackware 晚 3 週，原因也相同。名稱由他的伴侶 Debra 與自己的名字組合而成。Debian Manifesto 隨後於 1994 年 1 月發布，並確立基本原則：這個發行版由志願者公開維護，而不是由公司維護。

Debian 接著將這些原則正式記錄下來。Debian Social Contract 與 DFSG（Debian free software guidelines）於 1997 年 7 月採用，DFSG 並在 1998 年成為 Open Source Definition 的基礎。一份原本用來界定單一發行版內容的文件，最後為整個產業定義了授權條款類別。這也是你的 sources.list 具有元件的原因：main 存放符合規範的軟體，contrib 與 non-free 存放不符合規範的軟體，而 Debian 12 新增 non-free-firmware，讓配備無線網路卡的筆電無須到處尋找套件即可完成安裝。

工具鏈是另一項重要傳承。dpkg 安裝單一套件；若缺少相依套件，便會拒絕安裝並輸出 dpkg: dependency problems prevent configuration of。APT（advanced package tool）在 1999 年 Debian 2.1 中成為預設工具，負責判斷還需要擷取哪些套件，以及應依何種順序處理。每個 Debian 衍生版本中的 apt 指令，都源自這套機制。

發布流程使用 3 個套件庫，並遵循 1 項規則。維護者將套件上傳至 unstable，其永久代號為 sid。若套件能在發布架構上成功建置，且沒有新增 release-critical bug，腳本會在大約 5 到 10 天後將套件遷移至 testing。接著 testing 進入凍結階段，release team 清理剩餘問題，待 bug 清單縮短至足夠程度後，stable 才會發布。發布不依固定日期。這就是 Debian stable 看起來較舊、運作卻很穩定的原因：版本號會在凍結時停止更新，但安全性修正仍會回溯套用到這些版本。

治理方式也有明文規範，包括選出的 project leader 與具約束力的 general resolutions。2014 年，這套機制選定 systemd 作為預設 init system；持不同意見的人則建立 Devuan，並在 2017 年發布第一個版本。Debian 既不是第一個進行這項變更的發行版，也不是最後一個。這項變更反覆發生的原因，以及後來證明正確的反對意見，詳見systemd 取代 SysV init 的經過。規模較大的衍生版本包括 Ubuntu、Raspberry Pi OS、Proxmox VE、Kali 與 Linux Mint。

Red Hat, 1994：RPM，接著分拆為 Fedora 與 RHEL

Marc Ewing 在 1994 年萬聖節前後發布了第一版 Red Hat Linux。Bob Young 的公司於 1995 年買下它，兩人建立了第一家銷售支援服務而非軟體的 Linux 企業。Red Hat 於 1999 年 8 月 11 日上市。IBM 在 2019 年 7 月完成對該公司的收購，交易金額約為 34 billion dollars，因此多數企業軟體所認證的發行版，自此一直屬於 IBM。

RPM（Red Hat package manager）是 Red Hat 最持久的技術貢獻。Erik Troan 與 Marc Ewing 於 1995 年為 Red Hat Linux 2.0 撰寫了 RPM。RPM 會宣告相依性，並由 spec file 產生；spec file 是任何人都能執行的建置配方。正是第二項特性，讓後來獨立重建 Red Hat 企業產品成為可能。

2003 年的 Red Hat Linux 9 是原始產品線的最後一版。公司將產品線一分為二：2003 年 11 月推出 Fedora Core 1，作為快速更新的社群版本；而 RHEL（Red Hat Enterprise Linux）則作為更新較慢的付費版本。RHEL 最初於 2002 年以 Advanced Server 2.1 的形式推出。原因很明確。同一個產品不可能同時是測試新版本的平台，也是銀行連續十年不變地執行的平台。兩個分支彼此相連：RHEL 主要版本從 Fedora 版本分支而出，經過穩定化後再凍結。套件工具也依循相同時程演進，從 2000 年代的 yum，轉為 2015 年 Fedora 的預設工具 dnf，而兩者底層都使用 rpm。

CentOS 為何不再是免費的 RHEL 重建版

CentOS 在 2004 年開始時只有一項簡單任務：取得 Red Hat 發布的原始碼套件，移除商標後重新建置，再免費提供給使用者。它在接下來的 10 年成為預設的免費伺服器發行版，Red Hat 則在 2014 年將這個專案納入公司內部。

2020 年 12 月 8 日，Red Hat 宣布 CentOS Linux 8 將於 2021 年 12 月 31 日終止支援，比原先公布的日期提早 8 年；CentOS 這個名稱則會以 CentOS Stream 的形式延續。Stream 不是重建版，而是 RHEL 小版本的來源分支，因此其進度會領先 RHEL，而不是落後於 RHEL。若某台機器預計使用多年，領先並不是正確方向，因為你會在 Red Hat 的付費客戶之前收到變更。

2021 年出現了兩個重建版。Rocky Linux 由 CentOS 共同創辦人 Gregory Kurtzer 發起。AlmaLinux 則由 CloudLinux 提供資金。2023 年 6 月，Red Hat 停止在 CentOS Stream 和客戶入口網站以外的地方發布 RHEL 原始碼。Rocky 仍以完全相同的重建版為目標。AlmaLinux 則將目標改為 ABI（應用程式二進位介面）相容性，也就是為 RHEL 建置的軟體可以執行，但不保證錯誤清單逐項一致。Oracle、SUSE 和 CIQ 在同年稍後成立 OpenELA，以發布共用原始碼。從 2003 年的分裂、2023 年的原始碼變更，到目前各重建版的承諾，Red Hat、CentOS、Rocky 與 AlmaLinux 的完整說明都有詳細追蹤。

如果供應商的映像檔清單仍標示 CentOS，請先確認它實際指的是哪一個版本，再以此為基礎建置系統。

cat /etc/os-release

NAME="CentOS Stream" 是引導 RHEL 的滾動式開發分支。NAME="AlmaLinux" 或 NAME="Rocky Linux" 則是跟隨 RHEL 的重建版，提供 10 年的支援期限。

Ubuntu，2004：按照時程發布的 Debian unstable 快照

Ubuntu 4.10 由 Mark Shuttleworth 資助，於 20 October 2004 發布。Ubuntu 與 Debian 的關係是機制上的，而非情感上的。每個開發週期都會先將套件從 Debian unstable 匯入新的 Ubuntu 版本。這些匯入作業會持續到週期中段的 Debian Import Freeze；之後，Ubuntu 便維護自己的變更。許多 Ubuntu 套件都是 Debian 套件加上差異內容，changelog 會說明其中差異。

另一半是發布時程。Debian 準備好後才發布。Ubuntu 則在 April 和 October 發布，版本號就是日期：24.04 於 April 2024 發布。每隔一個 April 版本就是 LTS（long term support），供應商列出未加限定詞的 Ubuntu 時，指的就是這類版本。伺服器應選用哪一種版本，是 選擇 Ubuntu LTS 或 interim release 的核心問題；從一個 LTS 升級到下一個 LTS 也有專屬程序，詳見 從 24.04 升級至 26.04。

有一項細節每年都會引起伺服器管理員注意。Ubuntu 的套件庫分為多個元件。main 由 Canonical 維護整個支援期間。universe 由社群維護，其安全性涵蓋範圍是另一項承諾。apt install 不會顯示兩者的差異。以下指令可以查看：

apt-cache policy nginx

Repository line 以 /main 結尾，表示該套件由 Canonical 的安全團隊負責。以 /universe 結尾，表示由社群負責。任何面向網際網路的服務，都應檢查這項設定。

Arch，2002：滾動發布與部分升級的代價

Judd Vinet 在 11 March 2002 發布 Arch 0.1，內含他自行撰寫的套件管理器 pacman，以及以純 shell script 撰寫的建置配方。Arch 完全沒有版本化發布。安裝媒體是相同滾動套件庫的日期快照，因此，2019 年安裝且每週更新的機器，執行的 Arch 與今天安裝的機器相同。AUR（Arch user repository）存放使用者貢獻的建置配方。這些是配方，不是經過審查的套件，因此，執行前閱讀 PKGBUILD 是管理工作的一部分。

滾動發布只有一種失敗模式，而且每次都是自行造成的。使用 pacman -Sy foo 安裝單一套件時，會先重新整理套件資料庫，再安裝一個以比磁碟上更新的函式庫連結而成的新二進位檔。接著，程式會出現以下錯誤：

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

受支援的操作是 pacman -Syu，它會一次更新所有內容。專案也會發布新聞項目，說明特定升級前需要手動介入；未閱讀這些項目就執行升級，可能導致機器無法開機。

因此，若計畫忽略伺服器，Arch 並不是理想選擇。每週更新的機器沒有問題。若隔了一年才更新一次，所有跳過的手動介入步驟都會在單次執行中一併出現。

Alpine：因容器而廣為人知的小型發行版

Alpine 約於 2005 年從 LEAF（Linux embedded appliance framework）分支而來，而 LEAF 本身則源自 Linux Router Project。Natanael Copa 設計 Alpine 的目標是嵌入式設備，而不是桌面電腦。它替換了大部分常見的使用者空間元件：以 musl 取代 GNU C library、以 BusyBox 取代 GNU core utilities、以 OpenRC 取代 systemd，並使用 apk 作為套件管理員。2014 年發布的 Alpine 3.0 改用 musl。

容器讓 Alpine 受到廣泛採用。Alpine 基礎層的大小只有 Debian 或 Ubuntu 基礎層的一小部分。因此，自 2016 年起，Alpine 成為常見的基礎映像檔。許多從未安裝 Alpine 的人，也每天在執行 Alpine。

代價是 musl 並非 glibc，兩者的差異會以看似無關的錯誤呈現。連結 glibc 的二進位檔在 Alpine 上執行時會失敗，並顯示一則讓人尋找既有檔案的訊息：

sh: ./myapp: not found

程式確實存在，但其 ELF interpreter 不存在，因為系統沒有 glibc 的 loader。Python 是另一個常見的意外：針對 manylinux 建置的預先編譯 wheel 無法在 musl 上安裝，因此 pip 會改為從原始碼編譯，並在未安裝編譯器時停止。2021 年推出的 musllinux wheel 標準，解決了有發布這類 wheel 的專案之問題，其他專案則不受影響。

在 VPS 上將 Alpine 作為主機作業系統時，安裝所需空間小，更新速度快，但使用的環境與大多數文件預設的環境不同。凡是指南要求執行 systemctl enable，都必須改寫為 rc-update add。

不可變世代：原子更新與映像檔式伺服器

最新的分支改變的是更新模型，而不是套件清單。以 ostree 為基礎的系統會將 /usr 保持唯讀。更新內容是完整的新檔案系統樹，會先下載並暫存，然後在下次重新開機時切換。舊的檔案系統樹會保留為開機項目，因此更新發生問題時，只要重新開機並選擇舊版本即可復原。

Fedora Silverblue 在 2018 年將這種方式帶到桌面環境；Red Hat 在 2018 年收購 CoreOS 後，Fedora CoreOS 於 2019 年將其帶到伺服器。Flatcar Container Linux 在 2020 年停止維護原始的 Container Linux 後，延續了其做法。openSUSE MicroOS 則透過 btrfs 快照與 transactional-update 達到相同目的。2024 年，Red Hat 為 RHEL 加入以映像檔為基礎的模式，建構於 bootc 之上；作業系統會以容器映像檔形式提供，而更新機器時，只需將其指向新的 tag。Talos Linux 更進一步，完全移除 shell 與 SSH：機器透過 API 設定，因此沒有可登入的介面。NixOS 首次於 2007 年發布，採用不同的方式。整個系統由單一宣告式設定建置，先前的世代仍可開機使用。

你的供應商可能不會以一鍵映像檔提供上述系統，因為這些系統預期在首次開機時由 Ignition 或 cloud-init 進行設定，而不是由管理員透過 SSH 編輯檔案。這些系統適合大量相同的機器。當你開始同時管理多台 Linux 伺服器，並需要證明每台機器都與其他機器完全一致時，就能發揮效益。

一個版本支援多久？

版本政策是您需要長期面對的發行版特性，通常會以年數公布。以下是 5 個目前伺服器版本的支援期間。

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine 的每個 3.x 分支支援 2 年。因此，相較於長期不變的主機，它更適合經常重新建置的容器映像檔。Debian 的安全團隊會支援穩定版本約 3 年，之後由 LTS 團隊繼續支援常見架構，總計約 5 年。Ubuntu LTS 會為 main 中的套件提供 5 年支援；Ubuntu Pro 訂閱則延長至 10 年。個人可在少量機器上免費使用。RHEL 10 公布 10 年支援期限，付費的 extended life cycle support add-on 可將期限延長至 13 年。AlmaLinux 10 無需任何訂閱，即可提供與 RHEL 相同的 10 年支援期限。這正是建立這些重建版本的完整原因。

這裡沒有列出 Arch，因為 rolling distribution 沒有需要支援的版本。對 Arch 而言，真正重要的是您能讓機器維持多久不更新，而這通常以週計算。

為什麼你的 VPS 映像檔清單會長這樣

供應商提供的映像檔，通常是客戶會直接點名、而且能在其 hypervisor 上以無人值守方式完成安裝的版本。因此，幾乎每份清單都會以 Ubuntu LTS 和 Debian stable 開頭，加入供需要通過 RHEL 認證的軟體使用者選擇的 AlmaLinux 或 Rocky，並將 Alpine、Arch 和 Fedora 排在後面。了解 VPS 是什麼，以及映像檔如何寫入磁碟 後，這個模式就很清楚：供應商選擇的是能完成無人值守安裝，且支援週期長於一般客戶使用伺服器期間的作業系統。

這項選擇不只決定套件管理員，也決定你 3 年後會採用的升級方式，而不同家族的方式完全不同。Debian 和 Ubuntu 支援就地進行主要版本升級。Red Hat 家族透過 leapp 執行升級。Arch 沒有所謂升級，因為它沒有版本。Alpine 的升級方式是編輯 /etc/apk/repositories，然後執行 apk upgrade --available。這項選擇也決定你不新增第三方 repository 時能安裝哪些軟體、執行中的軟體出現 CVE（常見漏洞與曝露）項目時由誰提供修補程式，以及未來的軟體會假設系統上存在何種 init system 和 C library。

還有一項影響很容易被低估。網路上的大多數解答都假設使用 Debian 家族或 Red Hat 家族的流程，因此選擇其他家族，就代表整台機器的生命週期都要自行轉換操作指示。請選擇其 release policy 符合你願意多久維護一次伺服器的家族，然後持續使用。上層套件很容易更換。要更換底層 distribution，則必須重建整台機器。

FAQ

我的伺服器屬於哪個 Linux 發行版家族？

執行 cat /etc/os-release。ID 欄位會列出發行版，ID_LIKE 會列出其家族，因此 Ubuntu 電腦會回報 ID_LIKE=debian，AlmaLinux 電腦會回報 ID_LIKE="rhel centos fedora"。套件管理器也能提供判斷依據。apt 和 dpkg 表示 Debian 家族，dnf 和 rpm 表示 Red Hat 家族，apk 表示 Alpine，pacman 表示 Arch。

CentOS 仍然是 RHEL 的免費版本嗎？

不是。CentOS Linux 8 是最後一個以該名稱發布的重建版本，已於 31 December 2021 終止；CentOS Linux 7 也已於 30 June 2024 結束生命週期。現存的 CentOS Stream 專案是建置 RHEL 次要版本的分支，因此它會比 RHEL 更早取得變更，而不是較晚取得。接替舊有角色的免費重建版本是 AlmaLinux 和 Rocky Linux，兩者都提供 ten year 的支援期間。

為什麼 Debian stable 的版本號看起來這麼舊？

因為版本號會凍結，但修正仍會持續加入。Debian 會將安全性修補程式回溯套用至已發布的版本，而不是匯入較新的上游版本，因此標示為 2.4.57-2+deb13u1 的套件，仍可能包含上週發布的修正。上游版本後面的尾碼是 Debian 修訂版本，apt changelog <package> 會列出其中包含的變更。只根據版本號判斷 Debian 伺服器的安全性，結果一定會失準。

我應該在 VPS 上執行 Arch 這類 rolling release 嗎？

只有在你會依照排程更新時才適合。rolling distribution 假設每台機器都會與目前的套件集合保持一致，因此使用 pacman -Sy foo 更新單一套件，可能留下不相容的函式庫，並產生 cannot open shared object file 等錯誤。定期執行 pacman -Syu，每次執行前先閱讀專案的新聞頁面，系統就能維持穩定。若延後一年才更新，第一次升級就會變成高風險操作。

immutable 或 atomic distribution 實際上改變了什麼？

它改變更新套用的時機，以及復原更新的方式。/usr 會以唯讀方式掛載，更新會先準備成完整的新樹狀目錄，並在重新開機時切換；先前的樹狀目錄則會保留為開機項目，以便復原。如此一來，機器不是已完整更新，就是完全未更新，不會處於只套用一半的狀態。你將無法透過直接修改檔案來安裝軟體，因此應用程式會改放入容器或分層套件中。