linuxkit VS Flatcar

Another project that aims to deliver this is Linuxkit (https://github.com/linuxkit/linuxkit). All the components they ship are written in memory safe languages (usually Go) and run as containers under containerd. You can build a custom image very easily, fully defined as a YAML file.

docker-the-company maintained https://github.com/linuxkit/linuxkit when I worked there. I have no idea who maintains it now, but it looks like it is still active (presumably still docker-the-company, since their adopters list [1] lists docker desktop).

[1]: https://github.com/linuxkit/linuxkit/blob/master/ADOPTERS.md

LF-Edge EVE project leverages Linuxkit to create custom OSs for Edge Devices which in turn leverages Containers as Lego Blocks

LinuxKit - Docker

Behind the scenes Docker Desktop for Mac spawns a linuxkit VM with a bit of extra stuff like NFS to enable mounting Mac paths into containers. In the Docker Desktop settings you'll find the current resource assignment for that VM. That is pretty much reserved for docker so that it does not have to compete with MacOS processes for available resources.

That said... you might want to check out linuxkit

The definition of what a unikernel is needs to be narrowed down, a lot of these projects in the space (not all the ones listed above) have material differences that are not clear:

- some run only one language

- some require recompilation

- some essentially swap out libraries, others do something closer to dropping your already mostly static binary in a minimal disk image

- some build pid1 processes, others VMs images

Anyway, here are some additional entries in the space:

- https://ssrg-vt.github.io/hermitux/

- https://github.com/linuxkit/linuxkit (more embedded/minimal VM than unikernel)

- https://nabla-containers.github.io/ (runs on Solo5)

I am going through using Linuxkit to build AMIs for cloud providers now. I wouldn’t necessarily class linuxkit as a universal project because it doesn’t have the hallmark blurring of user and kernel space or kernel-as-a-library but you can customize the kernel so it’s an adjacent idea, and I think it’s the one most likely to be in actual use at non-hyperscalers.

I believe there is growing interest in providing leaner, "trimmed" runtimes for services deployed to the cloud. Today, this is seen largely by specializing the Linux kernel for, for example, container services[0] or in general[1], as much as that is possible (the paper above covers this problem in greater detail). But, Unikernels in themselves are not yet widely adopted. This is the space Unikraft is aiming to enter, providing the ultimate level of specialization for a target application.

It's clear that bigger players, such as Red Hat[2] are interested in the topic of unikernels, and that cloud providers are preparing for this future too [3].

[0]: https://github.com/linuxkit/linuxkit

Sounds like you're looking for the CoreOS Linux successor FlatCar https://www.flatcar.org/

It's actually based on some ChromeOS update tools under the hood but is a regular Linux distro, just super minimal and designed to run containers.

I guess if you found my comment to be "comically hyperbolic" then replying to mine with a "comically reductionist" is fair game

So, anyway, I actually did dig up a concrete example of my experience with it, and I cannot link to the "Additional information" section but that is both why I think the thing was a mess and also why the Miroservices YT joke resonated: https://github.com/flatcar/Flatcar/issues/220

I think the CoreOS boot strategy was decomposed into a bunch of different executables, each responsible for doing their own little slice of the world. Maybe it drew inspiration from systemd in that way. But, just like my real life experience with microservices, it requires keeping a bunch of different projects and their upgrade paths in ones head, knowing their disparate config formats, and when one of them inevitably has a bug, understanding how to troubleshoot what went wrong with the system as a whole

And, again in trying to be reasonable in this discussion[1] I do also understand why one would opt for the data URI, given how much of the rest of Ignition loads content from URLs. I don't believe cloud-init has that remote content paradigm baked into in nearly the same way, so I hear you about that.

And yes, my belief is that JSON is a data-exchange format from _computer to computer_ and making people write them is a poor DX choice, IN MY OPINION. And, to reiterate, I know that CoreOS's perspective is that it is a computer-to-computer transmission from the transpiler-project-o-the-day to the Ignition binary, but that is predicated on one having access to that transpiler binary in all cases, which is quite different from the problem that cloud-init is trying to solve

fn-1: I'm sorry you got hurt by my "tire fire" outburst, and that evidently derailed this whole interaction, but it was my experience