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.

@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.

@be i just started a new part time job and their servers are on Debian... so the move will arrive.

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.

@tychosoft I'm not aware of those, care to say more?

@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 on , and 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.

@be @tychosoft The biggest design flaw of Flatpak and Snap is, IMO, combining sandboxing and software distribution so tightly. IMO, sandboxing should be something independent that the distribution platform can depend on.

Basically, sandboxing a system program and sandboxing a Flatapk should be a similar process. Right now, bubblewrap isn't very usable alone. If effort were instead put into a bubblewrap-based program to make it more usable and sandboxing were removed from Flatpak in favor of just using that program for any software (Flatpak or native), I'd be quite happy (something something UNIX philosophy). The closest thing we have right now is bubblejail (a FireJail-inspired bubblewrap wrapper).

I would say that Flatpak is much less bad than Snap because Snap is a closed platform. Like any closed platform that people depend on, this gives Canonical power over the ecosystem that lives on said platform. This is another good example of the difference between "free software" and "open source": both Snap and Flatpak are OSS but Flatpak is more "free". It's also a good example of why I dislike the "free/nonfree" binary: while plenty of software is certainly 100% proprietary, not all free software is equally free

@Seirdy @tychosoft That's a reasonable critique. Not knowing much about the technology implementing it, I don't understand why sandboxing should require any particular packaging format.

@be @Seirdy Sandboxing solves a problem we often do not have. And yes, the questions of distribution packaging and sandboxing should be decoupled. Separation of concerns. I think appimage does the generic packaging part without trying to also manage sandboxing.

@tychosoft @Seirdy I think the way Flatpak strives for a middle ground between "only link system packages" and "vendor everything" is really interesting.

@be @tychosoft Snap and Flatpak try to solve many problems at once. I think that there are many solutions that solve individual problems for a subset of programs. Each partial solution has minimizable trade-offs but can work better for a subset of users that are okay with those trade-offs. Many small subsets add up to a big chunk of the ecosystem.

Library versions -> static linking, vendored libs (like what most browsers do)
Interpreter versions -> backward-compatible code, backports/polyfills, and bundled interpreters
Sandboxing -> operating system syscalls (seccomp), bubblewrap as a library (webkit2gtk3 does this), external sandboxing tool (bubblewrap with a bunch of flags, a bubblewrap wrapper like bubblejail, firejail)

I could go on.

Some of these require more work for the user, but I think that this is a problem solvable with better + more intuitive tools. Some solutions require more work for devs. For some entries such as "interpreter versions", good maintainers can help share the load.

Only when no partial solution looks good would Flatpak be a good fit. Blender and Gimp, for instance, would be a good fit: Blender uses a lot of its own tools and Gimp depends on a ton of libs and resources that need to be kept in sync. Kdenlive is a good example of making complex software easier to package: if you already package the essential KDE and multimedia components you've done most of the work for packaging Kdenlive.

The best use-case for Flatpak is proprietary desktop apps like Zoom or VS Code (though using an IDE inside a sandbox can be a pain). The best way to distribute proprietary desktop apps is not to distribute them, because FLOSS=good. The second-best way is to use Flatpak.

@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.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.