I am so sorry this got so long. I’m absolutely horrible at brevity.
Applications use things called libraries to provide particular functions rather than implement those functions themselves. So like “handle HTTP request” as an example, you can just use a HTTP library to handle it for you so you can focus on developing your application.
As time progresses, libraries change and release new versions. Most of the time one version is compatible with the other. Sometimes, especially when there is a major version change, the two version are incompatible. If an application relied on that library and a major incompatible change was made, the application also needs to be changed for the new version of the library.
A Linux distro usually selects the version of each library that they are going to ship with their release and maintain it via updates. However, your distro provider and some neat program you might use are usually two different people. So the neat program you use might have change their application to be compatible with a library that might not make it into your distro until next release.
At that point you have one of two options. Wait until your distro provides the updated library or the go it alone route of you updating your own library (which libraries can depend on other libraries, which means you could be opening a whole Pandora’s box here). The go it alone route also means that you have to turn off your distro’s updates because they’ll just overwrite everything you’ve done library wise.
This is where snaps, flatpaks, and appimages come into play. In a very basic sense, they provide a means for a program to include all the libraries it’ll need to run, without those libraries conflicting with your current setup from the distro. You might hear them as “containerized programs”, however, they’re not exactly the Docker style “container”, but from an isolating perspective, that’s mostly correct. So your neat application that relies on the newest libraries, they can be put into a snap, flatpak, or appimage and you can run that program with those new libraries no need for your distro to provide them or for you to go it alone.
I won’t bore you on the technical difference between the formats, but just mostly focus on what I usually hear is the objectionable issue with snaps. Snaps is a format that is developed by Canonical. All of these formats have a means of distribution, that is how do you get the program to install and how it is updated. Because you know, getting regular updates of your program is still really important. With snaps, Canonical uses a cryptographic signature to indicate that the distribution of the program has come from their “Snaps Store”. And that’s the main issue folks have taken with snaps.
So unlike the other kinds of formats, snaps are only really useful when they are acquired from the Canonical Snaps Store. You can bypass the checking of the cryptographic signature via the command line, but Ubuntu will not automatically check for updates on software installed via that method, you must check for updates manually. In contrast, anyone can build and maintain their own flatpak “store” or central repository. Only Canonical can distribute snaps and provide all of the nice features of distribution like automatic updates.
So that’s the main gripe, there’s technical issues as well between the formats which I won’t get into. But the main high level argument is the conflicting ideas of “open and free to all” that is usually associated with the Linux group (and FOSS [Free and open-source software] in general) and the “only Canonical can distribute” that comes with snaps. So as @sederx indicated, if that’s not an argument that resonates with you, the debate is pretty moot.
There’s some user level difference like some snaps can run a bit slower than a native program, but Canonical has updated things with snaps to address some of that. Flatpak sandboxing can make it difficult to access files on your system, but flatpak permissions can be edited with things like Flatseal. Etc. It’s what I would file into the “papercut” box of problems. But for some, those papercuts matter and ultimately turn people off from the whole Linux thing. So there’s arguments that come from that as well, but that’s so universal “just different in how the papercut happens” that I just file that as a debate between container and native applications, rather a debate about formats.
Sometimes you use a Library pre-made sauce or spice blend as part of a recipe, so you don’t need to waste time remaking something that is commonly used.
Every so often, a company will tweak the recipe for the things you are using, but it still basically tastes the same. Sometimes they just decide that now it’s salty instead of sweet, so it would complete ruin the dish you would like to make.
The recipe you are using assumes you live in Australia where the new version of the sauce/spice blend is more common, but where you live still only sells the old version.
So now you can either wait for the store to sell the new sauce/spice blend, import it from Australia, or try to make it yourself. But you might have another recipe that still needs/uses the old sauce/spice blend. Needing to have both can lead to issues where you use the wrong one, ruining the food you are trying to make.
This is where snaps, flatpaks, and appimages those dish-in-a-box kits come into play. They’ll have the correct version of the spices/sauces you want, so it doesn’t really matter which version you have in your kitchen.
Snaps branded dish-in-a-box kits are developed by Canonical, and they can be kinda weird. You need to check for updates if you need to re-buy them manually, and you can only get them from the “Snaps Store”. Other dish-in-a-box kits allow you to get them from whichever store you want, and will automatically re-order when needed.
And that’s the main issue folks have taken with snaps. If you have 50+ programs are making a meal with 50+ dishes, and you need to constantly check if you need to rebuy them one by one, it gets old quickly.
Also, Snaps takes up a lot of room, and generally just kinda suck compared to installing things normally or through flatpack.
My first introduction to them was “hey why does startup take so long now? This machine used to be so much faster.” and realizing it was snapd that was eating up the time. It’s also not exactly efficient at using storage compared to native installs of dependencies.
For a desktop these may not be noticable but for low power embedded systems it’s a nightmare. It should be an option but really isn’t ready to be default. And when appimages are already a thing that work well I don’t really see the point.
I’m not suggesting appimages are better, just that I’ve had fewer problems with them relative to snaps. Ultimately I’d argue all attempts to remove dependencies are not ready to replace typical packages for low powered systems. For desktop Linux the performance difference is negligible anyway.
Snap is a software packaging and deployment system developed by Canonical for operating systems that use the Linux kernel and the systemd init system. The packages, called snaps, and the tool for using them, snapd, work across a range of Linux distributions[3] and allow upstream software developers to distribute their applications directly to users. Snaps are self-contained applications running in a sandbox with mediated access to the host system. Snap was originally released for cloud applications[4] but was later ported to also work for Internet of Things devices[5][6] and desktop[7][8] applications.
So (having tried various distro for almost 2 decades now, but always reverting to windows) the two useful things as I read that are 1) not having to know thst some bullshit distro doesn’t use apt and you need to figure out wtf the package manager is because this distro is a special snowflake and they wanted to show the world by being a bitch and not using apt; and 2) direct from devs, which is nice and imo preferred.
But like… native packages mostly handled this? I’ve been watching from the sidelines for a few years as this happened and I’m still like ‘this is a solution looking for a problem, and adding complexity in the name of simplicity’.
Can I get a tl;dr on flatpak? I think it’s basically snaps but again ‘we can make this standard better! by creating another fragment to the available standards!’ which is just, ugh.
That kinda is (one of) the big issues with Linux, in my eyes - everyone thinks their shitty implementation is best, and this happens for everything, and so instead of having one standard for everything you have 53 and none of them get the proper dev time and so ‘I can do this better’ and now you have 54 standards and […]. Like, it’s cool to be able to patchwork together the special sauce of 18 distros manually, but like… There could be consolidation and then 1 would have the special sauce of 18 in a user-friendly iso instead of taking 35 hours to get working. As a user, I want shit to just fucking work, or be moderately easy to get. Adding more fragmentation to the space is doing a disservice to the whole community.
I’m not completely sure but don’t flatpaks offer good sandboxing. If they do it could be a good idea for people who use/need proprietary software like steam and zoom so when you run those programs at least it can’t read through your files and stuff
You don’t need to break everything that exists, cause maintenance issues and incur that much overhead to have sandboxing. The security features that allows sandboxing in the first place are also available for regular binaries not installed in some weird ways, with all their advantages and flaws.
Snap is just Canonical’s way of getting more control over things. The only upside of Snap was “easier distribution”, which turned out to not be that true. The downsides, however, especially regarding maintenances and software updates, are very real.
What’s snaps?
I am so sorry this got so long. I’m absolutely horrible at brevity.
Applications use things called libraries to provide particular functions rather than implement those functions themselves. So like “handle HTTP request” as an example, you can just use a HTTP library to handle it for you so you can focus on developing your application.
As time progresses, libraries change and release new versions. Most of the time one version is compatible with the other. Sometimes, especially when there is a major version change, the two version are incompatible. If an application relied on that library and a major incompatible change was made, the application also needs to be changed for the new version of the library.
A Linux distro usually selects the version of each library that they are going to ship with their release and maintain it via updates. However, your distro provider and some neat program you might use are usually two different people. So the neat program you use might have change their application to be compatible with a library that might not make it into your distro until next release.
At that point you have one of two options. Wait until your distro provides the updated library or the go it alone route of you updating your own library (which libraries can depend on other libraries, which means you could be opening a whole Pandora’s box here). The go it alone route also means that you have to turn off your distro’s updates because they’ll just overwrite everything you’ve done library wise.
This is where snaps, flatpaks, and appimages come into play. In a very basic sense, they provide a means for a program to include all the libraries it’ll need to run, without those libraries conflicting with your current setup from the distro. You might hear them as “containerized programs”, however, they’re not exactly the Docker style “container”, but from an isolating perspective, that’s mostly correct. So your neat application that relies on the newest libraries, they can be put into a snap, flatpak, or appimage and you can run that program with those new libraries no need for your distro to provide them or for you to go it alone.
I won’t bore you on the technical difference between the formats, but just mostly focus on what I usually hear is the objectionable issue with snaps. Snaps is a format that is developed by Canonical. All of these formats have a means of distribution, that is how do you get the program to install and how it is updated. Because you know, getting regular updates of your program is still really important. With snaps, Canonical uses a cryptographic signature to indicate that the distribution of the program has come from their “Snaps Store”. And that’s the main issue folks have taken with snaps.
So unlike the other kinds of formats, snaps are only really useful when they are acquired from the Canonical Snaps Store. You can bypass the checking of the cryptographic signature via the command line, but Ubuntu will not automatically check for updates on software installed via that method, you must check for updates manually. In contrast, anyone can build and maintain their own flatpak “store” or central repository. Only Canonical can distribute snaps and provide all of the nice features of distribution like automatic updates.
So that’s the main gripe, there’s technical issues as well between the formats which I won’t get into. But the main high level argument is the conflicting ideas of “open and free to all” that is usually associated with the Linux group (and FOSS [Free and open-source software] in general) and the “only Canonical can distribute” that comes with snaps. So as @sederx indicated, if that’s not an argument that resonates with you, the debate is pretty moot.
There’s some user level difference like some snaps can run a bit slower than a native program, but Canonical has updated things with snaps to address some of that. Flatpak sandboxing can make it difficult to access files on your system, but flatpak permissions can be edited with things like Flatseal. Etc. It’s what I would file into the “papercut” box of problems. But for some, those papercuts matter and ultimately turn people off from the whole Linux thing. So there’s arguments that come from that as well, but that’s so universal “just different in how the papercut happens” that I just file that as a debate between container and native applications, rather a debate about formats.
Sounds like docker with a load of extra steps.
I think of snap and flatpack as docker containers but for GUI apps.
There’s more differences of course, but I take that as the gist.
I understand less now.
Take that person’s post, comparing it to cooking.
Sometimes you use a
Librarypre-made sauce or spice blend as part of a recipe, so you don’t need to waste time remaking something that is commonly used.Every so often, a company will tweak the recipe for the things you are using, but it still basically tastes the same. Sometimes they just decide that now it’s salty instead of sweet, so it would complete ruin the dish you would like to make.
The recipe you are using assumes you live in Australia where the new version of the sauce/spice blend is more common, but where you live still only sells the old version.
So now you can either wait for the store to sell the new sauce/spice blend, import it from Australia, or try to make it yourself. But you might have another recipe that still needs/uses the old sauce/spice blend. Needing to have both can lead to issues where you use the wrong one, ruining the food you are trying to make.
This is where
snaps, flatpaks, and appimagesthose dish-in-a-box kits come into play. They’ll have the correct version of the spices/sauces you want, so it doesn’t really matter which version you have in your kitchen.Snaps branded dish-in-a-box kits are developed by Canonical, and they can be kinda weird. You need to check
for updatesif you need to re-buy them manually, and you can only get them from the “Snaps Store”. Other dish-in-a-box kits allow you to get them from whichever store you want, and will automatically re-order when needed.And that’s the main issue folks have taken with snaps. If you
have 50+ programsare making a meal with 50+ dishes, and you need to constantly check if you need to rebuy them one by one, it gets old quickly.Also, Snaps takes up a lot of room, and generally just kinda suck compared to installing things normally or through flatpack.
I would have liked more technicalities, but wonderful write-up. Thanks
My first introduction to them was “hey why does startup take so long now? This machine used to be so much faster.” and realizing it was snapd that was eating up the time. It’s also not exactly efficient at using storage compared to native installs of dependencies.
For a desktop these may not be noticable but for low power embedded systems it’s a nightmare. It should be an option but really isn’t ready to be default. And when appimages are already a thing that work well I don’t really see the point.
Appimage has no sandbox
I’m not suggesting appimages are better, just that I’ve had fewer problems with them relative to snaps. Ultimately I’d argue all attempts to remove dependencies are not ready to replace typical packages for low powered systems. For desktop Linux the performance difference is negligible anyway.
An AppImage can be sandboxed.
Here friend, I also didn’t know
You must have a container to be able to run a different library version?
Why not run like Android API version level?
So (having tried various distro for almost 2 decades now, but always reverting to windows) the two useful things as I read that are 1) not having to know thst some bullshit distro doesn’t use apt and you need to figure out wtf the package manager is because this distro is a special snowflake and they wanted to show the world by being a bitch and not using apt; and 2) direct from devs, which is nice and imo preferred.
But like… native packages mostly handled this? I’ve been watching from the sidelines for a few years as this happened and I’m still like ‘this is a solution looking for a problem, and adding complexity in the name of simplicity’.
Can I get a tl;dr on flatpak? I think it’s basically snaps but again ‘we can make this standard better! by creating another fragment to the available standards!’ which is just, ugh.
That kinda is (one of) the big issues with Linux, in my eyes - everyone thinks their shitty implementation is best, and this happens for everything, and so instead of having one standard for everything you have 53 and none of them get the proper dev time and so ‘I can do this better’ and now you have 54 standards and […]. Like, it’s cool to be able to patchwork together the special sauce of 18 distros manually, but like… There could be consolidation and then 1 would have the special sauce of 18 in a user-friendly iso instead of taking 35 hours to get working. As a user, I want shit to just fucking work, or be moderately easy to get. Adding more fragmentation to the space is doing a disservice to the whole community.
My thoughts.
🫰🤏🫰
I’m using Linux for almost 30 years and never use snap or flatpak. I install native apps with apt or pacman or whatever.
I’m not completely sure but don’t flatpaks offer good sandboxing. If they do it could be a good idea for people who use/need proprietary software like steam and zoom so when you run those programs at least it can’t read through your files and stuff
You don’t need to break everything that exists, cause maintenance issues and incur that much overhead to have sandboxing. The security features that allows sandboxing in the first place are also available for regular binaries not installed in some weird ways, with all their advantages and flaws.
Snap is just Canonical’s way of getting more control over things. The only upside of Snap was “easier distribution”, which turned out to not be that true. The downsides, however, especially regarding maintenances and software updates, are very real.
about flatpak’s sandboxing: https://madaidans-insecurities.github.io/linux.html#flatpak