This is one of my biggest gripes with systemd. Millions of lines of code. Immense complexity. Constant churn. Endless config changes(leading to outdated and potentially dangerous configs).
Sysvinit, it's a 1000 lines of code, maybe a bit more. It's a rock compared to systemd.
So many devs have zero issue with large codebases. Some substitute "small" with "perceived small because I pull in 10M lines of node and composer packages".
And of course the new goal is to bring "trusted computing", eg Microsoft style EEE to Linux with Lennart's now corporate gig.
But it is a different world. So, what can you do?
But that's not quite the the right comparison, is it?
Systemd doesn't just replace 1000 lines of Sysvinit. Those "millions of lines" also replace the thousands of hundred-line poorly-vetted Bash scripts you need, plus your syslog daemon, plus dozens of "fork, setuid, chroot" variants, plus your cron daemon. And that's before we get into things not directly related to service management, like logind, hostnamed, networkd, resolved, timesyncd, tmpfiles, udevd, and so on.
Systemd is an umbrella project. Look at each individual component in isolation, and the vast majority of the time the thing it replaces is significantly more complex and fragile. Systemd was adopted by most of the Linux ecosystem because it was a significant improvement over the status quo, there is no need to invent conspiracy theories here.
But is the actual architecture of systemd giving simple, securable, reviewable boundaries? This is a codebase that runs in stages of inherent privelege and very low levels in many linux systems.
> It's a rock compared to systemd.
Complete opposite of my experience. I've never had a single problem with SystemD - it's one of the most surprisingly reliable parts of Linux IMO.
In contrast SysVInit worked ok on servers and sort of on desktops, but on laptops forget it.