Why Did It Take Devuan Two Years to Replace Systemd?

Are you referring to the systemd journal? I think you should lay out your arguments in detail if you want to make claims like that, since there is a lot of compelling evidence to the contrary. Russ Allbery's analysis of systemd [1] lays out a convincing case that the journal is a highly developed, flexible, and useful feature:

  * Integrated daemon status.  This one caught me by surprise, since the
  systemd journal was functionality that I expected to dislike.  But I was
  surprised at how well-implemented it is, and systemctl status blew me
  away.  I think any systems administrator who has tried to debug a
  running service will be immediately struck by the differences between
  upstart:

    lbcd start/running, process 32294

  and systemd:

    lbcd.service - responder for load balancing
     Loaded: loaded (/lib/systemd/system/lbcd.service; enabled)
     Active: active (running) since Sun 2013-12-29 13:01:24 PST; 1h 11min ago
       Docs: man:lbcd(8)
             http://www.eyrie.org/~eagle/software/lbcd/
   Main PID: 25290 (lbcd)
     CGroup: name=systemd:/system/lbcd.service
             └─25290 /usr/sbin/lbcd -f -l

  Dec 29 13:01:24 wanderer systemd[1]: Starting responder for load balancing...
  Dec 29 13:01:24 wanderer systemd[1]: Started responder for load balancing.
  Dec 29 13:01:24 wanderer lbcd[25290]: ready to accept requests
  Dec 29 13:01:43 wanderer lbcd[25290]: request from ::1 (version 3)

  Both are clearly superior to sysvinit, which bails on the problem
  entirely and forces reimplementation in every init script, but the
  systemd approach takes this to another level.  [...] the most useful
  addition in systemd is the log summary.  And that relies on the 
  journal, which is a fundamental  design decision of systemd.

  And yes, all of those log messages are also in the syslog files where
  one would expect to find them.  And systemd can also capture standard
  output and standard error from daemons and drop that in the journal and
  from there into syslog, which makes it much easier to uncover daemon
  startup problems that resulted in complaints to standard error instead
  of syslog.  This cannot even be easily replaced with something that
  might parse the syslog files, even given output forwarding to syslog
  (something upstart currently doesn't have), since the journal will
  continue to work properly even if all syslog messages are forwarded off
  the host, stored in some other format, or stored in some other file.
  systemd is agnostic to the underlying syslog implementation.

The benefits that Russ describes above are meaningful, tangible improvements to the user experience that helps system administrators like me. Far from being brittle, the journal seems quite flexible (being "agnostic to the underlying syslog implementation"); it seems highly-developed and well-integrated into the systemd toolkit, and I see no evidence that it's over-complicated.

> Message broker (IPC)?

Are you referring to dbus? Dbus is not part of systemd and predates systemd by almost a decade! Dbus already had significant adoption when systemd took a dependency on it. It's used by GNOME, KDE, and even the Upstart init system. From Lennart Poettering's blog [2]:

  D-Bus has been a core component of Linux systems since more than 
  10 years. It is certainly the most widely established high-level
  local IPC system on Linux. Since systemd's inception it has been
   the IPC system it exposes its interfaces on. And even before
  systemd, it was the IPC system Upstart used to expose its
   interfaces. It is used by GNOME, by KDE and by a variety
  of system components.

It's tightly integrated where it doesn't need to be (with zombie reaper), you can't replace it (only slap something on top of it), and generally those few last log lines that are displayed are useless anyway, as usually when something breaks I still need to view full logs. Much more useful would be debuggability (with syslog this part is easy), remote data collection (syslog has it for decades already), and storage resilience (journald can corrupt log files on system crash).

> Are you referring to dbus? Dbus development began in 2002 whereas systemd's first release was in 2010.

When what was started is pretty much irrelevant. I didn't say we don't need D-Bus as a message broker (though I consider sub-par the way D-Bus works), I said that we don't need it in neither zombie reaper nor daemon manager. It worked well enough being a stand-alone service for a decade.

And now, you haven't addressed the glorified zombie reaper including a task scheduler and QR code generator. Why do you think their integration is so important that they needed to be included in systemd?

New features require time to gain wider adoption. Some services already support this, but most don't (yet).

This was not the way it was sold. It was originally sold as an init replacement.

If at the start the systemd guys had come out and said, "We aim to replace much of the core of Linux with some kind of Windows-Linux conglomoration: replace not only init but dns, syslog, turn all system log files binary, replace intetd, fuck with account naming, and oh, by the way, there'll be no easy way for distros that go with systemd to give their users a choice to use something else" then I'm not so sure how many people would have gotten onboard.

Basically, systemd has been a retooling of the core Linux ecosystem by people who think they know better. Well, this might be news for systemd fans, but they don't necessarily know any better than the rest of us, and the rest of us would like some choice in the matter. Instead we're force fed systemd and our operating system are no longer Linux but some bastardization of Linux and Windows.

"Nobody shoved anything down anyone's throat, least not the SystemD developers."

Tell that to the significan number of RedHat, Debian, and CentOS users who strongly object to systemd yet are forced to use it because that's all their distro supports.

"Anyway, in reality, software does not become mature and well-tested without early exposure to real users and systems. Chicken-and-egg problem there."

You don't have to test it out on all RedHat users, all Debian users, all CentOS, etc, etc. Getting a bunch of volunteers and letting them use a feature-complete version for five or six years before springing it on the rest of us would have been a good start. Instead you get an ever-morphing and ever-growing trojan horse.