-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/17/07 12:33, Jorge Peixoto de Morais Neto wrote:
>>
>> - tar has been around forever
>> - tar is standard on pretty much every *nix system (which GNU tar
>> becoming more common even on commercial Unices)
>
> Tar is easily available even on Windows. Good programs like 7-zip and many,
> many others, can handle tar well.
>
> - gzip provides better compression than zip (bzip2 is even better but
>> it takes lots of CPU)
>
> rzip, which is built on top of bzip2, manages to compress significantly
> better than bzip2 (specially for large files), while being significantly
> faster.
> A drawback is that it cannot work as a filter (IIRC, it can't read from a
> pipe, and the author says that the design of the algorithm makes it hard or
> even impossible to make it able to read from a pipe).
> It was done by Andrew Tridgell (which dispenses presentation).
> 7zip compresses even more (more than zip, gzip, bzip2 or even rzip) but is
> very slow.
I'll have to try it.
> My choice is rzip.
For big "stand-alone" files, it's great.
> I really don't know why isn't rzip integrated with tar (like gzip and bzip2
> are) and why isn't it more widely used.
Because tar uses pipes, which, as you pointed out, rzip can't use.
Pardon me if I say something stupid, but I don't know why tar cannot just
1)run the .tar.rz file through rzip when decompressing, than extracting the necessary files from the .tar
2)when compressing, generate a .tar and then run it through rzip.
It would probably be slower than to use pipes, but would be good enough
in many situations. Anyway, having the option wouldn't hurt, and I
think it would be quite simple to add this to the tar code.
If, for instance, .deb's used rzip, they would probably be significantly smaller and I believe that the time saved in download would be much higher than the additional time spent in decompressing.