Fwd: XO in-field upgrades
C. Scott Ananian
cscott at laptop.org
Mon Jun 25 16:28:47 EDT 2007
On 6/25/07, Christopher Blizzard <blizzard at redhat.com> wrote:
> On Mon, 2007-06-25 at 15:38 -0400, C. Scott Ananian wrote:
> > To my mind, this makes it clear that the on-wire format should be a
> > binary diff. We could uncompress these diffs on receipt and maintain
> > a blob store as in the current proposal, but it seems much more
> > reasonable to sign, authenticate, and store the *diffs* rather than
> > the *blobs*, so that we don't need to recompute diffs when we want to
> > pass on our upgrade to a neighboring XO.
> It's not clear what that data means, exactly. Do those files like this:
> 158 usr-bin-clamconf
> 158 usr-bin-clamdscan
> 161 usr-bin-clamscan
> 159 usr-bin-freshclam
> 162 usr-bin-sigtool
> Actually include binary files changes or are they just permissions
> changes? If so you're >75x larger charge seems a little over the top
> since they wouldn't be transferred at all in Alex's case outside of the
> manifest. :)
No, they are actually 4-byte changes to each binary, buried in the
linker-generated section, presumably caused by an offset change in the
library. I stared at this and the patches for a while. You're
correct that most of the size of this diff is spent coding the
filename, but there is a real diff there.
There's a 60x change if you just look at the libraries. So this
savings is definitely real.
> That being said, this is pretty compelling stuff. I would love to see
> this done against various versions of libgklayout.so, which will
> probably be our largest offender.
If I were bored, I might indulge you. ;-)
> It also might be interesting to layer a diff system on top of what Alex
> has proposed so you could do it either way - diffs if ya got 'em, raw if
> ya don't.
That sounds suspiciously like the complexity you're afraid of. Let's
just do diffs and call it done.
( http://cscott.net/ )
More information about the Devel