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

I think this is also a great path forward, but this will require additional community outreach which neither GNOME nor Canonical seem to be doing at the moment. Some outreach that needs to be done:

  • The PR for file picker portal support in electron is stuck at the moment: https://github.com/electron/electron/pull/19159
  • There is no current work to add support for camera and audio portals into electron.
  • There is no current work to add support for any portals in Java Swing.
  • Many applications need to be ported to these new api’s and many snaps need upstream inclusion, updates to the latest and greatest desktop helpers/extensions etc.

Asking app developers to support the portal api’s directly is not the right way forward, in my opinion. This needs to be supported by the toolkits, and we need people familiar with these technologies to write that support.

I am 100% convinced that Canonical cannot do this outreach on their own. Fixing app distribution on Linux desktop requires so much work that the only way we can achieve this is by collaboration. Adding portal support is a great step in the right direction. Glaring issues like snapd’s lack of internationalization in snap metadata can be easily fixed by using existing standards like AppStream. I understand the security issues of AppStream, but not using it means “app metadata” is one more issue that Canonical need to fix on their own. You simply can’t expect Canonical to have enough developer resources available to solve all these issues at once.

So in my opinion, it is vital for the future of snaps that you increase collaboration with the wider desktop Linux ecosystem. I’m not entirely sure how to do that. However, responding to criticism with “people who don’t like Canonical will never like snaps” seems counter-productive. Sure, the proprietary nature of the snap store will hardly be an issue for the wider ecosystem of app publishers, but it is a big issue for the other people who are trying to fix Linux desktop app distribution. You need good relations with them because you simply can’t fix all these issues on your own. It doesn’t matter that these people will never use snaps. What matters is that these people see Canonical as a good open-source citizen worthy of collaborating with.

Sidenote: portal support for snaps on 18.04 is still wonky; I have a snap that consistently crashes when it tries to use the files portal on 18.04. Where should I report issues like that?

2 Likes

None of those alternatives are open source releases of GitHub’s server code, however. If a third-party wants to write their own snap store neither we the community, nor they Canonical will stand in their way.

1 Like

In fact, I remember someone from Canonical published a proof of concept open source snap store a few years ago, but nobody was interested enough to pick it up and actually run an alternative store.

3 Likes

That would be this: https://github.com/noise/snapstore

2 Likes

The problem with this and any Snap Store is, once again, assertions. All Snaps are signed with a Canonical private key on the Store Server side. Thus, the user must install a forked snapd on their system with different public keys to use a different server.

The only thing the hardcoded assertions key currently enforces is that each snapd instance is only connected to a single snap store. A different distribution like Manjaro could very well ship a modified snapd to their users which points at their own store. Manjaro chose to use the snap store hosted by Canonical because they like the advantages that gives them. This is no different from how Linux Mint used to point apt on their devices to the Ubuntu repo’s in the beginning and switched to their own repo’s after a while. Manjaro will be able to switch to their own snap store if that makes sense to them. Note that this is exactly what the Ubuntu Touch project did. They are using “click”, the precursor to snap, and they created their own store and Canonical helped them with the transition from the Canonical store to their own store.

So I strongly disagree that “any open-source 3rd-party effort is pointless”. Snapd is a great package manager and any distribution can take advantage of that, just like they already do with apt.

However, in this context, there are two limitations in snapd that apt doesn’t have:

  1. There is no user-accessible config to change the snap store. This is something that would be trivial to add to snapd if people are interested in running other stores, though this feature would need a lot of design work to make sure that the user experience of switching to a different store is good. For example: what happens with the already installed snaps? Given that on some devices, the kernel itself is also a snap, this is an important issue to solve before making it possible for users to change this.
  2. Each device can only use a single store at one time.

The second point was a conscious design choice by the snapd developers with two main motivations:

  • The first motivation is that having only one store per device solves a lot of the user experience issues that ppa’s have. Note that this is not “everyone using snap should use the Canonical store”. What they actually want is “every device using snap should only use a single store”, regardless of who runs that store. Canonical’s experience with ppa’s showed them the disadvantages of having each device connect to multiple separate “stores”. Flatpak is currently experiencing the same issues; hence their push to get as much apps as possible into Flathub, instead of each publisher hosting their own Flatpak repo like they did in the beginning.
  • The second motivation is that having only one store makes a lot of stuff easier to implement. The snapd developers have not implemented this functionality to make their jobs a lot easier. Though on this forum some snapd developers have showed that they are open to the idea of someone else adding this functionality to snapd. They will simply not add it themselves.
5 Likes

[ bad faith ON ]
As if actual things regarding snap were already well enough designed to ensure a good UX.
[ bad faith OFF ]
Improvements are real, and are really still needed today, on what snap offer. One thing after the other. There is a cruel lack of fancy, easy, eye candy, full featured snap manager aiming at average desktop users.

The possibility of other snap-stores are interesting ( I can totally see why the team behind a distro would want that ) and their relative limitations ( one store per device ) are totally understandable.

But details matter. UX is not a detail, especially when targeting desktop-users. Strange how the « big lines » or « global concepts » of snap sound very well thought, but their [ realization / what happens in front of average users’ eyes ] are not so glorious.

What is the problem with @jeremie’s comment ?

He points towards the same kind of very strange ways of showing things to the users…
logiciels-ff-01.png
↑ Here is an obvious lack of distinction and biased sorting ( coming from https://forum.ubuntu-fr.org/viewtopic.php?id=2054335 where someone has installed Firefox as a snap without really noticing it I guess + it’s U18.04 so this bug → Firefox snap 77 cannot download anything? other example here ).

Now if people gets confused with snap-store, maybe it’s also very easy to fix : just mention on the store front page something like « here you will only find the finest app’s in all shiny glory snap package ».
Maybe it’s already like that, i don’t know, snap-store is not installed by default on Ubuntu Budgie.

Self-explain. Teach. Trigger curiosity. Never hide !

If people tell “you” they are confused, it’s very probably because “you” forgot to show or tell them something - a thing that was obvious for “you” but not at all for them. It’s a language/communication/design/layout issue. Maybe the ability to install both snap-store ( for only snap ) and (gnome-)software ( for only apt/.deb official repositories ) ? One should not exclude the other.

If not addressed, those « language » issues end up perceived as intended attempts to « impose » something.


( later ) Another example of « I installed something without noticing it was a snap and my app’ does not work as expected » → https://discourse.ubuntubudgie.org/t/qbittorrent-and-or-transmission-cannot-access-mounted-hdd-in-mnt/3860 It’s just so annoying as voluntary helper to again and again point people towards the permissions settings, only because app-snap itself does not have the politeness to do it.

We did have a look at what would be needed to add portal support in Chromium, on the basis that this would eventually percolate through to Electron:

Similar to that Electron PR, there was similar push back against simply porting over to GtkFileChooserNative, over concern for supporting old versions of GTK. Rather than using dlsym to check for those symbols though, the Chromium developers seemed to think coding directly to the portals D-Bus API would be a better approach to remaining compatible with those old systems. Nothing has really progressed on that front for a while though.

As far as camera/audio portals go, that is currently tied in to PipeWire. I suspect Ubuntu will eventually adopt it, but we are not there yet. It’s also requires modifications on the application side (somewhat simpler if they’re accessing devices through a framework like GStreamer).

1 Like

Thanks for the update about portal support in Chromium.

Do you mean that the camera and audio portals only work on distributions shipping PipeWire? How should applications handle some portals working and some not? Is there a way for an application to know that the camera portal does not work on that distro?

I’ve started a documentation page about portals in snaps at XDG desktop portals. However, I did not find much information about which portals are supported in snaps, and which portals are supported by Ubuntu. Is there any information available on this?

I’ll preface this by saying I don’t have much experience with PipeWire yet, so take what I say with a grain of salt. As I said earlier, it seems highly likely that Ubuntu will adopt PipeWire in the future: something like it is a requirement to continue providing features such as screen recording as we move to Wayland (where clients can’t simply screen cap the root window like in X11).

On the audio side, having a sound server that has had confinement in mind from day one is definitely a plus. We’ve added some level of access control in our Pulse Audio packages, but it hasn’t been without problems (i.e. USN 4355-1).

It’s not clear whether we’re at a point where it makes sense to recommend PipeWire to app developers yet though. The 0.3 release from February made incompatible changes to the API/ABI, and while they are promising library ABI stability that’s not quite the same as protocol stability. That’s a concern when the libraries inside the sandbox are not in sync with the host system.

Further more, the current Pulse Audio compatibility story relies on an alternative implementation of libpulse.so that speaks the PipeWire protocol. It’s not clear how old snaps using the original libpulse.so would work on PipeWire systems, or how you’d create a snap that would function on both PipeWire and Pulse Audio systems.

4 Likes

I’ve finally managed to read this whole thread and couldn’t help noticing a trend among the commenters: either you agree about Canonical’s current side (e.g. auto-updates by default; closed-source license for snap-store server, etc.), or you disagree; but I think the spectrum of possible solutions here is not just black or white, there’s some middle ground which hopefully would make both sides happy. Let me elaborate with my 2cents point of view:

  • On updates: the people that don’t want auto-updates by default claim the most important aspect to preserve from the user point of view is control. However, control for the sake of control may hamper UX for no obvious reason. Let’s really explore the reasons why a user may want control over auto-updates. I only see these:

    • Auto-updates consume bandwidth without the user knowing: this might not sound important but these days many users connect their laptop with their mobile’s hotspot, which could mean they incur in charges over big data usage. Also, tablets (some with 3G connections) are increasing in usage over laptops/desktops, and people may start to tinker and install Linux on them.
    • Auto-updates use CPU heavily when installing software: this might not be good if the user is working actively on the computer (or say playing a video-game).
    • Auto-updates may break an app if the new version brings a bug that was not present in the previous version: even if this is the developer’s fault, the user should know that this problem happened because of an update (otherwise, without knowing this, she may not be able to figure out that a temporary workaround is to revert to previous version).

    A middle-ground solution to these 3 problems above could be the following:

  1. Adopt an “update notification” approach like macOS does, which nags the user constantly about updating: offer only 3 options when updates are found: a) update, b) uninstall the app, or c) postpone update. (Arguably, this should still be considered as having “auto-update enabled by default" because there’s no option to stay in the old version.)
  2. Allow developers to side-step the update-notification only if the update is marked as “security critical”. This way, security trumps reliability so: bandwidth and CPU usage are less important than a security breach. The update would happen in the background without the user knowing. If the update breaks the app because of a bug, this is still acceptable (better to have a broken app than an insecure app). Note: to not abuse this setting on updates, Canonical could manually review each time it’s requested.
  • On the license of the server-side of snap-store: it’s fair enough that by keeping it closed source, Canonical is actually preventing many problems that could arise because of fragmentation. However, IMO it doesn’t inspire confidence to the opensource community (so it doesn’t feel “Linuxy”) to adopt a software ecosystem that has components with some degree of vendor-lockin.
    Again, I think a middle-ground solution exists. There are software licenses which represent some shade of grey in the spectrum of licensing, even if none of them would be approved by the OSI or FSF. Examples are the BSL of MariaDB (more info: https://techcrunch.com/2016/08/19/mysql-founder-tries-a-new-software-licensing-model/ or https://mariadb.com/bsl-faq-mariadb/) or the license of the Unity3D game-engine software (more info: https://blogs.unity3d.com/2018/03/26/releasing-the-unity-c-source-code/): as far as I understand, these licenses allow you to view the code (so that you can contribute fixes and propose them to the vendor for inclusion in next release) but not allow you to run it without permission.

I won’t extend myself more cause I wanted to be as brief as possible. Keep up the good work everyone.

4 Likes

I think it’s interesting to investigate what the “grey area” is in terms of licenses for the Snap Store. However, I think that “source available” licenses for the snap store might actually spark more disagreement. Although source available is great for communities which historically have used mostly commercial software, I do not think it is a good option for a Linux community. I think very few people who are complaining about the proprietary parts of the store will be happy with a source-available store.

Nevertheless, I personally would prefer a source available license over the current state, because then I could finally try to fix some bugs in the store myself. Ironically, the team building the store is one of the least responsive teams in the snapcraft ecosystem, even though the community needs their involvement the most. Given that we don’t have the source, we can’t scratch our own itch and have to rely on Canonical to fix issues.

Not quite related to the above post, but Hackaday just did an article reviewing the situation. I think the image at the top of the post says all you need to know about their article’s perspective.

While Canonical is no stranger to walking back on unpopular decisions, snap packages are almost certainly here to stay. The logistical advantages of containerized packages are simply too great when your whole company is structured around providing support for multiple versions of a Linux distribution. Conversely, the users who have strong feelings on snaps will inevitably be a small (if vocal) minority. Canonical designed snaps to be the solution to the unique challenges of maintaining a huge and multi-faceted distribution like Ubuntu, and it’s working exactly as intended.

That said, it seems unlikely that snap packages will be embraced by the larger Linux community. Currently, the repository back-end is actually proprietary. While Canonical does allow for companies to create “branded” versions of the Snap Store, it’s just a cosmetic change and doesn’t allow you to run your own server. So even if another distribution such as Mint decided to embrace the snap package format, they would have to rely on Canonical to provide the infrastructure for distributing the packages to their users. This single point of failure is bound to be a point of contention for adoption outside of Ubuntu itself.

Once again, the comments from people who tried Snap are almost universally negative. Again, the PR for Snap among people who actually care what it means is really lacking at the moment…

3 Likes

Critical point in this paragraph being rely on Canonical to fix issues. That says a lot about current problems with Snap ecosystem nowadays.

3 Likes

And also on every distro upgrade you have to add PPAs again.
With snaps I can still use LTS with up-to-date applications. Snaps are a bit slow but are improving.

I think an “open source” snap store is really a proxy for lock-in concerns with using the closed source snap store, especially for commercial products. You need at least one viable competitor if you don’t like the commercial terms of Canonical’s snap store. Snap is technically well done by a set of people who have grappled with and suffered through these (nontrivial) problems in the past. I’d like to stand on their shoulders. But I’d like to afford it too.

3 Likes

Snaps (and more generally Canonical) are under attack by people who attacking their legitimacy. Not only are you not countering these attacks, but you’re even supplying the ammunition. The long term effect is that you are being shut out of Linux distros, like we now see with Mint, and eventually that will lead to a situation where if a developer publishes his app on Flathub he reaches 100% of Linux desktops, but if he publishes on the Snap Store he reaches about 40% of Linux users. Supporting Snaps would then become redundant and developers will abandon the Snap platform. This is an existential threat to you.

If you want Snaps to succeed, you need to first of all neutralize the attacks against you by removing the basis for those attacks. Then you need to go on the attack yourselves.

Neutralizing the attack means going 100% open source, allowing users to choose a different store than the official one, and giving users back the ability to control updates. Your argument against #1 and #2 is that it’s an effort. Well, if it means the survival of the platform, then it’s worth it. Your argument against #3 is basically that you want to discover solve all the practical problems of auto-updates first, but if the platform doesn’t survive then it won’t matter.

A word about store fragmentation: store fragmentation is already here. It’s called Flatpak. What difference does it make if 3rd party stores are made using Snap or Flatpak technology?

As far as going on the attack, in addition to a PR push to publish the truth about Snaps and how you fixed the issues people had with Snaps, how about monetization, with a revenue-sharing program for distros that ship the Snap Store, and a tip mechanism to draw free-software projects and developers, in addition to the commercial developers?

You need to flip the script now while you still have momentum, because it looks like the momentum is shifting against you, and that your platform can end up being relegated to irrelevance.

4 Likes

Thank you!!! This is exactly what I am trying to say, but significantly less forcefully. I was trying to still be somewhat “nice” about it, but you cut straight to the point. You’ve summed it up better than my efforts. Well done.

2 Likes

Seriously, Snap Developers, you need to get out of this echo chamber of a forum where most things about Snap are positive-looking. Look in the broader world, and broader Linux user base, for a change: Hackaday, Reddit, Hacker News, Linux Mint, Elementary OS, Pop!_OS, the Lunduke Show, Arch Linux forums, you name it. Read the comments on those articles and posts from people who claim to have tried Snap - it’s almost all negatives. Many of these people don’t like Flatpak for various reasons either, but there are definitely more people happy with Flatpak than Snap at the moment. And so far, very few have defended Flatpak by saying “but Canonical.” I have seen people saying that Snap is the latest in a long line of failed Canonical projects, but almost nobody is defending Flatpak because they just hate Canonical or are Red Hat fanboys.

The broader negativity actually threatens the success of Snap. The main sell of Snap is that it is a universal package format. It doesn’t matter if it works on a technical level across distributions if distribution makers refuse to ship it by default. If there is a lesson to be learned from anywhere in the last 10 years, it’s that the defaults always win.

And that’s what I don’t get. Let’s pretend I was a distribution maintainer. Why should I ship Snap? Why should I? What are the advantages for me? Flatpak has almost all the apps and has a much better reputation, and it decentralizes control rather than centralizing it, and the apps don’t take 10 seconds to load. Even if I like Snap and respect it, the reputation of Snap is so bad right now in the broader community and the percentage of haters so large, I might just ship Flatpak or AppImage to avoid the community pressure and hate. To put it simply, if you were a distribution creator, the competition has significantly positives while Snap has some major, dealbreaking negatives.

You might say that there will always be haters. You do have to watch your back though when the haters are strong enough to sink the boat.

3 Likes