It’s literally a choice between what deb you want to get. One is a transitional package that installs a different package on the system (in this case the snap) as Debian transitional packages have done for decades, and the other is a third party package that provides the app rather than the transitional package. Just as when there was the ffmpeg vs. libav split, if you don’t want the transitional package to be installed and you want your third-party package from a different repository, you have to tell apt that.
Thanks for that correction then. I wasn’t conscious of that detail.
In any case, the issue remains that, if the vendor’s default repositories push for a type of package I don’t want, I either have to manually find and vet third party repositories I trust or find someone else to rely on for defaults I’m fine with.
The difference between “I want a different source for a single package, so I’ll manually select a different source for that one” and “I don’t trust Canonical to select sources I agree with anymore” is one of scale. I’m fine with manually pinning the transitional package, uninstalling it and the snap (hopefully remembering to back up my profile before realising that it also deletes user data) adding a ppa, reinstalling it and reimporting my profiles just for firefox.
But if I feel like I have to fight my distro vendor over not using their preferred package distribution system, it’s probably better to jump ship - other vendors have beautiful distros too.
(Also, “you can just use a different source” is part of the reason people prefer not to use snap, where you can’t do that)
If you’re fighting your distro vendor over the choice of packages they’re providing in their repos, then yeah, you should probably use another distro. But that’s exactly what I was saying in my original comment above. If you don’t like rpms or flatpaks, you shouldn’t be using Fedora either, since those two packaging technologies are what Fedora uses for their distribution. For me the Linux Mint developers’ hostility to snaps (which in my experience tend to be the best trade-offs for my needs) is one of the many reasons I won’t use or suggest Mint.
KDE Neon provides their own packages in their repo that add Mozilla’s apt repository for Firefox as well as setting up the preferences. In fact, here’s the file, which gets placed in /etc/apt/preferences.d/org-kde-neon-packages-mozilla-org-pin:
# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL# SPDX-FileCopyrightText: 2022 Harald Sitter <sitter@kde.org>Package:firefoxPin:releaseo=packages.mozilla.orgPin-Priority:1000Package:firefox-*Pin:releaseo=packages.mozilla.orgPin-Priority:1000Package:firefox-locale-*Pin:releaseo=packages.mozilla.orgPin-Priority:1000
The great part of KDE Neon’s approach to it is that since I do want the Firefox snap on my KDE Neon laptop, I can simply run sudo apt remove neon-repositories-mozilla-firefox firefox && sudo apt update&& sudo apt install firefox to get the snapped version of Firefox.
Also, snapd keeps a snapshot of your per-revision configuration from an app for a while after you remove it. You can run snap saved to see all the current snapshots. It doesn’t remove your $SNAP_USER_COMMON directory for that snap (which is where the Firefox snap stores its profiles), so moving from the snapped Firefox to the version from apt is just a matter of moving the .mozilla directory out of ~/snap/firefox/common to ~/
For me the Linux Mint developers’ hostility to snaps (which in my experience tend to be the best trade-offs for my needs) is one of the many reasons I won’t use or suggest Mint.
I mean, analogous to firefox example you supplied, you could just delete nosnap.pref and be on your way.
Also, snapd keeps a snapshot of your per-revision configuration from an app for a while after you remove it. You can run snap saved to see all the current snapshots. It doesn’t remove your $SNAP_USER_COMMON directory for that snap (which is where the Firefox snap stores its profiles), so moving from the snapped Firefox to the version from apt is just a matter of moving the .mozilla directory out of ~/snap/firefox/common to ~/
I could have sworn I checked that, but I was a lot less familiar with these things at the time, so maybe I missed it.
I don’t think snaps are a bad thing on principle, my own bad experiences with them notwithstanding. I could also live with a for-profit operating its own curated package repository as part of its service.
I’d personally prefer not to use a client locked into one particular package provider, but if that’s the tradeoff for that provider’s security guarantee that your packages are all Canonical-certified safe, I’d accept that. If it were preinstalled with an OS, that’s fine. If they make it the default Software Store, we’re on par with the Microsoft Store and other App Stores and those too provide a utility and convenience, particularly for those less technically minded. The ship on “don’t bundle your browser with your OS because that’s monopoly grabbing” has sailed long ago anyway.
All of these are things I’m fine with, even if I personally would choose not to use them. If that was all, I’d still recommend Ubuntu as a beginner distro, because it was my intro to Linux too and I found it good at the time.
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.
Having a transition package for a name change or breaking up a larger project into modular packages is one thing. Using it to instead run an entirely different package manager pulling from a proprietary repo?
Worse still, if you had trouble with one app so you went and found a non-snap repo, you pinned it with higher priority, reinstalled it from the new source and thought you were in the clear because that worked as expected.
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…
I get that automatic upgrades don’t pull from all repos by default for security reasons, but at least look at the priorities and realise “Ope, not gonna touch that, I’ll notify the user to do it manually if they trust the update”.
And that, for me, is the part that takes it from apathy to disdain; the part that goes beyond “each distro has its own preferences, no big deal”; the part that reeks of a profit-oriented company aiming for vendor lock-in.
To close the topic out: All of this is just explaining my stance; I’m not telling anyone what to do or not to do. You gave your point, I gave mine. By all means, if it works best for you, I’m not getting in your way. I just wish there was a better option.
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:
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.)
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.)
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!
I stuck with the ~mozillateam PPA for quite a while, regularly trying the snap and reporting bugs to Mozilla
Mad respect. I wouldn’t have had that amount of time or patience due to personal circumstances, nor the ideological drive to see it work well, but it is people like you that compensate for those of us that can’t or don’t want to contribute to that same extent. All other preferences aside, I appreciate that contribution to a better ecosystem.
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.
You’re right, that would have been the worst “solution” - none at all.
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”
Between my experiences with supporting users and corporate lingo, I don’t think so. Provide a concise, maybe slightly propagandised ad about how snap is better and more secure, then provide the users with a highlighted button “Yes, I want to continue automatic security updates” and a subdued “No, I want to maintain it myself” along with a help pop-up for a slightly more technical “What’s the difference”.
Most casual users I know that just want things to work - myself included, in some cases - will just skim it, see the appealing buzzwords, click “Yeah whatever, I don’t care”. The more technical ones would probably google it, read the ensuing arguments and recommendations, and either decide like you did to give it a shot or end up responsible for their own thing (which is both the liberty and the jeopardy of Linux in general: you can do your own thing, but if it breaks, that’s on you).
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.
I wasn’t aware of that detail (given I never cared about snap anyway, I never would have run into the issue). Paired with the unwillingness to remedy resulting problems, that is indeed a shitty move. I’d consider it on par with suddenly replacing my firefox with a version that worked very poorly*, which also caused me confusion and frustration, but unlike the firefox case, I don’t see any graceful way of handling that transition in a user friendly manner.
*It just occurred to me that some of the issues may have been exacerbated by running on an HDD as opposed to an SSD. Prior to tossing Windows entirely, my SSD held my Win7 installation, while Ubuntu got its own partition on the HDD. I never migrated it to the SSD, instead using its limited 256GB to hold whatever games I was playing at the time.
Re: Linux Mint hostility, apathy about resulting problems, misinformation, paternalism
Those are all good points.
Being hardliners about their philosophy is a common phenomenon in the Linux sphere. While I agree that it’s not particularly user-friendly (and generally value open debate), I also feel that a distributor is within their rights to do what they feel is right rather than caving to users. Conversely, that’s a philosophy I wouldn’t want to endorse either.
The charge of paternalism is one I would level at Canonical too, given the concerns I expressed about pushing towards a monolithic, corporate controlled system. Good intentions notwithstanding, I worry it may pave the path to hell. They’re more subtle about it, but that’s no more of a redeeming quality to me than MS slowly creeping in new bullshit. (I’d gladly be wrong about that, of course - even if I may not want to use it, options are a good thing.)
But misinformation is an problem and I concede that I may well have fallen prey to it myself. I did try to search for info about open source options like what you mention, but my results and interpretations may have been biased, and I didn’t spend enough time for a comprehensive understanding. I could make excuses, but that won’t change the fact of my error.
I’m just elaborating on the one thing since you didn’t seem to get why it’s a problem.
I didn’t. Thank you for taking the time.
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.
It can’t have been more than a few years ago, given that the snap move happened with 22.04 which released about 2.5y ago and I encountered that error. But I was, for all intents and purposes, a noob, so I can’t exclude the possibility of user error. I’ll take your word that this no longer happens.
nix, immutable distros / building blocks, Android comparison
I’ve never tried either nix or immutable distros. The idea of an immutable base, vetted for compatibility issues between what you refer to as the “building blocks”, seems appealing from a “I don’t want to worry about the details” perspective for casual use.
Android is convenient for another reason where I’m not sure how relevant it is to our context. It offers a unified version with a common set of features and interfaces, allowing app development relying on that version.
Exchangeable blocks can introduce complication in the same way that, for an example I’m familiar with, node package dependencies will feature a whole set of “at least this version” or occasionally “exactly this (major) version” specifications to ensure the individual parts all meet the requirements.
It’s a tradeoff between modularity and reliability, as I see it, and both have their merits. I do tend to favour modularity, which is why I do appreciate the concept of snap as I have now come to understand it. Like I said, my misgivings are with Canonical more than the technology itself.
I’ve enjoyed this conversation with you, because we’re each giving opinions and learning from each other. […] 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!
Likewise. I’m no fan of the adversarial nature of many conversations in the tech sphere either. Progress thrives on creativity, if tempered by skepticism and scrutiny. If we’re willing to share perspectives, we can catch each other’s blind spots. And if it comes down to personal opinions in the end, at least we can form those consciously and part ways a little wiser than before.
I’d be curious to hear about your other misgivings some time, but this conversation has been going on a while now and I may not have much time to read or respond the next few days. In any event, thanks for taking the time!
It’s literally a choice between what deb you want to get. One is a transitional package that installs a different package on the system (in this case the snap) as Debian transitional packages have done for decades, and the other is a third party package that provides the app rather than the transitional package. Just as when there was the ffmpeg vs. libav split, if you don’t want the transitional package to be installed and you want your third-party package from a different repository, you have to tell apt that.
Thanks for that correction then. I wasn’t conscious of that detail.
In any case, the issue remains that, if the vendor’s default repositories push for a type of package I don’t want, I either have to manually find and vet third party repositories I trust or find someone else to rely on for defaults I’m fine with.
The difference between “I want a different source for a single package, so I’ll manually select a different source for that one” and “I don’t trust Canonical to select sources I agree with anymore” is one of scale. I’m fine with manually pinning the transitional package, uninstalling it and the snap (hopefully remembering to back up my profile before realising that it also deletes user data) adding a ppa, reinstalling it and reimporting my profiles just for firefox.
But if I feel like I have to fight my distro vendor over not using their preferred package distribution system, it’s probably better to jump ship - other vendors have beautiful distros too.
(Also, “you can just use a different source” is part of the reason people prefer not to use snap, where you can’t do that)
If you’re fighting your distro vendor over the choice of packages they’re providing in their repos, then yeah, you should probably use another distro. But that’s exactly what I was saying in my original comment above. If you don’t like rpms or flatpaks, you shouldn’t be using Fedora either, since those two packaging technologies are what Fedora uses for their distribution. For me the Linux Mint developers’ hostility to snaps (which in my experience tend to be the best trade-offs for my needs) is one of the many reasons I won’t use or suggest Mint.
KDE Neon provides their own packages in their repo that add Mozilla’s apt repository for Firefox as well as setting up the preferences. In fact, here’s the file, which gets placed in
/etc/apt/preferences.d/org-kde-neon-packages-mozilla-org-pin:# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL # SPDX-FileCopyrightText: 2022 Harald Sitter <sitter@kde.org> Package: firefox Pin: release o=packages.mozilla.org Pin-Priority: 1000 Package: firefox-* Pin: release o=packages.mozilla.org Pin-Priority: 1000 Package: firefox-locale-* Pin: release o=packages.mozilla.org Pin-Priority: 1000The great part of KDE Neon’s approach to it is that since I do want the Firefox snap on my KDE Neon laptop, I can simply run
sudo apt remove neon-repositories-mozilla-firefox firefox && sudo apt update && sudo apt install firefoxto get the snapped version of Firefox.Also, snapd keeps a snapshot of your per-revision configuration from an app for a while after you
removeit. You can runsnap savedto see all the current snapshots. It doesn’t remove your$SNAP_USER_COMMONdirectory for that snap (which is where the Firefox snap stores its profiles), so moving from the snapped Firefox to the version from apt is just a matter of moving the.mozilladirectory out of~/snap/firefox/commonto~/I mean, analogous to firefox example you supplied, you could just delete nosnap.pref and be on your way.
I could have sworn I checked that, but I was a lot less familiar with these things at the time, so maybe I missed it.
I don’t think snaps are a bad thing on principle, my own bad experiences with them notwithstanding. I could also live with a for-profit operating its own curated package repository as part of its service. I’d personally prefer not to use a client locked into one particular package provider, but if that’s the tradeoff for that provider’s security guarantee that your packages are all Canonical-certified safe, I’d accept that. If it were preinstalled with an OS, that’s fine. If they make it the default Software Store, we’re on par with the Microsoft Store and other App Stores and those too provide a utility and convenience, particularly for those less technically minded. The ship on “don’t bundle your browser with your OS because that’s monopoly grabbing” has sailed long ago anyway.
All of these are things I’m fine with, even if I personally would choose not to use them. If that was all, I’d still recommend Ubuntu as a beginner distro, because it was my intro to Linux too and I found it good at the time.
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.
Having a transition package for a name change or breaking up a larger project into modular packages is one thing. Using it to instead run an entirely different package manager pulling from a proprietary repo?
Worse still, if you had trouble with one app so you went and found a non-snap repo, you pinned it with higher priority, reinstalled it from the new source and thought you were in the clear because that worked as expected.
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…
I get that automatic upgrades don’t pull from all repos by default for security reasons, but at least look at the priorities and realise “Ope, not gonna touch that, I’ll notify the user to do it manually if they trust the update”.
And that, for me, is the part that takes it from apathy to disdain; the part that goes beyond “each distro has its own preferences, no big deal”; the part that reeks of a profit-oriented company aiming for vendor lock-in.
To close the topic out: All of this is just explaining my stance; I’m not telling anyone what to do or not to do. You gave your point, I gave mine. By all means, if it works best for you, I’m not getting in your way. I just wish there was a better option.
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-Priorityof 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.)
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.
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-upgradessettings 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.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:
snap refresh --amend.)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.
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!
Mad respect. I wouldn’t have had that amount of time or patience due to personal circumstances, nor the ideological drive to see it work well, but it is people like you that compensate for those of us that can’t or don’t want to contribute to that same extent. All other preferences aside, I appreciate that contribution to a better ecosystem.
You’re right, that would have been the worst “solution” - none at all.
Between my experiences with supporting users and corporate lingo, I don’t think so. Provide a concise, maybe slightly propagandised ad about how snap is better and more secure, then provide the users with a highlighted button “Yes, I want to continue automatic security updates” and a subdued “No, I want to maintain it myself” along with a help pop-up for a slightly more technical “What’s the difference”.
Most casual users I know that just want things to work - myself included, in some cases - will just skim it, see the appealing buzzwords, click “Yeah whatever, I don’t care”. The more technical ones would probably google it, read the ensuing arguments and recommendations, and either decide like you did to give it a shot or end up responsible for their own thing (which is both the liberty and the jeopardy of Linux in general: you can do your own thing, but if it breaks, that’s on you).
I wasn’t aware of that detail (given I never cared about snap anyway, I never would have run into the issue). Paired with the unwillingness to remedy resulting problems, that is indeed a shitty move. I’d consider it on par with suddenly replacing my firefox with a version that worked very poorly*, which also caused me confusion and frustration, but unlike the firefox case, I don’t see any graceful way of handling that transition in a user friendly manner.
*It just occurred to me that some of the issues may have been exacerbated by running on an HDD as opposed to an SSD. Prior to tossing Windows entirely, my SSD held my Win7 installation, while Ubuntu got its own partition on the HDD. I never migrated it to the SSD, instead using its limited 256GB to hold whatever games I was playing at the time.
Those are all good points.
Being hardliners about their philosophy is a common phenomenon in the Linux sphere. While I agree that it’s not particularly user-friendly (and generally value open debate), I also feel that a distributor is within their rights to do what they feel is right rather than caving to users. Conversely, that’s a philosophy I wouldn’t want to endorse either.
The charge of paternalism is one I would level at Canonical too, given the concerns I expressed about pushing towards a monolithic, corporate controlled system. Good intentions notwithstanding, I worry it may pave the path to hell. They’re more subtle about it, but that’s no more of a redeeming quality to me than MS slowly creeping in new bullshit. (I’d gladly be wrong about that, of course - even if I may not want to use it, options are a good thing.)
But misinformation is an problem and I concede that I may well have fallen prey to it myself. I did try to search for info about open source options like what you mention, but my results and interpretations may have been biased, and I didn’t spend enough time for a comprehensive understanding. I could make excuses, but that won’t change the fact of my error.
I didn’t. Thank you for taking the time.
It can’t have been more than a few years ago, given that the snap move happened with 22.04 which released about 2.5y ago and I encountered that error. But I was, for all intents and purposes, a noob, so I can’t exclude the possibility of user error. I’ll take your word that this no longer happens.
I’ve never tried either nix or immutable distros. The idea of an immutable base, vetted for compatibility issues between what you refer to as the “building blocks”, seems appealing from a “I don’t want to worry about the details” perspective for casual use.
Android is convenient for another reason where I’m not sure how relevant it is to our context. It offers a unified version with a common set of features and interfaces, allowing app development relying on that version.
Exchangeable blocks can introduce complication in the same way that, for an example I’m familiar with, node package dependencies will feature a whole set of “at least this version” or occasionally “exactly this (major) version” specifications to ensure the individual parts all meet the requirements.
It’s a tradeoff between modularity and reliability, as I see it, and both have their merits. I do tend to favour modularity, which is why I do appreciate the concept of snap as I have now come to understand it. Like I said, my misgivings are with Canonical more than the technology itself.
Likewise. I’m no fan of the adversarial nature of many conversations in the tech sphere either. Progress thrives on creativity, if tempered by skepticism and scrutiny. If we’re willing to share perspectives, we can catch each other’s blind spots. And if it comes down to personal opinions in the end, at least we can form those consciously and part ways a little wiser than before.
I’d be curious to hear about your other misgivings some time, but this conversation has been going on a while now and I may not have much time to read or respond the next few days. In any event, thanks for taking the time!