[HN Gopher] RustyHermit - A Rust-based, lightweight unikernel
___________________________________________________________________
RustyHermit - A Rust-based, lightweight unikernel
Author : brodo
Score : 137 points
Date : 2022-10-31 08:59 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| dang wrote:
| Related:
|
| _HermitCore-rs - A Rust-based, lightweight unikernel_ -
| https://news.ycombinator.com/item?id=18444832 - Nov 2018 (10
| comments)
| anderspitman wrote:
| 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?
| eyberg wrote:
| 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.
| kitplummer wrote:
| Is there a Heroku-like service for any of the unikernels yet?
| brodo wrote:
| There is this one: https://nanovms.com/
| eyberg wrote:
| 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.
| unikraft wrote:
| Also https://unikraft.org/
| ComputerGuru wrote:
| I suggest adding firecracker to the list of supported
| virtualization stacks.
| cmrdporcupine wrote:
| Nice, was just chatting with a friend last night that I would
| love to see a MirageOS equivalent for Rust.
| unikraft wrote:
| 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
| nequo wrote:
| That is very exciting! Could you describe the main
| differences between Unikraft and RustyHermit?
| ThinkBeat wrote:
| Great work
| mastax wrote:
| I guess the name HermitCrab was already taken?
| Corendos wrote:
| 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
| mjburgess wrote:
| 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.
| galangalalgol wrote:
| With the advent of any-arch binaries, and fast emulation (qemu
| wasm), it probably won't matter if it is x86 or not.
| pjmlp wrote:
| Why advent? That was already standard on OpenSTEP.
| pasc1878 wrote:
| And NeXTStep OpenSTEP's predecessor had already implemented
| it.
| pjmlp wrote:
| Might have been, I mentioned OpenSTEP, because NeXTSTEP
| didn't need to be cross platform, that requirement only
| came to be with the former.
| pasc1878 wrote:
| 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
| pjmlp wrote:
| I stand corrected.
| galangalalgol wrote:
| 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?
| pjmlp wrote:
| You had all binaries on the same executable.
|
| https://en.m.wikipedia.org/wiki/Mach-O
| nigerianbrince wrote:
| Multitasking can go to hell I guess.
| dmitriid wrote:
| Define multitasking :)
|
| There was a company (sadly defunct) that was building Erlang
| unikernels, and you can't say Erlang doesn't have
| multitasking.
| Corendos wrote:
| I mean, if you have one task to do only, multi-tasking is
| kind of pointless yes
| dundarious wrote:
| 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.
| pjmlp wrote:
| Each of those services can be a unikernel being managed
| by a type 1 hypervisor.
| dundarious wrote:
| 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.
| pjmlp wrote:
| In a way it is a return to the days of playing games in 8
| and 16 bit platforms. :)
| [deleted]
| cmrdporcupine wrote:
| Why? You can easily implement a scheduler. And there's
| multiple cores. And potentially multiple instances on the
| hypervisor.
| Jweb_Guru wrote:
| "Easily" is doing a lot of work there.
| cmrdporcupine wrote:
| Yeah I re-read it later and was like.. ok, fine, I should
| put "easily" in quotes ;-)
|
| Still, it's entirely feasible.
| eyberg wrote:
| 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/1
| 0.1186/s424... .
| bumblebritches5 wrote:
| UltraViolence wrote:
| 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?
| [deleted]
| progbits wrote:
| 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.
| skrtskrt wrote:
| How would something like this support logging, telemetry,
| debugging, etc as part of enterprise-grade software
| clusters if it has "no other services"?
| ComputerGuru wrote:
| 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.
| lordleft wrote:
| Isn't this, in a very roundabout way, an echo of docker? Or at
| least the abstraction Docker relies on?
| agtorre wrote:
| I definitely see this as an alternative route from docker
| containers / WASM.
| WastingMyTime89 wrote:
| 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.
| max_ wrote:
| What exactly is a unikernel and why should I care? or How is a
| unikernel different from an ordinary kernel like linux?
| nkozyra wrote:
| 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.
___________________________________________________________________
(page generated 2022-10-31 23:01 UTC)