Mozilla Firefox Switches To .tar.xz For Linux Packaging

[caligula]

Let's look at some actual data.
I took the data.tar.xz out of my system's recent Firefox update package and recompressed it with a few compressors I'm familiar with.

`xz` definitely has the best balance of size, compression time, and decompression time in this list. `zstd` had a poor showing and would not appear in further rounds of testing if I were working on this issue.

Maybe you should use the native archive format. .tar.zstd sounds totally retarded.

[shmerl]

Browsing through big archives compressed with zstd is way smoother than browsing through them compressed with xz. Size difference is not huge, so I'd say decompression speed wins as being more valuable.

[murlakatamenka]

Whoever names a distro (from 2024) without zstd support wins.

https://www.factorio.com/download = factorio-space-age.tar.xz !

---

Jokes aside, as show in the comments above, xz can provide better compression (even if compression/decompression time will be slower). If compression ratio is the ultimate optimization criteria, then zstd can be beaten. Just usual "computer stuff" tradeoffs.

[stormcrow]

For one time software downloads, the size of the file is more important for cumulative software update time (download+decompress+install) than just decompression speed.

Little known fact: ISPs and other large scale data oriented organizations have to pay for interconnect transfers on metered basis. Unlike most consumer end users where there's a flat fee on the last mile, interconnect charges are on every byte moved outside their network. That's one of the big reasons regional data centers exist. It cuts out the interconnect usage fees by keeping origins inside the big ISP networks and minimizing the number of interconnects.

Therefore, the cost is not CPU time on servers, the major cost is metered cross network charges. Smaller file transfers = smaller interconnect bills. In comparison the couple of seconds efficiency saved on file compression is dwarfed by the fees on how many times that file is requested by users outside their ISP's network.

[intelfx]

personally zstd is fine, but their cli interface is lacking, it should be like gzip/xz/bzip2 but it differs in annoying ways and of course there's pzstd which differs from zstd in annoying ways.

The fact that it "differs" does not mean that it's "lacking".

those reasons and the fact it's not as widely deployed, means it shouldn't be considered a standard archive format just yet.

Dude. It's 2024, basically everything that cares does support Zstd.

BTW, it always amuses me how people motivate their (non-)preference with absence of popularity. "It might be good but it's not popular, let's... keep it not popular"

[mos87]

Also there's this https://www.nongnu.org/lzip/xz_inadequate.html

[mos87]

Dude. It's 2024, basically everything that cares does support

Dude almost nothing in this world that MATTERS lives on the edge. Grow up.

ппц ты пионер конечно. а строит из себя эксперта

[fitzie]

The fact that it "differs" does not mean that it's "lacking".



Dude. It's 2024, basically everything that cares does support Zstd.

BTW, it always amuses me how people motivate their (non-)preference with absence of popularity. "It might be good but it's not popular, let's... keep it not popular"

it is both lacking and unnecessarily different both to other tools and to itself. I think the lack of care about its command line tool being familiar should be taken as a sign that it's maintainers don't really care about making it a drop in replacement. luckily xz developers didn't have that mindset which is why xz will become ze standard and zstd will not.

sorry I don't control the universe, so don't roll eyes on me. I'm just explaining why zstd isn't going to become a standard for archive any time soon.

[Anux]

it is both lacking and unnecessarily different both to other tools and to itself.

Woha. That's some next level logic there!

[filbo]

I just wish we had new instead of tar format that is more efficient or perhaps compression format on linux similar to 7z or rar that can pack all files optimally together. 7z isn't modern format by any means, but it allows 7za to individually look at each file and apply different filters to get best results compression wise, i assume some .so files weren't compressed at all by .xz in tarballs but they were by .7z .

`tar` doesn't compress at all, it just concatenates files. `7z`'s trick here is that it sorts files by extension, which puts similar data types near each other. That's beneficial to compression engines with a limited buffer scope.

If you build your tarball in the same file order as `7z`, the output of a compressor like `xz` would benefit somewhat. `lrzip` wouldn't benefit, since its big trick is that it prescans the entire input and rearranges it to put similar data types near each other; this is more or less the same trick as `7z`, except the data grouping is based on actual runtime measurement of similarity, not just a heuristic that same extensions will probably compress well together.