You gotta have balls or be receiving tons of money to publicly celebrate the sloppiest software company of the decade making your programming language Tier 1 internally.
Every time I see Anthropic ship an issue like this, I'm reminded of Boris Cherny's glorious quote: "At this point it's safe to say that coding is largely solved."
From my experience, Windows does freeze and become completely unusable too, just not usually from RAM usage hitting 100%.
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.
Windows does freeze and become unstable, but it's usually because of some ring 0 errors not getting trapped appropriately.
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.
Doesn't Windows, like macOS, automatically expand swap? You can't run out of memory nearly as quickly as you can on Linux. And at least on Windows I always figured this is why it felt so sluggish under load--it ends up paging alot. Not sure why macOS has always felt more consistent; perhaps the OS and major apps are less gratuitous memory hogs?
In Windows 9x (95/98/ME) the swap file could expand indefinitely, with no mechanism to limit its size.
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.
If you're referring to Apple Silicon, my intuition is that the SoC design allows for higher bandwidth between SSD and RAM which reduces the performance impact of paging. I might be totally wrong though
Note that the fork()/execve() semantics of Linux pretty much depend on memory overcommit. You may get weird OOM crashes when there is seemingly no memory pressure, if you turn overcommit off.
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.
Has anybody tried a compromise? Like, the program forks and overcommit is ignored for it for a 1 second grace period? I know it would be more complicated than that, but something along those general lines.
> I had a frozen linux server that ran out of RAM yesterday
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.
True. It's just a tiny Lenovo that I've repurposed as a homelab and that is punching above it's weight with to many applications I suppose. Either way the logs point to RAM issues but it could be my incompetence.
edit: I meant that regularly hitting OOM on a production server is usually more of a provisioning/resource-management issue. Obviously, how the OS handles OOM once it happens is still its responsibility.
Running out of memory on a linux server sounds more like a skill issue than something comparable to how a desktop OS should behave :\
Windows uses eager memory allocation, and applications will die when they allocate (and think image editor loads a beefy image) or fail to start when it runs out of memory.
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.
macOS includes a GUI user land whereas Linux is just a kernel.
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.
I mentioned they aren't the only UNIX where this isn't a problem.
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 mentioned they aren't the only UNIX where this isn't a problem.
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.
> Who says it needs to be desktop for proper memory management, servers and embedded can crash willy-nilly with OOM?
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.
Windows will aggressively page out as you approach RAM usage, MacOS does the same but based on activity iirc. On Linux if you just set up paging (forgot how i did this on arch) you won't have any issues.
