blocks|key|2741489|text|“最小公分母”。节省的额外空间很少值得失去互操作性。大多数嵌入式Linux系统都有gzip，但没有xz。许多旧系统也是如此。Gnu是行业标准，它支持通过gzip处理的标志-z，通过bzip2处理的和-j，但一些旧系统不支持xz的-J标志，这意味着它需要两步操作(以及大量额外的磁盘空间用于未压缩的.tar，除非您使用%7Ctar+xf+-的语法-许多人不知道这一点)。此外，在嵌入式ARM上从tar.gz解压大约10MB的完整文件系统需要大约2分钟，这并不是真正的问题。没有关于xz的线索，但是bzip2大约需要10-15分钟。绝对不值得节省带宽。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|CODE|entityRanges|data|2741490|entityMap^0|24|M|33|2|2D|2|2R|2|36|2|44|4|4E|9|5E|6|6L|2|6T|5|0^^$0|@$1|2|3|4|5|6|7|I|8|@$9|J|A|K|B|C]|$9|L|A|M|B|C]|$9|N|A|O|B|D]|$9|P|A|Q|B|D]|$9|R|A|S|B|D]|$9|T|A|U|B|D]|$9|V|A|W|B|D]|$9|X|A|Y|B|D]|$9|Z|A|10|B|D]|$9|11|A|12|B|D]]|E|@]|F|$]]|$1|G|3|-4|5|6|7|13|8|@]|E|@]|F|$]]]|H|$]]

"Lowest Common Denominator". The extra space saved is rarely worth the loss of interoperability. Most embedded Linux systems have gzip, but not xz. Many old system as well. Gnu Tar which is the industry standard supports flags <code>-z</code> to process through gzip, and <code>-j</code> to process through bzip2, but some old systems don't support the <code>-J</code> flag for xz, meaning it requires 2-step operation (and a lot of extra diskspace for uncompressed <code>.tar</code> unless you use the syntax of <code>|tar xf -</code> - which many people don't know about.) Also, uncompressing the full filesystem of some 10MB from <code>tar.gz</code> on embedded ARM takes some 2 minutes and isn't really a problem. No clue about <code>xz</code> but <code>bzip2</code> takes around 10-15 minutes. Definitely not worth the bandwidth saved.

blocks|key|2531795|text|出于同样的原因，Windows+(r)中的人们使用zip文件而不是7zip，一些人仍然使用rar而不是其他格式……或者在音乐中使用mp3而不是aac%2B，等等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2531796|每种格式都有它的好处，人们习惯于坚持他们在开始使用计算机时学到的解决方案。再加上向后兼容性和硬盘驱动器中的快速带宽%2B+GB或TB空间，更大压缩的好处就不那么重要了。|2531797|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

For the same reason people in Windows (r) use zip files instead of 7zip, and some still use rar instead of other formats... Or mp3 is used in music, instead of aac+, and so on.

Each format has it's benefits and people use to stick to a solution they learned when began using a computer. Add this to backward compatibility and fast bandwidth + GB or TB of space in hard drives, and the benefits of a greater compression won't be that relevant.

blocks|key|50948|text|老实说，我只是从一份培训材料中了解了.xz格式。所以我只是用它的git+repo做了个测试。git是git://git.free-electrons.com/training-materials.git，，我还编写了三个培训幻灯片。总目录大小为91M，混合了文本和二进制数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|50949|这是我的快速结果。也许人们仍然喜欢tar.gz仅仅是因为它的压缩速度快得多？我个人甚至在压缩没有太多好处的情况下使用普通的tar。|50950|[02:49:32]wujj@WuJJ-PC-Linux+/tmp+$+time+tar+czf+test.tgz+training-materials/

real++++0m3.371s
user++++0m3.208s
sys+++++0m0.128s
[02:49:46]wujj@WuJJ-PC-Linux+/tmp+$+time+tar+cJf+test.txz+training-materials/

real++++0m34.557s
user++++0m33.930s
sys+++++0m0.372s
[02:50:31]wujj@WuJJ-PC-Linux+/tmp+$+time+tar+cf+test.tar+training-materials/

real++++0m0.117s
user++++0m0.020s
sys+++++0m0.092s
[02:51:03]wujj@WuJJ-PC-Linux+/tmp+$+ll+test*
-rw-rw-r--+1+wujj+wujj+91944960+2012-07-09+02:51+test.tar
-rw-rw-r--+1+wujj+wujj+69042586+2012-07-09+02:49+test.tgz
-rw-rw-r--+1+wujj+wujj+60609224+2012-07-09+02:50+test.txz
[02:56:03]wujj@WuJJ-PC-Linux+/tmp+$+time+tar+xzf+test.tgz

real++++0m0.719s
user++++0m0.536s
sys+++++0m0.144s
[02:56:24]wujj@WuJJ-PC-Linux+/tmp+$+time+tar+xf+test.tar

real++++0m0.189s
user++++0m0.004s
sys+++++0m0.108s
[02:56:33]wujj@WuJJ-PC-Linux+/tmp+$+time+tar+xJf+test.txz

real++++0m3.116s
user++++0m2.612s
sys+++++0m0.184s|code-block|syntax|javascript|50951|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Honestly, I just get to know .xz format from a training material. So I just used its git repo to do a test. The git is git://git.free-electrons.com/training-materials.git, and I also compiled the three training slides. The total directory size is 91M, with a mixture of text and binary data. 

Here is my quick result. Maybe people still favor tar.gz simply because it's much faster to compress? I personally even use plain tar when there aren't many benefits to be gained in compression. 

<pre><code>[02:49:32]wujj@WuJJ-PC-Linux /tmp $ time tar czf test.tgz training-materials/

real 0m3.371s
user 0m3.208s
sys 0m0.128s
[02:49:46]wujj@WuJJ-PC-Linux /tmp $ time tar cJf test.txz training-materials/

real 0m34.557s
user 0m33.930s
sys 0m0.372s
[02:50:31]wujj@WuJJ-PC-Linux /tmp $ time tar cf test.tar training-materials/

real 0m0.117s
user 0m0.020s
sys 0m0.092s
[02:51:03]wujj@WuJJ-PC-Linux /tmp $ ll test*
-rw-rw-r-- 1 wujj wujj 91944960 2012-07-09 02:51 test.tar
-rw-rw-r-- 1 wujj wujj 69042586 2012-07-09 02:49 test.tgz
-rw-rw-r-- 1 wujj wujj 60609224 2012-07-09 02:50 test.txz
[02:56:03]wujj@WuJJ-PC-Linux /tmp $ time tar xzf test.tgz

real 0m0.719s
user 0m0.536s
sys 0m0.144s
[02:56:24]wujj@WuJJ-PC-Linux /tmp $ time tar xf test.tar

real 0m0.189s
user 0m0.004s
sys 0m0.108s
[02:56:33]wujj@WuJJ-PC-Linux /tmp $ time tar xJf test.txz

real 0m3.116s
user 0m2.612s
sys 0m0.184s
</code></pre>

blocks|key|50969|text|最终的答案是可访问性，第二个答案是目的。XZ不一定像Gzip那样合适的原因：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|50970|50971|嵌入式和遗留系统更有可能缺乏足够的可用内存来解压缩诸如XZ之类的LZMA/LZMA2存档。例如，如果XZ可以将发往OpenWrt路由器的数据包的KiB+(vs.+Gzip)减少400，那么如果路由器有16+MiB的内存，节省的空间又有什么好处呢？类似的情况出现在非常旧的计算机系统上。|unordered-list-item|50972|这类系统的处理器速度通常很慢，解压时间增加会非常快。在200+MHz的ARM内核或50+MHz的microSPARC上，在酷睿i5上额外解压3秒可能会非常长。与所有更好的压缩方法(如XZ甚至Bzip2)相比，Gzip压缩在这样的处理器上非常快。在过去20年中创建的所有类UNIX系统(以及几乎所有非类UNIX系统)几乎都支持|50973|Gzip。XZ的可用性要有限得多。如果没有解压的能力，压缩是无用的。|50974|更高的压缩率需要很长时间。如果压缩时间比压缩比更重要，则Gzip优于XZ。老实说，lzop比Gzip快得多，而且压缩效果也不错，所以那些需要尽可能快的压缩和不需要Gzip的普遍性的应用程序应该考虑一下这一点。我经常使用诸如"tar+-c+*%7C+lzop+-1+%7C+socat+-u+-+tcp-connect:192.168.0.101:4444“这样的命令在可信的局域网连接上快速地洗牌文件夹，Gzip可以在速度更慢的链路上使用类似的方法(即，通过互联网上的SSH隧道执行我刚才描述的相同操作)。|50975|50976|现在，在另一方面，XZ压缩在某些情况下是非常优越的：|50977|50978|通过慢速链路发送数据。Linux3.7内核源代码XZ格式比Gzip格式小34+MiB。如果你有一个超快的连接，选择XZ可能意味着节省一分钟的下载时间；在廉价的DSL连接或3G蜂窝连接上，它可以减少一个小时或更多的下载time.|50979|Shrinking备份档案。使用"+Gzip+-9“与"xz+-9e”压缩Apache的httpd-2.4.2的源代码，得到的XZ归档的大小是Gzip归档的62.7%25。如果在您当前存储为100+GiB的.tar.gz归档的数据集中存在相同的可压缩性，则转换为.tar.xz归档将大幅削减备份集的37.3+GiB。将整个备份数据集复制到USB+2.0硬盘驱动器(最多30+MiB/秒的传输)作为this数据将需要55分钟，但XZ压缩将使备份时间缩短20分钟。假设您将在具有充足CPU能力的现代台式机系统上处理这些备份，并且一次性压缩速度不是一个严重问题，那么使用XZ压缩通常更有意义。如果您不需要to?|50980|Distributing大量可能高度可压缩的数据，为什么还要处理额外的数据呢？如前所述，Linux3.7的源代码对于.tar.xz是67+MiB，对于.tar.gz是101+MiB；未压缩的源代码大约是542+MiB，并且几乎全是文本。由于内容中的冗余量，源代码(以及一般的文本)通常是高度可压缩的，但像Gzip这样使用小得多的字典运行的压缩器无法利用超出其字典大小的冗余。|50981|50982|最终，这一切都归结为四个方面的权衡:压缩大小、压缩/解压缩速度、复制/传输速度(从磁盘/网络读取数据)和压缩器/解压缩器的可用性。选择高度依赖于“您打算如何处理这些数据？”这一问题。|50983|还有check+out+this+related+post，我从中学到了一些我在这里重复的东西。|offset|length|50984|entityMap|0|LINK|mutability|MUTABLE|url|http://blog.grandtrunk.net/2004/07/practical-compressor-test/^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|2|R|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1C|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1D|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|1E|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|1F|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1H|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|P|3|Q|5|E|7|1J|8|@]|9|@]|A|$]]|$1|R|3|S|5|E|7|1K|8|@]|9|@]|A|$]]|$1|T|3|U|5|E|7|1L|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1N|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1O|8|@]|9|@$10|1P|11|1Q|1|1R]]|A|$]]|$1|12|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]]|13|$14|$5|15|16|17|A|$18|19]]]]

The ultimate answer is accessibility, with a secondary answer of purpose. Reasons why XZ is not necessarily as suitable as Gzip:

<ul>
<li>Embedded and legacy systems are far more likely to lack sufficient available memory to decompress LZMA/LZMA2 archives such as XZ. As an example, if XZ can shave 400 KiB (vs. Gzip) off of a package destined for an OpenWrt router, what good is the minor space savings if the router has 16 MiB of RAM? A similar situation appears with very old computer systems. One might scoff at the thought of downloading and compiling the latest version of Bash on an ancient SparcStation LX with 32MB of RAM, but it happens.</li>
<li>Such systems usually have slow processors, and decompression time increases can be very high. Three seconds extra to decompress on your Core i5 can be severely long on a 200 MHz ARM core or a 50 MHz microSPARC. Gzip compression is extremely fast on such processors when compared to all better compression methods such as XZ or even Bzip2.</li>
<li>Gzip is pretty much universally supported by every UNIX-like system (and nearly every non-UNIX-like system too) created in the past two decades. XZ availability is far more limited. Compression is useless without the ability to decompress it.</li>
<li>Higher compression takes a lot of time. If compression time is more important than compression ratio, Gzip beats XZ. Honestly, lzop is much faster than Gzip and still compresses okay, so applications that need the fastest compression possible and don't require Gzip's ubiquity should look at that instead. I routinely shuffle folders quickly across a trusted LAN connection with commands such as "tar -c * | lzop -1 | socat -u - tcp-connect:192.168.0.101:4444" and Gzip could be used similarly over a much slower link (i.e. doing the same thing I just described through an SSH tunnel over the Internet).</li>
</ul>

Now, on the flip side, there are situations where XZ compression is vastly superior:

<ul>
<li>Sending data over slow links. The Linux 3.7 kernel source code is 34 MiB smaller in XZ format than in Gzip format. If you have a super fast connection, choosing XZ could mean saving one minute of download time; on a cheap DSL connection or a 3G cellular connection, it could shave an hour or more off the download time.</li>
<li>Shrinking backup archives. Compressing the source code for Apache's httpd-2.4.2 with "gzip-9" vs. "xz -9e" yields an XZ archive that is 62.7% the size of the Gzip archive. If the same compressibility exists in a data set you currently store as 100 GiB worth of .tar.gz archives, converting to .tar.xz archives would cut a whopping 37.3 GiB off of the backup set. Copying this entire backup data set to a USB 2.0 hard drive (maxing out around 30 MiB/sec transfers) as Gzipped data would take 55 minutes, but XZ compression would make the backup take 20 minutes less. Assuming you'll be working with these backups on a modern desktop system with plenty of CPU power and the one-time-only compression speed isn't a serious problem, using XZ compression generally makes more sense. Why shuffle around extra data if you don't need to?</li>
<li>Distributing large amounts of data that might be highly compressible. As previously mentioned, Linux 3.7 source code is 67 MiB for .tar.xz and 101 MiB for .tar.gz; the uncompressed source code is about 542 MiB and is almost entirely text. Source code (and text in general) is typically highly compressible because of the amount of redundancy in the contents, but compressors like Gzip that operate with a much smaller dictionary don't get to take advantage of redundancy that goes beyond their dictionary size.</li>
</ul>

Ultimately, it all falls back to a four-way tradeoff: compressed size, compression/decompression speed, copying/transmission speed (reading the data from disk/network), and availability of the compressor/decompressor. The selection is highly dependent on the question "what are you planning to do with this data?"

Also <a href="http://blog.grandtrunk.net/2004/07/practical-compressor-test/" rel="noreferrer">check out this related post</a> from which I learned some of the things I repeat here.

blocks|key|50377|text|我在1.1+on的Linux安装vmdk镜像上做了自己的基准测试：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|50378|rar++++=260MB+++comp=+85s+++decomp=+5s
7z(p7z)=269MB+++comp=+98s+++decomp=15s
tar.xz+=288MB+++comp=400s+++decomp=30s
tar.bz2=382MB+++comp=+91s+++decomp=70s
tar.gz+=421MB+++comp=181s+++decomp=+5s|code-block|syntax|javascript|50379|最大CPU、英特尔I7+3740QM、内存32+on+1600、源和目标内存磁盘上的所有压缩级别|50380|我通常使用rar或7z来归档像文档这样的普通文件。|50381|对于归档系统文件，我使用.tar.gz或.tar.xz+by+file-roller，或者使用带有-z或-J选项的tar，以及--preserve来使用tar进行本地压缩并保留权限(也可以使用.tar.7z或.tar.rar+)|50382|更新:由于tar只保留普通权限，而不保留ACL，因此也可以使用普通.7z加上备份，并通过getfacl和sefacl手动恢复权限和ACL，这似乎是文件归档或系统文件备份的最佳选择，因为它将完全保留权限和ACL，具有校验和、完整性测试和加密功能，唯一的缺点是p7zip并不是处处可用|50383|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I did my own benchmark on 1.1GB Linux installation vmdk image:

<pre><code>rar =260MB comp= 85s decomp= 5s
7z(p7z)=269MB comp= 98s decomp=15s
tar.xz =288MB comp=400s decomp=30s
tar.bz2=382MB comp= 91s decomp=70s
tar.gz =421MB comp=181s decomp= 5s
</code></pre>

all compression levels on max, CPU Intel I7 3740QM, Memory 32GB 1600, source and destination on RAM disk 

I Generally use rar or 7z for archiving normal files like documents. 
and for archiving system files I use .tar.gz or .tar.xz by file-roller or tar with -z or -J options along with --preserve to compress natively with tar and preserve permissions (also alternatively .tar.7z or .tar.rar can be used)

update: as tar only preserve normal permissions and not ACLs anyway, also plain .7z plus backup and restoring permissions and ACLs manually via getfacl and sefacl can be used which seems to be best option for both file archiving or system files backup because it will full preserve permissions and ACLs, has checksum, integrity test and encryption capability, only downside is that p7zip is not available everywhere

blocks|key|2741588|text|gzip还有一个重要的地方，那就是它可以与rsync/zsync互操作。在某些情况下，这可能是带宽方面的巨大好处。LZMA/bzip2/xz不支持rsync，而且可能不会很快支持它。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2741589|LZMA的一个特点是它使用安静的大窗口。为了让它对、rsync/zsync、友好，我们可能需要减小这个窗口，这会降低它的压缩性能。|2741590|entityMap^0|L|B|0|P|D|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

Also one important point for gzip is that it's interoperable with rsync/zsync. This could be huge benefit regarding bandwidth in cases. LZMA/bzip2/xz doesn't support rsync and probably won't support it anytime soon. 
One of characteristics of LZMA is that it uses quiet large window. To make it rsync/zsync friendly we would probably need to reduce this window which would degrade it's compression performance.

blocks|key|51045|text|gz在任何地方都被支持，并且具有良好的可移植性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|51046|xz较新，现在得到了广泛或良好的支持。它比gzip更复杂，有更多的压缩选项。|51047|这并不是人们可能不总是使用xz的唯一原因。xz可能需要很长的时间来压缩，而不是很短的时间，所以即使它可以产生更好的结果，它也可能不总是被选择。另一个缺点是它会使用大量内存，特别是在压缩时。你越想压缩一个项目，所花的时间就越长，这是一个指数级的递减回报。|51048|然而，在我的经验中，在压缩级别为1的大型二进制项目时，xz通常可以在更短的时间内产生比zlib在级别9的更小的结果。这有时可能是一个非常重要的差异，在与zlib相同的时间，xz可以生成的文件大小是zlib的一半。|51049|bzip2也处于类似的情况，然而xz拥有更优越的优势和一个强大的窗口，它在所有方面的表现都要好得多。|51050|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

gz is supported everywhere and good for portability.

xz is newer and now as widely or well supported. It is more complex than gzip with more compression options.

This is not the only reason people might not always use xz. xz can take a very long time to compress, not a trivial amount of time so even if it can produce superior results it might not always be chosen. Another weakness is that it can use a lot of memory, especially for compression. The more you want to compress an item by the longer it takes and this is exponential with diminishing returns.

However, at compression level 1 for large binary items in my experience xz can often produce much smaller results in less time than zlib at level 9. This can sometimes be a very significant difference, in the same time as zlib, xz can make a file that is half the size of zlib's file.

bzip2 is in a similar situation, however xz has far superior advantages and a strong window where it performs significantly better all round.

blocks|key|2531995|text|是的，我的想法是，现在可以把最初的问题归结为“为什么tar.gz比tar.lz更常见”(因为lz似乎压缩了slightly+better而不是xz，所以xz是一个糟糕的归档选择，尽管它确实提供了一些很好的功能，比如随机存取)。我想答案是"momentum“人们习惯于使用它，有很好的库支持，etc.etc。lz的引入可能意味着xz现在的增长速度将会放缓，FWIW...|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2531996|然而，也就是说，lz似乎比xz更适合decompress+slower，并且有像Brotli这样的新事物即将出现，所以还不清楚在popularity...but方面会发生什么，我在野外似乎有几个.lz文件...|2531997|entityMap|0|LINK|mutability|MUTABLE|url|https://www.nongnu.org/lzip/lzip_benchmark.html|1|https://www.reddit.com/r/linux/comments/58swzc/xz_format_inadequate_for_longterm_archiving/^0|1A|2|1Z|2|24|2|1H|F|0|0|I|H|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@$9|Y|A|Z|1|10]]|E|$]]|$1|F|3|G|5|6|7|11|8|@]|D|@$9|12|A|13|1|14]]|E|$]]|$1|H|3|-4|5|6|7|15|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]|P|$5|K|L|M|E|$N|Q]]]]

Yeah the thought I had is that the original question could be reposed these days as "why is tar.gz more common than tar.lz" (since <code>lz</code> seems to compress <a href="https://www.nongnu.org/lzip/lzip_benchmark.html" rel="nofollow noreferrer">slightly better</a> than <code>xz</code>, <code>xz</code> is <a href="https://news.ycombinator.com/item?id=12768425" rel="nofollow noreferrer">said</a> to be a poor choice for archiving, though does offer some nice features like random access). I suppose the answer is "momentum" people are used to using it, there's good library support, etc.etc. The introduction of lz may mean that xz will grow less fast now, as well, FWIW... 

However, that being said, lz appears to <a href="https://www.reddit.com/r/linux/comments/58swzc/xz_format_inadequate_for_longterm_archiving/" rel="nofollow noreferrer">decompress slower</a> than xz, and there are new things on the horizon like Brotli so it's unclear what will happen in terms of popularity...but I have seem a few .lz files in the wild FWIW...

Whenever I see some source packages or binaries which are compressed with GZip I wonder if there are still reasons to favor gz over xz (excluding time travel to 2000), the savings of the LZMA compression algorithm are substantial and decompressions isn't magnitudes worse than gzip.

Why is *.tar.gz still much more common than *.tar.xz?

每当我看到一些用gzip压缩的源包或二进制文件时，我想知道是否仍然有理由偏爱gz而不是xz (不包括2000年的时间旅行)，LZMA压缩算法的节省是巨大的，解压缩并不比GZip差很多。

问为什么.tar.gz仍然比.tar.xz普遍得多？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么*.tar.gz仍然比*.tar.xz普遍得多？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么.tar.gz仍然比.tar.xz普遍得多？
EN