There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

lengau

@[email protected]

This profile is from a federated server and may be incomplete. Browse more on the original instance.

lengau ,

Man I’m so glad I love my job.

lengau ,

Art isn’t open source, right?

lengau ,

I’m sure I’ll get shouted down for this suggestion by the haters, but I’m going to make it anyway because it’s actually really good:

Use an Ubuntu LTS flavour like Kubuntu. Then, add flatpak and for apps you want to keep up to date, install either the flatpak or the snap, depending on the particular app. In my personal experience, sometimes the flatpak is better and sometimes the snap is better. (I would add Nix to the mix, but I wouldn’t call it particularly easy for beginners.)

This gets you:

  1. A reliable Debian-like base that you only have to upgrade to new releases every 2 years
  2. Up-to-date apps, including confinement for those apps
  3. New kernels every 6 months (if you choose - you don’t have to, though)
lengau ,

Oh I think we all know why…

lengau ,

Yeah, Arch isn’t exactly an easy install for beginners.

lengau ,

This is why we should be ranching echidnas.

lengau OP ,

Isn’t that kinda the same with, for example, Fedora and Flatpaks? Or Debian and debs? Or Ubuntu and debs? Or Fedora and rpms?

The packaging system that your distro provides gets you the packages you get. For a small number of packages that were a maintenance nightmare, Ubuntu provides a transitional debs to move people over to the snaps (e.g. Firefox, Thunderbird), but if you want to get it from another repo, you can do exactly what KDE Neon does by setting your preferences.

lengau OP ,

I don’t understand how a transitional package that installs the snap (which is documented in the package description) is any different from a transitional package that replaces, say, ffmpeg with libav.


<span style="color:#323232;">$ apt show firefox
</span><span style="color:#323232;">Package: firefox
</span><span style="color:#323232;">Version: 1:1snap1-0ubuntu5
</span><span style="color:#323232;">Priority: optional
</span><span style="color:#323232;">Section: web
</span><span style="color:#323232;">Origin: Ubuntu
</span><span style="color:#323232;">Maintainer: Ubuntu Mozilla Team <[email protected]>
</span><span style="color:#323232;">Bugs: https://bugs.launchpad.net/ubuntu/+filebug
</span><span style="color:#323232;">Installed-Size: 124 kB
</span><span style="color:#323232;">Provides: gnome-www-browser, iceweasel, www-browser, x-www-browser
</span><span style="color:#323232;">Pre-Depends: debconf, snapd (>= 2.54)
</span><span style="color:#323232;">Depends: debconf (>= 0.5) | debconf-2.0
</span><span style="color:#323232;">Breaks: firefox-dbg (<< 1:1snap1), firefox-dev (<< 1:1snap1), firefox-geckodriver (<< 1:1snap1), firefox-mozsymbols (<< 1:1snap1)
</span><span style="color:#323232;">Replaces: firefox-dbg (<< 1:1snap1), firefox-dev (<< 1:1snap1), firefox-geckodriver (<< 1:1snap1), firefox-mozsymbols (<< 1:1snap1)
</span><span style="color:#323232;">Task: ubuntu-desktop-minimal, ubuntu-desktop, kubuntu-desktop, kubuntu-full, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop, ubuntukylin-desktop, ubuntukylin-desktop, ubuntukylin-desktop-minimal, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop-minimal, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi, ubuntu-unity-live, edubuntu-desktop-gnome-minimal, edubuntu-desktop-gnome, edubuntu-desktop-gnome-raspi, ubuntucinnamon-desktop-minimal, ubuntucinnamon-desktop
</span><span style="color:#323232;">Download-Size: 77.3 kB
</span><span style="color:#323232;">APT-Manual-Installed: no
</span><span style="color:#323232;">APT-Sources: http://us.archive.ubuntu.com/ubuntu noble/main amd64 Packages
</span><span style="color:#323232;">Description: Transitional package - firefox -> firefox snap
</span><span style="color:#323232;"> This is a transitional dummy package. It can safely be removed.
</span><span style="color:#323232;"> .
</span><span style="color:#323232;"> firefox is now replaced by the firefox snap.
</span>
lengau OP ,

They’re not forced to do so. You can install snaps locally (or provide a distribution system that treats snapd much the way apt treats dpkg), or you can point snapd at a different store. The snap store API is open and documented, and for a while there was even a separate snap store project. It seems to have died out because despite people’s contention about Canonical’s snap store, they didn’t actually actually want to run their own snap stores.

lengau OP ,

These are two incredibly persistent pieces of misinformation…

  1. Canonical provides snaps for Ubuntu. This is no more “forcing” you to use snaps than they force you to use debs, or than Fedora forces you to use flatpaks/rpms.
  2. Apt doesn’t “prefer snaps” by any means. Canonical provides transitional packages for certain packages that got migrated from debs to snaps, but the steps for using another apt repository to replace one of these transitional packages are the same as the steps for replacing any other package provided in your base repos with one from a different repository: You add the other repository, and you tell apt to prefer that repository for the specific packages.
lengau OP ,

While Canonical’s particular snap store implementation is closed source, all of the client software as well as the store API are open, and snap isn’t even tied to using snaps from their store. One could easily make a client app that treats snapd much the way apt treats dpkg. (In fact given apt-rpm I think it would probably be feasible to quite literally use apt for that.)

KDE seems to upload their packages to the snap store for Neon, judging from their page.

KDE also maintains most of the flathub.org packages for KDE apps. Not sure what the point is here.

canonical are not the ones doing the maintenance for those apt packages. the debian team does that.

This is wrong in two ways. First, Canonical are the primary employers of a lot of Debian developers, including to do Debian maintenance or development. This includes at least one of the primary developers of apt. Canonical also upstreams a lot of their work to Debian. Second, of the three (!) whole packages that Canonical decided to make transitional packages to the snap, none were coming from upstream Debian. Firefox was being packaged by Mozilla (and Mozilla were the ones who decided to move it to the snap), Thunderbird’s package had been something Canonical was packaging themselves due to the Debian/Mozilla trademark dispute that they never moved back to syncing from Debian due to technical issues with the port, and Chromium was, at least at the time, remaining frozen at old versions in a way that was unacceptable to Ubuntu users.

lengau OP ,

Because people who just want their daily Two Minutes’ Hate rather than actually having nuanced takes.

lengau OP ,

Canonical provides transitional packages for packages that they’ve decided to provide as snaps. They’re not forcing anyone to use snaps, they’re saying “if you want the default we provide you, we’re providing you with a snap.” KDE Neon (my current distro, which is downstream of Ubuntu) has decided that they want to use the deb packages from packages.mozilla.org, so they provide an override. If you want to use the deb from packages.mozilla.org, you could grab KDE Neon’s repository deb and install that, or just set up the mozilla repository and use the same pin file they already have.

This is like saying “Debian FORCES you to use libav” Debian moved from ffmpeg to libav for a while. No, they provided libav and made transitional packages for this drop-in replacement. Some people didn’t like that and made their own ffmpeg repos, and the process for using their separate ffmpeg rather than Debian’s transitional packages was the same as the process for using Firefox from a different repository. (I was one of the people used some third-party ffmpeg repositories, and I was glad when they switched back to ffmpeg and provided libav to ffmpeg transitional packages.)

Does the fact that the Ubuntu repositories don’t contain Keysmith mean “Ubuntu PROHIBITS you from using Keysmith?”

lengau OP ,

Uhm… and why does the user have to transition to snaps?

They don’t. But Canonical will no longer be providing debs in primary Ubuntu repositories, so those transitional packages exist so that users don’t wind up with an abandoned, old version of Firefox.

Why does Canonical provide those transitional packages while there are perfectly valid debs for the same thing?

For the same reason neither Ubuntu nor Debian provide debs for Google Chrome, despite Google having an official apt repository? Those debs exist in somebody else’s apt repository. If you want to add that apt repository, you’re welcome to. But those external packages aren’t part of the system they provide.

you instantly refute yourself, kudos!

Your unwillingness to accept what I’m saying doesn’t make what I’m saying contradictory.

lengau OP ,

sure, and convince people to switch. it’s been done before of course but it’s a big effort

I agree! But this, IMO, is a better argument for how flathub.org being (theoretically) open source doesn’t actually make it any better than snapcraft.io. The technical hurdle, either of writing another snap store or of setting up a flatpak host, pales in comparison to the social hurdle of getting people to switch. Which is likely why the previous open snap store implementation died. Nobody wanted to host their own and convince people to switch, because at the end of the day there wasn’t any benefit.

that does not mean that the particular developer agrees with or even approves of the snap thing.

Never said it did, although in the particular case of the developer I mentioned, he’s also an Ubuntu Core developer, which depends entirely on snaps. I can’t imagine he’d have put himself in that position if he were particularly anti-snap

steam was a big one that a friend had trouble with, and they just installed that though apt i’m pretty sure.

Ubuntu has never had a steam package in their apt repos, and the steam-installer package still behaves the same way as ever. Personally, I do use the Steam snap and haven’t had any issues with it, though I do know that others have.

lengau OP ,

I don’t believe Flatpak has the ability to package something like node. It certainly can’t package kernels system services (at least not without leaving the user with a ton of manual work to do that would make it not much better than getting a tarball).

lengau OP ,

If I were giving you €50/month, and then one day I decided to give you USD$55 instead, am I “forcing” you to accept US currency? No, I’m choosing to give you something I don’t have to give you in the first place in a different form. You can always reject my offer. You can ask someone else to give you €50/month.

They’re choosing how they want to provide Firefox. If anyone else wants to provide Firefox differently, Canonical isn’t stopping them. In fact, Canonical literally hosts and does the builds for an unofficial Firefox repo with their free Launchpad service.

Distributions decide what they want to package and how to package it all the time. Pretty much every time, someone is upset. But that upset is generally based on an unreasonable sense of entitlement.

lengau OP ,

If you don’t want to explain, you’re perfectly welcome to not explain. But saying what amounts to “if you don’t know I’m not telling you”, especially when you weren’t specifically asked, is a pretty unkind addition to the conversation.

lengau OP ,

In both cases, the packages are owned by the same people? (Fun fact: mozilla actually owns both the Firefox snap and the firefox package in the Ubuntu repos.) I’m non sure how that “potentially introduces vulnerabilities” any more than “having a package which has dependencies” does.

I’m not sure what you’re referring to with Docker. Canonical provides both the docker.io package in apt and the docker snap. Personally I use the snap on my machine because I need to be able to easily switch versions for my development work.

lengau OP ,

Yes, you are literally forcing me to accept your dollarinos, which, unless I exchange them MYSELF, are USELESS!

Hold on, have I fallen for Poe’s law?

lengau OP ,

Because the separate installation means you can actually end up with both an apt installed and a snap installed.

This is something that can happen any time you have multiple package managers or even multiple repositories in the same package manager. Google’s official Chrome apt repo has debs for google-chrome-stable, google-chrome-beta and google-chrome-unstable, quite intentionally.

My comment about docker was a specific example of such a case, where vulnerabilities were introduced. It was actually a commonly used attack a few years ago to burn up other CPU and GPU to generate crypto

Can you provide a link to a source about that? I can’t find anything about it.

and you ended up with both a snap and apt installed docker

If you installed both the docker.io package from apt and the docker snap, yes you wound up with both. Just as if you install both google-chrome-stable and chromium you’ll end up with two packages of (almost) the same browser.

The fact that they are both packaged by Canonical is both irrelevant and a perfect example of the problem.

Then I’m gonna ask that you elaborate what specific problem you’re trying to explain here, because these seem pretty contradictory.

lengau OP ,

as you can see on other comments I’m not alone with that stance.

Being in the majority doesn’t necessarily make one right, as shown by [insert election result you disagree with here]. But if you actually are serious about that, you do realise how entitled it sounds to demand that someone do free work for you in the particular way you want it done?

And I believe you mean prerogative.

lengau OP ,

over the course of a few updates, they replaced half of your programs with snaps (without telling you),

You don’t need to lie. A full list of debs that have been transitioned to snaps is:

  • Firefox
  • Thunderbird
  • Chromium
lengau OP ,

And they’re providing Ubuntu for free. If you were a paying customer and the contract you’d signed with them said they’d provide Firefox as a deb, that would be a different situation.

lengau OP ,

Lol imagine a canonical employee using nixos

lengau ,

Uhh this is a bottle stopper

lengau ,

I’m sorry. I didn’t mean to reveal to the world that your butt is an outie

lengau ,

To be fair MS Office fully working on Linux is about the only thing we really need to make it completely viable for businesses.

lengau ,

The main problem is Excel, TBH. Far too much stuff depends on Windows-only features of Excel (e.g. macros using COM objects).

lengau ,

I agree, but unfortunately our opinions don’t move a gazillion finance bros

lengau ,

My favourite Euphorbia

lengau ,

Can confirm. I once ate in my lab and accidentally ate a capacitor I absent-mindedly thought was a piece of broccoli.

lengau ,

Some further context on this that @Dop might want to know:

While Canonical’s snap store is proprietary (which, to be clear, I don’t really like), all the client software is open source and the API is well documented (though a bit janky). Their snap store relay app (which is open source) has a full implementation of it. There was a fully functional open snap store for a while, but the project died out of a lack of interest. You can also distribute snaps through another mechanism and install them locally on the machine (though you then lose the benefit of snapd’s auto updates). You can even do this with snapd still checking the signatures of the snaps.

The standard for snaps is fully open, as is snapd itself.

There’s no need to oversell the negatives to the point of being wrong.

lengau ,

Flatpaks and snaps both have shared dependencies, just at a less granular level than debs. OCI images and VMs are pretty much the extreme opposite of shared dependencies.

lengau ,

I pretty consistently find the snaps to be the best trade-off of being up-to-date and stable for me. Especially for CLI tools and services.

lengau ,

I don’t think snaps are bad (and when someone tries to explain why they are, about 85% of the time they say something wrong enough that I suspect they’re probably just parroting someone else rather than actually knowing what’s going on). It’s sad, because if we could get rid of the bullshit we could actually have decent discussions about the benefits and shortcomings of snaps (and how to fix those shortcomings).

On the .deb front: it’s a package format made by Debian. Each archive contains a data tarball, which has the files in the package in their full structure from /, and a control tarball, which contains metadata such as name, version and dependencies as well as pre-install, pre-remove, post-install and post-remove scripts, which are used doing any setup or removal work that can’t be done just by extracting or deleting the files.

The upside of deb files is that they tend to be pretty small. The downside is that this typically comes from having a tight coupling to library versions on the system, which means upgrading a library can break seemingly unrelated things. (This is why you get warnings like this page: wiki.debian.org/DontBreakDebian) Many third party distributors (e.g. Google with Chrome) take care of this by packaging most dependencies inside the deb, inflating the size.

Another major difference between packages like debs and rpms and newer formats like snaps and flatpaks is that the latter have confinement systems to prevent apps from having full access to your system.

lengau ,

Well that’s what /opt is for. Well-behaved application packages that aren’t part of your core distro should install themselves in there.

lengau ,

If you look through the desktop portals GitHub, it seems to be a mess of bikeshedding, mostly on the part of a small number of people on the flatpak side. Canonical seem to have been working around this in snaps by writing their own interfaces as stopgaps until the desktop portals catch up, probably because they got such pushback when the similar frustration on the display server side resulted in them releasing mir with its own protocol until the Wayland folks could get their act together.

lengau ,

It was being done by a group of snapd developers at Canonical, IIRC, but after a couple of years of exactly zero interaction from anyone outside Canonical I think they just gave up and decided it wasn’t worth it because they were getting accused of trying to monopolise whether they had an open store or just an open API.

Of course, you can also distribute snaps without using the snap store API. I’ve used this for airgapped machines in the past. You can either just grab the .snap file (which is just a squashfs file with a meta/snap.yaml in it so snapd knows how to treat it) and install it with –dangerous, or you can include an assertion file for that snap signed by a certificate that your machine’s snapd trusts and not even have to do that. (Those airgapped machines trusted our own certificate so we could ensure that the snaps came from our CI process and weren’t a developer’s random test snap).

lengau ,

I don’t use Notepadqq anywhere (I use kate btw), but on my KDE Neon system it’s currently showing:


<span style="color:#323232;">$ snap info notepadqq
</span><span style="color:#323232;">name:      notepadqq
</span><span style="color:#323232;">summary:   A Notepad++-like editor for Linux.
</span><span style="color:#323232;">publisher: Daniele Di Sarli (danieleds)
</span><span style="color:#323232;">store-url: https://snapcraft.io/notepadqq
</span><span style="color:#323232;">license:   GPL-3.0
</span><span style="color:#323232;">description: |
</span><span style="color:#323232;">  It helps developers by providing all you can expect from a general purpose text editor, such as
</span><span style="color:#323232;">  syntax highlighting for more than 100 different languages, code folding, color schemes, file
</span><span style="color:#323232;">  monitoring, multiple selection and much more.
</span><span style="color:#323232;">  You can search text using the power of regular expressions. You can organize documents side by
</span><span style="color:#323232;">  side. You can use real-time highlighting to find near identifiers in no time.
</span><span style="color:#323232;">snap-id: 6iueWFAtx9P2OQz4SIW64Kry9hT8aUCL
</span><span style="color:#323232;">channels:
</span><span style="color:#323232;">  latest/stable:    1.4.8          2018-09-14 (855) 151MB -
</span><span style="color:#323232;">  latest/candidate: ↑                                     
</span><span style="color:#323232;">  latest/beta:      2.0.0-beta+git 2019-10-12 (890) 201MB classic
</span><span style="color:#323232;">  latest/edge:      2.0.0-beta+git 2019-10-16 (897) 197MB classic
</span>

It seems to be a dead project (the last release on GitHub is that same 2.0 beta from 2019), but looking at the snapcraft.yaml file, it looks like it’s because they’re vendoring in a pretty big chunk of KDE and gtk libraries. 2019 was before I started doing anything with snaps or flatpaks for desktops so I’m not sure what the state of KDE content snaps was then (I know there was a GNOME one because the core18 gnome content snap is installed on my system for uhh… some app that I have), but these days for desktop apps there are content snaps for gnome (published by Canonical) and KDE Frameworks (published by KDE) to deduplicate those dependencies.

lengau ,

The package structure for snaps is very much open, as is the API for a snap store. There was for a long time an open source snap store implementation, but it died out due to lack of interest by others in actually hosting their own stores, which to me says a lot about whether people actually want to host their own repo or just want to use it as a way to complain.

lengau ,

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.

lengau ,

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:


<span style="color:#323232;"># SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
</span><span style="color:#323232;"># SPDX-FileCopyrightText: 2022 Harald Sitter <[email protected]>
</span><span style="color:#323232;">
</span><span style="color:#323232;">Package: firefox
</span><span style="color:#323232;">Pin: release o=packages.mozilla.org
</span><span style="color:#323232;">Pin-Priority: 1000
</span><span style="color:#323232;">
</span><span style="color:#323232;">Package: firefox-*
</span><span style="color:#323232;">Pin: release o=packages.mozilla.org
</span><span style="color:#323232;">Pin-Priority: 1000
</span><span style="color:#323232;">
</span><span style="color:#323232;">Package: firefox-locale-*
</span><span style="color:#323232;">Pin: release o=packages.mozilla.org
</span><span style="color:#323232;">Pin-Priority: 1000
</span>

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 ~/

lengau ,

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!

lengau ,

Snap is far more like nix. Flatpak deals with a limited subset of what nix and snap do (e.g. it can’t distribute kernel packages).

While snap is certainly not without its problems, people repeatedly make massive negative claims about it that, while often based on a core of truth, are highly embellished to the point of being misinformation. (This is the same tactic I see with bad-faith political trolls, and with a similar result really - they’ll consistently try to use that core of truth to make far stronger claims than are defensible and, when it’s pointed out to them, they move the goalposts to a smaller, more defensible claim, only to repeat the bigger, debunked, claim later.)

lengau ,

I’d love to know what’s consistently breaking on KDE Neon for you. I’ve got some specific bugs I’m working through with their team, but I’ve never found it to be “always broken” (although I will say it is easier to break than Kubuntu IME).

lengau ,

Canonical have made the same mistake three times as far as desktop environments are concerned, IMO:

  1. 2004: went with GNOME
  2. 2010: made Unity as a way to rid themselves of the hostility of the GNOME devs
  3. 2017: Instead of leaving GNOME in the dust, they went back.

IMO using GNOME is an abusive relationship.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • lifeLocal
  • goranko
  • All magazines
    •