系统与基础设施0pointer.net
重新审视我们如何组装 Linux 系统
Revisiting How We Put Together Linux Systems
2014 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
systemd 作者 Lennart Poettering 在这篇提案文中重新审视 Linux 系统如何组装：他指出各发行版打包和依赖关系碎片化，使上游软件难以测试、分发，并提出基于 btrfs 子卷、文件系统命名空间/容器等机制，让系统镜像、应用与依赖更独立地分层和交付。文章立场鲜明，引发了关于是否值得再引入一层间接、是否真需要最新版本，以及发行版打包价值的长期争论。
为什么经久不衰：它直面 Linux 发行版碎片化与打包/依赖管理的核心矛盾，且其中关于隔离、镜像和上游交付的设想与后来的容器化、不可变系统潮流相呼应，因此多年后仍值得回看。
HN 评论精选
认为文章只解决 systemd 的测试难题，真正矛盾是发行版碎片化导致的库依赖与兼容性，并讨论符号版本化和静态链接的取舍。
这篇文章完全跑题了：他基本是在抱怨无法在所有发行版上测试 systemd，因为每个发行版做法都不同；解决办法是虚拟化发行版，但这只解决他的问题。真正的问题是发行版碎片化让 Linux 的共享库链接体验对普通用户很不方便；发行版擅长打包、提供一键安装，却以兼容性为代价造成锁定。作为上游开发者，我认为动态链接器按符号匹配库的机制可以扩展到图标、locale 等支持文件，而符号版本化通常由上游库开发者负责；静态链接是最简单的匹配方案，却不是我们真正想要的，因为还想用安全修复或更快的实现替换符号。
tbingmann查看英文原文
The article is completely by side the point. He's basically ranting about how they can't test systemd on all distros, because every distro does things differently. How to fix it? Virtualize distros, yay. That may fix your problem, but no one else's. The real point is that, due to distro fragmentation, Linux gives the casual user an inconvenient shared library linkage experience. At the same time the distros are really good as packaging software, which gives us the "one-click install" experience we're so use to. But they do so, at the price of compatibility, so we have the current distro lock-in situation. Anyway, as an upstream software developer, I see the medal from the side of library linkage: when my program starts, the dynamic linker resolves this big list of symbols that my program contains and finds me matching libraries. You can extend this paradigm to icons, locale, and other support files as well. So who tells the dynamic linker which symbols to match? Well, the contents of the shared libraries, and these already contain versioned symbols (e.g. this memcpy@1.0 does this, memcpy@1.1 doesnt do that anymore). The easiest solution to the matching problem is static linking. But that's not what we really want, because we may actually want to replace symbols with better versions (due to security fixes, faster implementations, super-set of features, etc). And who versions symbols? Well, usually the upstream developers of the important libraries do. And they do that somewhat remarkably well already, but it could be better. If your program uses an upstream that doesnt version things, well, bad choice, static linking is probably the best solution here. So what I would propose, is to move the problem down to a linkage problem, with better consensus between binary creators and upstream authors on how to version symbols. And if my system currently doesnt have a matching symbol installed? Just download it from the distro's well-versioned repositories, maybe not the whole gtk+ library, but a diff of it to another version. We would then in the end not have a package installer, but a fetcher-of-missing-versioned-symbols-for-a-binary installer. But this model is pretty far fetched, since the current method of compiling code into monolithic shared libraries is much simpler. On the other hand, the linux dynamic linker is already very intelligent, maybe it's time for the large distros to cooperate on this level.
质疑“必须随时用最新版”的前提，认为旧版本和成熟期通常够用，例外可手动编译解决。
这类提案隐藏着假设：某个任意程序发布当天就能安装最新版并直接可用，既是人们真正需要的，也是可解决的问题，而且不会在可用性、认知、第三方集成或安全上带来重大权衡。我用了二十多年 Linux：最新版 Foo 几乎从来不是必需的，用一两年前甚至五年前的运行环境通常也能把活干完；让软件有时间成熟反而是好事。例外情况可以自己编译（也许静态编译），放进 /opt 的 tarball，再做符号链接或改 PATH，然后继续解决真正的问题。
otterley查看英文原文
Hidden in these sorts of proposals is an underlying assumption that being able to install the newest version of some arbitrary program the day it's released and have it Just Work is something that (a) people actually need, and (b) this is a solvable problem that doesn't involve significant tradeoffs in usability, cognition, third-party integration (which is more important in server environments than people realize), or security. I've been working with Linux systems for over 20 years now. Despite the grumblings of wet-behind-the-ears programmers to the contrary, having the newest version of package Foo is almost never necessary and one can generally get things done on a 1, 2, even 5 year old version of some operating environment. In fact, I'd argue that allowing time for software to mature is a Good Thing -- in the meantime, bugs get fixed, regressions in libraries are reverted, semantic versioning violations are repaired, etc, which reduces the amount of needless headache you have to deal with when you just want to Get Work Done. Of course there are exceptions (I would never ask anyone to write server code under Ruby MRI pre-2.1), but those conditions are readily dealt with: you compile what you need (perhaps statically), put it in a tarball in /opt, make some symlinks to /usr/local (or update your PATH and other environment variables) and move on to the next actual problem. Yes, standards and "old packages" can be annoying if you're used to a greater level of control on your personal equipment. But fences and constraints can be good: they keep your eye on the problem you're trying to solve; they keep the goalposts from moving; they minimize combinatorial compatibility problems; and they allow people to leverage their zones of expertise at the appropriate layers.
批评提案复杂且制造新的不兼容，强调系统组件应由发行版审查，标准镜像可自行可复现地构建。
我通常尽量不公然消极，但这很愚蠢。大多数用户不在乎新版本多快到手，当前发行版打包系统就挺好；Poettering 总能搞出没必要的复杂东西。最搞笑的是他拿 systemd 当例子——那恰恰是我希望很少变动、并由熟悉我所用发行版的人审查和集成的软件，认为我会运行上游打包的 systemd 很荒谬。提议的打包系统只是又一个与其他系统不兼容的系统；想要标准镜像，从所选发行版构建、卸载 dpkg/rpm、做磁盘镜像并自动化到可复现即可。
kelnos查看英文原文
I usually try not to be blatantly negative, but this is just stupid. Most users do not care how quickly new versions of software get to them. The current distro packaging system is just fine. Leave it to Poettering to come up with something complicated for no good reason. The funniest part is that he's using systemd as an example. That's exactly the kind of software that I want to change very rarely, and I want those changes to be vetted and integrated by someone intimately familiar with the distro I'm running. The idea that I'd run an upstream-packaged version of something like systemd is absurd. The proposed packaging system is just another system incompatible with all the others out there. Want a standardized system image? Build one from your distro of choice (guess what: your users don't care about that either), uninstall dpkg/rpm/whatever, make a disk image. Automate the process so it's reproducible. Done.
反驳文章对专有软件和库依赖困境的描述，认为第三方仓库与静态链接已能应对，核心问题只是发行版互不兼容。
我认为他在“上游项目”下列出的许多现状要么错误要么夸大。比如声称 Linux 打包方案不适用于专有闭源软件就完全不对：厂商可以自己打包放进第三方仓库，deb/apt 和 rpm/yum 早就有这种能力，很多用户正是这样获取发行版不收或更新滞后的软件，还能用现有系统保持更新。主要问题确实是多个发行版互不兼容，但像 Google 对 Chrome/Earth 那样只针对 Fedora 和 Debian/Ubuntu/Mint 并不难；库依赖不同也可以靠静态链接解决。
Arizhel查看英文原文
I think a lot of things he listed in how things currently are (under "Upstream Projects") are either wrong or overblown. For instance, the claim that the Linux packaging scheme doesn't work for proprietary, closed-source software. That's just plain wrong. No, proprietary software makers can't rely on distribution maintainers to package their stuff, however there is nothing preventing them from packaging it themselves, and making it available in a 3rd-party repository. Both deb/apt and rpm/yum have had this facility for ages, and it's how a lot of Linux users get either software not supported by the distro (like media stuff that Fedora refuses to include), or software that the distro drags its feet on updating. Proprietary vendors can easily use the same system to make their software available to users, and to allow the software to be easily kept up-to-date using the existing system instead of running a separate "update checker" constantly in the background like is common on Windows systems. The main problem is that there's more than one Linux distro out there, and they're not compatible with each other. But as Google does already with Google Earth and Chrome, for instance, it's not that hard to just target RH/Fedora and Debian/Ubuntu/Mint. Another important point is libraries. They complain about the library dependencies all being different on different distros. But there's nothing stopping proprietary vendors from statically-linking everything, which is how they usually do it anyway, both on Linux and on Windows. Sure, it bloats up the binary, but it avoids a lot of library version and dependency problems, and with modern HD and RAM sizes, it's not that much of an issue. It seems to me that they're proposing an enormously complicated and bloated system here in an effort to increase usage of desktop Linux, but this isn't going to help.
历次讨论
同类还值得读
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编辑精选