4 ms·

What advantages do unikernels have over microkernels?

by akavel 8y ago

eyberg 8y ago
The operating system universe is a lot bigger than most people have been led to believe. They think it's windows vs linux vs osx. If you're 'wild' you go *BSD. There's a lot more out there - unikernels in particular are similar in nature to RTOS (like the system that is on the Mars Rover) and they definitely descend from the microkernel branch of the tree. Having said that many microkernels tend to be multi-process. There are now over 10 different unikernel implementations out there currently. They all have different aims and goals but I'd say one defining characteristic amongst all of them is that they are single process by design. There's many other considerations but that's the most important one that comes to my mind.
- akavel 8y ago
  Ok, so IIUC, that could be especially useful if I were to go quasi-embedded way, meaning at least a "fully dedicated server" (for the one and only Process ...princess?), as a unikernel might then let me get closer to the metal with little to no effort on my side. Amirite? Thanks!
msla 8y ago
Unikernels are older than microkernels, in terms of design philosophy, and owe more to VM (the IBM project from the 1960s) than later OS design. Microkernels are about splitting a single OS into what are sometimes called 'servers', whereas unikernels are individual systems running on a hypervisor; ultimately, the biggest advantage is that, in a microkernel, if one 'server' goes down (the disk server, for example) the whole system is down, whereas a single unikernel can fail without impacting any other unikernel. https://jdebp.eu/FGA/microkernel-conceptual-problems.html https://jdebp.eu/FGA/microkernel-conceptual-problems.html https://utcc.utoronto.ca/~cks/space/blog/tech/HypervisorVsMicrokernel https://utcc.utoronto.ca/~cks/space/blog/tech/HypervisorVsMi...
- Fnoord 8y ago
  > the biggest advantage is that, in a microkernel, if one 'server' goes down (the disk server, for example) the whole system is down Rather, if the disk server goes down, the whole system might go down. It doesn't necessarily will go down. You could, for example, simply restart it. If your Graphics server goes down, you might still be able to SSH to the machine, and in the example of yours which I quote you could run a remote emergency SSH server in full RAM. Unikernel and microkernel are good examples of (fine-grained) principle of least privilege. Doing that right is difficult. Just ask the NSA or Intel.
  - msla 8y ago
    Realistically, if a disk server goes down, there are two possible reasons: 1. The disk hardware is bad. By all means, take everything down until you replace the disk so you don't get garbage in important files! 2. The disk driver software is bad. By all means, take everything down until you replace the software so you don't get garbage in important files! In neither case is simply bouncing the disk server an acceptable answer. Debugging and fixing the underlying problem is essential, and that requires taking the whole system down.
    - Fnoord 8y ago
      The question is rather: would a unikernel or monolithic kernel have behaved differently? Probably #1 (or a nefarious person being root), but you do have backups and redundant servers, right? I'd read SMART logs first. Back when my Death Star died some 20 years ago I remember it getting more difficult by the day to spin it up. But once it worked, it'd work fine.. until the machine tried to read from a bad sector (a good OS wouldn't have frozen on that but this was Windows 9x). Here are some alternative possibilities: 3. Physical compromise; e.g. a cable got yanked. 4. Disable write caching and continue despite the driver or hardware being bad. 5. There is no quick way to get physical access. 6. A disk server isn't necessary to keep the system up. Goes well with #4. If you look at how it all went, the massive redundancy of cheap commodity hardware won. Containers add further on that, and no doubt more bloat can be removed via a unikernel or microkernel (leading to smaller attack service but also more complexity). But that doesn't mean every aspect of such a machine needs to keep running, and it does imply a FOSS solution.

What advantages do unikernels have over microkernels?

by akavel 8y ago

What advantages do unikernels have over microkernels?

The operating system universe is a lot bigger than most people have been led to believe. They think it's windows vs linux vs osx. If you're 'wild' you go *BSD. There's a lot more out there - unikernels in particular are similar in nature to RTOS (like the system that is on the Mars Rover) and they definitely descend from the microkernel branch of the tree. Having said that many microkernels tend to be multi-process. There are now over 10 different unikernel implementations out there currently. They all have different aims and goals but I'd say one defining characteristic amongst all of them is that they are single process by design. There's many other considerations but that's the most important one that comes to my mind.

akavel 8y ago
Ok, so IIUC, that could be especially useful if I were to go quasi-embedded way, meaning at least a "fully dedicated server" (for the one and only Process ...princess?), as a unikernel might then let me get closer to the metal with little to no effort on my side. Amirite? Thanks!

msla 8y ago

Unikernels are older than microkernels, in terms of design philosophy, and owe more to VM (the IBM project from the 1960s) than later OS design. Microkernels are about splitting a single OS into what are sometimes called 'servers', whereas unikernels are individual systems running on a hypervisor; ultimately, the biggest advantage is that, in a microkernel, if one 'server' goes down (the disk server, for example) the whole system is down, whereas a single unikernel can fail without impacting any other unikernel. https://jdebp.eu/FGA/microkernel-conceptual-problems.html https://jdebp.eu/FGA/microkernel-conceptual-problems.html https://utcc.utoronto.ca/~cks/space/blog/tech/HypervisorVsMicrokernel https://utcc.utoronto.ca/~cks/space/blog/tech/HypervisorVsMi...

Fnoord 8y ago
> the biggest advantage is that, in a microkernel, if one 'server' goes down (the disk server, for example) the whole system is down Rather, if the disk server goes down, the whole system might go down. It doesn't necessarily will go down. You could, for example, simply restart it. If your Graphics server goes down, you might still be able to SSH to the machine, and in the example of yours which I quote you could run a remote emergency SSH server in full RAM. Unikernel and microkernel are good examples of (fine-grained) principle of least privilege. Doing that right is difficult. Just ask the NSA or Intel.
- msla 8y ago
  Realistically, if a disk server goes down, there are two possible reasons: 1. The disk hardware is bad. By all means, take everything down until you replace the disk so you don't get garbage in important files! 2. The disk driver software is bad. By all means, take everything down until you replace the software so you don't get garbage in important files! In neither case is simply bouncing the disk server an acceptable answer. Debugging and fixing the underlying problem is essential, and that requires taking the whole system down.
  - Fnoord 8y ago
    The question is rather: would a unikernel or monolithic kernel have behaved differently? Probably #1 (or a nefarious person being root), but you do have backups and redundant servers, right? I'd read SMART logs first. Back when my Death Star died some 20 years ago I remember it getting more difficult by the day to spin it up. But once it worked, it'd work fine.. until the machine tried to read from a bad sector (a good OS wouldn't have frozen on that but this was Windows 9x). Here are some alternative possibilities: 3. Physical compromise; e.g. a cable got yanked. 4. Disable write caching and continue despite the driver or hardware being bad. 5. There is no quick way to get physical access. 6. A disk server isn't necessary to keep the system up. Goes well with #4. If you look at how it all went, the massive redundancy of cheap commodity hardware won. Containers add further on that, and no doubt more bloat can be removed via a unikernel or microkernel (leading to smaller attack service but also more complexity). But that doesn't mean every aspect of such a machine needs to keep running, and it does imply a FOSS solution.