(I'm the guy in the video on the linked page, but this is just my opinion, nothing official) > Looking at the dismal state of sandboxing APIs in the major oper

(I'm the guy in the video on the linked page, but this is just my opinion, nothing official) > Looking at the dismal state of sandboxing APIs in the major operating systems, and the advent of KVM on Linux, WHP on Windows (including Windows Home!), and HVF on Mac, I wonder if the future of securely running applications might be to just throw every app in a VM Yes, absolutely. Its clear on the server side the tradeoffs here strongly favor (micro) VMs over kernel-level or language runtime-level multi-tenancy for any non-trivial applications. The paper goes into more detail on why that is, but the short version is that the tradeoffs seem easier if we put the shared API at the "hardware" level rather than on top of the kernel. These kernel/"hardware" interactions are vastly simpler than the userspace/kernel interactions, and also much less of a moving target. I'm not a client-side expert, although I have played with Qubes. The tradeoffs may be different there. > While Firecracker is faster, QEMU does actually have a microvm[0] machine which boots pretty dang quickly. Yeah, QEMU is great. QEMU's ambitions are broader than Firecracker's, and that leads to the teams making different tradeoffs over time. Intentionally staying minimal and simple is nice if you can get it, and in the context we use Firecracker at AWS we can. There's also a "rising tide lifts all boats" angle here. QEMU, or any of the rust-vmm hypervisors, succeeding is good for everybody in this space.