Re: Init freedom
I think you might want to spend a bit of time looking at what systemd *does*, and *how it does that* before saying these things.
For a start, it's a collection of modular things that do their own little thing, but require cooperation in modern systems. For just one example, power management are absolutely critical for servers, particularly virtualized processes.
Systemd enforces a security model, again critical for servers, that supplements (or outright replaces) the hopelessly complicated SELinux with something that is even simpler to get going than chroot jails on *BSD. As the ultimate parent process, this is the best place to do it, particularly when you take into account its lightweight containerization capabilities.
Systemd's modular security architecture provides separation of duties, so a compromise of one module doesn't imply a compromise of the entire system. It's early days yet, so I bet there's a few sandbox bugs to work out, but this sort of sandboxing is absolutely critical for Internet facing servers.
Systemd has lightweight containerization, which is critical to servers, particularly cloud based servers. You can boot a new environment with a single command without a lot of setup. Like any init process, it knows how to start, stop, suspend, or provide services to it.
Systemd has a completely orthagonal administration model, which eliminates guesswork. This is critical for servers and reduces the chances of admins stuffing it up.
Systemd boots in a fraction of the time taken by any init. This is critical for servers where taking a 4 minute reboot holiday basically means losing any chance of 99.99% uptime that year.
Please, please, please, don't let facts get in the way of your emotions. It's just new, which means you should learn about it. It's actually quite good. I was sceptical at first, but now, I can't imagine returning to the old way.