I congratulate the
Linux Mint team for clearly taking a stand against snaps today by removing it from their repository, it was something many of us were voicing already since last several months. Snap is being shoved down upon Ubuntu users' throats by making it the default which isn't a very sensible thing to do.
 |
|
- The backend is proprietary.
This goes directly against the spirit of what Linux and FOSS stands for. Building proprietary platforms and turning them into walled gardens is exactly what companies like Microsoft and Google are doing, this is exactly why us Linux folks wanted a separate ecosystem in the first place. Snap is highly problematic in this regard.
- Developer controls the updates.
Again, this goes directly against the GNU Philosophy. In fact, one may as well use Windows or OSX if they wanted to go this route, why use Linux at all?
With proprietary software, the program controls the users, and some other entity (the developer or “owner”) controls the program. So the proprietary program gives its developer power over its users. That is unjust in itself; moreover, it tempts the developer to mistreat the users in other ways.
APT does a fantastic job as it is.
apt/deb is a wonderful package management system and everyone is happy with it, at least the majority of Ubuntu/Debian users. Besides, dnf/rpm is also a similar packaging system for Fedora/RH systems and everyone is happy with that too. In the age of Jenkins and automated builds where builds can target multiple formats, I don't see why its so important to dump two working solutions for package management and invent a new one from scratch.
Don't shove it down our throats, make it optional at least.
If it were really so important for the distros to provide snaps, the least they could have done was made it optional, why have it by default and mandatory? If I really wanted it, I'd simply "apt install snap" my way into installing it.
Also, as the article mentions, starting from Ubuntu 20.04, the DEB package for chromium sneakily directs you to the snap package instead of installing it from the apt repository without even the user's consent or permission. This behavior is no different than what a backdoor does. This, along with other mentioned reasons reeks of glitches and bad intent with respect to snap, hence it should be avoided as much as possible.
21 comments:
You have missed a vital point: snap packages are buggy as hell! Peek, a simple screencast tool, when installed as snap doesn't capture the screen at all. Slack doesn't open links in the default browser. Certain snap applications don't copy/paste between each other (which is the craziest/stupidest bug ever IMO), and the list goes on.
One problem solved by Snap that isn't solved by Apt is self-containment. But both Flatpack and AppImage solve this problem while being less problematic w.r.t. the FOSS community.
Even with CI/CD (Jenkins et al.), the problem of dependency management still exists. As a developer, you're restricted to the intersection of packages provided by your supported distributions and the minimum API version across all platforms. Self-containment allows you to deploy on all platforms regardless of the other libraries provided by the distribution.
Fantastic Article, Snaps should have been option.
In all my new installation Debian is replacing Ubuntu...
This is quite an unbalanced article. None of the benefits are mentioned at all. I suppose everyone is entitled to their own opinion.
Snap solves distributing security updates to web apps that can run in Snap strict sandbox, where web app code does not have access outside of sandboxed directory. Web app developers get constantly new updates to Node.js and other dependencies, and reports about vulnerabilities from security researchers. With Snap, updates are installed to thousands of servers so that the window of opportunity of web apps to get hacked gets smaller. Usually soon after some CVE is announced, some hackers reverse engineer that and start hacking servers.
If some Snaps (or other packaging formats) are broken, proper reaction would be for Open Source community to help fixing those packages, and help with packaging to other packaging formats.
I have spent many hours packaging to Snap and other formats for Wekan Open Source kanban https://wekan.github.io . For me, Snap is the best packaging format, because when I release update that has security etc fixes, it also updates all my servers where Wekan is installed, without any user intervention. Snap is available for many distros, and I'll try to create multiarch Snap so that it would work for also other CPUs than x64.
Compared to Snap, Docker takes much more disk space with those many layers.
I have Ubuntu on both my laptops. I think snaps makes it slow. Apt does a great job. Let's go back to apt.
Am I missing something isn't https://github.com/snapcore/snapcraft and https://github.com/snapcore/snapd Free Software under the GPL3.
I had seen some discussion before about the server not being open source but I can clearly see the store api there. I'm just looking at the code now and haven't taken any time in testing it out for myself yet.
Regarding debian packages and apt as we have seen with the amount of PPAs, there really has to be some solution for that. I like the snap format I believe it's heading in the right direction. It still has some problems with desktop software but that seems to be addressed as it has progressed.
There is this strange cold war between Red Hat and Canonical and Red Had seem to have most of the NIH problems if you look at the history. I really don't think Red Hat or some of it's developers possible like relying on code from Canonical.
So true but for news users snaps are alot easier to use.
I was invited to upgrade to the latest version of Ubuntu a few days ago but I've decided to ditch Ubuntu permanently because of this and use Debian instead.
@Ólafur Arason
The part you're missing is that, while you're correct that the snap client and daemon are indeed open source (as is the store protocol specification), the store SERVER that actually hosts the packages for distribution is NOT.
Additionally, the client is hard-coded to use the Ubuntu Store.
There's no config files, no equivalent to sources.list.
If you want to host your own snap repo, for whatever reason(curation, self-hosted publishing, private/internal enterprise repo, etc) you have to:
1) write an entire snap store yourself, and implement every server-side part of the snap protocol yourself, to be able to host a repo privately, AND
2) edit and recompile snapd to point at your own repo instead of Ubuntu Store. (There is no "in addition to"; the code has no implemented way of resolving multiple sources. If you switch off of the Ubuntu Store, you get nothing from them.)
If you want private repos, you literally have to do all the same implementation work yourself, and it cuts you off from the Store.
This is incredibly hostile to anyone that wants to consider hosting a private repo, and all attempts to request multiple/private repo support from the Ubuntu team have been essentially met with middle fingers.
You don't get the point of snaps and flatpaks at all. Debs ans Rpms are not perfect at all. They are not "self contained", that means that each package requires other packages in order to work, and specific version of librairies that are contained in those packages. And given that every six months there is a new ubuntu release, mantainers have to work a lot just to make sure specific software are still working and to fix potential issues. Snaps, flatpak and Appimage are trying to address these problems, and they do for the most part. They are not perfect yet but they are becoming better after each new release. In the future developers will spend their time improving apps instead of just making sure they start and work. About Snaps. It's true that snaps and the snap store are products by canonical. It's not true that snaps are proprietary software, but it's true that the snap store infrastructure is still closed source and fully owned by canonical. Alan Pope from Canonical explained why this isn't open sourced yet and also stated it will eventually become (go watch the interview on linux for everyone youtube channel). I personally think that all this hate towards Canonical is unjustified. Of course snaps are not perfect and Canonical sometimes does mistakes, but it is also true that projects like Mint exist because Canonical made ubuntu. Clem should bow before Mark Shuttleworth because without ubuntu Mint would never have existed. It is also true that while taking some "controversial" initiatives Canonical is pushing the entire linux ecosystem forward.
A big part you are missing is that it is a tool that can offer security features and sandboxing that apt isn't providing.
How was snap ever proprietary?
Mint dropping snap support is that same way gnome support was dropped. Reluctance to change.
What snaps (and other similar systems like Flatpak and AppImage) are trying to solve is the problem of fragmentation in Linux ecosystem. A developer can just build a single package that will run on all distros, compatible with the chosen packaging system, instead having to re-build the same package against several dozen different versions of runtime libraries contained in various distros. Sort of like it's done on Windows. You just make a single setup program for all Windows versions, not a separate installer for every version.
Both users and developers benefit from this: there's only one package to maintain which is self-contained and easy to install for new users.
Of course I'm strictly against forcing of snap usage, but I do think snap system does deserve a chance.
Totally agree. Snaps also increase overall boot time. With one or two you won't notice the difference, but with a dozen you'll definitely notice the difference (and I have a i9 with plenty of RAM and a m.2 hard drive.
Than you. Yes, I have uninstalled Ubuntu, primarily because of Cannonical’s anti- open move but also because Ubuntu does not meet performance requirements for my new machine.
I have uninstalled Ubuntu- power to the open movement!!
@TheDarkFreak
"This is incredibly hostile to anyone that wants to consider hosting a private repo, and all attempts to request multiple/private repo support from the Ubuntu team have been essentially met with middle fingers. "
The Snap Store wants to address a known problem with PPAs, indeed private repositories that proved in the years to have a common problem: they are not easily discoverable and they are often unmantained after just a couple of ubuntu releases. When users look for new software, they want to open a Store, look for the program they want and install it, not look on the web for some guide (often not up to date), to enable some obscure repository (obscure because everybody can open a PPA, and we don't know who the hoster actually is) and see what happens. For that reason I like the idea of a unique, central repository of software. What I don't like, maybe, is the fact that this central repository it is owned and managed in the hands of a single, private company, and not because I think companies are *evil*. The problem here is that a company is not a stable enough entity to host a such important repository of software. What happens if the company is aquired by some other hostile company? To me, this is the real weakness of the snap ecosystem. To me, Snapcraft.io should be managed by an independent consortium: an external organization (foundation?) made to develop and mantain the tecnology behind it: exactly like flatpak.
@neff
Having the freedom to add new repositories and be able to create new repositories (both made impossible and very difficult respectively) isn’t a “Problem”, but rather a feature.
If you don’t want to use an “obscure” repo, you don’t have to, but that doesn’t mean others shouldn’t be allowed to make their own for the purpose of hosting software
@Bob Pav
yes it was a feature that has proven to lead to problems: see what happens when you try to upgrade OS version or when you look a repository for a software. As I said in my previous comment, repositories are not easily discoverable. The idea of a centralized but open repository is to me a much better solution. That's also why it's easier to find flatpaks and snaps than appimages.
We get the point of snaps and flatpaks. It just turns out that the solution provided for that point turned out to be horrible.
We get it... you want portable applications distributed in a way that is independent of distributions and limitations of the shared libraries and other dependenscies. Great. But lots of us don't need or want to be tied to bloated packages that duplicate resources, update themselves without notice, provided by a proprietary system, and don't integrate with the rest of the chosen distribution well. And if they are "integrated" then they just become distribution dependent which violates the whole "point" of them.
Snaps for portability? Great. Every distribution should provide a way to install snaps AND provide a way to install the distribution's non-snap version of want for common applications. Take LXD for example. No reason for that to be a snap. If you're installing LXD you're intending that system to be a significant and integral part of what that server does. It should be as lightweight and as stable as possible.
Post a Comment