There are reasons why Flatpaks are better, both technical and social.
On the technical side, Snaps add to boot up time, as all of them are mounted on boot, which can make the machine several seconds slower to boot in my experience. I don’t need Thunderbird before I’ve logged into my account, yet Thunderbird is already mounted and partially decompressed the moment I see a login prompt.
On the social side, you can easily host your own Flatpak server. Don’t trust flathub? Set up your own website! Users can add your repo with one command and you’re good. Users even get a prompt on package conflicts so they can pick which repo to use. On Snap, there are no alternative stores. The backend is hardcoded to use Canonical’s infrastructure, the alternative repos need to be installed as Snaps, and Oracle charges a hefty sum to those wanting to maintain a repo.
I wouldn’t be very upset if Canonical migrated to snaps had they implemented their system in a reasonably open design. There are advantages to Snaps over APT packages, for sure, and even though I’d rather see them use Flatpaks instead, a fully integrated Snap environment seems to be working just as well.
Canonical did a lot of things right. Mir was a good idea, for instance. AppArmor is much better than the SELinux tooling that Red Hat ships. They have some excellent dev tools for things like k8s (running on Snap, ironically). Plus, they have one of the best server distros out there.
Mir is not a good example of good distro engineering, because it’s an extreme case of NIH syndrome. Unlike what it is today, the original Mir was an alternative to Wayland.
The story started when Canonical decided that X isn’t good enough and they needed an alternative. They chose Wayland first, exciting the entire Linux desktop community. But then they dropped Wayland in favor of the new in-house Mir project, citing several drawbacks to Wayland. The Wayland community responded with several articles explaining why Canonicals concerns were unwarranted. But in typical Canonical style, they simply neglected all the replies and stuck with Mir.
This irked the entire Linux community who promised to promote Wayland and not support Mir at all. This continued for a while until Canonical realized their mistake late, like always. Then they repurposed Mir as a Wayland compositor.
Now this is a repeating story. You see this with Flatpak vs Snap, Incus vs LXD, etc. The amount of high handedness we see from Canonical is incredible.
FYI my understanding is that Incus is forked from LXD, because nobody trusts Canonical any longer. I don’t think LXD itself is them doing the thing that makes them untrustworthy.
You might be referring to something they have done since then, apologies if I misunderstood. Wouldn’t be surprised if they tried to make it a Snap or force Snaps into it.
LXD was under the Linux containers project earlier. After the Canonical takeover of LXD, the following changes were made:
The repo privileges of the original LXD developers were revoked. Those developers are driving the development of Incus now.
LXD’s license was changed to AGPL+CLA
The first point means that Incus is the true successor of the original LXD. The current LXD is a jealously guarded pet project of Canonical in the same manner as Snap and Mir.
As for the second point, I’m usually a proponent of AGPL. But CLA corrupts it so much that it’s more harmful than with a permissive license. The real intention of this license change is to prevent Incus from incorporating changes from LXD (since the copyleft license of LXD code is incompatible with the permissive license of Incus). Meanwhile LXD continues to incorporate changes from Incus, although the Incus developers haven’t signed any CLA. This move by Canonical is in very bad faith, IMO.
So yes - I consider LXD to be untrustworthy. But that doesn’t cover the old LXD code, its developers or its community. Those transformed fully into the Incus project the same way OpenOffice was forked into LibreOffice. And I don’t trust the LXD name anymore in the same way nobody trusted the OpenOffice name after the fork (before it was donated to the Apache foundation).
There are reasons why Flatpaks are better, both technical and social.
On the technical side, Snaps add to boot up time, as all of them are mounted on boot, which can make the machine several seconds slower to boot in my experience. I don’t need Thunderbird before I’ve logged into my account, yet Thunderbird is already mounted and partially decompressed the moment I see a login prompt.
On the social side, you can easily host your own Flatpak server. Don’t trust flathub? Set up your own website! Users can add your repo with one command and you’re good. Users even get a prompt on package conflicts so they can pick which repo to use. On Snap, there are no alternative stores. The backend is hardcoded to use Canonical’s infrastructure, the alternative repos need to be installed as Snaps, and Oracle charges a hefty sum to those wanting to maintain a repo.
I wouldn’t be very upset if Canonical migrated to snaps had they implemented their system in a reasonably open design. There are advantages to Snaps over APT packages, for sure, and even though I’d rather see them use Flatpaks instead, a fully integrated Snap environment seems to be working just as well.
Canonical did a lot of things right. Mir was a good idea, for instance. AppArmor is much better than the SELinux tooling that Red Hat ships. They have some excellent dev tools for things like k8s (running on Snap, ironically). Plus, they have one of the best server distros out there.
Mir is not a good example of good distro engineering, because it’s an extreme case of NIH syndrome. Unlike what it is today, the original Mir was an alternative to Wayland.
The story started when Canonical decided that X isn’t good enough and they needed an alternative. They chose Wayland first, exciting the entire Linux desktop community. But then they dropped Wayland in favor of the new in-house Mir project, citing several drawbacks to Wayland. The Wayland community responded with several articles explaining why Canonicals concerns were unwarranted. But in typical Canonical style, they simply neglected all the replies and stuck with Mir.
This irked the entire Linux community who promised to promote Wayland and not support Mir at all. This continued for a while until Canonical realized their mistake late, like always. Then they repurposed Mir as a Wayland compositor.
Now this is a repeating story. You see this with Flatpak vs Snap, Incus vs LXD, etc. The amount of high handedness we see from Canonical is incredible.
FYI my understanding is that Incus is forked from LXD, because nobody trusts Canonical any longer. I don’t think LXD itself is them doing the thing that makes them untrustworthy.
You might be referring to something they have done since then, apologies if I misunderstood. Wouldn’t be surprised if they tried to make it a Snap or force Snaps into it.
https://linuxiac.com/incus-project-lxd-fork/
LXD was under the Linux containers project earlier. After the Canonical takeover of LXD, the following changes were made:
The first point means that Incus is the true successor of the original LXD. The current LXD is a jealously guarded pet project of Canonical in the same manner as Snap and Mir.
As for the second point, I’m usually a proponent of AGPL. But CLA corrupts it so much that it’s more harmful than with a permissive license. The real intention of this license change is to prevent Incus from incorporating changes from LXD (since the copyleft license of LXD code is incompatible with the permissive license of Incus). Meanwhile LXD continues to incorporate changes from Incus, although the Incus developers haven’t signed any CLA. This move by Canonical is in very bad faith, IMO.
So yes - I consider LXD to be untrustworthy. But that doesn’t cover the old LXD code, its developers or its community. Those transformed fully into the Incus project the same way OpenOffice was forked into LibreOffice. And I don’t trust the LXD name anymore in the same way nobody trusted the OpenOffice name after the fork (before it was donated to the Apache foundation).
Oh, yep, that’s shady and bad behavior. Thank you.