I politely disagree. Try to look at Snaps this way: Canonical maintains 16.04, 18.04, 20.04, 22.04 and 24.04. Each with their own repos. Each has to be properly maintained. With snap they can release the package a single time, and it can be used across all of their releases. I think this is the main point of snap. Being able to use it across other systemd distros is just a bonus.
You can download a .snap package and install it. If you add the author’s signing key as trusted in your own snapd, you can even do it alongside their own assertion file.
With snap they can release the package a single time, and it can be used across all of their releases. I think this is the main point of snap. Being able to use it across other systemd distros is just a bonus.
Flatpak is not a solution for packaging a large portion of the types of software Canonical packages with snap, such as database servers, kernels and containerisation software like lxd.
Flatpak can’t run CLI apps. Also, they started around the same time. Flatpak in 2015 and Snap in 2016. This is like saying dnf shouldn’t exist because apt is a thing.
Why would Canonical abandon their own solution because some people online complain?
The question that I have to ask: what category of CLI apps (or even some examples) exist that are too complex to maintain a few versions simultaneously as native packages but are not complex enough to just use an OCI container for them instead?
Personally I use (and maintain) snaps for several developer tools I use, because the automatic updates through snap means I can have automatically up-to-date tools with the same package across my Ubuntu, Fedora, Arch and OpenSuSE machines.
Nix on non-NixOS distributions would be great, if it would support installing apps into the users home directory instead of a global directory (without recompiling everything).
(When I looked into it, it wasn’t possible, but if you made it work, please share.)
Yes, they maintain a lot of LTS releases and want to minimize work. Which is their own problem entirely. So I’m going to go back to Debian next time I reinstall or build.
Some time ago, I tried Ubuntu for the first time. I was shocked that the preinstalled Firefox (snap package) took 10 seconds to launch, compared to 1-2 seconds on Windows.
Ubuntu benefited from an open community for years, and when it came time to create a solution for a problem, they chose to develop something and not share it with community that helped them get where they are now. That’s a straight up asshole move.
I dare say that allowing any distro to use their repos is pretty generous, and gives back to the community. They have no obligation to open source Snapcraft’s server, and snapd being able to install snaps locally is more than enough.
Silly whataboutism. When there are multiple Linux package management solutions to choose from that are functional, decentralized, and fully FOSS, including ones that work across distros, switching to the proprietary Canonical-controlled Snap Store is moving backward for no good reason.
Let’s look at the very worst case possible scenario: Everyone abandons Flatpak and AppImage and moves to Snapcraft, and Canonical decides to make a decision that destroys the store.
You can still install FOSS apps from somewhere, at worst compile them.
All that would be lost if Snapcradt stopped existing are the proprietary apps, which you wouldn’t use anyways.
That’s not the worst possible scenario, I’d love to see the Snap Store completely replaced with decentralized FOSS alternatives. Any scenario in which the Snap Store takes market share from decentralized FOSS alternatives is considerably worse.
Also, who said I wouldn’t use proprietary apps? I refuse to use Snap because Flatpak and other FOSS application packaging solutions that aren’t locked to a store controlled by a single for-profit company already serve my needs. I don’t have any objection to using proprietary apps that don’t have alternatives that meet my needs.
I politely disagree. Try to look at Snaps this way: Canonical maintains 16.04, 18.04, 20.04, 22.04 and 24.04. Each with their own repos. Each has to be properly maintained. With snap they can release the package a single time, and it can be used across all of their releases. I think this is the main point of snap. Being able to use it across other systemd distros is just a bonus.
There is no way to install snaps from any source other than Canonical and the snap server software is closed-source.
You can download a
.snappackage and install it. If you add the author’s signing key as trusted in your own snapd, you can even do it alongside their own assertion file.You’re just describing flatpack.
Snaps predate flatpaks though.
Yeah but only in 2016 were they made available for other Linux distros. Flatpaks were available since 2015.
So why would Canonical switch to another technology that came after what they made and doesn’t cover their biggest use cases for snaps?
I’m not saying they would.
But if flatpak doesn’t meet the widest use case of snap, are they really describing flatpak?
I replied to:
Flatpak is not a solution for packaging a large portion of the types of software Canonical packages with snap, such as database servers, kernels and containerisation software like lxd.
Flatpak can’t run CLI apps. Also, they started around the same time. Flatpak in 2015 and Snap in 2016. This is like saying dnf shouldn’t exist because apt is a thing.
Why would Canonical abandon their own solution because some people online complain?
The question that I have to ask: what category of CLI apps (or even some examples) exist that are too complex to maintain a few versions simultaneously as native packages but are not complex enough to just use an OCI container for them instead?
Personally I use (and maintain) snaps for several developer tools I use, because the automatic updates through snap means I can have automatically up-to-date tools with the same package across my Ubuntu, Fedora, Arch and OpenSuSE machines.
Install CLI packages with Nix. You don’t need a proprietary system
Nix on non-NixOS distributions would be great, if it would support installing apps into the users home directory instead of a global directory (without recompiling everything).
(When I looked into it, it wasn’t possible, but if you made it work, please share.)
I found this that might help:
https://discourse.nixos.org/t/how-to-use-a-local-directory-as-a-nix-binary-cache/655/13
Or just use flatpak or Appimage.
Yeah, exactly. I was about to say flatpak exists and isn’t proprietary.
Also, the snap for docker/compose is hot garbage.
Yes, they maintain a lot of LTS releases and want to minimize work. Which is their own problem entirely. So I’m going to go back to Debian next time I reinstall or build.
So offering 10 years of support for a release is a bad thing now. Got it.
No. But I’m not willing to trade convenience for vendor lock-in. Not that this matters in containerland anyway.
Some time ago, I tried Ubuntu for the first time. I was shocked that the preinstalled Firefox (snap package) took 10 seconds to launch, compared to 1-2 seconds on Windows.
Why do they need to disrespect their users rights to that though?
How does Canonical disrespect your rights?
Ubuntu benefited from an open community for years, and when it came time to create a solution for a problem, they chose to develop something and not share it with community that helped them get where they are now. That’s a straight up asshole move.
I dare say that allowing any distro to use their repos is pretty generous, and gives back to the community. They have no obligation to open source Snapcraft’s server, and snapd being able to install snaps locally is more than enough.
https://forum.snapcraft.io/t/download-snaps-and-install-offline/15713
What an embarassingly obsequious viewpoint.
They snap store is proprietary
So are the drivers your computer likely relies on. Are you willing to buy a thinkpad from 2005 and use a random FSF approved distro?
Silly whataboutism. When there are multiple Linux package management solutions to choose from that are functional, decentralized, and fully FOSS, including ones that work across distros, switching to the proprietary Canonical-controlled Snap Store is moving backward for no good reason.
I don’t see how this matters.
Let’s look at the very worst case possible scenario: Everyone abandons Flatpak and AppImage and moves to Snapcraft, and Canonical decides to make a decision that destroys the store.
You can still install FOSS apps from somewhere, at worst compile them.
All that would be lost if Snapcradt stopped existing are the proprietary apps, which you wouldn’t use anyways.
That’s not the worst possible scenario, I’d love to see the Snap Store completely replaced with decentralized FOSS alternatives. Any scenario in which the Snap Store takes market share from decentralized FOSS alternatives is considerably worse.
Also, who said I wouldn’t use proprietary apps? I refuse to use Snap because Flatpak and other FOSS application packaging solutions that aren’t locked to a store controlled by a single for-profit company already serve my needs. I don’t have any objection to using proprietary apps that don’t have alternatives that meet my needs.