Re: Solving the compression dilema when rsync-ing Debian versions

[Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de>]

>>>>> " " == Michael Moerz <aon.912411198@aon.at> writes:

     > On Thu, Jan 11, 2001 at 07:28:58AM +0100, Goswin Brederlow
     > wrote:
    >> >>>>> " " == Otto Wyss <otto.wyss@bluewin.ch> 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
    >> compression.
    >> 
    >> 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.

MfG
        Goswin