Announcement

Collapse
No announcement yet.

Fedora 32 Install Media Unlikely To Lose Weight But Fedora 33 Could Be Zstd'ed

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fedora 32 Install Media Unlikely To Lose Weight But Fedora 33 Could Be Zstd'ed

    Phoronix: Fedora 32 Install Media Unlikely To Lose Weight But Fedora 33 Could Be Zstd'ed

    There had been a proposal to better compress the Fedora 32 install media via SquashFS without the nested EXT4 file-system setup for its live images and also ramping up the XZ compression. But this proposal was rejected at yesterday's engineering meeting on the basis that a more optimal compression path could be utilized...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Why the hell they not implement the function to copy the live session to Ram? Just do this and problem solved with zstd.

    You still need to do this mannualy putting
    Code:
    rd.live.ram
    on grub flags.

    Comment


    • #3
      Originally posted by Mario Junior View Post
      Why the hell they not implement the function to copy the live session to Ram? Just do this and problem solved with zstd.

      You still need to do this mannualy putting
      Code:
      rd.live.ram
      on grub flags.
      No idea, probably they believe people still run Fedora on PCs with less than 2gigs of RAM.

      Comment


      • #4
        Originally posted by Mario Junior View Post
        Why the hell they not implement the function to copy the live session to Ram? Just do this and problem solved with zstd.

        You still need to do this mannualy putting
        Code:
        rd.live.ram
        on grub flags.
        It's about the decompression speeds and how XZ is as slow as molasses at Antarctica at very high compression levels and Zstd is just slow at high compression levels. Going to ram or disk won't change that. Zstd is 5-6x faster at decompressing than XZ when both are using their maxed out settings.

        Comment


        • #5
          Originally posted by skeevy420 View Post

          It's about the decompression speeds and how XZ is as slow as molasses at Antarctica at very high compression levels and Zstd is just slow at high compression levels. Going to ram or disk won't change that. Zstd is 5-6x faster at decompressing than XZ when both are using their maxed out settings.
          According to my estimates ZSTD is even faster - up to 30 times faster that XZ when both use the most extreme compression settings.

          Comment


          • #6
            Originally posted by birdie View Post

            According to my estimates ZSTD is even faster - up to 30 times faster that XZ when both use the most extreme compression settings.
            For compressing, yep, it is that much faster, especially the low/fast Zstd compression compared to low XZ compression, but extreme level decompressing is where the gap starts to "close in".

            It's in quotes because Zstd is still faster by a good margin

            Comment


            • #7
              zstd sounds like some Indonesian junk that's going round

              Comment


              • #8
                been there, done that, zstd compressed pkgs since over two years already ;-) https://www.youtube.com/watch?v=dQee4IDoUow

                Comment

                Working...
                X