Re: deb + tar + bzip2 suggestion
email@example.com (Erv Walter) writes:
> In article <firstname.lastname@example.org> 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
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.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org