The road forward for systemd

First of all, you create the impression that systemd’s core design was about dependencies. Well, it is not. Dependencies are supported by systemd only for the purpose of early boot. Normal services should not really use that for much. One of the nice things in systemd is that the kernel will get the dependencies and ordering right for you, out of the box.

Also, it is misleading that the hw hotplug logic would only really make sense in an event-based systemd. But well, that’s not true. It fits really nicely in a system that does dependencies: for example, there is a dependency between “bluetooth dongle is plugged in” and “bluetoothd must be running”. Systems that support dependencies can express that dependency explicitly, while event-based systems cannot.

Did you never get the idea that maybe nobody else is using your event-based design, because it is simply broken? (For the reasons I pointed out in my original blog story.)

Also, claiming that launchd’s or systemd’s core design was around on-demand loading of services is misleading. While we support that too, we do socket-based activation mostly to parellelize boot-up and to get rid of explicitly configured dependencies. Only a few services will actually be started on-demand in a systemd system. Most will be started in any case, but fully in parallel due to the socket activation logic.

Yes, systemd does both socket-based activation and dependencies. Manually configured dependencies are however only really needed for early boot-up or late shut-down and a few other cases. launchd does not support dependencies at all, for the price that their early boot-up is completely seperate from the starting of daemons, while in systemd this can be interleaved quite a bit.

OpenSUSE has already given up all Upstart experiments btw. Right now only Ubuntu uses Upstart fully, and Fedora and RHEL use it in sysv compatbility mode only.

And generally I think it would be nice to talk more about stuff Upstart has actually already accomplished, instead of great plans. In my postings about systemd I kept the part about my plans very short. Almost all features I talked about in my various postings can be listed under “DONE”, not under “WILL BE DOING”.

Note that systemd supports quite a few triggers for starting a service. And they can be combined in various ways. For example, we can start CUPS as a dependency of “printer plugged in”, as well as a dependency of “client requests CUPS services”, as well as “there’s a file in the CUPS spool dir”. It’s all implemented, and works fine. CUPS fits perfectly in the systemd model, as all its triggers are available already. If one of the conditions holds, CUPS is started. I don’t see how the current Upstart could do anything like this… So, on this topic: systemd 1, upstart 0.

And finally, I don’t think you have really understood launchd or systemd. The focus is on using socket-activation for parallelizing and getting rid of explicit dependencies. It’s much less on on-demand loading.