I really don't get this hatred of systemd. Systemd solves many programs that have plagued Linux forever. Sure, SysV-init was super simple, and it was great bac

I really don't get this hatred of systemd. Systemd solves many programs that have plagued Linux forever. Sure, SysV-init was super simple, and it was great back in the 1980s or even the 1990s when your server ran just a handful of daemons. But systems get more complex and featureful over the years. In the year 2024, my standard Fedora Linux desktop, has 73 daemons running in the background... Dealing with sysv single-threaded and start-and-forget architecture is not great on modern systems. You might say, well, why not Upstart!? Well. Upstart added a lot of complexity to the init process, while adding very little overall benefit. Systemd added a lot of complexity, no doubt about that. But, it also added a TON of features that reduced complexity elsewhere on the system. I mean, just to rattle a few things off: * systemctl. Holy fuck! A SINGLE command, that works across all modern Linux to control system services. I do not miss the days of service, chkconfig, /etc/init.d/xxx start, update-rc.d, insserv, rc-update, rcconf, sysv-rc-conf, ntsysv. And every distribution having their own special init scripts that worked in a very specific way to that distro. A great example of this is RHEL5's sshd sysv init script, a 500!!! line shell script to start the ssh daemon... Compared to RHEL9's sshd 24 line systemd unit file. * cron - scheduled tasks being handled by a screwball 3rd party service that had no built-in method of ensuring a cronjob would be retried in the event of a failure... systemd timers fixed that nonsense. * at - see above * autofs - Here's a lovely service that is stupidly complex. Whenever I have to setup autofs I get the feeling that the developers purposefully asked themselves "what can we do to make our application hard to configure?" then, once they had an answer to that question, they went back to the drawing board and asked, "Okay, configuring autofs is hard, but, what can we do to make it even more obtuse?". systemd automounts are drop-dead simple, a 5 line unit file saying what to mount and on what condition. * Parallelization and dependencies - Systemd can start services in parallel and only after their dependencies are ready, unlike SysV’s linear approach. This isn't just for faster boot times; it's also about reliability. Ever had a service fail because another wasn’t ready? Systemd handles that for you. * systemd has overall good built-in security! All services are started in their own cgroup and with posix capabilities and r/w access to the filesystem easily restrictable. You claim systemd is a "badly written multifunction blob" but that's mostly not true, look at `/usr/lib/systemd/systemd-*` and `/usr/bin/systemd-*`. Systemd is split out into multiple purpose-specific executables in almost every place where it makes sense to do it. I could go on all day, but I'll stop here. I agree that the system isn't perfect, and they've made some choices I disagree with. But overall, systemd is a MASSIVE improvement over everything that came before it.