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

Linux

114 readers
1 users here now

founded 2 years ago
21
How do you think about Snap? (kbin.social)
submitted 1 year ago by [email protected] to c/[email protected]
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
[โ€“] [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.