Systemd is the most common software suite for managing Linux-based systems. It includes init, rc, device manager, temporary files manger, network name resolution service, cron alternative, machine manager, spoon, fork, nuclear reactor, remote control of the world, etc.
Let's see what problems could not be solved even after 14 years of development.
-
Many maintainers use the entire systemd suite, even if they don't require all its components.
-
Systemd-init, the core part of systemd, offers a wide range of features surpassing other init systems. More features lead to more bugs and security vulnerabilities.
-
Source-based distributions may experience increased compilation time due to systemd.
-
Systemd is exclusive to Linux and cannot be used on other Unix-like operating systems such as FreeBSD or OpenBSD. This limitation means that software dependent on systemd, like GNOME, won't be compatible with these non-Linux systems.
-
The project is primarily led by Red Hat. There is a possibility of Red Hat stopping systemd development as a completely FOSS software and making it an exclusive feature of RHEL. Red Hat is a commercial company that will prioritize profit within legal boundaries. SystemD is still a tool used by Red Hat to increase its influence on GNU/Linux. The interdependence between SystemD and udev nowadays highlights the significance for Red Hat to encourage widespread adoption of their suite, rather than utilizing components developed by multiple teams of developers.
But you will still end up using SystemD, or at least some of its components. This is because opentmpfiles (the only alternative to systemd-tmpfiles) has been abandoned. Udev/Eudev has no alternatives and is a dependency for NetworkManager, Gnome, KDE, and many others. Gnome cannot function without logind/elogind. Systemd-boot is the default bootloader for certain Linux distributions (such as NixOS, for example). And it won't get better from here. The further we go, the more dependent we will become on SystemD. And this needs to be somehow stopped. Because the more widely used a software is, the more people will search for vulnerabilities in it. And with the amount of code in SystemD, finding a serious vulnerability is not that difficult.
Just waiting for systemd-kernel to replace the "old archaic" Linux kernel. j/k j/k j/k don't block me yet!
I used to be very much against systemd and I still don't like the interdependencies to everything (as highlighted in the OP), but at the same time - this is a decade old discussion and everything that was worth saying was already said back then and nothing has really changed much.
Most popular distros adopted systemd and that's that and we've since then kept piling in more eggs to that same basket. There are options (distros) available if you don't like it, but most of the "Linux community" chose systemd and that's where we've been for a decade.
I don't really have strong opinions these days - systemd boots my computer and most days I don't need to know about it. I still have to check the manpages for usage because the flags are just archaic as fuck, but that's more of a "me problem" than problem with the software.
I am worried about IBM though. The steps RedHat has been taking under their new mothership have been worrying and I have a feeling we "parasites" (as the RH CEO called us) might have just seen the beginning of this new strategy.
This isn't systemd specific fear, but while the "well we just fork it" is a nice thought, I'm not sure were "we" have the resources and money to continue maintaining it.
Anyway, that's just idle speculation from my part. Systemd discussions tend to be as constructive as "vi vs. emacs". Sides have been picked. Time has passed.
It is what it is.
The funniest thing is that most of the arguments against systemd can be made against X and the other way around. But with X the community opinion tends towards a "burn it with fire" or a completely new replacement, whereas for systemd all those arguments somehow get turned on their head.
If you're ever bored, try replacing systemd with "X" in a fan's comment justifying the former.