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.
You’re missing a TON of history here. Like udev being a dependency to all those projects AND systemd, which led to systemd adding it to their project. Really it could be said that udev is the critical component here.
As you mentioned networkmanager, you clearly know that many popular distros use that rather than systemd-networkd.
Grub2 is by far the most popular boot loader, so far ahead that it’s not even worth considering others. Grub has had several major issues, every distro uses it, why not pick on grub as the risk?
Did you have these same concerns about sysvinit? About the various distro network scripts? What about libc? Good god if there’s a problem with libc we’re all in deep trouble.
Yes, code has bugs. But New code has new bugs (ironically an argument previously used against systemd). Whatever you replace these components with will be just as likely to have a critical vulnerability, but far fewer maintainers and resources to fix it. Systemd has simplified and improved features of so many parts of Linux that it’s funny to see how vehemently people argued against it. Feel free to disable any parts you don’t need, but I think you’re missing 20 years of painful history that led us here.
Their entire post history is either trash-talking of popular software, or careful omission of important details, which also just feeds into the same kind of behavior. Don’t waste your time, trying to argue with someone who’s purposefully flaming the community