Comments for Lzip
Re: Other LZMA tools
As I gather, lzma-utils-produced files lack magic identification bytes and a checksum, and if you believe forum archives, lzma-utils did not manage to come up with a suitable new format in more than two years. It is about time lzip came along—7z sounds nice too, but seems to have gotten no ground in the Unix world due to subpar unix integration.
As for lrzip, it is actually an extension of rzip—and the two are more of a proof-of-concept than a realworld-workable format.
Other LZMA tools
An alternative command-line compressor using LZMA is lzmash from lzma-utils. Also interesting is lrzip which adds a preprocessing step before the LZMA compression to give a better speed/tightness tradeoff, at the expense of using more memory.
Re: Other LZMA tools
I think you are right that the standalone 'lzma' program (replacing the older lzmash) has a very basic data format. But still, it works, and is the more established tool. I would be happy for lzip to replace it if lzip is better, but to do that it should include support for decompressing legacy .lzma files.
(I note that the gzip format has provision for alternative compression methods but nobody ever seems to use it.)
> As for lrzip, it is actually
> an extension of rzip---and the two are
> more of a proof-of-concept than a
> realworld-workable format.
The file format may be basic but the tool is very good. It usually compresses better than plain LZMA (the algorithm, used in both lzma-utils and lzip) and faster too. LZMA is better for all-purpose use but for batch compression tasks where you don't mind relatively high memory usage, lrzip can give a big improvement. For some Subversion dump files I back up overnight it gave a fourfold increase in compression for about the same speed.