I’m very beginner of Linux server admin. Few days ago I set up snap version of nextcloud server app on my own Ubuntu VPS server, and I found that Snap system might be focused to build original file system hierarchy in /snap directory, and I felt a little weird about that.
For example, Linux file system hierarchy is defined to set server app config into /etc/app/conf.d or so.
But snap version app tend to set it into /snap/app/current/app/config or so.
It sounds so complicated for me.
So I want to know about how Snap is thought by others. I’m happy if you might tell me something here.
The problem I have with Snap is that it’s a rather mediocre over-engineered technology (e.g. decompressing images had poor performance for a long time; see the Firefox snap drama) that is pushed very hard by Canonical. It has a closed-source market and nobody knows what Canonical does on their side for performing anti-malware scans (that haven’t been very reliable in the past). That’s not how open-source works. We want to have a decentral approach like Flatpak repositories have.
Flatpak is my default, but sometimes I also use AppImages.I simply don’t understand why snaps exist in 2023 with the existence of flatpaks.
I only use it for my #Nextcloud instance. #Snap does make it easy to upgrade or rollback and configure. That said I wouldn’t use it for anything else and would probably use the #docker image next time.
Why bother when you have flatpak?
Because you’re Canonical?
I’m all for native packages, no appimages/snaps/flatpaks.
For instance, Joplin is only available as an AppImage, whats the result of that? On the same machine under Windows it launches instantaneously under Debian it takes 3-5 seconds to launch the AppImage. Why are we propagating this BS?
Another example, up until Debian 12, LXD/LXC was only available as a snap. Besides the overhead and the 9999 snap processes always running, snap updates your stuff automatically and you get tons of broken things.
Package maintainers prefer appimages/snaps/flatpaks over native because it’s as close to write once, deploy everywhere as we’re going to get. Maintaining packages for distros is a thankless job often done by volunteers because there’s no possible way for the developer to maintain packages for every distro.
The idea itself is reasonable enough: get some security by isolating packages from each other, and avoid python-style package conflicts by isolating dependencies as well.
Macs have been doing it for forever, and hardly anyone noticed.
Which leads to the real problem, that Canonical’s implementations are consistently terrible.
They’re slow, I vastly prefer Flatpaks.
It’s annoying fragmentation when even for a stable distributable package there’s flatpak as a standard, and I’ve never seen why Ubuntu needs their own with a proprietary store.
Like I generally tend to favor native packages, but I can at least appreciate Flatpaks having advantages and times even I want to use them. (Largely when stuff is a pain to compile on Arch for library reasons.) Snap is a non-universal universal package format.
(Also going to shout out AppImages, which are an entire package as a single ELF file you can run on basically any distro. I’m not sure how good they are for important work, but I just think they’re neat and have come in handy for running stuff on old CentOS in the past.)
For server software I prefer docker/podman,
For desktop apps I prefer native and then flatpaks
