3 ms·
I think the reason why unikernels are typically associated with virtualization is that nobody these days would want to dedicate a whole computer to a single tas
by mwcampbell 11y ago
I think the reason why unikernels are typically associated with virtualization is that nobody these days would want to dedicate a whole computer to a single task. Even the cheap ARM SBCs (Raspberry Pi, Cubieboard, etc.) are capacious enough for a full multitasking OS or hypervisor, and the Mirage stack is probably too big to run on microcontrollers. In what situation would it be useful to run a unikernel on bare metal, without a hypervisor or multitasking OS underneath it?
- anttiok 11y agoLet's assume that a consumer device vendor does not want to pay more for hardware than what is required by their application. It's an assumption, but I think it's a fairly reasonable one to start from. So the game boils down to "required by". For any non-trivial application (larger than x kB microcontroller) running on non-trivial hardware and using non-trivial software constructs you need non-trivial drivers. Those non-trivial drivers have to come from somewhere. That is the reason why OS's are scaled down (i.e. hacked to pieces) to fit the embedded market. When you start looking at constructing the software stack from the perspective of the requirements of the application, not those of the OS, you can leave a huge amount of gunk out since you know precisely what you will need. Why wouldn't you build your software stack to consume only the necessary amount of resources?