>>> > gzip --compress-like=old-foo foo
>
>gzip creates a dictionary (that gets realy large) of strings that are
>used and encodes references to them. At the start the dictionary is
>empty, so the first char is pretty much unencoded and inserted into
>the dictionary. The next char is encoded usi
> > No, this won't work with very many compression algorithms. Most
> > algorithms update their dictionaries/probability tables dynamically based
> > on input. There isn't just one static table that could be used for
> > another file, since the table is automatically updated after every (or
> > n
> " " == Otto Wyss <[EMAIL PROTECTED]> writes:
>> > gzip --compress-like=old-foo foo > > where foo will be
>> compressed as old-foo was or as aquivalent as > possible. Gzip
>> does not need to know anything about foo except how it > was
>> compressed. The switch "--compress-lik
> " " == Otto Wyss <[EMAIL PROTECTED]> writes:
>> > gzip --compress-like=old-foo foo
>>
>> AFAIK thats NOT possible with gzip. Same with bzip2.
>>
> Why not.
gzip creates a dictionary (that gets realy large) of strings that are
used and encodes references to them. At th
> > gzip --compress-like=old-foo foo
>
> AFAIK thats NOT possible with gzip. Same with bzip2.
>
Why not.
> I wish it where that simple.
>
I'm not saying it's simple, I'm saying it's possible. I'm not a
compression speciallist but from the theory there is nothing which
prevents this
> > gzip --compress-like=old-foo foo
> >
> > where foo will be compressed as old-foo was or as aquivalent as
> > possible. Gzip does not need to know anything about foo except how it
> > was compressed. The switch "--compress-like" could be added to any
> > compression algorithmus (bzip?)
Goswin Brederlow wrote:
> >> gzip --rsyncable, aloready implemented, ask Rusty Russell.
>
> > The --rsyncable switch might yield the same result (I haven't
> > checked it sofar) but will need some internal knowledge how to
> > determine the old compression.
>
> As far as I unde
> " " == John O Sullivan <[EMAIL PROTECTED]> writes:
> There was a few discussions on the rsync mailing lists about
> how to handle compressed files, specifically .debs I'd like to
> see some way of handling it better, but I don't think it'll
> happen at the rsync end. Reas
There was a few discussions on the rsync mailing lists about how to
handle compressed files, specifically .debs
I'd like to see some way of handling it better, but I don't think
it'll happen at the rsync end. Reasons include higher server cpu load
to (de)compress every file that is transferred and
> " " == Andrew Lenharth <[EMAIL PROTECTED]> writes:
> What is better and easier is to ensure that the compression is
> deturministic (gzip by default is not, bzip2 seems to be), so
> that rsync can decompress, rsync, compress, and get the exact
> file back on the other sid
> " " == Otto Wyss <[EMAIL PROTECTED]> writes:
>>> So why not solve the compression problem at the root? Why not
>>> try to change the compression in a way so it does produce a
>>> compressed
> result
>>> with the same (or similar) difference rate as the source?
>> Ar
> No, I want rsync not even to be mentioned. All I want is something
> similar to
>
> gzip --compress-like=old-foo foo
>
> where foo will be compressed as old-foo was or as aquivalent as
> possible. Gzip does not need to know anything about foo except how it
> was compressed. The switch "
On Mon, Jan 08, 2001 at 05:28:56PM +0100, Otto Wyss wrote:
> >> So why not solve the compression problem at the root? Why not try to
> >> change the compression in a way so it does produce a compressed
> result
> >> with the same (or similar) difference rate as the source?
> >
> >Are you going to
>> So why not solve the compression problem at the root? Why not try to
>> change the compression in a way so it does produce a compressed
result
>> with the same (or similar) difference rate as the source?
>
>Are you going to hack at *every* different kind of file format that you
>might ever want
On Mon, Jan 08, 2001 at 11:58:26PM +1100, Peter Eckersley wrote:
> On Mon, Jan 08, 2001 at 08:27:53AM +1100, Sam Couter wrote:
> > Otto Wyss <[EMAIL PROTECTED]> wrote:
> > >
> > > So why not solve the compression problem at the root? Why not try to
> > > change the compression in a way so it does
On Mon, Jan 08, 2001 at 08:27:53AM +1100, Sam Couter wrote:
> Otto Wyss <[EMAIL PROTECTED]> wrote:
> >
> > So why not solve the compression problem at the root? Why not try to
> > change the compression in a way so it does produce a compressed result
> > with the same (or similar) difference rate
> " " == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> On 7 Jan 2001, Bdale Garbee wrote:
>> > gzip --rsyncable, aloready implemented, ask Rusty Russell.
>>
>> I have a copy of Rusty's patch, but have not applied it since I
>> don't like diverging Debian packages from up
Previously Bdale Garbee wrote:
> Wichert, have you or Rusty or anyone taken this up with the gzip upstream
> maintainer?
I'm not sure; I'll meet Rusty next week at linux.conf.au, I'll ask
him.
Wichert.
--
/ Generally uninteres
Previously Jason Gunthorpe wrote:
> Has anyone checked out what the size hit is, and how well ryncing debs
> like this performs in actual use?
Rusty has, the size difference is amazingly minimal.
Wichert.
--
/ Generally unint
[EMAIL PROTECTED] (Matt Zimmerman) writes:
> As you know, it's been eons since the last upstream gzip release.
On advice of the current FSF upstream, we moved to 1.3 in November 2000.
I think it is entirely reasonable to talk to upstream about this before
contemplating forking.
Bdale
On Sun, Jan 07, 2001 at 08:16:08PM -0700, Bdale Garbee wrote:
> [EMAIL PROTECTED] (Wichert Akkerman) writes:
>
> > gzip --rsyncable, aloready implemented, ask Rusty Russell.
>
> I have a copy of Rusty's patch, but have not applied it since I don't like
> diverging Debian packages from upstream t
On 7 Jan 2001, Bdale Garbee wrote:
> > gzip --rsyncable, aloready implemented, ask Rusty Russell.
>
> I have a copy of Rusty's patch, but have not applied it since I don't like
> diverging Debian packages from upstream this way. Wichert, have you or Rusty
> or anyone taken this up with the gzip
[EMAIL PROTECTED] (Wichert Akkerman) writes:
> gzip --rsyncable, aloready implemented, ask Rusty Russell.
I have a copy of Rusty's patch, but have not applied it since I don't like
diverging Debian packages from upstream this way. Wichert, have you or Rusty
or anyone taken this up with the gzip
> " " == Otto Wyss <[EMAIL PROTECTED]> writes:
> It's commonly agreed that compression does prevent rsync from
> profit of older versions of packages when synchronizing Debian
> mirrors. All the discussion about fixing rsync to solve this,
> even trough a deb-plugin is IMHO
Otto Wyss <[EMAIL PROTECTED]> wrote:
>
> So why not solve the compression problem at the root? Why not try to
> change the compression in a way so it does produce a compressed result
> with the same (or similar) difference rate as the source?
Are you going to hack at *every* different kind of fi
Previously Otto Wyss wrote:
> So why not solve the compression problem at the root? Why not try to
> change the compression in a way so it does produce a compressed result
> with the same (or similar) difference rate as the source?
gzip --rsyncable, aloready implemented, ask Rusty Russell.
Wiche
26 matches
Mail list logo
