Why Mint’s blocking of ‘snapd’ is absurd

Before writing this, let me preface this by saying this isn’t meant to devalue the great work Linux Mint has done to make it the ‘beginner friendly’ Linux it has become, up to Linux Mint 19.3 anyway.

That being said, I’ve kept a keen eye on Linux Mint 20 as of recently, both because I was curious on how they’d handle the chromium-browser package, and also because I have always been curious on the direction of Linux Mint ever since Feren OS’s, and Feren OS Classic’s, nearly 5 year lifetime (at the time of writing this article).

Therefore, I’ve seen and looked into the recent… decisions… the Linux Mint team has made regarding packages in Linux Mint 20 as they happen. This post is here to corrugate my thoughts on the current situation.

The 2019 Blog Post

Let’s just first of all get the Blog Post from 2019 out of the way. In this blog post Clem went over in a section of the post his thoughts on SnapD at that current point in time, especially with regards to the Deb-to-Snap transition Canonical has been doing as of 2019 to Ubuntu. I don’t remember exactly why, but I do remember feeling disappointed when reading that blog post.

Either way, it was definitely foreshadowing for what was to be announced this year by Linux Mint, however the extent to which they acted upon this was nowhere near expectations.

The Chromium Elephant in the room

As for the elephant in the room, chromium-browser in Ubuntu 20.04, and Linux Mint 20, let’s just get this out of the way.

For the uninformed, chromium-browser in Ubuntu 20.04 is a transitional dummy package, a package designed for the sole purpose of transitioning users to the Chromium Snap package, in case an APT package depends on Chromium for functionality. Clem made it clear in the aforementioned 2019 blog post that he was strongly against this idea, and that has not changed in the very slightest since then.

Obviously, as Mint has announced, they replaced the chromium-browser package with their own replacement package. Ironically I actually discovered that a few days before the announcement as I checked the Mint repositories, hosted at packages.linuxmint.com, looked in Mint 20’s codename of Ulyana and through a quick CTRL+F found a replacement chromium-browser package sitting there with Mint’s generic package versioning scheme.

To put it simply, all the package Mint provides is is the generic package changelog files and so on that every natural DEB package is likely to come with nowadays, but apart from that this package is literally empty.

Furthermore, the description of the package leads users towards the official download page for Chromium, which leads to downloadable scripts and Terminal commands to locally download a copy of Chromium that does not update itself in the standard manner (thankfully the scripts they recommend comes with an update script which serves the purpose of updating Chromium when the script’s launched).

Explanation aside, I’m not against this decision at all. I can understand why they did this. However, I do have one tiny qualm with how they handled the announcement about this and Snap-blocking…

Mint’s Snap response’s over-exaggeration

*sigh* I really wish I didn’t have to mention this kind of stuff being done by a famous distribution, but Linux Mint has made that happen, so…

There’s two things I’d like to point out here with regards to their 2020 Blog Post. Two quotes that really make Linux Mint sound immature.

  • “the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store”

Don’t get me started on how absurd their claim about Chromium’s post-deb-to-snap-transition package being a backdoor is. I get it’s running ‘snap install’ as Superuser, the highest privileged user (as far as I know) in a Linux system, but if this were a backdoor as they claimed way more people would be complaining right now as they investigate just what that process really does to your machine. Backdoors are programs that run code that can be malicious at superuser-level, for example from people who want nothing but your personal data, and so on.

Now, you’re basically comparing a (mostly) open source project made by a mostly trustable vendor which has taken strides to make take Linux to the levels of popularity it has today, to those people, seriously? That’s like if I compared Linux Mint 20.0 (so far) to Windows 10 in S Mode because they vendor lock their users out of an application ecosystem that is otherwise available to their users when restrictions are removed.

As for SnapD being installed behind your back… what a load of bull that is. You see in the dependencies that ‘snapd’ will be installed if you look at the package changes (or dependency list in GDEBi) presented to you on screen (unless ‘snapd’ is already installed on the system anyway). Not only that but the package version also has ‘snap’ in the version string, and the package’s description literally says it’s transitioned to the Snap of Chromium, which are both shown to the user in Mint’s Software Manager, GDEBi, and so on.

The ugly truth about blindly supporting this decision

Finally, let me end this write-up by stating an ugly truth to those blindly supporting Mint’s decision to block SnapD installs in Linux Mint 20 and later.

For the uninformed, Linux Mint 20 and later will not permit the installation of ‘snapd’ via APT by default. Upon my own recent further investigation, this is because Linux Mint has introduced an APT config file in /etc/apt/preferences.d/nosnap.pref (package providing this file: ‘ubuntu-system-adjustments’) that makes APT unable to find any packages named ‘snapd’ irregardless of if they exist or not unless workarounds are used.

A certain someone mentioned that maybe Linux Mint was blocking SnapD via a ‘config file’, so during my sleep after that I came to the realisation that if they have, there are two places that it is most likely to be at: ‘mintsystem’ or ‘ubuntu-system-adjustments’, and lo and behold that was indeed the case.

In other words, Linux Mint is trying to prevent vendor locking in of users into the Snap ecosystem by creating their own vendor locking that vendor locks users out of Snap’s ecosystem irregardless of their own will, unless they know to delete the aforementioned config file from their system to restore functionality that quite frankly should have never been taken from the user to begin with (the ability to make their own decisions about installing SnapD if they want to).

You know what makes this worse, though? Take Chromium out of the equation for a minute, here, and just look at how much freedom for common package types you get with Ubuntu 20.04 LTS vs Linux Mint 20.0 (in its current pre-Beta form at the time of writing):

  • Ubuntu 20.04 LTS: APT (including DEBs), AppImage, Flatpak (installable), SnapD

NOTE: The reason I didn’t specify that APT packages are not available for Snap-transitioned packages (aka Chromium) is because Linux Mint has equal amounts of package unavailability to Ubuntu in that respect since Linux Mint makes those packages entirely empty instead of ‘resurrecting’ them.

Noticed how Linux Mint 20.0, the distribution known to have ‘freedom’ in its slogan, is providing users with less options than Ubuntu for where to get their applications from?

Overall Linux Mint is actually restricting users more than Ubuntu in this regard by vendor locking their users out of Snap by default. Ubuntu lets you use Flatpak if you want to use it, so why can’t Mint just do the same with the Snaps support package ‘snapd’, eh?

If the reason Mint is so against Snaps is because Canonical has control over their repositories, then answer this:

Why are they depending on an APT repository that is completely controlled by Canonical for their own distribution? Why not just move over to Linux Mint Debian Edition if you are worried about Canonical’s control over packages?

Canonical could quite literally with the snap (heh.) of their finger push a package update to a random package Linux Mint hasn’t overridden yet to cause major turmoil for Linux Mint and its users at any point if they so desired.

Please, Mint fans, consider those facts, among the rest of the facts, when you defend Mint’s decision here to block SnapD for their own users by default. Don’t be those people who have double-standards because of what they read the people, in the team they’re part of the fandom of, saying, please.

Some last closing words

Before I do finish this write-up, let me be clear on this: I’m no Snap supporter, either. I’m mostly neutral on that stance currently, but I’m not afraid to call big distributions out when their actions are inhibiting their users’ freedom to choose where they get their software. I’d call out Ubuntu any day, even, if they ever blocked Flatpak installs by default in Ubuntu, because that is vendor lock out.

Before I do go, let me shout out some other distributions that also give you the freedom to choose between native/standard packages, AppImages, Flatpaks and Snaps if you want to install or enable support for them:

Ubuntu and Ubuntu-based

I mean, while Ubuntu is currently SnapD-centric, it still provides users with the option to use native APT packages, AppImages, Snaps, and also if the user installs support for it, via an APT package in the default Ubuntu package repositories, Flatpaks.

Manjaro

One thing I will give Manjaro credit for is the fact they allow their users, via Pamac, to easily turn on and off searching for Snaps and Flatpaks alongside standard Arch Linux packages with a flick of a few switches in the settings panel of Pamac itself at any time.

Feren OS and distributions which also take Feren OS’s approach

You know that I could not at least mention Feren OS’s stance on this topic, right? Anyway, Feren OS inherits supporting Flatpaks by default from its Mint-based lifetime, however it also supports AppImages, and native APT packages, and it even supports Snap in a user-friendly manner if the user goes into Welcome Screen -> Install Software -> Snap Apps and installs Snaps support from there, with the Snap Store being installed via that installation process for those users to give those users easier access to Snap’s ecosystem.

A final message to Linux Mint

Linux Mint’s team, if you’re somehow seeing this, please… just do the right thing by Mint 20.0 Stable and onwards. You did everything else in a fair and justified way here, except for this change and some of the word usage. Don’t make your users suffer just because you don’t like SnapD that much.

You’re needlessly indirectly provoking hate against SnapD, a project people are spending their time and effort working on, with that kind of wording to describe all of SnapD. I understand that you really don’t like SnapD, but still you don’t have to go that far about your dislike for that package ecosystem.

If you want to reduce the risks of SnapD ever becoming successful enough to result in vendor lock-in, this is not the way to go about it.

Sources referred to here:

2019 Blog Post: https://blog.linuxmint.com/?p=3766

2020 Blog Post: https://blog.linuxmint.com/?p=3906

I was thinking of maybe covering how awkward this whole chromium-browser situation is in a future post, to explain why the way Canonical handled this whole ordeal is justified and potentially one of the best ways they could have handled the transition from APT to Snap without risking the stability of what works just so that the transition is more transparent to users, so if people want me to make that a reality gauge your support for this kind of posting with claps I guess.