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

Linux

59 readers
2 users here now

founded 2 years ago
1
How do you think about Snap? (kbin.social)
submitted 2 years ago by wave_walnut@kbin.social to c/linux@kbin.social
11 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] TCB13@lemmy.world 0 points 2 years 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.

[–] moon_matter@kbin.social 1 points 2 years 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.

[–] Widget@kbin.social 0 points 2 years ago

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.