just as debian patches out spyware, they should be aggressively culling any package that isn't multithreaded. zipping a 5gb file should not peg one core of my 36 core machine and take 30x longer than it should. this is madness.

@alrs why are things like gzip/bzip2 installed or even available when they are so plainly defective

@sneak There are a lot of shell and even Perl and Python scripts out there that were written against gzip.


@alrs yes so why is the existing broken one being shipped and not a replacement with the same name?

@sneak "broken" sounds a bit strong. I imagine that pigz doesn't create byte-for-byte bug-for-bug identical output to gzip. That would be a pretty massive project with a multi-architecture QA effort to rival that of sqlite.

@alrs if i am compressing a file and it takes 32x longer to compress than it's supposed to, that's broken.

@sneak I see your viewpoint. To me the path out of this is "we've got Go now, so let's accept that anything non-trivial written in shell, Python, Ruby, Perl or Node is tech-debt toxic-waste." Instead of "ZOMG BROKEN" I see the situation as "this janky stuff is going to be around a long time, and as long as we're deleting shell scripts faster than we write them, that's fine."

@alrs you have turned my statement that "the gzip package in ubuntu is pathologically broken and should be fixed or replaced" into some kind of anti-shell-script, "rewrite stuff" tangent. i'm fine with shell scripts calling gz. i like bash. i don't like a 30x slower /usr/bin/gzip for no reason.

@sneak a version of this converstion is shaking out on the Debian lists right now. lwn.net/Articles/846405/

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!