Every article tag can be clicked to get a list of all articles in that category. Every article tag also has an RSS feed! You can customize an RSS feed too!
We do often include affiliate links to earn us some pennies. See more here.

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

By - | Views: 44,814

The Linux Mint distribution team put out another of their monthly updates, and this month was quite interesting.

In the past the Linux Mint team had been quite vocal about Snaps, the next-generation Linux packaging system backed by Ubuntu maker Canonical. Like Flatpak, they're trying to redefine how Linux users install packages. The main issue here it seems (from what they said) is that Snaps are more locked-down. They compared Snaps to using proprietary software as you "can't audit them, hold them, modify them or even point snap to a different store", it pushes Ubuntu directly and Snaps are done in the background.

Mint's founder Clément Lefèbvre has said that with Linux Mint 20, they will push back firmly against Snaps. Currently in Ubuntu, which Mint builds off, Chromium is an empty package which installs a Snap (info) so the Mint team will ensure it tells you why and how to go and get Chromium yourself. Additionally, by default APT on Mint will not let snapd get installed but you will be able to do so manually.

NVIDIA users rejoice! NVIDIA Optimus is to get better Mint support, with their included applet being able to show your GPU and select what card to use from the menu.

Optimus support goes further though, as they will also now fully support the “On-Demand” profile too in the MATE and Cinnamon desktops directly. You will be able to get a menu option to run something with the more powerful NVIDIA GPU. Like we've seen GNOME be able to do with the 3.36 release:

As for theme changes, the additions and tweaks to colours they previously announced will not happen due to a fair amount of negative feedback. They're not stopping though, instead they will seek feedback about each colour option individually during the Beta period of Linux Mint 20.

See the Linux Mint monthly update here. Their attention to the small details are always nice to see.

Article taken from GamingOnLinux.com.
20 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
68 comments
Page: «6/7»
  Go to:

ronnoc Jun 4, 2020
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
randyl Jun 4, 2020
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
Whitewolfe80 Jun 4, 2020
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
Bestia Jun 4, 2020
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.

link

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.
jarhead_h Jun 5, 2020
Cool. Now if we could get rid of Flatpack too and default to AppImage that would be awesome.
GBee Jun 5, 2020
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.
14 Jun 5, 2020
View PC info
  • Supporter Plus
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.
Purple Library Guy Jun 6, 2020
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.
Nevertheless Jun 7, 2020
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?
CatKiller Jun 7, 2020
View PC info
  • Supporter Plus
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.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.