Fwd: XO in-field upgrades

Alexander Larsson alexl at redhat.com
Mon Jun 25 04:00:39 EDT 2007


On Sun, 2007-06-24 at 12:46 -0400, C. Scott Ananian wrote:
> Sorry, wrong email...
>   --scott
> ---------- Forwarded message ----------
> From: C. Scott Ananian <cscott at laptop.org>
> Date: Jun 24, 2007 12:44 PM
> Subject: XO in-field upgrades
> To: alexl at laptop.org
> Cc: Christopher Blizzard <blizzard at redhat.com>, Michail Bletsas
> <mbletsas at laptop.org>, John Watlington <wad at laptop.org>,
> devel at lists.laptop.org
> 
> 
> In the weekend I just read about Alex' plan for XO in-field upgrades.
> The mailing list message is here:
>    http://lists.laptop.org/pipermail/devel/2007-June/005381.html
> I think the proposal deserves more discussion; in particular there are
> some interactions with vserver and copy-on-write, as well as
> networking (I really don't want the laptops broadcasting information
> about what upgrade blobs they have on mDNS!  We should use a multicast
> address at least...)  Also, I think we've discussed shipping binary
> diffs rather than git's integral blobs, which may (or may not) be
> incompatible with the proposal so far.  Fundamentally, I don't think
> that re-using git's design philosophy wholesale is actually the Right
> Thing for this application.

For the stuff in that mail I don't see how vserver and copy-on-write has
any bearing. That mail is strictly about how to get the bits of a
specific update to the laptop. How we then later apply the bits to the
machine is a different thing.

mDNS *is* multicast. But the blobs won't be exposed over mDNS, that is
far to much data for a protocol like that. mDNS is just used to announce
"here is a laptop that has this version of the image installed", and if
the version is later we can upgrade another laptop from that one.

Binary diffs seem much less useful. They enforce a specific base version
that you have to have around, and they enforce the direction of upgrade.
If you can cheaply generate at runtime (on the client) a minimal diff
between any two versions you can avoid storing unnecessary information,
and you can upgrade between any two versions (including going
backwards). I find that quite superiour to having to e.g. upgrade
multiple steps by using multiple diffs.






More information about the Devel mailing list