[nine_k]

Virtualization, no. A hypervisor running a Windows kernel and a Linux kernel side by side is not about capability-based security. You can even see it like cap-based security approach: VMs only see what the hypervisor gave them, and have no way to refer to anything that the hypervisor did not pass to them.

Containers, yes. They are a pure namespacing trick, and can be replaces by cap-based security completely.

[kazen44]

Also, VM's make multitenancy really easy.

It allows you to divide up physical computing power across multiple people/organizations etc.

Containers make this kind of distinction far more hazy.

[marcosdumay]

Emulation and API compatibility layers can be done in more ways than an hypervisor-based VM. And many of those other ways perform better.

[nine_k]

What are they? Why the hypervisor approach is the standard then?

[marcosdumay]

You can already make Linux run any binary you want for the same CPU architecture, for example, wine uses this functionality. You can make it run natively binaries from other architectures with a rewriting VM like qemu (although I'm not sure qemu itself can port binaries between architectures, just that it's rewriting VM). Your VM can enforce security with a sandbox instead of a hypervisor, like the Java, C#, node ones do.

Hypervisor is not the standard, it's one of the many ways people do it right now.