FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-07-2010, 01:47 PM
Steve Langasek
 
Default Parallellizing the boot in Debian Squeeze - ready for wider testing

On Fri, May 07, 2010 at 03:15:25PM +0200, Julien Cristau wrote:
> On Fri, May 7, 2010 at 14:57:08 +0200, Petter Reinholdtsen wrote:

> > [Aaron Toponce]
> > > I thought Upstart was on the list for release in Sqeeze. Has this changed?

> > > http://lists.debian.org/debian-devel-announce/2009/09/msg00003.html

> > It is still on the wishlist, but the needed pieces are not ready, so
> > it seem unlikely to happen this late in the release process. At the
> > moment, I believe it will happen shortly after Squeeze is released, if
> > the needed pieces are ready by then.

> What are the "needed pieces"?

Upstart doesn't work on any kernels other than Linux. The original goal was
to have a compat layer to pull upstart jobs into the sysvinit system, which
would both address the hurd/BSD kernel issues and allow a soft transition to
upstart where users could opt to stay with sysvinit, but this compat layer
hasn't materialized.

So upstart by default in squeeze would require one of:

- a compat layer for non-Linux ports
- an upstart port to kfreebsd (and ideally hurd)
- a decision to drop kfreebsd as a release architecture

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 05-07-2010, 02:24 PM
Julien Cristau
 
Default Parallellizing the boot in Debian Squeeze - ready for wider testing

On Fri, May 7, 2010 at 15:47:39 +0200, Steve Langasek wrote:

> Upstart doesn't work on any kernels other than Linux. The original goal was
> to have a compat layer to pull upstart jobs into the sysvinit system, which
> would both address the hurd/BSD kernel issues and allow a soft transition to
> upstart where users could opt to stay with sysvinit, but this compat layer
> hasn't materialized.
>
> So upstart by default in squeeze would require one of:
>
> - a compat layer for non-Linux ports
> - an upstart port to kfreebsd (and ideally hurd)
> - a decision to drop kfreebsd as a release architecture
>
Thanks for the explanation, Steve.

Since 1 and 2 aren't happening, I think we should consider going with
the third option. That's assuming there's still time to move to upstart
before the squeeze freeze; if there isn't, that means we should have
decided to drop kfreebsd earlier.

Cheers,
Julien
 
Old 05-07-2010, 03:48 PM
Vincent Danjean
 
Default Parallellizing the boot in Debian Squeeze - ready for wider testing

On 07/05/2010 16:24, Julien Cristau wrote:
> On Fri, May 7, 2010 at 15:47:39 +0200, Steve Langasek wrote:
>
>> Upstart doesn't work on any kernels other than Linux. The original goal was
>> to have a compat layer to pull upstart jobs into the sysvinit system, which
>> would both address the hurd/BSD kernel issues and allow a soft transition to
>> upstart where users could opt to stay with sysvinit, but this compat layer
>> hasn't materialized.
>>
>> So upstart by default in squeeze would require one of:
>>
>> - a compat layer for non-Linux ports
>> - an upstart port to kfreebsd (and ideally hurd)
>> - a decision to drop kfreebsd as a release architecture
>>
> Thanks for the explanation, Steve.
>
> Since 1 and 2 aren't happening, I think we should consider going with
> the third option. That's assuming there's still time to move to upstart
> before the squeeze freeze; if there isn't, that means we should have
> decided to drop kfreebsd earlier.

I would object to this analysis. Having a compat layer would also allow
to stick to sysvinit on linux ports. I think this is very important because
*lots* of system uses local sysvinit scripts and does not have ported them
to upstart (not even to inserv dependency...)
If all linux ports are required to switch to an other thing than sysvinit
for squeeze, I think it will be a bad thing for lots of server admin in the
real world. If this is only the default upgrade path, then this would be
a good think.

About the switch to a new boot system, I reported #576788 to ask for a
good, local, documentation. No answer for now. If it were only me, I would
put this bug RC. But as nobody else complains, I let it normal. I think
that local admin will be hit by hit when they will try to upgrade
their 'stable' Debian server with local specific init scripts.

Regards,
Vincent

> Cheers,
> Julien


--
Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BE43663.6000600@free.fr">http://lists.debian.org/4BE43663.6000600@free.fr
 
Old 05-07-2010, 04:00 PM
Cyril Brulebois
 
Default Parallellizing the boot in Debian Squeeze - ready for wider testing

Since -bsd@ might be interested, Cc-ing them:

Steve Langasek <vorlon@debian.org> (07/05/2010):
> On Fri, May 07, 2010 at 03:15:25PM +0200, Julien Cristau wrote:
> > On Fri, May 7, 2010 at 14:57:08 +0200, Petter Reinholdtsen wrote:
>
> > > [Aaron Toponce]
> > > > I thought Upstart was on the list for release in Sqeeze. Has this changed?
>
> > > > http://lists.debian.org/debian-devel-announce/2009/09/msg00003.html
>
> > > It is still on the wishlist, but the needed pieces are not ready, so
> > > it seem unlikely to happen this late in the release process. At the
> > > moment, I believe it will happen shortly after Squeeze is released, if
> > > the needed pieces are ready by then.
>
> > What are the "needed pieces"?
>
> Upstart doesn't work on any kernels other than Linux. The original goal was
> to have a compat layer to pull upstart jobs into the sysvinit system, which
> would both address the hurd/BSD kernel issues and allow a soft transition to
> upstart where users could opt to stay with sysvinit, but this compat layer
> hasn't materialized.
>
> So upstart by default in squeeze would require one of:
>
> - a compat layer for non-Linux ports
> - an upstart port to kfreebsd (and ideally hurd)
> - a decision to drop kfreebsd as a release architecture

Follow-ups available under:
http://lists.debian.org/debian-devel/2010/05/msg00145.html

Mraw,
KiBi.
 
Old 05-07-2010, 04:15 PM
Marc Haber
 
Default Parallellizing the boot in Debian Squeeze - ready for wider testing

On Fri, 7 May 2010 09:26:18 +0200, Stefano Zacchiroli
<zack@debian.org> wrote:
>The init.d world has changed quite a bit in recent years and might
>change even more in the next, it is possible that for Squeeze+1 we'll
>want to be elsewhere than at CONCURRENCY=makefile.

If we want to be elsewhere for squeeze+1, why do we need to do a
critical migration twice?

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: E1OAQCy-0007LF-Nt@swivel.zugschlus.de">http://lists.debian.org/E1OAQCy-0007LF-Nt@swivel.zugschlus.de
 
Old 05-07-2010, 05:27 PM
Stefano Zacchiroli
 
Default Parallellizing the boot in Debian Squeeze - ready for wider testing

On Fri, May 07, 2010 at 06:15:24PM +0200, Marc Haber wrote:
> On Fri, 7 May 2010 09:26:18 +0200, Stefano Zacchiroli <zack@debian.org> wrote:
> >The init.d world has changed quite a bit in recent years and might
> >change even more in the next, it is possible that for Squeeze+1 we'll
> >want to be elsewhere than at CONCURRENCY=makefile.
>
> If we want to be elsewhere for squeeze+1, why do we need to do a
> critical migration twice?

(Beside the nitpick on "we want" vs "we possibly want") I'd argue that
it's because we want a faster boot from our users ASAP. More
importantly, I was trying to understand whether the migration really is
critical, as the shown bug list didn't seem to imply that.

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c' ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu tous ceux que j'aime
 
Old 05-08-2010, 01:22 AM
Raphael Geissert
 
Default Parallellizing the boot in Debian Squeeze - ready for wider testing

Vincent Danjean wrote:

> Having a compat layer would also allow
> to stick to sysvinit on linux ports. I think this is very important
> because *lots* of system uses local sysvinit scripts and does not have
> ported them to upstart (not even to inserv dependency...)

Support for SysV init scripts is not going to be removed.
The compat layer is to allow non-linux ports to run upstart jobs.

Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: hs2ecp$3qd$1@dough.gmane.org">http://lists.debian.org/hs2ecp$3qd$1@dough.gmane.org
 
Old 05-08-2010, 09:37 AM
Marc Haber
 
Default Parallellizing the boot in Debian Squeeze - ready for wider testing

On Fri, 7 May 2010 19:27:54 +0200, Stefano Zacchiroli
<zack@debian.org> wrote:
>On Fri, May 07, 2010 at 06:15:24PM +0200, Marc Haber wrote:
>> On Fri, 7 May 2010 09:26:18 +0200, Stefano Zacchiroli <zack@debian.org> wrote:
>> >The init.d world has changed quite a bit in recent years and might
>> >change even more in the next, it is possible that for Squeeze+1 we'll
>> >want to be elsewhere than at CONCURRENCY=makefile.
>>
>> If we want to be elsewhere for squeeze+1, why do we need to do a
>> critical migration twice?
>
>(Beside the nitpick on "we want" vs "we possibly want") I'd argue that
>it's because we want a faster boot from our users ASAP.

So it is the classical desktop vs. server situation. For my Debian
servers, that get booted at most once a month, I don't give a damn
about a faster boot.

I _do_ care, however, about not having migrations in the boot process
which has the potential of breaking a system reboot, possibly making
it necessary to obtain a means to access the console in case of
breakage.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: E1OAgT8-0006UO-Nm@swivel.zugschlus.de">http://lists.debian.org/E1OAgT8-0006UO-Nm@swivel.zugschlus.de
 
Old 05-08-2010, 09:47 AM
Julien Cristau
 
Default Parallellizing the boot in Debian Squeeze - ready for wider testing

On Fri, May 7, 2010 at 19:27:54 +0200, Stefano Zacchiroli wrote:

> (Beside the nitpick on "we want" vs "we possibly want") I'd argue that
> it's because we want a faster boot from our users ASAP.
>
As far as I'm concerned, "faster boot" is irrelevant. Using an init
daemon that actually does its job of supervising services, and lets us
get rid of most of the stupidity and boilerplate of init scripts, otoh,
is overdue.

Cheers,
Julien
 
Old 05-08-2010, 09:51 AM
Stefano Zacchiroli
 
Default Parallellizing the boot in Debian Squeeze - ready for wider testing

On Sat, May 08, 2010 at 11:37:10AM +0200, Marc Haber wrote:
> So it is the classical desktop vs. server situation. For my Debian
> servers, that get booted at most once a month, I don't give a damn
> about a faster boot.
>
> I _do_ care, however, about not having migrations in the boot process
> which has the potential of breaking a system reboot, possibly making
> it necessary to obtain a means to access the console in case of
> breakage.

Sure, but I don't think that the server argument should be use to imply
that no changes, that benefit some of our users, are allowed at all.
Ideally, you shouldn't care about boot performance improvements, as long
as they do not introduce new (critical) bugs for your usage scenario.
Whether this is possible or not in the specific case at hand is what
we're all trying to understand in this thread.

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c' ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu tous ceux que j'aime
 

Thread Tools




All times are GMT. The time now is 04:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org