That reminds me of the stake Ubuntu Core was born with in its heart:<p>> An Ubuntu SSO account is required to create the first user on an Ubuntu Core installation.<p>They just keep flinging shit at nothing and hoping to hit a wall they can build a gate in.<p>They're trying to boil the frog slowly with Snap on the Server/Desktop branches.<p>There is no possible genuine motive for these maneuverings to be in the position of gatekeeper.<p>If anyone at Canonical is listening, you should be aware it doesn't matter how slowly and carefully you approach this, or how you justify it, the first time I'm forced to kiss the ring to get my software to work, your software is gone from any system I own or manage, immediately and forever.<p>You're not going to get within a thousand miles of monetizing the ecosystem by gatekeeping it -- the moment you even so much as assert the position of gatekeeper you're trying to create for yourselves you're dead to me.
"Interestingly, Canonical actually released an open-source prototype Snap store backend a few years ago, but there was very little interest from the community in in actually maintaining and running a second Snap store, so the project bit-rotted and became incompatible with the current Snap protocol."<p>That open-source server was a single-python-file hacky prototype written in an employee's spare time. It's not surprising it got little interest.<p>Not only that, but this is the biggest omission of the truth: Making your own server is no longer possible because of assertions. All Snaps are now digitally signed by Canonical, so you actually need to have the end-user install a forked snap tool on their system to access the custom repository. You cannot disable this signing - your only way around it is to manually download the snap and install it with `--dangerous` through the CLI. And you won't get auto updates that way.
<i>"Although they invested significant resources in open sourcing Launchpad, there is still only one instance of Launchpad running and they have not received any significant contributions from non-Canonical employees."</i><p>For what it's worth, there <i>is</i> another Launchpad instance in existence: <a href="https://quickbuild.io/" rel="nofollow">https://quickbuild.io/</a><p>From personal experience, I found it functionally impossible to get a local instance working when I tried a few years ago. I applaud someone else managing to pull it off.
It's not for nothing that Snap is considered dangerous by SUSE and is not officially supported. They even fail basic upstream responsibilities.<p><a href="https://blog.linuxmint.com/?p=3906" rel="nofollow">https://blog.linuxmint.com/?p=3906</a><p>> A year later, in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.<p>> First, I’m happy to confirm that Linux Mint 20, like previous Mint releases will not ship with any snaps or snapd installed.
Semi-related:<p>Does anyone else feel like Ubuntu has lost a lot of its momentum over the past few years? I don't hear about things they're doing nearly as often anymore.
This is easy to explain if you think of it as a business decision. Why would anyone pay $30000 for a custom "enterprise edition" snap store[1] -- which among other features restores full control of updates -- if anyone could easily set up their own snap stores?<p>[1]<a href="https://ubuntu.com/pricing/devices" rel="nofollow">https://ubuntu.com/pricing/devices</a>
I do like the snap concept, but some implementations are just not that great. For instance, kustomize as snap doesn't let you read anything outside that is not in the snap fs. Not even in --classic mode. A similar issue happens with nextcloud which is good on paper, but if you tweak something inside the snap fs it will be overridden in the next update(expected behavior); however, for services that require mutable configuration there needs to be a way to preserve that data (I tested that nextcloud behavior more than half a year ago).
I tried not to interpret the article in the worst possible way, but I failed, it feels disingenuous to me.<p>I don't think comparing ppa's to snaps is a good comparison.<p>ppa's have the disadvantage of potential dependency problems which might break things like upgrades, and that has nothing to do with having a distributed store.<p>snaps solve this and that has nothing to do with a proprietary single company controlled store.
My main reason for disliking Snap is the fact that it allows anybody in the world to publish a package with minimal moderation. This completely undermines the inherent trust that system package managers should have.<p>When installing critical system packages, I want to be absolutely certain that these are legitimate/official, and that even if I make a minor error in typing a command, I won't inadvertently install some sort of typosquatted fake version of the package.<p>When using Apt with the default repositories, this isn't a problem at all, as only known, trusted packages are available. In other words, there's no chance of someone publishing a fierfox or apahce2 package to try to typosquat someone.<p>I don't even want to talk about the forced automatic updates either... these make it essentially impossible to have a stable/reliable system for specialist use cases, e.g. browser testing, bastion host, build environment, where control over updates is very important.<p>On the sandboxing - it's good in principle, but rarely seems to be implemented in a truly meaningful way, as ultimately once you have home drive access, you don't even need to worry about escalating privileges as everything valuable is probably in your home area! There's an xkcd about this somewhere...
> Snap is designed so each device only connects to a single store for three reasons:
> users can easily discover new applications,
> developers can easily publish their apps,
> and developing Snap itself is easier.<p>Just a PR bullshit to cover for lack of freedom and need for control. Disregard.
The better question is why is there a snap store? With flatpack and appimage already working well, why muddy the waters with another offering, much less one that it awful.
God, I could not hate Snap more. At least a .snap file can be mounted as a SquashFS and salvage what you can to run the program without snapd. Unrelated, but it is curious that some applications I have encountered depended on some proprietary library. To the bin it went. :D
It does not seem that the author is affiliated with Canonical. Ideally, Canonical should be the ones defending their product.<p>IMO, it is okay for the backend to be propriety as long there is a published, easy to implement protocol for talking to snapd (along with an accessible way for clients to configure snapd). Otherwise, there is lock-in to the service. It's not just the FOSS community that should be concerned, but business users as well. Do you want to internally distribute in-house snaps via Canonical's servers?<p>> DockerHub and GitHub are insanely popular and they are completely proprietary.<p>These are arguments against, not for, using these services. And many proprietary SaaS companies sell installations on on-prem air gapped servers.