I hope there will be an update where when my RAM gets full my PC doesn't freeze and becomes unusable... I remember that Linux and Windows do this in different ways and Windows doesn't have the problem.
I now have btop permanently running in a Terminal and I habitually Alt-Tab to it to watch my swap. As soon as my free memory gets less than 1 Gb I kill any Firefox tabs (the memory black hole).
I know this won't be popular, but Linux people have some kind of Stockholm Syndrome on this. They tell you all of the obscure configuration files you have to edit, the additional programs you install. They insist that just having the OS kill a random program to save the DE is a good plan. It's the typical "your holding it wrong" mantra.
I run both Windows and MacOS and have done so for decades. I cannot remember the last time I had a hard freeze like I get on Fedora. On the exact same box running Windows I was able to have VS Code, Chrome with 15+ tabs, terminals, docker, etc. all running with zero issues. On Fedora I have a handful of Terminals and Firefox with less than ten tabs and nothing else running and I have to watch btop like a hawk.
The excuses people make are mind bending, and the shifting of blame from the system onto the user is shameful.
The vast majority of my computer use has been on MacOS for the last 15+ years, since a Macbook Pro is the standard issue dev environment at every company I have worked at. I had a Windows desktop entirely for gaming that I've repurposed to be a Linux dev box. I genuinely thought all of the hype about Linux desktop that I have seen lately was an indication that it was finally ready for general use.
Now that I am vigilant watching RAM I haven't had the freezes. And I refuse to let the OS roll the dice on what program it wants to kill in its last ditch attempt to save itself from a problem it shouldn't have in the first place. And since Firefox seems to demand 800MB-1GB per tab process, it is a reliable scheme to just close heavy tabs when I see memory dip into the danger zone.
I just wish RAM wasn't so expensive right now, since I'd buy as much as I could just to avoid this pain.
The Linux world is a different kind of beast. I too went through the same motions as many newbies but at some point I just stopped complaining and started fixing what I didn't like.
If you start screaming for corporate money which should fix things that's another can of worms, corporate doesn't really do good will, they are usually buying control whenever they pour money into a project. Which can become tricky for Linux.
What a fucking joke lmao. I'll just keep buying Macs.
> Who should do it for you?
People who want me to use it.
Stay on macos. Or windows. Whatever. Have fun.
edit: Just to be clear, my point is about entitled people demanding things like they paid for it. You do that in a restaurant, where you pay for the service, you expect certain things. I understand if something isn't working it isn't great, but spitting on it while it's free because you feel entitled is the wrong attitude. That's what a lot of people getting into Linux get wrong, they feel entitled to it, while it's free. You need to adjust your expectations.
> decades, which is as long as they've been unable to crack double digit users
and you say
> I honestly don't really want you to use it.
then you kinda make their point entirely for them.
I'm not even going to bother addressing the rest of the projection in your post. Whew.
Is it acceptable? No. Did it solve my endless crashes that I used to get every day? Yes.
I don't love Ubuntu, I just hate modern Windows and find my ubuntu for work popos for gaming setup to be better for me. Ymmv.
At work I ran the same Firefox profile in Windows, with 16 GB of RAM, it used to eat RAM more eagerly, and restarting only helped for a few hours. I never understood why, but GMail and WhatsApp tabs were usually the biggest memory drains.
I'm just happy I don't have to deal with that anymore, since we were moved to iMacs at work, and the same Firefox profile gives no trouble with 24 Gb or RAM. WhatsApp is still the hungriest tab, but it stabilizes. Maybe there's a sweet spot between which tabs are opened and how much RAM do you have?
I’ve found a few idle YouTube tabs is enough to bring macOS to its knees. Though I do wonder if uBlock Origin is the hidden cause rather than Firefox itself.
This is what nohang [0] does. There is no reason to do that by hand. Obscure configuration files to edit?
Yeah it's kind of annoying that it's not built in to most desktop distros, but... literally `apt install nohang; systemctl enable --now nohang.service`. Hardly that difficult.
And then I scroll down and see the install instructions for my distro:
> To install on Fedora:
>
> Orphaned for 6+ weeks, not available.
But hey, just sudo install this package! What could go wrong? You only use your desktop to access your online banking, etc. Forget the trust mechanism of your distro and just live a little!
By killing a program, yes, but how else do you expect it to work? If your RAM is not enough you have to kill stuff. And I really doubt you mean to say that Windows is _more RAM efficient_ than Linux, because that's kind of absurd. Maybe Firefox is less RAM efficient than Chrome.
Edit: MacOS I wouldn't doubt being better in RAM management than the others because they have been selling their devices with ridiculously low amounts of RAM for decades.
It's been less than 24 hours since an OOM killer was identified as responsible for a bug I was experiencing.
How does it work on Windows and MacOS where I don't get the same freezes and random programs aren't killed by the OS? Because I'd expect it to work like that.
There is this false dichotomy, a black and white kind of thinking on display.
> And I really doubt you mean to say that Windows is _more RAM efficient_ than Linux
What I'm saying ought to be clear to anyone willing to listen. My system should not get into an unrecoverable freezing state when I am doing routine tasks on a fresh install of an OS. And the community that is supposed to champion this OS should not then shift the blame to me if I complain about it.
This video from Mark Russinovich is a classic explaining it. It is old but still relevant.
https://m.youtube.com/watch?v=AjTl53I_qzY&ra=m
"My system should not get into an unrecoverable freezing state[..]"
There is a good precedent for what you want: Safety critical embedded systems. Your car ECU should not be in an unrecoverable freezing state when you want to break.
These embedded systems also are known to be terribly memory inefficient because every bit of memory is statically assigned and never reused.
So, it is not that what you want is impossible, it's just wasteful and expensive.
Linux and Windows sit on slightly different points on this spectrum (opposite of said embedded systems) and what you perceive as Windows' better behavior under memory pressure has a price too.
I've moved to Linux from Windows some years ago but the first thing that shocked me was precisely the abysmal performance around low memory availability.
Got my system stabilized eventually by means of some magical incantations but this wasn't a pleasant experience and I wouldn't want to repeat it.
It's beyond me how come Linux is so decrepid in this particular area compared to Windows.
And back when I was forced into running Windows, I used to get memory-related freezes daily. Literally daily.
So I’m really not convinced the situation is drastically different there. I mean if it were that simple, Linux would have fixed it already.
On Windows it's usually the hard drive being over-used that makes things drag for me.
Linux already does this. The issue is when your swap is full too, or you’ve exhausted your RAM at such a rapid pace that the disk IO cannot keep up with the read and writes to swap.
I’ve seen Windows choke under the same conditions too.
> do something like pre-X macOS, where it would provide a warning when you are getting close to running out of memory, so that a user might have the chance to do something before the current process starts getting swapped out.
This is where the desktop and the kernel being entirely separate organisations (not even projects, but literal organisations) makes things a touch harder. And those DEs aren’t even Linux specific either. So any tooling would have to portable (which, in fairness, should be possible with POSIX in this particular scenario).
I think KDE does provide tools here for gracefully handling memory constraints. But that’s just one desktop environment of many.
And I've run out of memory while compiling packages (I'm looking at you, composable-kernel) on Gentoo. It's not like it can notify me and I close things in the milliseconds it takes for a few more GCC processes to spawn and allocate and fault all the remaining memory.
I don't know what that means. When your system is in such extreme memory pressure, it comes to a crawl, exactly because your memory use can't outpace your IO. There's no 'cannot keep up' state.
Btw, there's (at least) two sides to swap:
(1) While there's plenty of headroom, you might still want to swap out 'cold' memory, so you can keep more files cached in RAM.
(2) When you are (nearly) out of memory, you need to evict to swap so that you don't run out-of-memory.
Swap mostly helps you, when you have plenty of cold memory that are pretty much never accessed again. Or when you have applications that you switch, but that you don't use concurrently.
When your active working set is bigger than your RAM, then, yes, swap is slow.
Surely that's obvious to other people aside from me. It's an attended system, not a headless server in a rack hundreds of miles away that must not ever alert someone.
You can pick applications from that list and choose between "Resume" (for "paused" applications) or "Force Quit".
At no point the system becomes unresponsive.
That is, if you are lucky enough for the dialogue to pop up.
I do agree that when you get the dialogue, it is a much better user experience than under Linux.
Also I know linux has `cgroup_enable=memory` setting in /etc/default/grub, that's for Docker/K8S to be able to watch over containers RAM. It's not enabled by default as it slows down OS a little. Don't know if it's related to my first point.
Meanwhile if I try something similar on a 32GB Linux system, it will sputter or outright freeze. Suspend the system at 16GB used and on wakeup it takes 15 seconds to get back to full responsiveness.
Yes, some of this can be addressed with swappiness settings, however that behavior isn't partically clear and doesn't take into account that depending on your workflow on a given day (e.g. coding then video editing) different swap behaviors may be more optimal. Nor does it help for people who are trying to get good productivity out of a 16GB or lower system.
The one thing that has helped is moving to Brave Origin. Whether that's loading less JS ad SDKs or general optimization, it does seem to use a lot less ram than Edge/Chrome.
Where did the technology go?
Well, As a bizarre counter thought...
My work PC, at least with all of the corporate fuckware installed...
I tend to see two behaviors when moving between work and home.
Either:
A - It won't go out of sleep, it basically forces a reboot.
Or,
B - It leaks memory that I can't free without a hard reboot, to where even copy-pasting becomes absolutely jank (my favorite nasty behavior; it double-processes paste operations, not fun when dealing with credentials...)
I do have 'local admin' and while I only checked a couple of times, both times it looked like even then I couldn't do a force kill/restart of whatever was jacking the thing up.
Meanwhile my wife's current 'my old' PC with the same amount of RAM as work laptop and probably lower/older CPU spec could last between forced windows updates without a reboot and a lot more general churn.
-----
If there's one reason I'm bringing this up, it's because I know my work PC has a lot more 'kernel' type management stuff installed...
And yeah, workplace people in charge of that stuff gives that same weird 'blame the user' focus as what you describe.
I use it when I am doing exploratory work and might materialize something too big. It has always killed the Python process or terminal program which did something silly.
I've gotten plenty of freezes and even more slowdowns on my MacBook Air M3 when using lots of RAM. But I'm using a lot more than 15 tabs in Firefox, and quiet a few VS Code instances, too.
I agree that we should be improving Linux instead of making excuses.
When I run in a frozen system because of RAM, I'm a happy user of the Magic SysRq 'f' [2], it bypasses most kernel scheduling so it works even on frozen systems
Docs https://docs.kernel.org/admin-guide/mm/multigen_lru.html#thr...
I don't use Windows much, nor do I care much about that environment, but from what I've seen it seems to keep RAM usage below 100% most of the time. What I do see pretty often is the drive getting stuck at 100% usage instead, which makes the whole system ridiculously unusable anyway.
Running out of memory on a linux server sounds more like a skill issue than something comparable to how a desktop OS should behave :\
Thing is that I never know this could happen. As a Windows user I'm used to a system that does stuff in the background without knowing how it works.
My Linux VM's can be broken because I'm in charge and I'm a noob. I kind of love it. I've learned so much from troubleshooting.
This has so many variables that it's practically useless as a data point. We have a few Ubuntu VMs running complex business web applications and their Postgres database on only 4 GB or RAM and 20-50 GB of storage, no swap space. Ocassional high load, but Zero OOM problems for many years.
We could upgrade the RAM, but we were stingy when we created them, and it has worked well so far, so why waste resources? Incidentally, using no swap was a deliberate choice, as it would slow things down too much. We preferred to see and correct any memory/OOM issues beforehand, but fortunately we had none.
Linux uses lazy allocation and overcommits, so what dies isn’t necessarily what you would expect thanks to the OOM killer.
With a fixed swap size windows doesn’t necessarily slow down as it runs out of memory.
YMMV if you don’t have 64 gigs of RAM and a 64 gig swap.
So Apple can build a whole user-controlled GUI workflow around memory exceptions, which Linux cannot.
Maybe what needs to happen is new Linux syscalls + signals for DEs to utilise for building memory exception UIs? But the problem then with that is you’re impacting the portability of those DEs. So some maintainers might still refuse to work with Linux to provide this.
That all said, I’m pretty sure KDE does provide GUI tools for when this kind of scenario arises.
Also we cannot use the reasoning Linux means distributions, instead of using GNU/Linux for it, and other times Linux is just the kernel, depending on convenience.
You did. But without examples, it’s a meaningless throwaway.
Personally, I can’t say I’ve pushed many other UNIX desktops that far that they’ve OOMed. Except maybe OpenSolaris and FreeBSD, neither of which faired much better. But they’d also suffer from the same kind of DE development issues I described for Linux.
> Also we cannot use the reasoning Linux means distributions, instead of using GNU/Linux for it, and other times Linux is just the kernel, depending on convenience.
I’m not saying it for convenience. I’m saying it because it matters in this specific situation.
Surely you must understand that the reason Windows and macOS have arguably better GUI support for OOM is because the same company that owns the kernel also writes the frontend too? It’s hardly rocket science as a concept.
As I said in my previous comment, there are ways Linux (the kernel) could work with DEs to bridge that gap. But at present, they’re entirely separate concerns.
In any case, Xenix, DG/UX, SunOS/Solaris, Aix, HP-UX, z/OS UNIX, NeXTSTEP.
The context of the thread is about the UX.
And the OS crashing isn’t a better option than an OOM killer. Frankly, there’s no good automated options. That’s why modern desktop OSs present users with a warning. And hence why we are talking about GUIs.
> In any case, Xenix, DG/UX, SunOS/Solaris, Aix, HP-UX, z/OS UNIX, NeXTSTEP.
Listing OSs doesn’t explain how they handle things better.
For example you’ve cited SunOS and I already said previously, I’ve seen SunOS completely die on its arse when OOM.
Alas, not one that was made back in 1970, so here we are.
To be clear: I’m not trying to defend Linux here. Just calling out the GPs BS when he said Linux is uniquely bad in POSIX.
But Windows has always handled both OOM and out of disk space very well. The system will be extremely sluggish, but it typically continues operating.
The Linux design is to keep using memory, then push to swap, and then when you OOM you hard lock. The built in kernel OOM module can miss when RAM usage spikes rapidly. You can enable OOM monitors like systemd-oomd or earlyoom, but they do not run by default, and their behavior is to term the offending process.
The thing about Windows is that when you request memory, you're only granted memory if it can be guaranteed in the first place. The application will get a "not enough memory" error. On Linux, you're permitted to request more memory than the system actually has, with the idea that you won't actually use that much memory. It's optimistic that way. But if you do use it, then you're screwed.
sysctl -w vm.overcommit_memory=2 sysctl -w vm.overcommit_ratio=50
It is probably a bad idea to do that though as it will limit the amount of virtual address space an application can use
In the short time between fork() and execve(), the new process duplicates the entire virtual memory of the old one. None of this is physically allocated due to copy-on-write, but still all counts as virtual memory.
Under Windows NT 4.0, Win2k, or WinXP and on, the page file has a built-in size limit that you can set. You can indirectly force that minimum size to increase if you enable full memory dump capture in the event of a crash (it must be larger than main memory to do that) and that was really easy to do so I think a lot of people made that mistake. Even on the modern Windows, if you have a crash then the system will automatically enable full memory dumps for the next 4 weeks hoping to be able to debug the second crash. That can also result in the minimum size increasing beyond the maximum you set, but in neither case does it grow indefinitely.
Eventually the OS will start returning an error that it's out of memory or out of virtual memory. But if the application you're running can handle that gracefully, then it may not even crash.
I think Windows is sluggish now in part because it's about 5 or 6 layers of abstractions piled on top of each other between the application and the hardware, and also because Microsoft keeps jamming services and side projects onto you. It's been a long time since Microsoft has adopted the "shut up and get out of the user's way" approach to OS design. Now it loves to distract you from the program you're working in.
Linux OOM handling is just atrocious.
Chrome/Vivaldi are the only browsers where, when i have a long HN page open, when i resize it, my laptop freezes for like a minute. Not a full freeze, the mouse still moves, but like it's the year 1999 with a refresh rate of 4 seconds.
echo 2 | sudo tee /proc/sys/vm/overcommit_memory
https://www.kernel.org/doc/html/latest/mm/overcommit-account...
Of course I did this when RAM was cheap but one of the best decisions I have ever made in life.
IME, many default installations in recent years don't configure swap by default. Dedicate a few tens-of-gigabytes on your hard drive and memory overflows there instead of borking.
Most applications these days are very good about that; you likely have just a single app that you use regularly that leaks. If you kill the process the memory will be recovered, save for some allocations the kernel maintains.
https://kubernetes.io/docs/concepts/scheduling-eviction/pod-...
https://kubernetes.io/docs/concepts/configuration/manage-res...
https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#... (New feature)
So normally if you overcommit it might be undefined behavior if you not have enough memory. However if everything is fine pods can preempt based on prio to new nodes.
With the right settings only the faulty app might fail. Without it it can be a real pain to find the rouges
But yeah it’s completely ridiculous and frustrating that the default is to just lock up your DE
When your OOM killer isn't aggressive enough, not having swap makes you go fully unresponsive sooner. You still get into a situation where the OS keeps having to purge pages and read them again from disk. But without swap one hand is tied behind its back and it can only purge code pages, not data pages.
Maybe not in the same way then.
Anyways, you've unlocked an old memory of mine, where Windows would crap itself due to low RAM and the fonts and interface elements would render in a "compatible" way, like using "fixedsys" font everywhere.
But only in veeery old Windows, think Win95B or the like.
If you disable pagefile (like I did for some of my servers) and your program mallocs more than what you have in available space (even without ever dirtying a page) you will observe this.
I'm sure that this helps Windows a lot, even if it's not counted as actually used until the page is dirty.
Linux programs very often have virtual addresses many times the amount of physical ram, because there's never been any restriction. It's then very easy to just malloc huge chunks and use what you need and don't care about it too much.
Especially with many "tiny" allocations, python for example has huge sized objects which consume gobs of RAM dynamically, so any long running python process not only fragments memory but ends up having a bunch of objects consuming virtual memory...
idk why I felt the need to rant about this, but it's a difference that I've noted.
I prefer the Windows approach, it's more predictable and has better behavior under memory pressure. But it can cause issues with software written under the assumption that the OS uses memory overcommit
all these electron apps and invisible virtual machines (looking at you Claude) really don't help.
The communication is more direct too with GPT5.6 family of LLM. No more belt and suspenders.
What’s a decent amount? No idea. Don’t test it :)
The only way to save my file system was to boot into recovery mode and run a verification with Disk Utility, then I was able to remove some files and get my space back.
Both Windows and Linux allow applications to map memory in an uncommitted state. However, in Linux, uncommitted memory can magically become committed by simply trying to use it, whereas on Windows you have to first actually commit it with a separate API call.
You might wonder why you would even bother allocating uncommitted memory on Windows if you have to explicitly commit it later. Simple: just to reserve a contiguous slice of address space for later.
The consequence of this is that on Windows an allocation failure usually occurs at an API call where it can return a failure, and indeed does. On Linux though, an allocation can fail during a page fault that is entirely transparent to the application. So instead, the default behavior is to allow overcommit, where applications are allowed to commit more memory than the system actually has, under the assumption that in many cases it won't all be in use at once. Instead of an application hitting an error or crashing on a failed allocation, if there is no memory left, a process simply hangs.
Here's my take on why this is the way it is:
- Because programs are written without any knowledge of what memory pages are committed, applications will allocate physical memory pages transparently even if they didn't malloc or mmap anything. Because of that, when an allocation fails under memory pressure, it's pretty likely the first page to stall on overcommit isn't really related to the actual memory pressure.
- To try to mitigate this, during high memory pressure situations, mechanisms like the OOM killer have to score tasks based on several factors to try to guess which ones are causing the problem.
- When you have something like make -j running, it is pretty easy for it to choose Firefox instead of the 200 instances of Clang, since individually none of those Clang instances are really using much memory. This, of course, doesn't fix the bleeding, it just kills your browser. There are ways to mitigate this problem, but they are not often implemented and nothing will ever be perfect.
One may wonder if it is worth the trouble... Probably not, but it does have its advantages, particularly when it comes to databases and caches, which can aggressively reserve memory and mmap files and heavily lean on demand paging for memory management. It's just that in this case, managing memory pressure becomes somewhat heuristics-based, and tools like cgroups are often desired to isolate failure domains and control memory allocations in production systems.
This is a tough problem to solve. Many improvements to the Linux OOM situation have been made, from simply fixing problems that made the wedging even worse, to tweaking the OOM scoring, to usermode daemons like systemd-oomd that try to catch memory pressure earlier. However, so far this is a solidly unsolved problem - the same exact wedging is still possible today.
As hopeless as it seems, I am still open-minded here. The Linux desktop moves slow, but nonetheless it seems pretty good at overcoming challenging obstacles.
Before the recent increase in RAM prices, it was not difficult to have a generous amount of RAM in a PC, that would make very unlikely the out-of-memory situations.
When OOM really happened, it was much better to become aware of this immediately, and reduce the number of concurrent threads for a running job, or whatever caused that, instead of having reduced performance or even freezing.