Vanilla OS 2: an immutable distribution to run all software

Vanilla OS, an immutable desktop Linux distribution designed for developers and advanced users, has recently published its 2.0 "Orchid" release. Previously based on Ubuntu, Vanilla OS has now shifted to Debian unstable ("sid"). The release has made it easier to install software from other distributions' package repositories, and it is now theoretically possible to install and run Android applications as well.

The idea behind Vanilla OS is to maintain a small, immutable core operating system while isolating additional software from that core through containerization or sandboxing. The core of Vanilla OS is based on Open Container Initiative (OCI) images composed of packages from Debian sid. These images are updated and managed by the ABRoot utility. Rather than handling system updates through a package manager, Vanilla OS downloads a new OCI image, and then uses the new image when it reboots. This is similar to other image-based operating systems, like Aeon and Bluefin that use A/B image update strategies—though each distribution has its own method of doing so. All of this happens under the hood, so users don't have to be aware of how updates work.

One of the reasons that Vanilla OS shifted from Ubuntu to Debian was that the latter offers a more vanilla GNOME experience by providing the software without significant customizations. As the project's announcement from last year said:

Ubuntu provides a modified version of the GNOME desktop, that does not match how GNOME envisions its desktop. One of the high-level goals of Vanilla OS is to be as vanilla as possible, so we reverted many of these changes to reach that goal.

Another concern cited in the announcement was Ubuntu's reliance on the Snap packaging format, with problems like slow startups and Canonical's control over the official Snap store.

Installing the system and applications

The project offers an ISO image for x86-64 systems, with no support for other architectures. Only UEFI systems are supported, and even on those systems, the installer seems quite finicky. On two physical test machines, the installer seemed to run fine until it aborted with a generic error message. I managed to install Vanilla OS in a virtual machine (using GNOME Boxes) only after selecting Debian testing as the operating system (and choosing UEFI, of course).

When the installer works, it is straightforward to use. After the first reboot, a configuration wizard guides the user through creating an account and selecting applications to install. After a second reboot, the user is prompted to choose a password, followed by the installation of the selected applications using Flatpak.

Upon installation of these applications, a stock GNOME desktop environment appears. The recommended way to install applications in Vanilla OS is through the GNOME application Software, which is configured to install applications as Flatpaks from Flathub. By default, Flatpaks installed this way are updated automatically. Vanilla OS also checks for system updates weekly, by default. Users can change this to daily, weekly, or never if they choose. To minimize any impact on the user experience, the updater considers factors such as system load, battery level, and network connection before applying system updates. With the core operating system and applications set for automatic updates, Vanilla OS aims to relieve users of the often tedious task of keeping all packages updated.

Installing non-Flatpak packages

Although Flatpak has gained popularity, many applications are still not available as Flatpaks. Given that Vanilla OS is based on Debian, users might be tempted to install a .deb package directly into the core operating system when there's no Flatpak version for it. However, Vanilla OS doesn't offer that possibility. It addresses the need for Debian packages with the Vanilla System Operator (VSO v2), a container where users can safely install any .deb package.

VSO integrates software installed in a container with the desktop so that it appears just like any other desktop application. After downloading a .deb package, double-clicking on the file in the GNOME Files application launches the Sideload utility, which installs the .deb package into the VSO container. Once installed, the application is displayed among other applications in GNOME's activities overview. Launching the application runs it in a container, isolated from the operating system but integrated with the user's home directory. Thus, an application installed via a .deb package behaves similarly to one installed via Flatpak.

There's also a command-line method for installing .deb files. The default terminal emulator in Vanilla OS is Black Box. When launched, this application takes the user to a shell within the VSO container rather than the core operating system. Packages can be installed in this container using Debian's apt package manager.

This method is also useful for troubleshooting dependency issues. For instance, I decided to install an open-source ChatGPT alternative called Jan on Vanilla OS. When I attempted to install its .deb package with Sideload, the application failed to start without any clear indication of what was wrong. Opening Black Box and running the jan command in the shell revealed an error message regarding a missing library: libasound2.so. It turned out that Jan's .deb package didn't list this library as a dependency. After executing sudo apt install libasound2 in Black Box, I was able to run Jan successfully.

Vanilla OS offers a similar method for installing Android apps by running them in a Waydroid container. However, the developers caution that this is still an experimental feature. I was able to initialize the Android subsystem with vso android init in the VSO shell but encountered issues when trying to manually open an Android .apk file with Sideload. Despite several troubleshooting attempts, I was unable to get the Android functionality running. This was possibly due to my test system running in a virtual machine, a scenario that the project has not tested.

Linux subsystems

While VSO is the default container in Vanilla OS, the operating system allows users to install separate "subsystems" based on various Linux distributions through Apx, a wrapper around Distrobox. The latter, in turn, is a wrapper around Podman, Docker, or the simple container manager lilipod to create containers that are highly integrated with the host operating system. Incidentally, Luca Di Maio, the creator of Distrobox and lilipod, is also part of the Vanilla OS team and one of its co-founders.

Vanilla OS includes a graphical user interface for Apx, enabling users to easily create a subsystem based on a stack (Alpine, Arch Linux, Fedora, openSUSE, Ubuntu, and Vanilla OS are supported by default) and a package manager (apk, apt, dnf, pacman, or zypper). After creating and starting the subsystem, the user can search its packages and install them using commands in the VSO shell, such as:

    apx gecko search qucs
    apx gecko install qucs-s

Here gecko is the name I gave to the subsystem in this example, based on an openSUSE container.

Applications installed this way are "exported", which is a feature of Distrobox. The application then appears in GNOME's activities overview. When clicking on the icon, the subsystem's container is automatically started, and the application launches. This provides an easy way to install software available in specific distribution repositories. Furthermore, the apx package management commands are consistent, regardless of the underlying package manager, so users don't need to remember the differences between apt, dnf, or zypper, for example.

Apx offers a lot of flexibility. Users can add other package managers, such as yay instead of pacman for an Arch Linux subsystem. This involves mapping each apx package management command to the corresponding yay command. Similarly, users can create their own stack by referencing an image from one of the well-known container repositories. A stack can also have a list of pre-installed packages. This is useful for setting up a complete development stack in a container.

Development and documentation

Development is happening in the Vanilla OS GitHub organization, which has 24 members. Its more than 100 repositories include numerous container files and various custom tools. Although many of these tools were specifically created for Vanilla OS, the developers try to make them as distribution-independent as possible. For instance, there are instructions for using Apx in other distributions.

There's no fixed release cadence, but the lifecycle of Vanilla OS is clear: when a major version is released, the previous major release enters the maintenance state. This means that it only gets important bug fixes and security fixes. After six months in the maintenance state, the release is declared end of life. Updates are released at irregular intervals with detailed descriptions of bug fixes and enhancements. The project does not have a separate security-announcement list.

The transition from Vanilla OS 1 to 2 was significant, not only due to the shift from an Ubuntu base to Debian, but also because tools like ABRoot, VSO, and Apx were completely rewritten. However, the Vanilla OS documentation site still primarily covers ABRoot v1, VSO v1, and Apx v1. While the man pages seem to have been updated, information about the new features in Vanilla OS 2 remains fragmented, scattered across the project's web site, blog, and GitHub repositories.

Overall, Vanilla OS appears to be a good choice for advanced users who need applications from multiple distributions without risking system instability. Major applications can be easily installed as Flatpaks, while others can be installed in subsystems from various distributions. Thanks to the tight integration of the VSO and Apx containers with the host operating system, users can seamlessly work with all those applications without worrying about the underlying differences. And when something goes wrong with one of the applications, the core operating system isn't impacted and the VSO or Apx container can simply be recreated.