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.
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.
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 don't know of other benefits, though.
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.
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.
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.
"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 will take a while but in the future it will not be any worse at runtime and it will be much, much easier to package and run apps across releases and OSes
I dont care packaging got easier. I care for a smooth working system I can understand and instrument, and that does not hog resources.
I'm not a fan of using it as the default though, and flatpak isn't immune to issues either, for example I use a flatpak package which regularly can't be updated for months because of some incorrect metadata if the error message can be believed.
I still think it's a good step forward for increasing compatibility especially across different Linux distributions.
This stuff is pushed with corporate power. Not adopted because great great fallback method it provides.
The compatibility is also balkanized for the start with the flatpack/snap split. Pfff, what a mess.
sudo snap remove gnome-calculator
sudo apt install gnome-calculator
snap list
snap remove <copy-paste packages from above>
sudo service snapd restart # core is tricky to get rid of
sudo snap remove core
snap list # check it's empty
sudo apt install gnome-calculator gnome-characters gnome-logs gnome-system-monitor
sudo apt purge snapd squashfs-tools gnome-software-plugin-snap
rm -r ~/snap
I hope they smooth these rough edges further before they push more snaps onto the world.
I think this is the wrong way to look at it. You still have access to the same packages as before without snap. If you're using snap, that means you either explicitly chose it, or the package is not available in the repo.
The choice here isn't between a package or a snap most of the time. It's between: not using the app, packaging it on your own, or using a snap which is not perfect.
I understand why they're doing this (primarily to save on build times), but the way they've gone about it (using a transitional Apt package that just installs the Snap) is messy and inconsistent.
If I type `apt install` then I want an Apt package. Under no circumstances should this install a Snap.
You need a migration path from an existing package. It's also nice not to invalidate every post on the web which describes the installation.
Chrome is special... it already doesn't really belong in the repository and was handled in a special way. It bundles tens of libraries in its binary without relying on the system/repo deps. It's actually more natural for it to live with all the other "include all deps" applications.
Anyone is welcome to maintain chromium as an apt package for your distribution release of choice, and you're welcome to point apt to that repository instead. The reason it's not happening is that it's increasingly impractical to do while also maintaining Ubuntu's quality standard for debs.
Exactly!
I found a way to remove snap[1] and get Chromium from Debian[2]. But I'm close to leaving the buntus over this drama.
[1] https://github.com/cies/kubuntu-setup#remove-snap
[2] https://github.com/cies/kubuntu-setup/tree/master/chromium
First I had to research and find out how to give it microphone permissions. That worked, but the mic works for about one minute then stops.
So frustrating, I had to move meetings to Firefox which is where I do most of my work. I like to have two browsers to split the work to that which is most appropriate.
[1] https://github.com/cies/kubuntu-setup#remove-snap
[2] https://github.com/cies/kubuntu-setup/tree/master/chromium
Oh THAT'S why that happens sometimes. I never bothered debugging it.
I used Spotify, VS Code and some PS2 emulator from Snap and haven't seen this behaviour. Which snap package does that for you ?
I don't get why they're doing that. Snaps have mostly created problems for me, like they don't scale when other apps do, or the styling is off, or they don't show up properly in the software manager. The snap daemon on one of my laptops always blocks the shutdown by 30 seconds. Generally a rather confusing experience.