
Unicore: A new Unikernel project - ingve
https://lists.xen.org/archives/html/xen-devel/2017-09/msg00670.html
======
btrask
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.

~~~
yazaddaruvala
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.

~~~
btrask
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.)

~~~
pentelian
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.

~~~
lkurusa
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).

------
richdougherty
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.

~~~
ZenoArrow
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.

------
sanxiyn
Why gratuitous name collision? Unicore is an instruction set architecture.
Linux kernel port is upstream.
[https://en.wikipedia.org/wiki/Unicore](https://en.wikipedia.org/wiki/Unicore)

~~~
btrask
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.

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

~~~
Norther
Surely 'Nukey McNukeface' is the obvious choice.

~~~
cgb223
True bikeshed enthusiasts would name it "Shedy McShedface"

Its the clear choice

~~~
cperciva
Bikey McBikeface. And it would be painted blue.

~~~
Aloha
The ISO standard governing bikesheds specifically prohibits blue.

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

------
cies
Why not RedoxOS (promising project in Rust)? Besides that RedoxOS is not
strictly a unikernel (be may well be used as one), I see a lot of the same
focus points in those two projects.

And can I assume the kernel will be written in C?

