[remix2000]

"Tricycle – Car Without Engine"

Honestly though, the argument against systemd is that it moves too much stuff into init, but I don't think it does enough of that, it's still extremely conservative, like, SD-DBus should be using binder x-port IMO.

[XorNot]

The thing is systemd really doesn't: the things people claim "shouldn't be in an init system" aren't - but there are systemd branded versions of a lot of basic facilities because you generally need something like them in a usable system.

And a lot of those utilities are just straight better then the alternatives, or at least make a decent practicality vs correctness trade off for desktop Linux.

systemd-cryptenroll for example is just straight up much easier to use for most applications of FDE, unless you're really doing network unlocking with something like Clevis.

[account42]

No, one complaint (out of many) against SystemD is that it moves too much complexity into PID 0 which is a very special process on Linux that must not crash ever or the whole system goes down with it. The init system is one thing that SystemD insists on running under PID 0 even though it could be designed otherwise.

[remix2000]

But PID 0 on Linux is the idle task…? Init is (usually) PID 1, PID 0 kinda just means that nothing is running on a given CPU (with caveats), also killing 0 has special meaning because well it's not a real process…

[direwolf20]

Nitpicking. Of course they meant PID 1.

[teddyh]

Systemd seemd to be moving away from D-Bus and adopting varlink instead.

[direwolf20]

Which is like, D-Bus from Temu, if Temu was systemd. Is there anything they haven't NIH'd?

[teddyh]

Varlink is everything that the usual systemd detractors should want; no binary formats, simpler mechanisms, based on stdout/stdin of processes.

Also, systemd did not create varlink, nor did they create D-Bus. They simply adopted them as the most suitable and established methods for IPC at the time.