It is said in a very confusing manner. The core idea is dependency inversion: instead of the admin dictating the capabilities of the kernel, dictating the capab

It is said in a very confusing manner. The core idea is dependency inversion: instead of the admin dictating the capabilities of the kernel, dictating the capabilities of the applications, we turn the whole thing around. The client application might use a library dependent on, say, a high-frequency clock. Therefor, during the build of the application, the specific capability is build into the kernel. Synchronisation and sanity checks of this high-frequency clock runs only when this specific image (or unikernel) is loaded. It's a pretty neat idea and fits well in the global trend of dependency inversion. It also highlights the gaping architectural hole in the current container (docker) offerings: by using a base-image, you specifically ask for everything that is necessary for: networking, IPC, process management, scheduling, file system management, package management, printing, the whole POSIX interface etc. etc. This in turn creates a huge attack surface from a security perspective and makes maintenance and quality control much harder. My sole question with unikernels is: doesn't this just move resource management (scheduling) upwards and security (access to resources) downwards? Or in other words, are we not creating two extra rings?