3 ms·
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
by fn-mote 2y ago
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 2y ago> 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 2y agoYeah 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.