>> source code, even 100KLOC? Once you go to .gz you're already at better >> than 2:1. What are you going to save by going to even 3:1, 10Kbytes? >> compared to the nuisance inflicted, it's nothing. > > Over the entire CPAN archive, it'd be significant... > > I agree on the individual case it's probably not worth worrying about too > much. But if it's easy to use .bz2 or something better it wouldn't hurt > to get that word out. (And it may be worth making it easy, though I'm not > sure about that.) > > Daniel T. Staal > Disk space is cheap. Bandwidth is cheap. What's rough is the rsync between mirrors. Compressing to .bz2 won't help that: the stress is doing a stat on every single file in CPAN not the transfer. Work toward optimizing the mirror distribution instead of worrying about bz2 vs gz. Remember not everyone is on UNIX or UNIX-like: Windows users use CPAN also and AFAIK Windows doesn't understand .bz2 -- certainly not .xz .
If it is desirable to achieve better disk space utilization filesystem-level dynamic compression is an option at the expense of additional CPU/memory resource for accessing the content (with the possible gain of more data from the IO channel by getting 2-3 blocks for a 1 block read). Overall, the past consensus has been that the rsync is the best available method but is a heavy burden on the systems. Work toward improvement was started by I think Andreas. I have to get a chance to look at that code...
