You mean, the same way as asteroids of various sizes have impacted into the Earth throughout the history of the planet, and "Damage" is only relevant to those affected by it?

Yes, I agree.

Nothing prevents writing runtime libraries on safer languages than C, even C++11 would be a lot better (unless abused, but that applies to C too). And assembler is used very little these days, because there are many relevant CPUs in the market (ARM variants, x86, x64).

Even if a compiler for a "fancy" safe language were written with a "crude" unsafe language, it would still be just one program to verify for ptr++ kind of bugs. Additionally, a compiler is a classical input -> output kind of non-interactive program, which yields itself very well for running under verification tools like valgrind, which increases confidence that at least for any given input, it will not do nasty things.

Mmm, not sure what point or joke you are trying to make, but it is ruined by numerical inaccuracy: generally one object (whether you mean C++ class or a compiler output object file) contains many exported functions.

Mmm, yeah, a barebone OS would not have almost anything except the kernel. But Linux and BSD kernels offer a complex API: all the system calls. Not barebone at all.

Or

I don't know, it could be made to be one-time trigger, which starts the shutdown. If there's no way to get altered input through, that will not allow hacking. It should be simple enough to,be made bug-free.

Note that discussion is about users noticing performance gain with OS running on bare metal in the year 2020. At that time, with harware of that time, they'll need a benchmarking software to notice the difference between native and VM host, even for stuff like games.

In fact, at that time, I think state-of-the-art games etc PC software will be delivered as VM images, because the OS part of those images is going to be so small part of total size of the game that it is inconsequential, and developing against a fixed virtual OS is going to save tons of time, especially on the compatibility testing.

Well, for the totally barebone version, you could run it in a VM and examine its memory contents there.

I think even barebone OS would need *some* functionality. It would have to be able to shut itself down, on PC probably by ACPI events. It would probably need to be able to start the first process/program, because I think an OS has to be able to do that, even if that process then wouldn't be able able to do anything due to lack of APIs. Etc. So even barebone, it still needs to do something.

More practical than examining a VM, much like physical skeletons on display, most likely there would be some extra support to be able to see what is going on. Equivalent of wires and rods for a real skeleton would be some kind of debug features for the barebone OS: display messages on screen or over RS232, possibly accept some commands like reboot or dump information, even provide machine language debugger/disassembler.

Point would be to have a stripped to the bone OS.

Actually it's kind of same as having a stripped to the bone animal (ie. skeleton): you can for example study it, put it on display, give it to the kids to play with... ;)

First, assumption is that we're talking about the kind of virtual machines people run in VirtualBox etc, using the native CPUs etc. IOW, not talking about emulators like QEMU.

VM host RAM overhead is essentially static, while VM guest memory sizes go up along with all memory sizes, so actually RAM overhead asymptotically approaches 0%.

30% CPU, just how do you get that number? Virtual memory page switches etc may have some overhead in VM maybe, I don't know, but normal application code runs at the raw CPU just like code on the host OS.

And there's normally no emulation of hardware, there's just virtualization of hardware in the normal use cases. Hardware can also be directly connected to the VM at the lowest possible level, bypassing most of the host OS driver layers (non-performance-related, this is very convenient with mice and keyboards in multi-monitor setups, where each monitor can have a VM in full screen with dedicated kb&mouse in front of it, no more looking at one VM while focus is in another).

Except there will be no performance boost. There may be a blip in some benchmark.

Additionally, programmers are already running *application code* on bare metal when that kind of performance matters, most commonly on GPUs.

No, stripped to the bone, operating system offers no APIs at all, and it will not run any user applications. It will just tend to itself. Then you add some possibilities for user applications to do things, the less the better, from security and stability point of view. Every public API is a potential vulnerability, a potential window to exploit some bug.

Well, they're not really arbitrary. There are at least three points you can argue about:

1. Argue to change the definition (actual written words), which determines which is which and what isn't either.

2. Argue about interpretation of the defintion. Though, if this succeeds, then it makes the definition ambiguous, and the classification of border cases does become arbitrary.

3. Argue about the chosen terms "planet" and "dwarf planet". For example I'm personally not too happy having "dwarf planets" which are not a subclass of "planets", it's a bit unintuitive to me.

"Cleared its orbit" means, the planet controls everything which shares or crosses orbit with it. This may mean the usual moons, but also oribtal resonance (such as the Pluto-Neptune resonance) and minor bodies oribiting the Lagrange points of the planet (Trojans at L4/L5) instead of the planet itself like the usual moons.