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