Snap Debate

DeaconFrost

[H]F Junkie
Joined
Sep 6, 2007
Messages
11,245
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.
 

Vermillion

Supreme [H]ardness
Joined
Apr 5, 2007
Messages
4,203
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.
 
Joined
Dec 1, 2011
Messages
887
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.
 

DeaconFrost

[H]F Junkie
Joined
Sep 6, 2007
Messages
11,245
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"?
 

Vermillion

Supreme [H]ardness
Joined
Apr 5, 2007
Messages
4,203
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.
 

Mazzspeed

2[H]4U
Joined
Dec 27, 2017
Messages
2,711
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.
 

IdiotInCharge

NVIDIA SHILL
Joined
Jun 13, 2003
Messages
14,712
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.
 

Mazzspeed

2[H]4U
Joined
Dec 27, 2017
Messages
2,711
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.
 

KarsusTG

2[H]4U
Joined
Aug 27, 2010
Messages
3,228
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
 

IdiotInCharge

NVIDIA SHILL
Joined
Jun 13, 2003
Messages
14,712
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.
 

KarsusTG

2[H]4U
Joined
Aug 27, 2010
Messages
3,228
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.
 

IdiotInCharge

NVIDIA SHILL
Joined
Jun 13, 2003
Messages
14,712
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.
 

KarsusTG

2[H]4U
Joined
Aug 27, 2010
Messages
3,228
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.
 

DeaconFrost

[H]F Junkie
Joined
Sep 6, 2007
Messages
11,245
What are your thoughts on flatpaks? Same overall feelings and concerns as snaps?
 

cjcox

[H]ard|Gawd
Joined
Jun 7, 2004
Messages
1,770
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...
 

IdiotInCharge

NVIDIA SHILL
Joined
Jun 13, 2003
Messages
14,712
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.
 

cjcox

[H]ard|Gawd
Joined
Jun 7, 2004
Messages
1,770
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.
 

JustinC

Weaksauce
Joined
May 25, 2020
Messages
75
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.
 
Top