Linux Mint 20 disables deb2snap packages, and Snap's growing external adoption problem

I do understand this is hyperbolic, but it’s to try to make my point. Like I said about looking broader, I would estimate that 80% of comments online in the broader world about Snap (for example, read from the sources I mentioned) are negative. How do you quantify that as a percentage? Saying that a “silent majority” likes Snap? I think that it is safe to say that there is definitely a problem.

In the end though, it can’t really be quantified. Look for yourself - get out of this bubble.

Yes, but you just missed my point, and your image confirms my point. Not by default. The first 6 releases are all Ubuntu. Linux Mint doesn’t ship Snap by default. KDE Neon does not. Ubuntu again. Elementary OS does not. Zorin does ship with it. Pop OS does not. Debian 10 does not. Manjaro does not. Linux Mint again does not. Ubuntu 20.10 hasn’t even been released yet.

List of popular distros with Flatpak included by default:

  • CentOS 7+ (when using GNOME)
  • Elementary OS
  • Fedora
  • Endless OS
  • Pop OS (coming soon)
  • Zorin OS (shared with Snap)
  • Solus (shared with Snap)
  • PureOS
  • Clear Linux

Versus the list of Distros with Snap built in by default:

  • Ubuntu + Derivatives
  • Solus (shared with Flatpak)
  • Zorin (shared with Flatpak)

There is not even one distribution outside of Ubuntu that supports Snap only and not Flatpak, while there are plenty of distributions outside of Ubuntu that are solely Flatpak. That should be a big warning sign.

Look, I don’t want to harp on Snap’s failure here. But I want the developers to realize where the wind is going and realize that Snap is going to be dead on non-Ubuntu distributions as a default before it even started. Yes, of course people can manually install Snap, but like I said, the defaults always win*.

*With the exception of Microsoft Edge and Bing.

2 Likes

In the area of population growth there is such a thing as demographic momentum, where you have a high birthrate at some point so you end up with a large generation, but then the birthrates go down to below replacement level so for many decades the population keeps growing despite the fact that not enough babies are being born to replace the people who will be dying. Then the large old generation starts dying off due to old age and at some point the population starts to shrink.

In the same way it looks to me like Snaps may be heading towards this kind of situation where right now you have momentum and keep growing, but at the same time there is a counter-momentum that is going to increasingly marginalize Snaps until they become irrelevant to application developers, because Flathub exists and is universally supported, and then the Snap Store will become a ghost town of apps that don’t receive updates. At that point the main apps still there are just open-source apps maintained by Ubuntu maintainers and some Canonical apps and that’s it, so all you’ve done is replace the Ubuntu apt repositories with a Snap repository, and then you’ll have to ask yourselves if it’s worth maintaining your own repository of applications for desktop apps when you can get all the same apps by switching to Flatpak, and just use Snap for appliances, IOT, and servers and things like that where Flatpak is weak.

Don’t get me wrong. I like Snaps. I prefer them over other distribution methods. I don’t need you to open-source the Snap Store, I don’t need to be able to use a different store, I don’t need the ability to disable automatic updates. What I would like is for Snaps to survive and thrive, and those problems can kill the platform in the long run.

2 Likes

Another thing to note is that in your own survey over 30% disliked Snaps. That’s alarming. It means that even among Ubuntu users, who should be predisposed to like whatever Canonical and Ubuntu are doing, 1 in 3 people dislikes it. How do you think this reflects on the broader Linux community?

When I go on YouTube I see tech podcasters describing Canonical as a tool for Microsoft to destroy Linux, as the new Microsoft trying to take over Linux, saying that Ubuntu is the devil, that Snaps are a tool to create vendor-lock-in.

Now you have at least one distro, and IIRC there’s already a second one, who choose to actively block users from being able to Install snapd, and it’s a fairly popular high-profile distro.

First comes de-legitimization. Then marginalization. Then extermination. Take a look at how these kinds of things work.

When you open-sourced Launchpad nobody used the source code to build another Launchpad. So what? The important point is that it was no longer a weakness that your haters could exploit to turn public opinion against you. They couldn’t attack you that way anymore. When you came out with Unity it was heavily criticized, but it was also exciting and generated enthusiasm. Do you think maybe the requirement to sign on to copyright assignment might have dampened that enthusiasm and discouraged contributions, which then led to Canonical being the only ones contributing to the project?

You shoot yourselves in the foot, then argue over whether the injury exists or if it’s serious enough to bother seeing a doctor.

1 Like

I understand why Snap and Flatpak are constantly compared with each other. On the desktop, both provide an easy way to get the latest versions of applications. Many of these apps are normally not in the distro repositories or are very outdated. From the standpoint of a user who simply wants an easy way to install these applications, Snap and Flatpak are very similar.

That said, Snap is much more than that. Snap is also a system to build distributions, similar to apt.
Some examples of software which can be put in a snap but which are not “applications”:

  • There is current work ongoing to put the entire Linux printing stack inside of a snap. One of the advantages of this is that the printer stack can be updated independently from the OS. Once this work is complete, every single Ubuntu version and every other Linux distribution will be able to use the latest printer drivers. Getting new printers to work on older distro’s is currently a difficult task and you risk breaking something when you mess too much with it. This is one of the issues snap can solve, but this is not something Flatpak was designed to do. Flatpak simply uses the printer stack of the host system. If that host system is 2 years old, you will get 2 year old printer drivers.
  • When the Communitheme (now Yaru) initative started, we wanted an easy way to make the latest updates of the theme available on Ubuntu 18.04. Normally, a system theme is shipped together with the distro, so users do not get updates after the distro releases. For Ubuntu 18.04 we put the system theme inside of a snap, so every time we updated the snap, the system theme would be updated too. This is again not something Flatpak was built for, because a system theme is not an “app”. The only theme support Flatpak is concerned about is making sure the apps inside of the Flatpaks are properly themed.
  • There are many devices running whose kernel is a snap. This is again not something Flatpak is designed for.

These are not meant to be criticisms of Flatpak. Flatpak was designed to be “the future of apps on Linux” and it does that very well. Flatpak is simply not designed to be a tool to build distributions, so even if Ubuntu would switch to Flatpak for app distribution, they would still need snaps for kernels, printer stacks, system themes etc.

3 Likes

I’m finally going to chime in here a bit.

I started working with Snaps in May for my new job. I have been tasked with rolling an Ubuntu Core 18 image for my company’s hardware platform to distribute to one of our partners for their own purposes. So, all my thoughts are through an embedded developer’s lens.

So far, I’ve had a lot of trouble with this. A good chunk of my trouble can be chalked up to me being a noob and growing pains (the platform isn’t that old), however, there’s a LOT of missing, outdated, misleading, or just plain wrong documentation for the embedded side, which Canonical is pushing a LOT. It’s been a total pain to fight through these issues, and I do REALLY appreciate all the help I’ve received on this forum, but, a lot of my issues I feel should’ve already been addressed, or taken care of, for a platform that so heavily pushes the embedded side.

A few examples

I’d love to contribute to this documentation, and to an extent, I have. But I don’t get paid to contribute, so I’m doing most of this after work out of sheer frustration of battling whatever absurd issue I come across.

It’s also practically impossible to develop on the actual unit itself simply due to the static, read-only nature of Ubuntu Core and its snap base, which, while I certainly understand the appeal, makes iterating on software for Ubuntu Core really, really slow. I feel like that issue needs to be addressed somehow. Although, maybe that’s just the nature of snaps and I need to gain a better understanding of the platform.

Finally, and this one is way less important than my other problems, there’s the really annoying fact that super popular tools such as, oh, say, vim, aren’t available as snaps on all platforms, not even armhf (so forget about having a good text editor on my dev device). I’ll be the first to say that I should be the change I want to see in the world, but again, I don’t get paid to do that, and there’s only so much day in my day. I think Canonical should at least make an effort to ensure that basic tools such as vim are available as snaps.

So, in summary, I’d say Snaps don’t really shine in the embedded world either. They make embedded development feel sluggish.

That’s my two cents.

Edit: I just looked at the documentation on that page and this does seem to be the regular Ubuntu server 18.04 images for the raspberry pi, not the Ubuntu core images.

As an example, the docs recommend installing a desktop with apt: sudo apt-get install xubuntu-desktop; this is not possible on Ubuntu core.

This could also be made a lot better with docs which explain the “development workflow” Canonical recommends.

Thank you for your contributions, they are much appreciated! I started working on the desktop application docs for the same reason.

I think part of the issue with the Python docs is that they assume the application already has a working setuptools configuration. Setuptools is not something snap-specific, a large part of all packages you install with pip use setuptools. However, when I created my first snap of a python package, I had no idea how setuptools worked. I think many people are in the same boat.

If you want an easier way to contribute to the docs; You can always submit feedback on individual doc pages by clicking on the link “Help improve this document in the forum” and leaving a comment. I’ve noticed the documentation team regularly checks these comments and addresses them.

3 Likes

Yes, and these are reasons why I like Snap! Flatpak can’t do this stuff. But I don’t think anything you just mentioned fixes any of the major problems blocking wider Snap acceptance. Flatpak is “good enough” and doesn’t have any of the multiple major dealbreakers that Snap has.

For example: As a distro maintainer, Snap takes 10 seconds to open an app the first time, whereas Flatpak is almost as fast as native. That alone is enough to close the case. Add in the centralized control, case closed again. The lack of other distributions joining? Case closed again.

Real-world experience beats the technical features. Technical works to serve the Real-world, not the other way around. A few minor positive features like printing are absolutely not going to outweigh what people perceive as major problems.

In the real-world millions of people use Snaps every day… While that doesn’t mean there aren’t problems, it serves to highlight that the few people vocal about their reluctance to use the system are by far outweighed in numbers by the people who use it without issue.

2 Likes

Fair point, I just thought I’d offer a new embedded dev’s perspective and first impressions. Also, I want to be clear that just because I dislike these things, I think snap is kinda cool and I’d like to work on improving the Documentation I have issues with, and (if I ever have any freetime) I’d like to address some of the development cycle issues I have. (For example, python plugin cross compilation).

I’m not trying to win any wars here, I’m just providing some context for this discussion. I also think there are glaring issues with snaps, but I think it’s important to explain the context so both parties can understand each other. Without understanding, these discussions turn into unproductive “yes!”, “no!” shouting matches.

I don’t think anyone has to be convinced that the startup speed is still an issue for some desktop snaps. Many people are working on fixing this, both from Canonical and people in the community. The latest work on startup speed is discussed here: Application startup performance

Part of the difficulty with snap startup speed is that the issues fall into two categories: issues with individual snaps and issues with snapd itself.

  • For example, reducing the size of your snap greatly improves startup speed. Simply updating your snap to use the desktop extensions will also improve the startup speed of your snap. Updating all these snaps is a long process, especially since snaps are published by thousands of different developers. Flathub has an advantage here in that they have much more oversight in who publishes Flatpaks and what build manifests these people are using, given that every app manifest is part of one GitHub org.
  • On the snapd side, many performance issues have already been fixed. The remaining issues now are the compression and library caching and are currently being worked on. However, these only affect a small number of snaps. Most snaps are able to have good startup performance if they are updated to use the latest tools.
1 Like

This is a growing problem of politics, ideology, public perception.

It doesn’t matter how many people use Snaps. What matters is that Flatpaks exist and provide a good enough alternative for desktop applications, and give you 1 distribution platform with which to reach all of Linux, while Snaps are being marginalized to the point where they may become Ubuntu only.

If you were a developer trying to distribute an app on Linux, would you prefer to reach all users with 1 package, or reach all users with 1 package and then also redundantly reach 40% of users with another package?

Flatpak and Flathub make Snaps redundant, so why should developers use Snaps at all for desktop application distribution? As a developer, wouldn’t you prefer to reach everyone with minimum effort?

When Snaps are being vilified and de-legitimized it doesn’t matter how technically excellent they are. They simply won’t be used and will even be actively blocked, like what the original topic of this conversation is about.

Take nuclear energy for example: new and better and safer reactors have been designed, but they are not used. Instead we keep using old reactors way past their expiration date, like Fukushima. Why? Because nuclear energy has been turned into a boogie man and therefore regulated out of existence.

The same thing is being attempted against Snaps.

If Snaps are illegitimate than all the many interesting and useful things they can do and their technical excellence will be irrelevant. They will simply be shunned by the wider Linux community, and perhaps by over 30% of current Ubuntu users (according to your survey), who, the more you transition to delivering applications as Snaps, the more they will jump ship to another distro.

As far as secondary issues, I do have issues with the documentation. I made a little command-line game called Sparky and wanted to ship it with Gnome Terminal so that I could launch it full screen like a normal game with a .desktop file. I didn’t find any documentation that would help me. I didn’t find any documentation directly addressing what parts are, how to bundle dependencies, or how to add a launcher for my app or the file structure. So I shipped it as something that can be launched only from inside a terminal.

BTW, Sparky is a Snap exclusive. The only other way to get it is to compile it from source.

I don’t think startup times are a real issue. VS Code launches in 3 seconds. Android Studio in maybe around 10 second. Most apps that I’ve tried are around VS Code’s speed or maybe even faster. It’s not snappy, but it’s passable. If nobody pointed it out I wouldn’t have paid any attention.

I don’t think file size is important, because who cares? As long as it’s not huge users probably won’t notice, except for a few zealots of efficiency. What will kill Snap is the issue of legitimacy.

1 Like

The captain is holding the steering wheel going on and on about how big and beautiful and majestic his ship is, and how the engines are state of the art and so powerful. One of the passengers comes screaming to the captain that there’s an iceberg right ahead. The captain then explains to the passenger that his ship is really big and state of the art and is accelerating very nicely, so everything is okay.

Yes, the ship is big and beautiful and majestic with powerful, state of the art engines, but what does that matter when there’s an iceberg in your path if you don’t turn to avoid it?

That’s the problem here. Not the technical details, but the strategic situation.

1 Like

Might be that our documentation isnt the best here, but below is a full iteration of building/developing a snap on a core18 device … (for convenience you might want to manually add your user to the lxd group in /var/lib/extrausers/group, that saves you from needing sudo with the lxc commands)

$ grep Model /proc/cpuinfo 
Model		: Raspberry Pi 3 Model B Plus Rev 1.3
$ grep PRETTY /etc/os-release 
PRETTY_NAME="Ubuntu Core 18"
$ snap install lxd
$ sudo lxd init --auto
$ sudo lxc launch ubuntu:18.04 bionic
Creating bionic
Starting bionic
$ sudo lxc shell bionic
root@bionic:~# snap install snapcraft --classic
...
root@bionic:~# git clone https://github.com/ogra1/htpdate-daemon-snap.git
root@bionic:~# cd htpdate-daemon-snap/
root@bionic:~/htpdate-daemon-snap# snapcraft --destructive-mode
...
Snapped 'htpdate-daemon_1.2.2_armhf.snap'
root@bionic:~/htpdate-daemon-snap# exit
logout
$ sudo lxc file pull bionic/root/htpdate-daemon-snap/htpdate-daemon_1.2.2_armhf.snap .
$ snap install --dangerous htpdate-daemon_1.2.2_armhf.snap
htpdate-daemon 1.2.2 installed
$
6 Likes

The problem is larger,

The “autoupdate” to ONLY canonical servers is a real problem in our opensource ecosystem. We are running totaly disconnected LXC containers and we don’t want that a problem who leads us to connect to internet (firmware update download etc…) leads to a castastrophic update. SNAP is ok for desktop use, but not for Server production use.

We actualy manage this actualy in deb packages with internal mirror who is running N version, there is N+1 version ready, so we start update to a locked version ecosystem who has been VALIDATED. But this INTERNAL mirror is not possible anymore with snap (only a version of “proxy” for “closed beta” are you serious ?!)

I handle this in 18.04 by removing snap and removing possibility to install it. BUT with lxd 4.x there’s a dependancy with LXD and SNAPD… So with actual SNAPD update policy AND SO LXD we don’t work on 20.04 migration (but on another solution migration) it’s a dead end.

Canonical is going to kill his server ecosystem with totaly irresponsible decision : no local mirror and no local repos AND no LXD without SNAP.

Does Linux distro needs a new package version ? Does Linux distro need a vendor locked install process ? What are you playing ? even Microsoft is comming to full open architecture.

The LXD snap supports channels and tracks; they create a new track for every major release. When you switch to the track of a major release, you will only get minor and security updates automatically. To update to a new major release, you have to manually switch te snap to the channel of the new release.

See https://snapcraft.io/docs/channels for more information.

Does this solve your use-case? You can switch a few test machines to the track of the new release and when everything works, you can switch all machines.

1 Like

Registered just to say this.
I quit ubuntu due to “snap”, and i’m not going back!
You must understand that you are humans and errare humanum est, even though you are Canonical.
Hence auto-updates will live (since you are a mini-microsoft now) until you screw up so badly that everyone realizes how bad it was in the first place. And i hope that linux users are not windows forgiving fools.
You are breaking the whole idea of the open source and this is enough for me to leave you.

p.s. GPU HPC cluster maintainer and lead admin + phd appl.math.

Despite all the wrong points made but…you do know that there are ways to opt-out of snaps right? Like uninstall snapd and set up an APT pinning so that it won’t be re-installed due to the deb2snap dependencies.

Well this may be a workaround at home, on a personal pc.
Not when you’re in charge of dozens or hundreds machines.

I totally understand why LXD should be able to run without any dependency to snap, or why mirroring a « local » snap store is a needed thing at scale.

And I’m really not familiar with LXD… So I guess educated people at Canonical thought about that way deeper than I ever could, right ?

there isnt much to think about, maintaining a package on all possible underlying distros and their derivatives, fixing bugs with all possible combinations of userspaces and kernels costs a plethora of manpower … having to maintain a single snap instead frees up huge amounts of developer time to fix actual bugs in the packaged application instead

… if you had a team of three, would you prefer to have two of these devs working only on porting and fixing distro specific bugs of the different flavours your app runs on, or would you prefer having all three of them work on your application with one of them occasionally testing/releasing an automatially built snap ? this is simple math of not wasting developer resources.

7 Likes

I know you’re right.

But getting back to an older post : it’s not made while « walking in user’s shoes ».
Solving dev’s’ problems does not solve users’ issues.

The example about LXD is not exactly a « wide audience » matter. If there’s such a limitation when « snap’d » then it was not rightfully thought dev’ side.