On 11/15/05, Paul A Houle <ph18@xxxxxxxxxxx> wrote: > In the past, boot times have been a major complaint of ordinary > consumers. You missed my point entirely. Why are we considering all "start up" situations as "full boot" scenarios? Why isn't focusing on suspend to disk scenarios a better win? > Laura's first complaint about the machine was that it took forever > to boot, and I realized she was right. I took about 2/3 of the stuff > out of the boot sequence (HP laserjet drivers, asian language input > methods...), and things got a lot better. And if we focused instead on a robust suspend that most users could use... how often would such a system need to do a full reboot instead of a suspend? Every kernel update? > > FC3 and RHEL 4 made a great leap forward. When I installed RHEL 4 > on an old 400 MhZ machine, I booted the machine for the first time, > turned my back on it, expected it to still be grinding, and was amazed > to see that it was already up! Right.. improvement without having to reach for parallelzation. We still don't have a direct side by side comparison of a "default" set of services that shows that paralization is going to be a worthwile win on average hardware..let alone legacy hardware like a 400 Mhz machine with what I imagine is below average ram compared to desktops shipping now. You want to see a bootup process slowdown..have it start swapping out memory because of competing processess. I have not seen a convincing argument that parallelization can get to a boot time much lower than continued optimization of the default init process we have right now. The big win, is suspend to disk, so that you can avoid doing the full boot on day to day shutdown and restarts. > The starting and stopping experience makes a big difference in the > experience of a computer. If it takes forever to boot your computer, > you leave it on all the time, wasting electricity and being a bigger > target for hackers. I'm not arguing that.. I'm arguing that most day to day startup situations do not have to be "full boot" situations they could be "recover from suspend" and avoid service startup completely. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
