The problem with snaps is that they are a stupid way to distribute software that doesn't solve any problem, while introducing many other.
Basically a snap package is a container, that means an image of an operating system just to run one software. Just this idea should be considerered stupid, is like saying every software is distributed in a Docker container. It's a great way to waste disk space, and also RAM since shared library are no longer really shared...
You can have software that update automatically also with debs, where is the problem? Unattended upgrades exists since decades, you install it, and it updates all your packages automatically.
You can even have proprietary software packaged in .deb packages, why not, if for Canonical that is a concern. You can even have software that runs in a container packaged as a .deb package, why not?
Snap has no real purpose to me.
Flatpack is something that makes more sense, since it aims at providing a way to package software for multiple distributions, doesn't really need a runtime, a daemon like snap, but it builds application bundles that you double click and run, without installing them.
There's flat out wrong stuff in this post. First off snap packages don't waste a lot of disk space because they avoid duplication of shared dependencies by using file hashes. Snap packages that need the same dependencies won't duplicate them.
One big advantage that snap has over flatpak is the "--classic" option to allow non-sandboxed applications given that some applications are hard to ship completely sandboxed without getting into some serious usability issues.
> There's flat out wrong stuff in this post. First off snap packages don't waste a lot of disk space because they avoid duplication of shared dependencies by using file hashes. Snap packages that need the same dependencies won't duplicate them.
This is not true. Snaps are just squashfs images, there's nothing fancy there. No deduplication or anything. You're thinking of Flatpaks with OSTree, which does do this.
Squashfs has a sorted order to files and LZ compression is stable (change a byte and everything will be the same after the dictionary window if not sooner). So it should be really easy to make very small update deltas for snaps without any kind of complicated GIT-like infrastructure at all.
I've only glanced at the docs but Flatpack looks very complicated with lots of infrastructure and things that can go wrong; use Git to extract the app into a local repository with hard links to resources? It sound like typical linux centralized overcomplication.
Snaps may be slow, there may be a lot of machinations going on to make it happen, but at the end of the day it's just a file. You have the file, your program runs. That's a big advantage.
Snap doesn’t work well in distributions that don’t support Apparmor, so you will run into various issues.
The biggest concern I have with Snap is that it’s hardcoded to a store controlled by Canonical. The store itself is closed source. Snaps can be side loaded, but doing so is a huge pain. Snap also requires you sign a CLA with Canonical, allowing them to relicense the ecosystem however they see fit.
> Snap packages that need the same dependencies won't duplicate them.
As long as they depend on exactly the same versions, right? This seems unlikely to happen by chance, without someone there to actively coordinate the versions, so there will still be substantial duplication.
Shared dependencies made sence back in the day, when the world was a simpler place and there was less variety.
We have long since arrived at a point where its much more sensible to sandbox every application, with a majority of it's dependencies - less things break, less compatability problens, easier updates, greater reliability.
All major operating systems have done this now, Windows, Mac, etc. There is no turning back now.
Is it? On the Linux desktop there haven't been any new desktop apps for well over a decade (up to maybe Krita and the Blender redesign). Inkscape has been 20 years in the making and just released 1.0. These apps are basically developed against the X Windows API from 1983 or so. So for which hypothetical apps exactly we do need these enormous container formats isn't clear at all. It's not that the existing desktops apps like Libre/OpenOffice (also from late 1980s/early 1990s) have grand plans for new components, or run better all of a sudden.
Is it browser-/Electron-based apps that need constant updates? Then the developers really should consider their choices; why would I download a webapp along with a whole browser runtime repeatedly rather than simply run the app from their website, especially when the target environment is also sandboxed like a browser? That simply doesn't make sense. At a certain point, after over 25 years of attempting to shoehorn the web into an app delivery platform, things get absurd.
It's true though that shared libs have caused more trouble than worth, and are the root of this mess. But the solution is simply to not use them and just ship statically linked binaries instead rather than put a layer of abstraction over them. Even on DOS/Windows back in the day users were able to download an .EXE.
Basically a snap package is a container, that means an image of an operating system just to run one software. Just this idea should be considerered stupid, is like saying every software is distributed in a Docker container. It's a great way to waste disk space, and also RAM since shared library are no longer really shared...
You can have software that update automatically also with debs, where is the problem? Unattended upgrades exists since decades, you install it, and it updates all your packages automatically.
You can even have proprietary software packaged in .deb packages, why not, if for Canonical that is a concern. You can even have software that runs in a container packaged as a .deb package, why not?
Snap has no real purpose to me.
Flatpack is something that makes more sense, since it aims at providing a way to package software for multiple distributions, doesn't really need a runtime, a daemon like snap, but it builds application bundles that you double click and run, without installing them.