There is an OOM kill count in Linux

The Linux kernel OOM killer only acts if there's nothing left that can be discarded, which often happens way too late to save the system. You need a user-mode OOM-killer like earlyoom if you want to keep the system responsive.

Maybe there are reasons, but it is not nearly good enough -- I frequently run out of RAM and encounter OOM kills (prefer not to deal with linux swap), usually requiring a reboot. I really wish that I could just set an upper limit on (e.g.) firefox RAM usage -- 8GB for example -- instead of its insistence on using all of the unused RAM minus a couple to several hundred MB, which does not leave enough room for memory usage spikes. There might even be a way to set this buried somewhere in the config parameters, but I could never find it. It must be technically possible to set some limit because otherwise the browser would not be able to maintain a somewhat consistent usage just below the total system RAM.

We ran out of space, and then we realized we are a storage company.

If you turn swap off the allocator will error out when you are out of memory. I don't think most software handles that error but all the wiring is there to do that.

I believe something like that exists on mobile platforms for memory, at least on iOS you get a message (applicationDidReceiveMemoryWarning:) when the system is memory starved and wants your app to free memory. If you don't release enough memory and the memory pressure doesn't go down, the system will start killing apps.

malloc() can fail, everyone knows this in theory, but assume you're the programmer handling the malloc() error -- you know the system is likely to have already run out of free memory -- how do you make the program fail gracefully without doing anything at all to allocate memory?

It's not even safe to call printf() since it might have to allocate a new string. There are very few things in modern code that doesn't "incidentally" allocate a couple bytes here and there.

Not to mention languages higher level than C where you don't directly call malloc() but have the language handle it for you (GC etc.). Handling OOM for those programs is even more impossible because you really have no idea whatever class/method/function you're calling is going to trigger an allocation or not.

The best you can do in those cases is try to commit critical data (if any) to disk and have the program die ASAP. Which is not that different from having the kernel kill it for you.

The OS could really just say no. But that would commit memory to a process even though it might not actually end up using it, making it unavailable for processes that need it right now. Also, memory allocation latency is higher since the OS has to really do all the bookkeeping up front. Therefore, most Linux distributions by default optimistically grant allocation requests even though there might not be enough memory available yet.

The big disadvantage is that the OS might be unable to actually grant memory. The process then gets OOM killed. This is sort of fine on servers since users usually get assigned limits. But there is something left to be desired for single-user systems.

Processes can at any time return memory to the OS when they don't need it. Usually they do that, but this has the disadvantage that they have to ask the OS again for it, which is quite slow compared to keeping it around.

Few applications are actually able to just release memory on request. It's critical user and internal application data after all. Databases and applications with garbage collectors come closest.

There are already interfaces which can do some of what you are talking about: the most common is memory mapping backed by a file, swap, or filesystem caching. This is the most common form of 'optional' memory usage, and it's generally managed by the kernel. A lot of the kind of thing you are talking about can be mapped onto this abstraction. For cases where backing by a file doesn't make sense (e.g. it's cheaper to regenerate the cached data than to read it back from disk), if you are using a mmap-like interface, you can generally mark pages as 'don't need', which means they may be freed by the kernel if there is memory pressure, but won't be wiped immediately. Again the main issue is the use-cases where this represents a significant percentage of memory usage are pretty slim.

Windows Logon is superior to all the shells as a core Windows subsystem in that it is the one that executes the shell (usually Explorer) on boot/login and can also execute Task Manager, in addition to its primary duties of tracking and securing user logins (hence the name).

This means even if Explorer has completely froze or has crashed, you can always get to Task Manager via Windows Logon and then kill or execute another instance of Explorer (or CMD or Powershell!) or otherwise force reboot the system from Windows Logon.