This post makes sense except for the unrealistic notion that some kind of mystical unikernel is going to descend fluorescent pink-winged from the heavens and spear code cruft with its long sinuous Tusk of GreatCode +37.<p>The goal of less kernel bloat is a great one, however the realistic options in a modern environment are either (1) accept the performance and management overhead in running and maintaining a whole new kernel per application; or (2) use containers, thereby unifying the kernel across all containers and removing that overhead (but accepting some security risk).<p>The pink-winged unikernel is option (3) Everyone rewrites all their code to run on some exotic kernel, or accepts a very complex and long-winded automated recompilation of their existing kernel (eg. Linux) in line with automated application profiling and agrees to deploy on paravirt instead of containers and take the resulting performance hit.<p>I think (3) is unrealistic, though parts of it will eventually occur at appropriately latency-agnostic portions of mature continuous deployment processes, but do wish unikernels and their winged brethren the best of luck.