The whole argument about Systemd being counter to the Unix philosophy because it clusters a bunch of seemingly unrelated pieces of functionality(networking, dev

The whole argument about Systemd being counter to the Unix philosophy because it clusters a bunch of seemingly unrelated pieces of functionality(networking, device detection, process initialization, session management, power management, et. al) is not really applicable in my opinion. All of the functionality on that list has two things in common that make them good candidates for Systemd: they all require programs to be started and stopped in response to state changes, and they all will require different programs to be started at initialization based on the initial state of the system. I was annoyed too when udev became systemd-udev and broke a few pieces of functionality I was relying on 15 years ago but if you're building a system around the Linux kernel it's a really useful toolkit if you have the resources to use it, because it does a ton of stuff for you. Before Systemd I was having to write ifup/ifdown scripts and monkey with shell scripts in init.d and updating udev rules to control initialization, which was more Unixy but also riddled with edge cases. For example, there's nothing stopping ifup/ifdown scripts from running out of order with certain udev rules when you plug in a USB-to-Ethernet adapter without inventing your own ad-hoc synchronization mechanism. Systemd builds that same thing in and essentially makes it the default. It's had some irritating teething problems, and I would also prefer some more interchangeability and some reduction in the amount of binary code, but I have a better experience with it than without it in the systems that I work with.