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

61–70 of 92 posts

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

#61

Post by pjmlp »

Tainnor wrote: post #57
pjmlp wrote: post #43

Earlier quoted context omitted.

In the kind of corporate environments I work on, you won't be doing any SSH into the production containers. Nothing that a classical UNIX admin would expect is installed on those images.

Those kind of corporate environments would also never use a technology like MirageOS that very few people know how to use.

In those kind of corporate environments liability is a concern, and something like MirageOS would be quite appealing.

These are the same kind of environments where CI/CD can only fetch from internal repos, where stuff only gets installed after IT and legal had a say on it.

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

#62

Post by reycharles »

mkarliner wrote: post #50

Does anyone know if there might be Arm support coming? This strikes me a a nice fit for some single board computers.

It is possible to run Mirage in ARM under for example KVM or using the seccomp target.

There is as well an experimental bare-metal target for raspberry pi 4 called gilbraltar https://github.com/dinosaure/gilbraltar. A big obstacle there is the device drivers. It is very cool to run bare metal on an rpi4, but it would be cool to be able use the network interface too.

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

#63

Post by fhuici »

lazzlazzlazz wrote: post #22
v1ne wrote: post #8

I'm really sold on the idea: Instead of a full-blown OS, you compile your application with a thin layer of support libraries that provide the OS features that your application needs (network, I/O) and that talks to a hypervisor. I mean, if your application runs in a virtualized environment, there's little need to SSH into the system in the first place (except for debugging purposes). Thus, why bother with a full-blow…

But what's the benefit of cutting out the full-blown operating system? It's rare that such things would be the bottleneck.

At least for cloud deployments you don't need a full blown OS when all you want to do is run apps like NGINX or Redis. If you use a unikernel instead, then you severely (orders of magnitude) reduce cold boot times, memory consumption, server density (thousands on hw-isolated instances on a single server) and TCB.

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

#64

Post by fhuici »

repelsteeltje wrote: post #16
Osiris wrote: post #10

Earlier quoted context omitted.

Isn’t this the same idea behind unikernels?

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.

For a language-agnostic unikernel project you can also check out www.unikraft.org (OSS/Linux Foundation, actively maintained).

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

#65

Post by fhuici »

troupo wrote: post #48
v1ne wrote: post #8

I'm really sold on the idea: Instead of a full-blown OS, you compile your application with a thin layer of support libraries that provide the OS features that your application needs (network, I/O) and that talks to a hypervisor. I mean, if your application runs in a virtualized environment, there's little need to SSH into the system in the first place (except for debugging purposes). Thus, why bother with a full-blow…

> I'm really sold on the idea: Instead of a full-blown OS, you compile your application with a thin layer of support libraries that provide the OS features that your application needs I'm really sad that unikernels never took off, even there seemed to be a lot of excitement around them a few years back.

The second wave is coming :) . At www.unikraft.org we're hard at work providing a Linux-API compatible unikernel (run unmodified apps/langs) and combining it with tooling like docker and k8s.

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

#66

Post by fhuici »

9dev wrote: post #39

What is the benefit over using containers, as in Docker? Whether you use a container runtime or an actual hypervisor comes down to pretty much the same thing, operationally. Both keep your self-contained services alive and distributed. From the application perspective, a container also contains only those parts of an OS the app actually needs, and defers everything else to the host. The only caveat about MirageOS see…

At least for cloud deployments you'll (for almost all cases) already have a hypervisor underneath to provide strong isolation. With that in place, ideally you'd run your application (ultimately the only thing you care about) as close to that hypervisor as possible. Instead, we have hypervisor, and then inside the VM the (say Linux) kernel, user-space, the container runtime, and finally the application.

With a unikernel the stack becomes hypervisor and a VM that has a very thin layer and then the application -- as close to the application running on the hypervisor as possible. This results in lots of gains in terms of minimal cold boot times, memory usage, server density (thousands on a single server), etc.

In fact, you don't need to see containers and unikernels as an either or choice: in fact, at Unikraft (another unikernel project) for development and local deployment we have support for Docker/Dockerfiles -- and then for deployment we provide a lean unikernel as described above.

Hope this clarifies things somewhat.

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

#68

Post by Veserv »

gizmo wrote: post #52
9dev wrote: post #39

What is the benefit over using containers, as in Docker? Whether you use a container runtime or an actual hypervisor comes down to pretty much the same thing, operationally. Both keep your self-contained services alive and distributed. From the application perspective, a container also contains only those parts of an OS the app actually needs, and defers everything else to the host. The only caveat about MirageOS see…

It makes no sense for a microservice that does one simple thing to run on top of 10 million lines of 90s C code. Especially since a lot of that code has to do with hardware quirks that don’t exist in a hypervised environment.

A hypervised environment also has 10 million lines of 90s C code with a lot of code dealing with hardware quirks, it is called the hypervisor.

You are right that it makes no sense to have a hypervisor, OS, and application. The hypervsior and OS are basically doing the same job. But the solution is not bare metal + hypervisor + device drivers + hypervisor services + library OS + application like a unikernel design. It is bare metal + OS + device drivers + OS services + application like a container design.

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

#69

Post by baumschubser »

fhuici wrote: post #67
goy wrote: post #30

Another one is HalVM [0], for Haskell. Unfortunately it's not maintained anymore. [0] https://github.com/GaloisInc/HaLVM

There's also LF/OSS www.unikraft.com, language-agnostic/Linux API compatible, actively maintained.

https://unikraft.org/ it is

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

#70

Post by insanitybit »

Tainnor wrote: post #57
pjmlp wrote: post #43

Earlier quoted context omitted.

In the kind of corporate environments I work on, you won't be doing any SSH into the production containers. Nothing that a classical UNIX admin would expect is installed on those images.

Those kind of corporate environments would also never use a technology like MirageOS that very few people know how to use.

Sure they would. I've be interested in Mirage and I don't believe that developers should have SSH access to systems.

I could see the value in a debug port or something, though. But giving full remote code execution is total overkill.

Post reply on HN