I noticed with interest that the 11.4 release announcement states that opensuse has replaced the traditional sysvinit system with systemd (freedesktop.org - Software/systemd).
Does anyone who follows the developer mailing lists have any insights into why this was chosen instead of Upstart, which seems to have been chosen by Fedora, Ubuntu and even Redhat Enterprise 6, among others?
Well for one thing systemd will replace upstart in F15, so evidently the Fedora devs think it’s even better than upstart. RHEL6 is frozen so you won’t see systemd until RHEL7 I guess. And since Ubuntu was the sponsor of upstart, they would swear by it.
Apart from the technical differences, Wikipedia has this to say about Upstart:
Upstart is subject to Canonical’s controversial contributor agreement, requiring contributors to assign copyright to Canonical, and allowing Canonical to release it under a non-open source license.
I am a bit biased because I listened to Lennart’s talk recently. However aside from that, and the fact that I have not explored it in depth, I do notice that systemd subsumes the functions of (x)inetd as well, which upstart doesn’t handle, as it only replaces rc. It also replaces a lot of code that the daemon itself has to do, such as forking. double forking, and uid changing. I regard these as improvements already. Some of the ideas in it will be familiar to those who have used OS/X’s launchd.
The Rindfleischfischteich mit Bier article was very interesting, he makes some good arguments there. I wasn’t aware that the Redhat world (Fedora and future RHEL) were going away from upstart, I had the idea that Opensuse was going some non-standard course with systemd. Looks like it’s the other way around, and let Ubuntu do whatever wacky thing they want
Upstart has some flaws, the major one, in my opinion, being event-based instead of dependency-based. SystemD is much easier and more flexible to configure/administer. Every daemon simply have its own configuration file, while in an event-based system a dameon “B” dependent on a daemon “A” has to configure daemon "A"s events to start up after A is started.
Even better, SystemD can simply ignore dependencies. All target-daemons can be started in parallel, they connect to pseudo-sockets that causes the processes behind the sockets to start up automatically. The socket that connects to the socket-dummy will block until the process behind the socket is ready to answer requests.