But, the 10,000 ft view is that they reduce the amount of control I have over my system. They offer restrictions I chafe at while giving me no benefit that I care about.
I'm not going to sit here and say they shouldn't exist. That they're not to my taste doesn't mean that others who like them shouldn't have them. But they're not to my taste at all.
After seeing systemd getting widely adopted (also not to my taste), if snaps (or flatpacks, although I am less allergic to those) join the party then that's just a clear indication that the Linux world and I have diverged too much and I need to move on.
But this bloatification is happening all over the place. Firefox is starting to have more and more dependency on flatpak’s daemons, even if you don’t use flatpak. These daemons are becoming the de facto standard for some interfaces too sadly. This also means that a lot of software is a lot less portable.
I'm saddened to hear that FF has dependencies on flatpack daemons, but I'm not surprised by it. The direction Linux is going seems very clear to me, and I expect more of that sort of thing as time goes on.
However, it depends on the implementation and Snap just sucks.
(Note that the default Unix assumption is that no users can be trusted but all applications can be trusted, which is wrong imho. Containers provide a way out of this, but things get messy very fast.).
Your other data, in other sandboxes, is protected though.
It is, but I also actively don't want every package to run in its own container. I'd rather containerize select applications that I choose.
I moved to Qubes OS and like it.
Snaps allow you to hold updates indefinitely now: no forced updates any more. Use "snap refresh --hold <some snap name>". See https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--....
- you're a hardcore oriented distro, you assume most things will be built from source, follow all of your dependencies and maintain the glue for your distro. Gentoo/Slackware style。
- you value convenience and go the snaps/flatpack route.
And you can still go the convenience path while building some specific apps from source, but there will be a bigger gap to bridge and it won't make sense formost applications.
I get the shift, as we're already seeing it, even outside the cloud, I think it's still the best of both worlds. I compare that to how I'm running a natively compiled postgres version but a containerized mysql because it was too much of a pain to match all the dependencies.
Reminds me of the early days of the tensorflow where everyone used whatever binary package worked an no one could run anyone else's code because people kept getting stale binaries somewhere in the stack.
For open source software, snap is the same software, but slower, more broken and with worse upgrades.
Snap's changed the firefox update process so I now have to run 'sudo snap refresh' and wait for a download, where before I just closed and reopened it. Maybe it'll make my running application's dock icon disappear, hope you always use alt+tab instead of the dock. Snap can install ffmpeg - but I can't feed a screen recording to vaapi for compression because whoever set up the sandboxing forgot to allow that. Good luck sharing anything from, say, ~/.config/ on, say, discord - you get a silent unexplained failure, because hidden folder access is blocked by the sandbox. Installing a browser? With snap you get three copies; you can adjust refresh.retain down to only keep 2 copies - but 1 copy is out of the question.
There's a reason canonical has to force snap down people's throats, and it's because nobody uses it by choice.
And btw SteamOS is absolutely not a sandboxed environment. It just has a read-only OS filesystem so they can safely blow it away upon upgrade.
The obvious answer is: vendor lock in. Once Ubuntu is snap-only you won’t be able to host your own package repositories, since it’s their secret code.
Uploading public applications is free. Uploading proprietary software is a business model.
It also pretty much locks Ubuntu users in, because no other project uses snaps, so if an app chooses snap for their distribution method (certbot, for example) it suddenly becomes a lot easier to just download Ubuntu than it is to install Snap for a foreign platform.
That's an exaggeration. It's about as easy to install snap support for a non-Ubuntu as it is to install any other third party app on that platform. And the latter case is exactly what you're trying to achieve by trying to install a third party app on that platform in the first place, so by definition it can't be significantly harder than any alternative method.
Not me, for programs that are not from the repos I do not like debs.
I needed to install dubious apps like Skype,Slack, Some Pdf Editor etc. With deb I would give them root , so I either find an app image or snap, or try to unpack the deb file and attempt to run the binaries without root.
I also installed one a server some CLI snaps, they did their job and I did not had to build them from source.
I agree from things that are in the repo I prefer the debs 99% of the time.
The main problem that Snaps solve is this latter case: when third parties are trying to ship directly into someone's distribution installation[1].
Often third party debs appear to work OK, but then break future distribution upgrades. By then users have forgotten about the third party software that has hacked itself into their system, and blame the distribution for their upgrade failure. The problem is that distribution debs are designed to provide metadata about what has changed so that the package manager can accommodate. But it's not possible for distribution debs to be aware of the third party debs to handle those changes. So things break.
The breakages caused by debs aren't just limited to future distribution upgrades. A bad third party deb package can break your entire system. We routinely get reports where it turns out that this is what happened to our users!
There's also the problem of dependencies. If a third party app needs a bunch of dependencies, then they can't realistically bump those dependencies on the system as a whole without regressing all the other apps that need older versions of that dependency. So they have to bundle their dependencies, and this is something else that regular deb tooling doesn't handle well. You can theoretically construct a deb that bundles all its dependencies, but then that's exactly what snaps and snap tooling handles better - that's half the point. Nix only partially solves the problem by better supporting concurrent installation of multiple versions of those dependencies. But those concurrent versions would still each have to be maintained; that's something that distributions try to avoid by picking one version of each dependency and making the entire distribution release work with just that one. Moving that maintenance responsibility to each third party app developer, and having the packages bundle their dependencies, is the other solution. This was already happening with deb packages like for Firefox. Firefox upstream bundles nearly everything, and the debs (eg. in Debian) do the same for most of their dependencies. Snaps just call a spade a spade and are designed around it.
You also wouldn't really expect a third party app to have access to everything on your system. Say for example you download and install some game app to try out. Do you really want it to have access to your online banking browser session? The game developer might not secure their development infrastructure as if someone's trying to steal their users' money, because that's expensive and they're only shipping a game. But if you install their game, then that's what you risk. That game developer's infrastructure is suddenly an attack vector for an adversary that wants to get to your online banking session. On iOS and Android, each app only has system-mediated access to everything outside its sandbox. Debs fundamentally cannot provide this separation, so if you install third party debs then you're giving all those third parties access to everything, which really is unacceptable in modern security practice. Snaps give you that sandboxing.
So that's what snaps are for: 1) bundling dependencies, because that's necessary in world of third party software that ships independently of the distribution; and 2) sandboxing, because that's necessary in a world of third party software if you don't want to give all those third parties and their adversaries root on your system.
If you don't want third party apps, and only want what your distribution ships in a curated manner, then you don't really need snaps. But consider that Firefox is essentially a third party, non-curated app, regardless of your distribution or how it was packaged! See [1] below.
Snaps are also immutable, which really helps with stability and upgrade and revert cases. This is more relevant for snap-only systems like in IoT, not the Ubuntu desktop. In an IoT deployment you can't tell the user to run "apt-get -f install" to fix up the system because power got interrupted during an upgrade - because that's how debs work.
In years gone by, Ubuntu tried really hard to make third party debs work. But it didn't work for various reasons. In the meantime, it became the norm for third parties to ship debs together with all of their problems, since there was nothing better possible at the time. This is what snaps solve.
Disclosure: I work for Canonical. But here I am speaking for myself, not my employer. I'm not involved in the design of snaps, but as a distribution developer, it's clear to me what problems they solve.
[1] Packages like Firefox also use snaps because even as a deb it's really not the case that Firefox is curated by the distribution and mostly unchanged after release any more. So it suffers from mostly all the same problems that third party debs do.
How so? Every dependency of every dependency is in the nix store and they’re all immutable. A nix package installed will work forever because its environment can’t change. Am I not right?
Bugs and security issues are found from time to time. When that happens, every occurrence in use needs an update. If ten different incompatible versions of a package are in use, they all need to be replaced. That's more work than one per traditional distribution release.
(What I'm getting at is: why does it make sense for Canonical to define its own sandboxed application format when another one already exists?)
Snaps solve a bunch of problems that are out of scope of Flatpaks, such as CLI apps and the packaging of kernels and other hardware-level pieces. This allows for an entirely snap-based system that is immutable and atomically updated, which is essential for IoT devices to be reliable.
If you look at the history of snaps, they are an evolution of click packaging, which were created for the Ubuntu phone that is no more. But the history goes back further than that - back to Ubuntu's App Review Board and (deb based) third party app packaging system, which failed for exactly the reason that deb is an unsuitable packaging format for third party apps.
If you look at the history of Flatpaks, you'll find that their initial release was at a similar time to snaps. But given that they don't solve a bunch of problems that snaps do, what was/is Canonical supposed to do? Ditch snaps entirely and drop their IoT support? Integrate IoT support into Flatpaks? Do Flatpak upstream even want that? Look at the history of Canonical wanting to ehnance GNOME, and the history of how Unity began, to see how that doesn't seem like it would be a practical way of delivering functionality to users in a reasonable period of time.
Consider that it is Ubuntu that is at the centre of this third party app packaging problem. It's Ubuntu that everybody targets first with their third party debs. For the same underlying reason, it's Ubuntu that gets more user support requests because of bad third party debs than every other distribution. It makes sense that Ubuntu developers are best to understand the problem and develop a solution.
So yes, we've ended up with two parallel contenders. But I don't think it's reasonable for Canonical to have done anything differently in regard to Flatpak. It appeared at the same time while Canonical had already been working away at the problem for years, doesn't solve or even try to solve all the problems that snaps are designed to solve, and those problems appear to be out of the scope of Flatpak anyway. As much as critics frame them as like-for-like options that Canonical could just decide to switch over, they simply aren't and thus "simply switching" doesn't even make sense.
As for "another one already exists", that statement could just as well apply the other way round: look at the timelines!