Linux发行版历史：Slackware、Debian与Red Hat谱系

Linux 发行版究竟是什么

Linux 发行版的历史始于一个缺口：Linux 内核本身无法执行用户可用的任何操作。它会启动并识别硬件，然后停止。必须有人添加用户空间，决定如何安装和更新软件，并承诺在未来多年持续修复问题。发行版就是这些选择的集合，以及之后持续维护它的人员群体。

它由 5 个部分组成。即使大多数二进制文件相同，只要其中任意一项不同，就是不同的发行版：

• 内核：使用项目选定的版本，以及项目添加的补丁和驱动程序。
• 用户空间：C 库、shell、init 系统和标准命令。
• 软件包格式，以及用于安装软件包的工具。
• 发布策略：允许更改哪些内容、发布频率，以及每个版本获得修复支持的时长。
• 人员：软件包维护者、安全团队，以及软件包出现问题时负责响应的人员。

内核是共享部分，因此两个 Linux 发行版之间的距离，远小于任一发行版与另一种 Unix 之间的距离。比较 Linux 和 FreeBSD 作为服务器平台时，应牢记这一点：在 FreeBSD 中，内核和基础用户空间由同一个项目构建并一同发布。在 Linux 中，这些部分来自不同的上游项目，而发行版负责让它们彼此兼容。

Linux 发行版三大谱系的历史

Slackware、Debian 和 Red Hat 这 3 个项目分别于 1993 年和 1994 年启动，后来发展成为三大谱系。如今 VPS 控制面板中的几乎每个镜像都属于其中一个发行版，或属于它的衍生版本。衍生版本会继承软件包格式、文件布局以及通常的发行方式。因此，即使去掉品牌标识，Debian 衍生版使用起来仍然会保留 Debian 的特征。

独立发行版需要单独说明，因为它们没有从其他发行版分叉而来。Arch、Gentoo、Alpine、NixOS 和 Void 都自行编写了软件包管理器，并制定了自己的规则。其中 Arch 和 Alpine 最终也出现在服务商的镜像列表中，但原因与桌面环境无关。

1992：各发行版家族出现之前

MCC Interim Linux 于 1992 年 2 月出现，由 Manchester Computing Centre 的 Owen Le Blanc 组装。它将内核和 GNU（GNU's not Unix）工具放入两张软盘映像，并提供菜单驱动的安装程序。这样做是因为手动完成这些工作需要花费一天时间。

SLS（Softlanding Linux System）由 Peter MacDonald 于 1992 年发布，功能更进一步，加入了 X（X Window System）和 TCP/IP 网络支持。如今 distribution 一词的含义，源于 SLS。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 自由软件指南）于 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 套通道，并遵循一条规则。维护者将软件包上传到 unstable，其永久代号为 sid。如果软件包能在发布架构上成功构建，且没有引入新的发布关键漏洞，脚本会在大约 5 到 10 天后将其迁移到 testing。随后 testing 进入冻结阶段，发布团队处理剩余问题；漏洞列表足够短时，stable 才会发布。发布不按固定日期进行。这就是 Debian stable 版本较旧但运行稳定的原因：冻结后版本号不再变化，但安全修复会持续回移植到这些版本中。

治理规则同样形成了文档，包括选举产生的项目负责人和具有约束力的全体决议。2014 年，这套机制选择 systemd 作为默认 init 系统。持不同意见的开发者随后创建了 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 月完成对该公司的收购，交易金额约为 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）则作为更新缓慢的付费发行版。RHEL 最初于 2002 年以 Advanced Server 2.1 的形式出现。原因很明确：一个产品不可能既用于试验新版本，又作为银行连续十年不变地运行的平台。这两部分彼此关联：RHEL 的主版本从某个 Fedora 版本分支出来，经过稳定化处理，然后被冻结。软件包工具也按同一计划演进：从 2000 年代的 yum，发展为 2015 年 Fedora 的默认工具 dnf，两者底层都使用 rpm。

CentOS 为何不再是免费的 RHEL 重建版

CentOS 于 2004 年开始运行，目标很简单：获取 Red Hat 发布的源软件包，移除商标，重新构建，然后免费提供。它在十年间成为默认的免费服务器发行版，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 于 20 October 2004 发布，由 Mark Shuttleworth 资助。Ubuntu 与 Debian 的关系是机制上的，而不是情感上的。每个开发周期开始时，都会将软件包从 Debian unstable 导入新的 Ubuntu 版本。导入会持续到周期中段的 Debian Import Freeze。此后，Ubuntu 会维护自己的更改。许多 Ubuntu 软件包是在 Debian 软件包基础上加入差异补丁，changelog 会说明具体内容。

另一半是发布时间表。Debian 准备好后才发布。Ubuntu 在 April 和 October 发布，版本号表示发布日期：24.04 于 April 2024 发布。每隔一个 April 发布版本就是一个 LTS（长期支持）版本。提供商列出 Ubuntu 而不附加其他限定时，通常指的就是 LTS。服务器应选择两个版本中的哪一个，完整讨论见如何在 Ubuntu LTS 和 interim releases 之间选择；从一个 LTS 升级到下一个 LTS 也有专门的流程，详见从 24.04 升级到 26.04。

有一个细节每年都会引起服务器管理员注意。Ubuntu 的软件仓库分为多个组件。main由 Canonical 在完整支持期限内维护。universe由社区维护，其安全覆盖范围是另一项承诺。apt install不会显示两者的区别。可以使用一个命令查看：

apt-cache policy nginx

以 /main 结尾的软件仓库行表示该软件包由 Canonical 的安全团队负责。以 /universe 结尾的软件仓库行表示由社区负责。对于任何面向互联网的软件包，都应检查这一点。

Arch，2002：滚动发布与部分升级的代价

Judd Vinet 于 2002 年 3 月 11 日发布了 Arch 0.1，并提供了他自行编写的软件包管理器 pacman，以及使用纯 shell 脚本编写的构建配方。Arch 完全没有按版本划分的发行版版本。安装介质是同一组滚动软件仓库在不同日期的快照，因此，2019 年安装并每周更新的机器，运行的 Arch 与今天安装的机器相同。AUR（Arch 用户软件仓库）存放用户提交的构建配方。这些是配方，不是经过审核的软件包，因此运行前阅读 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 年将这种模式带到了桌面，Fedora CoreOS 则在 2019 年将其带到了服务器；此前 Red Hat 已于 2018 年收购 CoreOS。Flatcar Container Linux 在 Container Linux 于 2020 年停止维护后，继续了其原有路线。openSUSE MicroOS 通过 btrfs 快照和 transactional-update 实现了相同目标。2024 年，Red Hat 为 RHEL 增加了基于镜像的模式，该模式构建于 bootc 之上。操作系统以容器镜像形式发布，更新机器时只需让它指向新的标签。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 年支持，付费的延长生命周期支持附加服务可将期限延长至 13 年。AlmaLinux 10 在完全不需要订阅的情况下提供与 RHEL 相同的 10 年支持，这正是这些重建版本存在的全部原因。

这里没有 Arch，因为滚动发行版没有需要支持的固定版本。对 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。这个选择还决定您无需添加第三方仓库即可安装哪些软件，运行的软件出现 CVE（常见漏洞和暴露）条目时由谁发布补丁，以及未来软件默认使用哪个 init 系统和 C 库。

还有一个容易被低估的影响。互联网上的大多数答案都假定使用 Debian 家族或 Red Hat 家族的路径，因此选择这两个家族之外的发行版，就意味着在服务器的整个使用周期内转换这些操作。请选择发布策略符合您维护服务器频率的发行版家族，然后保持使用。更换其上的软件包很容易。更换底层发行版则意味着重建服务器。

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 获得变更，而不是晚于 RHEL。接替 CentOS 旧角色的免费重建版本是 AlmaLinux 和 Rocky Linux，二者的支持窗口均为十年。

为什么 Debian stable 发布的版本号这么旧？

因为版本号会冻结，但修复会持续发布。Debian 会将安全补丁回移到已发布的版本中，而不是引入更新的上游版本，因此显示为 2.4.57-2+deb13u1 的软件包可能已包含上周发布的修复。上游版本号后的后缀是 Debian 修订号，apt changelog <package> 会列出其中包含的内容。每次仅根据版本号判断 Debian 服务器的安全性，结论都会错误。

我应该在 VPS 上运行 Arch 这类滚动发行版吗？

只有在能够按计划更新时才适合。滚动发行版假设每台计算机都会收敛到当前的软件包集合，因此使用 pacman -Sy foo 更新一个软件包后，可能留下不匹配的库，并出现 cannot open shared object file 等错误。定期运行 pacman -Syu，每次运行前阅读项目新闻页面，系统就能保持稳定。若一年不更新，第一次升级就会变得有风险。

不可变或原子发行版实际上改变了什么？

它改变了更新的应用时机，以及撤销更新的方式。/usr 以只读方式挂载，更新会暂存为完整的新目录树，并在重启时切换；之前的目录树会作为启动项保留，以便回滚。这样得到的系统要么已完全更新，要么完全未更新，不会处于半更新状态。代价是不能通过原地编辑文件来安装软件，因此应用会转移到容器或分层软件包中。