Comment by mickeyp | Hacker News Reader

Comment by mickeyp | Hacker News Reader

Parent Full thread

All this lather about doing it the UNIX way, whilst neglecting to point out that the old tooling was far worse. "Do one thing well" implies it was done well to begin with.

DNS: Can you from memory recite how name lookups work on Linux? Ever had t otrack down problems with non-standard setups? `resolvectl` is not perfect, but it does let you control all of this stuff in one place, and with a nice, orderly view of what does what.

Init system: ever written the old sysV ones from scratch? Sure they're just shell script, but did you remember to make yours re-entrant? What about forking or master-slave processes? Hope you got your pid checking code just right...

Containers: Docker is quite robust nowadays but it's not like it follows the 'UNIX philosophy' either. And systemd/nspawn at least lets you do namespacing and cgroups reasonably well and in a straightforward way...

Mounts, etc.: let's not get into fstab and its idiosyncrasies.

Logging: let's hope you set up logrotate properly or you're in for a surprise.

And on it goes.

Systemd is not perfect. But what it replaces was god-awful and far worse.

> DNS: Can you from memory recite how name lookups work on Linux

Yes, I can, and I use systemd only because it's the default on debian, I have no reason to try devuan yet.

> ever written the old sysV ones from scratch?

Many, many times, and I was only an enthusiast/user, not a sysadmin.

> did you remember to make yours re-entrant?

Dealing with PID files was only mildly annoying. Init scripts were very boilerplate-y, so I wouldn't forget anything after my copy-paste-edit-delete unnecessary parts cycle. In a single afternoon, one could bash out an CLI init-script generator that uses jinja2 templates and interactively asking <10 questions about the service.

> Systemd is not perfect. But what it replaces was god-awful and far worse.

Init systems shouldn't have anything to do with managing container lifecycles beyond managing the container-runner service using the usual unix interface (signals). Call me a purist, but system services shouldn't be containerized.

An init system shouldn't be managing DNS or logging either, those should be standalone components. If they are problematic, there should be composable, domain-specific tools that solve them, instead of smooshing everything into systemd.

SystemD wasn't the only possible way to solve those logging, DNS, or security policy problems, and I'm glad other PID 1 projects that focus on being init systems are thriving.

So one could agree that something should be done, in each of these cases. But that doesn't imply that the thing to be done should have been systemd, or even systemd-shaped. But no, it has borged the lot.

Reply on news.ycombinator.com