Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Flattr, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

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

By - | Views: 24,328

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.
21 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
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.
See more from me
74 comments
Page: «6/8»
  Go to:

Pangaea 4 Jun
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.)

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.
Tuxee 4 Jun
Pangaea
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.)
Nanobang 4 Jun
CatKiller
NanobangNONE 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.
CatKiller 4 Jun
NanobangThanks 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.
slapin 4 Jun
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 $$$.
ronnoc 4 Jun
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 4 Jun
View PC info
  • Supporter
Tuxee
Pangaea
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
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 4 Jun
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 5 Jun
Cool. Now if we could get rid of Flatpack too and default to AppImage that would be awesome.
While you're here, please consider supporting GamingOnLinux on Patreon, Liberapay or Paypal. We have no adverts, no paywalls, no timed exclusive articles. Just 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!

You need to Register and Login to comment, submit articles and more.


Or login with...