Linux EFI Zboot Abandoning "Compression Library Museum", Focusing on Gzip, ZSTD

[fn-mote]

The article gives reasons, but it sounds to me like gzip was retained mainly because it is in use. I don’t have a horse in this race, but if only Zstd were left I would feel like even more simplification was accomplished.

Everybody has their own tiny preference for one of the other but really… if it’s not embedded what is the impact?

> - GZIP is tried and tested, and is still one of the fastest at decompression time, although the compression ratio is not very high; moreover, Fedora is already shipping EFI zboot kernels for arm64 that use GZIP, and QEMU implements direct support for it when booting a kernel without firmware loaded;

> - ZSTD has a very high compression ratio (although not the highest), and is almost as fast as GZIP at decompression time.

[bawolff]

> but it sounds to me like gzip was retained mainly because it is in use.

Isn't that what the article is literally saying?

They aren't trying to get rid of badly performing compression algos, just ones that are effectively unused.

[klysm]

Yeah I generally agree that leaving just zstd would simplify things, but I also see advantages in leaving 2. It seems plausible that a better thing will come along in the future. It’s nice to leave the abstraction in place that enables having more than one algo in place.

[theandrewbailey]

> - ZSTD has a very high compression ratio (although not the highest), and is almost as fast as GZIP at decompression time.

If you're using zstd and its decompression speed isn't at least twice as fast as gzip's, you're using it wrong.

[mananaysiempre]

Not actually true if gzip refers to libdeflate[1] or isa-l[2] instead of zlib. Does seem sus here, though,—I couldn’t quickly find which decompression code is used in zboot, but I’d expect it to be closer to zlib. Perhaps their implementation of Zstandard is simpler than the reference one?

[1] https://github.com/ebiggers/libdeflate

[2] https://github.com/intel/isa-l

[consp]

Yes, everyone tunes their compression settings. /s

It's a generalized statement of 'good enough'.

[walrus01]

zstandard with the correct flags and more cpu/time-intensive options, when creating the compressed file, can be almost as good in ratio as xz.

[alkh]

As far as I can tell, one of zstandard's main benefits is compression/decompression speed. Is the ratio still worse than xz though?

[user20180120]

Long Range Zip tends to give faster decompression. Anyone know which command line switches gives optimum results?

[lousken]

why not keep lz4 as well, shouldn't it have the smallest performance hit compared to those two?

[Ufvasl]

This can't be answered with a simple yes/no without benchmarking this specific use case on specific hardware.

For other use cases I've personally never really found lz4 very useful (neither gzip). Usually zstd on either low/medium can be both faster (or at least, fast enough) and better compressed.