Snap Debate

DeaconFrost

[H]F Junkie
Joined
Sep 6, 2007
Messages
11,582
For the Linux newbs, what is all the discussion/debate surrounding snaps and why Mint is not going to enable them by default. To the newb (me), it was an easy way of installing applications. What's the counter argument...the one against snaps. I'm not trying to fan the flames, just asking out of curiosity.
 
For the Linux newbs, what is all the discussion/debate surrounding snaps and why Mint is not going to enable them by default. To the newb (me), it was an easy way of installing applications. What's the counter argument...the one against snaps. I'm not trying to fan the flames, just asking out of curiosity.

The fact that Canonical controls the Snap store bothers people.
 
They're often slow to launch/run, and often have problems with GUI inconsistencies with the desktop environment.

I try to avoid them in favor of proper packages native to the distro.
 
Interesting. I can see the issue with Canonical controlling them, as that flies in the face of the open source nature. Are flatpaks pretty much the same, in terms of a single entity controlling them?

That being said, is it better to install applications using apt and/or the distributions "app store"?
 
Interesting. I can see the issue with Canonical controlling them, as that flies in the face of the open source nature. Are flatpaks pretty much the same, in terms of a single entity controlling them?

That being said, is it better to install applications using apt and/or the distributions "app store"?

I don't see an issue with Canonical owning Snapcraft.io. Someone has to own that stuff somewhere. The problem I see is the fact that to actually get the benefit from Snap security from confinement you need AppArmor. Not all distros use that. For example on Arch I can install snapd and then install snaps but unless I enable AppArmor in the kernel and configure it all I can't get full confinement.

Flatpaks you just develop and can download and install. Distros like Elementary have adopted them and integrated them into their app stores.

"App stores" just make browsing the repos easier. Doing a sudo apt install gimp in a terminal window on an Ubuntu based distro is the same as going through their app store and clicking on install.

Personally I don't use Snaps or Flatpaks. All the software I use is typically in the repos. The only two pieces I use that aren't in the Arch repos is Google Chrome and Insync both of which are in the AUR. ;)

They're often slow to launch/run, and often have problems with GUI inconsistencies with the desktop environment.

I try to avoid them in favor of proper packages native to the distro.

The GUI issues is a big one but I do know they're working on ways to get around that without sacrificing security.
 
The fact that Canonical controls the Snap store bothers people.

I don't think the issue is really one of control, in fact assuming the software store is curated that's not such a bad thing. I think the bigger issue is the problems related to Snaps running in their own container and the resulting HDD space issues as well as issues related to Snaps not playing well outside of their container.

I run a couple of Snaps, in fact there's been a situation where I had to run the Snap of VLC as there was an issue with MPV mucking up certain dependacies resulting in VLC not working, running the Snap of VLC was the perfect solution to my problem. I can also understand why Snaps are beneficial to Linux as a whole (as well as Flatpaks) and can see that Canonical are just trying to create a standardized platform for software installation under Linux.

However, I don't like the idea of Snaps being forced onto me, especially if what I'm hearing is true and Canonical are hijacking apt installs and installing Snaps instead of apt packages, that's not cool.

I rarely use Ubuntu's software center anyway, preferring to add external PPA's to install my software or use a .deb where necessary. I've never had a problem with external PPA's from obviously trustworthy sources.
 
Biggest issue of Canonical controlling Snapcraft.io would be the constant specter of anti-competitive practices.

They'd get hell for it, but if everyone started using Snaps exclusively... no one would be able to do anything about it.

Now, on the balance, I'm supportive of the idea. I think literally everything should be containerized where possible; the same security could be attained using other means, but Snaps build that security into the framework and distribution of applications.

Main counter-issue to containerization, in general, are the various performance, usability, and creature-comfort issues involved. Those need to get mitigated ASAP.

Last, I see containerization leading to truly 'universal' apps. With dependencies and access needs pre-defined, the only last step would be for a repository to be able to compile binaries for every potential environment, on the fly if needed.
 
Biggest issue of Canonical controlling Snapcraft.io would be the constant specter of anti-competitive practices.

They'd get hell for it, but if everyone started using Snaps exclusively... no one would be able to do anything about it.

Now, on the balance, I'm supportive of the idea. I think literally everything should be containerized where possible; the same security could be attained using other means, but Snaps build that security into the framework and distribution of applications.

Main counter-issue to containerization, in general, are the various performance, usability, and creature-comfort issues involved. Those need to get mitigated ASAP.

Last, I see containerization leading to truly 'universal' apps. With dependencies and access needs pre-defined, the only last step would be for a repository to be able to compile binaries for every potential environment, on the fly if needed.

Totally. Like yourself, I'm supportive of the idea.
 
Meh, once you get over the initial learning curve, you should move on to an rpm based distro. At least if you are going to be working with linux in the IT fields. Also, Flat > Snaps. https://flathub.org/home
 
Meh, once you get over the initial learning curve, you should move on to an rpm based distro. At least if you are going to be working with linux in the IT fields. Also, Flat > Snaps. https://flathub.org/home
I find that the learning curve is mostly 'shit that Red Hat doesn't think you need' that Debian and derivatives include by default. Also, SELinux compiled and enforcing by default on RHEL, which can cause some goofiness for stuff developed primarily for Debian without SELinux in mind, even stuff as simple as piHole.
 
I find that the learning curve is mostly 'shit that Red Hat doesn't think you need' that Debian and derivatives include by default. Also, SELinux compiled and enforcing by default on RHEL, which can cause some goofiness for stuff developed primarily for Debian without SELinux in mind, even stuff as simple as piHole.

*shrug* It's not entirely untrue, but the simple fact of the matter is SELinux, much like Wayland is everyone's future regardless of how many kicking and screaming temper tantrums get thrown on the web. The massive increase in people working from home is going to do nothing but speed this up too because security is a topic that is coming up more and more.

I actually did a job interview here recently where one of the competency tests they give you is installing and setting up your dev environment from scratch on RHEL 8. The interviewer said I would not believe the number of candidates they get that cannot do this simple task.
 
I actually did a job interview here recently where one of the competency tests they give you is installing and setting up your dev environment from scratch on RHEL 8. The interviewer said I would not believe the number of candidates they get that cannot do this simple task.
Yeah... RHEL is even more restrictive than CentOS 8, and most of these folks are used to Fedora if they're used to an RPM-based distro at all. Which I get, but really it just means that they've been lazy in their approach to security. A secure CI / CD setup requires more effort than that.
 
Yeah... RHEL is even more restrictive than CentOS 8, and most of these folks are used to Fedora if they're used to an RPM-based distro at all. Which I get, but really it just means that they've been lazy in their approach to security. A secure CI / CD setup requires more effort than that.

Ya, from what I understood of the company, they have you work from home, but give you the choice of mailing you a tower or giving you a vmware key and have you setup a work environment with IT coming behind you and basically running their version of a gold disk to lock it down. It was hilarious imo, but whatever works for them. I honestly didn't understand why they didn't just provide you with a desktop to remote into since it would be cheaper and easier to implement (I think.) I didn't get that job, but it was eye opening to see where things are heading.
 
What are your thoughts on flatpaks? Same overall feelings and concerns as snaps?
 
Opinion follows... so we all want it all.. all want to depend on different versions of underlying infrastructure (libraries, services) and this creates this dependency hell issue. Mitigated by distributions as long as you stay inside their controlled "box" (which means you can't just willy nilly use later versions of whatever you want even if you think you're "justified" in doing so).

Answers to this problem.. things like flatpak which exploit concepts like "disk is free" and create "folder worlds" with all batteries included.

Another popular answer is containers, as each container can be it's own world.

What do I think? I think all of this "run/develop as fast as you can and change every second of every day" approach is sort of messy.

I like api's that are well thought out and extensible without destroying (for example). Services that maintain backwards compatibility so that you might have some hope of stability, etc...
 
Ya, from what I understood of the company, they have you work from home, but give you the choice of mailing you a tower or giving you a vmware key and have you setup a work environment with IT coming behind you and basically running their version of a gold disk to lock it down. It was hilarious imo, but whatever works for them. I honestly didn't understand why they didn't just provide you with a desktop to remote into since it would be cheaper and easier to implement (I think.) I didn't get that job, but it was eye opening to see where things are heading.
Network shares are more reliable than streaming desktops, and local software is more responsive? I abhor remoting in to work, since I have to stream my work desktop (though since it's the one on my desk, at least my stuff is all there).

What do I think? I think all of this "run/develop as fast as you can and change every second of every day" approach is sort of messy.
This is going to come to a head of sorts; but at least these schemes force developers to define all of their variables, and security folks have a better idea of what's going on so that unintentional (and intentional) violations may be mitigated if not outright prevented.
 
I'm developing a new product to manage web services, called httpc.

Later that day
: httpc now comes with facebookc to handle facebook. It's an improvement over mere facebook. Users of httpc will need to convert.

Still later that day: httpc now also comes with googlec to handle google. Again, it's better than the crap way you're doing it now, you will be forced to switch. Hopefully you're running the latest httpc. We really don't support the ancient versions (like the one from this morning).

Noonish, same day: httpc now comes with searchc which replaces googlec and bingc. Generalizes all search engines. Incompatible with ancient versions of httpc.

Early afternoon: httpc now comes with instantc which replaces archaic technology like Microsoft Teams. If you're using httpc, you don't have to migrate to instantc, but you will have to reconfigure and recompile everything to remove that (a bad idea).

Afternoon: httpc now comes with officec, a full blow office productivity application that replaces legacy products from Microsoft, Libreoffice and others. Again, fully integrated, but completely optional with some work.

Late afternoon: httpc api has changed to apic, this new api is a complete overhaul of the api previously used throughout all httpc components. You will need to update httpc and all of its components.

Early evening: httpc now manages calendaring automatically. Fully integrated into all components, this is the last calendaring system you'll need. Update as soon as possible.

Late evening: httpc apic has been displaced with easyc, a new advanced messaging api. httpc and all of its components need to be updated as soon as possible.

Next day: Announcing httpc v2. v2 includes mediac, a full blown multimedia engine that works with all modern streaming services. httpc v2 is not compatible with configuration files from httpc (as you would expect). Keep up everyone!

Following day on the internal dev forum: Frustrating, spent the last hour debugging an issue with a person running some pre v2 variant of httpc. Very important that everyone keeps up.
 
I used to use Snap packages. They were great until a few days later I saw inconsistencies in the GUI. The improper functioning of the apps.
I would rather rely on proper packages from the distro repository.
I also do not like that Snap is controlled by Ubuntu guys. They should make it open-source.
We would see much better improvements in the overall functioning of the apps on any other distro.
 
I used to use Snap packages. They were great until a few days later I saw inconsistencies in the GUI. The improper functioning of the apps.
I would rather rely on proper packages from the distro repository.
I also do not like that Snap is controlled by Ubuntu guys. They should make it open-source.
We would see much better improvements in the overall functioning of the apps on any other distro.
Does that mean you can't add software repositories to the snap store?
 
Does that mean you can't add software repositories to the snap store?
To my knowledge, you cannot. Ubuntu has full control over snap distribution, and can curate their store (repo) as they see fit. I think Snap is interesting, but compared to Flatpak I find it not ready for primetime yet. It would also appear that the developer community feels that way as well, because I've noticed more and more that snap packages tend to lag behind in updates compared to the same package being available in the Flatpak repos. That's just anecdotal evidence and not indicative of an abandonment of snap necessarily, but I feel like that is what's happening personally.

Snap does have some cool features, but I feel like Canonical jumped the gun and deployed it too early, and forced its use in Ubuntu by having certain system utilities being replaced by their snap variants which has led to a less than ideal end user experience. When I was still using Ubuntu I had a post install script that I would run to get everything setup the way I like, and one of the first things it did was remove all of the preinstalled snap apps and install the proper deb packages. I did that because the snap apps didn't respect theming and were horrendously slow to open. Why in the world would I want to wait 10-15 seconds for System Monitor to open when I'm probably opening to kill a process? I'm already trying to kill the process to get back to what I was doing. The last thing I want is an artificial slowdown because Canonical wants to force snaps down my throat.
 
Snaps are severely flawed in the sense that they fail to work out of the box whenever the application needs elevated privileges. Try running nmap as a snap and it just won't work unless you go through the hoops to grant it privileges.
 
Snaps are severely flawed in the sense that they fail to work out of the box whenever the application needs elevated privileges. Try running nmap as a snap and it just won't work unless you go through the hoops to grant it privileges.
Well, to be fair, isn't that the point of containerization? Also, AFAIK flatpak's require the same kind of tweaking to access various parts of the system.
 
It's odd. People have been asking for sandboxing for years (although, technically Snaps aren't 100% sandboxed). When they finally get something really close, they don't like the impact sandboxing has regarding applications interacting with the rest of the system.

It's like no one really thought of the implications before asking.
 
Last edited:
Well, to be fair, isn't that the point of containerization? Also, AFAIK flatpak's require the same kind of tweaking to access various parts of the system.
nmap requires only a few ports open... Docker doesn't have this problem. IMO snaps are either technically faulty or misconfigured if they don't work out of the box.
 
nmap requires only a few ports open... Docker doesn't have this problem. IMO snaps are either technically faulty or misconfigured if they don't work out of the box.
How do you figure Docker doesn't have this problem? It has the exact same problem, the difference is that the docker compose file declares what access the container needs to the system. If ports aren't declared in Docker compose you end up with the same type of problem. Also, Docker, to my knowledge, isn't attempting to containerize system utilities and end user applications while also enabling those applications to perform their system level tasks. Docker is great for hosting services in a container, but having nmap in a Docker container would just be silly. My point being that snaps and flatpaks are trying to achieve the containerization of Docker and the like while making the fact that the application is containerized invisible to the end user. This is where snaps have largely failed in my opinion. But, I think it has less to do with the implementation of snap, and more to do with snap packages not declaring the access they need properly at install. Hence your original statement that nmap as a snap doesn't function properly until appropriate permissions are granted. That has to do with the snap config not being setup correctly resulting in an installed application that doesn't have access to system resources it needs.

EDIT: Want to add one more thought. After all of that defense of snap's implementation, I do still think it has implementation problems, but I don't think permission handling with snap packages is all that difficult. In fact, I'd argue that it's easier to do than it is with Flatpak's unless you use the Flatseal utility. I'm just making the case that snap package maintainers not properly declaring default permissions in their snap config files is not the fault of Canonical or the snap service itself.
 
How do you figure Docker doesn't have this problem? It has the exact same problem, the difference is that the docker compose file declares what access the container needs to the system. If ports aren't declared in Docker compose you end up with the same type of problem. Also, Docker, to my knowledge, isn't attempting to containerize system utilities and end user applications while also enabling those applications to perform their system level tasks. Docker is great for hosting services in a container, but having nmap in a Docker container would just be silly. My point being that snaps and flatpaks are trying to achieve the containerization of Docker and the like while making the fact that the application is containerized invisible to the end user. This is where snaps have largely failed in my opinion. But, I think it has less to do with the implementation of snap, and more to do with snap packages not declaring the access they need properly at install. Hence your original statement that nmap as a snap doesn't function properly until appropriate permissions are granted. That has to do with the snap config not being setup correctly resulting in an installed application that doesn't have access to system resources it needs.

EDIT: Want to add one more thought. After all of that defense of snap's implementation, I do still think it has implementation problems, but I don't think permission handling with snap packages is all that difficult. In fact, I'd argue that it's easier to do than it is with Flatpak's unless you use the Flatseal utility. I'm just making the case that snap package maintainers not properly declaring default permissions in their snap config files is not the fault of Canonical or the snap service itself.
Nmap is not a 'system utility', it's a simple port scanner tool. On docker I can define a set port or use host networking and it works. With a snap things become complicated and you have to grant snaps access to the system itself, sometimes superuser level access. This has not been made easy either. When requirements are not met, snaps just fail and give non-informative errors which do not tell the end user what's wrong. For example if you try to install pytop as a snap, it just won't work unless you follow a set of instructions on github.

My idea of snaps was that they're customized containers meant to work on *buntu out of the box. But it seems many of them require manual installation in reality.
 
Nmap is not a 'system utility', it's a simple port scanner tool.
Semantics. Yes, it is not a default system utility, however the difference is irrelevant to the point I was making considering I said "system utilities and end user applications." The point still stands. That's not what Docker is used for. Docker is used for hosting containerized services. Running simple command line utilities in docker would just be overtly silly.
With a snap things become complicated and you have to grant snaps access to the system itself, sometimes superuser level access. This has not been made easy either. When requirements are not met, snaps just fail and give non-informative errors which do not tell the end user what's wrong. For example if you try to install pytop as a snap, it just won't work unless you follow a set of instructions on github.
snap connect package:network :network is not easy for allowing a snap access to network services? I'm not going to pretend like snaps are perfect, but if we are going to criticize them or anything else our arguments need to have merit. Also, you are kind of making my point for me, even though pytop doesn't exist as a snap. The point still remains, that if the developers establish the connections for their apps correctly out of the box in their config, then the end user shouldn't/wouldn't have to manually set the connections, and this is a problem I have ran into with flatpaks as well. I don't know if this is because developers aren't used to the dealing with containers or what, but it is a fairly common problem I've noticed with snaps and flatpaks in particular.

As far as superuser access, I ask you why this is a problem? Don't you do the same thing when you run sudo for a command line application? What's the difference? Now, if you were trying to run the nextcloud snap and it wanted permanent superuser access, I'd see that as a problem, but if a utility normally requires superuser access to function when installed as a deb and is only ran by the end user and not as a service, why would you expect any different when it's installed as a snap?
My idea of snaps was that they're customized containers meant to work on *buntu out of the box. But it seems many of them require manual installation in reality.
This is the one point I agree with. That's exactly what snaps were supposed to be. The problem is that most of the time I find that their permissions are not declared properly by the developers in the snap config, GUI snaps don't integrate well into desktop, and they are horrendously slow. That's why I've decided not to use them on Pop. Pop defaults to flatpaks, and doesn't even install snapd by default, and that's how I like it.

Ultimately, I think the biggest problem with snaps is that Canonical is trying to be both Docker and Flatpak at the same time. They want to tackle the server side market that Docker dominates, and the end user market, but they've ultimately failed at both. Docker does containerization for server side services far better than snaps, and Flatpaks are better on the end user side. Snaps are trying to be the swiss army knife of agnostic package delivery, and they're failing miserably at it.
 
Semantics. Yes, it is not a default system utility, however the difference is irrelevant to the point I was making considering I said "system utilities and end user applications." The point still stands. That's not what Docker is used for. Docker is used for hosting containerized services. Running simple command line utilities in docker would just be overtly silly.

snap connect package:network :network is not easy for allowing a snap access to network services? I'm not going to pretend like snaps are perfect, but if we are going to criticize them or anything else our arguments need to have merit. Also, you are kind of making my point for me, even though pytop doesn't exist as a snap. The point still remains, that if the developers establish the connections for their apps correctly out of the box in their config, then the end user shouldn't/wouldn't have to manually set the connections, and this is a problem I have ran into with flatpaks as well. I don't know if this is because developers aren't used to the dealing with containers or what, but it is a fairly common problem I've noticed with snaps and flatpaks in particular.

As far as superuser access, I ask you why this is a problem? Don't you do the same thing when you run sudo for a command line application? What's the difference? Now, if you were trying to run the nextcloud snap and it wanted permanent superuser access, I'd see that as a problem, but if a utility normally requires superuser access to function when installed as a deb and is only ran by the end user and not as a service, why would you expect any different when it's installed as a snap?

This is the one point I agree with. That's exactly what snaps were supposed to be. The problem is that most of the time I find that their permissions are not declared properly by the developers in the snap config, GUI snaps don't integrate well into desktop, and they are horrendously slow. That's why I've decided not to use them on Pop. Pop defaults to flatpaks, and doesn't even install snapd by default, and that's how I like it.

Ultimately, I think the biggest problem with snaps is that Canonical is trying to be both Docker and Flatpak at the same time. They want to tackle the server side market that Docker dominates, and the end user market, but they've ultimately failed at both. Docker does containerization for server side services far better than snaps, and Flatpaks are better on the end user side. Snaps are trying to be the swiss army knife of agnostic package delivery, and they're failing miserably at it.
snap connect package:network :network is not exactly plug and play either. I always thought that snaps were supposed to be transparent containers built in buntu but it seems I was wrong.

Installing bpytop is not very intuitive - it just fails without instructions and you need to google the git repo to find the instructions:

sudo snap connect bpytop:mount-observe
sudo snap connect bpytop:network-control
sudo snap connect bpytop:hardware-observe
sudo snap connect bpytop:system-observe
sudo snap connect bpytop:process-control
sudo snap connect bpytop:physical-memory-observe

I think snap is still a half assed solution that needs a lot of ironing.
 
I think snap is still a half assed solution that needs a lot of ironing.
On that we can definitely agree. Like I said earlier, I prefer and use flatpak for desktop applications, and the next time I upgrade my home server I'll most likely utilize Docker for the various services. The only reason I'm not using Docker for my servers as configured now, is because they've been up and running for a few years now, and require minimal maintenance so I haven't bothered to redo everything on Docker. Might do that over the holidays though. Could be a fun project.

EDIT: Ultimately I think Canonical needs to decided whether they want snaps to be "the best" containers for the server or the desktop, but I feel like that's the decision they need to make and then execute. Trying to do both just isn't working.
 
Back
Top