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

Linux 發行版實際上是什麼

Linux 發行版的歷史始於一個空缺：Linux kernel 本身無法執行任何使用者可用的功能。它會開機並偵測硬體，然後就停止。必須有人加入 userland、決定軟體的安裝與更新方式，並承諾多年持續修正問題。發行版就是這些選擇的集合，以及之後持續維護它的人員與社群。

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

• Kernel：採用專案選定的版本，以及專案加入的 patch 與 driver。
• Userland：C library、shell、init system 及標準 command。
• Package format，以及負責安裝 package 的 tool。
• Release policy：允許變更的內容、變更頻率，以及每個 release 維護修正的期限。
• 維護人員：package maintainer、security team，以及 package 發生問題時負責回應的人員。

Kernel 是共用部分，因此兩個 Linux 發行版彼此的相似程度，遠高於其中任一發行版與其他 Unix 的相似程度。比較 Linux 與 FreeBSD 作為伺服器平台 時，這一點很重要；在 FreeBSD 中，kernel 與 base userland 由同一個專案建置並一同發布。在 Linux 中，這些部分來自不同的 upstream，而發行版負責讓它們彼此相容。

Linux 發行版的三大家族沿革

Slackware、Debian 與 Red Hat 這 3 個專案在 1993 和 1994 年啟動，後來發展成 3 個家族。如今 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）工具放入一對軟碟映像檔，並提供選單式安裝程式。之所以需要它，是因為手動完成這些工作會耗費一天。

SLS（Softlanding Linux System）由 Peter MacDonald 於 1992 年發布，功能更進一步，加入 X（X Window System）與 TCP/IP 網路功能。SLS 讓 distribution 一詞具備今天的含義。但它也存在許多錯誤，維護速度緩慢。到了 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；持不同意見的人員則 fork 出 Devuan，並在 2017 年發布第一個版本。較大型的衍生版包括 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 月完成對該公司的收購，金額約為 340 億美元。因此，多數企業軟體通過認證的那個發行版，自此一直歸 IBM 所有。

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

2003 年的 Red Hat Linux 9 是原始產品線的最後一版。公司將它分成兩個產品：2003 年 11 月推出的 Fedora Core 1，作為快速更新的社群版本；以及 RHEL（Red Hat Enterprise Linux），它最初於 2002 年以 Advanced Server 2.1 的形式推出，作為更新緩慢的付費版本。原因很明確。同一個產品不可能同時作為測試新版本的平台，以及銀行連續 10 年不變地執行的平台。兩個版本仍彼此相連：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 年出現了 2 個重建版本。Rocky Linux 由 CentOS 共同創辦人 Gregory Kurtzer 建立。AlmaLinux 則由 CloudLinux 提供資金。2023 年 6 月，Red Hat 停止在 CentOS Stream 和客戶入口網站以外的地方發布 RHEL 原始碼。Rocky 仍以完全相同的重建版本為目標。AlmaLinux 則將目標改為 ABI（application binary interface）相容性，也就是為 RHEL 建置的軟體可以執行，但不保證錯誤清單逐項完全一致。Oracle、SUSE 和 CIQ 於同年稍晚成立 OpenELA，以發布共用的原始碼。

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

cat /etc/os-release

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

Ubuntu，2004：以行事曆發布的 Debian unstable 快照

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

另一半是發布行事曆。Debian 準備好後才發布。Ubuntu 則在 4 月和 10 月發布，版本號就是日期：24.04 於 2024 年 4 月發布。每隔一次的 4 月版本就是 LTS（long term support）。供應商列出未加限定詞的 Ubuntu 時，通常指的就是 LTS。伺服器應選擇哪一種版本，完整說明請參閱在 Ubuntu LTS 與 interim releases 之間選擇；從一個 LTS 升級到下一個 LTS 也有專用程序，請參閱24.04 升級至 26.04。

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

apt-cache policy nginx

以 /main 結尾的 repository 設定行，表示該套件由 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 為基礎的容器。

代價是 musl 並非 glibc，兩者的差異會以看似無關的錯誤呈現。使用 glibc 連結的二進位檔在 Alpine 上執行時會失敗，錯誤訊息還會讓人尋找一個其實已經存在的檔案：

sh: ./myapp: not found

程式確實存在，但其 ELF 直譯器不存在，因為系統沒有安裝 glibc 的載入器。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 在 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 的安全團隊會為 stable 版本提供約 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 (common vulnerabilities and exposures) 項目時由誰提供修補程式，以及未來的軟體會假設系統使用哪個 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 會以唯讀方式掛載，更新會先準備成完整的新樹狀目錄，並在重新開機時切換；先前的樹狀目錄則會保留為開機項目，以便 rollback。這樣的機器只會處於完整更新或完全未更新的狀態，不會留下半套用狀態。你將無法透過直接修改檔案來安裝軟體，因此應用程式會移入容器，或改用分層套件。