At the end of part 1 we had a clean Amiga 500, both in the inside and the outside, which we couldn’t test because the power supply that came with it was broken.
With a brand new power supply here, it’s time to find out what it works and what it doesn’t.
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.
