While I’ve never been much of a collector myself, over the last couple years I’ve acquired a taste for retrocomputing content, avidly consuming the videos produced by people like The 8-Bit Guy, Adrian’s Digital Basement and Jan Beta, among others.

I’m amazed by the love they put on testing and restoring all kinds of old computers, and it’s definitely contagious. So, some months ago I decided to go shopping myself.

Being able to run AI models locally is one of the coolest tech things 2023 brought to the table. But given the extremely heterogeneous software stack for AI accelerators, doing that in an efficient way on your own laptop is not always as easy as it should be.

For instance, if you’re running macOS on an Apple Silicon machine, you can easily build llama.cpp with its Metal backend and offload the inference work to the M-based GPU. But can you do that from a container?

It’s been almost a year since I transitioned from the Virtualization to the Automotive team at Red Hat with the goal of ensuring RHIVOS ships with a powerful Virtualization stack. While there’s a large overlap between a Virtualization stack for Servers and the one for Automotive platforms, the latter is much more demanding on one particular aspect: GPU acceleration.

For me, personally, that meant having to delve into the Linux graphics stack, both kernel (DRM, GEM, KMS…) and userspace (Mesa, virglrenderer…), something in which, so far, I only had a superficial knowledge. And, when facing a new field, my preferred approach is looking for an interesting project that would both motivate me to play with those software components.

There’s this interesting idea of adding support for running Wasm/WASI payloads in libkrun, which is something we could easily achieve by simply embedding a Wasm runtime, statically built for Linux, into initrd.

Now, the problem with this approach is that, despite having a payload (the Wasm runtime) with a well-known behavior, we would still be using a (built with a minimal config, but otherwise complete) Linux kernel, despite only needed a small amount of its functionality. In other words, the workload’s TCB would not be optimal.

Sometimes, while working on macOS, you may find the need to test something quick on Linux, or use some utility that’s only available on this OS. But, of course, you don’t want to go through all the process of creating the VM from scratch.

The good news is, you don’t need to! Using krunvm you can create and start a microVM from a regular container image (that is, an OCI image), in just two commands and a couple of seconds.

Are you feeling adventurous today? Good, so let’s give a try to some of the coolest upcoming technologies.

• podman is a tool for managing containers. If you’re familiar with docker, you’ll find it’s CLI quite similar. RHEL8 will include podman as part of the container-tools module.

• Kata Containers is an OCI Runtime which runs containerized processes inside a VM, using QEMU+KVM. This gives you the versatility of containers, with the isolation of a VM, among other nice features like static resource management and PCI passthru. Kata is not included nor supported by RHEL8, but I hope it’ll eventually make into some minor release.