Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zstandard RFC 8878

datatracker.ietf.org

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Zstandard RFC 8878

#21

Post by m0zg »

mjevans wrote: post #19
m0zg wrote: post #11

Zstd is an amazing bit of work and all I ever use for data compression nowadays (or LZ4 when speed is even more critical). Several times the compression/decompression speed of gzip, approximately the same compression ratio with default settings. It's also supported by tar in recent Linux distros, if zstd is installed, so "tar acf blah.tar.zst *" works fine, and "tar xf blah.tar.zst" works automatically as well. Give…

I get why someone might want to avoid .zstd ; but that is the short name offered for humans. Was .zs not sufficient if a file format ending in 'std' is so abhorrent?

I'm not the one who came up with the extension. It just sort of organically happened I guess. I'd prefer "zstd" myself, but, frankly, "zst" is fine as well.

Re: Zstandard RFC 8878

#23

Post by Y_Y »

oofbey wrote: post #15
buryat wrote: post #12

i forgive facebook all their abuses just because they gave us zstd

I think you should read more about Facebook. Try e.g. the Damien Collins email dump, and read about how their android app tricked people into letting it record all phone call and text message records, knowing full well users would hate it if they found out. Clearly they produce good technology. But the company is morally bankrupt.

The PDF of of the information I assume you're referring to is: https://www.parliament.uk/documents/commons-committees/cultu...

Here is a quote from the summary, but I could not find where it was substantiated in the 250-page document:

> Facebook knew that the changes to its policies on the Android mobile phone system, which enabled the Facebook app to collect a record of calls and texts sent by the user would be controversial. To mitigate any bad PR, Facebook planned to make it as hard of possible for users to know that this was one of the underlying features of the upgrade of their app.

Re: Zstandard RFC 8878

#24

Post by ggm »

It's said to be a good fit for ZFS. I tend to lz4 because its baked into the older systems I use, but it may be at a point where my default should be zstd.

bz2/gz still predominates for compressed objects in filestore from what I can see.

Re: Zstandard RFC 8878

#25

Post by kzrdude »

felixhandte wrote: post #2

As someone on the Zstd team, I'm always happy to see it on HN! I'm curious though what motivates the submission?

Zstd is always interesting.

For many applications (file formats), ubiquity is important, so it would be fun if zstd becomes ubiquitous and can be relied on to be available. Let's say for example in future versions of HDF (HDF5 or later).

Re: Zstandard RFC 8878

#27

Post by lifthrasiir »

zinekeller wrote: post #7
vlovich123 wrote: post #5

Is there a reason zstd isn’t popular for HTTP and only brotli and gzip see adoption?

Because Facebook doesn't have a browser. (But seriously, Mozilla engineers have warned the Chrome team that they are too rush with the inclusion of Brotli, since that compression wars are heating up. They still proceeded though, which is unsurprising.)

While that might well be one reason, it should be also noted that Zstandard optimizes for the decompression speed with a reasonable compression ratio while Brotli concentrates on the compression ratio at the slight expense of speed (though it is very hard to do a fair comparison). This is evident from their defaults, where zstd uses a fairly low level (3 out of -7..22) and Brotli uses the maximum level (11 out of 1..11). But both have the decompression speeds far exceeding 100 MB/s which is the practical limit for most Internet users, so zstd's higher decompression speed wouldn't matter much in the web context.
Post reply on HN