[Top][All Lists]

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

Re: [Lzip-bug] why not offer a real 'zip' function using lzip?

From: Antonio Diaz Diaz
Subject: Re: [Lzip-bug] why not offer a real 'zip' function using lzip?
Date: Fri, 18 Dec 2009 19:16:45 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.11) Gecko/20050905

Hello Linda, thanks for writing and sorry for the delay.

Linda A. Walsh wrote:
If it's just another compression program like gzip/bzip2
(that both, inherently use 'tar' to store directory formats, but
that are not random access), I'm not sure how far it will go.

Lzip is "just" another compression program like gzip/bzip2 but I hope it will go somewhere because its format is safer than lzma and simpler than xz.

Noise or not, you're going to have a hard time beating the flexibility
and speed of 7zip.

I do not plan to compete against 7zip. 7zip is mostly useless for unix users because in can't act as a filter and because it doesn't restore file permissions.

But My point in the email was look at the diff between running lzip on
each file individual vs. a tar of them (~2.4M savings) lzip on a stream
(the tar) (~32M savings!).

You will obtain the same results for any Lempel-Ziv compressor with a dictionary size big enough.

The final results show all the lz's within <1% of each other.  7z was way
fast using 4 procs (at expense of 36K disk space).

Just try plzip[1] with 12 processors. :-)
[1] http://www.nongnu.org/lzip/plzip.html

Maybe you could enhance the existing 'zip' program using your algorithm/code?

I think the zip format already accepts a LZMA payload. In any case I do not have the time to write an archiver.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]