RustyHermit – A Rust-based, lightweight unikernel | Hacker News Reader

RustyHermit – A Rust-based, lightweight unikernel

github.com

153 pointsbrodo48 comments

It'd be really interesting to see some performance numbers.

iirc, this was roughly predicted by Jonathan Blow who complained that in the 80s developers would routinely bundle an OS with the app and it would run bare-metal

This would mean you could take any application made for, eg., x86, and run it on any x86 cpu -- rather than being "windows-specific" etc.

Why would you need an OS when you're running on bare metal? Isn't the whole idea of an Operating System managing shared and limited resources?

It's also about hardware abstraction. You don't want to rewrite your network stack for each platform but the unikernel can handle that.

It doesn't have to be unikernel either, Linux without anything else, your code being PID 1 is also good: no cruft and extra services that can be security holes, but great platform support, optimized network stack etc.

Of course if you just run on one hardware why not, just write the drivers you need.

How would something like this support logging, telemetry, debugging, etc as part of enterprise-grade software clusters if it has “no other services”?

It manages the services itself. Your app is one level down the totem pole. The http bit is just another service managed by your app.

Yeah an OS seems redundant here if you can just write freestanding bins.

With the advent of any-arch binaries, and fast emulation (qemu wasm), it probably won't matter if it is x86 or not.

Why advent? That was already standard on OpenSTEP.

Can you explain? I vaguely recall using it on sparc workstations a couple decades ago, but I wasn't coding for that target. A quick wiki read says it was an API framework that was "endian free" and that it trageted the three architectures that next ran on. Was it doing emulation for software using it? Or was it, itself a single binary? Or both?

You had all binaries on the same executable.

https://en.m.wikipedia.org/wiki/Mach-O

And NeXTStep OpenSTEP's predecessor had already implemented it.

Might have been, I mentioned OpenSTEP, because NeXTSTEP didn't need to be cross platform, that requirement only came to be with the former.

NeXTStep was cross architecture I ran and compiled Objective-C code on HPPA, i386 and 68000 machines. I suspect I built for SPARC as well

I stand corrected.

Isn't this, in a very roundabout way, an echo of docker? Or at least the abstraction Docker relies on?

Yes, containers and unikernels are possible answers to the same issue. If you consider an application running on a virtualised OS you have three layers: hypervisor, os, application with some duplication of functionality between the hypervisor and the os.

From there, if you want to simplify you can either add hypervisor-like isolation functionalities to the OS (containers) or move the little that’s actually needed from the OS into the application (unikernels).

That’s why Docker bought MirageOS a few years ago.

I definitely see this as an alternative route from docker containers / WASM.

Multitasking can go to hell I guess.

Generally speaking multi-tasking includes both multi-processing and multi-threading. Many unikernel projects support multi-threading so languages like Go/Rust can work very very well when deployed as unikernels. As for scripting languages like javascript, python, ruby they are inherently single-process regardless so you have to horizontally scale those. (eg: instead of having N servers having nginx front-end X app servers you just right size your workloads and spin up as many app servers you need behind a load balancer)

There's only one project I'm aware of that does multi-processing: https://cybersecurity.springeropen.com/articles/10.1186/s424... .

Why? You can easily implement a scheduler. And there's multiple cores. And potentially multiple instances on the hypervisor.

"Easily" is doing a lot of work there.

Yeah I re-read it later and was like.. ok, fine, I should put "easily" in quotes ;-)

Still, it's entirely feasible.

I mean, if you have one task to do only, multi-tasking is kind of pointless yes

It is nice to be able to listen to a podcast in the background while playing a game, and have the sound come out the same speakers/headphones. It's much harder to do that if the game runs bare metal.

Each of those services can be a unikernel being managed by a type 1 hypervisor.

Absolutely. But I think I'm correct in saying if today I wanted to play a game shipped as a unikernel, it would be pretty difficult to have the game and spotify running. First we need a spotify unikernel, then we need people to accept having to use the new unikernel version of spotify just when they play the game(s), maybe get used to the spotify unikernel not having access to graphics hardware, etc. Or we run spotify in a traditional OS in the hypervisor and lose all the benefits we were shooting for in the first place.

Technically all manageable, but that wasn't the aspect I was focusing on, rather the reality that we couldn't just do this today, or even really all that soon.

Alternatively, PCs become games consoles when running games, and you just can't do multitasking, just like you mostly can't on a PS2, etc. Honestly, I think this would be the most likely outcome if games went down this road.

In a way it is a return to the days of playing games in 8 and 16 bit platforms. :)

Define multitasking :)

There was a company (sadly defunct) that was building Erlang unikernels, and you can't say Erlang doesn't have multitasking.

I've been a bit interested in unikernels lately. I get the feeling they were pretty hyped a few years ago but never really took off. Can anyone give a brief summary of the history and current state and/or point to some good materials?

My own personal opinion is that a lot of the earlier projects were fixated on performance at all costs (even when the numbers didn't prove so - always run your own benchmarks) with the heavy downside that you would need to have custom compile/add patches for everything. That's a real non-starter for the vast majority of people out there.

There are now at least 3 venture-backed commercial companies working on unikernels today (maybe more), ours being one.

wish I was lucky enough to work in unikernels... is it in beautiful C?

It most definitely is. :)

I guess the name HermitCrab was already taken?

Not really but quoting the Readme:

"RustyHermit is a rewrite of HermitCore in Rust developed at RWTH-Aachen."

They wanted to keep the Hermit most probably

I suggest adding firecracker to the list of supported virtualization stacks.

Nice, was just chatting with a friend last night that I would love to see a MirageOS equivalent for Rust.

At https://unikraft.org/ we're working on that. We already have support for developing/adding OS modules to Unikraft in Rust, and we are planning to have support for Cargo/running Rust applications before the year's out (you can check out the Rust channel on our Discord server [1] if interested in more information)

[1] https://bit.ly/UnikraftDiscord

That is very exciting! Could you describe the main differences between Unikraft and RustyHermit?

I would say that a key difference between both OSes is the degree of compatibility with existing applications. Unikraft offers binary-compatibility with Linux apps written in arbitrary languages without the need for rebuilding, while RustyHermit is limited to Rust and C apps, and requires recompiling the app against the library OS code.

Another important difference is that Unikraft's kernel is written in C while RustyHermit's is in Rust (although if you want it to run C apps, RustyHermit needs to include a big chunk of C code that is the newlib standard library).

HermitCore-rs – A Rust-based, lightweight unikernel - https://news.ycombinator.com/item?id=18444832 - Nov 2018 (10 comments)

Is there a Heroku-like service for any of the unikernels yet?

There is this one: https://nanovms.com/

I work at NanoVMs. We don't actually do hosting. What we've found in the past is most organizations are very wedded to their existing infrastructure (AWS/GCP/Azure, etc.) so you can deploy Nanos to any cloud. I suppose we could turn something on again in the future if we wanted too but all of our users/customers are mostly on the big three clouds.

However, you are spot on that deploying Nanos to say GCP is very much a heroku like experience. I'd encourage anyone who is interested to just try it out.

Nice, this looks great.

You guys hiring?

Also https://unikraft.org/

Great work

What exactly is a unikernel and why should I care? or How is a unikernel different from an ordinary kernel like linux?

From the first paragraph:

> Unikernel means, you bundle your application directly with the kernel library, so that it can run without any installed operating system.

Reply on news.ycombinator.com