-
Systemd-init has a larger attack surface compared to runit, openrc, or sysVinit.
-
Systemd-logind relies on systemd, so we need to adapt it for non-systemD distributions to ensure compatibility with certain applications like GNOME.
-
Udev also depends on systemd.
-
SystemD is specific to Linux, which makes porting software to *BSD even more challenging. It’s uncertain what the future holds, and there may be circumstances where Linux becomes unusable for you (e.g., compatibility issues with your laptop). Having a good alternative that doesn’t require relearning everything is generally beneficial.
-
SystemD-based distributions often come with more than just “systemd-init.” They include additional components like logind, resolved, networkd, systemd-timers, etc. However, many people still prefer using the alternatives they were accustomed to before systemd became popular, such as dhcpcd and cron. Consequently, having both sets of tools installed can increase the attack surface.
I absolutely dislike the hate for systemd. Especially if there’s bullshit claims like
in there.
Because they don’t execute million lines super thoroughly checked shell code or why exactly? Without any explanation total FUD.
Some independent binaries from the systemd project, e.g. systemd nspawn, can even used on OpenRC and the systemd project explicitly didn’t change the way to launch udev in debug mode because the Gentoo non-systemd udev pkg maintainer asked to not do so (nicely).
You should instead tell people why OpenRC/runit is (more) awesome in your opinion and maintain initscripts for them. Maybe you can volunteer at the Debian project and get them to adopt OpenRC aside systemd instead of only removing the remnants of sysVinit support. This would also be beneficial for pragmatic pro-systemd users that have to deal with docker or chroot environments.
Whonix Dev quote:
It’s a matter of probability. Probability of discovering vulnerabilities in multiple tools doing same thing is higher than in just one.