Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mirage – A programming framework for building type-safe, modular systems

mirage.io

Post reply on HN
Print view View original

71–80 of 92 posts

Re: Mirage – A programming framework for building type-safe, modular systems

#71

Post by eyberg »

samuell wrote: post #33
repelsteeltje wrote: post #16

Earlier quoted context omitted.

Mirage is a unikernel. The catch here is Ocaml. You can design your unikernel "bare metal" in any way you want and make it do nothing but the essentials you need ... and design it in any language you want as long as that language is OCaml.

And on that note, I just found this list of UniKernel projects: http://unikernel.org/projects/ I have especially had hopes for the UniK [1] project, as it was/is written in Go AFAIK. I see now it incorporates work from the Mirage project as well. Not sure what is the status of this project anymore though. [1] https://github.com/solo-io/unik

Unik was just a build tool that utilized other projects like Rump, Mirage, IncludeOS, etc. It's now dead since Solo pivoted a very long time ago to service mesh/api gateways.

The GoRump port they use was from us and then we realized we needed to code our own from the ground up for many reasons so we wrote https://nanos.org (runs as a go unikernel in GCP).

Re: Mirage – A programming framework for building type-safe, modular systems

#72

Post by Veserv »

reycharles wrote: post #40
datadeft wrote: post #35

Earlier quoted context omitted.

> I'm really sold on the idea: Instead of a full-blown OS, You mean you are sold on the idea of going back to the 80s. We used to have an operating system with every game released[1]. 1. https://youtu.be/kZRE7HIO3vk?t=1114

A big difference in my opinion is that projects like Mirage does not try to reimplement the same hardware drivers as the host system and instead implements much simpler drivers for virtual hardware. For example, how do you write to a block device? You make a hypercall with a "handle", offset into the block device, the number of blocks to write and a pointer to memory to be written. There's no pretending it's a spinny…

That is just infinitely worse than calling write() on a file handle like a regular application.

The hypervisor + OS + application model is stupid. The hypervisor and OS are duplicative. If you can rewrite the application (as is needed for a unikernel design) there is no reason to use a hypervisor in your stack at all. You should just be running a OS directly on the bare metal with no hypervisor at all.

The only reason to prefer a unikernel is because you wrongly believe that hypervisors are a security boundary. Everything else about them is strictly inferior to a standard application on OS model.

Re: Mirage – A programming framework for building type-safe, modular systems

#73

Post by eyberg »

Veserv wrote: post #72
reycharles wrote: post #40

Earlier quoted context omitted.

A big difference in my opinion is that projects like Mirage does not try to reimplement the same hardware drivers as the host system and instead implements much simpler drivers for virtual hardware. For example, how do you write to a block device? You make a hypercall with a "handle", offset into the block device, the number of blocks to write and a pointer to memory to be written. There's no pretending it's a spinny…

That is just infinitely worse than calling write() on a file handle like a regular application. The hypervisor + OS + application model is stupid. The hypervisor and OS are duplicative. If you can rewrite the application (as is needed for a unikernel design) there is no reason to use a hypervisor in your stack at all. You should just be running a OS directly on the bare metal with no hypervisor at all. The only reaso…

One of the key insights for unikernels in general is that everything is virtualized now to begin with. The entire public cloud: AWS, GCP, Azure, etc. is virtualization with an api on top of it.

So unikernels take advantage of this fact to get the performance, security and ease of use benefits.

Hypervisors most definitely have better hardware-based isolation than a few processes running in linux. In fact the isolation is so good that the entire public clouds are built on this model.

Re: Mirage – A programming framework for building type-safe, modular systems

#74

Post by necrophcodr »

Veserv wrote: post #72
reycharles wrote: post #40

Earlier quoted context omitted.

A big difference in my opinion is that projects like Mirage does not try to reimplement the same hardware drivers as the host system and instead implements much simpler drivers for virtual hardware. For example, how do you write to a block device? You make a hypercall with a "handle", offset into the block device, the number of blocks to write and a pointer to memory to be written. There's no pretending it's a spinny…

That is just infinitely worse than calling write() on a file handle like a regular application. The hypervisor + OS + application model is stupid. The hypervisor and OS are duplicative. If you can rewrite the application (as is needed for a unikernel design) there is no reason to use a hypervisor in your stack at all. You should just be running a OS directly on the bare metal with no hypervisor at all. The only reaso…

This only works if your environment is bare metal to begin with. In some cases you may be in an environment where a lot of applications are proprietary, virtualized, or otherwise constrained in some other way. It is not an environment where you get to pick and choose how everything is setup. In such a case, having a distinct small application that fits as "an OS" in a virtualized environment can fit a lot better in, than trying to retrofit a baremetal containerized environment into a large enterprise datacenter where everything is already running Windows servers and proprietary services, managed by other people than yourself.

Re: Mirage – A programming framework for building type-safe, modular systems

#75

Post by hannesm »

eightnoteight wrote: post #41
rapsey wrote: post #14

Earlier quoted context omitted.

> there's little need to SSH into the system in the first place (except for debugging purposes). Pretty big except though. This concept has been done multiple times and has always failed. It's solving a problem that few care about.

exactly this, debugging is a pretty big part when it comes to operational aspects. but I feel like similar to kubernetes container injection systems. I suspect in future we would see dynamic injection into the unikernel where you can enable debugging environment instantly. like the library unikernel exposes a plugin system that you can inject in future, this way the unikernel is lightweight and only gets bloated when…

What you already can do is attaching gdb -- either live or at a core dump. Please see https://github.com/Solo5/solo5/blob/master/docs/debugging.md for detailed instructions ;)

What you as well can do is record-replay -- well, at least there used to be this option, I'm now lost whether it has never been merged anywhere, or it is stuck in some PR somewhere. This was truly great - since the external interface is so thin, it is easily doable to dump all external events (API calls and returns) onto disk and replay one-by-one, inspecting the state.

Re: Mirage – A programming framework for building type-safe, modular systems

#77

Post by 0xDEAFBEAD »

Veserv wrote: post #72
reycharles wrote: post #40

Earlier quoted context omitted.

A big difference in my opinion is that projects like Mirage does not try to reimplement the same hardware drivers as the host system and instead implements much simpler drivers for virtual hardware. For example, how do you write to a block device? You make a hypercall with a "handle", offset into the block device, the number of blocks to write and a pointer to memory to be written. There's no pretending it's a spinny…

That is just infinitely worse than calling write() on a file handle like a regular application. The hypervisor + OS + application model is stupid. The hypervisor and OS are duplicative. If you can rewrite the application (as is needed for a unikernel design) there is no reason to use a hypervisor in your stack at all. You should just be running a OS directly on the bare metal with no hypervisor at all. The only reaso…

>The only reason to prefer a unikernel is because you wrongly believe that hypervisors are a security boundary.

Thoughts on Qubes?

Re: Mirage – A programming framework for building type-safe, modular systems

#78

Post by naasking »

Veserv wrote: post #72
reycharles wrote: post #40

Earlier quoted context omitted.

A big difference in my opinion is that projects like Mirage does not try to reimplement the same hardware drivers as the host system and instead implements much simpler drivers for virtual hardware. For example, how do you write to a block device? You make a hypercall with a "handle", offset into the block device, the number of blocks to write and a pointer to memory to be written. There's no pretending it's a spinny…

That is just infinitely worse than calling write() on a file handle like a regular application. The hypervisor + OS + application model is stupid. The hypervisor and OS are duplicative. If you can rewrite the application (as is needed for a unikernel design) there is no reason to use a hypervisor in your stack at all. You should just be running a OS directly on the bare metal with no hypervisor at all. The only reaso…

> The only reason to prefer a unikernel is because you wrongly believe that hypervisors are a security boundary.

That's wrong. They rightly believe that traditional operating systems deployments come with much larger attack surfaces.

Re: Mirage – A programming framework for building type-safe, modular systems

#79

Post by fhuici »

ekianjo wrote: post #7

Is that similar to Firecracker?

No, though you could use Firecracker to launch a Mirage (or any other) unikernel.

Basically from the bottom up the stack is:

1. Hypervisor (e.g., KVM, Xen, Hyper-V), runs directly on the hardware 2. Virtual Machine Monitor (e.g., QEMU, Firecracker), running on the host's user-space (say Linux) and in charge of starting/stopping/managing VMs and interacting with the hypervisor 3. Virtual machines, eg, a Linux VM running an NGINX web server.

(the above is simplified because there are differences between type-1 and type-2 hypervisors, but those diffs would make this message too long)

A unikernel is actually a virtual machine, just a very specialized one that doesn't use a general-purpose OS underneath. They tend to use library OSes, so that it's possible to choose libs that are appropriate to each app at build time.

And while we're at it :) , a MicroVM is nothing more than a standard VM (e.g., based on Linux) launched/managed via a fast/modern VMM like Firecracker.

Re: Mirage – A programming framework for building type-safe, modular systems

#80

Post by fhuici »

jezovuk wrote: post #20

Is this (functionally) similar to CloudCaptain, ex-BoxFuse? https://cloudcaptain.sh/

No, CloudCaptain is based on Linux, and tries to provide a minimal, though Linux-based, image.

Unikernels do not use Linux at all: you can always try to minimize Linux but fundamentally it is a monolithic OS and fully specializing with it would require non-negligible engineering.

Instead, unikernels are (typically) based on a modular OS that makes it easier to pick and choose modules for each target application, resulting in images that can be an order of magnitude smaller, boot much faster, etc.

The difficulty with unikernels in the past has been to (1) making them Linux API compatible, (2) making them accessible/easy to use and (3) integrating them with popular tooling ecosystems (e.g., Docker, Kubernetes, Prometheus, etc.)

Post reply on HN