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-blown operating system? In the virtualized case, the true OS logic is in the host OS anyway, talking to the hardware. Cutting out all those superfluous layers in the app VM makes it small, start quickly, and gives less attack surface. Sounds like a win-win to me.
In contrast, FreeBSD on Firecracker is a full-blown OS, but boots in 25 milliseconds on the Firecracker hypervisor.
A big milestone was binary releases and deployment instructions, see https://robur.coop/Projects/Reproducible_builds
see more at https://blog.robur.coop https://hannes.robur.coop https://blog.osau.re/ https://reyn.ir/archive.html
If you're curious how/what to integrate MirageOS into your infrastructure, please reach out (best via email).
Pretty big except though.
This concept has been done multiple times and has always failed. It's solving a problem that few care about.
Nothing that a classical UNIX admin would expect is installed on those images.
I would love a super slimmed down stack to run workloads on. Most of the time when I run workloads, I want to run the workload and nothing else. The OS in the container exists to start the binary I care about and then basically very little else-these applications aren’t making use of a scheduler, or the init system (because again, I’m only running my binary), users and permissions go unused a good chunk of the time. With stuff like quic becoming more popular we’ve got user space networking too, so that’s out. So by this stage we’ve got a whole OSCthats doing almost nothing except passing stuff between layers an incurring a performance and risk overhead.
If we could have the same functionality, with better performance and the same or better security, why wouldn’t I do that?
> This concept has been done multiple times and has always failed
Isn’t it likely that this idea was just “before its time”? The compute landscape these days is pretty different to ~20+ years ago: massively available public cloud compute, prolific container usage, etc. Software stacks are deeper, more ossified and less fully understood than ever, I definitely see solutions that reduce that complexity being appealing.
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 you eventually want to debug something.
Security?
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].
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 disk with sectors and heads or what have you.
https://github.com/Solo5/solo5/blob/bf29b8af11feec9dbc2e74cc...
I'm really sad that unikernels never took off, even there seemed to be a lot of excitement around them a few years back.
MirageOS represents a significant shift in cloud and network computing, focusing on building highly specialized, secure, and efficient unikernels that streamline application deployment by shedding unnecessary components. It also puts extra focus on security, with most of the stack — including TCP and TLS — being rewritten in a type-safe language (OCaml).
Currently, MirageOS is expanding to include bare-metal and embedded systems, aiming to bring the same level of security and efficiency to this domain. The move towards embedded systems is a natural progression for MirageOS, given our emphasis on minimalism and security in environments where resources are limited and reliability is crucial. See for instance what is happening with SpaceOS: https://tarides.com/blog/2023-07-31-ocaml-in-space-welcome-s...
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.
> MirageOS is a library operating system that constructs unikernels for secure, high-performance network applications across a variety of cloud computing and mobile platforms.
Similar to trying to run containers bare metal directly on top of type 1 hypervisors, except unikernels are designed for this purpose.
Then a bunch of folks, with some VC money, decided to make the second coming of Java and .NET with it.
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.
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.
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.)
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.
EDIT: here as well: https://mirage.io/docs/install maybe you need a Solo5 backend that can run on ARM; and finally: https://github.com/Solo5/solo5/blob/v0.6.3/docs/building.md#...
> (…) They should build on any modern UNIX (or macOS) system with OCaml and OPAM installed. (…)
I just checked. MacOS Sonoma is STILL UNIX certified, and I get that wording “any modern UNIX” would not be clear this minor error annoys me.
s/or MacOS/including MacOS/
"We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy."
-- https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...
Though last I looked it wasn't nearly as mature as MirageOS.
https://dev.l1x.be/posts/2020/11/22/getting-started-with-fir...
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.
