On Sun, Nov 15, 2009 at 10:06:53PM +0300, Nikita V. Youshchenko wrote: > > > as you might have seen more and more FSO 2.0 subsystems are ready for > > > prime time, so we have to think about how configuration works for FSO > > > 2.0. Until now I used the same method as in FSO 1.0, which is having > > > it lumped all together in one config file. For FSO 2.0 I'm leaning > > > towards changing this. The benefit I see from one configuration file > > > per subsystem is: > > > > > > *) promoting the fine granular usage of individual FSO subsystems, > > > *) enable packagers to ship the config with the subsystem, if they > > > want, *) a third reason which i forgot while writing this mail. > > > > > > What do you think? > > > > Hi, > > > > from the Debian point of view I can support this idea, because it > > would make packaging easier :) > > > > How do you plan to start the different subsystems, if each subsystem > > uses it's own files? Will there be a init.d script for each subsystem? > > If I undrstand things correctly, mentioned "subsystems" are actually dbus > services, and as such, could be started on demand bu dbus daemon itself. > > This may be not true for a subsystem that takes long to initialize, in > which turn this subsystem should be started at system startup. > > Nikita
This may work for services, which can be started on demand, e.g. ogpsd, but some of them are supposed to run @ system startup, e.g. I want my display auto-disabled without requesting the event handler via DBus. -- Sebastian
signature.asc
Description: Digital signature
_______________________________________________ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
