A more efficient up2date service using binary diffs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux