The one-liner:

dd if=/dev/zero bs=1G count=10 | gzip -c > 10GB.gz

This is brilliant.

    • ivn@jlai.lu
      link
      fedilink
      English
      arrow-up
      19
      arrow-down
      1
      ·
      edit-2
      12 hours ago

      Linux and Windows compress it too, for 10 years or more. And that’s not how you avoid zip bombs, just limit how much you uncompress and abort if it’s over that limit.

      • Aatube@kbin.melroy.org
        link
        fedilink
        arrow-up
        4
        arrow-down
        2
        ·
        13 hours ago

        All I know is it compresses memory. The mechanism mentioned here for ZIP bombs to crash bots is to fill up memory fast with repeating zeroes.

    • DreamButt@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      12 hours ago

      No, but that’s an interesting question. Ultimately it probably comes down to hardware specs. Or depending on the particular bot and it’s env the spec of the container it’s running in

      Even with macos’s style of compressing inactive memory pages you’ll still have a hard cap that can be reached with the same technique (just with a larger uncompressed file)

      • 4am@lemm.ee
        link
        fedilink
        English
        arrow-up
        1
        ·
        8 hours ago

        How long would it take to be considered an inactive memory page? Does OOM conditions immediately trigger compression, or would the process die first?