Most of this is a good thing. Faster. Newer code that is easier to maintain. Less reliance on shell scripts favoring declarative config files instead.
But change has lots of difficulties.
The biggest resistance though is coming from people who are simply accustomed to the old approaches and don't see a problem with them.
But there are other objections from people who think systemd is too big in scope or too controlling or focussed on one technology or another or... some kind of conspiratorial trap or something (http://boycottsystemd.org). I think these arguments are a little hyperbolic since systemd isn't actually a single monolithic system and is really an overarching project to update a lot of major system utilities.
I'm personally more of a Mac user than Linux user. On the Mac, 10 years ago, launchd replaced many of the processes that systemd is now replacing in Linux. Particularly for things like cron and inetd (which were horrible to configure and work with) it was a huge improvement. However, the Mac never replaced as much all at once. It was a much gentler transition. In fact, discoveryd (which does a lot of what systemd's hostname daemon's are trying to do) was only introduced in the current Yosemite.
The speed benefits come at the trade-off of integration complexity potentially diminishing them: http://freedesktop.org/wiki/Software/systemd/Optimizations/
Whether or not it is easier to maintain cannot really be objectively gauged. As for declarative configuration, I will grant that. systemd is not the first to do this on Linux, though. eINIT was, though it used XML as its configuration language (similar to launchd and SMF in fact, though not as verbose). eINIT also had the benefit of a modular plugin-based architecture, a property also shared by finit and initng.
Change does not imply progress. This should go without saying.
No, a lot of objectors simply come from having different opinions on process management and general software architectures. That said, there is a contingent who did approve of the old approaches, yes. I dislike sysvinit, but I can understand them. Serial execution with a concretely defined boot sequence that is easy to reason about can be a benefit to some. In contrast, the systemd approach eschews any definition of "boot process" or "boot sequence" that can be specifically intervened in by order, instead taking the philosophy that specifying a unit's dependencies and relative order to a target/synchronization point is enough, the rest being handled by internal transaction and job semantics.
systemd most certainly is monolithic. It is also modular, but to a partial extent. System generators and various auxiliaries (journald, but also some of the more minor tooling) cannot be disabled at build time. Certain things like Plymouth communication are also explicitly done at runtime.
launchd as a whole is still a much smaller system than systemd, at the end of the day. This is because launchd has a concretely defined purpose. systemd has little in the way of that other than vague descriptions that ultimately amount to being "as much as possible between the kernel and base libs+utils".
Well, with roadmaps like this[1], one wonders if some of the criticism is really that hyperbolic or unjustified...
This in effect makes everything under the systemd umbrella tightly coupled. Can i run journald on its own, or logind, or resolved, networkd? As long as the answer is no, they mays well be one big blob.
And it is presented as such as well from a source point of view.
http://www.freedesktop.org/software/systemd/
There is no separate tarball for udev, journald, logind, or any of the other *d's that make up the systemd project.
So to you there is no difference between sendmail and postfix, they are both equally monolithic?
That's just a fact of life in this industry tho.
> But there are other objections from people who think systemd is too big in scope or too controlling or focussed on one technology or another or... some kind of conspiratorial trap or something (http://boycottsystemd.org). I think these arguments are a little hyperbolic since systemd isn't actually a single monolithic system and is really an overarching project to update a lot of major system utilities.
The problems start when those replacement system utilities become (more or less) tightly coupled, so if you want to change one of them (say, I want to use my own DHCP client) then you need to change all of them (and it's increasingly looking like you can't).
And that is the insidious nature of it all. the *d's panders developer laziness. What do you do when some production critical piece of code demands networkd, logind, or any of the systemd sub-daemons? Do you look to replace it, or do you roll over and replace whatever already functioning init you have with systemd?
It also brings "new" bugs.
And it's being built by a group of people with a history of pushing badly built catedrals onto Linux, that turn into ruins even before completion, and have to be maintained because people get used to praying there.
That is a beautiful mental image.
The "official" points by developers can be read in WP: https://en.wikipedia.org/wiki/Systemd#Reception
50% of the problem is that there is no appreciable advantage to me (as a Gentoo, XFCE user)