I’ve been using Fedora Silverblue as my daily driver for a while now. Over time, I’ve fully adopted Flatpak, which I really enjoy using alongside Flatseal. I particularly appreciate how Flatpak gives each application its own isolated directory structure, making backups incredibly straightforward. However, I eventually hit a wall when it came to proprietary GPU drivers for workloads like media decoding, 3D rendering, and running local LLMs. In these scenarios, Flatpak’s runtime abstraction can sometimes become a liability. While this can sometimes be solved by enabling the Flathub repository or installing custom packages, I wanted to avoid that route. After comparing various alternatives, I decided to write my own lightweight application launcher. The Problem Flatpak achieves portability by bundling apps inside standardized runtime environments (like the Freedesktop or GNOME runtimes). While this solves the “dependency hell” of the 2000s, it introduces a subtle friction point for he...
In Part 2 , I got a basic proof-of-concept running: a single headless microVM booting a minimal Debian kernel and forwarding Firefox back to my daily-driver desktop (“Viewer VM”) over VSOCK using Waypipe and PipeWire. It proved the concept, but it was essentially a static, single-instance test rig. To actually live in this setup like I used to in Qubes OS, I needed to turn this prototype into a scalable, multi-domain system. In this post, I’ll walk through the next iteration of the architecture: building a centralized VM lifecycle manager, isolating VMs under dedicated host users, scaling dynamic TAP networks, and running the Waypipe viewer inside a confined nested compositor container. 1. Domain Modeling & Host VM Management In Qubes OS, workloads are categorized into Disposable VMs (DispVMs) for ephemeral tasks and AppVMs for persistent user data, both derived from centralized Template VMs . While Qubes relies on Template VMs to maintain packages across domains, I chose ...