一台 ThinkPad X13s Snapdragon，跑 Debian Testing，把 systemd 从系统里移掉，换成 OpenRC。
这事听起来像一句老派 Linux 玩家的宣言，但原文记录出来后，最有价值的反而不是立场，而是故障：移除的是 essential package，系统一度无法正常启动，作者进 recovery mode 后才重新安装 OpenRC，把机器救回来。
我更在意的是边界。
这次实验说明，Debian 上从 systemd 切到 OpenRC 仍然可操作。但它不是一个安全开关，更不是“OpenRC 已经可以全面替代 systemd”的证据。它适合愿意自己修启动链路的人，不适合普通桌面用户拿来当教程。
动机不是反 systemd，而是不想把默认当唯一
作者 Daniel Cordova 在 2026 年 6 月 29 日发布博客，记录了这次迁移。他并没有把自己写成反 systemd 阵营的人。
他的态度更接近很多老 Linux 用户：systemd 对多数场景有效，也确实解决了大量发行版集成问题。但它不断吸收新职责，会让一部分人不舒服。
原文提到的触发点包括 systemd 对 age verification 相关可选字段的集成争议，以及 systemd 261 中出现的 systemd-sysinstall 等新组件。这里需要压住判断强度：这些只能解释作者为什么想试 OpenRC，不能推出 Debian 或 Linux 社区正在集体转向反 systemd。
现实仍很清楚。Debian、Fedora、Ubuntu、Arch 等主流发行版都默认使用 systemd。服务管理、日志、用户会话、设备管理、桌面登录，很多链路已经围着它搭好。
所以这次实验的意义不是“默认路线错了”。它说明的是：默认路线之外，还剩一条小路。但这条路窄，坑也真。
真正危险的命令，是移除 essential package
迁移的关键动作不温和。
作者发现 apt-get 不能直接卸载 systemd，apt 会提示 systemd 属于 essential package。最后用到的命令是：apt purge --allow-remove-essential systemd。
同时还需要安装：openrc sysvinit-core。
这一步不是普通换包。essential package 被移除后，只要依赖解析、中途断电、网络失败或 init 替换没接上，系统就可能进不了正常启动流程。
原文里也确实出事了。机器没有正常启动。作者进入 recovery mode，按 Ctrl-D 继续修复，再连上 Wi-Fi，重新安装 openrc sysvinit-core，才把启动链路补回来。
这比“成功替换”更值得记住。
| 路线 | systemd 默认路线 | OpenRC 实验路线 | 对用户的实际含义 |
|---|---|---|---|
| 启动系统 | 发行版默认维护 | 需要替换 init | 出问题要会进恢复模式 |
| 包管理风险 | 常规升级路径 | 涉及 --allow-remove-essential | 不适合在工作机直接试 |
| 服务迁移 | 多数包已有 systemd unit | 可能要写 /etc/init.d/ 脚本 | 需要懂服务启动顺序 |
| 桌面体验 | 默认集成更完整 | 音频、会话、电源可能要补 | 笔记本比服务器更容易踩坑 |
对 Debian/Linux 进阶用户，比较现实的做法是：只在备用机或测试盘上试，先准备可启动 U 盘和网络方案，确认自己能进 recovery mode，再动 apt purge --allow-remove-essential systemd 这种命令。
对团队或长期维护机器的人，动作应更保守。不要因为一篇个人实验就安排迁移。更合理的是延后迁移，把它当成兼容性调研：哪些内部脚本依赖 systemd unit，哪些服务没有 OpenRC 脚本，哪些机器一旦启动失败会影响业务。
能进系统不等于迁移完成
ThinkPad X13s 让问题更复杂。
这台机器采用 Qualcomm Snapdragon 平台，本来就比常见 x86 笔记本更依赖特定内核、固件和用户态服务。换 init 后，麻烦不只在 PID 1，还会落到电池、音频、远程处理器和桌面会话上。
作者提到，电池状态问题与此前遇到的内核回归有关。他把原来的 systemd oneshot 服务改成 /etc/init.d/ 脚本，用来启动 Qualcomm remoteproc 相关组件，电池状态恢复工作。
音频还不能算解决。
原文只说后面再测试，并推测可能与 PipeWire、WirePlumber 的启动方式有关，或者需要登录后再拉起相关服务。这里不能写成 OpenRC 已经完整适配 X13s。眼下能确认的是：基础启动可用，部分硬件服务还要逐项补账。
OpenRC 本身并不是冷门玩具。Gentoo、Alpine Linux 等发行版长期使用它。它的优点是简单、可读、边界清楚。
systemd 的优势则是统一、集成、默认路径成熟。争议也来自这里：它把复杂性集中起来，管理员少管很多碎片；OpenRC 把边界留得更清楚，但管理员要自己接住更多细节。
这不是谁天然更高级的问题。是你愿不愿意把时间花在维护启动和服务脚本上。
接下来最该看的，也不是机器能不能开机。更具体的观察点有几项：
- Debian Testing 后续升级时，依赖会不会把 systemd 相关包拉回来，或造成新的冲突。
- 挂起、恢复、电池状态和硬件热插拔能不能稳定。
- PipeWire、WirePlumber、桌面登录后的音频会话能不能正常启动。
- 作者是否会把同样做法迁移到工作笔记本；原文目前还没有这样做。
这个边界很关键。
作者是在 home hacking laptop 上测试，不是工作机迁移报告。它证明“能做”，不证明“该做”。
对普通桌面用户，最稳的判断仍是观望。对熟悉 Debian、SysV/OpenRC、恢复模式和服务脚本的人，这篇记录有参考价值，但更像风险清单，不像安装指南。
Linux 的选择权还在。只是选择权从来不是免费菜单。你可以离开默认路线，但要带上备份、时间和修机器的能力。