> Next you’re going to say that shipping VMs to users is the only way to deploy apps, lest people use different (or, gasp, out of date) OSes that might have bug

> Next you’re going to say that shipping VMs to users is the only way to deploy apps, lest people use different (or, gasp, out of date) OSes that might have bugs. This, but unironically. Why not ship an app as a VM? Firecracker is super fast. The only thing really stopping is is that we don't have VM friendly APIs that let VM guests act like desktop apps. (Well, nested virtualization should be more supported.) Also, we're already in a world in which we ship apps as basically containers. Is that all that different? What should be the interface between an app and its host OS (and other apps)? At one extreme, we have "thick", "batteries included" interfaces like old win32, with tons of convenience APIs and OS-provided in-process code, and at the other extreme, we have VM-style "thin" interfaces with only the most essential OS services provided and apps (well, VM guests) expected to bring their own batteries --- things like a virtio framebuffer. Whether an app interfere is implemented as a VM hypercall virtio thing, IPC, or in-process client library is an implementation detail. What matters is the thickness of the API surface. We're in the middle of a secular trend from thick interface surfaces to thin ones. I don't see that as a bad thing. Thin, arms-length interfaces maximally decouple app and OS development. They encourage cooperation over explicit, stable, and versioned interfaces. They simplify the entire industry. The technological environment that generated the old thick interfaces doesn't exist anymore. Freed of its constraints, we can do better now.