Hello, I agree with most of your points.
--- Jos Hulzink <[EMAIL PROTECTED]> wrote: > On Thu, 30 Oct 2003, Vedran Ljubovic wrote: > > - 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. You could isolate all such cases and fork & them. I agree that it would be much nicer to have a signle file that sets all dependencies in a clean style. But it a) takes time to implement, and more importantly bug-proof! (but if you already did it, then kudos to you!) b) is nonstandard - as in administrators coming from other unix/linux systems would be completely lost. > > * 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? Also consider that some people use a dm to login, while others use auto-login feature and go directly to desktop... it's not easy, there are really two realistic options: - start services when needed (e.g. start cups only when i try to print something) but it would require hacking kde or - use an arbitrary delay before starting a service and renice it so that user experience is not harmed. I think this second solution is not that bad, what do you think? > 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 ? Ok, so we agree that network is immediately necessary for desktop, while printing and scanning are not. What else? Through such discussion we could reach a list of services that can be delayed until after the desktop is up. > 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 ? I've read a very convincing post on Slashdot about this. Basically, bash is loaded immediately after kernel is booted and subsequent calls do not cause any overhead. Bash is also very fast. I'd like to see exact benchmarks of using c vs. bash in any of these scripts, given that all other circumstances are the same. Also, if you are going to use posix threads in C than good for you, but otherwise old-style threads are nothing but processes and multi-processing can be achieved in shell with fork operator. > > 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 > __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
