But at my last job, when compressing daily server logs, bzip was able to produce compressed files half to quarter the size of what gzip could do with the same log files. Consistently, over the course of months.
How often do you *serve* log files? Wasn't the discussion up until now about gzip for web server downloads?
The point wasn't to compress as fast as possible, but to keep the size of the archive directory as small as possible.
For downloads, yes, smaller files come down well, but if they take much longer to compress, your combined download+unzip time will be greater than the (admittedly slower) download+unzip time for bzip2.
Hardware is cheap these days. Compression time isn't always the first concern, especially when space is a firmer constraint than time.
Funny, I care more about the time that my machine spends fucked over trying to uncompress something than the extra second of download time.
End of discussion.
Oh, is it?
In another branch of this thread, David Cantrell wrote:
Yes, yes it is. I'm not going to use worse compression just because a few loonies are using legacy operating systems.
Once again David spurns what's probably the majority of the computer using public to, um, what was my phrase earlier? Indulge in geek dickwaving.
Sigh.
-- :: paul :: compiles with canadian cs1471 protocol
