One thing I obsess a little bit over is the fact that it’s 2026, we pretend that Linux is a serious OS, but we‘re still losing your data on a regular basis.

Out of memory conditions (OOM) are one of our biggest pain points, so I just did a quick experiment with macOS to see how they are handling OOM.

I loaded about 200 memory heavy tabs in Firefox and kept a close look at memory usage.

(1/4)

Once my 16 GB of memory were filled up, with a good extra amount saved thanks to compression, macOS just started creating swapfiles. Memory pressure went from the green to the yellow area, things got a little bit sluggish when switching to the oldest tabs, but no major slowdowns or freezes of multiple seconds.

The more tabs were open, the more swap files got created. At some point the disk would fill up though.

(2/4)

With about 200 MB of disk space left, Firefox froze completely, and at the same time a window popped up telling me that Firefox and a few other apps were frozen (not killed!!!) by the system.

The window prompted to either kill the app or resume it. Pressing resume, Firefox continued running smoothly for a few seconds, until it got frozen again. Pressing resume again, I could quickly close a few tabs, and things worked fine again.

(3/4)

All of this without one tab getting unloaded by Firefox, or one app getting killed without user consent.

So OOM conditions *can* be handled without losing people's data. Don't let kernel developers fool you into believing this is an impossible problem to solve.

(4/4)

@verdre I mean, some time ago I did ended up running a fork bomb on my system, and it was fine, it was really slow and the system monitor wouldn't open. but nothing got killed. and I don't even use swap, just zram
@verdre Do we know how Windows does this? It's got only the one page file which can fill up I think, and IDK if it can dynamically resize.
@x0 Nope, but would be interesting to take a look. I think they are also notoriously bad at this, so wouldn’t expect too much…
@x0 @verdre Windows freezes, does not wake up, shows a black (sic!) screen, complains about "cannot login".
@x0 @verdre I know because node instance went crazy w/o real reboot after a week
@verdre Sorry for sounding like reply guy but this is just unfair comparison.
Kernel OOM is last resort thing, meant to prevent complete freezing of system, which both Linux and MacOS have. MacOS can handle this better because it uses also (partially, more on that later) userspace Jetsom (its not rly named that on MacOS but iOS, but its essentially the same system) handler which monitors memory usage and does actions to prevent memory from going critically high so to not trigger the OOM.
There are systems like that on linux, like systemd-oomd, tho it's done more poorly and those also just kill apps, but before they trigger the kernel OOM.
There are also dynamic swap solutions like swapd, which do more or less the exact same thing, but it's not part of the kernel, which means it has to be installed.
I am not saying that ur wrong about the handling of it on Linux (by default), it's mostly done poorly on most if not all distributions by default, and yeah sure distro's could allow to set it up easier so that they also have dynamic swap, but it's not just a Kernel thing and I dislike this "don't let kernel devs fool you".
It's an desktop implementation and usespace issue, not kernel.
Again sorry for long reply but you insulted ppl based on a fallacious comparison so like lol

@verdre Funny, I just watched this video yesterday: https://youtu.be/Qb4v6YaEQa0?si=J1BHZw9g1EkOSQCE

When I was having trouble running out of memory and my entire computer freezing up, I just bought 32gb of ram, but I’m jealous of macOS.

8 GB of RAM wasn't enough? macOS RAM management explained

YouTube

@verdre I recently came to the same conclusion that the fundamental mistake in how out-of-memory situations are handled under #Linux is that it's based on killing processes rather than pausing them. That leads to doing nothing until it's too late, because killing a process can result in data loss whereas pausing it is relatively harmless (and entirely normal in #Android).

It isn't really a problem with the kernel though. It's the desktop environments that should handle pausing apps when OOM.

@verdre I could not agree more, this really needs improvement on Linux.

There's another feature in macOS that saved me a ton of frustration while writing my thesis in 2019. I had forgotten to plug my MacBook Air in, and with LibreOffice maximized for focus, I must have missed notifications about my battery being empty and only noticed when the screen went black. I was afraid of hours of work being lost, but after plugging in and booting up, LibreOffice launched with my document all intact.

@1peter10 Yup, you're talking about hibernation (aka writing memory to disk and then shutting down).

Not exactly cutting edge technology, it even works on most linux devices if you set it up.

Unsurprisingly, Linux distros don't care enough to make hibernate work OOTB, I'm hoping we can figure it out for GNOME OS though.

@verdre Yes, it's often not set up. From my experience with having the same happen on Windows 10 (but with dataloss), this disregard may be inspired by Microslop.

@verdre the good news is: systemd-swap allows creating swapfiles on demand to increase available swap memory.

The bad news: no distribution enables it by default afaik.

@karolherbst @verdre Just thinking: Couldn't #systemd (already handling oom kills faik) expose some interface over Varlink or dbus for Desktops like @gnome or @kde to replicate that functionality?

@jzohren @verdre @gnome @kde not the best to answer that, but I don't see why that wouldn't be possible.

The current implementation is entirely in userspace and it could choke on sudden spikes and not being able to create swap files quick. But I'd assume all those issues are fixable given enough motivation.

@karolherbst systemd-swap is unmaintained though :/

It seems like in the kernel things are in motion when it comes to mm right now. zram just gained compressed writeback, and zram can also set a custom writeback device, so potentially that could be used as a "fake" swapfile.

@verdre @karolherbst There's also https://github.com/Tookmund/Swapspace, packaged in Debian as swapspace, also not installed by default.

It worked well enough to completely hide an xdg-desktop-portal-gnome memory leak from me, until I accidentally noticed I had 17 GB of swap files for some reason after running htop.

GitHub - Tookmund/Swapspace: A fork of Jeroen T. Vermeulen's excellent dynamic swap space manager

A fork of Jeroen T. Vermeulen's excellent dynamic swap space manager - Tookmund/Swapspace

GitHub
@verdre Just a few days ago I accidentally closed a wrong window in Firefox. Thankfully Firefox keeps track of recently closed windows and lets you reopen them. The window had 8k tabs (don't ask). It took some half an hour and 80 GB of swap space but it did reopen the window and lost no tabs. Even tab groups were preserved.