Let me try to offer a slightly more substantial comment than the others here so far.

This proposal is motivated by trying to get more applications running off the shelf or with minimal changes, which is a worthy goal. But to achieve that, it seems like the concept of a unikernel is growing more and more complexity. At some point, isn't it just Linux (or any other traditional kernel/OS) with a (slightly?) more modular design, statically linked applications, and no memory protection or scheduler (but it might even have that)?

Wasn't the point of a unikernel to be small and simple? Aren't we losing something by bringing the kitchen sink back (even if there's a compile time option to turn it off)?

And even once you have all that complexity, you still can't SSH in and diagnose problems, poke around, etc.

I like the idea of unikernels, but I feel like they still haven't found their calling.

There are two things.

1. A Unikernel: It is supposed to be small and simple. Only containing the components it needs. And the security model is custom for the application itself.

2. A frame work to build Unikernels. This might include multiple implementations of file systems, schedulers, network stack, etc.

The framework does need to be extensive (large) in order to give Unikernel developers the most ergonomics/reuse while developing. However, each Unikernel would be "small" as you describe. Hope that helps.

Thanks. Yes, I understand.

But if you started with (e.g.) Linux, and turned off all of the compile-time features that you could, isn't the end result very similar? Say you run your application as PID 1, etc., etc.

My point is that a fully "generalized" unikernel is actually almost the same as a standard monolithic kernel. The technical differences are 1. memory protection, 2. scheduler (maybe), 3. single binary? 4. different and less flexible tooling around runtime debugging/admin.

I mean, we all want a fully featured unikernel that boots instantly, consumes no memory, etc. But there's no reason to believe that a unikernel with all of the features necessary to run, say, a database, won't have overhead similar to Linux tuned for that same role.

(Not trying to worship Linux here, I'm just holding it up as an example that has had a lot of eyeballs over the years.)

If you strip Linux and run your app as PID 1, you will still have context switching between user space and kernel space, which can be fairly expensive (thus the interest in user land TCP/IP stacks). Presumably most unikernels avoid that cost.

You should clarify your terminology:

-- "context switch" (expensive) is the switch among active (running on this CPU) tasks/threads/processes.

-- switching between kernel and userspace would be "mode switch", much less expensive and of "constant" cost (see, for example, http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma...).

Your phrase already carries this contradiction: "__can__ be fairly expensive" points to something depending on what is being executed, rather than a property of the mode switch itself. Then, arguably, the same need of that costly execution should also be present with unikernels?

It is hard to understand the benefit of a unikernel versus a very stripped down Linux kernel.

If any people from the mentioned project are here, I'd love to hear your answer to this.

There's a lot of literature that point towards more application-specific optimization in the lowest levels of the operating system, for example the Exokernel papers are an early example of this. More recently, you may want to have a look at the the MirageOS paper(s).

Here's my bit of uninformed speculation: presumably a lot more potential for aggressive optimizations. It's unlikely that you can make Linux as bare-bones as you could a unikernel. Besides, for all intents and purposes, you can't run Linux through a whole-program optimizer along with your application (not sure if this is even a worthwhile objective). I would also think that communicating between the application and the "kernel" via function calls instead of system calls would yield some non-negligible performance gains as well.

There may be some, but even if there isn't, some benefit could be the ease in which you strip it down.

Technology is all like this.

A grant vision. A winding path. It's indispensable to address the migration problem. The idea that people would rewrite applications for someone's fancy new idea is not only stupid, it's actually never happened.

If we get real benefits from disabling ex. memory protection, could we just use a deliberately crippled kernel from Linux/BSD? (rump kernels come to mind)

Unikernels remind me a lot of old applications distributed on floppy disks. The OS/application division is mostly absent and there's potential for real innovation by moving OS-like behaviour into the application - e.g. integrating the garbage collector with the code for swapping.

In the days before hard drives were common in home computers (between the early 80s and early 90s), the OS/application division still existed. The OS was built into computers of this era (stored in ROM chips). You wouldn't necessarily interact with this OS directly when using an application, but the OS was still there.

To give an example, the Amiga operating system was split into two parts, the Kickstart ROMs and the Workbench GUI. Not all apps would use Workbench, but it's harder to find apps that would work without Kickstart. You'd see evidence of this when running games when the infamous Guru Meditation error came up.

Why gratuitous name collision? Unicore is an instruction set architecture. Linux kernel port is upstream. https://en.wikipedia.org/wiki/Unicore

You know, if HN was going to design a nuclear power plant, we'd all get into a dispute over what to name the bikeshed.

I'm not so sure about that. I think most people would probably support a name like "Powwy McPowerface."

Surely 'Nukey McNukeface' is the obvious choice.

True bikeshed enthusiasts would name it "Shedy McShedface"

Its the clear choice

Bikey McBikeface. And it would be painted blue.

The ISO standard governing bikesheds specifically prohibits blue.

I prefer to follow the IETF standards on bikesheds, which impose no such restriction.