Power-on to GUI in 20 seconds

[Mitch Bradley]

Jim Gettys wrote:
> I will note that in January, no less than Gordon Bell congratulated us
> on how fast our boot was (slow though we consider it...).
>
> While for developers making it go faster may be worth some effort just
> to save developer time,

It's not about saving developer time - it's about
a) saving user time, and
b) simplifying the system to the extent that it is possible to actually 
understand it

Making the resume faster will extend the battery life by making it 
possible for us to sleep more often, but it won't otherwise make the 
user experience much better.  1-second resume is plenty fast for 
intentional sleeps.

We certainly do need to keep working on extending the battery life, but 
no matter how well we do, we aren't going to get to the point where 
batteries hardly ever run down.  There is always going to be a fair 
amount of rebooting, and to the extent that rebooting happens quickly, 
we look good and the users are pleased.

Re (b) - I have studied the system startup sequence in great detail, and 
it is so complicated/bloated that it almost defies understanding.  Huge 
chunks of the complexity are there to support big-iron configurations 
that have nothing to do with us.  The framework is designed to handle 
the problem that Red Hat faces - they have to work on any one of an 
almost infinite number of configurations.  So they need a 
bulldozer-class chassis.  But we are trying to build a souped up 
wheelbarrow, not a bulldozer.

What is the penalty of carrying around this complexity?  The main 
penalty is that it's all so big that understanding it is nearly a 
full-time job, and if you can't understand something well, you can't fix 
it or improve it.

Which leads me to:

Why are we still at 1.3 seconds resume time even though our hardware can 
go about 25x faster?  It is because Linux itself is so complicated.  
That complexity makes it very hard to track down exactly what is 
happening and harder still to change anything without breaking something 
else. And on top of that, Linux is alway changing, so we have to spend a 
lot of time just tracking changes, further reducing our ability to do 
anything.

Complexity always costs you.  Always.

> (if the effort is small), we should keep our eye
> on the prize of fast suspend/resume.  We're at 1.3 seconds; our hardware
> is good to .05 seconds....  
>                           - Jim
>
>
> On Fri, 2008-08-29 at 08:38 -1000, Mitch Bradley wrote:
>   
>> pgf wrote:
>>
>>     
>>> bert wrote:
>>>  > Am 29.08.2008 um 15:34 schrieb pgf at laptop.org:
>>>  > 
>>>  > > bert wrote:
>>>  > >> http://www.youtube.com/watch?v=-0fAUGRUDVA
>>>  > >>
>>>  > >> Brought to you by Gerardo Richarte, with bootstrapping help from  
>>>  > >> Mitch Bradley.
>>>  > >
>>>  > > i can't resist pointing out that we could probably do that with
>>>  > > linux too, if we weren't committed to using an off-the-shelf desktop
>>>  > > distribution.
>>>  > 
>>>  > Are we committed to that?
>>>
>>> i suspect so.  it gives us huge leverage in terms of reducing
>>> development time and in increased numbers of familiar developers. 
>>> while i'm sure there's a bunch of savings that could be had
>>> in boot time, some of it would come in terms of reduced or
>>> delayed services and system flexibility.  the fact is that
>>> once the XO is up and running, it's an extremely powerful,
>>> full-fledged workstation.  (approximately speaking, of course.  :-) 
>>> there's something to be said for that.
>>>   
>>>       
>> I think we need to be careful to stay focused on our mission.  To the 
>> extent that we are too compatible with the big wide world of PCs and all 
>> the different flavors of Linux, we risk becoming irrelevant.  If you 
>> want a PC, there are plenty of choices, nearly all of them better (at 
>> running conventional software) than XO.
>>
>> In my mind, making yet another PC is uninteresting.  We need to focus on 
>> doing something that is fundamentally better.  We cannot win at the old 
>> game; we have to invent a new game.
>>
>>     
>>> (i do think we should be making our dual-boot capabilities
>>> equally available for all OSes.  i'd love to be able to
>>> (trivially) try SqueakNOS or debxo, for instance, or be able to
>>> experiment with application-specific fast-bootable images.  and i
>>> think a lot of G1G1 folks that might prefer an "alternate"
>>> distribution of some sort for day-to-day would probably like to
>>> keep the OLPC code around as well, just to keep their laptops
>>> "stock", and to track our progress.)
>>>   
>>>       
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>