Yep. Except every application runs in a down-and-dirty virtual machine instead of a nice clean process, so they get to experience the joy that is hardware booting and get to configure virtual device buffers instead of calling send(). Progress.
replyThis isn't too dissimilar to DOS programs. DOS also gave you a filesystem, memory management, a shell a process loder, driver interface, but it was all in real mode, and you were free to replace these components with your own as you pleased.
replyOr if you're more familiar with embedded, like a BSP or RTOS
Arbitrating access to the hardware between multiple tenants still gonna be a PITA (as it was during the DOS days), especially if you want to expose actual hardware, not some generic VirtIO devices. Even with the latter, the hypervisor would have to do quite a bit of the resource management and interface translation.
replyUnless you're literally running a single application on a dedicated piece of hardware in which case... yeah, sure, you can do the OS-as-a-library schtick. But you could do it 10 years ago, too.
I mean, sure we can put labels wherever we want. I don't really care. MirageOS even has "OS" in its name.
replyThe point is all the other things: total number of lines of code, permissions and security, memory management, drivers, process mgmt, it all changes.
Does it though? And I'd really like to see how you'll revirtualize e.g. an NVIDIA GPU (notoriously context-full piece of hardware), while allowing transparent shared access to it from different applications. Heck, you'll run into trouble with most of PCI-connected devices except for the most primitive once.
replyyea, "virtualizing" an NVIDIA GPU is not truly feasible right now from what I see.
replyI do know that AMD has done more in this space. When I worked at Google there were (other) people on the Stadia team doing this. And some open source bits out there that I've seen, including from AMD.
Unfortunately, my real world work... and most real inference etc work others are doing... is on CUDA/NVIDIA.