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.
Systemd-init, the core part of systemd, offersa wide range of features surpassing other init systems. More features lead to more bugs and security vulnerabilities.
This is a bad take. Many of systemd's features improve security significantly. And having all that code in one cohesive place can't possibly be inherently less secure than the cornucopia of init scripts we used to use.
Many of systemd's features improve security significantly.
But not the issues of any integrated service suite running as PID 1.
Many maintainers use the entire systemd suite, even if they don’t require all its components.
This is the level of systemd-critic today?
Most of what you said applies to the Linux kernel too. It's good to have other options, but being popular does not mean something is bad.
security? I don't think systemd vulnerabilities are that critical, a vulnerability in systemd will provide a way to privesc at most, which means that the attacker must have initial access to exploit it. And considering that most linux servers are using containerized systems, a direct systemd exploit is not possible in most cases
also, more people using systemd means more devs working on systemd, so more security issues will be found and patched
I'm actually leaving systemd completely, I plan on using libudev-zero and it seems pretty viable to me
I use systemd-nuclear-reactor in my system, systemd-spoon and systemd-fork weren't good enough to replace just using my hands though.
