[EMAIL PROTECTED] (Erv Walter) writes: > In article <[EMAIL PROTECTED]> you wrote: > > Sorry for the late reply - catching up. > > > IMHO speed is always relevant, and so is memory usage. This is the trap > > Micro$oft > > and Apple have fallen into. Just because the hardware is capable of running > > faster > > is no excuse for sloppy coding. I'm not saying everything should be written > > in assembly > > language and optimized, but horsepower is not a substitute either. > > Memory usage is important, but the useage time is short in this > sense. Speed is important too, but the extra 30 seconds it takes to > uncompress somethis is made up for in this case by the 5 minutes saved > in downloading. This, of course, is only true if you have a slow link > to the internet, but I think that that is true for a majority of > people. > > Erv
Nobody (so I hope) wants to 100% replace gzip with bzip (which would be possible anyway). Only stuff that greatly benefits from it should be changed (thats extremly large and time and memory consuming stuff like X sources). >From that point of view memory should be that much of a problem. Think about how much memory X needs, esspezially for compilation. People, who unpack the X source, should have a large enough maschine to run bzip2 nicely. Anyway, bzip2 runs with 2.5 MB ram, which is nothing compared to what X needs to compile. The speed is also relative low. Whats 30 seconds decompression more to 20 MB download saved on a 14.4 modem connection? Whats 30 seconds compared to 20 hours of compilation? On fast maschines the decompression time is not that much more and on slow maschines uncompressing something like X sourcen takes more than 30 minutes. If someone waits 30 minutes for decompression he will not sit there and wait, he will do something else in parallel and then waiting 35 minutes is not a big problem. I like the suggestion to have signed tar files instead of signed gz files. The tar files could be compressed any way one likes and it could still be checkt for correctness. May the Source be with you. Mrvn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]