Some further context on this that @Dop@lemmy.world might want to know:
While Canonical’s snap store is proprietary (which, to be clear, I don’t really like), all the client software is open source and the API is well documented (though a bit janky). Their snap store relay app (which is open source) has a full implementation of it. There was a fully functional open snap store for a while, but the project died out of a lack of interest. You can also distribute snaps through another mechanism and install them locally on the machine (though you then lose the benefit of snapd’s auto updates). You can even do this with snapd still checking the signatures of the snaps.
The standard for snaps is fully open, as is snapd itself.
There’s no need to oversell the negatives to the point of being wrong.
Interesting, didn’t know it was feasible to make the distribution open.
That doesn’t give me much to complain about in theory, but canonical has lost way too much good faith to give people a reason to keep open snap distribution going for free. They should definitely consider hosting an open store just to get people on board again.
It was being done by a group of snapd developers at Canonical, IIRC, but after a couple of years of exactly zero interaction from anyone outside Canonical I think they just gave up and decided it wasn’t worth it because they were getting accused of trying to monopolise whether they had an open store or just an open API.
Of course, you can also distribute snaps without using the snap store API. I’ve used this for airgapped machines in the past. You can either just grab the .snap file (which is just a squashfs file with a meta/snap.yaml in it so snapd knows how to treat it) and install it with --dangerous, or you can include an assertion file for that snap signed by a certificate that your machine’s snapd trusts and not even have to do that. (Those airgapped machines trusted our own certificate so we could ensure that the snaps came from our CI process and weren’t a developer’s random test snap).
Some further context on this that @Dop@lemmy.world might want to know:
While Canonical’s snap store is proprietary (which, to be clear, I don’t really like), all the client software is open source and the API is well documented (though a bit janky). Their snap store relay app (which is open source) has a full implementation of it. There was a fully functional open snap store for a while, but the project died out of a lack of interest. You can also distribute snaps through another mechanism and install them locally on the machine (though you then lose the benefit of snapd’s auto updates). You can even do this with snapd still checking the signatures of the snaps.
The standard for snaps is fully open, as is snapd itself.
There’s no need to oversell the negatives to the point of being wrong.
Interesting, didn’t know it was feasible to make the distribution open.
That doesn’t give me much to complain about in theory, but canonical has lost way too much good faith to give people a reason to keep open snap distribution going for free. They should definitely consider hosting an open store just to get people on board again.
It was being done by a group of snapd developers at Canonical, IIRC, but after a couple of years of exactly zero interaction from anyone outside Canonical I think they just gave up and decided it wasn’t worth it because they were getting accused of trying to monopolise whether they had an open store or just an open API.
Of course, you can also distribute snaps without using the snap store API. I’ve used this for airgapped machines in the past. You can either just grab the
.snapfile (which is just a squashfs file with ameta/snap.yamlin it so snapd knows how to treat it) and install it with--dangerous, or you can include an assertion file for that snap signed by a certificate that your machine’s snapd trusts and not even have to do that. (Those airgapped machines trusted our own certificate so we could ensure that the snaps came from our CI process and weren’t a developer’s random test snap).