Re: Suggestion: Remove the -z / -j parameter from tar when dealing with compression

[Michał Górny]

On Tue, 2020-06-02 at 20:09 +0200, Reelix wrote:
> Linus Torvalds - From a recent post over at
> https://lkml.org/lkml/2020/5/29/1038 - Claimed
> 
> "People with restrictive hardware shouldn't make it more inconvenient
> for people who have better resources."

No offense but this seems to be a citation out of context.  I expected
to see some article about compression and this is just about Linus' line
width preference.  There's a huge gap between the two topics.  It's one
thing to say 'use wide lines because practically everyone reading
the code will have wide screen', it's another to say 'do not use
compression because practically everyone will have huge memory'.
The former means a few magnitudes less people.

I don't think Linus would have agreed with your assessment.  Do you
think he would appreciate trying to use his authority to push your idea?

> In the tar application, the -z / -j parameters exists for the purpose
> of decreasing the resultant file size of the created archive. The
> problem is that in doing so, the compression/decompression time
> increases.

Compression/decompression time cannot increase because without
compression there's no compression/decompression time.

> For those with larger amounts of storage, faster disks, and faster
> internet connections, this benefit is negligible, although they still
> have to suffer from the increased decompression time from those that
> have initially used the parameter.

With the majority of compression algorithms in use decompression is very
fast.  If you have high-end hardware, the time used in decompression is
negligible.

Even for medium-to-high-end hardware there are very fast compression
algorithms that can make a difference (LZ4, zstd...).  When dealing with
large amounts of low-entropy data, they can increase throughput by
achieving small compression in real time.

If you have low-end hardware, compression can be a life saver.  If you
really think this doesn't apply to any modern uses, I'd like to remind
you that people sometimes travel and have very poor reception. 
Compression can make a difference between being able to fetch a file
and losing the reception in the middle of it.

> I suggest that we follow Linus' idealogy and remove this parameter as
> - Like he claims - "People with restrictive hardware shouldn't make it
> more inconvenient for people who have better resources."

Removing this 'parameter' makes no difference.  People can still pipe
to a compressor, or compress the tarball afterwards.  That's just
killing a convenience and breaking a lot of existing scripts and tools.

-- 
Best regards,
Michał Górny

signature.asc
Description: This is a digitally signed message part