Hacker News new | ask | show | jobs
by xet7 940 days ago
This is discussion at 2019-2021.

There are many distros where snapd is not installed by default, including Linux Mint:

https://snapcraft.io/docs/installing-snapd

Nobody is forcing you to use distro that includes snapd by default.

Snap has advantages for server software that are using Snap strict sandbox:

- Strict sandbox does not allow read access outside of /var/snap/APPNAME/common . Only common directory is writeable.

- Snap code at /snap/APPNAME is read-only and can not be modified

- When new version is released, for example with security fixes, it is automatically updated worldwide, keeping servers secure.

Linux Mint has MintUpdate, that has options to enable automatic update of .deb and FlatPak packages, keeping everything up-to-date and secure without any clicking. Windows and Mac does not have that, you need hundreds of clicks to update each software separately, having many apps still vulnerable.

4 comments

I have ~8 self-hosted services with docker-compose and one with snap (nextcloud). While I get that snap gets some flak for how cavalier it can be with your system, ultimately my nextcloud is always up to date and I've had very little effort to put into it in over 7-8 years, which is not something I can say from my running docker containers. It might not be for everyone, but from a security standpoint it's much less fussy than basically everything else that I've tried.
Snaps have some cool use cases, like the one you mentioned. flatpak isn't there yet for CLI apps or hosting stuff from when I last checked, and the snaps for things like nextcloud just work. On a desktop system though, it's clear that everyone should just adopt flatpak for a universal app standard for the time being.
Why not just write something (or use a pre-existing tool) to update your docker containers? I know on Kubernetes there's plenty of tooling around Helm.
I redid my docker stuff with podman and quadlet recently and it's been great. Quadlet turns the containers into behaving like regular systemd services (i.e. you can trigger them with timers), and "auto update" is just setting Pull=true when the container re-runs (there's a heck of a lot of good reasons to also not do this).
To the point, I completely agree that snap seems to work quite well for server software.

Which makes it additionally frustrating that Canonical is insisting on forcing it on all the desktop users.

No one is installing server software through the Software Center. So why does that have to prioritize Snaps?

Canonical could very well have promoted snap as an option to package server software and used flatpaks or even debs for desktop software. There is no reason the 2 couldn’t exist as primary options at the same time for different use cases.

I believe flatpak provides all of those advantages too
Are there any advantages to using snap instead of docker for server software?
unless you have a lot of free time for debugging - none. We had a project where managment team force everyone to use snaps (cause of some weired company relations with Canonical) and guess what? They did not make it. I think we just wasted 6 months in order to get to be able to do stable prod releases with snaps and it felt like docker more mature and stable in every aspect. I guess that time and money could easily stream to do actually usefull things for end-users.