I like how the OOM killer stays up to date with its list of the worst possible processes to kill first. Back in the day, it used to prioritize X, bash, and ssh. Now it extends that to include newer pieces of essential infrastructure like "kubelet".

It's careful attention to detail like this that keeps Linux relevant for the next generation!

(I'm kidding, of course. I was recently trying to reproduce some Node test flakiness that only happened on CI, which has limited resources and exposes timing sensitivity. I had trouble getting this to happen on my 32 core workstation, so I decided to run 100 copies of the tests in parallel which definitely reproduced the issue -- and ran the machine out of memory. The OOM killer kicked in, and chose to kill all the extra Node processes without killing my SSH session, which was nice of it.)

> handle low memory situations really badly

Yeah, I wonder why this happens. I've seen LKML emails trying to address this problem, they even cited Firefox as an example:

https://lkml.org/lkml/2019/8/4/15

This also seems to be the norm in user space software. I've read a lot of source code where people simply assume malloc never fails. Tried to discuss this on freenode once, apparently nobody knows what to do in case the system is out of memory. Why can't it gracefully degrade?

Arguably they could degrade more gracefully by just starting slightly sooner when they have some resources to manage but they successfully ignored the problem until it became someone else's problem. At this point I don't know that any solution would be much better than simply running a daemon like earlyoom in practice. I'm just surprised that desktop distros ship with Firefox which absolutely can in edge cases leak gigabytes of memory but no good way to deal with misbehaving applications after memory is exhausted.

> Distributions ought to ship with it.

You mean install it by default? Even good old Debian stable ships with earlyoom (which I'm ofc using, since I saw it mentioned here once on HN).

Yes I mean install and enable by default. Look at the experience TulliusCicero had. People are extremely going to reasonably assume Linux freezes all the time not Firefox ate all my memory and Linux doesn't have a good story for handling oom.

I think a much more common problem than OOM is X itself. It ties programs tightly together, making it trivial for one badly behaving process to take down all processes with a GUI.

It seems intuitively true that you would always have SOMETHING acting as a go between video driver and all clients and if this crashed your graphical interface goes down unless you have something that acts as an interface that can in turn restart the component. A buggy client already shouldn't actually take down your X server but a bug in X obviously can.

It sounds odd to me to describe applications relying on a toolkit like QT/GTK which can run in dozens of different environments which in turn run on both X11 and Wayland which in turn can talk to a variety of different GPU drivers as tightly coupled.