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

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

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.

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

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).

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.

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

Apple is (rightfully IMO) far more notorious for taking something that’s been around for years already, adding it to their product line (or as a feature in a product), and then pretending they invented it. Almost every company will copy features/products from other companies, but they don’t usually pretend to have invented the whole thing.

Example: Gmail. It was revolutionary, but not because Google really invented much (or indeed claimed to). Rather, it was revolutionary because it provided features that already existed in paid options (e.g. full IMAP support, large mailbox sizes) for free, with a good web interface.

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.

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.

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: https://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.

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.

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.

Some further context on this that @Dop@lemmy.world 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.

The first two snaps I compared sizes of on my system are uv and bitwarden. The uv snap is 9.5 megs vs. the wheel’s 12.2 megs, and the bitwarden snap is 97 megs vs. the Deb’s 79 megs and the AppImage’s 114 megs. These seem pretty reasonable - doubly so since snaps also have delta updates.

Like with any time you’re trying to select a specific source for a package, you need to set apt configuration to prefer that source. It’s standard apt behaviour with a standard way to configure it.

Whose home? Apparmor applies things at a system level, not at a user level.

Gotta give people their Two Minutes Hate or they might remember that voting for Democrats is, for most Americans, the actual least evil option on November 5.

It’s amazing how close they get to making good points before veering off into “Dems bad, do <thing that gets Republicans more power>.”

This meme really doesn’t fit the format. Given the standard form of the meme, you’re implying that Israel are the reasonable, relatable ones here, that the warrants are unreasonable, and that someone other than the ICC has actually announced warrants.

Please don’t.

Nix is a cool, good technology. We don’t need it to be an annoying meme.

Nah, this is just the same “hivemind hates thing” leaking over from Reddit. It’s not that different to the systemd hate. There’s a core of a point, but if a small fraction of the energy spent on the daily Two Minutes Hate were redirected towards fixing the things those folks don’t like, they wouldn’t have any molehills to treat as mountains.