在 Debian 中用 OpenRC 替换 Systemd：一次关于自由与控制的实验

背景

Systemd 作为现代 Linux 发行版的事实标准初始化系统（init system），长期以来一直伴随着争议。支持者认为它极大地简化了服务管理、日志记录和系统引导过程；而反对者则批评它违背了 Unix 哲学中的“单一职责”和“KISS”（Keep It Simple, Stupid）原则，且过度集中了系统控制权。

作者是一名长期 Debian 用户，自 Systemd 早期阶段便开始使用。尽管承认 Systemd 在大多数场景下运行良好，但他对 Systemd 不断扩张的边界感到不安。这种不安主要源于两点：一是 Systemd 开始接管原本属于其他独立项目的职责（如网络管理、日志记录、甚至系统安装程序）；二是其某些决策引发了关于隐私和审查的伦理争议。

近期，随着年龄验证法案（age verification law）在部分国家/地区的推进，Systemd 被曝出集成了相关的验证字段，这成为了作者心理上的“最后一根稻草”。与此同时，Systemd 官方推出的 systemd-sysinstall 系统安装程序进一步加剧了作者对“初始化系统”角色越界的担忧。出于好奇与对系统控制权的回归渴望，作者决定在其运行 Debian Testing 的 ThinkPad X13s（Snapdragon 架构）上，尝试用轻量级的 OpenRC 替换 Systemd。

核心内容

动机：从技术哲学到伦理争议

作者的替换动机并非单纯的技术偏好，而是混合了对技术架构的质疑和对政治/伦理介入的反感。

1. 职责边界的模糊：Systemd 逐渐从单纯的进程管理器演变为一个庞大的系统平台，接管了网络、日志、挂载点管理等功能。作者指出，虽然其他项目也有类似趋势，但 Systemd 作为 PID 1 的核心地位使其扩张更具强制性。
2. 年龄验证法案的争议：当某些地区试图立法强制年龄验证时，作者原本预期 Linux 社区会像对抗其他不合理法规一样进行抵制。然而，他发现 Systemd 甚至在法案未正式通过前就集成了相关功能。这种“先斩后奏”或“主动迎合”的做法让作者感到愤怒，尽管该功能仅为可选字段，且开发者因此遭受了大量非议，但作者认为这种集成本身是不恰当的。
3. 系统安装程序的整合：Systemd 团队推出的 systemd-sysinstall 将系统安装这一独立领域也纳入其生态。作者认为，从 PID 1 到系统安装程序，这超出了“初始化系统”的合理职责范围，体现了 Systemd 团队某种程度的“控制欲”。

实施过程：在 Debian Testing 上的挑战

在 ARM64 架构（Snapdragon）的 ThinkPad X13s 上，将 Systemd 替换为 OpenRC 并非简单的 apt install 操作，而是充满风险的系统级重构。

主要挑战

1. Essential Package 保护机制：Debian 的包管理器 apt 默认禁止卸载标记为 essential 的核心包。Systemd 被标记为此类，直接卸载会报错。
2. 强制卸载命令：必须使用 --allow-remove-essential 参数来绕过保护机制。
3. 原子性操作风险：如果先卸载 Systemd 再安装 OpenRC，可能导致系统在重启时因缺少初始化系统而无法引导。因此，作者采用了链式命令，确保卸载与安装在同一会话中完成。

关键命令

# 卸载 Systemd 并安装 OpenRC 及其依赖
sudo apt purge --allow-remove-essential systemd && sudo apt install openrc sysvinit-core

遇到的问题与解决

1. 引导失败：首次执行后，系统无法正常启动。进入恢复模式（Recovery Mode）并按 Ctrl-D 继续后，发现 OpenRC 并未正确安装或被意外移除。作者重新连接 Wi-Fi，再次执行安装命令修复了此问题。
2. 硬件功能缺失：
   • 电池状态：由于 Debian Testing 内核回归问题，电池状态失效。作者将原有的 Systemd 服务转换为 Shell 脚本，并放置在 /etc/init.d/ 目录下，通过 OpenRC 启动。
   • 音频问题：音频功能（涉及 PipeWire 和 WirePlumber）未正常工作，作者计划后续通过配置登录会话或特定服务来解决。

服务迁移示例：从 Systemd 到 OpenRC

作者提供了一个具体的迁移案例，展示了如何为 Qualcomm 远程处理器（SLPI/ADSP/CDSP）启动服务进行转换。

Systemd 服务单元 (systemd.service):

[Unit]
Description=Start Qualcomm remoteprocs (SLPI/ADSP/CDSP)
DefaultDependencies=no
After=initrd-root-fs.target local-fs.target
Before=sysinit.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'echo start > /sys/class/remoteproc/remoteproc0/state; echo start > /sys/class/remoteproc/remoteproc1/state; echo start > /sys/class/remoteproc/remoteproc2/state'

[Install]
WantedBy=sysinit.target

OpenRC 脚本 (/etc/init.d/remoteproc):

#!/bin/sh
echo start > /sys/class/remoteproc/remoteproc0/state;
echo start > /sys/class/remoteproc/remoteproc1/state;
echo start > /sys/class/remoteproc/remoteproc2/state;

注：作者承认目前脚本较为简陋，后续需要将其转换为符合 OpenRC 规范的标准脚本。

未来计划

目前 OpenRC 在作者的“家庭黑客笔记本”上运行良好。作者计划继续测试数天至数周，如果体验稳定，他将迁移其工作笔记本（同样运行 Debian Testing 并共享配置）。作者强调，尽管替换初始化系统存在风险和怪癖，但这体现了 Unix 的自由精神——用户有权选择最适合自己且能正常工作的工具。

关键要点

• 动机多元化：替换 Systemd 的动机不仅包括技术上的 KISS 原则偏好，还包括对 Systemd 过度扩张职责（如网络、日志、安装程序）的不满，以及对 Systemd 在政治/伦理争议（如年龄验证法案）中立场的抵触。
• 高风险操作：在 Debian 中卸载 Systemd 需要强制绕过 essential 包保护机制（--allow-remove-essential），且必须确保 OpenRC 同步安装，否则会导致系统无法引导。
• 硬件兼容性挑战：在 ARM64 架构（Snapdragon）设备上，替换 init system 可能遇到内核回归、电池状态、音频子系统（PipeWire/WirePlumber）等特定硬件驱动或服务兼容性问题。
• 服务迁移复杂性：Systemd 的服务单元文件（.service）不能直接用于 OpenRC，需要手动重写为 Shell 脚本或 OpenRC 特定的配置格式，尤其是涉及复杂依赖关系和启动顺序的服务。
• Unix 自由精神的体现：作者认为，能够自由选择并替换核心系统组件，是 Linux/Unix 哲学中“用户控制权”的核心体现，即使这意味着要承担更多的维护成本和潜在风险。

意义与影响

1. 对 Systemd 垄断地位的反思

Systemd 已成为绝大多数主流 Linux 发行版（如 Debian、Ubuntu、Fedora、Arch 等）的默认初始化系统。此次实验表明，尽管 Systemd 功能强大，但其“大一统”的架构设计引发了部分资深用户和开发者的强烈抵触。这种抵触不仅源于技术分歧，更源于对系统控制权集中化的担忧。

2. OpenRC 的生存空间与适用场景

OpenRC 作为 Gentoo 的默认 init 系统，以其轻量、灵活和遵循传统 Unix 哲学著称。此次成功在 Debian 上运行 OpenRC，证明了其在现代硬件（包括 ARM64）上的可行性。对于追求极简主义、不喜欢黑盒操作或希望完全掌控系统启动流程的用户来说，OpenRC 依然是一个 viable（可行）的替代方案。

3.