Re: New release of F11 for the XO-1 is available for testing - OS13

[Bernie Innocenti]

On Mon, 2010-03-29 at 00:46 -0500, Mikus Grinbergs wrote:
>  I've installed the 2010/03/22 XO-1 kernel on two os13 systems and
> on one
>  115-py system.  Running those systems, I have seen no problems that I
>  would think could be attributed to using this newest kernel.  It is good
>  enough for me -- but I customize my systems (including kernel parameter
>  values and suchlike).  Whether an unmodified system is good enough for
>  your purposes is something you will have to decide for yourself. 
Cool. Can you please test:

(1) camera and video playback in Record

(2) sound recording in Record
    (this is expected to fail with any kernel, but we may be lucky)

(3) enable automatic power management in os115py and see if the camera
    still works

(4) networking after a few cycles of suspend


>  I've been installing new kernels for months.  [ I actually rsync
> to
>  /versions/pristine/xxx/boot/ ]  This upgrade was more tricky than most
>  -- kernel-firmware conflicts were found and I had to use --force 
you could also install the new kernel-firmware package.

BTW, I've been wondering: does kernel-firmware contain anything that we
actually need? Probably not. It would be interesting to drop it and see
if anything breaks.

With some luck, we could greatly reduce the body of questionable blobs
that we ship with the OS images (the remaining offenders are the
libertas firmware and the EC code).


>  > the alternate boot scheme (I wonder how many people actually use
> it and
>  > if it's still worth keeping)
>  
>  Something (such as a form of olpc-update ?) needs to be available that
>  is less drastic than using copy-nand (or equivalent).  My beef with the
>  alternate boot scheme is that the /versions tree takes up substantially
>  more jffs2 space than what is actually running - whereas the XO-1 does
>  not really have any jffs2 space to spare. 
While olpc-update might never become usable for the general case, Daniel
said that it works well for small OS patches. For small changes, yum
would also work, although with a tiny window for failure.

What's the actual cost we're paying in terms of disk space and kludgery
in order to support olpc-update?

Flashing is drastic, but very fast and easy to perform. We could reduce
user annoyance by improving our journal backup-restore UI, which needs
to be done anyway for other data loss scenarios.

Currently, users are being told to save anything they want to keep to a
USB stick. Kids don't seem to be bothered, except for one girl who had
created a lot of really cool stuff in Scratch which we had to be backed
up manually. The upcoming sugarized Scratch will solve also this case.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/