A more efficient up2date service using binary diffs

[Joe Desbonnet]

The 'up2date' is a great service, but serveral months after a core 
release, the bandwidth required to update a freshly installed machine is 
almost as much as that required to install in the first place.

I did a quick experiment: Using the bsdiff binary diff utility (see 
http://www.daemonology.net/bsdiff/) I compared  
kernel-2.6.9-1.667.i586.rpm  in the FC3/i386 distibution with 
kernel-2.6.10-1.737_FC3.i586.rpm in the updates. I converted the RPM to 
a cpio archive with the rpm2cpio utility before running bsdiff.

The resulting diff file was  6.2MB in size (compared to 16MB for the 
entire RPM).

I also checked  openoffice.org-i18n-1.1.2-10.i386.rpm in the FC3/i386 
distribution with
openoffice.org-i18n-1.1.2-11.5.fc3.i386.rpm in the updates.

The resulting diff file [*] was 1MB (compared to 166MB for the RPM)!

Has anyone thought about improving the up2date service by offering diff 
files in addition to the .rpm files?

Joe.

[*]
(This comparison was more tricky as I didn't have enough RAM to perform 
the diff directly. Instead I had to split the files into smaller chunks 
and do a separate diff on each chunk. I guess you would need almost 2GB 
of RAM to use bsdiff on the OpenOffice RPMs directly. However this 
memory requirement is for generation of the diff. The patch utility does 
not require much memory).