Monthly News - June 2019
July 2, 2019 By CLEM
http://blog.linuxmint.com/?p=3766

Snap

When snap was announced it was supposed to be a solution, not a problem. It
was supposed to make it possible to run newer apps on top of older libraries and to let 3rd party editors publish their software easily towards multiple distributions, just like Flatpak and AppImage. What we didn't want it to be
was for Canonical to control the distribution of software between
distributions and 3rd party editors, to prevent direct distribution from editors, to make it so software worked better in Ubuntu than anywhere else
and to make its store a requirement.

If you're a Fedora user and you want to install Spotify, you're told to go to https://snapcraft.io/spotify. Spotify doesn't distribute RPM packages, appimage, Flatpak or anything useful to a Fedora user who wants to download
it, or to a Fedora maintainer who wants to add it to a repository. Fedora
users are told to go to what is essentially a commercial store operated by a RedHat competitor where stats tell them their distribution is
only 7th best.

We're in luck, we can still download the .deb. If Spotify stops caring, what
do we do? We move to snap because we have to? Will the snap store continue to let people download actual .snap files in the future or will that get locked down ? Will the snap store continue to operate without an Ubuntu One account
or will we get vendor-locked ? I think it's important to appreciate these aspects.

We all have smartphones, and we all know how great the Google Play store is. How often do we see .apk (Android packages) on the web ? How hard are they to install without the Google store ? How free is an editor to publish its .apk itself while being present in the store ? Who controls all that and what does it mean for us ? Who governs what can and cannot go into the store ? Who
makes commercial deals ? Who do we rely on ? And why ?

As long as snap is a solution to a problem, it's great. Just like Flatpak, it can solve some of the real issues we have with frozen package bases. It can provide us with software we couldn't otherwise run as packages. When it starts replacing packages for no good reason though, when it starts harming our interaction with upstream projects and software vendors and reducing our choice, it becomes a threat.

A Fedora user shouldn't be told about Ubuntu and Ubuntu One when downloading software. His browser shouldn't have bookmarks pointing to another distribution. His software shouldn't be designed and tested primarily with another desktop environment and distribution in mind, and when he looks at screenshots he shouldn't see Ubuntu everywhere. It's wrong for Spotify to do that and it's wrong for any vendor to think that such a store can be the only store for all Linux users. For this to work it would need to be governed by us all, with clear goals, without bias and without conflict of interest.

When Flatpak came out it immediately allowed anyone to create stores. The Flatpak client can talk to multiple stores. Spotify is on Flathub and they
can push towards it. If tomorrow they have an argument with Flathub they can create their own store and the very same Flatpak client will still work with it. When Snap came out, it was only a client. The server was behind closed doors and the client couldn't talk to multiple servers. We've been worried about this since then, but it was OK. As long as Snap didn't become the de-facto standard for all editors to publish to all users of Linux, it was
OK. As long as editors didn't stop distributing packages, it was OK. As long
as Snap didn't remove what we already had, it was perfectly OK. The Ubuntu Store, which is now called the Snap Store (which makes sense since there can only be "one" store, by design), was promising because it could provide software we didn't have access to, and a payment platform to purchase commercial software. It's doing much more than that though, it could reduce access to free (as in beer) software and free (as in freedom) software.

There are a lot of things you can do with package managers (apt/dpkg in Linux Mint), that you can't do with Snap, and there are two reasons for this. First, they've been around for a while. They're mature, they're integrated fully within the OS in every distributions. Second, they've been developed with Free Software in mind. There are no commercial aspects in the design of apt/dpkg, it's all about empowering users and distributions. You can't modify, rebuild, pin, patch, mirror a snap, you're not supposed to.

I've been invited to participate by the Snap developers and I'm hoping one day we'll be able to integrate snap into Linux Mint. Although I'm worried about
the impact on the market, I think snap could work both as a client and a file format, if it didn't lock us into a single store. You might wonder why I'm so outspoken about this all of a sudden. There's a certain sense of urgency which demands action on our side. Ubuntu is planning to replace the Chromium repository package with an empty package which installs the Chromium snap. In other words, as you install APT updates, Snap becomes a requirement for you to continue to use Chromium and installs itself behind your back. This breaks one of the major worries many people had when Snap was announced and a promise from its developers that it would never replace APT.

The plan isn't just to delegate part of APT with Snap in the current Ubuntu releases, but also to backport this change towards Ubuntu 18.04 LTS. We don't want this to affect Linux Mint.

I don't think the points we're raising here are well understood by the community. I hope we'll talk with Ubuntu and the Snap project about this.
We're very interested in your feedback as well. A self-installing Snap Store which overwrites part of our APT package base is a complete NO NO. It's something we have to stop and it could mean the end of Chromium updates and access to the snap store in Linux Mint.


---

|03B|09lack |03P|09anther|03(|09RCS|03)|07

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Castle Rock BBS - bbs.castlerockbbs.com - (77:1/102)