Well, not just the default behaviour.
It's probably nonsensical to assume that a specific compression level will
produce identical (or even similar) results across different implementations
because
there are other possible variables, like the GZIP_FAST flag.
There is though a slight
Well, it seems that Denys merged the changes before I have the time to
respond to comments, but anyway:
I actually disliked the argument about "de-facto standard" on compression
levels. I think scripts should not depend on the default compression level,
and should instead specify it explicitly.
Applied, thanks
On Mon, Sep 2, 2019 at 11:58 PM Daniel Edgecumbe
wrote:
>
> Let's try once more, patches inline (new email client, gah!)
>
> 0001-gzip-default-level-with-ENABLE_FEATURE_GZIP_LEVELS-s.patch
>
> From 9d06f01e2805a5d6f1d775ceb651ae18ae2e1808 Mon Sep 17 00:00:00 2001
> From: Daniel
Hi,
On Tue, Sep 03, 2019 at 10:31:20AM +0800, Kang-Che Sung wrote:
> gzip -9 is quite fast in modern processors, and if someone builds busybox
> without CONFIG_FEATURE_GZIP_LEVELS, I think they are moke likely to stick
> with -9 as default instead of -6.
No, -9 is really slow with little gain:
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
I split out the third patch for this reason. I agree, it can be dropped
if people see no need for it. Adding a compile-time option I think is
overkill.
Daniel
On 03/09/2019 04.31, Kang-Che Sung wrote:
>> From 12d30559486502feec4e2821b3ab45ae6139e7aa Mon Sep 17 00:00:00 2001
>> From: Daniel
> From 12d30559486502feec4e2821b3ab45ae6139e7aa Mon Sep 17 00:00:00 2001
> From: Daniel Edgecumbe
> Date: Mon, 2 Sep 2019 22:09:15 +0100
> Subject: [PATCH 3/3] gzip: set default compression level to 6 when
> CONFIG_FEATURE_GZIP_LEVELS=n
>
> With this change, GNU gzip -n and BusyBox gzip now
Let's try once more, patches inline (new email client, gah!)
0001-gzip-default-level-with-ENABLE_FEATURE_GZIP_LEVELS-s.patch
>From 9d06f01e2805a5d6f1d775ceb651ae18ae2e1808 Mon Sep 17 00:00:00 2001
From: Daniel Edgecumbe
Date: Mon, 2 Sep 2019 22:03:14 +0100
Subject: [PATCH 1/3] gzip: default
A discussion with eschwartz on the Arch Linux freenode IRC channel led
to the discovery of some minor implementation details lacking in the
BusyBox gzip applet which can cause output to differ both across GNU
gzip and BusyBox, and different versions of BusyBox.
Please find attached three
On 9/2/19 5:31 PM, Daniel Edgecumbe wrote:
> A discussion with eschwartz on the Arch Linux freenode IRC channel led
> to the discovery of some minor implementation details lacking in the
> BusyBox gzip applet which can cause output to differ both across GNU
> gzip and BusyBox, and different
10 matches
Mail list logo
