On Mon, 2006-04-10 at 23:24 +1000, David Timms wrote:
> I haven't tried this but I thought I might: from my reading of
the rsync
> protocol, it can efficiently sync two identically named files,
even when
> the data moves around within the file. This is done by taking a rolling
> hash and comparing at each end.
>
> An rpm update for say FC5, would be very likely to have very small
> changes - ie bug fixes, but since compiles would otherwise be
the same I
> imagine it would be a good candidate for efficient rsyncing.
>
> I was thinking that the changes for even openoffice, or the
kernel might
> not be so great even between major release eg FC4 to FC5. Some
rpm might
> hardly change eg docs and tzdata, or the language packs for openoffice
> or kde etc.
The problem is that even if it is a small change, all the source gets
recompiled, so the resultant binaries could be different, and different
enough to cause large amounts of little changes. This is because we
don't just spin the same binaries with say a new doc file or something
like that. Little changes just from a recompile add up quickly.
On the subject of bandwidth, would it be possible to produce install
ISO images once a month that included latest updates? Images would be
dished out by bit-torrent and for each install would reduce load on
the main servers at time of first update.
Alternately produce an update repository torrent with instructions to
produce a local update repository. Each day a new tracker would
be produced and used to update the local update repository.
This could be automated as a script.
Rob Mortimer
(Some bloke)