4 ms·
I like the idea of the small attack service and minimal image size. However, having a different kernel image for each service seems likely to trigger some extr
by hodgesrm 11y ago
I like the idea of the small attack service and minimal image size. However, having a different kernel image for each service seems likely to trigger some extremely hard-to-diagnose bugs, which have to include performance problems.
As least with conventional OS you have a chance to get in and figure out what's going on. With Unikernels it sounds as if you may end up with either a core dump (how?) or a misbehaving service you can't access to diagnose problems.
- talex5 11y agoMirage can be configured to write trace data to a ring buffer shared with another VM, where you can run a visualisation tool to explore it. For an example, see: https://mirage.io/wiki/profiling https://mirage.io/wiki/profiling Of course, having such a small (and legacy-free) OS makes debugging vastly easier in the first place.
- hodgesrm 11y agoYou are right about simplification and I considered that point. Yet the fact that each application is developed on a general purpose platform, then compiled down to a unique production OS image seems to open up a lot of new corner cases involving long tail bugs. We had a similar phase in during the Java transition to JIT in the late 1990s, though that's obviously an antithetical technology approach. Either way you get a lot of ugly crashes. The key for industrial use is extremely robust dev and management tools. Unikernels are thought-provoking but on their own do not appear to be anywhere near enough to solve the problem they are taking on.