| |||||||||||||
|
| |||||||||||||
Formats supportedFormats supportedPosted Jan 6, 2008 5:17 UTC (Sun) by zooko (subscriber, #2589)In reply to: Formats supported by epa Parent article: RPM 5.0 released
By the way, I recently learned that 7z compresses noticeably tighter than bzip2, and even than lrzip (for the data sets that I was interested in). 7z also has the advantage over lrzip (and over rzip) that it can operate in "streaming" mode, and it has the advantage over all of them (except probably gzip) of being faster/taking less CPU time. http://allmydata.org/pipermail/tahoe-dev/2007-December/00...
(Log in to post comments)
Formats supported Posted Jan 10, 2008 13:52 UTC (Thu) by kirkengaard (subscriber, #15022) [Link] This discussion has been had many other places, and so far, LZMA (aka 7z) isn't unixy enough to behave like we all expect gzip and bzip2 to behave. Outputs and subarchiving, not to mention magic numbers and crc, seem to be troublesome still. It does what it does very well, sure, but it doesn't do what gzip and bzip2 do well. The other aspect is that of "sufficient improvement to outweigh transition costs". Once it behaves itself such that it can be a drop-in replacement for gzip or bzip2, the algorithm speed and CPU efficiency will be no-brainer reasons to switch. No workflow changes, IOW. As your referenced email states, it's all about the tradeoffs and the conditions of use. Look up HPA on kernel binary compression formats.
|
|
||||||||||||