
A Rust-Based Unikernel: First Version of a Rust-Based LibOS - ingve
https://hermitcore.org/2018/06/06/A-Rust-based-Unikernel/
======
andrewstuart
I put alot of time and effort into unikernels and the technology is very
appealing to me.

It has been something of a puzzle as to why they have gotten no traction in
any significant way.

My conclusion is that there are other technologies (i.e. containers/Docker)
that are not as good as Unikernels, but are good enough to solve the core
industry demand for lightweight nested virtualization. And indeed containers
solve that problem better than unikernels in two important ways which is boot
time (and I'm talking here about booting useful unikernel based applications
as opposed to theoretical unikernel OS boot times which can be milliseconds),
and also containers are better because they don't need nested hardware
virtualization switched on in the CPU - that's important obviously for cloud
computing where nested virtualization has now arrived but is not widespread.

And good enough is all that is needed.

It's hard for me to imagine a time when unikernels gain more acceptance than
they already have, which is basically little more than none, and the staunch
backing of operating systems researchers and a few true believers who really
hang on to the theoretical benefits.

~~~
cdoxsey
Unikernels can be difficult to debug. All the tools that come with your
operating system are missing.

A big chunk of managing distributed systems at scale is trying to figure out
what's wrong with them when they don't behave. Most operators will gladly
trade some performance overhead for access to a suite of tools they're
accustomed too.

~~~
wmf
Yeah, production-quality unikernels would need to have built-in observability,
tracing, and debugging support (probably in the libOS) but AFAIK no one has
started building such tooling. I suspect that production-quality unikernels
would end up re-introducing a lot of the "bloat" that unikernels were supposed
to eliminate.

~~~
himom
Yup. GNU/Linux has just been reinvented. Another flavor of OS to support
equals $$$$.

~~~
jacobush
_IBM OS 360_ has just been reinvented. It's turtles all the way down to the
1960s. This is just like nature. We are witnessing something like the
evolution of one celled organisms. Also, multicelled organisms have started to
appear. That would be cloud services (mats of algae and bacteria) and machine
learning (true multicelled organisms).

------
kjeetgill
Anyone use Unikernels in real life? They always sounded interesting but
without a lot of examples of real usage they feel ... academic and
theoretical?

~~~
noselasd
Most embedded systems are really unikernels - so yes, certainly they are very
widely used. Though the more recent developments of running traditional server
software on unikernels have not gained that much traction.

~~~
zaarn
I doubt you should call embedded systems unikernels.

Stuff like the ATmega chips run the application barematal, yes, but they are
cheap microcontrollers with 2KiB of RAM and no MMU. You can't run a kernel on
that so your application runs bare.

A lot of the higher-tiered embedded stuff usually either runs a Linux kernel
or DOS (and older) from my experience.

~~~
pjmlp
There are plenty of OS for embedded systems deployment.

Systems running Linux are the exception.

Linux does not fulfill the security requirements of high integrity systems nor
the real time constraints.

~~~
magduf
This is completely wrong.

Embedded systems running Linux are extremely common, and becoming more and
more popular because it runs on so many architectures (esp. ARM, but also
PPC). For many applications, hard real-time is not necessary, and Linux is FAR
easier to develop on.

They are not "the exception" by any means. Look at almost any automotive
"infotainment" system on current models: it's likely running on Linux. There's
countless others.

For high-integrity systems for critical safety applications, you would not use
Linux, you'd use a dedicated RTOS, of which there are countless choices. But
these all have big disadvantages: poor performance (they favor determinism
over performance), poor development support, high license costs, etc. If
you're doing avionics, then sure you'd use an RTOS, but if you're making a
"smart TV" to play Netflix, you wouldn't, you'd use Linux.

Also, Linux does have real-time capabilities, it just isn't hard real-time,
only soft. It works well enough for controlling hobbyist-level CNC machines.
I've used it myself for a pretty critical real-time system where ease of
development and performance were more important than absolute real-time
guarantees.

~~~
pjmlp
Some numbers would be nice then.

~~~
magduf
Most companies, and probably almost zero government projects, publicize what
embedded OSes they use. You're not going to get any numbers.

This means you also have no numbers to back up your claim.

~~~
pjmlp
Since you insist.

[https://m.eet.com/media/1246048/2017-embedded-market-
study.p...](https://m.eet.com/media/1246048/2017-embedded-market-study.pdf)

Apparently I was wrong, see it wasn't that hard to find.

------
justicezyx
Unikernel can be interesting as a thought channel for CPU/hardware vendors to
offer a meaningful alternative to public Cloud vendors, and avoid being
commoditized.

Roughly, K8s and many other container solution tries to commoditize hardware.
And they require an evolutionary, and modest, changes to application
development lifecycle. They emphasize horizontal scaling.

Unikernel requires app developers to substantially change how their
applications are written. It emphasize vertical scaling. It's imaginable that
hardware vendors can build a cluster-like-machine, where lots of
cpu/gpu/ram/spindle/ssd/accelerators, and offer a Unikernel scheduler; which
greatly reduces the influence of the higher-level container-based solutions.

I am interested in learning how others think about this view point.

~~~
codeflo
I'm also trying to understand the use for Unikernels, because I find them very
interesting from a technology perspective. To me, Unikernels might make sense
when running a high-performance application on bare metal. There's probably
quite a bit of performance to be gained by running your application in ring 0
directly on a physical machine.

But once you add a hypervisor and a scheduler, you've essentially reinvented
the OS. I struggle to see the point: just compile static executables and run
them on Linux, natively installed on physical hardware, like we did 30 years
ago. Deployment is just as easy (i.e. copy a file), performance should be
comparable (calling into the kernel should be comparable to calling into the
hypervisor), and the tooling is way more mature.

~~~
justicezyx
> But once you add a hypervisor and a scheduler

What I imagine is a giant machine with thousands of cores, running a unikernel
scheduler, for horizontal-scaling apps.

That means hardware vendors can sell their produce directly to application
developers, instead of being shoved behind scene by Cloud vendors.

That might means reinventing OS, which can be argued for K8s as well, which is
also reinventing similar OS concepts (process management == job management,
threading == sharding, ipc == SOA, kernel scheduling == container scheduling).

But the point is that it offers a produce that has technical superiority, and
hardware vendors would have more expertise to build them, i.e., unikernel
would have much more intimate relationship with baremetal than containers,
where hardware vendors would naturally know better to optimize.

------
shmerl
_> It promises a secure memory handling enabled by its principle of zero-cost
abstraction._

I thought memory safety comes from enforcing proper memory usage through
ownership rules (borrow checker), not through zero cost abstraction, which
simply indicates that high level language features are translated into
efficient system level code.

~~~
tybit
You are correct, the sentence implies that it is the zero cost abstractions
that makes it possible which is not right. The zero cost abstractions part is
a nice benefit, but unrelated to ensuring safety.

------
75dvtwin
No doubt a significant accomplishment, and should generate some creative
production uses.

For 'larger masses' of 'application-in-a-box', I think, however, a
NetBSD(like) with .NET CLR (or even .NET core) would be a much route.

this was discussed on HN in 2016
[https://news.ycombinator.com/item?id=11636926](https://news.ycombinator.com/item?id=11636926)

------
ingenieroariel
Does hermitcore work on non x86 systems (aarch64 or riscv)?

------
himom
Unikernels are fail and here’s why: they lack the whole panoply of production
monitoring, security, debugging, troubleshooting, auditing and arbitrary
general purpose infrastructure capabilities of JeOS boxes. From an ops-
usability perspective, chopping down an OS is better than writing one from
scratch.

