Linux/unix has a bit of an issue with it's init aging systems. One simple example is that they are serial, meaning that services start one by one with little to no concurrency. This causes several issues. Also, the most popular variant, system V is difficult to maintain having multiple directories for various run levels and other cumbersome features. I won't go into details here, just know that the popular init systems needed a refresh.
There are other options, but systemd seems to have caught on as the popular option for a replacement. The issue that most people take with systemd is that it does much more than replace init. It replaces cron, has a login management hooks, has it's own network daemon, replaces the system logging facilities and more. It's a serious complex system.
The issue some take with systemd has a few facets:
1) Some feel that systemd's approach to managing everything goes against Unix's core principles where services and applications are supposed to be small, self contained entities that work in unison to form a cohesive system.
2) It can be daunting task to switch over to systemd as you have to relearn many traditional unix tools that most take for granted (remote logging for example).
3) Security minded people are concerned that a single service is touching so many parts of the core system all at once. There have been many complaints levied that such a large change introduces too much risk into the ecosystem all at once.
4) Some have accused the dev team of having a "not invented here" problem. I've seen it asked many times why they really needed to replace cron or logging.
The pro-systemd stance is that they are simply cleaning up many of the antiquated systems. Cron, logging, and init definitely all needed an overhaul. Linux never had a good network daemon and there are good reasons for the other things they are doing. The systemd team sees systemd as not just an init system but basically the system manager. So, by that view, this all makes sense.
Ultimately, it's a fundamental difference of opinion about what services in general should or should not look like on a unix/linux system.
I agree completely that cron, logging and init all could use a little (a lot of) modernization. I just think it's really bad judgment to tie all of those together into one all-encompassing project whose scope seems to grow and grow the more I read about it, and whose leaders seem to have such a low opinion of what anybody else wants.
To make a stupid car analogy, it feels like having someone redesign your car's ignition switch and suddenly finding out that he also had strong opinions on the stereo UI so he made the changes together (and dependent on one another), and you're an idiot if you don't like it.
A lot of people complain about systemd missing the "unix philosophy" and that gets derailed on specifics of what people think that philosophy means ("everything is a file" or "do one thing only and do it well" and "be modular") but one significant difference to me between unix systems and Windows or OSX is that unix is built of simple components whose scope is very limited. It's related to do-one-thing and modularity but it's not exactly the same thing. Systemd is not simple or limited in scope.
That's uselessd. Software however relies on the other bits, e.g. logind dbus interfaces. For that there is a systemd-shim, but was not there initially and used to lag behind systemd for a 6+ months. Apparently it was also quite buggy. Seems ok now though.
To clarify, uselessd (http://uselessd.darknedgy.net/) is "a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism", not just the parent making a joke in the phrasing.
It's political theatre, to some extent. The traditional "SysV init" mechanism is there to do things that are slightly above kernel space, but too global to be considered part of userspace; so things like user settings for power management, managing long-running daemon processes, and handling logins could all be part of the init.
The problem motivating a switch is that init is an underpowered solution for the number of things that a distribution is asked to handle these days; it results in a lot of hand-tuned scripts with duplicated effort.
Enter the politics. A lot of the value of a distribution can come down to how its init system has been built, since it means the difference between essential stuff working or not working. Systemd pushes the value and the accountability into a central location by annexing lots of different features that were traditionally just spread out amongst various interdependent scripts. There are a lot of straightforward technical advantages to centralizing some of these things(speed, simplicity of configuration, etc.), but everyone and their dog has an opinion about which things should or shouldn't be annexed, and the form in which it should be done. Many people's jobs are potentially at stake here.
The more conspiracy-minded also view systemd as a power grab from Red Hat. Red Hat's business substantially involves contracts with the military, lending circumstantial evidence to the idea that they are doing deliberate harm to serve state interests - thus everything they do is viewed with some suspicion.
One person decided the way microsoft windows handles services was awesome and it would be a good idea to make the linux service manager work like that with complex binaries and binary logs instead of editable, standardized bash scripts and text logs. No vote, only veto. Very anti-linux.
Both launchd and SMF suck. Have you tried learning either?
SMF utilizes XML all over the place. launchd uses .plist trees all over the place. They're both a gigantic pain to learn, with obtuse configuration syntax, and in fact very few people actually learn them. They're both environments that breed epic cargo cults because they're overly complex, yet provide so little benefit that there's little motivation to bother to learn them properly. All you normally care about is getting your little script to run on boot or login, so the rest is just food for bugs.
SMF and launchd also organically grew to take over most of the management of /etc. Now neither is hardly any better than the Windows Registry.
systemd is not only moving in the same direction, they're going to leap-frog them. Why have a separate ntpd or dhcpd when you can just build it into the init framework. Why listen for SIGHUP or SIGTERM when "good" services (in as much as service can be good which isn't shipped with systemd) just use the systemd C API to listen for DBUS events.
That's the problem with systemd, SMF, and launchd. Like SMF and launchd, I have no doubt whatsoever that systemd will rocket past the boundary where the complexity exceeds the benefit.
There are other options, but systemd seems to have caught on as the popular option for a replacement. The issue that most people take with systemd is that it does much more than replace init. It replaces cron, has a login management hooks, has it's own network daemon, replaces the system logging facilities and more. It's a serious complex system.
The issue some take with systemd has a few facets:
1) Some feel that systemd's approach to managing everything goes against Unix's core principles where services and applications are supposed to be small, self contained entities that work in unison to form a cohesive system.
2) It can be daunting task to switch over to systemd as you have to relearn many traditional unix tools that most take for granted (remote logging for example).
3) Security minded people are concerned that a single service is touching so many parts of the core system all at once. There have been many complaints levied that such a large change introduces too much risk into the ecosystem all at once.
4) Some have accused the dev team of having a "not invented here" problem. I've seen it asked many times why they really needed to replace cron or logging.
The pro-systemd stance is that they are simply cleaning up many of the antiquated systems. Cron, logging, and init definitely all needed an overhaul. Linux never had a good network daemon and there are good reasons for the other things they are doing. The systemd team sees systemd as not just an init system but basically the system manager. So, by that view, this all makes sense.
Ultimately, it's a fundamental difference of opinion about what services in general should or should not look like on a unix/linux system.