Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Be quite, Snap is vendor-locked.


sort by: page size:

Thanks for the heads up. Have dealt with snap before (and eviserated it)

The Snap Store is controlled by one single entity, as is the Snap project itself. These things make it impossible that many other distros can use it.

We're already there. The snap store is not open source and can only be run by canonical.

And snap doesn't address the fact that the server components that talk to the snap 'store' software is closed-source and only available from Canonical.

Checkout snaps, where packages are preferred sand boxed and locked down, and require explicit permission from store operator and the user to install with unrestricted rights https://snapcraft.io/

And snap store backend is walled garden, you can’t really even make official snaps as external packages. Everything depends on Canonical.

Isn't SNAP is already restricted from tons of other things?

Slight correction: you can easily download a Snap from a website and install it like you would do with a Deb package.

It's the repository that's locked; Snap only supports a single repository; the "Snap Store".


The Snap Store server is closed source and controlled only by Canonical. There is currently no fully functional FOSS reimplementation of the Snap Store server.

Aren't channels things like "stable" or "bleeding edge" or something like that? Which means that this would only work if the snap vendor cooperates.

Snap is not vendor neutral - it has hard coded dependence on Canonical infrastructure. If you want to provide your own, tough luck.

Calling to attention about that is not anti-canonical trolling. It's avoiding creating a dependence on a third-party.


> the Snap Store server is proprietary and controlled only by Canonical.

Has nobody reverse engineered or created a replacement yet? I assume that's because nobody with the ability has the desire.

If this spurs anyone into action; make it AGLP3 or some other similar license.


how do we know? the snap server is proprietary and closed-source, right?

Oh God... I am not going to repeat myself. To put it briefly: Snap Store is Canonical's Play Store.

Then snaps could be the solution for proprietary software, not for regular software.

>If you really wanted to, you could run a lot of your software in unprivileged containers secured with seccomp.

We've come full circle, because Snap does run software in unprivileged containers.


What, no snap?

Snap is horrible.

The software required for running a Snap Store instance is proprietary [0], and there are no free software implementations as far as I know. Also, the default client code hardcodes [1] Canonical snap store, so you have to patch and maintain your own version of snapd if you want to self-host.

Snapd also hardcodes auto-updates that are also impossible to turn off without patching and maintaining your own version of snapd / blocking the outgoing connections to Canonical servers, so snapd is also horrible for server environments. To top that, the developers have this "I know what's good for you, you don't" attitude [2] that so much reminds me of You Know Who.

[0] https://www.techrepublic.com/article/why-canonical-views-the...

[1] https://www.happyassassin.net/posts/2016/06/16/on-snappy-and...

[2] https://forum.snapcraft.io/t/disabling-automatic-refresh-for...


The solution is just not to use snaps. Snap is trash. Consider PPAs if you need the most recent version of a particular piece of software.
next

Legal | privacy