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

Hey Linux Mint.... 2010 called and they want their UI back.

To be honest, I don't really care what year a UI comes from, I'm more interested in whether it works.
I tend to like furniture made of real wood over self-consciously modern uncomfortable chrome-y crap too.

And if you want to convince them that snaps are a good thing

For the record, I have no intention of doing that. I don't use snaps myself, and I'll happily tell people how to avoid using them. I've done so, in fact, on this site.

Containerised applications, in general, serve a purpose, just as distros serve a purpose, but I don't really care about which containers or distros people choose to use, or not use.

What I do care about, though, is people wasting our time and energy on cannibalism, which harms our chances of achieving our objectives as Linux gamers. There's plenty of reality-based discussion to be had about the challenges we face as a community. We don't need to make up more.

As a concrete example, Phoronix has some useful stuff, but you can't send people there in case they accidentally read the comments. I don't want gamingonlinux to be like Phoronix. I'd rather Phoronix wasn't like Phoronix, too.


Last edited by CatKiller on 4 Jun 2020 at 12:20 am UTC

I don't like Snaps anyway. I like flatpaks better, but to be honest I could care less about either of them. I rarely even use them.

Lol!! What an interesting read of comments. Y'know, one of the biggest draws of Linux is choice, if not the best thing about it. What has transcribed over the course of 5 pages is individuals going round and round with what boils down to choice. This isn't that complicated, I promise you.

If you like Snaps, utilize them. If you don't like Snaps, don't use them. That's it. There is no more. One's reason for or against are valid to each individual. No one gets to decide what works or doesn't work for another.

What I do care about, though, is people wasting our time and energy on cannibalism, which harms our chances of achieving our objectives as Linux gamers. There's plenty of reality-based discussion to be had about the challenges we face as a community. We don't need to make up more.

Hey, what did you expect from a bunch of Linux enthusiasts? Of course we've all got our priorities, but you'll always see a backlash when a company does something that can in any conceivable way be seen as against the spirit of software freedom. Any signs of vendor lockdown will not go down smoothly.

It would be nice if there was less knee-jerk involved, but that's the nature of conversations on the Internet. Of course, I don't think Linux is at a particular disadvantage here. People argue about software choices regardless of platform.

Also, what was that about wasting time? Isn't this a gaming website? :D

As a concrete example, Phoronix has some useful stuff, but you can't send people there in case they accidentally read the comments. I don't want gamingonlinux to be like Phoronix. I'd rather Phoronix wasn't like Phoronix, too.

Phoronix comment threads tend to quickly descend into crap slinging matches. It's just not worth wading through the festering muck for the rare pearl.


Last edited by tuubi on 4 Jun 2020 at 8:03 am UTC

Really? 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.)

Ah yes. Another sinister conspiracy...

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.

Really? 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.)

NONE of the snaps I've installed can even see my data partition exists, let alone access it.

https://snapcraft.io/docs/removable-media-interface

Thanks for the link, though a little explanation of why you were sharing it would have been much appreciated at my end.

Is `removable-media` something that can be set up by whoever is building the app? I seem to remember something like this being announced awhile ago, and I was actually quite excited when I heard about it. Unfortunately, none of the apps I tried after that had been built with this feature turned on or something, because, as I said, they didn't see my partition.

If this is the case, then the problem reflects less the short-comings of Snaps as the shortsightedness of the builders putting the snaps together ... but the result is the same, and it simply isn't a problem I've had with Flatpak or Appimages --- for whatever reason.

If, on the other hand, `removable-media` is a setting that I could turn on at as a user, then that's something else entirely; though, I don't infer this is the case from the minimal discussion at the page you linked.

Thanks for the link, though a little explanation of why you were sharing it would have been much appreciated at my end.

Snaps are sandboxed; they can only access resources outside the sandbox through a connected interface. The interface that controls file access outside the home directory is that removable-media one, which allows access to the directories listed on that page.

I 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.

The link was to show you both the existence of the restriction and the existence of the mechanism for creating the connection.

In general I have 2-3 bleeding edge software packages which are not packaged for distribution or too old. I do build custom system components, but that is unrelated. Blender never gave me any problem as is and for Krita I used appimage but gone back to distro version. All the rest is from distro. Don't feel the need for a system like snaps at all. Sometimes I use chroots and docker containers and virtual machines for development, but that will not be solved by any of these phat package systems. It is not that useful to be forced upon everyone, but remembering systemd it quite likely will be forced so Canonical will be able to make some $$$.

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 Jun 2020 at 1:36 pm UTC

Really? 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 Jun 2020 at 7:18 pm UTC

Well, 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

I 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.

!link

The interfaces can be autoconnected.

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

For 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.

What 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.

What 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.

What 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?

who 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

In 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.