Re: Definition of _boot_

2012-05-01 Thread Clint Byrum
Excerpts from Ben Hutchings's message of Sun Apr 29 16:27:54 -0700 2012: > On Sun, Apr 29, 2012 at 11:11:08PM +0200, Svante Signell wrote: > > On Sun, 2012-04-29 at 21:52 +0100, Ben Hutchings wrote: > > > On Sun, Apr 29, 2012 at 09:51:37PM +0200, Svante Signell wrote: > > > > Hello, > > > > > > >

Re: Definition of _boot_

2012-05-01 Thread Ben Hutchings
On Tue, May 01, 2012 at 10:36:58PM +0200, Svante Signell wrote: > On Mon, 2012-04-30 at 20:30 +0200, Vincent Bernat wrote: > > OoO En ce doux début de matinée du lundi 30 avril 2012, vers 08:15, > > Svante Signell disait : > > > > >> I'm rather sure that he wants to define booting as part of

Re: Definition of _boot_

2012-05-01 Thread Svante Signell
On Mon, 2012-04-30 at 20:30 +0200, Vincent Bernat wrote: > OoO En ce doux début de matinée du lundi 30 avril 2012, vers 08:15, > Svante Signell disait : > > >> I'm rather sure that he wants to define booting as part of what > >> currently is done in /etc/rcS.d. Configuring the network or mo

Re: Definition of _boot_

2012-04-30 Thread Carsten Hey
* Vincent Bernat [2012-04-30 20:30 +0200]: > OoO En ce doux début de matinée du lundi 30 avril 2012, vers 08:15, > Svante Signell disait : > > >> I'm rather sure that he wants to define booting as part of what > >> currently is done in /etc/rcS.d. Configuring the network or mounting > >> non

Re: Definition of _boot_

2012-04-30 Thread Vincent Bernat
OoO En ce doux début de matinée du lundi 30 avril 2012, vers 08:15, Svante Signell disait : >> I'm rather sure that he wants to define booting as part of what >> currently is done in /etc/rcS.d. Configuring the network or mounting >> non-essential remote file systems wouldn't be part of thi

Re: Definition of _boot_

2012-04-29 Thread Svante Signell
On Sun, 2012-04-29 at 23:48 +0200, Carsten Hey wrote: > * Svante Signell [2012-04-29 21:51 +0200]: > > In line with the recent discussion, lets aim at defining what _boot_ is: > > I'm rather sure that he wants to define booting as part of what > currently is done in /etc/rcS.d. Configuring the ne

Re: Definition of _boot_

2012-04-29 Thread Chow Loong Jin
On 30/04/2012 03:51, Svante Signell wrote: > - starting up the network: yes if network booting, other things can be > done later. > - starting an MTA: no > - staring sshd: no On my remotely administered Debian server, these three are *definitely* part of the boot process, and it's not network boot

Re: Definition of _boot_

2012-04-29 Thread Ben Hutchings
On Sun, Apr 29, 2012 at 11:11:08PM +0200, Svante Signell wrote: > On Sun, 2012-04-29 at 21:52 +0100, Ben Hutchings wrote: > > On Sun, Apr 29, 2012 at 09:51:37PM +0200, Svante Signell wrote: > > > Hello, > > > > > > In line with the recent discussion, lets aim at defining what _boot_ is: > > [...]

Re: Definition of _boot_

2012-04-29 Thread Carsten Hey
* Svante Signell [2012-04-29 21:51 +0200]: > In line with the recent discussion, lets aim at defining what _boot_ is: I'm rather sure that he wants to define booting as part of what currently is done in /etc/rcS.d. Configuring the network or mounting non-essential remote file systems wouldn't be

Re: Definition of _boot_

2012-04-29 Thread Svante Signell
On Sun, 2012-04-29 at 21:52 +0100, Ben Hutchings wrote: > On Sun, Apr 29, 2012 at 09:51:37PM +0200, Svante Signell wrote: > > Hello, > > > > In line with the recent discussion, lets aim at defining what _boot_ is: > [...] > > No, let's not. Beyond RAM, CPU, IRQ controllers and timers (all > of w

Re: Definition of _boot_

2012-04-29 Thread Ben Hutchings
On Sun, Apr 29, 2012 at 09:51:37PM +0200, Svante Signell wrote: > Hello, > > In line with the recent discussion, lets aim at defining what _boot_ is: [...] No, let's not. Beyond RAM, CPU, IRQ controllers and timers (all of which are part of the kernel's early initialisation) pretty much all of t

Re: Definition of _boot_

2012-04-29 Thread Jonathan Nieder
Svante Signell wrote: > In line with the recent discussion, lets aim at defining what _boot_ is: Why? Unless you are suggesting documentation is unclear, I don't see how this has any impact on the development of Debian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a