Discussion around Upstart’s future

Tux
Scott James Remnant, the lead developer of Upstart, described the possible future of Upstart in a post to the developer e-mail list. Most notable is that the post was initiated by discussions between him and Fedora and OpenSuse developers. As a result future work will also take into account the needs and wishes of the other distributions.

Scott’s post is several pages long and is quite technical. This is now wonder since it aims at the experienced Upstart developer. But one thing stands out: in contrast to former roadmaps D-BUS and HAL might find their way into Upstart.

The background is that Upstart currently has its own way of defining events. If D-BUS or HAL (or udev) need to talk to Upstart there is the need to convert such signals to Upstart events. As a result Upstart has to have converters for all the udev rules, HAL FDI files etc.

To get rid of that situation the idea is to connect Upstart directly to D-BUS and HAL. Upstart events would not longer be needed but could be replaced directly by D-BUS signals and methods. Also HAL devices could be taken directly as events. As a result (as far as I understand it) CUPSD would only come up in case you connect a printer to the system. Or smb and other network services would only be started in case there is a network connection actually available. Looking at my services list I do see quite some which would not have to be started when I have no network connection. That’s a total waste of resources and energy, actually.

Scott mentions that this HAL/D-BUS decision is quite important because it sets the limit for Upstart: without HAL/D-BUS Upstart might be limited to the “traditional services”, with the capabilities given by HAL and D-BUS it might be able to manage the “super-modern services that we’re going to see more and more of”. I must admit that I’m not sure which kind of services he has in mind, however my example with the network services above already is enough for me to see a strong need for better ways to start and stop services more dynamically.

In any way I’m pleased to see that there is at least some kind of cooperation between the distributions. And I’m pleased to see that there are possibilities and also the will to find a common ground. I think that Upstart – in the way of a redesigned service management system – has quite some potential and could give the Linux system quite some benefits.
Of course there is still lots to do and there are quite some problems even around the idea of using HAL and D-BUS (as an example these are traditionally started at the end, not at the beginning of a system boot), but these discussions and Scott’s e-mail are a start.

One thought on “Discussion around Upstart’s future”

  1. From a laymans view (mine) that looks pretty interesting. Better management of memory and resources by intelligently starting and stopping services when they are needed. Linux is already light on memory and cpu, but you can’t use too little.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.