Actually it is irrelevant whether you use an operating system or not.

One project I worked with these rules was on Verix OS.

The rules are more intended on reducing application complexity and unpredictability which is typically helping reliability regardless of the setting.

It was mostly on if the OS would actually allocate physical memory, or if it'd do a linux style overcommit. Without an OS, the latter is very unlikely.

Again, Linux DOES NOT overcommit memory.

Linux does not lie about what available memory is. Rather, it is most developers that do not understand how memory is managed on Linux.

What you probably mean is that you don't get physical memory when you run malloc().

That's because when you allocate memory on Linux you allocate virtual address space rather than physical memory.

Basically, you get a bunch of addresses that may or may not be backed up by physical pages.

If you want physical memory you just need to use mlock() along with malloc() and you are all fine.

You're redefining overcommit from how everyone else uses it.

https://www.kernel.org/doc/Documentation/vm/overcommit-accou...

If you want to "allocate" (reserve) physical memory just call malloc and then mlock. No lie. You get physical pages or error.

Get over it. What you call "allocation" is two distinct operations on Linux, one of which is called malloc in standard c library, unfortunately, and that's where your confusion comes from.

Overcommitting means providing more virtual memory to be mapped than is available in physical memory. It works by mapping memory as readonly, mapped to a zero page, and "committing" a real physical page when a write occurs to a page for the first time. The act of asking for virtual memory and mapping it is considered allocation. Linux overcommits virtual memory. Some OS, like Windows, actually commit physical pages to back virtual memory when you ask try to map new virtual memory.

I think you know these things and it's mostly just a semantics argument, but this is the widely agreed definition.