For me, it was a combination of Ubuntu breaking upstream and introducing its own unnecessary systems.
I had a few issues caused by Ubuntu that weren't upstream. One was Tracker somehow eating up lots of CPU power and slowing the system down. Another was with input methods, I need to type in a pretty rare language and that was just broken on Ubuntu one day. Not upstream.
The bigger problem was Ubuntu adding stuff before it was ready. The Unity desktop, which is now fine, was initially missing lots of basic features and wasn't a good experience. Then there was the short-lived but pretty disastrous attempt to replace Xorg with Mir.
My non-tech parents are still on Ubuntu, have been for some twenty years, and it's mostly fine there. I wouldn't recommend it if you know your way around a Linux system but for non-tech, Ubuntu works well. Still, just a few months ago I was astonished by another Ubuntu change. My mom's most important program is Thunderbird, with her long-running email archive. The Thunderbird profile has effortlessly moved across several PCs as it's just a copy of the folder. Suddenly, Ubuntu migrated to the snap version of Thunderbird, so after a software update she found herself with a new version and an empty profile. Because of course the new profile is somewhere under ~/snap and the update didn't in any way try to link to the old profile.
Then there were stupid things like Amazon search results in the Unity dash search when looking for your files or programs. Nah. Ubuntu isn't terrible by any means but for a number of years now, I'd recommend Linux Mint as the friendly Debian derivative.
As I understand it, snap the package format is not proprietary. Its as open source as say flatpak. What is proprietary is Canonical official snap store, and they patch their version of snap to only use that store. It'd be the same as flatpak being tied to only flathub.
Of course that goes against the spirit of FOSS, but there's a bit more nuance there than simply saying "snaps are proprietary".
Snaps don't just suck from an ideological but also practical perspective, as described for Thunderbird. Firefox on Ubuntu has also serious permission issues with webcam support OOTB even experts are struggling with (involving AppArmor, pipewire, snap, and FF device config). and has become unusable for things like browser-only MS Teams on mainstream notebooks.
Containers, popular as they may be on servers, can only add breakage and overhead to desktops, especially for an established and already much better organized system like Debian's apt. There just haven't been any new desktop apps for way over a decade that would warrant yet another level of indirection.
I've tried making snap packages, but I discovered they're very tightly tied to Ubuntu's base packages. They're not portable at all. In essence they're effectively just a secondary Ubuntu-specific package format for user-level applications.
For example, with flatpak you select a base runtime for your package that contains mostly system-agnostic libraries. With snap, you specify an Ubuntu version as a base runtime and additional dependencies that are Ubuntu packages.
My understanding is that the base layer (similar to what FlatPak provides) is shared and downloaded by the snap manager so it is portable as long as you want to download it.
The end result should be similar to FlatPak where you have practically no dependencies as it should package almost everything.
See, that's the issue. I want my distribution to distribute the dependencies I need to run applications outside of containers. That's, like, it's main job man.
Snapd still hardcodes Canonical's snap store signing key and provides no mechanism to add your own keys. Any other snap repos will be treated as second class citizens.
Defaults matter a lot, and snaps are the default in Ubuntu.
The topic is not whether snaps are avoidable or not, but the Ubuntu is going downhill. And snaps are purported to be part of that downhill, which would be Ubuntu's NIH syndrome. As far as I know, Ubuntu's only successful development is Ubuntu itself - the other projects have all failed over the years, and snap, while ongoing, is not winning any popularity contests either.
Snaps per se are no better or worse than flatpak. Canonical's mistake, IMO, was to make their store the only place snaps can be hosted. That is the "proprietary" bit everyone keeps talking about.
But in practice even for flatpak the only realistic place you can publish your flatpak if you want any traction at all would be flathub, so both formats have only one store right now. But flatpak allows a custom store while for some strange reason Canonical decided not to allow snap that freedom.
Another problem is, Canonical promised to release server components and enable alternative stores, and just forgot that they made that pledge.
Also, rugpulling users and migrating things to snaps without asking their users in order to "create a positive pressure on snap team to keep their quality high" didn't sit well with the users.
> But in practice even for flatpak the only realistic place you can publish your flatpak if you want any traction at all would be flathub
But, for any size of fleet from homelab to an enterprise client farm, I can host my local flathub and install my personal special-purpose flatpaks without paying anyone and thinking whether my packages will be there next morning.
Freedom matters, esp. it that's the norm in that ecosystem.
I was neutral-ish about Ubuntu, but I flat out avoid them now, and migrate any remaining Ubuntu server to Debian in shortest way possible.
I'm using Debian for the last 20 years or so, BTW.
Yes, same. I started with Ubuntu back in the day, because the server I inherited ran Ubuntu, and it was just natural after that for me to run it on the desktop as well. I grew to dislike their NIH over the years, tried distro hopping, and settled on Debian.
Yes, I agree. Snaps or Flatpak, not much of a practical, technological difference. What sets them apart is the way the distribution is handled, including the open source availability of the backend, which enabled for example Red Hat and Elementary to run their own stores.
If you are making your own distro, creating your own flatpak store is trivial, that's all what matters. Linux Mint doesn't use snap exactly because Canonical forces everyone to use their snap store.
Canonical doesn't force anyone to use anything. Snap is open source, just modify it to use a different store if you want. Mint literally forked a zombie DE, but changing a few lines of code in snap is an issue...
Defaults matter a lot, snap is not open source (client is, backend isn't), you cannot "just modify it (Ubuntu)" to use a different store, because Ubuntu installs snaps even with apt. Mint is not part of the discussion.
Red Hat do the same. They reinvented the wheel on multiple occasions (systemd and it's whole ecosystem like systemd-resolved and timed and the whole kitchen sink; podman, buildah, dnf, etc etc.)
They just have more success on getting their NIH babies accepted as the standard by everyone else. Canonical just fail at that (often for good reasons, Unity was downright crap for some time) and abandon stuff, which doesn't help their future causes.
Canonical did their own NIH init daemon called Upstart which failed due to the fundamental design and the implementation being plain bad. Redhat builds better software which is why their NIH gets more adoption.
They're not forced on anybody, they're not required by systemd, and many distributions use more feature-rich alternatives (including, afaik, RHEL — last time I looked at it, they used dnsmasq and chrony). They're also often shipped as separate optional packages:
> Still not anywhere near as popular as Docker. Although technically they're far better than Docker, and if anyone is using them, it's for that reason.
NIH packages are generally expected to be less popular, yes. They have some technical merit, though in my opinion that's mostly trade-offs rather than one being strictly better than the other. I would be surprised if everybody using them is using them because of technical merit as opposed to it being pushed by the distro.
Red Hat builds really good stuff. NIH is sometimes right because nobody invented the stuff at all. Standard Unix tools are great but they don't solve everything, so we've ended up with most distros having "the Debian way" or "the Red Hat way", the main difference of course being deb/apt/dpkg vs rpm/yum/dnf. When building an embedded system with Yocto, the basic choices are also Debian or Red Hat style, though you can of course do anything.
Special mention goes to NetworkManager, which has become the de facto standard way to configure networking because it's good. And with nmcli I can even remember how to connect to wifi from single user mode.
>They just have more success on getting their NIH babies accepted as the standard by everyone else.
This depends on the phrasing. We could also say that Red Hat produces actually useful software, in contrast with Canonical, whose developments don't seem to provide value over existing solutions.
We could also say that Canonical tries really hard to do exactly what Red Hat does, but in a slightly different space, and not very successfully.
A major difference is that Canonical projects have copyright assignment policies, while Red Hat projects don't - this probably explains a lot of the difference in adoption dynamics.
You're right. You don't have to use snaps. Ubuntu migrates packages slowly in behalf of you.
Using apt to install some packages installs snap plumbing and downloads the package as a snap automatically. You don't have to install it manually.
There's no malicious intent though, it's made to "impose a positive pressure on the snap team to produce better work and keep their quality high" (paraphrased, but this was the official answer).
Installing the inferior snap packages when you apt get is one of the worst cases of a Linux distro refusing to respect the user's intent that I've experienced.
This has got to be the most user-blind self-imposed preference in a modern operating system outside of Microsoft's BS.
If you're going to use an OSS operating system, the control of what is placed on the system should be inherently with the user. If the developer has a question if a new package should be added or is required, throw a prompt and ask -- with a default to not use application containers and the default packaging system.
And one of these migrations broke my workflow substantially enough that a dist-upgrade turned into a complete system reformat to Debian and cost hours that I couldn’t afford.
I'm with my neighbor comments. How do you use Ubuntu without snaps? The base Ubuntu install already comes with several snaps. Installing random things through apt leads to snaps. I personally do not know how to avoid snaps on Ubuntu.
It's just an empty package that tells the system snap is installed, to stop the broken dependency chains you otherwise get from force uninstalling snap.
It's been working fine on a handful of Ubuntu 24.04 systems I've been handed and can't change the OS of, for about half a year now.
I forget the exact context but I recall an Ubuntu dev stating they have more users of the Firefox snap alone than trendy distros have entire users.
I think it’s worth keeping that in mind with all the hate Ubuntu gets. Most users are just silently getting their work done on an LTS they update every two years.
Well, I don't know which trendy distro the dev is referring, but Debian is complete opposite of Trendy. It's a bedrock distro silently running almost everywhere in some form or shape.
Most of the Linux-based (enterprise and/or embedded) appliances are built upon Debian, for example.
P.S.: The total number of Debian installations and their derivatives are unknown BTW. Debian installations and infra do not collect such information. You can install "popularity-contest", but the question defaults to "no" during installation, so most people do not send in package selection lists, unlike Canonical's tracking of snap installations.
LXD was forked as Incus, and it’s an absolute delight.
Seamless LXC and virtual machine management with clustering, a clean API, YAML templates and a built-in load balancer, it's like Kubernetes for stateful workloads.
Incus is fantastic. I think Proxmox is where everyone is migrating to after the VMWare/Broadcom fiasco, but people should seriously consider Incus as well.
Switching to rust-based system software is very different from the clearly profit seeking (or control seeking which is just long term profit seeking) changes like ads and snap (with massive friction to not using snap).
Yes, but I prefer glibc + GNU Coreutils based systems in my installations. They're additional nails on top of the (fatal) ones like snap, Ubuntu Pro and MOTD ads.
> in what way has it gone uphill versus just using Debian?
Their lawyers' willingness to risk shipping pre-built zfs kernel modules (that are always in sync with the kernel). Pretty important if you're into that sort of thing, it's easier to remove cruft once post-install than to keep an eye on DKMS for years (making sure that it hasn't disassembled itself and continues working).
I'm an old-school user so I'm not exactly Ubuntu's target audience, but for Ubuntu was bad about a lot of the older, lesser-used bits of Linux.
The two things I can remember were problems with NFS out of the box (outside having to install nfs-common, which I'm fine with) and apt-cache not displaying descriptions of packages. There were lots of other, minor annoyances that affected people like me but wouldn't affect someone who got into Linux desktops after, say, 2010. My memory sucks though so those are the two I remember. Yes, there were bug reports filed and yes, they sat in the tracker for years with no attention from Ubuntu.
I wound up back on Debian once I got old enough that I didn't care about being behind the times a couple years.
In what way Ubuntu went downhill?