On Mon, Apr 30, 2012 at 02:00:15PM -0300, Fernando Lemos wrote:
> On Mon, Apr 30, 2012 at 12:50 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> > On Mon, Apr 30, 2012 at 12:04:32PM -0300, Fernando Lemos wrote:
> >> On Mon, Apr 30, 2012 at 11:57 AM, Thomas Goirand <zigo@debian.org> wrote:
> >> > On 04/30/2012 04:56 AM, Fernando Lemos wrote:
> >> >> I agree that OpenRC would be an improvement over the status
> >> >> quo, but migrating *away* from OpenRC later on would be a major pain
> >> >> as we would have to support both LSB/sysvinit scripts and OpenRC
> >> >> service descriptions for the foreseeable future.
> >> >>
> >> > Ah? Is this any different with other alternatives like
> >> > upstart or systemd?
> >>
> >> Yes. The kernel isn't getting any less event-based, so OpenRC would be
> >> an interim solution.
> >
> > Unless OpenRC itself could become more event-based.
>
> How realistic is that?

I'm not sure yet. That's one of the things I'd like to find out.


Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120501102134.GO28298@codelibre.net">http://lists.debian.org/20120501102134.GO28298@codelibre.net

On 27/04/12 19:33, Tollef Fog Heen wrote:
> ]] Martin Wuertele
>
>> * Josselin Mouette <joss@debian.org> [2012-04-27 09:53]:
>>
>>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
>>>>> Yes of course, because event-driven init systems have *always* been
>>>>> *only* about mounting USB devices.
>>>>
>>>> Then explain the _real_ reasons for having an event driven boot system!
>>>
>>> BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.
>>
>> That's a reason for udev/mdev, however I still fail to see why this
>> results in the requirement for an event based boot process.
>
> A trivial example is $remote_fs isn't satisfied until /srv/somewhere is
> mounted and /srv/somewhere comes off iscsi, which means it requires
> networking to be up, which means network drivers loaded, etc. So the
> event «network driver loaded» causes ifup to be spawned, which causes
> $network to be satisfied which causes the iscsi daemons to be started
> which causes mount to be called.
>

A better example is bluetooth.

In my Debian system I have /usr/sbin/bluetoothd running and I don't have
any bluetooth devices on my system... So wouldn't be better that instead
of launching the bluetooth daemon and let it waiting for the day that I
plug a USB bluetooth device (and still I never did that) to just launch
this daemon only when the kernel detects a bluetooth device?


"""
For a fast and efficient boot-up two things are crucial:

* To start less.
* And to start more in parallel.

What does that mean? Starting less means starting fewer services or
deferring the starting of services until they are actually needed. There
are some services where we know that they will be required sooner or
later (syslog, D-Bus system bus, etc.), but for many others this isn't
the case. For example, bluetoothd does not need to be running unless a
bluetooth dongle is actually plugged in or an application wants to talk
to its D-Bus interfaces. Same for a printing system: unless the machine
physically is connected to a printer, or an application wants to print
something, there is no need to run a printing daemon such as CUPS.
Avahi: if the machine is not connected to a network, there is no need to
run Avahi, unless some application wants to use its APIs. And even SSH:
as long as nobody wants to contact your machine there is no need to run
it, as long as it is then started on the first connection. (And admit
it, on most machines where sshd might be listening somebody connects to
it only every other month or so.)

Starting more in parallel means that if we have to run something, we
should not serialize its start-up (as sysvinit does), but run it all at
the same time, so that the available CPU and disk IO bandwidth is maxed
out, and hence the overall start-up time minimized.
""" http://0pointer.de/blog/projects/systemd.html

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
Carlos Alberto Lopez Perez http://neutrino.es
Igalia - Free Software Engineering http://www.igalia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~

Le dimanche 29 avril 2012 Ã* 18:45 +0100, Roger Leigh a écrit :
> As a
> trivial example: systemd creates user session information in
> /run/user/$user . I brought up with lennart the fact that this would
> only permit one session per user. He rejected out of hand the fact
> that more than one session would ever be needed, because Gnome only
> allowed one session per user. So the limitations of Gnome in this
> respect have led to a fundamental limitation in systemd's session
> management.

There hasn’t been such a limitation in GNOME for years.

OTOH, there is a *design choice* in GDM 2.30+, which is to switch users
to a new session instead of starting a new one. This choice is
consistent with any thinkable reasonable use of a workstation (except
for testing purposes, but a production system should not be tailored for
testing requirements).

Making the same design choice in systemd is consistent with this, but it
is way too restrictive for a low-level component, which could be used by
many other things than the display manager. In any case it is completely
unrelated to GNOME.

--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1335949080.4277.298.camel@pi0307572">http://lists.debian.org/1335949080.4277.298.camel@pi0307572

* Carlos Alberto Lopez Perez <clopez@igalia.com> [2012-05-01 23:07]:

> On 27/04/12 19:33, Tollef Fog Heen wrote:
> > ]] Martin Wuertele
> >
> >> * Josselin Mouette <joss@debian.org> [2012-04-27 09:53]:
> >>
> >>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
> >>>>> Yes of course, because event-driven init systems have *always* been
> >>>>> *only* about mounting USB devices.
> >>>>
> >>>> Then explain the _real_ reasons for having an event driven boot system!
> >>>
> >>> BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.
> >>
> >> That's a reason for udev/mdev, however I still fail to see why this
> >> results in the requirement for an event based boot process.
> >
> > A trivial example is $remote_fs isn't satisfied until /srv/somewhere is
> > mounted and /srv/somewhere comes off iscsi, which means it requires
> > networking to be up, which means network drivers loaded, etc. So the
> > event «network driver loaded» causes ifup to be spawned, which causes
> > $network to be satisfied which causes the iscsi daemons to be started
> > which causes mount to be called.
> >
>
> A better example is bluetooth.
>
> In my Debian system I have /usr/sbin/bluetoothd running and I don't have
> any bluetooth devices on my system... So wouldn't be better that instead
> of launching the bluetooth daemon and let it waiting for the day that I
> plug a USB bluetooth device (and still I never did that) to just launch
> this daemon only when the kernel detects a bluetooth device?

I don't think this is a better example. Actually I think this is an
example where udev/mdev could launch/stop bluetoothd.

Yours Martin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120502170533.GA11244@anguilla.debian.or.at">http ://lists.debian.org/20120502170533.GA11244@anguilla.debian.or.at

On 02.05.2012 19:05, Martin Wuertele wrote:
> I don't think this is a better example. Actually I think this is an
> example where udev/mdev could launch/stop bluetoothd.

Long running daemons should *not* be started by udev. udev is *not* a
service manager.
What udev should do is signal the init system that the device is
available and the init system will start and manage the daemon. That's
what systemd and upstart do.

Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

On 05/03/12 02:16, Michael Biebl wrote:
> On 02.05.2012 19:05, Martin Wuertele wrote:
>> I don't think this is a better example. Actually I think this is an
>> example where udev/mdev could launch/stop bluetoothd.
> Long running daemons should *not* be started by udev. udev is *not* a
> service manager.
> What udev should do is signal the init system that the device is
> available and the init system will start and manage the daemon. That's
> what systemd and upstart do.
>
So, this whole sub-thread boils down to this:

"Our current init scripts don't handle dependencies properly"

Once you fix that you can just let udev trigger /etc/init.d/bluetooth
start, and that will do all the needed magic properly.

... and OpenRC has been doing that for such a long time that I find it
hard to understand that people are still not using it

I'm still slightly confused what people mean with "event based", I think
there are at least three similar, but distinct definitions going around.
A good part of that is already handled by the device manager, and the
rest appears to be user actions - if someone can find me a good example
of an event that doesn't fit into these categories I might understand
why from my point of view people seem to be violently agreeing so hard.

Thanks,

Patrick


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FA1D733.5040901@gentoo.org">http://lists.debian.org/4FA1D733.5040901@gentoo.org

On Thu, May 03, 2012 at 08:54:11AM +0800, Patrick Lauer wrote:
> On 05/03/12 02:16, Michael Biebl wrote:
> > On 02.05.2012 19:05, Martin Wuertele wrote:
> >> I don't think this is a better example. Actually I think this is an
> >> example where udev/mdev could launch/stop bluetoothd.
> > Long running daemons should *not* be started by udev. udev is *not* a
> > service manager.
> > What udev should do is signal the init system that the device is
> > available and the init system will start and manage the daemon. That's
> > what systemd and upstart do.
> >
> So, this whole sub-thread boils down to this:
>
> "Our current init scripts don't handle dependencies properly"
>
> Once you fix that you can just let udev trigger /etc/init.d/bluetooth
> start, and that will do all the needed magic properly.
>
> ... and OpenRC has been doing that for such a long time that I find it
> hard to understand that people are still not using it
>
> I'm still slightly confused what people mean with "event based", I think
> there are at least three similar, but distinct definitions going around.
> A good part of that is already handled by the device manager, and the
> rest appears to be user actions - if someone can find me a good example
> of an event that doesn't fit into these categories I might understand
> why from my point of view people seem to be violently agreeing so hard.

So, what you're saying is that we should fork udev to do things that
neither its upstream developer nor its Debian maintainer doesn't intend
for it to do, all to make it possible to use an init-system that doesn't
support events, instead of using an event based system that's designed
to work with udev?

Yeah, makes perfect sense...


Regards: David
--
/) David Weinehall <tao@debian.org> /) Rime on my window (
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120503175804.GA10339@suiko.acc.umu.se">http://lists.debian.org/20120503175804.GA10339@suiko.acc.umu.se

On 05/04/12 01:58, David Weinehall wrote:
> On Thu, May 03, 2012 at 08:54:11AM +0800, Patrick Lauer wrote:
>> On 05/03/12 02:16, Michael Biebl wrote:
>>> On 02.05.2012 19:05, Martin Wuertele wrote:
>>>> I don't think this is a better example. Actually I think this is an
>>>> example where udev/mdev could launch/stop bluetoothd.
>>> Long running daemons should *not* be started by udev. udev is *not* a
>>> service manager.
>>> What udev should do is signal the init system that the device is
>>> available and the init system will start and manage the daemon. That's
>>> what systemd and upstart do.
>>>
>> So, this whole sub-thread boils down to this:
>>
>> "Our current init scripts don't handle dependencies properly"
>>
>> Once you fix that you can just let udev trigger /etc/init.d/bluetooth
>> start, and that will do all the needed magic properly.
>>
>> ... and OpenRC has been doing that for such a long time that I find it
>> hard to understand that people are still not using it
>>
>> I'm still slightly confused what people mean with "event based", I think
>> there are at least three similar, but distinct definitions going around.
>> A good part of that is already handled by the device manager, and the
>> rest appears to be user actions - if someone can find me a good example
>> of an event that doesn't fit into these categories I might understand
>> why from my point of view people seem to be violently agreeing so hard.
> So, what you're saying is that we should fork udev to do things that
> neither its upstream developer nor its Debian maintainer doesn't intend
> for it to do,
Not at all. I'm possibly suggesting actually using udev features, but
then I guess upstream will remove all of them that are fun
> all to make it possible to use an init-system that doesn't
> support events, instead of using an event based system that's designed
> to work with udev?
Somehow I get the feeling that I've asked this before, in which case I'd
be repeating myself, which is very rude of you ... but ... *which* events !?
If it's only device hotplugging / uevents we already have a handler for
that that can execute arbitrary code (udev/mdev), if not then someone
should at some point in time enlighten me what "event based" means to
them so I can finally see why people are disagreeing there. 'cause right
now it looks like violent agreement to me, which makes little sense

>
> Yeah, makes perfect sense...
>
Sense ... if we had some more of that this discussion wouldn't have
started at all


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FA323EA.4000409@gentoo.org">http://lists.debian.org/4FA323EA.4000409@gentoo.org

On 04/26/12 00:42, Roger Leigh wrote:
> On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote:
>> I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
>> have-always-been-there sysvinit/insserv init scripts in Debian.
> While as others have mentioned that ideally a more dynamic init
> system such as systemd or upstart is where I think the general
> consensus is
Define "dynamic" please, and don't use "lines of code changed per month"
as metric
As long as we don't even agree what that (and "event driven") mean it'll
be needlessly confusing for all involved to discuss without a shared
vocabulary.

Have fun,

Patrick


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FA7CE82.70901@gentoo.org">http://lists.debian.org/4FA7CE82.70901@gentoo.org

On 04/26/12 01:49, Marco d'Itri wrote:
> On Apr 25, Patrick Lauer <patrick@gentoo.org> wrote:
>
>> in the last months there have been many discussions about init systems,
>> especially systemd. The current state seems to make no one really happy
> Not true. systemd and upstart do not make /everybody/ happy, but nothing
> does.
Having read the source of both (and how much I laughed!) ...
They do have some mostly good ideas, but ... no thanks. Ideas are cheap,
execution matters.
>
>> I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
>> have-always-been-there sysvinit/insserv init scripts in Debian.
> What we need is an event-driven init system, anything else will just
> make us waste more time.
Waste time where how? and what does "event-driven" mean?
(and how does udev *not* do that already? especially if one assumes that
init scripts have dependencies properly expressed)

[sidenote: a context-free response like "anything else will just waste
time" is the fastest way to get emotional responses that can be
misunderstood so that you can randomly flame everyone and everything.
Not helpful, but kinda fun]

>
>> What we offer you is a modern, slim, userfriendly init system with
> Sorry, no. upstart, systemd or the Apple thing are modern init systems,
> this one is not.
Elaborate please. A random statement like that doesn't allow informed
debates
> But I agree that it would have been nice 5 years ago.
>
Well, Gentoo has had OpenRC for about 5 years, and the predecessor
(which was basically the same, but pure shell scripts whereas openrc has
some bits in C) was written just over a decade ago.

If y'all didn't suffer so much from NIH and "everyone else is silly" you
could have planned the switch 5 years ago and thus wouldn't have
anything to complain about now

Oh well. Your decision, I've enjoyed having named runlevels and such
things for so long that I still wonder how everyone else took a decade
to even think about it ...

Take care (and try to be less passive-agressive in emails),

Patrick


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FA7D451.2070908@gentoo.org">http://lists.debian.org/4FA7D451.2070908@gentoo.org