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

[Antonio Diaz Diaz]

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.


Regards,
Antonio.