perbu

Have you flown on autopilot? It maintains speed, height and direction. It doesn't land or take off. Originally it couldn't even turn.

Not quite. Everything runs as PID 0. :-)

There are no processes here. Everything runs inside the kernel. You don't have exec(), fork() or similar.

Basically you replace the system calls into the kernel with library calls. So you end up with a single binary that contains both the application as well as the operating system functionality.

This can lead to some rather spectacular performance benefits. One thing is that you remove the syscall overhead, but more importantly you can do a lot more optimizations at the compiler/linking steps.

You can remove complex code that tries to dynamically model the world with rather plain code that does just what it is supposed to. With IncludeOS (C++17 unikernel) we did make a firewall implementation that instead of using complex data structures relied on preprocessing the rule set and translate it into C++ code. The code to do this was quite simple and resulted in pretty amazing figures wrt number of rules per packet per second. Metaprogramming can sometimes deliver amazing results.

Similar things can be done in a traditional kernel as well and we've seen eBPF firewall implementations that are able to get similar numbers. On the flip side eBPF and it's firewall implementation is order of magnitude more complex. However, you can push eBPF code onto the networking card which can be a huge benefit. And ofc you could make a kernel module that implements a specific firewall ruleset and get similar performance without eBPF.

I like unikernels because I feel I can understand them better. You can reason about them and they are easier to optimize for very specific workloads.

So why aren't we using them? Likely because we know Linux so well and we've invested a lot in it. It runs everywhere and is extremely well supported. Bringing a new operating system to market is challenging, bringing a new operating system with a entirely different architecture is even harder. Even if it, on a purely technical level, could yield better results.

Unikernels are typically statically linked. Using copyleft code means the whole resulting binary is subject to copyleft.

Free software is great, but not everyone is in the position where they can release all of their code all the time.

For a unikernel to be viable it can't have copyleft code in it.

Highway speeds are 90-110km/h (55-70mph). General speed limits are 80km/h and 50km/h (50/30mph) depending on pop. density.

Speeds are often reduced if the road is sub par or if there have been accidents on that bit of road.

Yes. The limits are low, but definitivly not _incredibly_ low.

There used to be quite a few different mainframes on the market. HP/Tandem had their Non-stop systems which was perhaps the most distinct competitor - but there were quite a few companies competing in the space.

However, IBM has dominated this market for as long as I can remember and today I believe they are the only ones making mainframe computers.

It really isn't very expensive. Installation is mostly connecting the inside unit with the outside unit through an 8-10mm pipe (1/3"). The work is about 2-3 hours and material costs are pretty insignificant. The HX units are pretty costly, though. About $2K for a decent one.

Where I live, Norway, a lot of houses have gotten these retrofitted.

You can think of containers as virtual Linux environments, implemented natively in Linux. Contrasted with Linux, the overhead is pretty minimal. Since Unix systems have some "virtualization" built-in natively, being multi-process, it fits nicely, imho.

A unikernel is quite different. It allows you to create a bootable application with built-in operating system.

One really doesn't have much in common with the other.

It's low-value work. Facebook doesn't value these people enough to employ them so they likely don't have access to properly engineered tools.

GPL2, I doubt you'll find any GPL3 code in there.

Which is why bash on MacOS is from 2007.

Containers share the OS kernel and some services. This is a virtual machine monitor, so it deals with virtual machines. A container can only run Linux containers.

Firecracker can likely run other operating systems, such as IncludeOS. You can't run those in containers.

Firecracker contains a machine emulator. This emulator will jail itself before launching the OS to reduce the attack surface the emulator has towards the host.

KVM supports Windows just fine, which is why you can run Windows on GCP and Openstack. And Firecracker seems to support enough of a machine to boot Windows as long as the windows instance has support for libvirt disk devices and a libvirt NIC.

However, it seems they boot in a slightly unconventional way. They take a elf64 binary and execute it. This works for Linux and likely some other operating systems that can produce elf64 binaries. Windows supports legacy x86 boot and UEFI, but likely not elf64 "direct boot".

So if you can get windows into an elf64 binary and have it run without a GPU you could have it boot. So, likely not. But the reason isn't due to KVM.

IncludeOS is modeled much like FreeRTOS or Zephyr. The difference is mainly that it addresses CPUs and not microcontrollers as the primary platform. With paging, you have better security, typically.

If you plan on using Javascript on Lambda the bashing makes perfect sense.

So if want to write serverless functions in Go or Python you go somewhere else. But if you, as most other do, write them in Javascript, then this is a relevant platform to consider.

For a technical, in-depth overview of IncludeOS and how it was made I find the main authors presentation at Cppcon 2017 is a pretty good introduction:

https://www.youtube.com/watch?v=h7D88U-5pKc (one hour, quite entertaining).

There is also the original paper which was presented at the 2015 IEEE 7th International Conference on Cloud Computing Technology and Science (CloudCom).

https://ieeexplore.ieee.org/abstract/document/7396164

Absolutely. And most of those are deemed out of scope for Unikernels.

There is a project that tries to turn Linux into a library which could lead to a unikernel approach with the Linux. If you look at https://github.com/lkl you can see where they are.

A leaned down Linux-kernel with the application linked into kernel space would be pretty comparable. But it would be pretty enormous beast.

I'm hoping we're be able to port libuv to IncludeOS (which should be doable, much like libuv IncludeOS is eventdriven). Then we should be able to get Node up and running. Running Node.js through IncludeOS on Nabla could be interesting in a "FaaS" context.

Last I heard the author of Rumprun has picked up beer brewing full time and isn't interested in maintaining the project.

It would be great if someone where to pick it up.

OSv is also very relevant. They provide a much richer and more compatible runtime environment compared to IncludeOS (I think they even have zfs). And OSv is pretty active these days, so if you looking for a way to run some high performance stuff OSv is worth looking into.

Your assumption is correct. IncludeOS will never be fully compatible with Linux. Our goal is to provide "just enough POSIX" so that the applications that are relevant for the OS will compile and run. Mostly we're concerned with various "gateway-like" applications - firewalls, load balancers and down the line also IoT-gateways.

Wrt. to why we have to implement Linux-like syscalls; Musl is written specifically for Linux so in order to "unlock" the relevant POSIX-bits that Musl can provide we have to provide the underpinnings that Musl requires.

I'm hoping we can upstream some of our non-intrusive changes to Musl. However since Musl has a very specific purpose (a Linux-specific C and POSIX library) I'm not certain that our changes are within the scope of the project. To date we've only concerned ourselves with a small subset of Musl and only on amd64.

No worries. I never meant for the blogpost to reach an audience outside of our pretty narrow knitting circle so I didn't pay much attention to detail. I very much appreciate your insights here.

(I work for Includeos)

I don't think we need to run everything. I think we'll be happy if we can take some common libraries and compile them and they work. That is currently our goal. Down the road, depending on interest, we can perhaps expand a bit.

>> Moreover, since implementing a system call is typically pretty simple [...]

> You're in for a fun ride, folks.

Thanks for the heads up. It was meant as opposed to implementing the syscall and layers on top of it.

On Unix you typically fork as a part of initializing your application in order to demonize. Or when you are executing another program so a fork/exec.

The first one isn't needed in a unikernel. You are already demonized when you boot up.

The second use is not available to unikernel applications. The limitation of a single application per vm applies.

No. The Wifi is on the SDIO bus, I believe.

Absolutely. I would rank you in the very top of developers with experience in development of traditional operating systems. In particular DTrace stands out as an excellent piece of work. It's one of those fundamental advances that serves as inspiration for others.

Now, I'm not sure I agree that I have a horse in the race. I don't necessary believe that there is a race. I've never really been a proponent of the schism between Unikernels and Containers. I struggle to see how Unikernels can offer the same flexibility and ease of deployment as containers. We're likely won't be able to support the vast amounts of runtimes and infrastructure needed to replace something like Docker. Perhaps there could be very specific uses where something like the paper described could be used, but I'm not betting on it.

As a software project IncludeOS has a much narrower target than what people traditionally have thought when thinking of Unikernels. And as a result of of this we're not in the business of replacing neither containers not general purpose operating systems(GPOS). We're aiming to carve out a few niches where we are confident that a GPOS isn't the answer. We're only going to address those needs where we're pretty certain we can actually add some value. Basically we're think we can improve on security in addition to adding real time capability whilst still remaining source-code compatible with Linux (mostly thanks to musl).

My grief is singularly with the myths you helped create that Unikernels are something where you are forces to work with stone age tools and hardly without any tools, except printf, for debugging. We've had to spend a lot of time dispelling these. There are a few other things I believe you where wrong about at the time but I'll spare you the details. Better suited discussions over a beer of coffee.

No commits since April. I think Antti has left the project and started a brewery or something.

No, we didn't see you there. :-)

It was a more of a workshop in relation to ICS2018.

The value lies in security in this context. You also get a bit of performance as the "unikernels" are self-contained. So you can do most things, including the IP stack without switching into kernel mode.

I'm guessing this is mostly interesting for FaaS platforms or similar. You get isolation similar to hardware-assisted vms but with a lot less overhead and with phenomenal boot-times.

Cantrill is a smart guy. But he has always had a big mouth. And the fact is his post was written with ZERO experience with Unikernels. Zero. He was just assuming they act the way he imagined and attacked that image.

Which is fine if you're upfront about it. He wasn't.

Sure. As long as you disable init on the server you'll have a unikernel setup. Round hole, square peg, though. Linux isn't meant to work like that.