Wow they're still pushing snaps, the project with some the worst engineering I've ever seen.<p>- Extremely slow at doing anything, even the most basic commands.<p>- Ridiculous auto-update mechanism (you can't even disable it wtf).<p>- Random, nonsense limitations (why can't I open dot files and dot directories???).<p>So terrible that for most apps that I installed with snaps I end up installing the deb version later on.<p>What an abomination, it is a devil that's hurting the Linux desktop everyday.
Another snap failure story:<p><pre><code> You install chromium-browser through apt
Chromium gets installed through snap
You go to a PWA to install locally (like M$ Teams)
The desktop entry is saved with a path hardcoded to /snap/chromium/1234/... (1234 is the id)
You update chromium, either intentionally or automatically, the ID changes
Now you can't access your PWA anymore unless you edit the desktop entry and change the id or replace it with `current`.
</code></pre>
Such horrible user experience for no positive gain. And this is not a Linux problem, but an Ubuntu problem. Yet there is no difference in the eyes of people because "it's their Linux that broke...".<p>Bad user experience, bad implementation, bad decisions, and bad reputation to the wrong target, just because Canonical's Ubuntu is the "default" Linux.
Can we go back to just shipping apt packages?<p>They worked fine, and I don't feel like having multiple types of containers and update methods and mounted image file systems really made anyone's life better.
Mir, Unity, now Snap. Ubuntu has a track record of wanting to go it alone.<p>But, I'm all for competition, long may it continue. The only real negative here is that some apps will only release Snaps, others will only release Flatpaks and people will end up having to just revert to copr/AUR like before.<p>Choosing a distro is basically choosing a DE and package manager these days anyway - a single unified packaging format that works everywhere is more frustrating than an alternative DE or windowing system.
It speaks volumes to the success of Snap that they’re now moving to ensure Flatpak isn’t part of the default desktop experience.<p>The only outcome this leads to is monetisation attempts through their store and other OS integrations to try and turn free users into a source of revenue. If you’re using Ubuntu for desktop I’d urge you to start exploring alternatives.
<a href="https://fosstodon.org/@wimpy/109908489437633387" rel="nofollow">https://fosstodon.org/@wimpy/109908489437633387</a><p>@bluesabre@floss.social "[…] Ultimately, each of the current flavor leads agreed to the change. […]"<p>@wimpy@fosstodon.org "@bluesabre Did we agree? I think we complied with the requested change. You and I both played our part in ensuring this was clearly and openly communicated."<p>- - -<p><a href="https://nelsonaloysio.medium.com/installing-ubuntus-snap-on-fedora-silverblue-e82ca6fd6108" rel="nofollow">https://nelsonaloysio.medium.com/installing-ubuntus-snap-on-...</a><p>> […] As Ubuntu’s snap requires access to the root file system in order to create a symlink in /snap to /var/lib/snapd/snap, successfully installing it requires a few extra steps. Besides, $HOME directory in Silverblue defaults to the more traditional path /var/home/$USER, and since snap expects it to be on its modern location /home/$USER, this must be worked around as well. […]
Today VLC didn't start. No errors, no reason. Just didn't start.<p>Turns out snapd.apparmor, whatever that is, wasn't running. (I ran `vlc` on the cli to figure it out)<p>I love snaps, they're so convenient for the end user..
I wish there was a solution like flatpak or snap that does make things simpler, not more complex.<p>To begin with: It would be nice if the data of the containerized applications were stored in one place and one place only. Each application should simply be a single directory in /snaps/ or something.<p>At first I thought snap would be like that. But no. When I did some tests, the data of a snap seems to be splattered across various places on the file system.
The solution used by Linux Mint seems apt:<p><pre><code> cd /etc/apt/preferences.d/
cat nosnap.pref
# To prevent repository packages from triggering the installation of Snap,
# this file forbids snapd from being installed by APT.
# For more information: https://linuxmint-user-guide.readthedocs.io/en/latest/snap.html
Package: snapd
Pin: release a=*
Pin-Priority: -10</code></pre>
Reminder that if you don't like snaps and prefer flatpaks, it's pretty easy to migrate using: <a href="https://github.com/popey/unsnap">https://github.com/popey/unsnap</a>
What I really want is for Nix or something like Nix to become standard.<p>We can very easily mimic flatpak and snap by wrapping a nix closure in bwrap.<p>You can have the choice to sandbox it or not with Nix. And you can easily compose it with other software.
They could do with improving the behaviour of snaps first before removing alternatives. The updates are currently awkward as they don't seem to work if the application is running which can be a problem with something like Firefox which I have running for days at a time. It's also annoying that it's gone from using simple "apt" commands to keep the machine up-to-date, to also needing a "snap refresh".<p>I choose to use Ubuntu at work for a bunch of stuff, but snaps are making me consider whether it's worth migrating over to Debian instead.
It was expected, they're doing a semi walled garden with this snaps stuff it seems. I jumped ship back to regular Debian after the snapd stuff was foisted on users. Not looked back since.
I'm not sure if Ubuntu realizes that the entire Linux ecosystem is moving away from them because of this flatpak vs snap situation.<p>I'm sure their enterprise side is fine, but their consumer side is disappearing rapidly.
I think it should remove both - Flatpack and Snap. Stick to apt, improve it if you wish.<p>">This adds fuel to the fire that Canonical is doing this largely to further its own interests."<p>What a surprise, companies (excluding rare exceptions) are there to make money, not to give it out. Interests of the customers are taken into account only as far as it helps to increas income and satisfy legal obligations.
Canonical had a booth at CES this year, just a few rows over from mine. Every time I walked by it was totally deserted, just an employee or two looking at their phones.<p>It was rather cathartic to see
In 5 years I predict an arch based SteamOS derivative will be the most common desktop linux for personal users. It will have the backing of solid engineering form a company that couldn't care less about being opinionated regarding the desktop user space.
The more struggle Linux users have with snaps, flatpaks, appimages, and whatever their native package management system's quirks are, the more they will appreciate switching to NixOS one day, which IMHO is "the only sane Linux" as it's already definitively solved this problem. Join me in shaking my head at all this from the finish line...<p>And honestly, I get it. I avoided it for years (it's 20 years old now!!) mostly because the nix language and words like "derivations" scared me*, until a year ago after hopping distros for quite a while (hmmm Elementary, Pop_OS, Ubuntu, Manjaro, Arch...) and after a month where I had both a bricking AND a seemingly-unsolvable interdependency build problem, I got mad and decided to take a deep breath and check out <a href="https://nixos.org/" rel="nofollow">https://nixos.org/</a><p>* here, let me immediately solve that fear: Nix interactive language tour, it's like JSON with syntax sugar and pure functions: <a href="https://nixcloud.io/tour/" rel="nofollow">https://nixcloud.io/tour/</a> . And a "derivation"? That's basically a "lockfile" for a particular package, if you know what that is (and you probably do). Except it existed before the concept of "lockfiles", so it got that name.
As long as they stop shipping snaps by default as well and go back to stuff that 'just worked' instead of 'stuff that works in interesting and novel ways'.
Like many, I have had my fair share of frustrations with snaps. Already considering moving away from Ubuntu, but not sure where to go next. Is Debian a good option? I use Linux both personally and professionally, so while I do like to tinker with new stuff, I also need some stability.
I've used rolling-release distros in the past and its something I'd like to try again. Maybe Manjaro?
I see why software vendors don't want to have to target specific distributions if they can help it - it's expensive. I assume snaps and flatpaks try to mitigate that problem.<p>I wouldn't want it to be a very common solution really because it's not that efficient and means you get updates for security when that vendor feels like it.<p>I'm happiest with MOST software being in the distribution.<p>Anyhow I know there are lots of ways to look down on Arch/Pacman (Artix in my case - dinit instead of systemd) but I have to say that it is simply much more enjoyable to use than Ubuntu or Fedora or even Debian IMO. Perhaps one day some terrible thing will happen to make me regret it but I just cannot imagine going back to the horrible burdens of those distros - upgrading from one version to another (especially on Fedora - groan), selinux, snap Firefox etc
I wonder if these developments won't eventually result on a split, when at some point Ubuntu would rather not keep up with Debian packages, or talk things through upstream. Perhaps when there are some fundamental differences of direction at the packaging level.
I like flatpaks much better than snaps. I wish they would implement an equivalent to snap's classic confinement so that apps like vscode could interact easily with the default system shell, libraries, executables etc. That feels like a big hole in flatpaks.
Can't stand Snap, Flatpak and AppImage. They're the Nodejs of the software distribution world - a horrendously inefficient way to distribute software. DEBs and RPMs via APT and DNF are far better, imho.
Yep. The notion that they're listening to anyone, anywhere is marketecture at best.<p>I was outspoken in my interview about snaps. Of course this is the path to success in a monoculture.
> Ubuntu is prioritizing deb and Snap, its default packaging technologies, while no longer providing a competitor by default. This is described as an effort to provide consistency and simplicity for users.<p>It does! It'd be even simpler and more consistent if they dropped snaps and only used debs!
Personally I've just not had that many problems with snaps. Just one, really, with Firefox. Firefox was crashing every-time I used the File API; removing the snap file cache fixed the problem. I don't have enough experience with Flatpak to compare.
>Another potential concern may be that Canonical could be using this decision to force package upstreams to offer a Snap version or face not being easily available in the default Ubuntu installation.<p>There we are.
I didn't even know Ubuntu ships flatpak preinstalled. It's not like they are removing it from repositories, if you want flatpak install it - I don't see the issue.
Moved to Debian a while ago because of the mess with Unity and snaps, etc…<p>A shame, since ubuntu got me into linux desktop back then, but in the end they keep screwing things up needlessly.
If you are looking for a Linux distro, here is my recommendation. If you have the freedom, pick something that is independent + community driven(CD)/community oriented (CO) like Arch Linux(CD)/Linux Mint(CO) or which is not independent and depends on another distro's packages/infra but is still community oriented like Linux Mint or Elementary.<p>It's not some tinfoil stuff. Community oriented or driven (entirely community driven like Arch) always listens to the community. This snap and flatpaks wouldn't happen in the first place.<p>Use Linux Mint if you don't have time to initially set it up. Else use Arch Linux if you have initial time and patience to read. Arch is not scary like community is bad. There is a wall of text and it is intimidating. It needs time like a couple of days when you do it for the first time. But it is just about RTFM.<p>Flatpak and Snap are unneccessary abstractions which adds a hell a lot of bloat and for what? To make a point release distro work similar to rolling release. Nothing else. So just use a rolling release distribution like Arch or OpenSuse Tumbleweed (which I haven't used but have been hearing good things. Especially since last week here in HN).<p>But but, point release is bleeding edge and unstable!<p>NO! They are stable versions of packages and not development streams.<p>We seriously need to clear this confusion between a Linux distro's stable, testing, unstable repos and upstream's development branches. These two things are completely different.<p>When you say for eg; Firefox v222222.1 with a serious security patch is in testing branch for your distro, it means <i>it is not tested with YOUR distro which did some hacks to make it work cos it is a point release and froze your package for a point release</i>. *AND NOT BECAUSE OF THE UPSTREAM DEVELOPMENT BRANCH HAS BUG.* Majority of the time, it is fixed already in upstream. And even if it is a bug which is new, your package needs to be an important one. Otherwise you will have to wait till your next point release update or version bump before receiving the update. This backporting and picky patching on point releases is creating a huge amount of unneccessary overhead on upstream because hacks/patching differ on each distro.<p>Use any rolling release, Arch, Open Suse Tumbleweed, PCOSLinux, Void or a point release which uses unstable/testing branches (which ever is closest to upstream) like Debian unstable (Or whatever is being the distro's repo which is closest to upstream stable versions) which is essentially closer to upstream.<p>These are for desktop users. AND NOT SERVERS. FYI.