On 6/6/06, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
[Gustavo Franco] > Well, it seems to be obvious but before somebody else suggest this, > insserv won't be included in the 'desktop environment' nor in other > task (tasksel) by default. Perhaps not, but having it around make it easier to argue that the dependency information provided in the init.d scripts is useful. And if someone come up with an alternative system using the same dependency information, it will be a set forward anyway. I believe the most important feature of this dependency info at the moment is the fact that it allow us to automatically detect errors in the boot sequence. The more script include dependency info, the more confidence can we have in the current fixed boot sequence.
Sure, i wasn't discarding insserv or its usage. I just pointed out the tasksel status.
> I think we should change the boot to run in parallel ASAP by > default, and work to fix the bugs we introduced (if any). I'm not sure if that is a good idea. It will make the boot system non-deterministic, and I am not sure the speedup gain is significant enough to warrant that. I want to see numbers from the testing done by the SoC student before recommending to turn on parallel booting by default.
Ok, btw my related blog post is below for reference: http://stratusandtheswirl.blogspot.com/2006/05/in-2-minutes-you-can.html#links
> That's possible that with this first step, we will be already > forcing more maintainers to be friendly with our "LSB headers" > related bugs. I don't know who is behind this decision, but release > team could help us saying if it's a sane goal for Etch or Etch+1 > stuff only. Personally I suspect etch+1 is the sensible place to make parallel booting the default, and that we should only aim to get the dependency information in place for etch.
Sad but true. :( Btw, do we have any fallback in mind for desktop users in Etch? Eg.: Enable parallel booting just if the users install "desktop environment" task through some way. Either way, that would be good cut the boot times for Etch even if won't use parallel booting by default. We can do that in many different ways, right now, with some already being discussed in -devel. It's up to the SoC student work on the project that he sent to Google, and it's up to us deliver a better Etch and include his work in Etch+1 if not possible right now, IMHO.
(...)
regards, -- stratus _______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
