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