3 ms·

Not only a hypervisor-generic, just generic. Whoever said that unikernels required the cloud wasn't thinking too much </friendlyjab>. I share avsm's excitemen

by anttiok 11y ago

Not only a hypervisor-generic, just generic. Whoever said that unikernels required the cloud wasn't thinking too much </friendlyjab>. I share avsm's excitement, and think we're on the verge of a transition away from the world where the OS is some arbitrary black box that you must have for anything to work. In the future world the components included in software stacks are determined per application need instead of the OS author('s ego). That transition is partly motivated by the cloud, but also partly by more and more smaller and smaller special-purpose devices.

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 ago
  Let'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?

by anttiok 11y ago

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 ago
Let'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?