Hacker News new | past | comments | ask | show | jobs | submit login
Canonical to Work on Improving Snap Support Across Linux DIstributions (phoronix.com)
28 points by mikece on Jan 5, 2024 | hide | past | favorite | 57 comments



For "reasons" (i.e. I got a job at SUSE), I have been running openSUSE for the last 6 weeks. I like that I don't have to deal with snaps and flatpaks at all. I was able to install Slack, VSCode, Chrome, etc... from professionally maintained repositories. Open source apps like GNote just install cleanly from repos.

That said, it's nice that people who prefer snaps or flatpak (assuming such people exist) have that option without those packaging formats being shoved at me constantly.


Gaming has finally gotten me into desktop Linux. Most of my prior exposure comes from occasional using remote VMs in a work setting, which are generally maintained by other people. That is to say: I don't have a lot of first hand experience with packaging/installing on Linux.

But my understanding is that Flatpak solves the problem of "this guy has Ubuntu and that guy has Pop! and they both want to download this app, but each distribution has its own packaging system." Having a stable target that works across distributions seems good for the ecosystem.


Or developers compile a static linux binary for the specific architectures (usual amd64) and just compile all of the dependencies into the app. You download the binary and run it. That used to be how Steam worked, for example, and I assume still does.

I think that what snaps and flatpaks want to do that is "better" than this, is to isolate your system from such applications if they are malicious.


Your description of Flatpak is technically more apt for AppImage than Flatpack.

What you said is not wrong, however, it misses the bigger picture because like Snap, Flatpak also includes a package repository and distribution mechanism, whereas AppImage only solves the problem of running a dynamically linked binary on an unsupported distribution (the problem you described)


openSUSE is seriously underrated. As much as I like trying out different distros, I've been stuck with it for at least 8 years because it's so good.


Please no. I switched off Ubuntu because of Snap. It always caused problems with Firefox. It would update it in the background, which would cause it to silently break. I switched to the apt source of it but when I reinstalled just opted for a distro that didn't have Snap running.


"please close the browser you're using to avoid interruptions"

hey Snap, this pop-up is an interruption


I don't want snap, ever. It is really annoying to have to disable it on Ubuntu. I don't think it would be as bad if they didn't hijack apt to install what they think should be a snap.


Snaps are also built into Ubuntu in such a way that if you don't reenable it and try to upgrade releases you can seriously mess up your installation. Yet, while they take great pains to disable 3rd party repos and PPAs they won't even warn you that you have snapd blocked


I agree, 100%. For any readers who want to know how to disable snap after uninstalling it:

1. Create a file /etc/apt/preferences.d/nosnap.pref 2. It's contents should be: Package: snapd Pin: release a=* Pin-Priority: -10


I see a lot of apps shipped with Flatpak these days on the PopOS store. They seemed to have worked out having the publisher of the app declaring access to certain things/capabilities on the hosts it will require, however, I somewhat remember Snap and Flatpak being sold as security layers rather than the packaging layers that they are now.

If Snap and Flatpak are both packaging layers I'd prefer Canonical embrace Flatpak.


They already caved on the Mir->Wayland and Unity->Gnome fronts, but only after wasting significant resources and causing more unnecessary confusion/fragmentation in the Desktop Linux space.

I expect the same pattern to play out with Snap -> Flatpak, it's just a matter of when, not if.

Though maybe this is uniquely sticky, like the ongoing .deb vs. .rpm / dpkg/apt vs. rpm/dnf situation since Forever...


There was some speculation yesterday on why Canonical keeps picking and losing these fights:

https://old.reddit.com/r/linux/comments/18yvefc/why_does_the...

The top reasons given were:

- Not Invented Here: Canonical wanting to design its own everything and not being welcoming of contributions or feedback from outsiders.

- Inventing for itself first: Canonical builds what's best for Ubuntu and lets other people import the source if they want to. Other providers build in the relevant communities, which makes it easier for other distributions to import the next-gen stuff (e.g. X11 and its replacement Wayland both came from Xorg).

---

While I was writing that, I was really tempted to use lowercase "canonical" to describe Xorg's relationship with the graphics stack, and then changed to "relevant" when I realized that the company being discussed is uppercase "Canonical." I wonder if how much of their self image is reflected in their name: do they they they're the canonical stewards of the Linux desktop?


> Other providers build in the relevant communities, which makes it easier for other distributions to import the next-gen stuff (e.g. X11 and its replacement Wayland both came from Xorg).

It seems more like Redhat just employes more GNOME devs and thus Redhat's work seems like "default upstream work" while Canonical's seems like "rewrite because of NIH". It is not as if GNOME is super inviting to random outside contributions either.

I haven't used GNOME/Ubuntu in a long time but I remember when Canonical wanted to go Wayland first before rolling out their own display server for their phone use case. At that time, Wayland was mostly just in Meego and related devices.

I just wish these distro wars happened in the final UI layer of the software stack instead of duplicating enormous amounts of the useless/boring/core work over trivial differences. (rpm vs. deb, snaps vs. flatpaks, etc..)


Long time Ubuntu user here. I think caving is the wrong perspective. When both Mir and unity where created, the state of both X and Gnome were atrocious. From all the distribution, canonical was the main one pushing for simple, competent and bug fresh desktop experience.

Sometime an industry get in a rusty/complacent space and stop improving and only creating a competing product can change things. LLVM vs GCC is probably one of the best example in OSS. People have complaining about the compilation speed of GCC and the quality of error message for ages, only when LLVM came about and focus on those area did we see GCC make significant progress.

To me it's clear that without the competition (and relative success) brought on by Mir and Unity, Gnome and Wayland wouldn't be anywhere near what they are right now.

In the case of Ubuntu, canonical main focus was to bring linux to the masses and brush off some of that geeky/hackery. And the ecosystem was at best in interested in it and at worst hostile to this (https://www.reddit.com/r/programming/comments/2986i/why_i_qu...)

So i think it was the case the canonical has not choice to create those project to fullfil their mission.And from my perspective they have succeeded. The reason ubuntu got so popular as desktop OS, is because for a long time they offered the best desktop experience.

The switch to Wayland,Gnome and systemd(from upstart) also make sense. As things improve, and some of the improvement brought by those projects get into the OSS alternative it simply make less sense to keep them around. And some of those improvement are done by canonical themselves (https://www.omgubuntu.co.uk/2019/10/ubuntu-improves-gnome-sh...)

Snap seems to be the continuation of this process. Installing application on linux is/was a very bad experience for a very long time. Most of the efforts in that space (which were very all over the place when snap was created) were centered around server/security/containerization. Canonical was looking for something different.

I don't like snap. Mainly because of long habits, and also because the snap packages always seem to be older than what i can get through APT. But i really don't get the passionate hate snap received just for trying to solve a real problem that "regular" people might have.


> the state of both X and Gnome were atrocious.

X was working fine. Gnome was always a child with problems.


>X was working fine.

X remote/networok approach as never great for highly interective modern desktop. Isn't the main thing that bost Mir and Wayland are addressing ?


I don't get Ubuntu, or the comments sometimes.

> Some people do, as Snap supports some functionality that the Flatpak alternative does not (in particular, server applications).

That's called Docker and Kubernetes. I have no idea who, out there, would be stupid enough to trust a production server deployment on Snap. The very idea is horrifying. If something goes wrong, at all, you're probably SOL unless you pay Canonical a pretty penny for your as-good-as-proprietary setup.

In which case, if the server market has a far-and-away better solution, what markets are left for Snap? Desktop and IoT. In that case, make Snap exclusively IoT and concede desktop to Flatpak and we all go home happy.


Is there any demand for this?


By Canonical, yes. By software publishers, maybe. By users... I mean, probably somebody somewhere?


I'm yet to read a positive review on Snap, and while traditionally speaking I would just go with the flow, I can only tell that my experience with the Snapcraft has been infuriating. I simple cannot make the product work for me because my bandwidth is too limited, and unreliable. I struggle to install anything from Snapcraft... I know what you're thinking "that's your problem, buddy", and I partially agree, but sometimes I wish these decisions would consider a bit more than your average city slicker! (same story with Apple, always a struggle to keep a connection going to their servers)


Actually I like using snap. Sure, it's not perfect, but for some things it just works. Sometimes it's really nice just to execute one line without downloading/extracting/installing stuff by yourself.


But flatpak does the same and has broad distribution support. The problem isn't necessarily that snap is bad (though, I would argue generally inferior in a couple regards) but that it's doing the typical Canonical thing of recreating a solution to a problem everyone else is putting efforts to already, just causing more general fragmentation of the ecosystem.


I wish flatpak had proper integration into the host system's CLI (like snap does quite well). flatpak run org.blub.foo is unergonomic.


Can't that just be solved with this?

   alias foo="flatpak run org.blub.foo"
I would bet flatpak doesn't do this by default since it doesn't hijack a native package's namespace in the way Canonical is forcing people with snap hijacking apt install, and gives you a choice.

This lets me run multiple different Chromium flatpaks alongside the native package (stock Debian apt Chromium, official Chromium flatpak, Ungoogled Chromium flatpak) without issue, for example.


to lock down core functionality and security updates behind new partitioning of core OS ? yes

.. /me looks to Redmond with awe


It's nice to see agreement on the issues of snap on ubuntu.

The whole practice of third party package managers is a disaster.

One of the biggest improvements in secruity of a linux desktop as opposed to windows is the model of loading applications. In windows, binaries are loaded from random third parties over the internet, in linux distributions the applications are built, and the biniaries provided by the distribution.

Even if applications aren't methodically audited, the pathway for inspection and debug is already in place due to building teh application at the distributor, not by the third party proving the application.

Third party package managers are an aggrigated version of this, they bypass the infrastructure that provides binaries for distribution user's to execute.


But snap is another security layer. Firefox snap is more secure than .deb version from Mozilla. Snap may catch a zero day.

The server apps I tried are good. If you don’t want fancy features, nextcloud snap runs like a tank, and self updates.

As an end user, I don’t want to worry about updates either. I know developers have different opinions due to their jobs.


Does anyone actually want this?


Canonical wants this because it grants them power/influence over the FOSS ecosystem.


TBH, we still have the BSDs. Although, in the case of freedesktop, they are quiet dead.


and thats red hats job.


Is there a problem with Snap beyond Canonical forcing its adoption in Ubuntu and the potential for surveillance capitalism by Canonical? As a package deliver/installation mechanism is it objectively better or worse than Flackpack (or whatever all is completing in that space) or does it all just boil down to "I hate Snap because Canonical is being icky?"


This was Ubuntu 20.04 so maybe things have changed, but slow startup (calculators should open instantly), forced auto-update (yay Firefox forcing me to restart in the middle of doing something) were the egregious ones.


I don't remember specifically if it was the calculator, but at the time I remeber installing a ridiculously simple app, that should be a 5 mega download max, and snap installing a monstrosity of more than 1 gig in size on my disk. It's atrocious and wasteful.


It is for your own safety. Think about the children.

Nowadays, processor power is infinite, memory is infinite, disk space is infinite, so why so many people complaining ? /s


Same experience, with also a strange non-standard folder for binaries in the user's home.


Indeed; it's appalling. This thread [1] shows the absurdity of the situation; almost 8 years, and no signs of a XDG-compatible behavior. At least now you can hide it under ˜/.snap using the experimental flag "system experimental.hidden-snap-folder=true"

[1] Please move the "$HOME/snap" directory to a less obtrusive location https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053


So another program poluting the home directory. People doing this shall be banned from publishing SW (hello Firefox, KDE).


There has been a lot of improvements since then, both performance wise and auto-update wise.


firefox snap updates in ubuntu22.04 have always been difficult to deal with, and it still updates automatically, screwing up the current session. That sort of nonsense is why I cannot setup a laptop with ubuntu for grandma to use.

I suppose this page should tell how things have improved, but its ridiculous tall cookie wall kept me out of the site: https://ubuntu.com/blog/firefox-snap-updates-and-upgrades


nope, that's essentially the problem. Snap is curated and controlled by Canonical and they are forcing the issue.

The issues that both share are slow starts, larger package sizes, lack of safe ways to interact with the rest of the OS, etc.

Base concept is actually really good- Separating out dependencies and "containerizing/sandboxing" userspace applications is just a no brainier from a security and maintenance point of view. Its so nice to be able to easily install several versions side by side and know you arent fucking up system dependencies. Once they (flatpack, snap, some future competitor/iteration) iron out the kinks it'll 100% be the way systems are managed.


Yeah, super slow startup of apps, themes not applying correctly with snap versions when they do fine with non-snap versions, inability to control when updates happen (this has been fixed since 20.04 but it was a huge PITA), a zillion weird entries in fstab, and multiple ways to manage packages on the same system. It is all a mess. I just recently moved off of 20.04 and after trying a few distros ended up on Linux Mint because not only are snaps completely disabled, they have a system in place for basing off vanilla debian instead of ubuntu if ubuntu ever makes it impossible to skip the snaps.


Snap is locked down on ubuntu as I understand it so you can't really use a different source than Canonical's. The end game is probably for Canonical to be gatekeeper to all your software and extract some kind of toll once you're trapped. Avoiding this kind of situation is one of the main reasons I left Windows.


You can compare the pros and cons once you create your own flatpak and snap repositories, like you can with apt.

Oh wait. You can't do that with snap. Snap is pretty much locked down, so Canonical is the proverbial troll on the bridge.


As a developer, I really liked the packaging experience of snapcraft. Flutter apps are really easy to make a snap for. Great news that it's going to be easier across the ecosystem.


As an end-user, I prefer a good package manager. Snap & Flatpak both have their trade-offs. I find both of them not worth my time.


won't get me back on that cursed platform


Which do you prefer?


Gentoo started doing binary packages ;)

But all the cool kids are running Arch, Pop or Void.


Arguably, Qubes OS is cooler.


Depending on which thing we're discussing, the easy replacements are Ubuntu->Debian and Snap->Flatpak


Mint has been comfy and doesn't have Snap running by default.


God no!! Snaps got to go. Why do they keep pushing this trash?


I don't really understand ubuntus push for so much of their own branded solution to things, it often doesn't feel any better than the other alternatives already provided. Is snapd really something people like?


I remember when began using Linux. I was sad that installing software was complicated and there was no standard.

Then apt came and it seemed good. But I soon discovered that I was only good for software that was on the repositories.

Then I considered adding third party repositories and it seemed good. But I soon discovered that it could easily break my distro.

Then I considered compiling the software on my own machine and it seemed good. But then I discovered that newly available software required newly available dependencies.

Then I considered building dependencies on my own machine and it seemed good. But then I discovered that it soon becomes very complicated and could easily break my distro.

Then I considered replacing my distro periodically by newer versions and it seemed good. But then I discovered that it was unstable.

Then I considered using LTS releases only and it seemed good. But then I discovered that it was hard to use newly released software.

Then I considered compiling software and dependencies for my user only and it seemed good. But then I discovered that it was too much work.

Then I heard about klik, then I heard about glick, and containers and guix. And, during a long time, everything around these options evolved. And all that seemed good in different ways than before.

A few years ago I installed debian 10 from debootstrap, an incredibly learning experience. I then installed flatpak and guix on it. I loved it. I can finally have a distro with a stable core, long term maintained, where I can easily use newly released software without ever risking my system in a very simple way.

Linux, even considering only the kernel, evolved a lot for this to be possible. AppImages, flatpaks and snaps are a godsend for software installation on Linux. I really like the way all that matured along all those years. I had the beautiful experience of installing the latest released version of GIMP in different distros, different computers with different architectures all with the very same command a little time after it was made available.

I have just a vague idea how complicated it was to reach this point but I like where we are now. I know a lot of people worked hard to achieve it and I know a lot of good ideas died along the way. I don't know how harmful the ongoing "war" between snap and flatpak is today but I'm glad both worked as expected when I had to use them recently.

There's a lot to improve but I 'm hopeful and watching these improvements occur like someone who watches history being written. For all those who made this happen, for all those who made it possible: thank you all. You solved a lot of problems I had for years and I owe you a lot.


snap sucks. nobody wants this.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: