Re: init observations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux