Linux Mint votes no on Snap packages, APT to block snapd installs

It's worth noting that for those of us who run KDE Plasma, Snaps (and Flatpaks, for that matter) - Can be enabled or disabled with the click of a button in the Discover software center.

See ---> KDE Plasma Discover Sources Settings

Also worth noting are the reasons why someone might want to run certain apps as a Snap. For desktop users, a good use case might be the need to run an older LTS, like 18.04 (I'm looking at you, KDE Neon), but needing an updated version of a certain app. Or, in a production environment, having a standardized version of said application.

For a singular application, I'd personally would rather run as a Snap that going through the hassle of adding a PPA and dealing with the potential problems that said PPA may cause later on during a distribution upgrade.

TL/DR: Use KDE Neon


Last edited by ronnoc on 4 June 2020 at 1:36 pm UTC

Quoting: Tuxee

Quoting: Pangaea

Quoting: TuxeeReally? Showing an image of a flatpak package to prove the bloatedness of a snap? Really? (Besides I can't find a XNView snap to see whether this is different.)

Maybe read what I posted then, instead of barking up wrong trees. With bloat I always talked about the hilariously ill-named flatpaks. I have never used Snaps and don't intend to, so have no idea if these are bloated too or if the downsides are more about the Canonical lock-in.

Sorry. Yes you were mentioning flatpaks. (From my experience snaps are not exactly bloated.)

The "XNView MP" flatpak on Fedora (through Flathub) is only 191.1MB (install size) on disk for me. Installing apps across DEs invovles a lot of overhead in every case. All the missing libraries and frameworks need installed. That will happen on Flatpak, Snaps, AppImage, or your distro package mangler. If you're running Gnome and install a KDE app that has a lot of dependencies those will get installed no matter the source system. What it looks like is that person needs a lot of stuff that isn't on their system already. With Flatpaks once that runtime environment is installed all apps that use that version will share it. Although I believe they must be from the same flatpak repo so Fedora and Flathub runtimes aren't shared since their repo sources are different, or at least that has been my experience installing GIMP, Inkscape, and a couple other apps.


Last edited by randyl on 4 June 2020 at 7:18 pm UTC

Quoting: g000hWell, it's a good result as far as I'm concerned. Not a fan of alternative packaging systems. I just like to use the main one for the operating system, i.e. APT for Debian (and Debian clones) and RPM for Redhat (and clones).

Looking further into Snap myself, I notice that it adopts an update schedule very similar to Windows 10, i.e. Preventing the end-user from halting updates if they want to do so. Also Snaps introduce a bunch of file system mounts i.e. one extra mount point for each Snap which is active. No need to complain that you can turn this stuff off or hide it if you want to - My point about these two aspects is that it is the default behaviour and it is fiddly to deactivate.

was more a fan of deb packages because well am lazy and the thrill of using the command line for my packages is well and truly over

Quoting: CatKillerI think that the snap side of the interface has to be enabled by the snap maintainer, but the user side of the interface needs to be enabled by the user. I understand from what people have said elsewhere that you can enable the connection through the snap store, but I've never tried it, as well as creating the connection with the snap command, which I also haven't tried.

There is permissions settings in the snap-store for every app. So you can grant or revoke permissions for any single snap.



The interfaces can be autoconnected.

https://snapcraft.io/docs/permission-requests

QuoteFor the majority of interfaces, as well as for devmode, there are no special considerations. They can be used to develop strictly confined snaps, access system resources, and publish snaps to the Snap Store without any manual oversight.

However, there are specific circumstances when a manual review and approval process is required, and these circumstances are when a snap requires one of the following:

1. classic confinement and publishing to the Snap Store
2. automatic alias creation for an executable with a different name to the snap name
(see Application aliases for more details)
3. automatic interfaces connection with an interface that defaults to no auto-connection
4. a new track, often used to provide a stable version path with production grade applications
5. use of a more permissive interfaces, such as personal-files
In all of the above cases, a snap’s publisher needs to make a permission request in the store-requests category of https://forum.snapcraft.io.

Cool. Now if we could get rid of Flatpack too and default to AppImage that would be awesome.

Quoting: Purple Library Guy

Quoting: GBeeWhat the Mint packagers seem most concerned about is their own demise. If the world moves to Snap then there will be less opportunity for them to screw with code before it reaches the end user. This is a future I can get behind

That's ridiculous. If I choose to use a particular distribution, I want the people in charge of that distribution to have control over the packages. If I wanted the packagers of a different distribution to have control, I would have chosen that different distribution. Duh.

You seem to be misunderstanding the difference between distro level customisation and packagers silently modifying and f***ing up applications in all sorts of ways for no good reason and usually without end-users even being aware. Packages being created by _developers_ of the original application (you decided to ignore that part of my comment) would avoid a lot of instability, bugs, security flaws and provide consistency in application behaviour but would not prevent distros customising configurations, themes and generally deciding the mix of default packages to give their own spin.

I don't know where I stand on snaps, but I do like that Mint is making another step to make themselves distinct from Ubuntu. I'm not saying I hate Ubuntu either. I just like choice. But I don't like when you have 20 options and each of them are barely different at all.

Quoting: GBee

Quoting: Purple Library Guy

Quoting: GBeeWhat the Mint packagers seem most concerned about is their own demise. If the world moves to Snap then there will be less opportunity for them to screw with code before it reaches the end user. This is a future I can get behind

That's ridiculous. If I choose to use a particular distribution, I want the people in charge of that distribution to have control over the packages. If I wanted the packagers of a different distribution to have control, I would have chosen that different distribution. Duh.

You seem to be misunderstanding the difference between distro level customisation and packagers silently modifying and f***ing up applications in all sorts of ways for no good reason and usually without end-users even being aware. Packages being created by _developers_ of the original application (you decided to ignore that part of my comment) would avoid a lot of instability, bugs, security flaws and provide consistency in application behaviour but would not prevent distros customising configurations, themes and generally deciding the mix of default packages to give their own spin.

But Snaps would prevent all that. They're centralized to Ubuntu and can't be modified by other distros that carry them. That's the point of Mint avoiding them and hence the point of the article. If you're talking about something different you should perhaps signal that you're shifting off topic.
But in any case, no I'm not. The thing is, you're looking at things from a packager's perspective, but I'm looking at things from an end-user perspective, and as an end-user I have no real way to judge between packagers' ideas of what's a good package and Distro maintainers' ideas of what makes a good package, but I have some notion who the distro people are and basically no idea about the packagers. I don't choose between packagers, I choose between distros. So my instinct is going to be that no, I want the people I have some ability to choose between, to have the power to make alterations. Come to that, if I'm acquiring a whole system, I want the people testing it as a whole system to be deciding what's good security, not the people creating tiny individual bits in isolation. If that upsets some package maintainers, that's a pity, but too bad.

Quoting: Purple Library Guy

Quoting: GBee

Quoting: Purple Library Guy

Quoting: GBeeWhat the Mint packagers seem most concerned about is their own demise. If the world moves to Snap then there will be less opportunity for them to screw with code before it reaches the end user. This is a future I can get behind

That's ridiculous. If I choose to use a particular distribution, I want the people in charge of that distribution to have control over the packages. If I wanted the packagers of a different distribution to have control, I would have chosen that different distribution. Duh.

You seem to be misunderstanding the difference between distro level customisation and packagers silently modifying and f***ing up applications in all sorts of ways for no good reason and usually without end-users even being aware. Packages being created by _developers_ of the original application (you decided to ignore that part of my comment) would avoid a lot of instability, bugs, security flaws and provide consistency in application behaviour but would not prevent distros customising configurations, themes and generally deciding the mix of default packages to give their own spin.

But Snaps would prevent all that. They're centralized to Ubuntu and can't be modified by other distros that carry them. That's the point of Mint avoiding them and hence the point of the article. If you're talking about something different you should perhaps signal that you're shifting off topic.
But in any case, no I'm not. The thing is, you're looking at things from a packager's perspective, but I'm looking at things from an end-user perspective, and as an end-user I have no real way to judge between packagers' ideas of what's a good package and Distro maintainers' ideas of what makes a good package, but I have some notion who the distro people are and basically no idea about the packagers. I don't choose between packagers, I choose between distros. So my instinct is going to be that no, I want the people I have some ability to choose between, to have the power to make alterations. Come to that, if I'm acquiring a whole system, I want the people testing it as a whole system to be deciding what's good security, not the people creating tiny individual bits in isolation. If that upsets some package maintainers, that's a pity, but too bad.

For me it's mostly a matter of trust. Like you I choose my distributions carefully, I don't like using PPAs or the AUR, I don't like using proprietary software outside a sandbox.
When I hear that snaps are packaged by someone I don't know, put on a canonical server, which uses a proprietary snapd to deliver that software to users, who think they just installed an apt package, then I'm glad the Mint devs oppose it.
Intuitively I like flatpaks morr. I use Flatpak Steam, because it's great to have one sandboxed Steam installation for different distros that solves most possible compatibility issues, but I must admit there are open questions about Flatpak/Flathub security too. How regularly are packages updated? Who maintains packages? How transparent are package contents?

Quoting: Neverthelesswho think they just installed an apt package

You really should read the link that Liam gave. There is exactly one package that does that, which was widely publicised, and the reason for picking that package for dogfooding snaps is

QuoteIn summary: there are several factors that make Chromium a good candidate to be transitioned to a snap:

• It’s not the default browser in Ubuntu so has lower impact by virtue of having a smaller user-base


• Snaps are explicitly designed to support a high frequency of stable updates


• The upstream project has three release channels (stable, beta, dev) that map nicely to snapd’s default channels (stable, beta, edge). This enables users to easily switch release of Chromium, or indeed have multiple versions installed in parallel


• Having the application strictly confined is an added security layer on top of the browser’s already-robust sand-boxing mechanism

as given in Liam's link.

If Mint don't like Ubuntu's packages they can maintain their own.