3 ms·

"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 th

by remix2000 8mo ago

"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 8mo ago
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 8mo ago
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 8mo ago
  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 8mo ago
    Nitpicking. Of course they meant PID 1.
teddyh 8mo ago
Systemd seemd to be moving away from D-Bus and adopting varlink instead.
- direwolf20 8mo ago
  Which is like, D-Bus from Temu, if Temu was systemd. Is there anything they haven't NIH'd?
  - teddyh 8mo ago
    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.

XorNot 8mo ago

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 8mo ago

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 8mo ago
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 8mo ago
  Nitpicking. Of course they meant PID 1.

teddyh 8mo ago

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

direwolf20 8mo ago
Which is like, D-Bus from Temu, if Temu was systemd. Is there anything they haven't NIH'd?
- teddyh 8mo ago
  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.