The Tragedy of Systemd


Well-Known Member

Reaction score: 179
Messages: 327

As far as why journalctl has to be part of the init system is question worth exploring.

Or is it? Is systemd purely an init system? My understanding was that it was a sub-system that (necessarily) includes init functionality.
Similarish to the way that the Linux project revolves around creating and maintaining a kernel, whereas the FreeBSD project revolves around creating and maintaining an Operating system that (necessarily) includes a kernel.


Aspiring Daemon

Reaction score: 220
Messages: 527

Systemd does indeed solve a real-world problem, namely that the whole mess of how to start processes and services had become unmanageable complex.

The heart of the issue, I think.

Linux init and rc scripts are simple to read, open, transparent, and easy to trace. Their software tools approach makes for easy component management. However they are not easy to write well.

I find systemd complex, dense, and opaque. Systemd offers more, a lot more, but at a big price. Its reach is vast (and expanding). It feels like a "Windows" style solution. Comprehensive, but daunting.

I really enjoyed the video. And the message I took away (and have always thought) is that "the whole mess of how to start processes and services" is still looking for a good solution.

However you are completely correct about Linux (increasingly with systemd) dominating the commercial markets. Automated deployments and containerisation are just accelerating that. Everything else if falling by the wayside.

So I'm pretty sure that systemd is already the solution in the commercial world. C'est la vie. It's what the proprietary vendors used to call "adding value"...


Aspiring Daemon

Reaction score: 173
Messages: 651

it's the ethernal topic: monolithic vs. modular, script vs binary.
Systemd has some nice benefits like faster boot in some scenarios. But in some other scenarios it's simply not flexible enough. If you put constraints on stuff, inevitably you'll break some use cases that need more flexibility. Otherwise we would simply put all kernel, userland and ports in a single overbloated binary and call it a day. That's what systemd tries to do.