(Reliable process supervision which cannot be evaded,
cgroups existed before systemd.
the cgroups functionnality existed in the kernel but wasn't really used that much before.
systemd, with its tasks in setup/startup of things can handle the creation of jails during lauch when needed.
sane handling of process stdout/stderr
Up to the init script.
And thus each script end up fucking things up in its own original and different way.
proper handling of dependencies at runtime
Already handled by several init systems.
None of which are the original sysvinit.
Either it's relying on LSB-extended script and a different core which starts the scripts. (Debian had a makefile based one)
Or it's an entirely new system anyway like upstart.
We call it inetd.
Or cron if it's time-based activation. Or udev if it's hardware based activation. Etc.
Why do we need 83 different way to start some code ?!
Wasn't the whole point of Unix philosophy having one piece of software which concentrates into doing one thing and doing it well?
With systemd, setup/startup/stop/teardown responsibilities are concentrated with PID1 and it's helpers.
Before, you'd have the same concept spread into a dozen of different systems, each only doing part of that functionnality.
I like systemd, it makes my work easier on desktop, on server, on virtual machines, etc. and although it used to have hiccups when it was introduced before in opensuse, by now it has had the time to mature.
no need to bash it. if you don't like it, don't use it.
and perhaps the fact that it's slowly gaining popularity in lots of mainstream distro might be due not because systemd is "a spreading cancer" but because systemd is actually useful and solves real world problem