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.
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.
They’re all bad takes.
That’s an understatement.
If OP had their way, Gnome would just be a terminal window with applications listed, because it compiles quickly, and no features is better security You’d need to manually install the features you need.
I used to use Gentoo and roll my own kernel. Total waste of time
Yeah I’m not really convinced that systemd is less secure than anything else would be in actual practice. But if you want to address the theory that its much-maligned style of software development methodology leads to worse outcomes, the usual high-level argument would be that well-defined interfaces between replaceable components is what leads to a more robust system. For example having several available alterternatives for logging, such as syslog, syslog-ng, rsyslog, et cetera as opposed to everyone being pushed into additionally having systemd-journald running because the other systemd components just assume that it will be there.
There are certainly costs to the systemd style, it’s just a question of whether the benefits are worth it for you.
But not the issues of any integrated service suite running as PID 1.