OLPC-Update + RPMs WAS:Re: OLPC XO Opera browser as Sugar activity

[david at lang.hm]

On Mon, 30 Jun 2008, Erik Garrison wrote:

> On Mon, Jun 30, 2008 at 07:10:23PM -0400, C. Scott Ananian wrote:
>> On Mon, Jun 30, 2008 at 6:58 PM, Martin Langhoff
>> <martin.langhoff at gmail.com> wrote:
>>> On Mon, Jun 30, 2008 at 6:50 PM,  <david at lang.hm> wrote:
>>>> how many different deployment builds do you think are being supported at
>>>> this time? I think it's still in the single digits.
>>>
>>> I expect this to change quite drastically soon.
>>
>> Let's not get ahead of ourselves.  Someday we may be able to support
>> lots of different configurations.  Today, we will only be successful
>> if we can limit the number of configurations in the field to a
>> testable number (and then test them!).
>>
>
> In your opinion what is a 'testable number'?

this is a very squishable number, it's going to depend to a large degree 
on how different the builds are.

frankly, based on what I've been seeing, for the past 6 months the 
'testable number' has been <1 (several more have been deployed, but the 
resources have not been allocated to really test any of them)

note that I am speaking for myself.

>> That's the whole point of the core OS / activities split.  Do whatever
>> you like on the activities side, because that's your primary value-add
>> (you == countries).  We can also technically ensure that one bad
>> activity won't spoil the whole bunch.  We will in turn provide you
>> with a core OS which is as stable and functional as we know how.
>
> There is another primary value-add, which is a different operating
> system or window manager.  To enable this value-add we could be
> distributing a minimal image for each of the popular linuxes and then
> distributing packages to install sugar, activites, other window
> managers, etc.  Such packaging would be most useful to deployments
> engaged in customization.
>
> We already know that countries want to be able to run more traditional
> desktop environments.

this sort of thing is drastic enough that the package-based updaters would 
not help much.

<soapbox>
   unless you have maintained the software for an embedded system, or a 
very similar focused set of systems you don't understand the trade-offs as 
much as you think you do. When things get small and tight the overhead of 
normal distros becomes a huge factor. also the 'small' risk of an upgrade 
failing and jamming the box up becomes unacceptable becouse you don't have 
hands available to touch the systems (if you even have people in the right 
place to be able to touch the systems)

In the embedded space it is very common to use the approach that OLPC is 
useing. they provide a smapshot of the running system, and have a 
provision to load a second snapshot ans switch to it. My Tivo has been 
doing the same thing for about the last decade, and I've never had to send 
it in becouse an upgrade has failed (I have had to re-apply my own local 
modifications quite frequently as the upgrades wipe them out, but their 
stuff has just worked)
</soapbox>

what I would really like to see is for OLPC to not just release the 
snapshots, but to have a way for developers to get the rest of the build 
environment, complete with either the scripts, or command logs of what is 
done to go from the fedora build to the OLPC build. (This may already be 
available and I just don't know where to look)

I would then like to see someone maintain another base-level distro that 
can run on the OLPC, but not be based on Sugar so that people who want a 
normal distro can use one, and also so that various performance and 
usability issues can be identified as being caused by the software vs 
being caused by the limited hardware. there have been a few people who 
have made single-shot builds, but AFAIK nobody has maintained/improved the 
image after the initial 'here, see, it boots' announcement

David Lang