On Sunday 06 January 2008, David Schwartz wrote: > > looks to me like tar+lzma is the way to go, not 7z > > In my quick test, lzma got a 7.6, beating 7z by a negligible margin. > > I think it largely comes down to whether any of these are popular enough to > justify the effort of offering in that format. We've been down this road > before in the transition from compress to gzip and then from gzip to bzip2.
sure, i perfectly understand there's more to it than "just 1 more file, what's the big deal". please dont take my comments as "you need to get on this!". i'm just trying to direct things such that if you do decide to start supporting/transitioning to a new format, it's the right one looking at things long term and such. if there is a new compression standard coming up in the open source world, i believe it's going to be lzma-utils. imo, .lzma is the only thing worth considering at this time. wait a few releases of openssl and you'll get a better feel for how viable lzma is (or isnt). conversely, i'd put hard cash that 7z will not supplant tar ... after all, that is what the comparison actually is. 7z is an archiver (that also does compression). tar is an archiver. bzip2/gzip/lzma do compression. tar+lzma ftw :). side note, lzma typically is slower during compression, but faster/leaner during decompression. which is what matters in this scenario -- the packager compresses once while everyone else decompresses many many times. a few more data points from glancing at wikipedia ... Inno Setup, NSIS, and RPM include lzma in the latest releases -mike
signature.asc
Description: This is a digitally signed message part.
