Patches to make GNU gzip and BusyBox gzip produce identical compression results

Martijn Dekker martijn at
Tue Sep 3 12:39:03 UTC 2019

Op 03-09-19 om 04:31 schreef Kang-Che Sung:
> Excuse me, but I wonder one thing on the third patch: Why should we follow
> strictly with gzip on the no-options default behavior?

For two reasons.

First, the default 6 compression level is a de-facto standard. BSD gzip 
and Apple gzip (on macOS) use this default as well. So there is a 
reasonable expectation that different gzip implementations act the same. 
For instance, if the default for busybox gzip becomes 9, then someone 
writing a script using busybox gzip could reasonably expect that the 
compression level will still be 9 when the same script is run on another 
system. That would be wrong. Implementations should not deviate from 
de-facto standards without a strong reason.

Second, the inherent reason for this default has not gone away. While 
processor speeds have exploded since the default was set, so has the 
typical size of compressed files. Multiple gigabytes are nothing unusual 
these days. And gzip is often used for compression on the fly, precisely 
because it offers a good compromise between speed and compression ratio. 
So I believe 6 continues to be a reasonable default.

> The better change would be to allow the builder to choose the compression level
> at build time.

I disagree with that as well, for the same reasons.

- Martijn

modernish -- harness the shell

More information about the busybox mailing list