this post was submitted on 17 Jun 2023
21 points (100.0% liked)

Linux

114 readers
1 users here now

founded 2 years ago
 

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.

top 28 comments
sorted by: hot top controversial new old
[–] [email protected] 9 points 1 year ago

Not a fan, mainly because it’s proprietary. Canonical hosts the only repository and you can’t change it. The file system stuff is secondary.

I do think Flatpak is alright, and I use a few Flatpak apps, but since I use Arch, I generally prefer to install things from the AUR.

[–] [email protected] 8 points 1 year ago (1 children)

I simply don’t understand why snaps exist in 2023 with the existence of flatpaks.

[–] [email protected] 2 points 1 year ago

As the makers of the most popular distro and the creators of Snaps, the format will continue to exist until Canonical decides it shouldn't. The Linux community doesn't have a lot of say in the matter. Fragmentation and duplication of effort is also nothing new to FOSS and it has both pros and cons.

[–] [email protected] 8 points 1 year ago (1 children)

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

[–] [email protected] 6 points 1 year ago (1 children)

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.

It's the Canonical way, just as with Mir, Upstart, Unity, and a bunch of other NIH Canonical projects.

I miss the old Ubuntu sometimes, the Ubuntu that wanted to be an up to date Debian with sensible defaults, easy installation, and commercial support. It seems that wasn't profitable or visionary enough for somebody though, and we've ended up here instead.

[–] [email protected] 2 points 1 year ago

It's the Canonical way, just as with Mir, Upstart, Unity, and a bunch of other NIH Canonical projects.

A commonly repeated lie.

Mir, Upstart, and Unity all precede or are parallel to the other project. While Wayland technically existed when Mir was created, Wayland wasn't very active at that time. Upstart was replacing init, systemd was created later and draw inspiration from Upstart. Unity was replacing Gnome 2, Gnome 3 was released a year after Unity and was a mess. Finally, Snap and Flatpack are more or less parallel, both solving a different issue, with Snap being a more system-level solution such as for drivers, IoT, while up until recently, Flatpack couldn't handle command-line apps at all, concentrating solely on GUI apps installed through GUI appstore.

[–] [email protected] 8 points 1 year ago (1 children)

Why bother when you have flatpak?

[–] [email protected] 5 points 1 year ago

Because you're Canonical?

[–] [email protected] 6 points 1 year ago

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.

[–] [email protected] 6 points 1 year ago

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.

[–] [email protected] 5 points 1 year ago

Think of your datacenter as hooters restaurant. Snap is the creeps there, you want them nowhere near your servers.

[–] [email protected] 5 points 1 year ago* (last edited 1 year ago) (2 children)

IMHO: It's bullshit, wastes resources, ubuntus server implementation is proprietary and it fragments the package management of a distro. Snap is the worst, flatpak and appimage are tolerable since they are at least open source but i personally try to avoid these "solutions" like the plague.

apt for the win...

[–] [email protected] 6 points 1 year ago

Eh, when Debian doesn't have the latest version of dependencies, Flatpak is necessary. Flatpak will long-term likely be great for running abandoned legacy software too.

[–] [email protected] 3 points 1 year ago (1 children)

People always complain about "dependency hell" with apt, but I've always found it to be the perfect solution

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Me too, you just need to avoid installing packages from repos that are not for your distribution. And live with the package versions until the next release is ready

[–] [email protected] 4 points 1 year ago
[–] [email protected] 4 points 1 year ago* (last edited 1 year ago)

For server software I prefer docker/podman,
For desktop apps I prefer native and then flatpaks

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago) (1 children)

As others have complained, canonical and a lot of extra overhead (like mount an entire FS for every snap running). I tried it and got rid of it quickly. I do use flatpacks but really only on my gnome desktop (arch) due to the ease of the gui software center being right there. (EDIT: This is how containers work, I get that, it's just a lot for system utilities or small apps)

Are you using nextcloud locally or facing public? I run nextcloud on a homeserver but for anything public facing I run in a docker container on it's own bridged network served up by Caddy proxy container. It's no where near "hardened" or full proof but it's something better than just facing a snap at the world tbh.

[–] [email protected] 3 points 1 year ago

I really like the way Silverblue handles it--with flatpak being the standard for GUI applications and toolboxes being the standard for CLI applications

[–] [email protected] 3 points 1 year ago

They delved into this a bit in the latest Homelab episode around 35 minutes in or so.

[–] [email protected] 3 points 1 year ago

Just use Nix

[–] [email protected] 3 points 1 year ago

I've used snaps and flatpaks. Snaps take a lot of disk space, but that doesn't bother me much. I'm running EndeavourOS more often than I boot into Xubuntu lately, and I haven't installed snap on Endeavour yet, but I might.

Use what you like.

[–] [email protected] 3 points 1 year ago

They're slow, I vastly prefer Flatpaks.

[–] [email protected] 3 points 1 year ago (2 children)

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.

[–] [email protected] 8 points 1 year ago (1 children)

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.

[–] [email protected] 5 points 1 year ago

What Apple does is very different because macOS apps are mostly written using Apple's frameworks and there isn't a heavy unpacking stage like appimages. In Linux the dev landscape is way more fragmented and that means most snap and flatpacks need to bring A LOT of libraries and a lot of dependencies leading to tons of duplication and a poor performance.

I'm very, very skeptical when it comes to saying that this container tech provides more security. It does in some ways but it also allows for applications to ship with vulnerable libraries for ever. With "native" packages applications are forced to update their code because vulnerable libraries will be replaced in the repositories with newer versions and apps need to follow or become unusable.

[–] [email protected] 2 points 1 year ago

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.

[–] [email protected] 1 points 1 year ago

I've never had luck with snaps. Any time I've tried there has always been someting that didn't quite work. On Ubuntu based systems I generally install via apt or Docker. I have had some success with Flatpack applications on Arch though.

load more comments
view more: next ›