Snap is an attempt by Canonical to control Linux applications. The only Snap server is run by Canonical and they have not published the server software. Don't support Snap.
If you want to know why there is so much resentment towards Canonical and Ubuntu in the rest of the Linux world, this is a good example. https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/
@be i like Ubuntu but i’m fed up with disabling snap on every server and desktop i use.
If they still push this shit i will go debian.
My company gave Ubuntu Core (a Snap based distro) a serious look, despite our distaste. Start by forgoing most security, like system users ("it's coming" since 2018), paying royalties to run your Canonical controlled snapstore, broken compatibility on every update so far, and a mandatory app API that only supports desktop apps. The "many existing applications" is zero, b/c only desktop apps are currently allowed in the public store, while U.C. targets headless edge IoT. Total PR garbage.
To be fair though, Flatpak and Snap have similar problems with defining a permission interface that is desktop first and doesn't do well with daemons. But things like Fedora Silverblue don't rely on Flatpaks for daemons, and instead run custom containers, while Ubuntu's equivalent, Ubuntu Core, is "snaps all the way down" despite their inability to provide what's needed.
@be and 5 years later we see that it really isnt going very well and quite the opposite of "uniting" any distros. On the surface Its "okay" package management at best for those using it.
@be A quick look at Flatpak's packages will tell you all you need to know. Also, even Elementary (derived from Ubuntu) is moving to Flatpak with 6.
@be also because they're fucking white south african blood money and have never been a good-faith participant in the larger community
@migratory Ah yeah, it's just great how a white South African billionaire appropriated a Bantu term (Ubuntu) an turned it into a global brand.
@be snap already had other conceptual and design flaws that made me refuse to have it anywhere near any of my systems even before adding this consideration.
@be I once setup a system for group use with the firefox snap. It performed poorly, had desktop integration issues, etc. Then I removed the snap to migrate back to a normal install seeing that was a fail. Because snaps keep app settings inside the snap rather than as part of the user's home directory, every user permanently lost ALL their firefox settings all at once. Bleh...
@be I also once tried the #rocketchat #snap on #debian, and #lxd since they refuse to package it except as a snap now. That too had problems dealing with external filesystem locations, which is terrible for a system service that manages file data. Besides the desktop snap issues, snap based deamon services overall felt like running a bad implementation of docker. I refuse to package my own stuff as snaps.
@Seirdy @be what you get to at the end also touches upon what I mean by solving a problem we do not have. Yes, proprietary vendors do not care to learn our ecosystem and would not want to submit source packages to be built for a distro repo. Sandboxing also seems a crude tool; for a browser I might actually want to sandbox instances accessing web individual sites; that is, app context aware inside app sandboxing.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.