系统与基础设施blog.darknedgy.net
systemd 十年后：历史与技术回顾
Systemd, ten years later: a historical and technical retrospective
2020 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是一篇从历史与技术角度回顾 systemd 诞生十年的长文，梳理它如何从替代 init 演变为覆盖日志、登录、服务管理等层面的系统基础设施，并检视它与 Unix 小工具传统之间的冲突。文章也涉及围绕其设计选择、推广方式和默认行为变更的长期争论。
为什么经久不衰：它把一场仍在影响 Linux 日常运维的架构之争放回历史脉络，既解释 systemd 为何被广泛采用，也保留了对它最尖锐的批评，今天读来仍有助于理解这场争论。
HN 评论精选
文章被批为局外人抱怨，忽视了开源项目需要工程投入和多方共识。
我认为这段话很好地概括了这篇文章：……这是一篇冗长、晦涩的“为什么没人征求我意见？”式抱怨，归根结底只是开源项目如何运作的问题。init 系统比乍看之下更难，而且影响操作系统、所有发布守护进程的人以及运维者，需要异常多方的认可。如果你不投入同等的工程时间，我看不出凭什么期望和投入的人拥有同等投票权。
acdha查看英文原文
I think this really sums this article up: > One thing I’m certain of is that this shift cannot emerge from dilettantes, outsiders and proverbial basement hackers. One does not unseat a platform without already being part of the patriciate that calls the shots on what gets integrated where across the largest nodes in the ecosystem. It’s a long, turgid “why wasn’t I consulted?” complaint which really just comes back to the question of how open-source projects work. An init system is harder than it might seem at first and requires buy-in from an unusually large number of parties since it affects the OS, everyone shipping daemons, and the operators. If you’re not going to invest that level of engineering time, I don’t see how it’s reasonable to expect an equal voting share with those who do.
批评 systemd 的重造质量不佳，并强改默认行为且常无退路。
我对 systemd 的不满不在于它重新发明东西，那部分可能确实不错。问题之一是不少重造做得很糟。比如日志格式：非结构化日志确有缺点，但为什么不用像 sqlite 这样经过充分测试、可靠的嵌入式数据库或序列化格式来存日志？可惜没有。另一个问题是“我比你懂”的态度。用户注销后进程还能不能跑？启动时用哪个 DNS？登录应该是什么样？这些场景里，原先被广泛认为没坏的行为被替换，常常连退路都没有。新行为应该可用，但默认应保留旧行为。难怪我不在桌面和笔记本上跑 systemd。
nine_k查看英文原文
My beef with systemd is not its reinventing things. That part may actually be good. One problem is that a number of reinventions were poorly made. E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we take some ridiculously well-tested, reliable embedded database or serialization format (like sqlite) and use it as log storage? Alas. Another problem is the "I know better" attitude. Are user processes allowed to run after logout? Which DNS to use during startup? What logging in should look like? In each such case, existing behavior which was widely considered as not broken was replaced by a different behavior, often even without an escape hatch. The new behavior(s) in such cases should be made possible, but the default should be the old behavior. No wonder I don't run systemd on my desktops / laptops.
具体案例：默认杀注销进程破坏 screen/tmux 工作流，反映傲慢文化。
作为一个有点业余的家庭系统管理员，我在楼下机器上用 screen 时遇到：systemd 默认不允许从 shell 启动的持久进程，用户注销时更愿意终止它们。这包括 screen 这类存在意义就是注销后继续运行的进程。给出的变通办法，比如改 logind.conf 里的 KillUserProcesses=no 等，至今没成功。我不知道这是 systemd 还是发行版的问题，但很像上面那条最高赞评论概括的文化：轻率破坏现有工作流，然后随口用“这才是正确方式，我不在乎传统或保护‘错误’用法”来打发批评。
ttctciyf查看英文原文
As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this: https://www.reddit.com/r/programming/comments/4ldewx/systemd_kills_screen_and_tmux_by_default_on_logout/ Namely that systemd doesn't allow persistent processes started from the shell by default, preferring to terminate them when the user logs out. This would include processes like "screen" whose entire raison d'etre is to persist after the user logs out. (Well, it has other uses, but this is the main one IMO.) The stated workarounds - fiddling with some options like "KillUserProcesses=no" in logind.conf &co. - have so far failed. I don't know whether this situation is a problem with systemd or the distro, but it seems very much a problem with the culture summarised by the top commenter in the above thread, of (paraphrasing) glibly breaking existing workflows then casually brushing away criticism with arguments often boiling down to: "this is the right way, I don't care about tradition or protecting 'incorrect' usage."
抵制核心是推动方式和硬依赖政治，而非单纯技术好恶。
我年纪够大，记得 systemd 的问题与其说是技术问题，不如说是政治问题。人们不喜欢 systemd 开发者推动社区采用它的方式，尤其是要求第三方开发者把 systemd 变成硬依赖。不幸的是今天人们不记得这一点，以为用户抵制 systemd 只是因为他们不喜欢 systemd。
akagusu查看英文原文
I am old enough to remember that problems with systemd were less technical and more political. People didn't like the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency. Unfortunately,people don't remember this today, and think users resisted to systemd adoption only because they didn't like systemd.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选