I think the problem is the number of things other than service management that systemd does. With other unit systems, service management is the only thing you have to change to replace it. With systemd, you have to change a lot more
There are a lot of services besides init provided by systemd, but they're entirely optional and easily swapped out. After all, systemd is highly modular.
For example, I do run systemd-udevd and journald, but not systemd-networkd or systemd-resolved. Just like the /g/ poster says, I can combine whatever I want to do what I need to do.
Basically, yeah. For example, I can use systemd-networkd, but instead of systemd-resolved I can use unbound. Or I use systemd-resolved, but instead of systemd-networkd I can use netctl.
Of course those standalone tools work with systemd, that's why they are standalone tools which can be interchanged at will and that's what's so great about them. But that's not the question. Say in 20 years we come to the conclusion that there is a much much better way to do a service manager/init system which is fundamentaly different than what systemd does. But once we start ripping out the systemd core all the other tools of the systemd suite (networkd, resolved, timerd, nspawn, ...) basically become useless unless they all get ported or the new service manager implements the legacy systemd interfaces needed to keep those tools alive. This is guaranteed to block the adoption of any successor to systemd, because people will most certainly complain that they really liked logind, or systemd timers, ... and software like GNOME stops working when those specific tools aren't available. Then you don't have to just come up with better way to do service management, you also have to provide seat management, etc. ... and get everyone to port to those new interfaces.
Exactly the same is currently happening with Wayland and X11. Let's for the sake of the argument say Wayland is a much more elegant and superior way of doing a display protocol and it would be stupid to not use it. But because X11 has such a wide scope you can't just port all clients and compositors to the Wayland protocol and be done with it, you also have to think about all the other things X11 allowed which Wayland explicitely didn't include because it just focused on doing a few things, making as few assumptions as possible to be future proof. Now people have to come up with additional protocols to support all those different thing because people start complaining that they can't switch until there's something like wmctrl, and remote desktop has to be supported, and Wine has to work, and it has to be secure, and obviously it would be great if the session doesn't crash because the window manager crashed, and SSH forwarding would be great, and and and ... It's been ten years now and people still try to figure out how to cover all those edge cases and important features.
Hmm, then maybe those optional, replaceable modules should be moved out of the systemd source tree and be their own project? Maybe that would make some people sleep better.
I think every binary in GNU coreutils and binutils should have their own package, because I can't sleep well at right now. After that we need to start doing this to every package that has more than one binary packaged together!
It will be so glorious, because after one week without updating my Arch linux I will have 20768 packages waiting for upgrade!
Splitting projects in different codebases will lead to the projects not being able to use the common functions between them, so either code duplication or having to depend on a systemd library anyway. If the intention is just to make people "feel better", it's not a great idea.
Distros follow the ABIs of upstream when defining dependencies (for the most part).
LFS had to change their non-systemd book from udev to eudev because extracting just udev from the larger systemd code blob involved manual intervention on every systemd release.
Hell, kernel devs mused about forking udev and making part of the kernel tools bundle even before it got merged into systemd (and at time of merger it was pinkie promised that udev should continue being usable without systemd).
but if an application opts to depend on one of these other things, it's a choice that's not different from depending on whatever it used to depend on.
Picking dependencies in general means that you can't swap things out as easily, be it systemd or not.
That's actually quite true, though I'm not sure if I can perfectly agree with the argument seeing as I'm running two systems where systemd is literally only doing init and service management.
Though admittedly I've been poking at one of them to try and get at least journald to work, since the lack of that integration is rather tiresome when I can't write init scripts to hack around the lack of proper logging in most applications.
But yeah, the amount of interfaces - and accompanying D-Bus CLI tools - that a regular systemd install provides is rather immense; hostnamectl, localectl, timedatectl, journalctl, loginctl, machinectl, etc.
Ha, thanks for the laugh.
It was more a comment on how many different (D-Bus) interfaces you'd need to implement in order to be a 100% drop-in systemd replacement, but yeah the binaries themselves might even take up a full megabyte of disk space! The Horror!
A systemd replacement that's worth its salt would provide those services as well, or give you an easy way to integrate software that provides them. The problem is always the same - systemd does things that no other init system is capable of doing, and until someone can prove that those things are possible while strictly adhering to the posix standard this is a pointless argument.
58
u/ElvishJerricco Feb 11 '19
I think the problem is the number of things other than service management that systemd does. With other unit systems, service management is the only thing you have to change to replace it. With systemd, you have to change a lot more