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

[Erik Garrison]

On Mon, Jun 30, 2008 at 06:03:55PM -0700, david at lang.hm wrote:
> On Mon, 30 Jun 2008, Erik Garrison wrote:
>>
>> 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.
>

A lot of work, yes.  'Drastic...' I guess I don't really understand what
you mean.  Aside from a significant amount of work I'm not sure what
stands between us and this pattern of distribution.

> <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>
>

I will not claim any great expertise in the area, but I spent the last
year working on an 'embedded' linux system that drives a gene
sequencing device.  In the case of the gene sequencer, our concern was
primarily that it function exactly as specified and be 100% reliable
without continued maintenance, so our software distribution plans
centered around a disk image which could be used to flash the machine
into a completely known and well-tested state.

We are discussing software update systems in terms of a tradeoff
between flexibility and guarantees about reliability.  In the case of
an appliance such as a gene sequencer or digital video recorder, this
tradeoff is heavily weighted toward reliability.  The usage of the
system is well, and narrowly, defined.  Thus software can be provided
by the manufacturer which meets all the users' needs.  The damage
cause by software failures can be enormous.  I agree that a headless
appliance should not risk burying itself during software upgrades.
Lab time is valuable, and television shows may not repeat.

The usage patterns of embedded systems strike me as fundamentally
distinct from those of the XO.  In embedded systems we expect
prescribed, well-defined patterns to make up the vast majority of
usage.  In the case of our laptop we observe highly diverse usage
patterns.  Children take pictures, draw, write, read, browse the web,
and possibly even write a few applications of their own.  Provided we
do not prevent them, they will do everything which you can do with any
roughly equivalent hardware.

I am going to go out on a limb and make the claim that the XO is a
general purpose computer and not an embedded system per se.  If it
does everything a general purpose computer can do, and is expressly
designed to behave in such a way, what reason do we have to label it
as an embedded system and treat it as such?


A package management system can be used to solve a variety of problems
which we are solving locally.  I note: security (via security
updates), software upgrades (to shorten the time delta between our
bugfixes and their distribution), and configurability (consistently
using a package manager plays nicely with downstream reconfiguration).

The package manager need not preclude usage of a snapshot-based
approach to initially set up systems or pull them out of broken
states.  We already ship a package manager.  Why are we not using it?


Erik