There has been a lot of debate about the move to systemd by virtually all the Linux distros.
I'm firmly of the opinion that it's a bad thing, handled badly. I'm actually amazed at how many distros have adopted it, and how quickly it has happened, pretty much leaving people who don't want it with no alternative.
I knew it was in Fedora, but they suddenly, bam, all distros have adopted it, and where-was-the-debate?
Red Hat - I'm really disappointed in you. I can't believe you're moving to it in Red Hat 7.
There's some hope in that Debian are going to reverse their decision to adopt it - here's hoping.
The usual way of adoption in the Open Source world is slow, gradual, choice-driven and popularity based.
Take webservers for example. On the average distro, you have a choice of Apache, nginx, and probably some others. If you like the tried-and-tested Apache, you can use it. If you want something with some extra benefits to you, you can use nginx.
Then, in 10 years time, if we see that no-one is using Apache any more, it could be dropped from the repos/distros.
This switch to systemd has been like removing Apache, and only allowing you to use some newly written webserver.
Among the small number of people I've discussed this with, the view on systemd seems to coincide with whether they're a sysadmin or a developer.
I've been a sysadmin for the last 15 years, and have now moved into development.
Developers tend to be very upgrade-happy. They'll upgrade libraries and packages because "it might have some bugfixes in", or "it might improve performance", without a thought that it might introduce new bugs, or even slow things down.
Sysadmins on the other hand value tried-and-tested, stable, secure code. For instance, I don't update packages unless a: there's a security vulnerability in it, or b: there's a bug that I'm suffering from that is fixed. If you're not having any problems with the combination of software you're using, then why change it?
Linux is known for being secure, reliable, and stable. This is why people use it - and changes that could affect this should be very carefully, and very slowly discussed and implemented.
The usual retort from the people who like it is that people who don't are "crusty old grey-beards" who don't like change.
I have a tiny patch of grey in my beard these days, but what I object to isn't change - it's change without choice with no benefit.
I don't see any problems with the old system, or any compelling advantage to the new. There are the arguments regarding it breaking the unix philosophy too.
And lest we forget - this is replacing one of the most important parts of a Linux system - PID 1. If that goes wrong, it's not going to help your uptime.
Because the current init-script based startup system is easy to read/modify (script based), has been running for many years, and is tried and tested, we should throw this away only after a lot of debate and trials.
I won't go into the reasons I think it's a bad idea. Other people have written about them well. Here are some links whose sentiments I agree with.
I think you'll see plenty of problems with systemd in the future - crashes, security vulnerabilities, tight-coupling with software, and general difficulties debugging what's gone wrong.
We need to keep focussed on simple, small parts that can be changed/swapped out, using text config files, shell scripts and logs.
Make systemd an alternative to the current init system, and see how many people use that.
Or leave servers with the tried-and-tested system, and let people who value a slight improvement in booting times have it in the "client" versions of distros.