Linux

12 readers

1 users here now

founded 2 years ago

How do you think about Snap? (kbin.social)

submitted 2 years ago by wave_walnut@kbin.social to c/linux@kbin.social

31 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 3 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.

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

[–] TCB13@lemmy.world 5 points 2 years 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.

[–] moon_matter@kbin.social 3 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.