Open source desktop: the ideas to finally modernize it

A package update broke my graphical environment at 11 p.m. on a Tuesday, and I spent the night in a TTY reading logs. If you've used Linux on the desktop for a few years, you probably have a similar story. LWN published a piece with ideas to modernize the open source desktop, and the question underneath it is exactly this: how do you build a system that doesn't break when all you wanted was to update your browser?

I'll go over what's being discussed, why it matters for developers and what changes in practice.

What modernizing the open source desktop means

The classic Linux distro model is decades old. A package manager installs everything into a single shared file system. The app, the system library and the kernel all sit in the same bucket. Updating one thing can touch another.

That model worked well for servers and for people who know how to fix their own system. For regular people, and even for devs who just want to get work done, it comes at a high cost.

The modernization conversation revolves around a few areas that have been in motion for years:

• Immutable base system: the system root is read-only and gets updated as a whole image. Something went wrong? You boot back into the previous version.
• Isolated apps: applications run in a sandbox with explicit permissions, and they come in a format shared across distros, like Flatpak.
• Portals: instead of the app reading the whole disk, it asks the system to "open a file picker" and gets only what the user chose.
• Wayland by default: X11 is on its way out. GNOME has already dropped the X11 session as the default, and KDE also has a date to stop maintaining it.

None of this is new on its own. Fedora Silverblue has been around since 2018. Flathub became the de facto store for a lot of people. What changed is that the pieces finally seem ready to become the normal way to use Linux, not an experiment for enthusiasts.

Why the old model started to weigh us down

The core problem is coupling. When every app depends on the libraries the distro packaged, each distro becomes a different target. If you maintain a desktop app, you need to test on Ubuntu, Fedora, Arch, Debian stable and half a dozen more. In practice, nobody tests, and the user finds the bug.

Here's an example every frontend dev will get: imagine your project's node_modules was shared with every other project on your machine. Updating React in one project would update it in all of them. Sounds absurd, right? Well, that's roughly how the traditional Linux desktop treats system libraries.

A system you're afraid to update is already broken. It just hasn't told you yet.

The second burden is security. In the old model, any app you install can read your ~/.ssh, your tokens in ~/.config and your browser history. After so many supply chain attacks on npm and PyPI packages, blindly trusting every binary on your machine got hard to defend.

What changes for people building desktop apps

If you ship an app for Linux, whether it's Electron, Tauri or native GTK or Qt, the direction is clear: package once, run on any distro, ask permission for what you need.

A simple Flatpak manifest already shows the shift in mindset:

app-id: dev.horvatti.MyApp
runtime: org.freedesktop.Platform
runtime-version: '24.08'
sdk: org.freedesktop.Sdk
command: my-app
finish-args:
  - --share=network
  - --socket=wayland
  - --socket=fallback-x11
  - --device=dri

Look at finish-args. You declare what the app needs. Network, yes. Access to the entire home folder, no. If the app needs to open a file, it uses the file picker portal, and the system hands over just that file.

In practice, this changes three things in your code:

1. Hardcoded paths stop working. That fs.readFileSync(os.homedir() + '/Documents/config.json') will fail inside the sandbox. Use your framework's file dialog. In recent Electron and Tauri versions, it already goes through the portal.
2. Wayland stops being optional. Screen capture, global shortcuts and window positioning work differently. If your app relies on "grabbing the whole screen", it needs to use the screencast portal.
3. Updates become the format's job. You publish on Flathub and updates reach users without you writing an auto-updater.

That third point alone saves work. Anyone who has written an updater for Electron knows how painful it is.

Does an immutable system work for developers?

This is the objection I hear most. "I need to install compilers, databases, Docker, a specific Node version. An immutable system will lock me in."

The short answer: it won't lock you in, but it changes where things live. The base system stays untouched and your development environment moves into a container. Tools like Toolbx and Distrobox create a container with whatever distro you want, integrated with your home folder and your terminal.

distrobox create --name dev --image fedora:latest
distrobox enter dev
sudo dnf install postgresql nodejs

Inside the container, you can make whatever mess you want. Broke it? Delete it and create a new one in a minute. The system that gives you your desktop keeps working.

I've been using a variation of this for a while, and the real gain is psychological: I stopped being afraid to try things. That's worth more than it sounds. There is a cost. There's a learning curve, some tools that touch hardware get annoying to set up and the first day is a bit confusing. But you only pay that cost once.

What's still not solved

It would be dishonest to sell this as a finished solution. There are real weak spots.

Badly declared permissions. Lots of apps on Flathub ask for --filesystem=home because it's less work than using portals. Then the sandbox becomes decoration. The model only protects you if maintainers do their part, and today many don't.

Disk space and duplication. Each Flatpak runtime brings its own libraries. Deduplication helps, but on a machine with a small SSD you feel it.

Format fragmentation. Flatpak, Snap and AppImage are still competing. For people shipping apps, that means picking a side or maintaining three pipelines. My take: Flatpak won on the desktop outside Ubuntu, and fighting that is a waste of time.

Accessibility and older tools on Wayland. Screen readers, UI automation and utilities that relied on X11 letting any program peek at any window are still adapting. For some users this isn't a detail. It's what keeps them from switching.

My take on where the open source desktop is heading

I think the direction is right, and it took too long. The Linux desktop spent years optimizing for the user who can fix everything, and that audience was never big enough to sustain an app ecosystem.

The shift that matters to me isn't technical. It's about responsibility. In the new model, the distro takes care of the system, the dev takes care of the app and the user chooses what each app can access. Everyone stays in their lane. It's the same design that made phones usable for billions of people, only with open source code and without a company deciding what you're allowed to install.

If you maintain a desktop app, the practical advice is simple: package it as a Flatpak, stop assuming access to the home folder and test on Wayland before your users test it for you. And if you use Linux for work, try an immutable distro with a dev container. Worst case, you go back to the old model. Best case, you never spend another Tuesday night in a TTY.

If you want to see how I apply these ideas day to day, take a look at the projects I maintain.

A package update once cost me a whole night in a TTY reading logs. And the problem wasn't the package. It was the model.

On the traditional Linux desktop, the app, the libraries and the system all share the same space. Updating one thing can break another.

The fix that's finally maturing: an immutable base system with rollback, apps isolated in Flatpak and permissions requested through portals.

For developers, this doesn't lock anything down. Your dev environment moves into a container with Distrobox. If it breaks, you delete it and spin up a new one in a minute.

If you maintain a desktop app: package it as a Flatpak, stop assuming access to the home folder and test on Wayland before your users test it for you.

A system you're afraid to update is already broken. It just hasn't told you yet.

I wrote more about this on the blog. The link is in the comments.

#Linux #OpenSource #Flatpak #SoftwareDevelopment #DevExperience