Mozilla Firefox Switches To .tar.xz For Linux Packaging

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • fitzie
    Senior Member
    • May 2012
    • 672

    #41
    Originally posted by Anux View Post
    Woha. That's some next level logic there!
    yes, zstd ships two command line tools, zstd and pzstd. that's how they can be internally inconsistent. troll.

    Comment

    • Anux
      Senior Member
      • Nov 2021
      • 1942

      #42
      Originally posted by Weasel View Post
      Downloading the packages is much slower than xz decompression already for most people (1 Gbps is about the same), so literally who cares?
      So ill informed:
      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.
      https://archlinux.org/news/now-using...e-compression/

      Originally posted by fitzie View Post
      no distro packaging
      Another lie.​
      Originally posted by fitzie View Post
      yes, zstd ships two command line tools, zstd and pzstd. that's how they can be internally inconsistent.
      pzstds options are a subset of zstd and cmd-line structure is exactly the same.

      Comment

      • intelfx
        Senior Member
        • Jun 2018
        • 1136

        #43
        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)
        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".

        Originally posted by fitzie View Post
        saying 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.
        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.
        Last edited by intelfx; 03 December 2024, 06:05 AM.

        Comment

        • Weasel
          Senior Member
          • Feb 2017
          • 4501

          #44
          Originally posted by Anux View Post
          Do you even fucking read what you quote?

          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

          • Anux
            Senior Member
            • Nov 2021
            • 1942

            #45
            Originally posted by Weasel View Post
            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
            Exactly, that's why I quoted the thing that says 0,8% size increase. You seem to believe that downloading and decompression happens at the same time but all package managers I know do it serial. So decompression is added to download time.
            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).
            It obviously depends on your hardware, if you have a RasPi with Gb-internet then zstd or lz4 is better, if you have a threadripper with a 65k modem then xz would be better.

            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

            • fitzie
              Senior Member
              • May 2012
              • 672

              #46
              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.
              this is the most obvious and stupid default behavior, and you didn't even notice the lack of --exclude-compressed being the default there, so I don't even think more examples could help you. i could cite a lot more but you can look for yourself if you cared but you dont, just like the zstd developers. i think you are stuck in 1971. I don't think you will make a 16 bit timestamp overflow.

              hope that helps.

              Comment

              • fitzie
                Senior Member
                • May 2012
                • 672

                #47
                Originally posted by Anux View Post
                So ill informed:



                Another lie.​

                pzstds options are a subset of zstd and cmd-line structure is exactly the same.
                I'd have to review any shell scripts you write, I'd expect it to have many false assumptions.

                Comment

                • intelfx
                  Senior Member
                  • Jun 2018
                  • 1136

                  #48
                  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
                  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

                  • fitzie
                    Senior Member
                    • May 2012
                    • 672

                    #49
                    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.)​
                    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. I'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.

                    Comment

                    • intelfx
                      Senior Member
                      • Jun 2018
                      • 1136

                      #50
                      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.
                      I'm not ignoring your point, I'm rejecting your point. It is an afterthought for the zstd developers because it is an afterthought. It is, in my conviction, not a behavior that anyone should rely on, much less consider a "significant difference" or, worse, a basis for implying negligence.

                      Originally posted by fitzie View Post
                      I'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.
                      They, in fact, are. These kinds of projects tend to severely lag behind the state of the art, and not just in terms of compressors supported. So yes, it is pretty reasonable to say that they are likely still stuck in 2020.

                      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

                      Working...
                      X