A more efficient up2date service using binary diffs
Paul A. Houle
ph18 at cornell.edu
Mon Mar 14 19:25:25 UTC 2005
I was thinking about this stuff four years ago when I couldn't get DSL at
home and it was absolutely painful to update RH 7 (or was it 8?) with
The most obscene case was that up2date made me download 20 megs of font
files to fix a a bad configuration file.
If we were designing this kind of system as if users mattered, it might
make more sense to make it files-centric rather than rpm-centric. I
really hate the idea of making the system count on having rpms available,
because I'm not so good about keeping the original disks around. (Plus
the survival of optical disks is hit-or-miss. I've had some disks that
lasted 8 years after getting treated with moderate care, and I've had
other ones that I couldn't read after walking them across campus.)
It seems just as feasable to send diffs of the ~files~ rather than diffs
of the ~rpms~; if we're going to go through the bother of implementing
something like this, it makes sense to make something that "just works"
rather than another one of these things that almost works (or rather,
works if you have the disks, works if you are ready to pull the disks out
if you have yum, kinda might work if you have a network install, maybe
it won't work.)
This should be thought of as an optimization. If the files on the
disk don't checksum match the rpm database, we ought to download and
install the new rpm.
I've always wondered if the Red Hat Network would have been more
profitable if it had been less wasteful of bandwidth.
More information about the devel