Its a packaging model to pseudo-sandbox applications and avoid needing to install all of their dependencies locally… mostly.
There are performance implications but for actual performance critical operations, you are generally willing to install the dependencies (and would likely just run in a container/VM).
But the main issues boil down to concerns over some parts of the Snap ecosystem being closed source, Canonical’s ongoing efforts to try to get some of the Red Hat “premium linux” money, and arguments that other solutions (e.g. flatpaks and appimages) are “just as good, if not better”. And it doesn’t help that Canonical/Ubuntu is increasingly pushing snap as “the only solution” for some applications. Even though users can still just add the appropriate repository to use that with the package manager/sandbox solution of their choice.
Personally? I don’t like the ongoing push. But I also dislike how many applications are basically only supported as appimages (and to a lesser extent, flatpaks). My main issue with canonical that eventually made me switch to a different distro is that they are increasingly advertising their premium repositories. Theoretically, it is the same update frequency for the pro and free repos. Theoretically, I have a bridge to sell anyone who believes that.
Canonical is doing the same thing Microsoft is doing with Edge - using its dominant position to push its other products and force out competition, and to lock users (and potentially developers) into its own ecosystem.
Edge is chromium. If anything, it is MS providing an alternative to Chrome. Personally? I like having a browser that is not associated with my google account. Because sometimes you don’t want to have to do the twelve activation steps for a porn site every time you want to rub one out and having a different browser that nobody uses that you can keep a few cookies active in.
And considering Google already HAS that dominance and more or less have defined the ecosystem (to the point that reddit’s WYSIWYG was actively broken in Firefox for months, if not years)… that is a horrible example.
For future reference: A better argument is to reference chrome and the google assistant on an Android. Or siri and safari on an iphone.
Saying that Edge is Chromium is like saying that Manjaro is Arch or diamond is just coal. They’re related, but there’s significant material difference.
When it was introduced in Windows 10, Edge had an immediate and massive surge in its adoption rate. That wasn’t natural growth based on the application’s merits – it was simply a result of Edge being present in new installs.
But the advantage is that you don’t have to worry about installing some obscure version of a library because this application that was written ten years ago. Even though the vast majority of these are using pretty standard libraries anyway.
Its probably still a net good but I am very much the kind of person who would rather just run a few apt or dnf commands.
It’s actually less about the library being obscure, and more about version conflicts, which is actually more a problem with common libraries.
For example, let’s say you want to install applications A, B, and C, and they each depend on library L. If A depends on Lv1, and B depends on Lv2, and C depends on Lv3, with traditional package management, you’re in a predicament. You can only have one copy of L, and the versions of L may not be compatible.
Solutions like snap, flatpak, appimage, and even things like Docker and other containerization techniques, get around this issue by having applications ship the specific version of the library they need. You end up with more copies of the library, but every application has exactly the version it needs/the developer tested with.
Even a decade ago? Full agree and that is the source of a lot of my grey hairs.
These days? People understand these problems… in large part because the devs are dealing with them too. So there is a much bigger focus on backwards compatibility within a given major (if not minor) release and version tagged libraries so that you can have libfoo.so.1.2.3.4 and libfoo.so.2.4.6.8 installed side by side with no issues.
There are still definitely problem points and that is WHY containerization is more or less required for a production environment.
But in the consumer environment? It is nice and good practice but it is nowhere near as important as it used to be.
The age and obscurity of the library is irrelevant - you could always include libraries bundled with the app, if they didn’t exist in system repos. For example, in deb packages, you could include it in the data.tar portion of the package (see https://en.m.wikipedia.org/wiki/Deb_(file_format)).
Libraries with version names baked in are one solution to the dependency hell problem, but that requires support from the language/framework/tooling to build the application, and/or the OS (or things get hacky and messy quickly).
If you read that dependency hell page, you’ll see another solution is portable apps, which specifically mentions Appimage, Flatpak, and Snap.
Additionally, if you read the Debian docs on How to Cope with Conflicting Requirements, the first solution they give is to “Install such programs using corresponding sandboxed upstream binary packages,” such as “Flatpak, Snap, or AppImage packages.”
Bin the consumer environment? It is nice and good practice but it is nowhere near as important as it used to be.
I’ll give flatpak and snap one thing: they did make some concession to avoiding duplication, unlike docker which utterly duplicates everything.
With flatpak and snap, applications can depend on/pull in a maintained external layer. So you might want ‘gnome environment, version 43’ and other applications that want that can all share. That layer can be updated independently of dependencies. You might have two instances of the gnome layers (say 43 and 44) due to different applications declaring different versions, but it’s not too bad.
Now there is some duplication, some libraries that an app says “oh, no particular layer for this one, fine I’ll just bundle it”. But at least there’s a mechanism to not necessarily do that for everything.
I’ll add that the ‘pseudo-sandbox’ is of some dubious value, as far as I can tell the app declares how much or little sandboxing it wants and the user doesn’t really get the opportunity to consent or even know that a snap has full access versus limited access.
I’ll also say that some functionality is broken in snaps (and flatpak). For example I used KeepPassXC browser integration, and then when snap was used instead of native, it broke. A number of extensions broke and the development attitude was everyone pointing fingers everywhere else and ultimately saying “just find a ppa with a browser ok?”
I’ll second the “screw it, I give up on packaging, my app is now a monolithic flatpak, snap, appimage, or docker container” mindset of a lot of developers.
Its a packaging model to pseudo-sandbox applications and avoid needing to install all of their dependencies locally… mostly.
There are performance implications but for actual performance critical operations, you are generally willing to install the dependencies (and would likely just run in a container/VM).
But the main issues boil down to concerns over some parts of the Snap ecosystem being closed source, Canonical’s ongoing efforts to try to get some of the Red Hat “premium linux” money, and arguments that other solutions (e.g. flatpaks and appimages) are “just as good, if not better”. And it doesn’t help that Canonical/Ubuntu is increasingly pushing snap as “the only solution” for some applications. Even though users can still just add the appropriate repository to use that with the package manager/sandbox solution of their choice.
Personally? I don’t like the ongoing push. But I also dislike how many applications are basically only supported as appimages (and to a lesser extent, flatpaks). My main issue with canonical that eventually made me switch to a different distro is that they are increasingly advertising their premium repositories. Theoretically, it is the same update frequency for the pro and free repos. Theoretically, I have a bridge to sell anyone who believes that.
Canonical is doing the same thing Microsoft is doing with Edge - using its dominant position to push its other products and force out competition, and to lock users (and potentially developers) into its own ecosystem.
…
Edge is chromium. If anything, it is MS providing an alternative to Chrome. Personally? I like having a browser that is not associated with my google account. Because sometimes you don’t want to have to do the twelve activation steps for a porn site every time you want to rub one out and having a different browser that nobody uses that you can keep a few cookies active in.
And considering Google already HAS that dominance and more or less have defined the ecosystem (to the point that reddit’s WYSIWYG was actively broken in Firefox for months, if not years)… that is a horrible example.
For future reference: A better argument is to reference chrome and the google assistant on an Android. Or siri and safari on an iphone.
Saying that Edge is Chromium is like saying that Manjaro is Arch or diamond is just coal. They’re related, but there’s significant material difference.
When it was introduced in Windows 10, Edge had an immediate and massive surge in its adoption rate. That wasn’t natural growth based on the application’s merits – it was simply a result of Edge being present in new installs.
Wait, but doesn’t it result in more copies of the dependencies being installed locally because they’re duplicated for each application?
It sure does
But the advantage is that you don’t have to worry about installing some obscure version of a library because this application that was written ten years ago. Even though the vast majority of these are using pretty standard libraries anyway.
Its probably still a net good but I am very much the kind of person who would rather just run a few
aptordnfcommands.It’s actually less about the library being obscure, and more about version conflicts, which is actually more a problem with common libraries.
For example, let’s say you want to install applications A, B, and C, and they each depend on library L. If A depends on Lv1, and B depends on Lv2, and C depends on Lv3, with traditional package management, you’re in a predicament. You can only have one copy of L, and the versions of L may not be compatible.
Solutions like snap, flatpak, appimage, and even things like Docker and other containerization techniques, get around this issue by having applications ship the specific version of the library they need. You end up with more copies of the library, but every application has exactly the version it needs/the developer tested with.
Even a decade ago? Full agree and that is the source of a lot of my grey hairs.
These days? People understand these problems… in large part because the devs are dealing with them too. So there is a much bigger focus on backwards compatibility within a given major (if not minor) release and version tagged libraries so that you can have libfoo.so.1.2.3.4 and libfoo.so.2.4.6.8 installed side by side with no issues.
There are still definitely problem points and that is WHY containerization is more or less required for a production environment.
But in the consumer environment? It is nice and good practice but it is nowhere near as important as it used to be.
The age and obscurity of the library is irrelevant - you could always include libraries bundled with the app, if they didn’t exist in system repos. For example, in deb packages, you could include it in the data.tar portion of the package (see https://en.m.wikipedia.org/wiki/Deb_(file_format)).
Libraries with version names baked in are one solution to the dependency hell problem, but that requires support from the language/framework/tooling to build the application, and/or the OS (or things get hacky and messy quickly).
If you read that dependency hell page, you’ll see another solution is portable apps, which specifically mentions Appimage, Flatpak, and Snap.
Additionally, if you read the Debian docs on How to Cope with Conflicting Requirements, the first solution they give is to “Install such programs using corresponding sandboxed upstream binary packages,” such as “Flatpak, Snap, or AppImage packages.”
This is incorrect. The target audience for Flatpak is desktop users: https://docs.flatpak.org/en/latest/introduction.html#target-audience. Flatpaks are explicitly for consumer, graphical applications.
I’ll give flatpak and snap one thing: they did make some concession to avoiding duplication, unlike docker which utterly duplicates everything.
With flatpak and snap, applications can depend on/pull in a maintained external layer. So you might want ‘gnome environment, version 43’ and other applications that want that can all share. That layer can be updated independently of dependencies. You might have two instances of the gnome layers (say 43 and 44) due to different applications declaring different versions, but it’s not too bad.
Now there is some duplication, some libraries that an app says “oh, no particular layer for this one, fine I’ll just bundle it”. But at least there’s a mechanism to not necessarily do that for everything.
I’ll add that the ‘pseudo-sandbox’ is of some dubious value, as far as I can tell the app declares how much or little sandboxing it wants and the user doesn’t really get the opportunity to consent or even know that a snap has full access versus limited access.
I’ll also say that some functionality is broken in snaps (and flatpak). For example I used KeepPassXC browser integration, and then when snap was used instead of native, it broke. A number of extensions broke and the development attitude was everyone pointing fingers everywhere else and ultimately saying “just find a ppa with a browser ok?”
I’ll second the “screw it, I give up on packaging, my app is now a monolithic flatpak, snap, appimage, or docker container” mindset of a lot of developers.