Linux发行版历史：Slackware、Debian与Red Hat家族

Linux 发行版实际上是什么

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

它由五部分组成。改变其中任何一部分，就会得到不同的发行版，即使大多数二进制文件相同：

• 内核：使用项目选定的版本，以及项目添加的补丁和驱动程序。
• 用户空间：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 都自行编写了软件包管理器，并制定了各自的规则。其中 2 个发行版——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 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 套件和一条规则。维护者将软件包上传到 unstable，其永久代号为 sid。如果软件包能在发布架构上成功构建，且没有引入新的 release critical bug，脚本会在大约 5 到 10 天后将其迁移到 testing。随后 testing 进入冻结状态，发布团队处理剩余问题；待 bug 列表足够短时，stable 才会发布。发布不遵循固定日期。这就是 Debian stable 看起来较旧但运行稳定的原因：版本号在冻结时停止更新，而安全修复会持续反向移植到这些版本中。

Debian 的治理方式也有明确的书面规则，包括选举产生的项目负责人和具有约束力的全体决议。2014 年，这套机制选择 systemd 作为默认 init 系统。持不同意见的人随后 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），由 Erik Troan 和 Marc Ewing 为 1995 年的 Red Hat Linux 2.0 编写。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，用于发布共享源代码。

如果服务提供商的镜像列表仍然写着 CentOS，请先确认它具体指的是哪个版本，再基于它进行部署。

cat /etc/os-release

NAME="CentOS Stream" 是引领 RHEL 的滚动开发分支。NAME="AlmaLinux" 或 NAME="Rocky Linux" 是跟随 RHEL 的重建版，支持周期为 10 年。

Ubuntu，2004：日历上的 Debian unstable 快照

Ubuntu 4.10 于 2004 年 10 月 20 日发布，由 Mark Shuttleworth 资助。它与 Debian 的关系是机制上的，而不是情感上的。每个开发周期开始时，Ubuntu 都会将软件包从 Debian unstable 导入新的 Ubuntu 版本。这些导入会持续到周期中途的 Debian Import Freeze。此后，Ubuntu 维护自己的更改。许多 Ubuntu 软件包都是 Debian 软件包加上差异补丁，变更日志会说明具体内容。

另一半是发布日历。Debian 在准备就绪后发布。Ubuntu 在 4 月和 10 月发布，版本号就是发布日期：24.04 于 2024 年 4 月发布。每隔一个 4 月版本就是一个 LTS（长期支持）版本。提供商列出 Ubuntu 但不加限定词时，通常指的就是 LTS。服务器应选择两个版本中的哪一个，是 选择 Ubuntu LTS 还是非 LTS 版本 的核心内容；从一个 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 库，使用 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 在 2020 年原版 Container Linux 停止维护后，延续了其设计。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 镜像列表会是这样

服务商提供客户按名称要求、并且可以在其虚拟机监控程序上无人值守安装的镜像。因此，几乎所有列表都会以 Ubuntu LTS 和 Debian stable 开头，为软件通过 RHEL 认证的用户加入 AlmaLinux 或 Rocky，再将 Alpine、Arch 和 Fedora 排在更后面。了解VPS 是什么以及镜像如何写入磁盘后，这种排列就很清楚了：服务商选择的是能够完成无人值守安装，并且支持周期长于普通客户服务器使用周期的操作系统。

这个选择决定的不只是包管理器。它还决定您三年后执行哪种升级，而不同发行版家族的升级方式完全不同。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。接替其原有用途的免费重构发行版是 AlmaLinux 和 Rocky Linux，两者都提供 ten year 的支持周期。

为什么 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 以只读方式挂载，更新会作为完整的新目录树暂存，并在重启时切换；之前的目录树会保留为启动项，以便回滚。这样可以确保机器要么已完整更新，要么完全未更新，不会处于半更新状态。您不能再通过直接修改文件来安装软件，因此应用程序需要放入容器或分层软件包中。