I mean, analogous to firefox example you supplied, you could just delete nosnap.pref and be on your way.

Except equivocating those hides the ideological differences.

In the Ubuntu case, the apt package is simply a transitional package. It’s the same as the ffmpeg/libav case I mentioned before. They did the user-friendly thing of providing a replacement with equivalent functionality. (Yes, I’m aware of the bugginess of the early Firefox snap - I stuck with the ~mozillateam PPA for quite a while, regularly trying the snap and reporting bugs to Mozilla.) The alternative (not providing a Firefox deb in their repos any more, resulting in users with the firefox deb suddenly being abandoned) is a whole lot worse.

KDE Neon’s decision is at a similar level. They provide a package with equivalent functionality and set preferences to use that package.

But the Linux Mint decision is far more hostile. On the technical side, it’s a matter of “we’re blocking this package and providing no equivalent,” which is already a pretty hostile thing to do. Not only does it not provide an alternative, but if the user chooses to manually install snapd, it removes it. A Pin-Priority of 1 would have been the “correct” way to do it IMO, as that blocks automatic installation as a dependency, but still allows automatic upgrades if the user manually installs the package. But instead, Linux Mint took a hostile approach of choosing a negative number, which actually tells apt to remove the package even if the user has manually installed it. This is overriding user choice in a way that neither Ubuntu nor KDE Neon did.

On top of this, this Linux Mint decision came with an anti-snap screed that showed a major lack of understanding of both the technological and user friendliness problems that Ubuntu was working with. That hostility, combined with their hostility towards people who faced issues from this change (including a bunch of their apps suddenly disappearing and them not knowing why), made it clear to me that the Linux Mint team were not acting in good faith. Had they taken the negative feedback they got in response and softened their position, I would be more willing to give them the benefit of the doubt that they recognised their overreaction. Instead though, for several years now they’ve had a highly political document that is not only misleading, but also contains flat-out misinformation, on their own documentation site. Their continuing to double down on this shows a hostility and paternalism towards their userbase that is Apple-esque.

(I have many other issues with how Linux Mint does things too, as I said above. I’m just elaborating on the one thing since you didn’t seem to get why it’s a problem.)

The thing that irks me is when they’re being dishonest about it. You no longer wanna support a deb package in your repos? Fine, let me know, offer me a one-click migration option for installing the snap instead and moving my data over, give me the whole marketing routine of telling me how much better your new solution is, but make it my choice.

They literally moved over from one Mozilla-owned package (yes, part of their trademark deal with Mozilla that allowed them to use the Firefox logo and everything all those years ago was that Mozilla would get to own the package) to another Mozilla-owned package. What you’re suggesting is, IMO, a move that simply confuses new users. “Firefox updates automatically. Why is it suddenly asking if this update is okay? clicks no, has an unmaintained Firefox” This would have got them as much or more criticism, and IMO they would have deserved it in that case. And yet, it would still have been friendlier than what Linux Mint does, which is to automatically remove snapd even after the user has manually installed it.

But you forgot or didn’t know to also put a negative priority on the snap source because pin priorities seem intuitive enough, only for unattended upgrades to look at the pins and say “That sign can’t stop me, because I can’t read” (pins from repos I don’t know) and reinstall the snap…

That’s not how unattended upgrades work in apt though (well, unless you specifically configure it that way I guess, but Ubuntu’s OOTB unattended-upgrades settings don’t do that). There were bugs about a decade ago about unattended upgrades not obeying pins correctly, but those were bugs and, AFAIK, have long since been resolved.

And that, for me, is the part that takes it from apathy to disdain

The part that takes me from apathy to disdain about people’s hate for snap is that so much of it is based on actual misinformation, and that people do use this misinformation to tell people not to use a system that:

1. Is as open as any other from a client perspective. (Anyone can use Canonical’s open snap store API documentation to build their own snap store or, if they don’t like that API, sign and distribute snaps through any other mechanism they choose by placing the snap and its related assertion in a download directory together and telling snapd to install that file. In fact, the latter even allows you to provide your own snap distribution mechanism that supersedes Canonical’s snap store, since it won’t upgrade that snap to one from snapcraft.io without the user manually using snap refresh --amend.)
2. Provides functionality that their suggested replacements simply do not. (e.g. flatpak - much of the functionality in snap is out of scope for flatpak. That’s fine and not a problem any more than flatpak not being able to replace apt or dnf is a problem. The issue is when people treat it as equivalent.)
3. Hasn’t had specific bugs they point to about it for the better part of a decade now (and those bugs were recognised as bugs, not treated as “you’re holding it wrong”).

A far more reasonable comparison to snap is actually nix. They do it in slightly different ways (and each has its own advantages and disadvantages), but they’re far more similar to each other than snap is to flatpak (with nixos being the Ubuntu Core equivalent in this analogy). Flatpak and the immutable systems that use it (e.g. SteamOS, Fedora Silverblue) is far more similar to how Chrome OS or modern Android work - an immutable base with a locked down user area where apps can be installed (and Flatpak only handles the user area part of it). Nix and Snap (and by extension NixOS and Ubuntu Core) provide what I’d call an “immutable building blocks” system. Rather than a single immutable base, each part of the system is its own immutable lego block. Need a different kernel version? Great, you can replace your kernel package without replacing the whole immutable base. Why? Because the kernel package is just like any other package, but all the packages are immutable.

All of this is just explaining my stance; I’m not telling anyone what to do or not to do.

I’ve enjoyed this conversation with you, because we’re each giving opinions and learning from each other. To me you come across as a good-faith contributor who has issues with snap, and where we disagree I can and do understand and empathise with your point (e.g. the closed snap store), even if I disagree with it. It was, to be entirely honest, entirely different from the type of conversation I was expecting coming into this thread, which began as yet another piling on and telling people not to use snaps specifically because of factoids that are misinformation. Thanks for the very good conversation instead!