I don't see how RAM compression helps address the machine locking up when it'll still lock up when the compressed RAM is used up. It just buys you a little more time.
Also, Fedora has had zram enabled by default for a few years now along with systemd-oomd (which can sometimes be too aggressive at killing processes in its default configuration, but is configurable).
systemd-oomd is also default since Ubuntu 22.04. I remember it vividly because it effectively kept killing X when RAM filled up instead of sanely killing the process that last filled up the RAM, which is either gcc or firefox in my case. Absolutely user-unfriendly default configuration. I removed it and reinstalled earlyoom, which I have been using for years with a suitable configuration. I can only concur, RAM behavior isn't user-friendly on Ubuntu.
Thank you for mentioning earlyoom - I'll install and try it because current behavior of total, complete lockup without ability to do anything besides reset with the hardware button infuriates me unbelievably.
I really don't comprehend how something like this is possible
and default behavior in 2023 in OS marketed as 'desktop' and 'casual/user friendly'
Because it slows down as you use more RAM compression, so you have time to respond and close some apps. Without it you are working at a thousand miles an hour and then suddenly, brick wall.
Ah yes, the old, "you should enable swap so that when your RAM fills up, you know about it when the disk starts thrashing and all I/O grinds to a near-halt."
I mean, swap is useful, but that's not what it's for. Same is true for compressed RAM. If you want an alert for low available RAM, it seems like it would be better to write a script for that.
> disk starts thrashing and all I/O grinds to a near-halt
Nope, neither of those things happen when zram starts compressing ram. Nothing grinds to a near halt until the compressed RAM space is used up, it just slows down a little bit. Btw, compressed RAM via zram isnt swap, it's available as actual ram. It also increases the total amount of ram available. I don't think I need to make arguments in favor of ram compression since Windows and macOS both have ram compression by default.
In the case of zram, it reserves a portion of the physical RAM, and when the remaining physical RAM portion runs out, it begins compressing ram into the reserved portion. So the system slows down a bit as this compression starts happening. Nothing really adaptive about it to my knowledge but the result to the user is a noticeable slow down when there is high ram usage, which is a heads-up to me to close some stuff. Without it the system just locks up as soon as physical RAM is exhausted, without any warning, since it's fast up until that moment. Hope this makes sense. I'm not an expert on zram or other Linux RAM compression packages, so can't really answer questions about it beyond that.
Yeah you'd think it would make no difference but in my experience it does help a little. Don't ask me why.
But yeah even with zram my laptop still hard reboots 80% of the time when it runs out of RAM. No idea how people expect the Linux Desktop to ever be popular when it can't even get a basic thing like not randomly rebooting your computer right.
Also, Fedora has had zram enabled by default for a few years now along with systemd-oomd (which can sometimes be too aggressive at killing processes in its default configuration, but is configurable).