On Sun, Jul 16, 2023 at 3:55 AM Nicolas FOURNIL
> I cannot agree with you : Snap is good for desktop, that's true. But for production environment it's catastrophic :
> - my servers are isolated from internet : "snap way of life" is not possible.
The snap proxy allows for fully airgaped environments in much the same
way you'd normally handle with a package mirror.
For simpler setups that don't need an enterprise-wide solution,`snap
download`, `snap ack` and `snap install` works fine for offline
> - It's also not possible to let canonical do remote upgrade on a running system : before update there's validation on each environment !
The snap proxy allows for enterprise-wide control of what revisions
are being pushed, allowing for such validation pre-rollout.
Outside of using the snap proxy, you can use `--hold` which will
prevent any automatic refresh of a snap, effectively giving you the
same behavior as apt.
> - for replayability : you cannot rebuild a running snap from scratch (what exactly is inside ?)
That may be true for some snaps, for the LXD snap however as it's
included in Ubuntu, the same requirements on re-buildability and on
the source being fully public exists as for debs.
In the case of the LXD snap, its source has always been available in
the lxd-pkg-snap repository, nowadays at
The build is also all happening publicly with links to relevant source
and build log: https://code.launchpad.net/~canonical-lxd/+snap/lxd-latest-candidate/
Again, it's not something that all snaps HAVE to do, but it's
something that all snaps that are included in Ubuntu do have to do.
And as they build on the exact same infrastructure as Ubuntu's .deb,
this is really no different from deb packages.
> - you cannot own your snap store and stay far away from USA (just in case...)
Staying away from the USA, sure you can. Canonical is primarily a US
company, the snap store and all Ubuntu core infrastructure is all
hosted in the UK :)
Canonical only operates some build machines and CDN nodes in the US.
The part about running your own snap store is definitely correct and
the snap store being effectively a walled garden is one of the main
issues I have with it.
There was a community project aimed at running an alternative store
some time ago, but I don't think that really went anywhere.
> For these reasons snap IS NOT DESIGN for Server critical use, but for desktops.
It was designed for IoT, extended for server stuff and then made to do
desktop stuff too. From a technical standpoint, it definitely sucks
the most at desktop stuff, where Flatpack tends to do far better.
The lack of initial focus on offline/airgaped system has definitely
been a problem, but it's a problem that has been worked on and does
have solutions available.
The real issues of snaps are much more centered around the trust model
which relies on a central store, curated and managed by Canonical.
The rationale for that on the Ubuntu side is that you already have to
trust Canonical anyway as whether through snaps or debs, the reality
is that they have root on your system if they want to.
It becomes a bit more problematic when used on other distributions. In
general the central store model does have some benefits, like
enforcing the same security review and policies across all snaps,
making things more discoverable, ...
That's why on the Flatpak side, flathub is so popular. The reality is
that users don't like having to hunt for repositories and have to
individually review them and trust them.
But not offering the option at all and relying on a closed source
store is definitely problematic.