Switching Firefox from the apt repo to the snap is one of the things I did when using KDE Neon on my laptop (on my desktop with Nvidia I did the opposite on Kubuntu).

I don’t know what you mean about VLC though - while it’s available as an official snap published by VideoLAN, it’s also in the apt repos on all Ubuntu versions.

I have my own criticism of Canonical, but most of what I hear from the anti-Ubuntu crowd isn’t even grounded in reality.

My favourite one recently was that upstart was Canonical NIHing systemd.

Ironic - one of the reasons I like Ubuntu based distros is the easy access to snaps.

“Don’t feed the trolls” has ended up with the trolls running the place. I’d rather Lemmy not become yet another “lol ubuntu sux” echo chamber.

It might be time to upgrade

https://github.com/canonical/snapd

That’s pretty fundamentally not how flatpak works. It could theoretically be modified to do all of that, but by that point you’re recreating snapd and it would likely be easier and more straightforward to start with the current snapd and change what you dislike about it.

There was an open backend for a while. A complete lack of interest killed it.

No, I do that for free, because it’s a net benefit to me.

Flatpak doesn’t manage system services.

I use snaps on multiple non-Ubuntu systems, because they provide capabilities I haven’t been able to find elsewhere without having to manually manage updates, security issues, etc.

Yes, snaps are widely used so naturally people hate them too.

Ubuntu Core works by having everything on the system, kernel included, be a snap. Or, as another way of describing the same thing, everything on the system is installed by mounting a squashfs image (which by its nature is read-only) and applying groups to the processes in those images. This applies all the way down to the level of the kernel, although a kernel snap, on install or upgrade, does write out to a boot partition.

The net result is that you get many of the benefits of immutability, but also many of the benefits of traditional distros. For example, you can replace the kernel snap (and even build your own kernel snap if you choose) without replacing the rest of the base system, since the kernel is installed separately from the base. This is especially important for non-x86 systems that may need different (mutually incompatible) kernel builds for different SOCs, but even on x86 an example of replacing parts like that is NVIDIA drivers. But you don’t need a separate version of cups just because you have an Nvidia GPU. And because cups is in its own snap, it’s isolated too. You get the same benefits of confinement that applies to desktop apps, but for services, where it can be even stricter. After all, cups doesn’t need to even know that you have a GPU, so an attack vector of hacking cups and then using it to attack your GPU gets foiled in a way that an immutable base with unconfined services doesn’t.

It’s also inaccurate to say that they reinvented the wheel since snaps predate flatpaks.

It’s popular and widely used so people naturally hate it.

Ubuntu Core is the way Ubuntu’s doing immutability. They’ve already got tech demos of Ubuntu Core Desktop, but designing a distro around interchangeable parts with immutability and the ability to have airgapped networks that can still get updates is a nontrivial task. But it depends on things that snaps can do that Flatpak was never designed to do.

Does it still require Python 2 or did the author finally relent on that?

GPLv2 only says that people with access to the binary need access to the source code too. If they only used it internally they’d never have to make it public.

There were several cases of shenanigans from other Red Hat controlled projects yanking upstart configs and sysvinit scripts from their projects and replacing them exclusively with systemd units even though those configs had active maintainers (often people who worked at Canonical or Google). This made packaging those supposedly community owned but de facto Red Hat controlled projects more difficult for any system that didn’t use systemd, since the packagers had to scramble to find or recreate those files and then maintain patch series for them. They also very quickly jumped on adding systemd-specific integrations where similar integrations to make the services work better with upstart had been rejected because services weren’t supposed to favour an init system.

Something not necessarily (or provably) from Red Hat - a whole lot of misinformation about upstart suddenly started appearing on mailing lists and message boards when Debian was considering whether to use upstart or systemd. While I think they made the right decision to go with systemd, that sudden influx of new accounts complaining about upstart likely influenced the decision in ways I’m really not comfortable with.

I don’t dislike systemd. I’m happy to use it and think it works quite well for many (though definitely not all) of the things it does. But I am concerned about how it’s yet another case of Red Hat having a large amount of control over the Linux ecosystem and Red Hat controlled projects and the supporters of Red Hat projects using dirty tricks to further that control. And with systemd consuming more and more of how a Linux system works, I am concerned about the influence that gives Red Hat. Are we going to see systemd-packaged that manages your packages, but somehow the patches to make it work with non-RPM packages keep getting rejected or just held up for years at a time? (We’ve already seen similar things with xdg portals, where portals Red Hat wants get approved and merged very quickly, but portals proposed by Canonical or SuSE spend years “in review” with more and more petty changes requested, sometimes to be rejected because a Red Hat backed portal that only implements part of the functionality suddenly appeared and was approved within a week or two.)

I have the following complaints about systemd:

1. It was created basically by lennart because after RHEL 6 did pretty much the worst implementation ever of upstart he got NIH syndrome about it
2. Red Hat played a lot of dirty politics early on to get systemd everywhere (my tinfoil hat theory is that Red Hat let Lennart’s NIH syndrome run away with it because they thought having more control over the init system would be beneficial)
3. It’s subsuming everything, often with no real benefit over what it replaces.

The first two aren’t actually issues with systemd, but rather are political issues I have around the way Red Hat bullies the rest of the Linux ecosystem. I’m not going to let that become a stopping point for my using what is actually a fairly good piece of tech. The third is actually an ongoing issue, but it’s not enough for me to try throwing the baby out with the bathwater. It is, however, IMO a continuation of Red Hat’s sketchy political play.