系统与基础设施vitavonni.de
容器时代里系统管理员的悲惨处境
The sad state of sysadmin in the age of containers
2015 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 2015 年的博文批评容器时代的系统管理现状：软件依赖越来越混乱，从源码构建（如 Hadoop）几乎不可能，而 curl | sudo bash 式的安装脚本和来路不明的预构建镜像正在取代严谨的部署实践。作者怀念老派系统管理员对构建、审计和安全性的把控，担忧 DevOps 文化正在把不可信的网络资源引入生产环境。
为什么经久不衰：它精准预言了供应链安全和 DevOps 部署草率的问题，这些问题至今仍在恶化，多年后重登首页说明其批评依然切中要害。
HN 评论精选
curl|bash 安装方式令人不安，但基本系统管理其实比学习新部署工具更简单
这也让我很困扰。连添加软件源这么简单的事，现在都被用 curl | sudo bash 式的安装方式"改进"了。不过用 make 从源码安装过去和现在都是一团糟，通常导致软件过时、手动追踪版本。很多人对做基本的 Linux 系统管理有种奇怪的抵触，其实这些事真的很简单，往往比搞懂另一套部署系统还容易。
blfr查看英文原文
This bothers me as well. Even tasks as simple as adding a repository are now being "improved" with a curl | sudo bash style setup[1]. However, installing from source with make was (and remains) a mess. It may work if you're dedicated to maintaining one application and (part of) its stack. But even then it usually leads to out of date software and tracking versions by hand. Many people have this weird aversion to doing basic sysadmin stuff with Linux. What makes it weird is that it's really simple. Often easier than figuring out another deploy system. (The neckbeard in me blames the popularity of OSX on dev machines.) [1] https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories
部署草率不是工具的错，而是系统管理员没有尽到坚持规范的责任
我同意很多便捷的部署方式草率得令人尴尬，但坚持生产部署的严谨性是系统管理员的责任。没人告诉你怎么构建 Hadoop？那就自己搞清楚。随机下载 Docker 容器？那就用经过审查的本地镜像仓库。我甚至不允许厂商安装程序在生产系统上运行——我写了个脚本在 VM 里运行安装程序，再把结果重新打包成我能掌控的形式。如果系统管理员无法坚持良好的部署实践，那是组织或其沟通能力的失败。
skywhopper查看英文原文
I agree that many of these convenient setups are embarrassingly sloppy, but it's the sysadmin's responsibility to insist on production deployments being far more rigorous. No one can tell you how to build hadoop? Well, figure it out. Random Docker containers being downloaded? Use a local Docker repo with vetted containers and Dockerfiles only. I don't even allow vendor installers to run on my production systems. My employer buys some software that is distributed as binary installers. So I've written a script that will run that installer in a VM, and repackage the resulting files into something I'm comfortable working with to deploy to production. If a sysadmin is unable to insist on good deployment practices, it's a failure of the company or organization or of his own communication skills. If a sysadmin allows sloppy developer-created deployments and doesn't make constant noise about it, then they aren't doing their job properly.
大厂内部基础设施并不用流行工具，老派系统工程师只是转到了幕后
前 Amazon 员工在此。那些脾气暴躁的老派系统工程师并没有消失：我们被 Google、Amazon 等公司雇去构建大规模基础设施……有时再作为服务卖回给你。信不信由你，大部分底层基础设施并不运行在当年流行的技术上，差得远，这就是它能正常工作的原因。现代 DevOps 那些每月破坏向后兼容的百万种工具，有时成了午餐时的笑柄。
ex_amazon_sde查看英文原文
Ex Amazon here. Most grumpy system engineers did not disappear: we got hired by Google/Amazon/etc to build large-scale infrastructure... and sometimes sell it back to you as a service. Believe me or not, most of the underlying infra does not run on the popular technology of the year. Far, far from it. That's why it works. Modern devops, with its million tools that break backward compatibility every month sometimes becomes the running joke at lunch.
真正的问题是引入不可信外部依赖的"先上线再说"文化，而非具体工具
这确实是一篇掩盖了核心问题的 rant：核心是引入了不可信、不可靠的网络资源，常常藏在一串依赖里。我常看到有人把"去某个随机第三方拉取东西"这种疯狂操作塞进容器的启动流程等重要位置。这是技术债，而且往往不会被清除——等你扩容时，所有新实例都在同一个出问题的外部资源上超时，在最糟糕的时刻爆炸。具体工具不是问题，问题在于"先上线、后果以后再说"的文化。
mr_tristan查看英文原文
This is definitely a rant that obscures the underlying point: the introduction of _untrusted_ or _unreliable_ network resources, frequently hidden in a string of dependencies. I'm baffled how often I see an someone throw this sort of craziness - "go fetch this thing from some random third party" - into very important places, such as the startup procedures of a container. It's something I see in a culture of the two person startup just trying to get something out the door. It's definitely "technical debt", and frequently, it won't get removed. Thus, you try to scale up to meet load, and all these new instances go time out on the same external resource that's randomly having problems... boom! At the worst possible time. Never mind the potential huge security gaps. But the specific _tools_ aren't the issue here. It's the culture of "ship something now we'll deal with fallout later". A lot of people start using Docker and won't ever look at the Dockerfile, or, will add a Maven dependency and won't even check licenses or security updates for _any_ of the transient dependencies. Cloud technologies and containerization make everyone just think "we can do things so fast now" and never, ever pay attention to details that can come back to bite you. On the flip side, it's a good time to be in cybersecurity; because this cultural problem will never, ever, get solved. :)
历次讨论
同类还值得读
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编辑精选