The Ubuntu Lovers' Blues

I upgraded to Ubuntu 26.04 LTS recently, the first jump I’d made since 24.04, sticking to LTS releases the way I always have. Within days I was fighting AppArmor denials in my logs, snaps behaving differently to their .deb equivalents for no obvious reason, and the general low-grade friction of debugging the packaging layer instead of the software I actually wanted to run. I’d already documented one of these fights in public: getting Zoom’s camera working again on Wayland meant ripping the Snap out entirely and installing Mozilla’s own .deb instead, because the sandbox was standing between the app and the hardware and no amount of granted permissions fixed it.

So I asked Reddit why Canonical was still pushing this so hard, expecting the usual “snaps are great” and “flatpaks also suck” one-liners that make up most of that debate. Mostly, I got exactly that. But two replies, from a longtime Ubuntu community member posting as u/jo-erlend, and a more measured one from u/tomscharbach, were worth taking seriously enough to go and check against the actual history rather than leave sitting in a comment thread.

This isn’t a rebuttal of either of them, and it isn’t a “why I’m leaving Ubuntu” post. I’m not leaving. I want this to keep working. It’s a look at what’s actually true in the case for Snap on the desktop specifically, not on Ubuntu Core or IoT, where I think Canonical’s approach has been genuinely good, and what that leaves someone like me, a developer who lives on this desktop daily rather than someone who packages software for a living, to actually do about it.

The Part jo-erlend Is Right About

Strip the rhetoric out of jo-erlend’s longest comment and there’s a real argument underneath it. Debian, and by extension dpkg, was designed in 1993 on a total-trust model: every package gets to do whatever it wants to your system, because the kernel had no other way to let it work. That’s not exaggeration. The Linux Security Modules framework that makes application confinement possible didn’t start development until around 2001 and wasn’t merged into the mainline kernel until version 2.6 in December 2003, a full decade after Debian’s founding. AppArmor specifically, the confinement mechanism Snap and Ubuntu actually use, wasn’t merged into the mainline kernel until version 2.6.36 in October 2010. Debian’s packaging model was frozen in amber before the tools to do anything else even existed.

That total-trust design has a real cost today that it didn’t have in 1993. Every third-party repository and PPA you add is, by design, granting whoever controls it full root access to your machine, because dpkg has no concept of a package that isn’t fully trusted. In a world with more cyberattacks and more supply-chain compromises every year, that’s a genuinely dangerous default to still be shipping as the norm, and it’s a fair critique regardless of what you think of Canonical’s specific fix.

tomscharbach’s reply filled in the architectural picture: Canonical isn’t trying to solve this only for desktop apps. Ubuntu Core, the base for the fully containerised, immutable version of Ubuntu that Canonical wants the desktop to eventually become, has been running in IoT deployments since 2014, and every layer of it, kernel included, is a snap. I know that timeline first-hand: 2015 is the year I was testing Snappy Core on IoT devices myself, the same year I imported a Meizu MX4 to run Ubuntu Touch as my daily phone (more on how that went below). His dates were slightly off, the architecture traces to Click packages built for Ubuntu Touch around 2013, with Snappy Ubuntu Core itself announced on 9 December 2014, and Snap didn’t arrive on the desktop until Ubuntu 16.04 in April 2016, but the shape of what he described is accurate, and it’s the same shape I was standing inside of a decade ago. It worked well there then, and by every account I’ve read since, it still does; the friction in the rest of this post starts precisely where that same model meets the desktop. Flatpak was never built to do this. It packages applications. Snap, as designed, is meant to be compared to APT and RPM, not to Flatpak, because it’s trying to replace the whole distribution model, not just the app layer.

Where “The Way of the Future” Falls Apart

That’s the strongest version of the argument, and it’s worth taking seriously. What doesn’t hold up is the leap from “the architecture is sound” to “resistance to it is nostalgia,” which is roughly where jo-erlend lands.

His claim that Snap is “the opposite of vendor specific” because anyone can run their own store is true in theory and irrelevant in practice, and another commenter, u/catbrane, caught it directly: snapd is hardcoded to Canonical’s store, and that store is closed-source. Nobody runs a real alternative. A Debian repository, by contrast, is something anyone can stand up today with a text file and apt. Nitrokey, building an open-hardware home server, documented exactly what that closedness costs in practice: publishing a snap that touches hardware interfaces like GPIO or I2C requires a Canonical “Brand Store” at a reported US$30,000 a year, with no free tier for non-commercial projects, and the advertised “10 years of security updates” turning out to mean five free, five paid. That’s not decentralisation. That’s a toll booth with an open API sitting behind it. None of that is a knock on Ubuntu Core’s technical merits on embedded hardware, it’s a knock on who controls the shelf, and the same gate stands in front of anyone publishing a desktop snap too.

His other move, that you can just unconfine a snap and it becomes equivalent to a .deb, doesn’t survive contact with how the system actually works either. u/Oliv_3 pointed out that classic and devmode snaps aren’t something a user can just flip on, --classic only works when the publisher built it that way, and even then the artefact stays a mounted SquashFS with its own revision and update model. It’s not the same thing wearing a looser belt. It’s a structurally different install with a different failure mode, which is exactly what I hit with Zoom’s camera: correctly granted permissions, and the sandbox still stood between the app and the hardware.

And Zoom’s camera wasn’t a one-off. I run an Ansible playbook across my own desktops, and its git history reads like a log of the same failure recurring under different names. Slack’s snap started throwing AppArmor /etc/ denials and seccomp io_uring blocks under 26.04, replaced with the native .deb. Obsidian’s classic snap runs a desktop-gnome-specific.sh script at launch that stopped working against 26.04’s GNOME stack, replaced with the native .deb. OrcaSlicer’s snap simply isn’t published for 26.04 at all, replaced with the upstream AppImage. The freshest one landed the day before I posted to Reddit: adding a Linux desktop build target to a Flutter app failed at the link step with undefined reference to 'g_task_set_static_name', because the Flutter snap bundles GTK3 and GLib frozen at core20, GLib 2.64 from 2020, while a plugin needing the system’s libsecret pulled in the host’s GLib 2.88 instead. Forcing the build to prefer system libraries didn’t fix it, it surfaced roughly eighty more undefined references spanning GLIBC 2.32 through 2.43, because the snap’s entire bundled toolchain was that far behind the host. The fix was the same one every time: stop using the snap. None of this is universal, the same machines still run nineteen other apps happily as snaps without a single issue. It’s specifically that the moment an app needs to reach past its own bundled sandbox, a system library, a desktop-integration script, a syscall filter, the working fix on record is always subtraction.

That’s the technical failure mode. There’s a separate, strategic one: apt quietly offering less, regardless of whether the snap it steers you toward even works. I hit this myself troubleshooting a flipped image on a USB webcam, cheese was the obvious tool, and apt install cheese on 26.04 just tells you to run snap install cheese instead, there’s no .deb left at all. Firefox and Chromium made that same move years ago. Thunderbird followed in 24.04. None of those apps broke the way Slack or Flutter did, they were simply removed from apt outright. That’s not a bug, it’s a policy, and jo-erlend’s “you don’t have to use Snap” gets less true every time it runs.

This Isn’t My First Rodeo With Canonical’s Big Bets

I’ve been here before, and it’s worth saying so plainly rather than pretending this is a fresh grievance. That Meizu MX4 experiment is one I wrote up at the time: genuinely excited about the vision, real technical merit, responsive developers who shipped a missing feature within days of me asking on Reddit, and still not ready for daily use. I closed that post with “I still hope to settle there eventually.”

Convergence never arrived. In April 2017, Canonical killed Unity 8, Mir, and the phone project outright, and Mark Shuttleworth said so without much hedging: neither the free software community nor the industry had wanted it the way he’d hoped, and Canonical was pivoting to cloud and IoT instead. It’s a call that’s easy to respect in hindsight, a founder who’d bankrolled the bet personally for years choosing to cut it cleanly rather than let it limp on half-funded, and saying so in public rather than quietly starving it of resources. That pivot is the direct ancestor of the Snap strategy I’m writing about now. Same company, same underlying instinct to bet everything on one unifying architecture, same eventual reckoning with whether anyone else actually wanted it.

That history cuts both ways. It’s why I don’t think the answer here is to leave. Canonical has form for admitting a bet didn’t land and changing course without the company falling apart, which is precisely what my original post asked about. But it’s also why “trust the roadmap” isn’t quite enough on its own anymore. I did that in 2015 too.

Where Canonical’s Own Timeline Actually Stands

Because I didn’t want to keep arguing from Reddit threads, I went and read what Canonical itself has said about where this is going, and how it’s tracked against what they’ve actually shipped.

In May 2023, Canonical’s own blog described Ubuntu Core Desktop’s arrival as “in due course, when we think the entire system can be delivered this way,” with no date attached, and admitted plainly that “snaps are a little famous for having some rough edges on the desktop.” It was hoped for 24.04. It missed that. It missed 24.10 too. By November 2024, a Canonical engineering director was telling The Register that working builds existed internally but real integration problems, like switching kernel update tracks or installing an alternative desktop environment, were still unsolved, and offered no firm date. As of 26.04, the release I’m actually running, the official roadmap language is still “helps pave the way for Ubuntu Core Desktop,” not “here it is.” Mark Shuttleworth was already describing an all-snap desktop as a “long-term vision” that might happen “in a very distant future” back in 2017. Nine years on, distant is still the operative word.

And the specific complaint that started my post, apt quietly resolving to a snap install, isn’t new either. Linux Mint blocked Snap by default in 2020, for the exact same reason: apt install chromium on Ubuntu 20.04 was silently handing back a snap instead of a package. That’s six years of the same unresolved bait and switch, just with a different app name each time.

A Real Look at the Options, Because I Actually Looked

Every option below is, in its own way, a different answer to the same question Snap, Flatpak, and Nix are all trying to answer: how do you stack unrelated things on top of each other without them crushing what’s underneath. My first instinct, and I suspect a lot of people’s, is to just go back to Debian and be done with it. Having actually checked, that’s not the long-term answer it feels like in the moment.

Debian removes Canonical’s specific implementation of the problem without removing the problem. Debian 13 (“trixie”) ships Firefox ESR by default, and a plain apt install firefox fails outright unless you add Mozilla’s own repository or reach for Flatpak. Flatpak isn’t installed by default either. So “switch to Debian, avoid the snap headache” quietly becomes “switch to Debian, then add Flatpak for anything current,” the same third-party distribution problem Snap exists to solve, just relocated, and it does nothing at all for the dpkg trust model I actually agree is the deeper issue.

Fedora Workstation is the strongest existing answer to “I don’t see a long-term option,” because it isn’t hypothetical. It ships today: SELinux confinement on the base system, and Flatpak with Flathub pre-wired into GNOME Software’s first-run setup as the sanctioned way to get third-party and fast-moving apps. It’s what Snap claims to be building toward, already built, by a different vendor, with actual industry backing behind it via Red Hat.

openSUSE Aeon and Kalpa, the GNOME and Plasma spins of what used to be MicroOS Desktop, are a second working proof rather than a hypothetical: an immutable base, atomic snapshot updates, Flatpak for everything on top. Aeon is at release-candidate stage as I write this, Kalpa is a step behind at alpha, but both ship live snapshot builds monthly. A smaller project than Canonical has already built the thing Ubuntu Core Desktop has been “paving the way” toward since 2023.

Stripping Snap out of Ubuntu and staying put works today, several people in that Reddit thread already do it, but it’s a rear-guard action you’ll have to refight every release as more packages get pulled from apt, and you’ll likely end up installing Flatpak anyway for whatever’s missing.

NixOS, which I’d rather seriously consider than Arch, answers a genuinely different half of jo-erlend’s complaint better than anything else on this list. Its store is content-addressed by the hash of a package’s full dependency tree, so installs are reproducible byte for byte, upgrades apply as new atomic generations that either fully succeed or roll back instantly, and the “system left half-broken mid-upgrade” failure mode that dpkg’s sequential, single-threaded model allows for basically doesn’t exist. What it doesn’t do is runtime confinement. Nix’s sandboxing isolates the build process, not the running application against your files and network the way AppArmor or Flatpak’s portals do. It solves the integrity half of the 1993 problem about as rigorously as anything currently shipping. It doesn’t touch the security-confinement half at all.

Line them up and there’s a pattern worth naming plainly: every route off Ubuntu converges on Flatpak, or on a fundamentally different model like Nix’s. Debian needs Flatpak to stay current. Fedora ships Flatpak as the default. openSUSE is built entirely on it. The only path that gets you Snap instead of Flatpak is staying exactly where you already are. That’s not two ecosystems in a fair fight. The rest of the ecosystem has already picked, and Snap’s isolation from it is Canonical holding its own course, not a live contest it’s still plausibly winning.

What I’d Actually Ask For

Not a farewell, then. A plea, made from someone who wants to keep using this system, and who has form for hoping Canonical gets there eventually because I’ve watched them get there before.

Three things, all specific, none of them “become a different company”:

Stop the silent substitution. If apt install cheese is going to hand someone a snap, say so before it happens, don’t let people discover it mid-command the way Mint’s users did in 2020 and I did in 2026.

Open the store, or stop describing it as open. An API anyone could theoretically implement isn’t decentralisation while snapd is hardcoded to one closed-source backend with a US$30,000 toll gate behind it for anyone who wants real independence.

Commit to a date, or stop implying one. “In due course” has now outlasted an entire LTS cycle. Say when Core Desktop actually ships, or say clearly that it’s a decade-plus bet the way the all-snap desktop was always going to be, and let people plan around the honest version instead of the aspirational one. Mark Shuttleworth showed exactly this kind of clarity in 2017, cutting Unity and Mir cleanly rather than letting them limp on underfunded. I’m hoping for the same call here, on whatever timeline it actually lands on: ship it, or kill it, but say which.

I still hope to settle there eventually. I wrote nearly that same sentence in 2015, about a phone that never quite arrived. I’d like this one to land differently. That’s on Canonical now, not on me finding somewhere else to go.

Thanks to u/jo-erlend and u/tomscharbach for the arguments that made me actually go and check the history, and to u/catbrane and u/Oliv_3 for the rebuttals that kept the checking honest. Read the original thread on Reddit →

Update: What nhaines Added

u/nhaines, a moderator of r/Ubuntu, replied to this piece directly in the follow-up thread, and it’s worth engaging properly rather than folding a line into the body above. Three points land clean.

First, the Snap Store isn’t just a listing page, it’s tied into Canonical’s build service the way Launchpad is: point a snap’s source at a GitHub repository and Canonical rebuilds it automatically on every push. That’s a real, useful feature I hadn’t accounted for, and it’s a fair reason the store can’t simply be forked the way a Debian repository can. Forking the listing wouldn’t get you the build pipeline behind it.

Second, there’s already a local path around the closed store for building, if not distributing: snapcraft spins up the same LXD-based build environment the Snap Store itself uses, so testing or building a snap doesn’t actually require Canonical’s infrastructure.

Third, on Ubuntu Core Desktop’s stalled timeline: the modularity idea itself isn’t new, Canonical’s own 2023 blog above already describes swappable desktop environment snaps, and The Register’s piece already named the same integration problems. What nhaines added was the framing: that this is being built deliberately so flavours and community members can build and swap in their own desktop snaps, not just so Canonical can offer a menu of desktop environments. If accurate, that reframes years of “in due course” as engineering caution rather than drift. It doesn’t change the ask in this piece, commit to a date or say plainly it’s a decade-plus bet, but it changes why the date hasn’t come yet.

Two points don’t hold up as well.

nhaines attributes most of the breakage I documented (Slack, Obsidian, the Flutter/GLib failure) to publishers not testing snaps thoroughly enough against changes, not to a flaw in the sandbox itself. That’s plausible, and I already assumed as much going in, dpkg has no monopoly on badly maintained packages either. But that distinction has never been communicated anywhere a user would see it. From the install prompt, “the sandbox is architecturally sound but this publisher didn’t test it” and “the sandbox doesn’t work” produce the identical experience: the officially steered install method fails, and the fix is always to leave it. A distinction that only lives in a moderator’s Reddit reply isn’t a distinction users can act on. And closing that gap is Canonical’s responsibility, not the volunteer and third-party maintainers who packaged into an architecture they didn’t choose, that apt now defaults to.

On the US$30,000 Brand Store fee: nhaines frames it as the cost of custom branding for a specialised IoT product, not a general toll on independence, which would mean the Nitrokey example cited above overstates the case. Checking that against Nitrokey’s own writeup again: they hit that tier specifically while trying to get GPIO and I2C interface access for NextBox, not branding, and by their account Canonical never confirmed whether a Brand Store was actually the only route to that access or merely appeared to be. Nearly five years on, if that’s still the state of it, it isn’t a niche branding case, it’s the same absence of a clear answer showing up a second time.

Neither point resolves the piece’s other open question: none of this touches why a developer should keep supporting two divergent packaging standards while the rest of the ecosystem, Fedora, openSUSE, and Debian’s own practical dependence on Flatpak, has already converged somewhere else.

Sources

The technical history of confinement and dpkg

• Debian Project. Founded August 1993 by Ian Murdock
• Linux Security Modules: framework development began around 2001, merged into the mainline kernel with Linux 2.6, December 2003
• AppArmor: merged into the mainline Linux kernel at version 2.6.36, October 2010 (LWN.net, Phoronix)

Snap and Ubuntu Core’s actual origin

• Click packages developed for Ubuntu Touch from around 2013
• Canonical, Snappy Ubuntu Core announcement, 9 December 2014
• Snap arrived on Ubuntu Desktop with the 16.04 LTS release, April 2016

Canonical’s own statements on Ubuntu Core Desktop

• Canonical. Ubuntu Core as an immutable Linux Desktop base, 31 May 2023
• The Register. Why we’re still waiting for Ubuntu Core Desktop, 6 November 2024
• OMG! Ubuntu. What’s Next for Ubuntu Desktop? Mark Shuttleworth Shares His Plans, April 2017

The precedent: Unity, Mir, and the 2017 course correction

• Phoronix. Ubuntu To Abandon Unity 8, Switch Back To GNOME, April 2017

Why Snap hasn’t spread past Canonical’s own family

• gHacks. Linux Mint 20 will block Ubuntu Snap by default, June 2020
• Nitrokey. NextBox: why we decided against Ubuntu Core, 2021

The alternatives

• Fedora Project. Flathub setup and Third-Party Repositories
• openSUSE. Portal:Aeon
• Debian. flatpak package, trixie
• NixOS. Nix package manager

The follow-up conversation

• u/nhaines. Reply to this piece, r/Ubuntu, 29 July 2026

Related reading on this site

• Good bye Android? Hello Ubuntu! Not yet unfortunately..., the 2015 Ubuntu Touch post this piece keeps returning to
• Escaping the Sandbox: Fixing the Zoom Camera on Ubuntu 24.04 and 26.04, the confinement failure that started this
• Why on earth is Canonical still pushing Snap so hard?, the original Reddit thread
• Follow-up: wrote it up properly instead of more replies, the thread nhaines replied in

• Ubuntu
• Snap
• Canonical
• Flatpak
• Dpkg
• Linux Desktop
• Package Management
• Open Source