[rfc] Activating Common Services

[David Zeuthen]

On Tue, 2007-06-19 at 16:05 +0100, Richard Hughes wrote:
> Sure, replace HAL with bluetooth, the argument changes.

The plan here, as I've discussed with the Bluez guys, is to start the
Bluetooth daemons as a HAL singleton addon; e.g. it's running if, and
only if, you have a Bluetooth host controller interface.

Keep in mind there are multiple ways of starting processes on a modern
Linux OS. E.g. hammers are for nails, screwdrivers are for screws.. or
something.

> > System-bus activation is mostly only useful for privileged helpers; one
> > way I like to think about it is that it's an extremely nice replacement
> > for setuid root binaries.
> 
> And surely launching stuff like CUPS? I print about once a month, any
> yet every time I turn on my computer everyday I spend a couple of
> seconds "Starting cups..."

Well, the way CUPS currently works on most OS's is in a way such that it
monitors the local link for CUPS servers from a system scope and
sometimes advertises itself too. Hence, if you have printers to share,
it needs to be started at boot time. 

Otherwise it's fine only to start when someone calls into CUPS. But
since CUPS don't use D-Bus for the cupsd <-> application transport
layer, D-Bus system bus activation is not applicable. If someone were to
express the cupsd <-> application transport layer via D-Bus it would be
fine to use system bus activation for CUPS if you turn off the other
interface. And then things would be nice: only run a printing daemon
when you, uh, actually need one. I wonder how hard that is.

> > Actually FYI that bug was introduced on HEAD (by one of your bugfixes
> > even!); 0.5.9 is (almost) fine - it will get fixed for 0.5.10.
> 
> Ahh! To be fair, when I patched the startup ordering bug we had never
> even discussed system activation :-)

Heh, yeah, it should be easy to fix though.

      David