Originally posted by Anux
View Post
Mozilla Firefox Switches To .tar.xz For Linux Packaging
Collapse
X
-
Originally posted by Weasel View PostDownloading the packages is much slower than xz decompression already for most people (1 Gbps is about the same), so literally who cares?
Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup.
Originally posted by fitzie View Postno distro packaging
Originally posted by fitzie View Postyes, zstd ships two command line tools, zstd and pzstd. that's how they can be internally inconsistent.
Comment
-
-
Originally posted by fitzie View Post
1) gzip *; (compresses all files not ending with gz and removes them)
2) zstd *; (compresses all files including .zstd files and doesn't remove them)
And it has all the same flags, it's just the default that was flipped — so nothing is being "unfamiliar".
Originally posted by fitzie View Postsaying zstd is the standard is pretty out of touch. no distro packaging, no container packaging uses it. not a default in github or gitlab, etc.
I really think you're writing from year 2020. Please run that time machine in reverse direction and get back to 2024.Last edited by intelfx; 03 December 2024, 06:05 AM.
Comment
-
-
Originally posted by Anux View PostSo ill informed:
https://archlinux.org/news/now-using...e-compression/
I never said zstd isn't faster at decompression, I said the bulk of package installation is in the DOWNLOAD stage for most people. Even those with Gigabit connections still have it slower than xz decompression with a decent CPU, assuming the server isn't congested in the first place (in which case no connection would help you).
I don't give a shit if zstd is a million times faster or even instant at decompression, if 90% of the time is taken by download. I mean for packaging obviously.
I don't hate zstd, I think it's a great algorithm. I use it where I need speed, like my entire root filesystem is in squashfs with zstd for speed. Or live compression like my ZRAM. Package management/downloads ain't one of them.
But in other cases xz is obviously superior because any bit of size reduction is better, giving adequate speeds (there's compressors that are better than xz but are ultra slow, like 500 KB/s kind of deal).
Yes LZ4 is even faster than zstd but its compression ratio is pretty terrible. Unless your data compresses well with it (i.e. a lot of wasted data, probably zeros), it's pointless; at that point just don't compress at all?Last edited by Weasel; 03 December 2024, 12:30 PM.
Comment
-
-
Originally posted by Weasel View PostI said the bulk of package installation is in the DOWNLOAD stage for most people. Even those with Gigabit connections still have it slower than xz decompression with a decent CPU
But in other cases xz is obviously superior because any bit of size reduction is better, giving adequate speeds (there's compressors that are better than xz but are ultra slow, like 500 KB/s kind of deal).
But since there is practically no difference in size with the change to zstd people with slower hardware do profit while others hardly notice the difference.
Comment
-
-
Originally posted by intelfx View Post
So the only "unnecessary difference" you could cite is that zstd uses --keep instead of --rm by default? That's quite a flimsy argument you got there. Besides, the difference is necessary: deleting source files is bad UX, no other CLI tool does that.
And it has all the same flags, it's just the default that was flipped — so nothing is being "unfamiliar".
Yeah, like Arch and Fedora and OCI containers and podman (the change to default in F41 was rejected, but it's not really "rejected" as much as "delayed", they are going to implement double-compression and retire gzip later, which is a clear migration path in progress)? Talk about being out of touch
I really think you're writing from year 2020. Please run that time machine in reverse direction and get back to 2024.
hope that helps.
Comment
-
-
Originally posted by Anux View Post
Comment
-
-
Originally posted by fitzie View Post
this is the most obvious and stupid default behavior, and you didn't even notice the lack of --exclude-compressed being the default there
Put it other way: if you wrote a script relying on that behavior (or absence thereof), I'd fire you. (And yes, I'm in position where I do make such decisions.)
Comment
-
-
Originally posted by intelfx View Post
That's an even more flimsy argument. Out of all the gzip/bzip2/xz man pages, this behavior is only mentioned in passing in one of these, so what's actually monumentally stupid is relying on it.
Put it other way: if you wrote a script relying on that behavior (or absence thereof), I'd fire you. (And yes, I'm in position where I do make such decisions.)
Comment
-
-
Originally posted by fitzie View Post
you are ignoring my point. I didn't say it's hard to figure it out, it's just an afterthought for the zstd developers.
Originally posted by fitzie View PostI'm sure if and when toybox/busybox adds zstd it will not be trash like it is upstream. for some reason they are still stuck in 2020. I'll let them know.
It's not a bad thing per se, but I prefer to call a spade a spade.Last edited by intelfx; 03 December 2024, 05:31 PM.
Comment
-
Comment