Re: TODO for etch ?

[Bob Proulx]

Brian May wrote:
> ...which of course is a problem if the daemons are required to setup
> the network connection to the NTP server...
> 
> e.g. network tunnels and DNS servers both might need to be started
> first before the NTP server can be contacted.

This is already a long standing problem causing the default ntpdate
configuration to fail out of the box when used in conjuction with a
local caching nameserver.

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245338

Bob


signature.asc
Description: Digital signature

Re: TODO for etch ?

[Tollef Fog Heen]

* Rich Walker 

| email (exim) should start before programs that send email (mailman,
| smartmontools)

No?  /usr/sbin/sendmail usually works when the mail system is down
(and mailman sends out mail itself in the default configuration, so
the only reason for it needing an SMTPd on the host is to receive
incoming mail for the lists.)

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Alban Browaeys]

Le dimanche 19 juin 2005 à 23:22 +0200, Florian Weimer a écrit :
> * Marc Haber:
> 
> > On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer
> > <[EMAIL PROTECTED]> wrote:
> >>That could "save" a grand total of about a second.
> >
> > It will save time in case of error when the bootup process stalls for
> > timeouts like DNS and NTP.
> 
> You should set the clock using NTP *before* starting any daemons.
> Most daemons don't use monotonic clocks (I'm not even sure if Linux
> supports them at the required level), and some of them fail in strange
> ways if the system clock warps.

We need an "interface is ready" target in rcS and move ntpdate to
ifconfig if-up ...
This is tricky and i have no idea yet how to do it ... fix hotplug-net
or deisgn something new (as in hardware and internet ready , let s start
daemons ) ? 

Alban

Re: TODO for etch ?

[Darren Salt]

I demand that Andrew Suffield may or may not have written...

> On Mon, Jun 20, 2005 at 07:22:08PM +0100, Darren Salt wrote:
>> I demand that Florian Weimer may or may not have written...
>>> * Olaf van der Spek:
> You should set the clock using NTP *before* starting any daemons. Most
> daemons don't use monotonic clocks (I'm not even sure if Linux supports
> them at the required level), and some of them fail in strange ways if
> the system clock warps.
 Doesn't Linux or NTP support gradually changing the clock exactly to
 avoid such warps?
>>> Gradually skewing the clock doesn't exactly work that well if the offset
>>> exceeds a few minutes.  You don't want to run with a wrong clock for
>>> hours or even days.
>> Maybe ntp, ntpdate etc. should recommend adjtimex?

> adjtimex is pretty near useless and should not be used. It can make things
> worse rather than better, especially with the clocks in modern boxes (which
> are grossly inaccurate).

I find that it improves matters.

> Under *no circumstances* should adjtimex be used at the same time as ntpd.

That's not a problem here - ntpdate is run regularly, and I don't have a
permanent net connection so (AIUI) ntpd isn't really practical here, and I
don't run it.

> The clock will jitter all over the place because they won't agree and will
> keep slewing it in opposition to each other.

(There's a hint of 'adjtimex is a daemon' about that, but let's ignore that.)

If altering the kernel's system clock rate variables while ntpd is running is
the cause of the problem which you mention, then perhaps it's worth
mentioning that in the ntpd and adjtimex man pages. I don't see that altering
them without a running ntpd should cause a problem (so long as the values
used are good), even if ntpd is then started.

-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| sarge,| Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   Say NO to software patents

File not open, 0:1


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Helmut Wollmersdorfer]

Andrew Suffield wrote:


Under *no circumstances* should adjtimex be used at the same time as
ntpd. The clock will jitter all over the place because they won't
agree and will keep slewing it in opposition to each other.


That's very true - I experienced this.

Helmut Wollmersdorfer


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Andrew Suffield]

On Tue, Jun 21, 2005 at 02:48:14AM +0200, Helmut Wollmersdorfer wrote:
> Darren Salt wrote:
> >I demand that Florian Weimer may or may not have written...
> 
> >>Gradually skewing the clock doesn't exactly work that well if the offset
> >>exceeds a few minutes.  You don't want to run with a wrong clock for hours
> >>or even days.
> 
> >Maybe ntp, ntpdate etc. should recommend adjtimex?
> 
> ntp has its own sophisticated logic if skewing, but does not correct 
> offsets > 500 sec (AFAIK). Having your BIOS clock at local time (e.g. 
> UTC+1), then installing Linux with configuration system clock = UTC, 
> will remain a falseticker. Even offsets of some minutes need a long time 
> to be corrected by ntp.

That's not really true, it's just the default configuration.

Actually the default configuration in Debian is pretty sucky. It
assumes that ntp is used in combination with ntpdate - but ntp
upstream is of the considered opinion that this is a bad plan.

Nowadays, I always change it to add the -g option to ntpd (disabling
the 1000s limit) and the iburst option to the config file (causes ntpd
to sync up in seconds when it starts up, instead of hours, before
entering normal operation).

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: TODO for etch ?

[Andrew Suffield]

On Mon, Jun 20, 2005 at 07:22:08PM +0100, Darren Salt wrote:
> I demand that Florian Weimer may or may not have written...
> 
> > * Olaf van der Spek:
> >>> You should set the clock using NTP *before* starting any daemons. Most
> >>> daemons don't use monotonic clocks (I'm not even sure if Linux supports
> >>> them at the required level), and some of them fail in strange ways if the
> >>> system clock warps.
> >> Doesn't Linux or NTP support gradually changing the clock exactly to avoid
> >> such warps?
> 
> > Gradually skewing the clock doesn't exactly work that well if the offset
> > exceeds a few minutes.  You don't want to run with a wrong clock for hours
> > or even days.
> 
> Maybe ntp, ntpdate etc. should recommend adjtimex?

adjtimex is pretty near useless and should not be used. It can make
things worse rather than better, especially with the clocks in modern
boxes (which are grossly inaccurate).

Under *no circumstances* should adjtimex be used at the same time as
ntpd. The clock will jitter all over the place because they won't
agree and will keep slewing it in opposition to each other.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: TODO for etch ?

[Helmut Wollmersdorfer]

Darren Salt wrote:

I demand that Florian Weimer may or may not have written...



Gradually skewing the clock doesn't exactly work that well if the offset
exceeds a few minutes.  You don't want to run with a wrong clock for hours
or even days.



Maybe ntp, ntpdate etc. should recommend adjtimex?


If, then only ntpdate + adjtimex is a good combination.

ntp has its own sophisticated logic if skewing, but does not correct 
offsets > 500 sec (AFAIK). Having your BIOS clock at local time (e.g. 
UTC+1), then installing Linux with configuration system clock = UTC, 
will remain a falseticker. Even offsets of some minutes need a long time 
to be corrected by ntp.


Chrony can correct hours very fast.

Helmut Wollmersdorfer


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Darren Salt]

I demand that Florian Weimer may or may not have written...

> * Olaf van der Spek:
>>> You should set the clock using NTP *before* starting any daemons. Most
>>> daemons don't use monotonic clocks (I'm not even sure if Linux supports
>>> them at the required level), and some of them fail in strange ways if the
>>> system clock warps.
>> Doesn't Linux or NTP support gradually changing the clock exactly to avoid
>> such warps?

> Gradually skewing the clock doesn't exactly work that well if the offset
> exceeds a few minutes.  You don't want to run with a wrong clock for hours
> or even days.

Maybe ntp, ntpdate etc. should recommend adjtimex?

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| sarge,| youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   Let's keep the pound sterling

You will be travelling and coming into a fortune.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Brian May]

> "Florian" == Florian Weimer <[EMAIL PROTECTED]> writes:

Florian> You should set the clock using NTP *before* starting any
Florian> daemons. 

...which of course is a problem if the daemons are required to setup
the network connection to the NTP server...

e.g. network tunnels and DNS servers both might need to be started
first before the NTP server can be contacted.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Florian Weimer]

* Olaf van der Spek:

>> You should set the clock using NTP *before* starting any daemons.
>> Most daemons don't use monotonic clocks (I'm not even sure if Linux
>> supports them at the required level), and some of them fail in strange
>> ways if the system clock warps.
>
> Doesn't Linux or NTP support gradually changing the clock exactly to
> avoid such warps?

Gradually skewing the clock doesn't exactly work that well if the
offset exceeds a few minutes.  You don't want to run with a wrong
clock for hours or even days.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Olaf van der Spek]

On 6/19/05, Florian Weimer <[EMAIL PROTECTED]> wrote:
> * Marc Haber:
> 
> > On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer
> > <[EMAIL PROTECTED]> wrote:
> >>That could "save" a grand total of about a second.
> >
> > It will save time in case of error when the bootup process stalls for
> > timeouts like DNS and NTP.
> 
> You should set the clock using NTP *before* starting any daemons.
> Most daemons don't use monotonic clocks (I'm not even sure if Linux
> supports them at the required level), and some of them fail in strange
> ways if the system clock warps.

Doesn't Linux or NTP support gradually changing the clock exactly to
avoid such warps?

Re: TODO for etch ?

[Marc Haber]

On Sun, 19 Jun 2005 23:22:01 +0200, Florian Weimer <[EMAIL PROTECTED]>
wrote:
>* Marc Haber:
>> On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer
>> <[EMAIL PROTECTED]> wrote:
>>>That could "save" a grand total of about a second.
>>
>> It will save time in case of error when the bootup process stalls for
>> timeouts like DNS and NTP.
>
>You should set the clock using NTP *before* starting any daemons.

This is a _should_, but there are situations where this is not
possible. A common case where ntp is not available at startup (and the
timeout delay _not_ appreciated) is when a complete machine park at an
ISP was shutdown (for example during move, power works or an
emergency) and is now re-started. The firewalls usually depend on the
NTP and DNS servers which they protect, so if you start the NTP
servers first, the firewalls are not there so there is nothing to sync
from, and when you start the firewalls first, the NTP servers are not
there so there is nothing to sync from again.

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

Re: TODO for etch ?

[Steve Langasek]

On Sun, Jun 19, 2005 at 04:04:24PM +0100, Jon Dowland wrote:
> On Sun, Jun 19, 2005 at 04:16:28PM +0200, Petter Reinholdtsen wrote:
> > [Adam Majer]
> > > That could "save" a grand total of about a second. Also, during
> > > startup the bottleneck is the hard drive in many cases so starting
> > > concurrently might not speed up your boot process significantly.

> > Do you have any good references document this fact?  I've seen
> > articles documenting a speedup when things are started in parallell,
> > so I wounder where you got your information from.

> I think the redhat people who are working on this are getting the most
> benefit from a large disk read-ahead, prior to the main services being
> started. If that accounted for the majority of speed-up, maybe it alone,
> and not a fragile parallel boot process too, would be sufficient for
> most people in need of a more efficient boot.

The boot process is already fragile.  The strict ordering of boot scripts
means that any changes to the rank of one script will cause ripple effects
affecting any other scripts depending on it, which may go undetected for
long periods of time; and the available update-rc.d interface makes it more
or less impossible to automatically correct a wrongly-ordered startup script
without either losing local configuration or failing to handle systems that
don't use sysv-rc.

Switching to a sound dependency-based init system would solve the above, and
let people experiment with parallel startup or not, as they want.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: TODO for etch ?

[Florian Weimer]

* Marc Haber:

> On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer
> <[EMAIL PROTECTED]> wrote:
>>That could "save" a grand total of about a second.
>
> It will save time in case of error when the bootup process stalls for
> timeouts like DNS and NTP.

You should set the clock using NTP *before* starting any daemons.
Most daemons don't use monotonic clocks (I'm not even sure if Linux
supports them at the required level), and some of them fail in strange
ways if the system clock warps.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Marc Haber]

On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer
<[EMAIL PROTECTED]> wrote:
>That could "save" a grand total of about a second.

It will save time in case of error when the bootup process stalls for
timeouts like DNS and NTP.

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

Re: TODO for etch ?

[John Hasler]

Adam Majer writes:
> The biggest problem is debugging. Sure, you can fork and start all of the
> processes concurrently, but what about if the start fails?

Then you restart with "--serial".

> You also want to have some processes started before others so you need
> asynchronous instead of synchronous waits...

Which is why you need dependencies.

> Alternatively, don't start Apache and Postgres on your workstation to
> save a second or two in the boot process.

I use Apache and PostgreSQL on my workstation.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Jon Dowland]

On Sun, Jun 19, 2005 at 04:16:28PM +0200, Petter Reinholdtsen wrote:
> [Adam Majer]
> > That could "save" a grand total of about a second. Also, during
> > startup the bottleneck is the hard drive in many cases so starting
> > concurrently might not speed up your boot process significantly.
> 
> Do you have any good references document this fact?  I've seen
> articles documenting a speedup when things are started in parallell,
> so I wounder where you got your information from.

I think the redhat people who are working on this are getting the most
benefit from a large disk read-ahead, prior to the main services being
started. If that accounted for the majority of speed-up, maybe it alone,
and not a fragile parallel boot process too, would be sufficient for
most people in need of a more efficient boot.

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Petter Reinholdtsen]

[Adam Majer]
> That could "save" a grand total of about a second. Also, during
> startup the bottleneck is the hard drive in many cases so starting
> concurrently might not speed up your boot process significantly.

Do you have any good references document this fact?  I've seen
articles documenting a speedup when things are started in parallell,
so I wounder where you got your information from.

http://initng.thinktux.net/index.php/Boot_charts_Official>
indicate that a sigificant speedup is possible, and I would really
love to speed up the debian boot sequence.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Adam Majer]

On Sat, Jun 18, 2005 at 10:14:27PM -0500, Gunnar Wolf wrote:
> Adam Majer dijo [Wed, Jun 15, 2005 at 01:15:00PM -0500]:
> > > - Change boot system, to one capable of handling dependencies and
> > >   parallell invocation, to speed up the boot process.
> > >  
> > >
> > Err.. Why? The current "slow" bootup is caused mostly by hardware
> > detection from my experience. Speeding up hardware detection or remove
> > it in favour of manual /etc/modules entries would speed up the boot
> > process a lot more than changing the boot process. If it ain't broke, do
> > not fix it.
> 
> My systems have no hardware detection at all - But they start many
> daemons at boot time. Probably, say, Apache and Postgres could be
> started concurrently, saving some extra time.

That could "save" a grand total of about a second. Also, during
startup the bottleneck is the hard drive in many cases so starting concurrently
might not speed up your boot process significantly.

The biggest problem is debugging. Sure, you can fork and start all of
the processes concurrently, but what about if the start fails? You
also want to have some processes started before others so you need
asynchronous instead of synchronous waits... Blah..

Anyway, you can test your maximum speedup like this,

1. Get a list of all the /etc/init.d/ scripts you want to start.
2. Start the sequentially while timing them.
3. Now start them concurrently and time them. When all /etc/init.d/
scripts terminate, that is when you are done.
4. What is the difference?

If you are using bash for this, the easiest way might be to trap
SIGCHLD or something to check when the child terminates.

Alternatively, don't start Apache and Postgres on your workstation to
save a second or two in the boot process. :P

- Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Gunnar Wolf]

Adam Majer dijo [Wed, Jun 15, 2005 at 01:15:00PM -0500]:
> > - Change boot system, to one capable of handling dependencies and
> >   parallell invocation, to speed up the boot process.
> >  
> >
> Err.. Why? The current "slow" bootup is caused mostly by hardware
> detection from my experience. Speeding up hardware detection or remove
> it in favour of manual /etc/modules entries would speed up the boot
> process a lot more than changing the boot process. If it ain't broke, do
> not fix it.

My systems have no hardware detection at all - But they start many
daemons at boot time. Probably, say, Apache and Postgres could be
started concurrently, saving some extra time.

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Paul TBBle Hampson]

On Thu, Jun 16, 2005 at 03:05:52PM +0200, Marco d'Itri wrote:
> On Jun 16, Paul TBBle Hampson <[EMAIL PROTECTED]> wrote:

> > And there there's hotplug-ng [1], a hotplug replacement in C, which I'm
> > looking forward to a packaging of, now that klibc's in the ITP list.

> You'd better not, because I have already ITP'ed it a long time ago. :-)

Ooops. I meant I look forward to it being packaged, not to packaging it myself.

I want to _use_ it, since my laptop's boot time is currently approximating the
time of any given task I do when using it.

^_^

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgpzHcT7Dw7KM.pgp
Description: PGP signature

Re: TODO for etch ?

[Marco d'Itri]

On Jun 16, Paul TBBle Hampson <[EMAIL PROTECTED]> wrote:

> And there there's hotplug-ng [1], a hotplug replacement in C, which I'm
> looking forward to a packaging of, now that klibc's in the ITP list.
You'd better not, because I have already ITP'ed it a long time ago. :-)

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: TODO for etch ?

[Paul TBBle Hampson]

On Wed, Jun 15, 2005 at 01:26:04PM -0500, Adam Majer wrote:
> Jesus Climent wrote:

> >On Fri, Jun 10, 2005 at 11:39:16PM +0400, Nikita V. Youshchenko wrote:
> >  

> >- get rid of hotplug in its actual incarnation. Is hell of slow and
> >  painful.

> I agree that it is a bit slow :) But again, this is a single package
> problem more suited for BTS. For example see bug #309588 where there is
> a patch to speed up hotplug.

And there there's hotplug-ng [1], a hotplug replacement in C, which I'm
looking forward to a packaging of, now that klibc's in the ITP list.

While hotplug being slow is a single-package problem, having an alternate,
faster hotplug package _should_ be on the etch TODO, even if only as a
"needs investigating" entry.

[1] http://www.kerneltraffic.org/kernel-traffic/kt20050329_300.html#2

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgpEEJ8B2CX9J.pgp
Description: PGP signature

Re: TODO for etch ?

[Jesus Climent]

On Wed, Jun 15, 2005 at 01:26:04PM -0500, Adam Majer wrote:
>
> >- Early start of X, while some other stuff is still loading on the bg.
> >
> That's a single package "problem" so not exactly an Etch todo candidate.
> But I think the real problems for slow boots is the hardware detection.

No, it needs a good integration, since you dont want to have X working already
before ldap clients/servers, network,... is up.

I have read reports on people login in X before network/ldap was up, so they
actually could not.

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

The fool looks at a finger that points at the sky.
--The Sacré-Coeur Boy (Amelie)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Rich Walker]

Adam Majer <[EMAIL PROTECTED]> writes:

> Petter Reinholdtsen wrote:
>
>> - Change boot system, to one capable of handling dependencies and
>>   parallell invocation, to speed up the boot process.
>>  
>>
> Err.. Why? The current "slow" bootup is caused mostly by hardware
> detection from my experience. Speeding up hardware detection or remove
> it in favour of manual /etc/modules entries would speed up the boot
> process a lot more than changing the boot process. If it ain't broke, do
> not fix it.

At present, almost everything installs itself in runlevel 20. This kind
of suggests that almost everything is order-independent. But this isn't
true: the raid and device mapper stuff *has* to have the right order, or
your boot fails. Other stuff probably has subtle ordering constraints
that are not being managed: the system "just works". 

Example:
foo:~--# ls /etc/rc5.d/
K11anacron   S19ssh   S20diald  S20klisa  
S20setkey  S50systune
K90metalog   S19userv S20exim   S20lprng  
S20smartmontools   S50wu-ftpd
S10ipchains  S20alsa  S20exim4  S20mailman
S20smartsuite  S83chrony
S10iptables  S20amavis-ng S20famS20makedev
S20swapd   S89anacron
S10metalog   S20apache-perl   S20firestarterS20mdnsresponder  
S20sysstat S89atd
S10sysklogd  S20arpwatch  S20firewall-easy  S20mon
S20teapop  S89cron
S11klogd S20atop  S20framerdS20mysql  
S20totdS90samba
S12kerneld   S20autofsS20gpmS20netsaint   
S20wwwoffleS91apache
S13genpower  S20binfmt-supportS20greylist   S20nfs-kernel-server  
S20xfs S91apache-ssl
S14ppp   S20cfengine2 S20hddtempS20nut
S20xprint  S99fetchmail
S18portmap   S20clamav-daemon S20hylafaxS20p3scan 
S21nfs-common  S99kdm
S19amavisS20clamav-freshclam  S20inetd  S20pdnsd  
S23ntp-server  S99rmnologin
S19bind  S20crywrap   S20iptotalS20postgresql 
S30squid   S99stop-bootlogd
S19nis   S20cupsysS20isdnutils  S20queue  
S31sqcwa   S99xdm
S19slapd S20daapd S20jmon   S20rsync  
S31squid-prefetch
S19spamassassin  S20dcc-clientS20junkbuster S20sauce  
S45usbmgr


Now, I may have tweaked a few things in there, but it seems to me that

firewalls should start after networking and before network-using things

email (exim) should start before programs that send email (mailman,
smartmontools)

databases should probably run after filesystems, firewalls, system
monitors, swap daemons, and so forth.

and there are probably a few other easy deductions.

Switching to a "make -j runlevel5"-type system (dependencies encoded in
makefile fragments, some kind of "foo Provides firewall" structure, and
(hard) a method for stopping things as well as starting them would

(a) allow parallel startup, important for some users
(b) allow correct ordering to be specified

cheers, Rich.



-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Bartosz Fenski aka fEnIo]

On Wed, Jun 15, 2005 at 01:15:00PM -0500, Adam Majer wrote:
> > - Change boot system, to one capable of handling dependencies and
> >   parallell invocation, to speed up the boot process.
> >  
> Err.. Why? The current "slow" bootup is caused mostly by hardware
> detection from my experience. Speeding up hardware detection or remove
> it in favour of manual /etc/modules entries would speed up the boot
> process a lot more than changing the boot process. If it ain't broke, do
> not fix it.

I don't use any hardware detection and my boot process _is_ slow.

I tried on some test machine initng[1] once and it really speeds up boot
process. It can be viewed on some charts[2].

regards
fEnIo

[1] - http://initng.thinktux.net/
[2] - http://initng.thinktux.net/index.php/Boot_charts_Official


-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Re: TODO for etch ?

[Adam Majer]

Jesus Climent wrote:

>On Fri, Jun 10, 2005 at 11:39:16PM +0400, Nikita V. Youshchenko wrote:
>  
>
>>Hello.
>>
>>- 
>>
>>
>
>- Early start of X, while some other stuff is still loading on the bg.
>  
>
That's a single package "problem" so not exactly an Etch todo candidate.
But I think the real problems for slow boots is the hardware detection.

>- get rid of hotplug in its actual incarnation. Is hell of slow and
>  painful.
>  
>
I agree that it is a bit slow :) But again, this is a single package
problem more suited for BTS. For example see bug #309588 where there is
a patch to speed up hotplug.

- Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Adam Majer]

Petter Reinholdtsen wrote:

>>- 
>>
>>
>
> - Improve hardware detection, make sure excluded kernel modules only
>   need to be listed one place.
>  
>
OK. Something to improve uppon.

> - Replace default syslog-daemon to one capable to storing
>   severity/facility in the log file.
>  
>
People can install their own syslog replacement. I don't see a reason
why we need to change something that works now for most people.

> - Change boot system, to one capable of handling dependencies and
>   parallell invocation, to speed up the boot process.
>  
>
Err.. Why? The current "slow" bootup is caused mostly by hardware
detection from my experience. Speeding up hardware detection or remove
it in favour of manual /etc/modules entries would speed up the boot
process a lot more than changing the boot process. If it ain't broke, do
not fix it.

- Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Jesus Climent]

On Fri, Jun 10, 2005 at 11:39:16PM +0400, Nikita V. Youshchenko wrote:
> Hello.
> 
> - 

- Early start of X, while some other stuff is still loading on the bg.

- get rid of hotplug in its actual incarnation. Is hell of slow and
  painful.

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

Coffee and cigarettes. That's like the breakfast of champions.
--Bob (Blue in the Face)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Bill Allombert]

On Sat, Jun 11, 2005 at 10:44:14PM +0200, Joerg Friedrich wrote:
>   - improved menu system:
> 
> I'd like to have the possibilty to hide some programs from the users
> menu, or from groups of users.
> 
> present them a 'smaller default' 
> 
> and let them easily adjust their personal menu

You can already to that, ask on the custom Debian distibutions list.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Joerg Friedrich]

Nikita V. Youshchenko schrieb am Freitag, 10. Juni 2005 um 23:39:16 +0400:
> - 

My wishlist as a user:
  - Finer graded task selection while installation like Javier already
wrote in "And now for something..." :-)

  as a sysadmin:

  - debtags support in the package system, since I often spend time
searching the right application by google and then checking it it's
already packaged

  - improved menu system:

I'd like to have the possibilty to hide some programs from the users
menu, or from groups of users.

present them a 'smaller default' 

and let them easily adjust their personal menu




-- 
Jörg Friedrich

There are only 10 types of people:
Those who understand binary and those who don't.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Nico Golde]

Hallo Adrian,

* Adrian von Bidder <[EMAIL PROTECTED]> [2005-06-11 17:23]:
> On Friday 10 June 2005 21.39, Nikita V. Youshchenko wrote:
> > Hello.
> >
> > Is the TODO list for etch available anywhere?
> 
> It is now.
> 
> 
> 
> Please help updating it.  Because I really mean it, I repeat here the 
> guidelines that I feel can keep this list useful instead of providing a 
> battleground for edit-wars...

[...] 
What about writing it to http://www.debian.org/devel/todo
Or maybe link the wiki site on it?
Regards Nico
-- 
Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpsngZHGPTRM.pgp
Description: PGP signature

Re: TODO for etch ?

[Olaf van der Spek]

Nikita V. Youshchenko wrote:

Since I can't find such a list, I'll try to write (a beginning of) one.


Shouldn't such a list be maintained in a Wiki or at least on a web page?
100+ different posts with a few entries don't make sense.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Adrian von Bidder]

On Friday 10 June 2005 21.39, Nikita V. Youshchenko wrote:
> Hello.
>
> Is the TODO list for etch available anywhere?

It is now.



Please help updating it.  Because I really mean it, I repeat here the 
guidelines that I feel can keep this list useful instead of providing a 
battleground for edit-wars...

 - Don't list issues with single packages here - we have the bug tracking 
system for this! http://bugs.debian.org
 - Don't list proposals here on how the Etch release should be managed. 
There is ReleaseProposals for this.
 - For all issues, please try to provide links to mailing list discussions 
etc. - while the Wiki is good for keeping track of issues up to some point, 
it is not a good discussion medium imho. So, if you list controversial 
issues here, DON'T discuss these things here and don't just remove them - 
add links to relevant parts of the mailing list archives.

(obviously, this is not a 'etch won't be released until this list is empty' 
kind of thing, but rather a 'things that could be done better in etch' 
list.

greetings
-- vbi

-- 
Try not.
Do.
Or do not.
There is no try.


pgp0iiKOCTfqU.pgp
Description: PGP signature

Re: TODO for etch ?

[Andreas Schuldei]

On Fri, Jun 10, 2005 at 11:39:16PM +0400, Nikita V. Youshchenko wrote:
> Hello.
> 
> Is the TODO list for etch available anywhere?

- multi level configuration for poplular services and some other
  unpopular ones
  (needed for cdds)

- change policy to allow for automatic reconfiguration of packages
  (needed for cdds)

- allow apt to install special configuration packages (which
  pre-seed debconf or supply configuration by other means before
  the packages that are to be pre-configured) are installed or
  reconfigured
  (important for modularized preconfigured subsystems) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Petter Reinholdtsen]

[Nikita V. Youshchenko]
> Is the TODO list for etch available anywhere?

I'm not aware of any.

> - 

 - Improve hardware detection, make sure excluded kernel modules only
   need to be listed one place.

 - Replace default syslog-daemon to one capable to storing
   severity/facility in the log file.

 - Change boot system, to one capable of handling dependencies and
   parallell invocation, to speed up the boot process.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[George Danchev]

On Saturday 11 June 2005 00:56, Adam Majer wrote:
> Nikita V. Youshchenko wrote:
> >Since I can't find such a list, I'll try to write (a beginning of) one.
> >
> >- Complete transition to g++ 3.4/4.0 ABI
> >- Resolve FDL issue
> >- Get Xorg and KDE 3.4 into the archive. [as time passes, the version
> > number may change]
> >- (?) multiarch
>
> I'm not sure about multiarch, but the following will most likely happen,
> * Amd64 port officially added,
> * The "scc" archive split to lighten load on mirrors for stuff that
> only needs one or two mirrors anyway,

Then you can have it other way (instead of having scc arches, have scc 
mirrors). If there is enough man & buildd power & users (remember that human 
help and hardware donations have being proposed many times) for an arch 
currently supported then you can have second class mirrors (partial ones) and 
first class ones carrying all arches. In fact I think that it is not a rare 
situation where the primary country mirror really doesn't carry all arches, 
but there are other mirrors which track them all. Here is an example with the 
primary / but partial / ftp.bg.debian.org (debian-cd just x86) [1] and 
ftp.uni-sofia.bg (a secondary one tracking all arches, including full 
debian-cd, debian-amd64, debian-volatile, and this is not just for fun and 
completeness). There is also at least one secondary one. So I'm afraid that 
your decision based on currently primary mirrors not tracking all arches for 
various reasons could be broken source for generalizations. I'm also sure 
that this is not a single example that could be given. If the Debian Project 
decides to cut some arches, then you wont wait a lot to see various external 
and unofficial archives like: 
debian-$scc-for-Debian-but-supported-by-

[1]http://kitenet.net/~joey/blog/entry/d-i_scc_ready_already-2005-05-18-23-47.html

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Adam Majer]

Nikita V. Youshchenko wrote:

>Since I can't find such a list, I'll try to write (a beginning of) one.
>
>- Complete transition to g++ 3.4/4.0 ABI
>- Resolve FDL issue
>- Get Xorg and KDE 3.4 into the archive. [as time passes, the version number
>may change]
>- (?) multiarch
>  
>
I'm not sure about multiarch, but the following will most likely happen,
* Amd64 port officially added,
* The "scc" archive split to lighten load on mirrors for stuff that
only needs one or two mirrors anyway,
* finally get new apt (6.x) included.

There will be a lot of other new stuff in the archive, but I don't think
we will need an official TODO list for that (eg. Qt 4).

- Adam



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

[Roberto C. Sanchez]

On Fri, Jun 10, 2005 at 11:39:16PM +0400, Nikita V. Youshchenko wrote:
> Hello.
> 
Hi.

> - 
> 

OpenOffice.org 2 will be a fairly large undertaking, AIUI.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


pgpjmspx9bgke.pgp
Description: PGP signature