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.

Ideally, no. If you have to compete against other businesses, you need to set your prices to match the competition. When you compete against other technologies, you can set the price according to what the market can bear. Consider Apple, they have their own technology, which competes against for example Microsoft and Linux related technologies. Now they can set their price according to what those who want their technology are willing pay, and rake in big profits. While in (for example) Windows PC/laptop or Android phone business, companies are competing against each others, and many are struggling to make any profit.

Obvious solution to poor documentation: don't read it!
.
There's a lot of decent, good and even excellent documentation to read too, after all. Why would anybody read the bad documentation instead?

You are drawing a false equivalency between "learn vi" and "get started with vi". Using vi before one has learned it well is... painful. Really painful. Knowing what you want to do, but not knowing how to do it in vi effectively. While at this stage of learning, not knowing many vi commands, one tries to do the editing tasks using same methods as with a more conventional text editor. And that is painful, being force to think about the editor instead of thinking about the content.

To use vi effectively, one needs to learn an entirely new way of thinking about editing text, and that takes time before it stops being distracting. Not to mention, one needs to learn far more than 60 commands, options, settings and so on. Just pick a random vi cheat sheet / reference card, and count the items. Learning and *remembering* one per minute is kinda... optimistic.

Then if you don't know regular expressions beforehand, you can double the time it takes for one to learn to use vi well enough for it to be practical.

Informal and exact are mutually exclusive, pretty much by definition.