[ck2]

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.

[bkor]

According to the blogs it is based upon what Mac OS does as well as Solaris. So it is very UNIX in mind.

[wahern]

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.