Hi folks,
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
chan
On Sun, 15 Nov 2009, Michael 'Mickey' Lauer wrote:
> Hi folks,
> 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 tog
On Sun, 15 Nov 2009 10:05:31 +0100
m...@mnet-online.de wrote:
> On Sun, 15 Nov 2009, Michael 'Mickey' Lauer wrote:
>
> > Hi folks,
>
> > 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
On Sun, Nov 15, 2009 at 1:53 PM, Michael 'Mickey' Lauer
wrote:
> Hi folks,
>
> 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
> l
On Sun, Nov 15, 2009 at 09:23:39AM +0100, Michael 'Mickey' Lauer wrote:
> Hi folks,
>
> 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 havi
> > 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
> > tow
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
>
Ok, thanks for your feedback, I guess it's settled then. I will do the
changes at the end of this month.
> > > 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,
On Mon, Nov 16, 2009 at 04:16:16PM +0100, Michael 'Mickey' Lauer wrote:
> Indeed, dbus system activation should work for almost all services but
> one or two. For those cases, you will need an init script or something
> similar.
>
> On a related note... my super-secret plan is to get rid of sysvi
>
> On a related note... my super-secret plan is to get rid of sysvinit and
> make a highly optimized init process that does just enough to get dbus
> and (optionally) X up. That may as well be incorporated into
> fso-monitord, we'll see...
How that relates with (1) upstart, (2) whatever moblin us
Am Montag, den 16.11.2009, 17:57 + schrieb Enrico Zini:
> On Mon, Nov 16, 2009 at 04:16:16PM +0100, Michael 'Mickey' Lauer wrote:
>
> > Indeed, dbus system activation should work for almost all services but
> > one or two. For those cases, you will need an init script or something
> > similar.
Am Montag, den 16.11.2009, 21:09 +0300 schrieb Nikita V. Youshchenko:
> >
> > On a related note... my super-secret plan is to get rid of sysvinit and
> > make a highly optimized init process that does just enough to get dbus
> > and (optionally) X up. That may as well be incorporated into
> > fso-m
> > > On a related note... my super-secret plan is to get rid of sysvinit
> > > and make a highly optimized init process that does just enough to
> > > get dbus and (optionally) X up. That may as well be incorporated
> > > into fso-monitord, we'll see...
> >
> > How that relates with (1) upstart, (
Am Montag, den 16.11.2009, 21:57 +0300 schrieb Nikita V. Youshchenko:
> > > > On a related note... my super-secret plan is to get rid of sysvinit
> > > > and make a highly optimized init process that does just enough to
> > > > get dbus and (optionally) X up. That may as well be incorporated
> > >
Am Montag, den 16.11.2009, 20:08 +0100 schrieb Michael 'Mickey' Lauer:
> Am Montag, den 16.11.2009, 21:57 +0300 schrieb Nikita V. Youshchenko:
> > > > > On a related note... my super-secret plan is to get rid of sysvinit
> > > > > and make a highly optimized init process that does just enough to
>
On Mon, Nov 16, 2009 at 07:37:47PM +0100, Michael 'Mickey' Lauer wrote:
> > > On a related note... my super-secret plan is to get rid of sysvinit and
> > > make a highly optimized init process that does just enough to get dbus
> > > and (optionally) X up. That may as well be incorporated into
> >
Hello.
On Mon, 2009-11-16 at 19:40, Michael 'Mickey' Lauer wrote:
> Am Montag, den 16.11.2009, 21:09 +0300 schrieb Nikita V. Youshchenko:
> > >
> > > On a related note... my super-secret plan is to get rid of sysvinit and
> > > make a highly optimized init process that does just enough to get dbus
* Michael Lauer [16.11.2009 16:16]:
> Ok, thanks for your feedback, I guess it's settled then. I will do the
> changes at the end of this month.
>
> > > > 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 subsy
The proposed changes (per-daemon configuration files) have now been carried out.
As an example, here's how to migrate fsodeviced. Copy all sections starting
with "fsodevice"
to a new file named /etc/fsodeviced.conf or /etc/freesmartphone/fsodeviced.conf
Change section [fsodevic
19 matches
Mail list logo