I'm on Fedora where the equivalent is called Flathub/Flatpaks. There are definitely some rough edges still, but the possible upsides are amazing for me.
It makes it way easier for a developer to release for different Linux-flavors. The applications get sandboxed and there is much less risk to mess up your system. Stuff like permission, similar to Android/iOS becomes possible.
There for sure is problems to: it makes it way easier for a lazy developer to ship ancient libraries without security fixes, the "packages", now images, are much larger and the quality check of the packager gets sidestepped. And, as always when you try something new, it gets worse before it gets better.
But I think the idea is good and I hope for the best.
The way i see it, software which is truly part of the distribution can and should still be packaged the traditional way. But snap/flatpak creates a standard way to install software which is not really part of the distribution. It replaces all the random tarballs and unpacking things in /opt that you occasionally had to do when installing third-party software. It makes sense for VS Code, IntelliJ, Slack, Chrome, etc, to be in snap/flatpak.
It doesn't make sense for open-source software built with traditional tools by the distribution maintainers themselves to be in snap/flatpak.
I note that on Ubuntu 18, snapd itself is distributed as a snap, which seems like a very poor idea to me.
> snapd itself is distributed as a snap, which seems like a very poor idea to me
I took this as a "vote of confidence" that snap could self-host snapd.
Hosting via snap means they can push updates and not have to wait for users to `apt update; apt upgrade`, as snaps auto-upgrade without user intervention.
> I'm on Fedora where the equivalent is called Flathub/Flatpaks. There are definitely some rough edges still, but the possible upsides are amazing for me.
Except Ubuntu and Fedora each use their own container format. The entire reason we're in this place is that RedHat went with .rpm and Debian/Ubuntu with .deb. There's no-one winning in this format war, and no-one is winning by putting yet another layer of abstraction either. Like with Docker, the problem that container app images are trying to solve (that of incompatible 3rd party shared libs) cannot be solved by containers, because the reason for shared libs to exist in the first place is so that eg. security vulnerabilites in old shared lib versions can be transparently fixed by having the OS install newer libs; but (as you say yourself) with containerized apps this is impossible. You might as well ship statically linked apps instead.
> The applications get sandboxed and there is much less risk to mess up your system.
Apparently snaps are also sandboxed between versions of the same application. My very first experience of snaps was Vuze getting updated overnight and all my configuration and torrents just vanising.
I ended up rolling back the version (to restore everything that disappeared) and, upon discovering snaps are designed to never be able to lock a version number, shot it in the head by killing the daemon and chmod'ing its executables to not be executable.
I assume Vuze's snap was misconfigured, but it really turned me off of them and I've since decided to stick to nix instead of snap whenever I can.
My understanding is snap and flatpak are not equivalent at all because snap is more permissive whereas flatpak is sandboxed.
Specifically, it is not possible to do gpg signed commits from flatpak (e.g., jetbrains idea) without tweaks upstream.
I agree with the overarching idea though: it gets worse before it gets better. See wayland and how we still can’t capture display in obs.
I am a little torn on this. Should the onus to “fix” be on jetbrains and obs? I personally think no where possible. Replacements should be drop in without effort or at least with clear guidance and not too much effort on behalf of individual applications.
Snaps are sandboxed. They can be granted extra privileges, such as access to $HOME, camera, bluetooth etc. Some of these interfaces such as $HOME can be gained automatically by any snap. Others need to be granted by Canonical (to automatically grant access on install), or manually granted by the user post install. There is also a 'classic' mode where the app is unsandboxed, which again needs to be granted by Canonical and in addition requires explicit acceptance by the user when being installed.
"classic" snaps are not sandboxed, and you have to acknowledge that when installing them.
"modern" snaps are sandboxed, and you can change their permissions in the Settings/Control-Panel app. You might argue with the choice of permission granularity, but it IS there.
It makes it way easier for a developer to release for different Linux-flavors. The applications get sandboxed and there is much less risk to mess up your system. Stuff like permission, similar to Android/iOS becomes possible.
There for sure is problems to: it makes it way easier for a lazy developer to ship ancient libraries without security fixes, the "packages", now images, are much larger and the quality check of the packager gets sidestepped. And, as always when you try something new, it gets worse before it gets better.
But I think the idea is good and I hope for the best.