Acclerating Ubuntu Core Desktop

Table of ContentsThree initial target use casesThe browser-centric machine

The developer workstation

The gaming machine

Key challengesApplication availability

Modularising the desktop

Permissions prompting

Partnering with enioka Haute Couture

Next steps

Summary

Ubuntu Core Desktop is Canonical’s (currently unreleased) immutable and attestable Linux desktop. It represents the most fundamental shift in Ubuntu’s desktop architecture to date, and will mature into the default experience for Ubuntu Desktop over time.

Ubuntu Core is Canonical’s “immutable Linux” distribution, and has been deployed in numerous commercial IoT, embedded and robotics platforms for almost ten years. Canonical announced a developer preview of Core Desktop in 2023, but the project has since been dormant. I’m thrilled to announce that the development of Ubuntu Core Desktop has restarted with a dedicated, cross-functional team working toward three well-defined initial use cases.

I’ve written previously about “immutable” Linux distributions, what they’re trying to achieve and where the promises are often broken. Ubuntu Core moves to everything as a snap - including the bootloader, the kernel, the desktop environment, userspace daemons and all of your apps. For users, this means a desktop that’s harder to break, easier to recover and more adaptable to different devices and workflows. It also gives users greater control over the data their applications can access.

Our 2023 preview fell short of this vision. While it helped us better understand the problems we’d face, it bundled much of the desktop into a single alternative base snap. Separating those components is one of our top priorities as we restart the project.

With this transition comes the promise of greater resilience, better security, more composability, but also more engineering complexity. In this post I’ll outline the vision, roadmap, and some of the complexities we hope to tackle.

People around the world use Ubuntu in many different ways, but over the coming cycle we’re going to focus on three key use cases for Ubuntu Core Desktop. These are by no means exhaustive, but will stretch our implementation in different ways, helping us to validate assumptions and implementation work.

Many personal and professional workflows today are satisfied almost entirely by the presence of a modern, competent browser. The rapid rise of web applications (and toolkits like Electron) was the catalyst that enabled many Linux enthusiasts to use Linux full-time in their professional lives.

I expect this use case to be the easiest and quickest to deliver. Much of this work was already complete in the last developer preview back in 2023 through the inclusion of Mozilla Firefox, and the availability of the Chromium snap.

Since then, work has been done on permissions prompting (more on that later…) to enable controlled access to the user’s camera and microphone, and we’ve been shipping Firefox and Chromium as snaps by default in Ubuntu for a number of years - these snaps are feature-rich, stable and reliable.

This might seem like one of the more complex cases to solve, since Ubuntu Core eschews many of the filesystem and permission norms that developers have become accustomed to. However, LXD (our next-generation system container and virtual machine manager) works just fine on Ubuntu Core, and Canonical Workshop builds on that.

Canonical Workshop provides the means for tailored, sandboxed development environments. Combine Canonical Workshop with its companion Visual Studio Code Extension and most developers have all they need to work on projects in any language with any toolchain.

This is how I’ve personally driven my development workflows for some years. Over time I’ve used Docker containers, Multipass VMs, LXD containers and more recently Canonical Workshops to keep my development environments isolated from my machine and shareable with others. This way of working comes with very little overhead and promises less divergence between developer machines, less toil on your workstation and a safe place to experiment.

There are many parallels here with how developers are finding ways to sandbox the various coding agents they are using. As coding agents gain popularity and more capability, isolating them from your host system becomes increasingly important to protect your credentials, sensitive files and personal information. Canonical already provides SDKs for many popular coding agents, and pushing developers toward development sandboxes with Workshops encourages them to detach their agents from their machines.

Today Canonical Workshop is distributed as a classic snap, but we have work underway and promising early results to move to strict confinement in the coming weeks, opening the door for this workflow. Visual Studio Code is also distributed as a classic snap - my hope is to make running it from within a workshop seamless, while we invest in a strictly confined option.

Gaming handheld machines like the Steam Deck and the Lenovo Legion Go have become increasingly popular, while the monumental amount of work that Valve has put into Proton has transformed game compatibility on Linux.

At Canonical, we’ve been maintaining the Steam snap for some time. Being strictly confined, it satisfies the confinement requirements for Ubuntu Core.

Game compatibility with Proton is dictated by a range of factors, and can sometimes mean users need to run different versions of Proton itself, experimental or tweaked versions of Mesa and varying hardware device drivers depending on the game and hardware in question. On a traditional Linux system this can be fraught with danger - a wrong move here could render a device unbootable, or have negative consequences for other applications on the device.

I want Ubuntu Core Desktop’s modular architecture to enable a more resilient and independently updatable gaming stack, including graphics components. Making that work reliably across games and hardware without destabilising the underlying system will be a complex task. The ability to compose snaps together, utilising ideas such as “content snaps” and snap components, enable us to be more agile in the distribution and integration of drivers across varying hardware and architectures than in other image-based approaches.

The Steam snap and its surrounding infrastructure haven’t had as much attention as I’d have liked over the past two years, mostly due to the same resource constraints that were preventing the Ubuntu Core Desktop project itself from progressing, but we’re now in a position to address that.

Developing Ubuntu Core Desktop for gaming devices gives us a chance to consider the general UX of the machine. In the case of a dedicated gaming device, booting directly into a traditional desktop environment might not be the best choice. This is a compelling reason to explore different modes of operation beyond the traditional workstation experience.

There will be many challenges along the way! Most of these stem from the fact that Ubuntu Core requires that all applications/services be packaged as strictly confined snaps. This immediately presents two challenges: making applications compatible with strict confinement, and ensuring sufficient availability of applications on the platform.

As I write this, there are over 11,000 snaps published in the Snap Store, the majority of which are compatible with Ubuntu Core. Others, particularly those using classic confinement, will need additional work to integrate into Core Desktop.

I do intend to build an ergonomic experience for those who want to use classic snaps on Ubuntu Core Desktop. Some popular applications, including Visual Studio Code, are packaged as classic snaps and cannot run directly on Ubuntu Core. There are a few approaches we could take here, but my current preferred idea is to make it easy to run graphical applications inside a Workshop, while presenting their windows on the host desktop - similar to the approach taken with WSLg.

The same is true for users who wish to use applications from alternative package managers such as apt, nix, flatpak and others - the advice will be to lean into our native primitives for virtualisation and containerisation, and the integrations we’ll build to make this ergonomic for desktop applications.

The biggest shortcoming of the 2023 developer preview was its architecture. The system used a modified base snap - swapping core22 for an alternative base snap that contained much of the desktop environment.

This alternate core snap was monolithic: it contained GDM, the GNOME desktop and even Firefox itself in early versions. This approach breaks many of the promises and goals of Ubuntu Core Desktop. It did enable the team to release what looked like a working PoC quickly, and this is what we’ve been working on for the past few weeks.

We want to build a modular desktop architecture that defines clear interfaces between components. Components such as the display manager, desktop environment, multimedia servers, networking and other core capabilities should adhere to well-defined interfaces and remain implementation agnostic.

The result will be a desktop whose constituent parts can evolve independently, without forcing the rebuild of the entire operating system image every time something changes - one of the key differentiators from other immutable operating system implementations.

Another key issue is troubleshooting and managing security confinement for apps that already are strictly confined. Application confinement is a moving target, and often packagers either aren’t able, or shouldn’t be able to make decisions on an end-user’s behalf about what an application gets access to on their machine.

This is why we built permissions prompting, one of the most technical and cross-team initiatives for Ubuntu in Canonical’s recent past. Prompting differs from any previous effort (like portals, for example) because it doesn’t require applications to be modified to benefit from the framework. Permissions prompting orchestrates a complex conversation between the kernel, AppArmor and snapd, operating at the syscall level. As a result, the framework is generic and can be applied to many different application behaviours. At the time of writing, we’ve wired up a nice user experience for camera, microphone and home directory access, but the scope will be much broader.

I firmly believe that a resilient and understandable prompting system is the key to Ubuntu Core’s success. Most users will be somewhat conditioned to this workflow from their Android or iOS phones.

Prompting enables packagers to express the intent of their applications, while giving users more control over what those applications can access on their machines. Not all users have the same threat model or circumstances, and we must be mindful of that.

During the initial work on our own Core Desktop, we worked with the KDE Neon Core team and enioka Haute Couture to bring a variant of KDE Neon based on Ubuntu Core. To their credit, the team has been pushing us ever since we wrapped up the project to get started again, and I’m very pleased that we are once again partnering with them.

The KDE team has a long and well-earned track record for delivering high-quality snaps for KDE applications, the Qt toolkit and more. Partnering with them will keep us honest on the modularity promises of Ubuntu Core Desktop, and I aim to have them as integrated with our team as we can mutually achieve.

Ubuntu Core Desktop should not be limited to the GNOME ecosystem - it should be a platform for desktop environments and experiences of all shapes and sizes. The Ubuntu flavours have a huge following because they offer users choice, and I don’