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

[mcphail]

From my hobbyist’s perspective, Mark, I think the easiest performance gain may come from formalising @galgalesh’s part which strips duplicate libraries which are already present in the core or content snaps. Ideally, this would happen during the staging process by actively excluding .debs which are duplicates of those in the core snap.

Using the current approach from @galgalesh, though, I’ve been able to dramatically slim down some of my snaps by an order of magnitude or more. This definitely helps startup speed, as well as initial download time and refresh speed. I suspect some of my snaps wouldn’t see such big gains, but these pack a lot of binary data which is already compressed, so changing the compression mechanism of the snap might not bring additional performance gains anyway.

[zyga-snapd]

@ianmjones

Fell or feel? (edit: haha, @zyga fixed it, feel it is)

Yes, funny how a typo can change the meaning.

[zyga-snapd]

I said something in a different forum on this topic just now and I think it’s worth sharing here.

I realize some people would like us to build a faster horse, just like dpkg/rpm apt/dnf/yum/zypper but better in some way without changing anything in how the old model worked. We are not making a faster horse, we are making a car.

There are differences compared to classic packaging but it is precisely because those differences exist we can build something larger and better than the old model allowed.

[sabdfl]

Strongly encouraging, or automating, the de-dup of libraries from core and popular content snaps sounds like a good idea for snapcraft, yes.

[sabdfl]

Elementary, or any distro, can easily have their own curated set of snaps in the store. The same mechanism lets many device manufacturers control which apps go to their IoT devices. Elementary, Kubuntu, any distro can do exactly the same with snaps. In their curated snap store, Elementary can work with any publisher to make any version of any software available, at whatever price they choose.

I don’t have any problem with Elementary’s decision to build their own app store. They are interested in specific experiences, and investing in those. The world is more interesting for the open source that different groups choose to produce. I’m not going to question their motivations, their sanity, or their intellect for doing it.

But for exactly the same reason, I’m proud of the work we continue to do with snaps. To be clear, we can improve things, and I know the team is committed to that. But as I look at it today, the experience we have enabled for publishers and consumers of apps on Ubuntu is a significant improvement, by and large, on what was possible before. I have been a contributor to Debian and Ubuntu for more than two decades, and snaps have decisively opened up the flow of high quality apps to an audience I care about. Well done.

[G.S.1]

@sabdfl

We did that experiment with Launchpad; the people who said they wouldn’t use it because it wasn’t open source were the same people promoting a closed source alternative. When we open sourced Launchpad, they said that they wouldn’t use it anyway because Canonical was the primary contributor.

I do admit the oddity of them focusing on open-source you but not open-source GitHub. I don’t know about the Canonical primary contributor issue as much though. I tried running Launchpad once and thought it was much harder to set up than GitLab. I wonder if some of the complaints regarding GitHub were reduced because there was always GitLab “in the wings” if needed?

@sabdfl

If you enjoy Catch-22 and Kafka’s dark comedy, the twisty arguments smart people use to justify not wanting to use a competitor’s stuff are hilarious.

Oh yes.

@sabdfl

Let’s just focus on making it absolutely amazing for anybody wanting to publish their app to Ubuntu users to do so, securely.

I’ve published Snaps before, and it wasn’t exactly the most amazing. Ubuntu-run SSO on a “neutral” platform was surprising, and the packaging process was a bit tricky. I’ve heard from several app devs that Snap is more difficult to package for than a certain Red Hat alternative, which shows more work is needed on this point.

@ianmjones

Flatpacks also suffered from a lack of discoverability, Flathub was a thing, but wasn’t integrated into many distros, and not in any that I used at the time anyway.

This is actually an odd pain point that needs to be addressed for Snap and Flatpak. Basically, Fedora and other distros won’t accept the integration of Flathub because it includes proprietary software in the main repo by default, and Snap does too. Typically, they would be split into “free” and “nonfree” repos with “nonfree” disabled by default, but neither Flathub or Snap offer that choice. This is why Flathub is disabled by default as “nonfree” by Fedora rules, and Snap is definitely not going to get included by default in other FOSS-repository-default distributions.

@zyga-snapd @sabdfl I think this is actually a major opportunity for Snap. If we offered a way to disable non-free packages from appearing by default, that’s something that Flathub does not have at the moment. If you can’t ship Flathub because it includes proprietary software but can ship Snap because it includes a free software only option, that might help out with being included on multiple distributions.

@sabdfl

Strongly encouraging, or automating, the de-dup of libraries from core and popular content snaps sounds like a good idea for snapcraft, yes.

@sabdfl

But for exactly the same reason, I’m proud of the work we continue to do with snaps. To be clear, we can improve things, and I know the team is committed to that. But as I look at it today, the experience we have enabled for publishers and consumers of apps on Ubuntu is a significant improvement, by and large, on what was possible before. I have been a contributor to Debian and Ubuntu for more than two decades, and snaps have decisively opened up the flow of high quality apps to an audience I care about. Well done.

I think Snap absolutely has great capabilities. @sabdfl However, perhaps we could do a better job with encouraging others to join in? Perhaps a page showing “what’s in it for you” if you join the project as a major distribution? Or perhaps a blog post addressing the most common concerns with a concrete roadmap to resolve them. Or showing how Snap will become a less Ubuntu-centric platform in the next year or two, or how it already has become more generalized. Perception matters.

[sabdfl]

However, perhaps we could do a better job with encouraging others to join in? Perhaps a page showing “what’s in it for you” if you join the project as a major distribution?

Yes, we could do that. But think of what we already do. We already run literally thousands of tests of every snapd commit, on many different distros, to avoid breaking anybody else, just like we try to avoid breaking Ubuntu. We go to pretty extraordinary lengths already to do hard, technical work that benefits non-Ubuntu distros. And there are quite a few other flavours of Linux that appreciate it, and enjoy snaps, and participate openly here.

I don’t think there are any distros that aren’t pretty clear about the upsides and downsides of using snaps, or that we’re pretty good to work with.

So, if they haven’t engaged yet, I don’t see that a single web page would help

Or perhaps a blog post addressing the most common concerns with a concrete roadmap to resolve them.

On the user side, yes, that makes sense too. Those top issues need to be addressed and we should be public about our commitment to addressing them. We want people who do use snaps to know they are going to keep getting better.

Or showing how Snap will become a less Ubuntu-centric platform in the next year or two, or how it already has become more generalized. Perception matters.

Yes, perception matters. So no matter what we do, some will invest in fomenting negative perceptions We have to choose where we spend our energy. Personally, I’d rather focus on conversations with people who WANT to use snaps, to meet their needs. That’s what we’ve been doing. We work with users, publishers, and distros. We can’t be too stressed about not working with folks who say they won’t work with us. Life’s too short.

As for becoming less Ubuntu-centric… I can’t think of a single element of snapd which assumes Ubuntu. There is a ton of code that specifically deals with NOT assuming Ubuntu! Yes, we take advantage of newer kernel capabilities because Ubuntu generally is faster to offer newer kernels, but we also work well on very old kernels from Ubuntu and other distros, and we test that rigorously.

[G.S.1]

@sabdfl

As for becoming less Ubuntu-centric… I can’t think of a single element of snapd which assumes Ubuntu. There is a ton of code that specifically deals with NOT assuming Ubuntu! Yes, we take advantage of newer kernel capabilities because Ubuntu generally is faster to offer newer kernels, but we also work well on very old kernels from Ubuntu and other distros, and we test that rigorously.

Yes, exactly, but the word doesn’t seem to have really gotten out about that. People seem to think it still is from the early days back when the core snap and others borrowed a lot from Ubuntu and assumed Ubuntu. Thus the need for the blog post announcing that things aren’t like that anymore.

One minor correction: Snap Developer accounts still announce the need for Ubuntu SSO, and snapd still authenticates with Ubuntu SSO. That could be separated out to not be “Ubuntu” in the title. Even in this case, if you made an announcement about how you were removing the last vestiges of “Ubuntu” in the Snap system for issues such as this, it would be helpful in addressing some of the FUD. Not everyone is going to search the forums for the answer.

@sabdfl

But think of what we already do. We already run literally thousands of tests of every snapd commit, on many different distros, to avoid breaking anybody else, just like we try to avoid breaking Ubuntu. We go to pretty extraordinary lengths already to do hard, technical work that benefits non-Ubuntu distros. And there are quite a few other flavours of Linux that appreciate it, and enjoy snaps, and participate openly here.

And that is great! People just don’t know that though. The current perception is that Snap is only developed with Ubuntu in mind, and there haven’t been any blog posts formally announcing what Snap is working on to stay distro-neutral. If they Google search Snap on other distros, they aren’t going to see that work, but are going to see some piece from a few years back about how only Ubuntu really works well with it. I think a blog post announcing where Snap is in 2020 and where it is going in general (instead of just a technical roadmap new users don’t understand) would be helpful, because a lot of opinions out there still think it’s like it was back in 2016-2017.

@sabdfl

Personally, I’d rather focus on conversations with people who WANT to use snaps, to meet their needs. That’s what we’ve been doing. We work with users, publishers, and distros. We can’t be too stressed about not working with folks who say they won’t work with us. Life’s too short.

Yes, but at the same time, I think it would be helpful to address the claims of people like Clement Lefebvre.

Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.

Maybe Clement will never be convinced, but we don’t need to leave users thinking that this is completely true. You can point out that you can audit them using such-and-such method, or that you can’t use a different store for such-and-such reason instead of just leaving them to assume “Canonical’s trying to take over in a massive power grab to satisfy Microsoft considering buying them out.”

I guess I’m trying to say, we need a Blog Post and a FAQs page. IMHO, it would go a long way.

Edit: This is like the third time I’ve edited this, but here’s another idea. Most users out in the broader community have not heard of a lot of the fancy new features that Snap has and competitors don’t, such as progressive releases or refresh awareness. A “Features” page elaborating on new stuff that Snap can do and other systems like Flatpak and AppImage can’t would also help. Even for myself, I can hardly keep track of all the developments, it’s moving so fast.

[spyke]

I don’t like talks about “very-very complicated store infrastructure”. I can run JFrog Artifactory or similar solutions and host my own registry of thousands of packages in minutes, make them scale globally, organize CDN, authorization (SAML/oAuth/Federated), policies, tracks/channels, package metadata, dashboard, etc. The only difference I see with Snapcraft Store is an ability to put some pictures and a video. Make a kubernetes config or something that can be done in one click. With today’s tools and container deployments package repositories should not be complicated.

[rogue]

Some (most) users make most (some) decisions based on perception not logic (due to lack of time, understanding or desire to try, some users rely on others experiences, etc).

As in the case of: Mir vs Wayland or Unity vs Gnome, it will not win the best, from a technical point of view, but the one that is perceived as the best. PR is very important and was ultimately instrumental in adopting Wayland and Gnome.

Snap is in the same situation vs Flatpak (it’s a war). Canonical does not have the same PR machine as Red Hat + Fedora ++ so it will be much harder for it to impose a product.

Snap’s big problems are:

1. startup speed;
2. themes;
3. permissions. A better way to inform and get the user’s consent (at least I need to be informed what to do to get that permission). Must be persistent.
   These 3 are very important because they are visible and persistent every time an application is started. Failure to resolve them will result in loss of support from regular users + the anti-Snap PR machine can use them as arguments (which can be “understood” by the user) = loss of war.

Startup speed also affects the perception of performance, so improving it also leads to improving “performance”. However some effort must be made in this direction as well.

If duplicate strip libraries can be implemented and work, it would largely eliminate complaints about startup speed and application size (disk and memory) so it must be zero priority. Started now not in a month or two.

Any other way to reduce startup speed must be investigated and implemented. 1-2 seconds more than the standard package is the maximum accepted.

Quite important:
4. lack of an easy-to-use mechanism for: delaying, banning or updating now. In fact the ability to control and be informed about certain aspects of snap(d) with a gui would be necessary. It must be available in all distributions Maybe in Snap Software;
5. size;
6. the centralized store;

7. still is a perception “for Ubuntu”. @ G.S.1 is right (a blog post is a good start but clarification is needed more “broadly”).

After implementation 1-5 you will need a PR campaign (youtube, sites, press, etc.) for combating old perceptions. The longer they last, the more exponentially the effort required to lower them will increase.

Snap has the potential to greatly help Linux but needs to be improved to increase adoption.

[G.S.1]

I think a major issue is that if I am a desktop user of Snap, I don’t know or care about IoT or Servers. I care about how Snap performs generally against Flatpak and AppImage. Even though there’s a lot of cool stuff for technical users that the competitors don’t have, my perceptions are very similar to what @rogue said.

The point is, as an average non-technical user, what incentive is there for me to use Snap instead of the competition? What feature does Snap have that the competitors don’t have that matters on the Desktop? What does Snap do better than everyone else?

That’s where, if I got into a conversation with anybody about Snap and Flatpak, I’d struggle. Snap just all-around for average users sounds like a worse version of Flatpak except that it includes the Store by default and Flatpak needs Flathub installed afterwards. That’s it. I know and appreciate that Snap has features for IoT and Servers, but as a desktop user, those don’t matter. Experience does, and the experience is almost completely subpar. Why would I use it? Why wouldn’t I just install Flatpak and Flathub and use that instead?

And look, I like Ubuntu. I’ve been a user since 11.04. But if someone who used Fedora asked me point-blank why she should consider using and installing Snap on Fedora, I would be forced to say that there is almost no reason whatsoever why you should do that. That’s a problem.

@sabdfl Maybe I’m missing something. What exactly are the incentives here, in your mind, for users to install snap?

[G.S.1]

I know that this is a major change in scope, but I still wonder at times if Canonical and the end-users would be happier if Snap and Flatpak set their focus.

Snap doesn’t really appear to have any advantages over Flatpak for the average desktop user, but has several major flaws in that experience. Flatpak runs shockingly well (at least on Fedora) now with imperceptibly different load times and smaller app sizes, and Flathub has a good collection of apps.

It’s probably very early to be saying this, but I could absolutely see a day where Snap decides to focus solely on the Server and IoT markets. This frees Snap from having to worry about those things like theming and load time and end-user experience and lets the Snap developers focus on where Snap is most innovative. Meanwhile, Flatpak (which doesn’t run on IoT or Servers) could focus on delivering desktop applications. The community would be rallied around one standard and most of the current misgivings about Snap on the desktop would immediately disappear.

Furthermore, with Snap now under-the-hood, it could be an impressive way to build a durable, reliable, and secure operating system similar to Ubuntu Core. Even Fedora’s impressive OStree and RPM-OStree has nothing on what Snap could do for the internal components.

[ogra]

@G.S.1

It’s probably very early to be saying this, but I could absolutely see a day where Snap decides to focus solely on the Server and IoT markets.

It did from 2014-2016 and then we added the initial desktop support to snaps, note that snap is far older than flatpak and has even been used in commercial setups before this (in early 2016 dell released snap based IoT gateways, flatpak was announced about half a year later, shortly after snap support for desktops was announced)…

regading your “what does snap provide over others” … take a look at “snap revert” to just point out one example, or the ability to install multiple versions of a snap alongside …

snaps are generally smaller (due to high compression of the squashfs (which in turn costs startup preformance)), do delta updates by default (very small downloads), can ship combined server/client app bundles, cli frontends with the latest version of the cli tools included etc … along with that (and a gazillion of other features i forgot), there is snapcraft which makes it unbelievable easy to package something for linux nowadays. this is indeed less interesting for the end user but devs that i talk to are most of the time really thrilled by the ease of packaging a snap. together with store channels (edge/beta/candidate), the ability to hook the channels up with CI systems and auto-builds, maintaining software becomes super easy …

EDIT: note that i also never get why people compare the two, snap is a general purpose packaging format designed to package anything and to achive very complex tasks (from bootloader snaps, over kernels up to desktop apps) while flatpak is a delivery mechanism for desktop apps (and very good at that, but still just doing this one small task here)

[sabdfl]

Rogue’s list of top three things seems like a good set of priorities, and I understand good work to be under way on all three.

As for controlling updates, you CAN do this, and it will get smoother on the desktop over time. There are good ecosystem health and hygiene reasons not to revert to the old behaviour of updates-maybe-if-someone-cares, but there are also good reasons to give desktop users better control, and we will.

Size is an interesting one, I like the de-dup idea, and would support snapcraft work or patches to walk publishers through the process.

As for a centralised store… there’s nothing in snapd’s license that forces you to use the global store. The people who are actually working on that have a very long list of things that we and customers want to do, and it’s a lot more effective for snap users for us to progress those as a priority. None of this has slowed actual publishers from pushing actual snaps.

I know for a fact that the team are a delight to work with. I also know that nothing that team can do will be good enough for people who refuse to use stuff from Canonical on principle. You just can’t get too wound up about those arrows, it isn’t worth your valuable time or energy.

Do good work. Have fun doing it. Appreciate the appreciation from those who appreciate it. Don’t sweat the flack from people who demand you do large amounts of stuff for them for free when you know full well they will just find some other reason to call you a terrible person.

[sabdfl]

It isn’t my place to critique a competitor. If I have even the slightest misconception in that critique, a torrent of abuse ensues, and even if get it exactly right, the commentary is inflammatory. So let me just say competition is great, I enjoy competing with Red Hat, and I’m proud of the work we do.

I am motivated to deliver a profoundly more secure compute environment for everyone who chooses Ubuntu. Snaps are a tremendous step forward to that goal. I also care about user experience - I think our work in that regard over the years is a good track record, it’s certainly been widely imitated by our competitors - and all the same people are engaged around snaps.

There are always glitches and controversies when you’re trying to do something that hasn’t been done before. And yes, we set out every day to do things that haven’t been done before. The fact that critics won’t recognise or internalise that doesn’t make a difference.

But controversy and bugs and glitches are no reason to give up. All my heroes were controversial. Many of them went to prison for being controversial. Online opinions from competitors and their users are not a reason to hesitate when we think we’re doing the right thing.

[Recydywa]

@rogue

Permissions. A better way to inform and get the user’s consent (at least I need to be informed what to do to get that permission). Must be persistent.

I consider this as the biggest problem with snaps.

Especially if you take into account that gtk-common-themes provides already many themes and there are also other themes packaged as snap. Which I hope soon won’t be needing the copy & paste of the commands to make them usable.

Can anyone point to the current state of that issue. The permissions aren’t easily discoverable for ordinary users. And that sometimes means end user has program that doesn’t work.

There is qBittorrent snap which needs to have two permissions enabled to be functional. Otherwise nothing will download and the user doesn’t get any information why it doesn’t work.

Also there is a problem of “Read/write files on removable storage devices” which as far as I can see is disabled for every snap. Again users have no idea why they can’t access those devices.

https://www.reddit.com/r/Ubuntu/comments/gxtxyf/snaps_dont_have_sane_permissions_outofthebox/

[jamesh]

On the desktop side, I hope to improve a lot of this via xdg-desktop-portal: the same tech used by Flatpak. We grant access to the service via the desktop interface, which is plugged automatically for any snap that asks for it.

Permissions are then handled just in time, and without specific prompts when possible (for example, when the user picks a file via the FileChooser portal, it is assumed they want the application to access that file).

In most cases, I would see snaps requiring users to manually connect interfaces as a failure. One of two things should happen:

1. the snap author should request a store assertion to allow the interface to automatically connect. This is generally granted when a user would expect an app to have that access. For example, it makes sense to grant a video conferencing app access to the camera and microphone by default.
2. the snap author should switch to safer APIs that don’t require the same level of privilege. For example, you can use the network-manager interface to be notified when the Internet connection goes up or down, but it also lets you reconfigure network interfaces. If all you need is connectivity status, then it would be better to use xdg-desktop-portal’s network status API (which your toolkit might handle automatically if you aren’t using an NM specific API).

[ivo.cavalcante]

Just my two cents.

I’ve read the whole thread and agree with most point of views. Mine is that there really is a general rejection of Snaps, and that’s because of mainly two points:

1. Inability to disable auto-update feature.
2. Aggressive pushing of Snaps without proper communication and instructions on how to change the behavior.

As for item 1, I’ve also read the main thread where it’s been discussed and every point in favor of the auto update is valid. However, not giving the user any choice beyond adopt the way it is or leave seems very inflexible. One could put every bit of warning, make user go through different windows if really wants to disable, but it should be doable; there must be a third option, neither accept as is or go away. I don’t intend to be rude and I personally adopt Snap the way it is - in fact, I believe I trigger updates manually more often then the auto feature - but wouldn’t adopt it in enterprise environments unless we had a company store on Snapcraft, but most users don’t.

As for item 2, I also see no problem but it should be broadly communicated - I mean, like some important and very common applications will, by default, be installed as Snaps (I’m looking at Chromium as example) and this is the way to revert/avoid such behavior (as previous item, should be doable, at least for now). Seriously, just informing the users would make them way less angry.

I like Snaps, like the technology and believe it can achieve things other formats can’t do - here, Ubuntu Core is an example. But PR on the technology is really being handled badly.

Again, I mean no “harm” , just wanted to give my opinion as end-user and long term Ubuntu user.

[BillDietrich]

My two cents as a normal desktop user.

IMHO, some changes Canonical/Snap could make to eliminate most of the objections:

1- Support an “update never” setting for a snap. Perhaps there could be a mechanism for
notifying that an update exists, that the update fixes security issues, and/or current version is past EOL. If this change is in progress now, announce it now, quell some of the hate.

2- Open-source the Snap store software. If it already is open-source, say so.

3- Have some kind of policy board overseeing the store, that includes outside (non-Canonical, non-Ubuntu-derivative) people.

4- Ban use of any “deb that actually installs a snap” packages. Really a distro policy issue, but snap could state it as the preferred policy, and Ubuntu should enforce it.

5- Allow Ubuntu system owner to set policies such as “I don’t want snaps in my system”
and “prioritize apt first” in the Ubuntu Software application.

Some of these are perception issues, some are setting changes a normal desktop user really should not do, or should not care about. But it’s important for Canonical/snap to react to the hate and the FUD, and be seen to be giving more control to users and more openness in the store.

Thanks.

[predr]

It’s not distribution users who are rejecting snaps its distribution developers! Snaps solve many Linux problems for users and application developers. However in the process they create some problems for distribution developers. Of course they are not going to like that.

I had reservations about snaps until I listened to @popey on some podcast talk about lessons learned from past attempts and then it all clicked for me (pun intended). So I think Canonical needs to better communicate reasons behind snap design decisions and problems snaps solve to a wider audience for faster adoption among users and application developers.

Keep calm and snapcraft snap