On Thu, 30 Oct 2003, Vedran Ljubovic wrote: > --- Jos <[EMAIL PROTECTED]> wrote: > > http://www.stack.nl/~josh/Mandrake > > Hello Jos! > > I think you have an excellent page there. > > Here are some thinkings: > > - Harddrake should *not* be disabled by default. If > one changes some piece of hardware (they'll probably > do that while their system is off :) strange things > may happen to their system. You may not change your > hardware often, but I for example have my case on > Removing harddrake might be sensible for laptops and > computers that are known to be black-boxes (servers, > non tech-savvy users; I'd like to make that call > myself).
My point is that someone who changes hardware knows what he is doing, and pressing "H" at boot time to run harddrake is only a small step after hacking your hardware. 95% of the users will never change hardware, or it must be an usb stick, which should not heb handled by harddrake, for harddrake only detects at boot time. (My system comes with /dev/sda1 not found while mounting filesystems for I happened to have an USB stick in my machine during the install of 9.2. Have been too lazy to fix it yet.) > - I don't think parallelizing helps on computers with > a single CPU that doesn't support hyperthreading. Sure Not true I think... Think about initializing network cards with a dhcp server. This isn't a busy wait. It is one of the few examples that really matter, but ok. We need benchmarks to see what's true. > we both need hard figures to back up our claims, but I > believe the effort can be spent much better by > rethinking some services and making their selection > smarter! Think about it: > * laptops don't need harddrake (4 seconds) > * people without a network card don't need > NFS/SMB/TMDNS (3-4 seconds) > * people not sharing printers and scanners can afford > to start cups and scannerdrake after the desktop is up > (10 seconds) Also shared printers can be set up after the desktop is there, though indeed, for real servers you might want to change priority. My problem is how to do implement your suggestions (which I agree with) in a neat way? > and other such examples. That's 18 seconds or more > than 20% of overall boot-up time. I don't think > parallelization can bring that much benefit. > Also consider splitting harddrake in part that is > needed to run X (detecting video card, monitor and > mouse) and the rest that runs after the desktop is up. > It can even show a nice GUI for new hardware :) What > else can be delayed after the GUI is up? Harddrake isn't _THAT_ slow, splitting it up would cause more overhead. /me wonders if XFree can be stripped. 99 % of the users will never use the remote connect features of X. I'm not an X expert, are the remote connect features and such loaded when X starts ? Oh and of course the reason X / KDE / Gnome boots so slow: the ELF file format... > To people bashing windows for this: please think about > it, it's a feature. I want to start doing productive > things as soon as possible. This is a desktop machine > we're talking about. I don't care if 90% of hardware > isn't working yet if I can startup my > editor/browser/e-mail program (sometimes I want to > hack rc so openoffice is started before everything > else, so i don't have to wait 20 sec for it ;) If your network card is useless, you can't open email :) So it's not that easy... What is the limit of non-working hardware ? > - I agree completely on depmod. > > - I also agree that using bash slows down things. But > I don't think that writing rc script itself in C will > help much. rc script is only a small portion of > overhead, I think that the bigger problem are scripts > in init.d that are 100% bash, such as devfsd script > that makes a bunch of symbolic links and stuff. That's not the issue. The issue is that a binary isn't hackable anymore. Using binaries will cause some unix freaks to run away. I used a binary for /etc/rc.d/rc for that script isn't interesting, and scripts don't allow multithreading. Another solution hacks init, drops /etc/rc.d/rc and calls everything directly. Question is: what is right ? do we (Mandrake) care about dropping standards in favour of a few seconds ? > One another thing: consider the services that already > work in background: scannerdrake, usb detection, xfs, > apmd, cups, crond, xinetd, kheader, devfsd. > Parallelizing tasks is as easy as adding a & to > appropriate script. And finding the dependencies, which is a nice puzzle sometimes :) Jos
