Your idea of the motivation behind unikernels is wildly different from the one stated in the original paper [1] that introduced the concept. The original motiva

Your idea of the motivation behind unikernels is wildly different from the one stated in the original paper [1] that introduced the concept. The original motivation wasn't a Unix bad, unikernels good thing. That's a different topic. Rather, it was a reaction to cloud computing. The authors behind the paper observed that people were deploying single purpose VMs on top of hypervisors. Those VMs included full-blown general purpose OSes. Many of the features provided by those OSes were unnecessary for this use case. That bloat not only lead to large image sizes, but also worse security caused by increased attack surface. As a solution, the authors proposed a new class of OS which they named unikernels. Simply put, they're library OSes targeting hypervisors. By using a library OS, the compiler would ensure that only features that are necessary would be included in the application image. And by targeting the hypervisor, the OS would be able to rely on high level primitives provided by hypervisors such as multitasking, isolation, and device handling. So taking this into account, let's go through your claims: > Later on certain people started to see that these high-level concepts are bad. ... So unikernels are invented. This isn't what unikernels are about. Nothing about the concept precludes implementing high level primitives in the OS. They just drop features that aren't required for the application on an individual basis. It's not about throwing every Unix features out of the window. > Unikernels aren't capable of just writing something to a simple file. No, they must write to a raw block device. That's not a description of unikernels. That's a description of the hypervisor's interface with guest OSes. Traditional OSes would have to deal with block devices too. Nothing about unikernels prevents them from implementing file system drivers like a traditional Unix system would. > Unikernels are also not capable of simply streaming data to another application. No, they must include their own Ethernet/IP/TCP stack, and on the host system you must set up a network bridge (hopefully with a firewall) just to let a couple of unikernels talk to each other. So let's solve that using AF_VSOCK! Again, you're describing hypervisors. Unikernels can implement communication mechanisms as they see fit. Unix OSes very much need to implement their own IPC and networking stack too, if they want their applications to be able to communicate. The difference is that unikernels only have to deal with virtual devices, a much narrower target than general purpose OSes. That can lead to efficiency and security benefits. > I have the feeling that we're coming full circle at this point. We didn't. [1]: http://unikernel.org/files/2013-asplos-mirage.pdf http://unikernel.org/files/2013-asplos-mirage.pdf