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.
Personally my only gripe with systemd is that the systemctl and journalctl commands are cryptic and unintuitive. Every time I have to use one (which thankfully isn’t often), I have to spend 5 minutes reading man pages to remind myself whether -u is “user” or “unit”, what the difference is between a “unit” and a “service”, etc.
I imagine this is what non-developers feel like when they’re forced to use git—having a whole pile of unfamiliar vocabulary and syntax thrown in your face when you’re just trying to do one simple thing.
I’m a long time Gentoo user. No systemd ever. When my old computer started failing and my Gentoo started falling apart (mostly because I made multiple mistakes when trying out testing versions of Plasma 5 and also due to me not updating for a long time and then getting into a long list of blockers) I installed OpenSUSE (Tumbleweed… Once you go rolling release, you can’t go back. :-D).
In just a few weeks, no idea why or how, it started having a weird problem. When shutting down, every time, it got stuck on some error (waiting for session something, I believe, but I don’t remember really) and it was waiting 1.5min until it continued. No explanation of what exactly it’s waiting for, no way to say “continue now without waiting”… No amount of googling got me anywhere near to finding out what the problem was.
Later I also ran into a problem where I was changing something about hard drives, I changed the fstab too, but for some reason systemd was getting stuck on trying to mount the drives that weren’t in the fstab anymore. Later I found out that it was my fault, I had a line that mounted the drive, and a few lines later I had some mount bind line operating on that first mount or something, but I still think the normal init system would just spit out that it can’t mount that and go on.