Our entire software empire balanced on the systemd everyone loves to hate
Description
Cartoon-style drawing: on the left, a huge stack of grey rectangular blocks and thin pillars forms skyscraper-like towers. Above it, bold text reads “Literally our computerized world,” with a bracket indicating the whole towering structure. Beneath this massive stack is a narrow grey platform. Far below, a tiny blue whale supports three brown turtles, which in turn carry three small grey elephants; a curved arrow points from the whale toward the base of the skyscraper, accompanied by the caption “This systemd that everyone hates.” The humor highlights how the vast, intricate layers of modern software depend on a single low-level init subsystem (systemd) that many engineers criticize, illustrating hidden complexity, dependency risk, and technical debt in contemporary Linux infrastructure
Comments
36Comment deleted
We’ve got multi-region self-healing K8s, four layers of service mesh, and a weekly chaos-monkey drill - yet the whole empire still hinges on one 600-k-line PID 1 written by a guy whose vacation isn’t in the runbook
After 15 years in the industry, I've accepted that systemd is like that one microservice that accidentally became a distributed monolith - it started as an init system and now it's your network manager, DNS resolver, boot loader, and probably your therapist if you enable the right unit file
Ah yes, systemd - the architectural equivalent of discovering your entire microservices empire is actually running on a single whale in the ocean. Everyone complains about its monolithic design and scope creep, yet somehow it's become the load-bearing mammal of the Linux ecosystem. The real joke? We spent decades arguing about init systems, and now we're all riding the same whale, pretending we have better alternatives while secretly knowing that migrating away would require rewriting half the infrastructure documentation ever written. At least it's not running in a Docker container... or is it?
We love to hate systemd, but the whole cloud is balanced on its PID 1 - when it hiccups, Kubernetes doesn’t self-heal so much as self-host a postmortem
We fawn over the K8s-orchestrated elephant-turtle-whale zoo scaling to infinity, but one peek at that stable COBOL fish triggers migration PTSD
Five nines, multi‑cloud, service mesh - then one bad systemd unit hangs boot; turns out our global architecture has a single critical box labeled PID 1
fixed Comment deleted
based Comment deleted
I mean, not really Comment deleted
Containers are easily the best thing since sliced bread package managers in SE Comment deleted
Docker as a tool is amazing, the only problem is how damn inefficient and ugly it is at times Comment deleted
I literally had to reimplement a slice of Podman for my usecase because even Podman couldn't start a thousand hello-world containers in parallel without consuming 16 GB of RAM Comment deleted
But why. That is decidedly not what containers are for. Comment deleted
I needed to start lots of isolated environments for a CTF challenge Comment deleted
hate docker luv vagrant simple as Comment deleted
Layers goes brrrr Comment deleted
i dont hate docker because i dont even know what it really is Comment deleted
Who hates systemd? Comment deleted
i do Comment deleted
Why? Comment deleted
People who want to shutdown systems properly Comment deleted
Can't you build your kernel without it? Comment deleted
Can't you disable it? Comment deleted
Didn't have any problem shutting down my system with systemd lol Comment deleted
for me 50% chance it waits for termination of a process FOREVER Comment deleted
That’s more of a most desktop Linux programs don’t close properly when asked to problem than a systemd problem lol Comment deleted
I do. I'd prefer init.d. Comment deleted
sysvinit FTW! 💪 Comment deleted
A thousand is a ridiculous number though. It's not really particularly reasonable to expect that to be less than 16GB Comment deleted
Well, those guys think otherwise. https://xkcd.com/619 Comment deleted
I mean… Linux is used by supercomputers, there's a genuine need for a feature like that Comment deleted
I am not very familiar with supercomputer design, so may be mistaken, but always thought that such systems are formed by a large number of regular nodes with 1 to 16 processors in each, and fast interconnect between nodes, but not that fast for external resources to be treated in the same way that local processors and memory is controlled by OS, — that is, they are just regular [multiprocessor] nodes connected in a cluster, much like in enthusiast grid computing but very tighly coupled. Comment deleted
Aaa, yes, Lennart "fucking" Poettering Comment deleted
Docker and 3 postgresql instances Comment deleted
It can’t predict when or if they’re gonna close at all Comment deleted
But I believe you can just configure it to kill them outright like most other inits do, instead of asking them nicely to close Comment deleted