Ubuntu, facing declining marketshare, doubles down on most hated feature
Ubuntu, facing declining marketshare, doubles down on most hated feature
How long before Ubuntu abandons Snap packaging in order to save the Linux distribution?
Ubuntu, the one-time-king of Linux distributions, is facing a massive decline in marketshare. In response to this, the Ubuntu team has decided to double down on supporting Ubuntu’s most hated feature — the very same feature that many blame for the steady loss of users… the Snap application packaging system.
Ubuntu is not only doubling down on their most hated feature… the Linux distribution is making a specific point of not supporting the competing (and potentially more popular) packaging system: Flatpak.
Mark Shuttleworth, CEO of Canonical and “Self Appointed Benevolent Dictator for Life” of Ubuntu, made the following statement when asked, at a recent event, about the possibility of Ubuntu including Flatpak support in the future:
“I can say right now Flatpaks wouldn’t work for us. I don’t think they have the security story and I also don’t think they have the ability to deliver the same integrity of execution over time that Snaps have ‘cos we built those things into Snaps.”
Ok. Got it.
No Flatpack in Ubuntu. Only Snap. Snap is the future of Ubuntu.
The Problems with Snap
Opponents to Snap would be quick to point out the disadvantages of using Snaps, including:
Snap packages tend to be significantly slower to launch than software installed via any other packaging system.
Software “Snaps” receive forced updates that cannot be disabled. You must use whatever latest version of a “Snap” that is available, unless you disconnect entirely from the Internet.
The “sandboxing” in Snap is so extreme, that it becomes difficult to perform simple tasks such as: managing extensions in a web browser, printing, or basic access to the /tmp directory.
And, later on during the same event, Shuttleworth made a brief acknowledgement of some of these issues:
“There definitely are places where we need to improve the Snap experience on the desktop. Startup performance times seem to be really, really important, so that’s something we can focus on. And also managing the boundary of security, managing the places where you want to deliberately take your application out of the box.”
If Canonical truly is going to focus on Snap as the packaging of the future for Ubuntu, Shuttleworth would be wise to focus on the many shortcomings of the system — as experienced and reported by their users.
Shortcomings which some have blamed for (or at least contributing to) the steady decline in the Ubunter user-base over the last few years:
Now, to be fair, Snap packaging is (in all likelihood) not the only factor that has led to the sharp decline in Ubuntu market-share. Reality tends to be far more complex than that. But, considering the timeline — and the general “word on the street” among Linux users — there does seem to be a very strong correlation.
Snap, itself, is not a new thing. It’s been around for a few years. But, worth noting, as the dependence on Snap has increased within Ubuntu itself, the market-share of Ubuntu has responded by declining.
Ubuntu’s Long Struggle With Snap
Canonical and Ubuntu have struggled, for years, to convince people to adopt Snap packaging.
To illustrate that fact, I’d like to tell you a little story. One that I was personally involved with.
Back in June of 2016 (early on in the days of Snap packaging development), Ubuntu made a major announcement:
“Developers from multiple Linux distributions and companies today announced collaboration on the ‘snap’ universal Linux package format.
Snaps now work natively on Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity, and Xubuntu. They are currently being validated on CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt and RHEL and are easy to enable on other Linux distributions.”
Taken at face value, this would be an absolutely amazing announcement for Snap packaging! Look at all those different Linux distributions adopting Snap! And they’re all “collaborating” together? Amazing!
Only one problem: It was not true.
During this time, I was in an elected position on the openSUSE Board. You’ll note that openSUSE is included in the list of Linux distributions that Ubuntu claimed to be working with.
Well, not long before Canonical issued that announcement (just days before, if memory serves), a Canonical representative contacted me to inquire about what, in theory, it might take to get Snap packaging working on openSUSE.
That, right there, was the sum total of the “collaboration” between Ubuntu and openSUSE on Snap packaging. It, literally, had not gone any farther than that. I would know. I was the guy they were talking to.
And openSUSE wasn’t alone. Here is a similar statement from a member of the Fedora team:
“The sum total of communication between Canonical and Fedora before the release of this press release was that they mailed us asking about the process of packaging Snappy for Fedora, and we told them about the main packaging process and COPR. They certainly did not in any way inform Fedora that they were going to send out a press release strongly implying that Fedora, along with every other distro in the world, was now a happy traveler on the Snappy bandwagon.”
Ubuntu (and parent company Canonical) were, obviously, desperate to show vast adoption of Snap. So desperate that they straight up lied about working with other Linux distributions.
From the very earliest days of Snap, the company behind the format has struggled to make the case for its adoption.
How many people use Snap? Who knows! It’s a secret!
Now, why do I mention that?
Well, Shuttleworth also made the statement that an “enormous” number of both users and developers prefer Snap packaging.
Ok. How big a number, exactly, is “enormous”? While I have no doubt that many people like Snap packaging (it certainly has some good points!) the word “enormous” is terribly vague.
Unfortunately Shuttleworth did not provide any details.
In fact, no details at all have been provided — in at least 4 years — for how many people are actually using Snap. Willingly or unwillingly.
Compare that with the extreme transparency of Flatpak.
We know, for example, that there have been 444 Million Flatpak packages downloaded from Flathub. We can even track downloads on a day-by-day basis.
A history of not telling the truth about Snap packaging, coupled with complete and total secrecy about the numbers, doesn’t paint a pretty picture. Especially when their competition is proudly letting the world see all of the Flathub stats.
So what does Ubuntu do about Snap?
This is a rough situation for the Ubuntu team. They have clearly invested a great deal of work into Snap and would hate to see it go away. That is something I can certainly empathize with.
So. What, exactly, will they do about it?
Let’s take stock of what we know:
Overall Ubuntu market-share appears to be dropping steadily.
The most talked about feature of Ubuntu is Snap packaging, and the overall sentiment, on that feature, is a highly negative one (often citing specific technical issues).
We have no insight into actual Snap usage, but the competing Flatpak is growing steadily in usage.
Ubuntu has a long history of struggling with convincing people to use (and like) Snap packaging. Even willing to lie in order to try to achieve that goal.
In spite of this, Canonical has doubled down on Snap and rejected working with competitors (who are experiencing growth).
Now, here’s the thing: We’ve been here before, with past Ubuntu projects:
Unity. Mir. Ubuntu Touch. Upstart.
Canonical (and Ubuntu) have a long established track record. A pattern that they repeat over and over again.
Introduce new software, developed in house, rejecting community driven projects or existing standards.
When people don’t like it, attack the people who criticize it.
When criticism escalates, double down on the project. Make it a core part of Ubuntu.
Double down two or three more times as the negative sentiment increases. Increase attacks on those who criticize.
Abandon project entirely.
This pattern is incredibly consistent, and ridiculously well documented.
Right now we’re on step 4.
Don’t believe me? Just watch. It might be a few months — heck, it might be a year or two — but Canonical Snap will move to Step 5. It is inevitable.
I look forward to the attacks against The Lunduke Journal for the statements here. Just as I was attacked after documenting criticisms and concerns with Unity, Mir, and all the rest. Canonical is nothing if not predictable.
One final thought
This may seem like a dark, desperate time for Ubuntu. Market-share is way, way down. The CEO is getting (clearly) defensive about a core feature that appears to be driving people away from the distribution.
It’s rough. No doubt about it.
But all is not lost for Ubuntu. Not by a long shot.
The reality is: There is a lot more to Ubuntu than just Snap packaging. And Ubuntu has a long, fairly impressive, history of fixing their mistakes. Sure, it may take Canonical and the Ubuntu team a couple years longer than necessary to fix problems… but they do have a solid track record of eventually doing so.
And I believe that will be the case here as well.
My prediction: Ubuntu will see a (small but noteworthy) rebounding of market-share after they completely remove Snap from the distribution and spend a release cycle focusing on the issues that have been driving people away. I just hope they do that sooner, rather than later.
I’m clearly late to this copulation of clusters, but from purely technical standpoint, where can one find an authoritative, *detailed* document describing what problems Snap attempts to address and what mechanisms it employs to do so.
I ask because this feels very familiar. When SUN led the way by putting dynamic linking into SunOS, the first versions were absolutely pilloried because of process startup overhead. (App launch delay.) SUN figured out the hot paths and added a couple of small caches in the dynamic linker and presto! Much much better. But it did require some serious sleuthing.
Likewise, when Apple introed sandboxing, the world was going to end. Luckily the devs fought it to a draw before anything slipped out, but the behavior did change fundamentally and only now is it getting to be mostly invisible.
This is all important because the “user”-based protection model we’ve used since forever, even augmented by the operational nightmare of ACLs, is completely insufficient.
Ex: at three different banks I am three completely unrelated people. A malware attachment to a banking app like Quicken
which has access to all three banks could
interfiltrate information between banks to
identify customers ripe for the picking.
Likewise, the trust level in apps is certainly not uniform. Library routines that read data
from files is trusted mot to make clandestine
copies of information. The Apple sandboxing
is the only widely deployed system which
can manage a “least privilege” surface down
to libraries which heretofore have been trusted because there was no alternative.
So even if an app is running as “you”, there
are areas which have historically used the fact it was running as “you” to perform some clandestine compromise. By doing a better job of compartmentalizing the app trust model a great deal can be done to prevent “surprising” app behavior.
I am wondering if the Snap machinery is trying to address these issues and is
plowing its own set of furrows trying to get there.
sorry for the length, but i’ve been working in this space for some time and hope there is something there to learn from.
-mo
I tested the startup of Calculator on a Ubuntu system a year (two? three?!) ago and while the universe version from the repository took little to no time to launch cold the snapped version took several seconds. I have never used snapped packages after that. I love the idea of the Unsnap project. 😂
Also, don't you dare SIDELOAD an AppImage on your Ubuntu system!