Re: Solving the compression dilema when rsync-ing Debian versions
>>>>> " " == Michael Moerz <firstname.lastname@example.org> writes:
> On Thu, Jan 11, 2001 at 07:28:58AM +0100, Goswin Brederlow
>> >>>>> " " == Otto Wyss <email@example.com> writes:
>> >> > Maybe it's time to design a compression alogrithmus which
>> has >> > this functionality (same difference rate as the
>> source) from >> > the ground up. >> >> There are such
>> algorithms, but they eigther allys use the same >> dictionary
>> or table (like some i386.exe runtime compressors >> that are
>> specialiesed to the patterns used in opcodes) or they >> waste
>> space by adding the dictionary/table to the compressed >>
>> file. Thats a huge waste with all the small diff files we have.
>> >> > These all have fixed compression, as far as I know there
>> isn't > any which combines a fixed with an adaptable
>> Yes, because having an adoptable algorithm contradicts the idea
>> of storing a fixed table in a file and if the table is fixed
>> for a lot of files, just let the compressor know the table.
> Well I think we all know what compression is about. I just want
> to point out at compression algorithms that don't have a table
> in the file per se. They "guess" the table by reconstructing it
> like the LZW algorithms (this has already been mentioned on
> this thread). Perhaps using that algoritm might prove useful.
Thats the problem here, gzip does not have a table but constructs it
for every char.
It just doesn't work, so maybe we can stop here.