You fap to YouTube?

SatansMaggotyCumFartFutaCum

Picture of my nutsack :
Is this a meme?

5th option : “I don’t give a shit.”

There’s plenty of Americans that love hockey, they’re just the ones that share a boarder with Canada, lmao.

“well duh, you were using one of those stupid AI boyfriend apps”

I’m so lucky, one day my heart will just explode and I’ll be dead instantly. Lucky me.

I just fly.

There’s an ffmpeg command to do it.

And remove the child because they eat more than what’s sustainable.

Here’s the how video. Still only mildly interesting lol.

If the data is overflowing from Zram into the backing device because the Zram block is full, that doesn’t necessarily mean that data is uncompressible. It simply means that there’s no place to put it even if it was compressible. The truly incompressible data ideally should be stored in the RAM that’s not allocated to the Zram block device, unless that RAM space is also already taken, then that data would go to the backing device. The scenario I’m thinking of is a lot more specific. Ofc, Zram would prioritize truly incompressable & idle data first when pushing into the backing device, keyword there is "idle", which supports the idea that the data isn’t necessarily uncompressible.

Already compressed media, for example, can’t really be compressed. In fact, if you try, you might just find it actually ends up bigger than the original.

There’s no case where this would happen, the data being pushed to the backing device is always unmodified by Zram, regardless if it’s compressible or not. Also, already compressed media would not necessarily be seen as incompressible by Zram. Zram can still compress already compressed data to some extent, depending on the type of compression used and the compressibility of the original data. For example, if the original data was compressed using a simple algorithm like LZMA, Zram might be able to achieve better compression using a more advanced algorithm like LZ4.
However, the benefit of compressing already compressed data with Zram is usually minimal as you’ve already said.
This is the primary purpose of CONFIG_ZRAM_MULTI_COMP to handle cases where the primary algorithm is unable to efficiently compress certain data.
Also, Btrfs uses a built-in pre-compression heuristics algorithm to analyze each file and determine if compression is beneficial. Comparatively, Zram has no such mechanism so it attempts compression regardless.

Tbh, deep down the rabbit hole is an understatement. here’s a more detailed documentation of Zram.

Edits : Wording improvement’s and added supporting sources.

Zram offers way more flexibility and versatility compared to ImDisk.
Zram can be used for swap space or as a general-purpose RAM disk. Unlike a traditional RAM drive, Zram can compress data using a nice hand full of algorithms, notably Zstd; allowing it to store more information within the same RAM capacity leading to faster I/O and efficient memory usage with minimal CPU usage; & LZO-RLE; offering the fastest compression and decompression speeds leading to faster data swapping between compressed and uncompressed states, potentially improving overall system performance. Also, ImDisk afaik only offers NTFS compression for RAM drives which is… well… pretty damn slow for this particular use comparatively.
Additionally, Zram persistence can be configured with writeback devices. ImDisk typically doesn’t offer persistence.
ramdrive.sys isn’t even worth talking about, it never had any kind of compression let alone anything else I mentioned previously.

Zram is very different. What Windows has is closer to Zswap.

That’s not that same. That’s closer to Zswap. “Enable-MMAgent -MemoryCompression” enables compressing inactive memory pages in RAM. Zram is 1 or more compressed block devices in RAM that can store a much larger variety of data.

But does it have Zram? 😏

It’s called going to McDonald’s walk-in and seeing a Karen…

The meme said “strange man” not “male partner”.