上个月我统计时，这个数字让我吃了一惊。到 2026 年，仍有十五个活跃维护的 Linux 发行版默认不搭载 systemd。经过十多年关于替代品会消亡的预测，它们依然存在。

当你启动一台 Linux 机器时，运行的第一个程序叫做初始化系统。它启动你的计算机所需的所有服务：网络、日志记录、桌面环境，一切。几十年来，Linux 社区一直在争论应该由哪个初始化系统来处理这项工作。一方说是 systemd，一个庞大的、一体化的工具，现在运行在超过 90% 的 Linux 安装上。另一方说它做得太多，违反了 Unix 的“做一件事并做好”的原则，并且更喜欢更小的替代品，如 OpenRC、runit 或 Dinit。这篇文章就是关于这场争论的。

初始化系统之争引发的争论比任何其他 Linux 争议都要激烈。比 Wayland 与 X11 之争更激烈。比内核采用 Rust 更激烈。在旁观了这场争斗这么久之后，我认为双方都部分正确，但主要还是固执己见。

以下是实际发生的事情、今天的状况，以及为什么这场争斗永远不会真正结束。

最初的 Unix 初始化系统很简单。PID 1 读取 /etc/inittab，按顺序运行 shell 脚本，仅此而已。对于 1980 年代来说，这运行得很好。

到了 2010 年，它已经分崩离析。顺序启动脚本意味着一个有 40 个服务的服务器需要几分钟才能启动完成。服务之间的依赖关系？你得通过像 S01networking 和 S20apache 这样的编号文件名手动管理它们，硬件检测基本靠祈祷，热插拔 USB 设备可能会使你的系统处于未定义状态。

SysVinit 在服务器一次启动并运行数月的情况下还能工作。现代系统拥有容器、云实例和动态硬件，需要更好的方案。

SysVinit 必须被取代。这一点已经尘埃落定，接下来发生了什么？

Lennart Poettering 和 Kay Sievers 于 2010 年发布了 systemd。到 2015 年，所有主要发行版都采用了它：Fedora (2011)、Arch (2012)、RHEL (2014)、Debian (2015)、Ubuntu (2015)、SUSE (2014)。

systemd 果断地解决了启动问题，并行启动服务，Socket 激活，适当的依赖关系跟踪，失败时自动重启。从顺序的 SysVinit 迁移到并行的 systemd 启动时，启动时间通常能缩短 70% 到 80%。

但 systemd 并没有止步于 init，它像黑洞吸收光一样吸收了其他功能：

• journald 接管了系统日志记录，也就是你的机器记录发生了什么以及何时发生的地方。

• resolved 接管了 DNS，也就是将域名转换为 IP 地址的部分。

• networkd 接管了网络配置，与 NetworkManager 竞争。

• logind 接管了用户会话跟踪，知道谁登录了以及在哪个屏幕上。

• udevd 接管了设备管理，检测你何时插入硬件。

• timesyncd 接管了时钟同步，保持你的系统时间准确。

• homed 添加了便携式家目录，你可以在机器之间携带。

这就是 Unix 哲学派人士失去理智的地方。“做一件事并把它做好”是 Unix 中最古老的规则。而 systemd 做了三十件事，而且其中一些只是做得尚可，而非卓越。

systemd 组件范围与传统 Unix 工具对比

虽然大多数发行版采用了 systemd，但少数顽固分子拒绝了。以下是他们使用的替代方案以及他们如何使其工作。

OpenRC (Gentoo, Alpine, Artix)：最成熟的替代品。OpenRC 是一个基于依赖关系的初始化系统，使用 shell 脚本，它不试图替换 syslog、DNS 或设备管理。Alpine Linux 使用 OpenRC 作为其默认初始化系统，这使得它在 Alpine 被选为基础镜像的容器部署中很常见。

runit (Void Linux, 部分 Artix 配置)：Runit 非常注重极简主义。三个阶段：一次性设置、服务监控、关闭，每个服务都是一个包含 run 脚本的目录。想启用一个服务？创建一个符号链接？想禁用它？移除它？没有 XML，没有 INI 文件，没有二进制格式。它的简洁性堪称优雅。

Dinit (Chimera Linux)：最新的竞争者。Dinit 提供基于依赖关系的服务管理，其设计比 systemd 更小，但比 runit 功能更强。Chimera Linux 选择 Dinit 作为默认，使其成为第一个将自身定位押注于此初始化系统的发行版。

s6 (一些自定义设置)：Laurent Bercot 的 s6 监控套件在技术上非常出色，但很少作为发行版默认使用，它主要出现在基于容器的部署和嵌入式系统中。

如果你在生产环境中运行过上述任何一种替代方案，我很乐意在评论区听到你的经验。

systemd 的技术优势是实实在在的，但这并不能完全解释它的主导地位。三个因素决定了这场战争的胜负：

Red Hat 的支持。Red Hat 在 systemd 开发和采用期间雇佣了 Lennart Poettering。Red Hat 控制着 Fedora，影响着 CentOS/RHEL，并塑造着企业级 Linux 的形态。当 Red Hat 采用一项技术时，企业界就会跟进。公司不在乎 Unix 哲学。他们在乎的是支持合同。

网络效应。一旦 Fedora 和 RHEL 采用了 systemd，软件开发人员就开始假设 systemd 存在，上游项目开始只提供 systemd 的 unit 文件。如果你的初始化系统无法运行那些假定 systemd 存在的软件，你的发行版就会遇到问题。

GNOME 依赖。GNOME 依赖 logind 进行会话管理。logind 是 systemd 的一部分。那些想要 GNOME 但又不想用 systemd 的发行版不得不创建 elogind，一个独立的 logind 分支。它能工作，但会带来持续的维护负担。

结果就是一个自我强化的循环。systemd 无处不在：软件以 systemd 为目标，发行版采用 systemd，然后 systemd 无处不在。

在 2026 年运行一个没有 systemd 的发行版，意味着要支付兼容性税。每个假定 systemd 存在的软件都需要一个变通方案。

elogind 为桌面环境处理会话管理。没有它，就没有 GNOME，没有功能完整的 KDE Plasma，没有完善的多席位支持。Gentoo 和 Artix 维护着 elogind 软件包，它能工作，但也需要有人不断从上游的 logind 移植变更。

eudev 曾是 udev 的独立分支。在 udev 合并到 systemd 之后，Gentoo 维护了它很多年，但在 2022 年因 favor of systemd-utils 而将其弃用。维护负担是真实存在的，并且很明显。

无 systemd 发行版的兼容层架构

这种兼容性工作才是运行替代方案的真正代价，初始化系统本身可能更简单，但整个系统的复杂性通常并非如此。

我对每种方法最适合哪里有着清晰的看法。

容器和嵌入式系统：采用 OpenRC 的 Alpine Linux 是基于容器的镜像的标准选择，最小化、快速、没有不必要的服务，runit 出现在每一个字节都很重要的嵌入式设备中。

你完全掌控的服务器：如果你构建了整个栈并且不依赖桌面软件，那么一个没有 systemd 的服务器运行得很好，它在现代硬件上几秒钟就能启动完成。

学习和理解：运行一个没有 systemd 的系统会教会你 systemd 实际上做了什么，你会既欣赏它解决的问题，也欣赏它增加的复杂性。

生产环境的企业服务器：使用 systemd。你的团队已经熟悉它，你的监控工具期望它存在，你的供应商支持它，与默认选择对抗，其代价超过了哲学上的满足感。

systemd 赢了。这就是 2026 年的现实！超过 90% 的 Linux 安装运行着 systemd，而且这个比例不会改变。

但关于软件设计的争论，关于 PID 1 是否应该管理 DNS、家目录和 NTP，关于紧密集成是否胜过可组合性，这个争论并没有解决。它可能永远也不会解决。

那十五个运行着没有 systemd 的发行版并不糊涂，他们对于软件应该如何构建做出了深思熟虑的选择。他们为此付出了实实在在的代价，体现在维护时间和兼容性补丁上。

我尊重双方的立场。初始化系统之争教会了我一些超越 Linux 的工程道理：最好的技术方案并不总能获胜，而获胜的方案也并非总是最好的。

尝试运行一个没有 systemd 的发行版一个星期。即使你之后回到 systemd，你也会比以前更了解你的系统。