Sharing a 'small' inconvenience I had to fix with #opensuse #slowroll (I suspect #tumbleweed is the same) - I couldn't launch snaps (spotify, bitwarden) after update - error was: ` cannot
Sharing a 'small' inconvenience I had to fix with #opensuse #slowroll (I suspect #tumbleweed is the same) - I couldn't launch snaps (spotify, bitwarden) after update - error was: ` cannot
@linux Sharing a 'small' inconvenience I had to fix with #opensuse #slowroll (I suspect #tumbleweed is the same) - I couldn't launch snaps (spotify, bitwarden) after update - error was: cannot determine seccomp compiler version in generateSystemKey fork/exec /usr/lib/snapd/snap-seccomp: no such file or directory
The fix (I first tried re-installing, didn't work) was to:
a. locate snap-seccomp - was in /usr/libexec/snapd
b. symlink: ln -s /usr/libexec/snapd /usr/lib/snapd
Not being able to launch snaps seems like a good feature
Why not flatpak?
@pastermil @linux I use both. There are packages where the website officially lists snap packages, no flatpaks.
Unless the project website has a link/install instruction recommending flatpak, I prefer either the distribution package where available, or snap otherwise - this is more from a supply-chain perspective - since snap requires the original developers of the package to package snaps.
If the developers have officially listed flatpak on their site, that however, is good enough for me.
I would take this with a grain of salt. For me, as long as the package is available and functional for my prefered installation method, I'd go with that.
Take cerbot for example. For some reason, the cerbot developers uses snap in their installation guide. I've been using apt on all my projects that requires https, both personal and professional (yes, I get paid to do this, among others). Never had any issue with it.
This is why I prefer using Distrobox on my personal computer. No package for Signal-Desktop? No problem, run it through a Debian container using Distrobox.
But snap is cringe