Live data from Hacker News

Now using Zstandard instead of xz for package compression

archlinux.org

101–110 of 155 posts

Re: Now using Zstandard instead of xz for package compression

#101
post #58

I used zstd for on-the-fly compression of game data for p2p multiplayer synchronization, and got 2-5x as much data (depends on the payload type) in each TCP packet. Sad that it still doesn't get much adoption in the industry.

Zstd knows how to use a user-supplied dictionary at each end. I hope you are doing that. But if latency matters you might better use lz4.

Yes, I did. Too bad that I didn't get to see up CI in that project, and current maintainers probably forgot to update the dictionary.

Re: Now using Zstandard instead of xz for package compression

#102
post #98
post #47

> Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup. Impressive. As a AUR package maintainer I am also wondering how the compression speed is though.

While the speedup is nice pacman still seems to operate sequentially, i.e. download, then decompress one by one. Decompressing while downloading or decompressing in parallel seems like a low-hanging fruit that hasn't been plucked yet that wouldn't have needed any changes to the compressor.

I might be wrong, but wouldn't it be prudent to first verify the checksum/signature of the downloaded archive before unpacking it? Even when just decompressing there's at least the danger of being zip-bombed (assuming a zip bomb can be constructed for any dictionary-based compression algorithm.)

FWIW I really applaud Arch here. Even if it's just a small step. Commercial operating systems should take notice. OS updates should really not take as long as they (mostly) do.

Re: Now using Zstandard instead of xz for package compression

#103
post #102
post #98

Earlier quoted context omitted.

While the speedup is nice pacman still seems to operate sequentially, i.e. download, then decompress one by one. Decompressing while downloading or decompressing in parallel seems like a low-hanging fruit that hasn't been plucked yet that wouldn't have needed any changes to the compressor.

I might be wrong, but wouldn't it be prudent to first verify the checksum/signature of the downloaded archive before unpacking it? Even when just decompressing there's at least the danger of being zip-bombed (assuming a zip bomb can be constructed for any dictionary-based compression algorithm.) FWIW I really applaud Arch here. Even if it's just a small step. Commercial operating systems should take notice. OS update…

Even then it still could be pipelined. download, check signature, decompress while the next download is running. But yeah, pacman is plenty fast already.

Re: Now using Zstandard instead of xz for package compression

#104

Earlier quoted context omitted.

This isn't a function of an AUR helper but rather makepkg itself. In makepkg.conf, ommit compression by specifying: PKGEXT='.pkg.tar' More information can be found at https://wiki.archlinux.org/index.php/Makepkg#Tips_and_tricks

Then it happens for packages I build myself (and want compressed) and those that I just want to install.

You can also override PKGEXT as an environment variable when invoking makepkg, so you can have compression by default but easily skip it when it matters:

  PKGEXT=.pkg.tar makepkg
EDIT: By the way, it's often a big win to use multithreaded compression (pigz, zstd -T0, etc.) in makepkg.conf. With this, it's fast enough that I hardly ever override PKGEXT anymore.

Re: Now using Zstandard instead of xz for package compression

#106
post #35

Meta: This post is yet another victim of the HN verbatim title rule despite the verbatim title making little sense as one of many headlines on a news page. How is "Now using Zstandard instead of xz for package compression" followed by the minuscule low-contrast grey "(archlinux.org)" better than "Arch Linux now using Zstandard instead of xz for package compression" like it was when I originally read this a few hours…

Saying it's "yet another victim" seems slightly too emotive to me. If people can't read the source site's domain after the headline then I agree there wouldn't be much context, but equally, if they can't read that, surely their best solution is to adjust the zoom level in the browser. It's clear you won't get complete context from the headline list plus domain, but a hint of it is provided and if you want more you cl…

Even using the source domain isn't informative enough. The alternative headline is better. You are being too charitable to an inferior title.

Re: Now using Zstandard instead of xz for package compression

#107
post #52

I'd love to see Zstandard accepted in other places where the current option is only the venerable zlib. E.g., git packing, ssh -C. It's got more breadth and is better (ratio / cpu) than zlib at every point in the curve where zlib even participates.

It would be great to see better compression supported by browsers.

Brotli has wide browser support (https://caniuse.com/#feat=brotli) and comes closer to zstd in compression ratio and compression speed, but its decompression speed is significantly lower and closer to zlib.

https://github.com/facebook/zstd#benchmarks

AFAIK (I haven't looked much into it since 2018) it's not widely supported by CDNs, but at least Cloudflare seems to serve it by default (EDIT: must be enabled per-site https://support.cloudflare.com/hc/en-us/articles/200168396-W...)

Re: Now using Zstandard instead of xz for package compression

#109
post #5

Earlier quoted context omitted.

Arch is actually surprisingly stable and even with infrequent updates on the order of months still upgrades cleanly most of the time. The caveats to this were the great period of instability when switching to systemd, changing the /usr/lib layout, etc but those changes are now pretty far in the past.

Sure, and I've done partial upgrades and it was mostly fine:) It just surprised me to see the devs going out of their way to support it on volunteer time. On the other hand, maybe that's exactly the reason; maybe someone said "hey look, I can make static packages that are immune to library changes! I guess I'll publish these in case they're useful". Open source is fun like that:)

Also, Arch devs probably run Arch servers, and I'd not be surprised if some of those have uptimes in hundreds of days.

Re: Now using Zstandard instead of xz for package compression

#110
post #35

Meta: This post is yet another victim of the HN verbatim title rule despite the verbatim title making little sense as one of many headlines on a news page. How is "Now using Zstandard instead of xz for package compression" followed by the minuscule low-contrast grey "(archlinux.org)" better than "Arch Linux now using Zstandard instead of xz for package compression" like it was when I originally read this a few hours…

I just woke up to this and was surprised the title was eddied as well. I looked up the guidelines and it looks like I violated the "If the title includes the name of the site, please take it out, because the site name will be displayed after the link." guideline.

In your defense, the only reason I knew about this being Arch is because I got the email first last night. The belief that "everyone reads the domain in light grey parens on the right" is false, as a reader I 100% ignore that information subconsciously. This article would be a lot better if it started with "ArchLinux: ...." as it apparently used to be last night. This is a 100% bad title edit, "guidelines" be damned - it made your article submission worse not better.
Post reply on HN