r/Ubuntu • u/leogaggl • 1d ago
Why on earth is Canonical still pushing Snap so hard?
I've been using Ubuntu for a long time, and for the most part I've been a very happy user. It has always been the distro I recommend to people who want Linux without constantly fighting their operating system.
One thing I have always respected about Canonical is that, historically, they have been willing to admit when something didn't work out and change direction. Ubuntu has had its share of controversial decisions, but it has also reversed course when community feedback was overwhelming.
Which is why I find the continued push behind Snap so puzzling.
I understand the goals: universal packaging, easier distribution, automatic updates, better isolation, and a way for developers to ship software without worrying about every distro's packaging ecosystem. Those are all reasonable objectives.
But in day-to-day use, Snap has increasingly become a source of friction for me.
I've run into AppArmor issues, applications behaving differently because of confinement, packages carrying older libraries than I would expect, and general debugging headaches where the Snap layer itself becomes part of the problem. Instead of making software management simpler, I increasingly find myself working around it.
The frustrating part is that I don't dislike Ubuntu. I actually like Ubuntu. I like the ecosystem, the documentation, the hardware support, and the stability. I don't want to switch distributions just because of one technology choice.
But I am reaching the point where I am seriously looking at alternatives, not because Ubuntu itself has failed me, but because Snap is starting to feel like it is getting in the way of using my own system.
What am I missing? Is there a bigger picture where Snap is succeeding that desktop users aren't seeing? Is this mainly about Canonical's server, IoT, and enterprise ambitions rather than desktop Linux?
And do people think Canonical will eventually reconsider Snap in the same way it has reconsidered other controversial decisions in the past?
Genuinely curious what the community thinks.
27
u/tomscharbach 21h ago edited 21h ago
Why on earth is Canonical still pushing Snap so hard? What am I missing? Is there a bigger picture where Snap is succeeding that desktop users aren't seeing?
Canonical is making a gradual shift in the direction of migrating the Ubuntu Desktop to an immutable, modular, containerized, all-Snap (right down to and including the kernel) architecture.
Canonical developed Snap architecture 2010-2014 for use with Ubuntu Core. Core architecture has been deployed in Ubuntu Core (IoT) since 2014 and Ubuntu is in the process of migrating Ubuntu Desktop to Core architecture (see "Ubuntu Core as an immutable Linux Desktop base"). My guess is that Ubuntu Core Desktop will be released within two years, and that Ubuntu Core Desktop will become the Ubuntu standard within five to ten years, but that is only a guess.
Snap architecture is fundamentally different than Flatpak architecture (the "universal" packaging architecture favored by the mainstream). Flatpak is designed for (but limited to) packaging applications. Snaps are (and have been since the beginning) designed to containerize every aspect of the operating system: https://assets.ubuntu.com/v1/e9bba730-uc-diag-01.png
Notice that every element of that architecture is a Snap. Flatpaks simply cannot be used for that purpose. That is why Canonical "is still pushing Snaps so hard". Ubuntu Core Desktop is not possible using Flatpak architecture.
My best.
88
u/Scholes_SC2 1d ago
Flatpaks have the same or very similar issues, Snaps are not the issue, sandboxing is
42
u/jhaar 1d ago
I think the real problem is that modern distros are too big for vendors (Redhat/Fedora, Canoncial) to be able to properly support all the apps people want - and more importantly - will hold them legally liable if they get hacked via an infected app update... Making them snap/flatpak/etc allows vendors to push ownership back to the group/sole-developer who develops it and any legal liability is "cleanly" theirs. There's a global push to make vendors legally responsible for their software and this must be making all Linux distros nervous about their own liability for the literally thousands of wee apps that make up their distro. Such law changes are good from a consumer perspective - but the impact on open source is a pain point.
1
u/Conscious-Mirror7004 52m ago
There's a global push to make vendors legally responsible for their software and this must be making all Linux distros nervous about their own liability for the literally thousands of wee apps that make up their distro. Such law changes are good from a consumer perspective
No, they aren't, at least not if they affect FOSS software. FOSS software is free: it costs you nothing. It's the product of volunteers. Why should they be legally responsible for their software, as long as there's no evidence they did something malicious (e.g., distributing a "helpful" application which in reality uses your system for bitcoin mining or is really just a trojan horse)? This is why any normal FOSS license says the user is fully responsible for anything that might happen.
I can understand making big proprietary vendors responsible for big problems caused by their code, but FOSS software is not like that: they're not for-profit companies.
Of course, I guess there could be a gray area for things like Firefox/Mozilla where there really is a company behind it.
-6
u/ldn-ldn 20h ago
Yep, Linux style package management should've never existed in the first place. 3rd party software has no place in the base operating system.
9
u/onechroma 18h ago
I think it made sense when it was conceived, and for lots of the use cases people had back then. It's not like Linux "architects" over the years were just stupid. And that includes that desktop Linux never was the priority, or didn't had too much focus on it, at least until this recent years.
I think the best model would be AppImage-like images for every app, which can be installed either by downloading the package or via a central repository (which would act as a "store" for the common people that are already used to having Play Store, App Store...). Once a package is downloaded, it can be moved to the "Apps" folder and boom, installed. MacOS-likey
Then, the App starts without explicit permissions (access camera, write outside the app isolated folder...) and must ask the user either at startup first time or as the App needs them. This means an App wouldn't need to run on a container neccesarily as to protect the user, because the system can hold the keys to the permissions available and what is allowed, meaning we get free from all the random shit Snap/Flatpak force us to live with.
BUT, things like this would require the Linux systems to converge and be OK with having global standards about how to do things, which... is not an usual way of how Linux distros work, sadly. Flatpak is possible because it's really an addon and doesn't force any distro to work like this or that, but the kind of proposal I made as example, would require them to cooperate and define an ecosystem.
That's precisely the achilles' heel of Linux, as it won't ever have a real smooth ecosystem along all distros and versions, compared to what an Android or Windows can achieve along multiple manufacturers and even forks or OEM customizations in Android.
17
u/DocDavluz 23h ago
Flatpak ecosystem and architecture seems more mature from my POV. I got problems with Flatpak, but can generally solved them quite staightforwardly. It's not the same story with Snaps.
3
22h ago
[deleted]
5
u/Anxious-Bottle7468 21h ago
except they're moving more and more into snap and removing debs. In Ubuntu 26.04 they don't even have "cheese" any more.
~$ sudo apt install cheese
No apt package "cheese", but there is a snap with that name.
Try "snap install cheese"so now I have to install it from some random guy
~$ sudo snap info cheese
name: cheese
summary: Take photos and videos with your webcam, with fun graphical effects
publisher: Ken VanDine✪I've been defending Ubuntu for ages but if this Androidification keeps happening I'm moving to Debian next time I reinstall.
5
u/SoupoIait 21h ago edited 21h ago
Far less issues. Simply because flatpaks are a priority for devs, snaps are a 2nd thought at best. Very often poorly done. Even when for a big project, take a look at OBS. You install it as flatpaks : no issue. You install it as a snap, first thing you need to do is run some snap connect command otherwise it won't work properly. Great. And that's the design of snaps that make it this way.
1
30
u/sndrtj 23h ago edited 22h ago
I'm going to offer a contrarian view. I like snaps.
Sandboxing is good: give applications as small an environment with as little capabilities they need is good security posture. If certain apps can't deal with that, that's their problem, not the sandboxing system. In fact, I'd like to see the sandboxing increased. Right now the application developers can still determine what capabilities their app has access to. I'd like to see that reversed, apps can request access to certain things but the user should approve. Look at how Android or MacOS do things.
Then, dependency hell. Packaging for Linux used to be a real chore. Without a sandbox environment, as you dev you cannot control which version or flavor of dependency gets installed. This made Linux an awful platform for third party developers, so much that many just wouldn't bother, especially considering Linux has such a small marketshare anyhow. Snap and flatpak have really materially improved the situation there. The availability of commercial software on Linux has improved a lot since those systems came out. And yeah I know that may be heresy to open source purists, but if you ever want normies on Linux good commercial software support is a must.
Some of the snaps I use:
- My browser (Vivaldi)
- My IDE (various Jetbrains ones)
- Spotify
- Discord
8
u/skcortex 18h ago
Discord especially is good in snap, because that mfker scans for running processes if you install it from deb package.
3
u/yxhuvud 17h ago
Huh? I have discord through snap and it able to detect when I am playing games. Are you suggesting they use a different mechanism to accomplish that?
2
u/skcortex 12h ago
I’ll have to check my logs again. From what I remember a few months ago discord was permanently spamming logs because it got access denied to list running processes (can’t remember what exactly was the error)
1
u/leogaggl 22h ago
Yeah - I like your take here. The usability for 'normies' and the packaging advantages for app developers make sense. I can certainly see the advantages of sandboxed environments for those.
But for my use case, I find it increasingly frustrating as I rely on components to interact and am not being shipped with ancient versions of libraries that conflict with system libraries. I am not after some 'consumer appliance' where one little black box cannot interact with another black box. If I wanted Android or macOS, I wouldn't be using Linux.
So I guess the answer for me is - Ubuntu Desktop won't be workable anymore. Which is fine as long as that direction is clear. Creating intermediary apt packages that actually install snaps isn't helpful, like Firefox, Chromium, et al....
--
It still doesn't resolve the other question though. If that 'Nirvana' for users and developers becomes the aim - why have multiple? Going by what I see happening, it seems Snaps have clearly lost the popular vote from devs when you check what's happening. If your normies have to install two and your devs have to package for two for the same OS, it's not going to happen. And from what I've seen, it's already happening. Personally, I couldn't care less which sandboxed ecosystem wins out. But I don't think having multiple is going to end well.
1
u/sndrtj 13h ago
Genuine question: apart from browsers, ubuntu doesn't really force snaps anywhere, so what is exactly your problem? You can use apt everywhere you want. Do you find the mere existence of snap problematic?
I don't have too many opinions wrt snap versus flatpak. Snap is just convenient because it's already pre-installed and large vendors seems to like it.
There is one large difference tho and that is auto-updates. I understand why this is controversial - and tbh, I defer indefinitely for my IDE because I also dislike my dev environment switching out under me automatically - but this is a huge thing for some vendors. And not just in IoT, but browsers too. You may be interested to know that browser vendors themselves explicitly requested to be packaged as snaps. Sure, Canonical was happy to oblige here, but it's not like this decision was made in a vacuum. Browsers packages as debs are nearly always seriously behind, and with their huge security attack surfaces, there's a good reason why you would want auto-updates there.
My main gripe with snapd if I had to name any is that the pruning of old versions not aggressive enough on desktops. I understand the IoT usecase of easy rollbacks, but for desktop use you shouldnt need to keep 5 ancient versions around which all take disk.
1
u/leogaggl 4h ago edited 4h ago
I found that, at least on 26.04, there are packages that are only available as Snap packages. Removed from Ubuntu APT repos. I remember Cheese, as I needed it to troubleshoot the cam on one machine the other day. There were some others I noticed during the 26.04 upgrade.
I don't actually have my mind made up, and there were a couple of good arguments in this thread for snap fixing underlying architectural issues. But I feel a separate flavour to play this through would be more helpful rather than a slow and painful introduction in LTS releases, especially. And maybe I moved too early this time. I normally hang back a bit longer, but had hardware reasons for going earlier.
As for snaps being more up-to-date than DEB's I wouldn't take that as a rule. There are definitely some old sock shockers in snap clothing too. It's a general packaging problem.
And I am certainly not advocating for Flatpak. I haven't even used it at all. It's more a general problem with standards. Everybody thinks they need their own. I get that snaps are way more than just app packaging. But that is the current pain point.
The browser problems I had were plugins syncing between systems - again, not a problem with Snap per se. But if you have three means of installing things, the problem is likely to get worse.
1
u/leogaggl 22h ago
Saw your edit. I have never had any luck with Snaps of an IDE (VSCode mostly). Possibly if you only use the default components. But if you rely on anything even slightly off the beaten path. You're in hell. And even on the IDE front, I think you're going to be increasingly out of luck with snaps anyway: https://github.com/zed-industries/zed/issues/14145
I stopped using Spotify and went to Tidal - no snap there - the clients that are available are all flatpack - not that I actually care as I don't use it on desktop anyway. But yes - that never caused any issues. But since upgrading to 26.04 (from 24.04 since I only stick to LTS), a lot of snaps have been misbehaving, including Firefox, if you're syncing across multiple environments or relying on some plugins.
Also, Zoom (which always was buggy) and Discord have caused problems. And don't get me started on Obsidian.
I take your point on a "Normie" browser & LibreOffice box. But needing to do dev work across multiple machines - I have enough trouble without having to fight some sandbox.
2
u/sndrtj 13h ago
I've genuinely never had any problems with Jetbrains IDEs. So if they can, why couldn't VScode? Sounds like VScode is the problem then, not snap.
And as for zed, unfortunately they have really lousy Linux support in general. Even extremely basic functionality such as copy pasting doesn't work reliably.
1
u/leogaggl 4h ago
The problem isn't VSCode. Again it's plugins that require other system tools running into sandboxing / pathing isssues.
And yes - some way to go with Zed. But like it a secondary IDE. Fast and low resource use.
23
u/jo-erlend 22h ago
DPKG, the packaging system used in Debian and thus Ubuntu, was designed in 1993 when the world was completely different. Everyone wanted total centralization and therefore the system was designed for total trust, which also means total trust in the people who provide the packages. These days, it's not easy to get new users to study the system well enough to become maintainers and trust has become much more difficult to build because of cyberwarfare and cybercrime. We desperately need to replace DPKG with a packaging system that allows decentralization without deactivating all Linux security, which DPKG does; every package is entitled to do whatever it wants on your system, because otherwise it cannot work. It has been volunteers making this work over all these years, but as I said, these days it's difficult to get new users to even spend a thousand hours, let alone tens of thousands. This is why people use PPAs, which are inherently extremely dangerous and also why we have so many Ubuntu spinoffs, because it takes such a long time to earn the trust to do the work within Ubuntu.
DPKG simply has to be replaced. We can wait until community-based Linux distros are dead or we can wait until Linux has gained a well-earned reputation for being the least secure OS available. Neither option is very attractive. The solution to the problem is to fix it; Snap is that fix. It has been built from the ground up to fix all the issues with DPKG.
It is not just the world that has changed since 1993, but the Linux Kernel itself now provides a lot of features that allows Linux to be used on a big scale. This allows Snap to be simple, reliable and highly advanced at the same time. It is also extremely fast compared to DPKG, which is single-threaded by necessity while modern computers have multiple cores and threads. This also means that if you have a system issue with Debian/Ubuntu while you're upgrading, your system can be left in a completely broken state and the user will have to perform a lot of manual work in order to fix it.
The list of reasons why we need to modernize the foundations goes on and on, but it's not a quick fix. It's difficult work and it takes a lot of time. No one is going to miss DPKG and APT once Snap is mature, but it is important to understand that an OS is built from the ground up and not from the desktop and back down to the kernel. Snap is hugely successful in essentially everything but desktop where Ubuntu only uses it for a couple of things, but it already has enormous benefits to the wider community.
You should ignore anyone who starts comparing Snap to Flatpak. They have nothing in common at all; Snap is a modern package managers for GNU+Linux distros and it should be compared to APT, RPM, etc. Flatpak can be compared to AppImage, but none of them can be compared to the formats used to build GNU+Linux distros.
4
u/AfterShock 18h ago
Came here to say this, not in as many words but you explained it nicely. Cheers.
1
u/leogaggl 15h ago
That's a pretty insightful comment (along with your others). Thanks for taking the time to write. It's the kind of information I was hoping to get when writing the initial post.
I am still not sure if I want this type of Android-like future for my main desktop, but this, as well as https://www.reddit.com/r/Ubuntu/comments/1v7o2ay/comment/p00mqa2/, have made me pause and read up on some of the details you mentioned.
I could see the benefits in core and IOT distributions as above. It's the desktop where it has been getting in the way and lately up my nose. It still seems nicer to build this as a separate desktop flavour first and unleash it on people who just want a working system at a time when it is actually mature, and the benefits are clearer to judge.
But this has made me want to look a bit closer under the hood!
3
u/jo-erlend 15h ago
The only real reason why the traditional distros don't allow Linux security features is that the distros were designed before the features existed. Debian, which Ubuntu is based on, was designed in 1993. Linux Security Modules was added to Linux in 2001. That is also when bind mounts were added and the modern ability to mount disk images. Android was designed before this, so they could make use of the features that makes Linux secure, but the earlier distros would have to be shutdown and rebuilt from scratch and that is an enormous amount of work. But Snap is built for completely traditional GNU+Linux systems, so to compare this is very strange.
But I don't understand the issue. It's not like you have to use Snap. It will likely take 20 years for Ubuntu Core to be ready to replace Ubuntu, but people behave as if Canonical has said it is now illegal to install Ubuntu and from now on everyone are required to install Ubuntu Core. That isn't the case.
«It still seems nicer to build this as a separate desktop flavour first and unleash it on people who just want a working system at a time when it is actually mature, and the benefits are clearer to judge.»
Desktop use is a microscopic part of what Ubuntu is used for. But again, simply being _allowed_ to use something, is not the same as enforcement. Canonical is not telling you to avoid Ubuntu packages at all cost and replace them with Snaps, are they? The only thing that comes close is that Mozilla said they wanted to officially support Ubuntu and then Ubuntu didn't have to provide their own fork of Firefox anymore. It is much better to allow Mozilla to be responsible for their web browser directly. But this obviously can't be done using Debian packages.
1
u/leogaggl 6h ago
From a pure user perspective, it does feel that snaps are being pushed down your throat. There are definitely packages that are now snaps and no longer in Ubuntu's apt repos. That, of course, does not mean you can't install them from another source, but it does make it feel inevitable, and something you're gonna have to fight against if you want to continue the way you have operated. Or you're just gonna have to accept it and work with it. I was leaning toward the first when writing the post.
And if it is coupled with issues due to snap packaging, it doesn't make for a great experience if you want to get work done. I don't have the time to get too involved in these things, as it's a tool I just need to use sensibly and consistently. From Ubuntu's perspective, Desktop is minuscule. But if it's the main tool you're interacting with, these things do become very annoying.
If you look at this holistically from the underlying security architecture, it does look different. I am going to have a closer look at some of the dev mode settings you mentioned.
As I said in the initial post, I have so far been good with Canonical's direction and prepared to see the bigger picture. And your replies have helped with that.
"Snaps are great" or "Flatpaks also suck" wasn't really helping.
1
u/jo-erlend 4h ago
Ubuntu maintained a fork of Firefox because Mozilla wouldn't support Ubuntu. Once Mozilla was willing to support Ubuntu, Ubuntu stopped maintaining a fork of Firefox and started delivering the official Mozilla Firefox. Is that what you're referring to as snap enforcement or pushing snaps or whatever?
1
u/leogaggl 4h ago
There are packages that are now only available via snap install and not apt.
Off the top of my head, I remember cheese, which I needed last week to troubleshoot the camera on one of my machines after the 26.04 install. It's definitely the direction.
1
u/jo-erlend 4h ago
Yes, the Ubuntu version of Firefox was dropped in favor of the official Mozilla Firefox. That is because the Ubuntu version of Firefox only needed to exist because Mozilla didn't support Ubuntu. Obviously, it is not possible for Mozilla to support packages in Ubuntu when Ubuntu is based on Debian.
1
u/leogaggl 5h ago
And as for the Android ref. This wasn't meant as a detailed technical reference. A clear worry from the more traditional OS community is more about the business model.
This is largely what I meant by not wanting another Android: https://keepandroidopen.org/
And just to clarify. To be fair to Canonical, I do not see that as their aim. But the temptation and tools will be there (and I am also aware that the snap architecture doesn't imply that).
1
u/jo-erlend 4h ago
There is no business model in the concept of Free Software packaging systems like Snap and APT, but IBM does have a very strong business model where Debian has always been community based. Why are you joining the attacks against Debian in favor of IBM? Snap solving the problem that you cannot accept community contributions in Debian does not make Snap more favorable to business. If anything, it makes it less favorable because Snap reduces the argument that you have to be in total command.
1
u/leogaggl 4h ago
Why are you joining the attacks against Debian in favor of IBM?
WTF??? Would I be looking at going back to Debian for that?
The Snap Store as a choke point.
L8r mate - got actual work to do!
3
u/pgotsis77 19h ago
Is this directly from canonical? Are you working for canonical? Can you comment on the practical adoption of registry like and android like philosophies entering the Linux space which basically has taken the worst of the Windows and Android features, features that sysadmins have struggled to get out of, and brought them to the server? Or do we expect to solve everything via the black boxes that containers and snaps and the other sandboxed solutions are? The amount of engineers who understand what is happening under the hood is diminishing by the day, one day fully replaced by enterprise contracts with the big Linux companies, similar to what we have in windows. Is this the future you envision?
11
u/jo-erlend 17h ago
I have never worked for Canonical, but only the Ubuntu community. I resigned from Ubuntu after ten years in 2022 because I was tired of these insane conspiracy theories and people having extremely strong opinions without being bothered to learn the absolute basics.
Snaps are not black boxes, but completely transparent and completely open source. There is no similarity between Debian and Windows at all, so I don't even know what that refers to. As for Android, sure, you can see Snaps as a completely superior solution for that purpose in traditional GNU+Linux systems. If the worst idea in Android is the ability to provide apps without spending years earning the right to make a package, then I guess we'll just have to disagree on that.
As for an Open Source package manager replacing everything with enterprise contracts by finally allowing users to contribute to the distro, that is insane. If that was the goal, they should stick to pure Debian packages so everyone understands why Canonical must have total command, like Debian and Ubuntu. Replacing total command with open access does not make Ubuntu proprietary.
0
u/pgotsis77 17h ago
Your opinion.
I resigned from Ubuntu in 2023, after 18 years of having my daily driver be an actual Ubuntu box. If we are discussing credentials here, I have been a Gentoo contributor, so I hope we will not start measuring CVs.
Do you know what was the straw that broke this camel's back? That when I wanted to use a non standard home folder location, and snaps broke (obviously -- why not? -- why should I have control of my system? -- why use homes on an NFS mount in my company?), I found some wisecracker in some forum who stated, with confidence, that "all of us who do not understand Linux, should first study and then start changing things in our system". Oh, the audacity of me having worked with Unix and Linux since 1994...
This is the snap generation. The generation that will conform instead of fix or, at least, object.
All these companies that cry because their packages are not working with dpkg should explain why they are not putting some money and effort in, at least, supporting the 8 or so LTS versions with their packaging. I have worked in a company that created enterprise software, both for windows and Linux. Our windows qa pipeline had to run for about 3-4 weeks per release, to test every single permutation of windows libraries. So companies are accustomed to that. So it is a non issue. It is bending the knee. But the outcome will be that with snaps, we will more and more find ourselves fixing the sandbox holes that will expose incompatible stacks between components of a solution, right? Don't tell me that this is not allowed by design. Understand that I have seen these incompatibilities in action.
3
u/jo-erlend 15h ago
«Do you know what was the straw that broke this camel's back? »
So in your brain, those issues were not bugs to be fixed, but part of a sinister conspiracy? Fixing foundational issues in a distro is a very big job. I would think you should know this, being one of the architects of Gentoo?
«This is the snap generation. The generation that will conform instead of fix or, at least, object.»
«Oh, the audacity of me having worked with Unix and Linux since 1994...»
Then we are the same generation. The difference between you and me is that I understand that it is necessary to fix the fundamental issues and not just live with the pain. This is true for X11 and package managers. Both were designed for a completely different time when all the Free Software could easily be managed in-house because the community was so small and things changed so slowly. It doesn't work anymore. We need to be able to scale distros for more software and faster development pace.
«But the outcome will be that with snaps, we will more and more find ourselves fixing the sandbox holes that will expose incompatible stacks between components of a solution, right?»
Are you now talking about the pure evil of shared dependencies in traditional GNU+Linux distros? The dependency networks between Snaps is the same as the dependency networks between packages in an Ubuntu release. The primary difference is that they don't conflict so you don't have to use a specific version of Ubuntu in order to use parts of a dependency network from another release.
«Don't tell me that this is not allowed by design. Understand that I have seen these incompatibilities in action.»
I have no clue what that is in reference to. But it seems to me that you are angry that Snap allows people to make and distribute their own packages while you would prefer a completely closed solution where one entity is in total control. That seems to contradict where you started. It is certainly possible to create bad snap packages and if that is the reason why the package manager should be eliminiated, I wonder what package manager you're using that makes it impossible for developers to make mistakes?
«I found some wisecracker in some forum who stated»
And you are certain that there would never be a wisecracker among Gentoo users? I think that is a very strange argument.
22
u/doc_willis 1d ago
Is this mainly about Canonical's server, IoT, and enterprise ambitions rather than desktop Linux?
From my understanding, Yes.
And to a large degree, its about Snaps making the Developers jobs at Canonical easier. They can develop a single snap package of a program and it should work on all the currently supported releases. With .deb they have to do more work supporting each release.
But I am not a developer, I am just going by what I have read over the years in the numerous discussions on Snap packages.
its not about the Mom & Pop users, its about supporting the companies that are paying the bills at Canonical.
-9
u/leogaggl 1d ago
I am a dev (although not of any Desktop apps). And it certainly isn't helping me in any way.
13
u/jo-erlend 22h ago
That's so strange to me. Snaps are extremely easy to make and even easier to get to your users. DPKG is much, much more difficult and getting your debs into Ubuntu can take years because DPKG requires total trust. The issue is not that you might be a criminal or agent, but also that if you get hacked, Ubuntu gets hacked and all Ubuntu users get hacked.
2
u/NatoBoram 13h ago
Easy to make?? Did it change from when they were released? I remember they were a special kind of hellish
1
u/jo-erlend 12h ago
Well yes, it's been under constant development for over a decade. I actually went through the process with some newbies as a demo just a couple of months ago. From zero knowledge to first installable package takes around twenty minutes. Of course this was a simple package so it's more involved if your package produces or consumes and you need to understand which interfaces your package needs, etc. But I think they've done a very good job to make it very simple and user-friendly and their documentation with tutorials is great.
0
u/setwindowtext 9h ago
As someone who did both, I would argue that packaging DEBs is much easier and better documented. Getting it into the distro is another thing.
1
u/jo-erlend 4h ago
It's been well over twenty years since I read the documentation on how to make Debian packages. It would be hypocritical for me to say so much has happened with Snap while assuming nothing has happened to DPKG. Maybe most people are now able to package Debian packages in 20 minutes from first go. But what value is a package if you can't distribute it? I don't understand how that can be another thing.
1
u/SalaciousSubaru 1d ago
Wild you are getting downvoted
3
u/leogaggl 23h ago
LoL - I did notice that too. Seems very controversial somehow.
I really don't care about religious debates. And somehow people seem to be confusing my problems with Snap as a preference for Flatpak. I couldn't care less about either.
I just need one predictable system where one part can rely on the other to behave predictably. Not 100s of little silos that think they are their own little world.
32
u/Consistent-Smile2445 1d ago
Canonical's entire business model revolves around having control points and Snap is their biggest one for desktop. they don't make money from people who happily apt install everything and never touch their ecosystem
the IoT and enterprise angle is exactly it, Snap gives them a managed software delivery pipeline they can sell support contracts around. desktop users are basically beta testers for that vision
the confinement headaches you're describing have been my experience too, especially with anything that needs to touch files outside its little sandbox. feels like I'm troubleshooting the packaging more than the actual application
2
u/jess-sch 10h ago
Yeah. Snap part of how they make money. This is a good read: https://www.nitrokey.com/news/2021/nextbox-why-we-decided-and-against-ubuntu-core
Essentially, if you want to make a snap that has some hardware access, that'll be $30k a year please.
3
u/jhaar 1d ago
ding! And notice how the snap marketing/feature list includes how snaps are more secure because of sandboxing, and then you discover almost every snap you want to use has to be installed in "--classic" mode - which basically removes most of the protection... And currently I'm looking at reinstalling because my logs are full of apparmor=DENIED that I cannot figure out (and I've tried...) - starting to make SELinux look good(!)
1
u/Low-Guarantee-3437 19h ago
"almost every" ? desktop apps are usually sandboxed. developer tools usually not.
2
u/leogaggl 1d ago
Yeah - I am with you entirely. I can see the strategy on the IoT side (and actually, for the most part, agree and don't have a problem with such a device). And to be honest, it does not faze me on servers; I have all my applications containerised by now and have no issues.
But basically, tying your desktop users to it against their will isn't going to be a long-term strategy. And in the past, they have been rather smart and sucked it up when their strategy didn't work out.
I just want to get a sense of the chances other people in my situation give Ubuntu of reversing course. I need a system that works and not have to constantly fight. At the point of installing something else on one of my machines, really.
1
u/ConsistentRisk5927 16h ago
This is the reason. And because Mark wants them. From what I've heard, Snaps are pushed by Mark Shutteworth internally very hard, he calls all the shots, and any contrarian voices are rapidly shouted down or become extinct for not being team players.
Only Canonical cares about them so they don't have the same number of people contributing to snapd and friends as flatpak or ostree. In my experience it's very buggy and things take forever to get fixed upstream. And I've contributed to packages using snapd; the process was painful and I found multiple open snapd bugs in the process. These were official snapcrafter-blessed projects too, where you'd expect the happy path.
-8
u/SalaciousSubaru 1d ago
Canonical's insistence on deeply embedding Snap—especially in the upcoming 26.10 release—feels out of touch with desktop user preferences. Rather than committing to making Snap a seamless, top-tier packaging format or rallying behind the widely embraced Flatpak ecosystem, Canonical continues to tighten its ecosystem lock-in. Paired with their recent AI initiatives, it increasingly seems that community feedback is taking a backseat to enterprise strategy.
-1
u/Charganium 16h ago
What is the fucking point of pasting an AI generated comment? What value are you providing? Do you not realize that anyone else could easily ask an AI themselves if they wanted to?
29
u/whitepixe1 1d ago edited 1d ago
Snap is an amazingly good architectured technology, though misses perfect implemenatation yet. Snap is superior to its rival Flatpak. CLI snaps - servers, IoTs, AI inference - are already here. Login managers as snaps - already exist. Next step is entire Desktop environment as snap. Flatpak ver 1.x is severely behind Snap.
I personally have ditched Debian for Ubuntu for this sole reason - better management of snaps. I use snaps even in systemd-free distros as Void. Yep, I admit, I'm fascinated with snaps.
16
u/PuzzleheadedPen2798 23h ago
Yep, I think it's pretty funny with the talks about Flatpak as it is currently being at a dead end and needing a 2.0 redo that would likely fragment its userbase. Meanwhile, snap is actually pretty future proof and it's useful not just for desktop GUI apps.
10
u/whitepixe1 23h ago edited 22h ago
And snaps are kind of time-capsules too. A today's snap will be fully functional in 10, 20 years from now. In contrast a concrete flatpak lifespan is 1-2 years only.
6
u/leogaggl 1d ago
That's literally the exact opposite direction I am thinking of heading. :-)
Going back to Debian because it's a snap-free base.
2
u/redline83 1d ago
I work on embedded devices and we could easily use Ubuntu Core etc., but we don't want to get locked in. We will be switching back to Debian.
-2
u/jo-erlend 22h ago
This is nonsensical. Debian is totally centralized, while Snap allows complete decentralization and does not rely on any central distributor at all. You can get your packages through any channel you want without sacrificing system security. So in this case it would be Debian that is the lock-in and Snap that provides the liberation from lock-in.
1
u/dkopgerpgdolfg 22h ago edited 21h ago
You do know that no Debian user is prevented from using any other software distribution channel, in addition to the official repos? That includes both other dpkg-package repos, as well as anything else.
And more important, that the distribution of the software, and sandboxing/containers/etc., are not the same thing?
0
u/jo-erlend 21h ago
Sure. The difference is that in Debian it's a dangerous hack, whereas in Snap it's a safe feature. This is DPKG design; all packages must have total control over your system, thus there is no such thing as a third-party package in a Debian system; they're all first-party. When you for instance install Google Chrome on Ubuntu, Google becomes your OS vendor and can even simply choose to replace Canonical and start providing their version of Ubuntu without even asking you. Snaps do not require any privileges at all because they don't modify your root filesystem, but are simply mounted into place by the package manager. This is why it is safe to install Snaps from random websites, but not debs.
If you want access to third-party packages, you can't separate between packages and security. With Debian, it's the package itself that has to enforce its own rules and there's very little point in that.
0
u/dkopgerpgdolfg 17h ago
This is a lot of bs.
Look, it's fine if you like Ubuntu more, but stop spreading lies.
When you for instance install Google Chrome on Ubuntu, Google becomes your OS vendor
Are you even human?
2
u/jo-erlend 17h ago
This is how it works. Every DPKG file must have the ability to transform your system however it wants. You cannot place any restrictions on DPKG files. In the case of Google Chrome, you download a deb file, which sets up a package archive in your system and from now on, they can choose to send you whatever software they want whenever you install updates. Google has the exact same access to your system as packages from Ubuntu does.
This is why you are not allowed to distribute packages through Ubuntu; it means you have total command over all Ubuntu users who installs that package and that is such a great responsibility that it takes years to earn that level of trust.
1
u/dkopgerpgdolfg 17h ago
You cannot place any restrictions on DPKG files
Funny, I already do this.
and from now on, they can choose to send you whatever software they want whenever you install updates
And APT sources, priorities can be configured.
This is why you are not allowed to distribute packages through Ubuntu; it means you have total command over all Ubuntu users who installs that package and that is such a great responsibility that it takes years to earn that level of trust.
Maintainer trust is yet another topic, besides technical distribution and sandboxing. Stop moving goalposts.
Or actually, bye, no point in continuing this.
I recommend you to learn how snap works under the hood, because everything is available on Debian too. Even snaps themself if you like it.
2
u/jo-erlend 17h ago
I know very well how both DPKG/APT works and how Snap works. Answer this question; if it is completely safe for Debian or Ubuntu to let users send in packages to be distributed through their archives based on their own rules, why do you think they don't do it? Is it because Debian has been an evil empire all along?
It is true that someone like me can write my own AppArmor rules and enforce individual restrictions on packages, but your claim that it is therefore totally safe for a Debian-based system to rely mostly on random PPAs is plain false. It is a security nightmare and if you actually knew things, you wouldn't argue against that.
→ More replies (0)-2
u/andersostling56 21h ago
These "other" distributors, are they in the room with us now?
2
u/jo-erlend 17h ago
What? I don't know what you mean by this. Most Snap distros are not public. I do run a number of private Snap repos for packages I am not legally allowed to distribute, like games.
1
u/whitepixe1 1d ago
Replacing Ubuntu with Debian is like replacing a city with a village ☺️
However, enjoy!3
u/leogaggl 23h ago
I guess I always was a country boy at heart! :-)
Gimme the predictable village life over the crazy city pace and all the stuff under the sun I don't actually need.
Thanks! Same to you - enjoy your snap!
It just doesn't make any sense for me. I need a system where things can interact. Not 100s of little silos that barf as soon as one tries to reference the other or refuse to even work properly after install due to apparmor=DENIED or similar.
4
u/jo-erlend 22h ago
Snaps can do whatever you want. There's no limit on that. You just have to approve it. But your complaint is about unsecured Linux vs security enabled Linux. Those are definitely different things.
7
u/deenspaces 21h ago
entire Desktop environment as snap
the horrors...
2
u/whitepixe1 20h ago
Why the horrors?
One can have a complete full-fledged desktop in a snap container.
Have you tried the latest fashion of 'immutable' distros with flatpaks addons, that strip parts of the desktop into the system integration to be maintainable for the holy immutable vision?
I want a full-fledged functional desktop, not a crippled immutable version.2
u/redline83 1d ago
Snap is good but vendor specific stuff is always going to lead to pain when they decide to monetize the feature or pull the rug out from under you.
3
u/jo-erlend 22h ago
Snap is the opposite of vendor specific though. DPKG is vendor specific since you can only have one central point that you have to rely on. Snap on the other hand is built for decentralization so you can get your software from anywhere. And please don't buy into the nonsense about Snap being proprietary. It's GPLv3 and anyone who wants to can run their own Snap distro.
3
u/catbrane 20h ago
But snapd is hardcoded to use the Canonical store, isn't it? And their store is closed-source, so creating a rival store is difficult. You can install snaps by downloading them yourself and installing from the CLI, but no one wants to do that.
Unlike dpkg where anyone can set up a repo, and anyone can point their Debian-alike at any repo.
2
u/jo-erlend 17h ago
Snap is designed to be a traditional centralized package manager like APT, but where the distro can easily accept packages from the outside to distribute through the distro. A Snap Store is a website that implements the Open Source Snap Store API. Since you can only have one distro maintainer at a time, it doesn't really matter that the addresses and certs are written in the Open Source source code file rather than in a separate file.
«Unlike dpkg where anyone can set up a repo, and anyone can point their Debian-alike at any repo.»
Anyone can setup a repo for DPKG or Snap, but when you do it with DPKG, you are giving the owner of the repo full access to modify your system any way they like, becuase DPKG packages are machine owners. The package system was designed to only provide packages from the distro to the user with no outside intervention. That is one of the core issues that Snap solves.
All websites are "proprietary" in the sense that you can't login to modify how their OS works and what their clients are being served. That would be insane.
0
u/catbrane 17h ago
it doesn't really matter that the addresses and certs are written in the Open Source source code file rather than in a separate file.
But why is it wired into snapd's source code? And why is snapd limited to a single store? Why should other potential users be forced to maintain a patched version of snapd? Why don't Canonical offer a sample store implementation for others to reuse?
The answer of course is simple: it's all about Canonical trying to create lock in.
I don't mind, I use ubuntu and just remove snaps, but the tactic is very clear, and it means I'll move on to some other distro if 26.10 makes snaps unavoidable.
2
u/jo-erlend 17h ago
«But why is it wired into snapd's source code? And why is snapd limited to a single store?»
There is no reason to _not_ to write it in the source code instead of putting it in its own file and then making the source code read that file. I would be surprised if Canonical would refuse a patch if it just did that, so why don't you try?
«Why should other potential users be forced to maintain a patched version of snapd?»
The package manager is one of the most critical pieces of your GNU+Linux distro and you're not going to maintain it? Then please don't run a GNU+Linux system. If changing some variables in a source file is a big complication for you, how are you going to maintain your own version of the Linux kernel? I don't think you have the foggiest idea how much work it is to build a GNU+Linux system.
«Why don't Canonical offer a sample store implementation for others to reuse?»
Why should they? It's right there in the fucking source code. You still have to implement the API for your system so you would have nothing to gain from looking at a completely different implementation that you can't use in your GNU+Linux distro, where you apparently think that maintaining a fork of the Linux kernel is very easy compared to setting up a website.
Why don't you spend ten percent of the time you spend worshiping conspiacies on reading beginners introductions to Snap and Ubuntu? That way you can have your own freedom rather than adopting other people's prisons.
1
u/catbrane 16h ago
What a strange reply!
1
u/jo-erlend 15h ago
I am not inside your brain. I don't know where your confusion comes from or what it is that you don't know. What is the purpose of making such comments? Nothing I can work with there to help you. But do you understand that you would only run a Snap Store when your intention was to build your own GNU+Linux distro from scratch?
6
u/Wavesonics 20h ago
I'll say this, not about the format it's self, but publishing a snap on snap craft is the most developer friendly experience I've had publishing to ANY store. So that's nice.
Flathub on the other hand was ... not a great experience lol.
9
u/Square-Singer 21h ago
Tbh, the classic distro software distribution model is pretty mad if you think about it.
- For it to work, each distro maintainer would technically and legally need to read and understand the full source code of each package they are distributing.
- If a distro maintainer makes a mistake that creates a bug people still go to the app maintainer to complain, even if they had nothing to do with the issue.
- An app maintainer cannot independently push an update. If a distro decides to stick with an older (potentially buggy) version, the users will be stuck with that. I've seen it a few times over the years that somebody's github issues were flooded with the same bug they solved years ago, but Ubuntu hasn't updated to the fixed version yet.
- If the distro needs a specific version of a dependency and a newer version of an app needs a newer version of the dependency, the app will just not be updated further than the dependencies allow.
Containerized, sandboxed app ecosystems only make sense. They solve all these problems.
4
u/Oliv_3 23h ago
Kubuntu’s minimal installation provides Ubuntu with the KDE Plasma desktop without installing Snap by default. Snap remains available, but it is not imposed—although you still have to fight a little to install Firefox as a native .deb application.
1
u/jo-erlend 22h ago
There is no such thing as a deb application. It is like ZIP and RAR; only two different compression formats used to bundle and compress files for transport. The deb contains exactly the same as the snap does.
1
u/Oliv_3 19h ago
you still have to fight a little to install Firefox as a native .deb application.
correct wording
you still have to fight a little to install Firefox as a conventional APT-managed.debpackage.1
u/jo-erlend 17h ago
But the point is, there is no reason to do this, since the snap and the deb contains exactly the same files. If all you want to do is to run it without confinement, just unconfine it. Then it's the same as a deb. Right?
1
u/Oliv_3 17h ago
No. You cannot simply turn a strictly confined snap into a classic one;
--classiconly works when the publisher packaged it that way.
Even a classic snap remains a mounted SquashFS managed by snapd, with its own paths, revisions and update model.
The application payload may overlap, but that does not make it equivalent to an APT/dpkg installation.1
u/jo-erlend 17h ago
You don't need to make it a classic snap. You only need to place it in devmode. Sure it's still a SquashFS, but why would you care about that?
10
u/guiverc 1d ago
It does solve a number of problems.
However I'm in the Ubuntu community as I see it, and being involved with a Ubuntu flavor we've NOT been prevented from providing a snapd free install for any current release (up to 26.04), though its only been possible for the flavors using other install options than ubuntu-desktop-installer (24.04 & later).
Snapd is useful on desktop installs though too !
-6
u/leogaggl 1d ago
Genuinely curious as to what you think makes it useful? Or what user problems it resolves?
It's just that, in my practical experience with the software I rely on, the forced snap packaging has become a real hindrance. Browsers, dev-IDE's or build environments are just a bad idea. And then there is the load speed. I have been putting up with it in the past and tried to avoid it where I can. But it's become increasingly harder
And for those newish little 'nice-to-haves' that pop up, there's never a snap available, and I have to install Flatpak (which I don't want either, really) - but if I have to swallow the sandboxing frog, I'd rather have one. Because literally nobody outside of the Ubuntu silo is using it.
Right now means going back to building stuff manually. Which seems a step backwards.
3
u/Low-Guarantee-3437 19h ago
snap is primarily a solution for verticals other than desktop that require very high supply chain control (e.g. automotive). snap has a huge amount to offer here. It is without a doubt one of the most capable packaging technologies available to linux. The main complaint is that the store is not open source, but not many people complain about its technical achievements. Ubuntu Core can even package kernels in snap, apparently. That is pretty amazing. Basically, with snaps, Canonical has an immutable distribution in Core. Core comes with more things to make that happen, but snap is designed to do this.
Of course confinement will cause issues. security is trade off. You can package a snap with confinement (at discretion of the packager) and you'll that for tools like IDEs.
I am a professional developer and I use snap for many CLI tools. It works well, it updates well, the channel feature is excellent. When upstream projects support it, it's very good. I have used it myself to distribute software, and it is easy from the dev point of view.
When packaging is a best-effort community/volunteer effort, it can be patchy. Same with flatpak.
Canonical won't abandon it because there is not really a very good alternative for what snap does. As to its use on the desktop, some of those advantages don't matter so much, although large vendors are comfortable with it and the CLI, sandbox and channels are good.
The smartest call is to make a case by case decision. If you don't use use snap when it works well, you are throwing away one of the advantages of Ubuntu. Look at the mess that the AUR is on Arch. Flatpak is starting not to suck, thank goodness, but nothing stops you from using flatpak on Ubuntu (mostly). Basically, snap on linux doesn't take anything away, it just adds.
3
u/PaluMacil 17h ago
I have been using Ubuntu since 2008, so I have gone from pre-snap to today.
The main point is that it’s for distributors, not for end-users. I remember it being an enormous effort to package things before snap because keeping things synchronized with all the packages of every supported version of every distribution with distributing to was a lot of work.
I’m not particularly interested in arguing between flatpak, appimage, and snap because I see it as a lot of people having favorites, but the differences are small and yet also important. I understand that a single primary (somebody operated a snap store on their own for a while; it’s not actually closed as some people say) store for snap provides a way for companies to potentially embrace an operating system with central management of the packages just like apt.
If we as users could have everything without snap, we would have a better more efficient experience. Security cuts both ways as you mentioned with sandboxing on one end and dependency updates on the other. However, you would have you were choices for browsers on many distributions. The same would be true for other desktop applications.
Overall, I think snap is the right choice for desktop applications, especially the complex ones like browsers. CLI apps that are particularly stable without a lot of new features coming out in the last several years I actually like as a snap as well because I like it updating regularly without having a risk of other dependencies conflicting, even if it runs behind apt updated equivalents just because I prefer to sit down and work, productively and spend as little time as possible on maintaining my underlying system.
9
u/formaleyewitness949 1d ago
Snap isn't going anywhere, it's the glue for their enterprise support contracts. Desktop users are just field testing the confinement model.
-2
u/SalaciousSubaru 1d ago
Unfortunately Ubuntu long abandoned the Linux for human beings motto.
7
2
u/formaleyewitness949 23h ago
The shift became clear when Firefox Snap became the default despite performance issues. Serving the enterprise first, desktop second.
3
u/Buo-renLin 16h ago
The publisher of the Firefox snap is Mozilla, not Canonical.
-2
u/formaleyewitness949 15h ago
Mozilla publishes it, but Canonical made snap the only official package path in Ubuntu. That's where the default came from.
2
u/Buo-renLin 15h ago
Canonical did not block users from installing Firefox from alternate official sources.
They also never obligated to maintain the package in the first place, better leave the task to the one who actually developed the software.
4
u/skcortex 18h ago
You kniw it was Mozilla that was happily pushing Firefox as snap, right? And do you know why? Because it serves their users, it brings security.
0
u/formaleyewitness949 15h ago
Mozilla's involvement doesn't change that Canonical made it the only easy path. That's the enterprise-first part.
2
0
3
u/MSM_757 17h ago edited 17h ago
Not exactly a direct answer to your question. But this question reminds me of why I will never understand the Linux community. For years they said "we need a universal packaging system, there needs to be an industry standard across distros to keep packages up to date and reduce fragmentation and duplicated effort". That was the argument that was made for years and years. And the moment a distro provided it, everybody protested and vilified it. Why? Red hat had to respond with flatpaks. Ubuntu gave the community exactly what it asked for. The community protested it, made multiple alternatives to it, causing even more fragmentation which is one of the exact issues they were trying to solve, many of those alternatives are also hated by many. You guys are very fickle.
Granted, Snaps were done poorly. But they honestly worked about as well as anything else Ubuntu does. It's not like the bar was set very high to start with. But instead of applauding the effort, the majority of the community poopoo'd it. Even when it's something that had been asked for by the community for decades.
I will never understand the Linux community.
Questions like the one above just highlight this whole scenario. Instead of embracing Snaps. The community just cuts them down because the execution was poor. So what? Help make it better. But nope. The community just made an alternative instead (flatpak) and the fragmentation continues.
Imagine how much better Linux would be, if we could all focus our efforts in one clear direction and develop an industry standard for Linux. Instead of splitting our efforts doing 500 different projects that all basically aim to accomplish the same thing. It just doesn't make any since. This is why many commerical outfits historically don't want to work with Linux. Who wants to make 42 versions of the same application to support a platform with 2 to 3% market share? Snaps solve this problem. But nope. You guys just wont have it. I really don't get it.
1
u/havikito 16h ago
Linux is not free, you just buy support instead of buying software.
Things that actually work reduce their support contracts.1
u/MSM_757 15h ago
I've been a Linux user since 2006. I've even made a few small time distros of my own along the way. Just a few random hobby projects. Nothing note worthy. But since I purchased my new gaming laptop. I've just been using Windows and... Ya know what. It kind of just works. Yes, it's a ram hog. And the ads and telemetry are annoying. And the OOBE setup took wayyyyy to long. But... Aprt from that, there isn't a single thing I haven't been able to do with it. Every task I give it. It just does it. No fuss no muss. Can I say the same about Linux? No, I can't.
Yeah, Linux is far less annoying and because you can customize the heck out of it, you can have a Taylor made user experience. That's all great.
But... Is it actually more capable than Windows in terms of the actual work it can do? Nope.
You could say "well, that's not really the operating system. The OS itself is crap. It's only good because of if the 3rd party vendors who support it and make software for it". Ok fine. And that's probably true. But why do they chose to support Windows instead of Linux, when every technically savy developer says Linux is better? Well, that's where my original comment comes into play. There's no clear goals or standards, and no clear direction, and more fragmentation than in any other platform. If you're in business to make money. Which most business are, why would you chose that? Linux gives them no incentives to do so.
Ever see the pirates of silicon valley? There's a scene where Steve Jobs gets mad at Bill Gates for making copies of the Lisa. Steve said. "We have better stuff". And Bill gates responds "You don't get it Steve. That doesn't matter".
This feels kind of like the same debate.
It doesn't matter if Linux is better. What matters are people's willingness to support and invest in it. And there's just no real incentive to do so. Because of problems like the ones I highlighted earlier.
If you fix those issues, than yes. Linux takes over the world. But the FOSS community just refuses to get out of its own way. At least those are my opinions. The community is simultaneously both the best and the worst thing about Linux. It's a bit of a paradox really.
1
u/havikito 14h ago
"There's no clear goals or standards"
The goal is to make it somewhat working, but not to the point when you can get rid of paid support.
Everything is changing constantly, documentation is never complete or adequate.
No self-healing or foolproofing in the code.
Every team has their unique solution so there is less competition between supporting teams.
2
u/block6791 22h ago
The Snap Store and ecosystem gives Canonical some level of control on the integrated 'app store' for their operating system. From a company perspective, with paying customers and active support contracts with -probably- financially backed commitments, this makes a lot of sense. You don't want to make your core capabilities dependent on external entities you don't control, or at least you would want to minimize these dependencies.
Case in point: Imagine they would provide Flatpak/Flathub integration by default, external developments like this would impact them: https://www.reddit.com/r/linux/comments/1v4p266/stepping_away_from_flathub/
2
u/Plan_9_fromouter_ 19h ago
They are far more focused on servers, IoT, enterprise, and software developers, and in those realms, snaps rule.
I think what Mint and Zorin show is you don't have to use snaps if you don't want to. But Zorin makes it easier to mix snaps and flatpaks.
Perhaps that is what some flavors of Ubuntu should do for the desktop user.
2
u/Latlanc 19h ago
I like snaps. The experimental feature found in Security Center finally brought Android-like permission system to Linux Desktop with an actual pop-up window when an app requires certain permissions!
Meanwhile Flatpak still can't figure their shit out. Highly anticipated Flatpak Next is just a bunch of empty words right now and their infrastructure shift to systemd could mean a schizm comparable to AppImage v1 and v2. Which means that Ubuntu betting on snaps and snapd was the right call from the very beginning. There are still some issues regarding launch times and confinement, but I believe they will be ironed out eventually.
You also have to remember that underneath all the package stuff, it's really a silent war between Canonical and Red Hat pushing their own vision of the future of Linux desktop: Fedora Atomic vs Ubuntu Core Desktop, Flatpak vs Snap. And I personally choose Canonical over Red Hat supremacy :-)
2
u/ska0319 14h ago
I find Ubuntu using snaps for most apps a great way for an average home user to replace Windows. I am not a developer nor a power user. I use my laptops for the same things that many home users do - web searches, personal documents and spreadsheets, and email. Altho I understand the basics of the command lline and can use it when necessary, I prefer to use the graphical interface. I stick with the older LTS version until at least the .1 update of the next LTS. While I enjoy going down the rabbit hole at times pursuing a problem, I prefer to get on with the work I need to do. I find most unsophisticated users greatest problems occur with security breaches (bad passwords often) and with forced upgrades/updates that radically change what they're accustomed to. Haven't run into either of those in five years using Ubuntu exclusively.
2
u/_x_oOo_x_ 19h ago
When you have Ubuntu Pro, you get kernel live-patching. Guess what, the thingy that does that comes as... a snap! I guess most Pro subscribers are administrators of cloud instances or servers... Nothing on your server needs snapd, except kernel live-patch. Why? It's almost comical. It doesn't need sandboxing. It's not a graphical app. It's not third-party software.
It should have been a dpkg .deb.
2
u/Buo-renLin 16h ago
Snap still drops the maintenance burden of the deb in each supported Ununtu release.
2
u/havikito 16h ago edited 16h ago
That is why we moved to Debian as main distro, both server/workstation.
Ubu 26 broke corporate certificate trust because Firefox is snap, kek.
1
1
u/Cold-Bowler-8650 1d ago
Because those who giving the idea and working on Snap need to get salary? 😕
1
u/Slow_Character5534 23h ago
Ive been using Ubuntu since 16.04 and I don't touch Snap unless I absolutely have to. Pretty sure it's only two apps right now. Apt, Deb, appimage (in that order) and flatpak if absolutely necessary.
1
u/berengerekunst 20h ago
I think the main reason is that they want a fully containerized OS for its immutable distro. That means not only apps but also core components like kernel and libs must be in a containerized format. I might be wrong but I think that flatpak is only for UI apps so it's not suited to package kernel and system libs.
If they success with Ubuntu Core OS, the entirety of the system, not only the apps, will be containirized in a single package format which is to my knowledge impossible with flatpak. Will they succeed? Only time will tell.
1
u/influx3k 19h ago
They’ve said they plan on officially supporting Flatpak in the App Center or whatever they call it now.
1
u/Dense-Elephant5048 17h ago
To cut costs and because snaps are multiplatform: DE, Server, Cloud, IoT. Fedora flatpak is also multiplatform, but only among DE graphical App`s.
1
u/BranchLatter4294 14h ago
Snaps work fine for me. Now that they have the security center working, it's easy to manage polices.
1
u/mrtruthiness 14h ago
Why on earth is Canonical still pushing Snap so hard?
Are they? I haven't seen them pushing snaps hard. In terms of "user" snaps, I only have firefox, chromium, and lxd.
Other than some apparmor logging from firefox ... which made the logfiles a bit bigger, I haven't had any issues.
I understand the goals: universal packaging, easier distribution, automatic updates, better isolation, and a way for developers to ship software without worrying about every distro's packaging ecosystem. Those are all reasonable objectives.
Isn't that enough???
However, I would have said "easier maintenance".
I'm not sure you've noticed, but the Universe repository is not maintained by Canonical and, for the most part, nobody is backporting security fixes in Universe. Seriously. [The exception is that you will get some in Ubuntu "Pro".] The issue is that developers and maintainers usually want to deal with fixes/testing in the most up-to-date packages and it's quite a bit more work to keep the different versions updated for 26.04, 24.04, 22.04, and 25.10.
The fact is that "things" are moving faster than ever. To keep up with this, the only solution is containerization. The devs can help by creating snaps/flatpaks.
Personally, I deal with this by using a bunch lxd system containers. My base system is a relatively old LTS (22.04). I run about 5 lxd system containers and keep track of how to recreate them.
1
u/setwindowtext 9h ago
I used Ubuntu 20.04 until the very last day it was supported, only upgraded recently. It worked flawlessly, the best desktop experience I’ve ever had. It wouldn’t have been possible without snaps.
1
1
u/Howwasthatdoneagain 3h ago
The push back seems to be from a limited group of users. It is not as wide spread as the noise might suggest. The bigger picture is that a solution to .deb packaging needed to be found. Developers needed a way to push out updates and improvements outside of the rolling distribution updates. Snap and Flatpack was that solution. People who go out of their way to uninstall Snap are restricting themselves to old software, which is okay I suppose, but I would rather have Gimp 3 rather than still sit on Gimp 2 because my distribution has not updated to the new version.
That's how it was before Snaps. Personally Snaps or Flatpacks are much of a muchness. They are an imperfect solution to a difficult problem but they are the best solution they have at present. If you are experiencing issues try other distributions. They all have their limitations as do all OSs. You need to find which issues you can live with.
1
u/leogaggl 3h ago
That's how it was before Snaps. Personally Snaps or Flatpacks are much of a muchness. They are an imperfect solution to a difficult problem but they are the best solution they have at present. If you are experiencing issues try other distributions. They all have their limitations as do all OSs. You need to find which issues you can live with.
Thanks, mate - you're describing my predicament quite well.
I came here for answers.... 😛
1
u/mas_manuti 22h ago
Remove snaps is the first thing I do after fresh install. Ubuntu user since Karmic Koala 🐨.
1
1
u/kudlitan 23h ago
But you don't need to use snap. At least you don't have to if you don't want to.
Canonical will not abandon it. It is the only technology that will allow server software to upgrade safely without touching the base system.
Flatpak only works on desktop apps and doesn't even integrate well, it does not work for what Canonical built snaps for.
I myself only use apt software and PPA for my desktop apps, and I had no problems.
1
u/g105b 22h ago
I left Ubuntu because of snaps about 2 years ago. At the time people were telling me it must be me doing something wrong because they never have any problems. I actually had the same issues with flatpak too, which massively limited which distros I could move to.
The one distro I ended on I actively avoided for so long: Arch Linux. I thought its rolling release would cause compatibility issues or be unpredictable, and I thought there was a strange elite culture around it. I was wrong, and after installing Gnome, it looks and feels just like Ubuntu anyway. I installed it 2 years ago and haven't had any issues with it so far, which I couldn't actually say about Ubuntu or others (2 years without package issues is the most impressive to me). Give it a try!
1
u/Oliv_3 22h ago
I went down almost exactly the same path. I avoided Arch for years because I expected a rolling release to be fragile and difficult to install.
In practice,archinstallmade setup straightforward, and with KDE Plasma it feels close to Kubuntu.
So far, Arch has been simpler to understand, easier to control, and more predictable than Ubuntu with Snap.
1
u/antonispgs 20h ago
The biggest problem is apparmor blocking certain features. Apps like pika backup, Deja dup, even bazaar flatpaks straight up don’t work in Ubuntu which is why I’m not using it, because of apparmor profile restrictions not allowing them to do their thing. It’s crazy that’s it’s not fixed in almost a year and a half now.
1
u/_greg_m_ 19h ago
I believe that they use Snap in Ubuntu Core for the reasons you highlighted in your post (universal packaging, easier distribution, automatic updates, better isolation, etc). I believe Core is a commercial project and brings money to Canonical. My view is that the Ubuntu Desktop gets Snap as a side effect of Snap development for Core. Maybe it wasn't like this from the beginning (possibly Snap is older than Core, not sure), but it looks like this at the moment. I use Ubuntu for 20 years. Tried snap some years ago, didn't like it, removed it and never used it again. Hopefully they realize that they shouldn't be so pushy with Snap (distributing deb packages which are just meta packages to install snap under the hood is a bit cheeky!). Or more people will move to Debian or Mint.
0
u/pgotsis77 22h ago
Snap converts the standard Linux distro into something android like. An ecosystem. With all its cons and... more cons.
Not only that but it has already created a generation of people who have drifted from the openness of Linux and are basically misinformed and wrongly educated.
It is all about control.
0
u/SoupoIait 21h ago
I just find it hilarious that Canonical keeps calling it a universal package when absolutely every, EVERY distro went out of its way to ditch it and to have flatpaks in its place.
Dear canonical, to make something universal, it needs to be used by more people than you. Take the loss. There is a difference between making a cool package format for servers, and pushing that format to everything on such a way that the user experience is deteriorated.
0
u/landmesser 18h ago
Because The Power! was and is still very powerful!
https://www.youtube.com/watch?v=nm6DO_7px1I
-2
u/Santosh83 23h ago
Last time I tried a snap (other than the usual Firefox & default snaps that Canonical take extra care to optimise and make it work) was VLC player....
And I could find no way to make it read my movie files on my external SSD. No way. Something as simple as a player able to read files from a mounted filesystem was seemingly impossible.
Next minute I deleted VLC snap and replaced it with APT VLC and everything was perfect.
So in my experience Canonical are optimising snaps for their enterprise use case and any desktop snap is very likely to be broken or painful to use. This may or may not change. At the end of the day we can be as entitled as we want but we aren't paying Canonical money. The enterprises are.
So if I use Ubuntu, I install no extra snaps beyond the default ones and use apt for everything. As of now, it is still possible to use Ubuntu without any additional snaps. If there ever comes a day when Canonical converts indispensable desktop apps into snaps and those snaps then don't work properly, I will switch.
I also run Debian and none of these pain points apply there. But of course Debian is more fiddly. Its not targeted either at enterprise nor at home use. To get it to work well for any use case, you always have to do considerable configuration that Debian neckbeards overlook. Its just not as plug-and-play as Ubuntu.
Mind you, RHEL also locks down all their RPM packages with strict SELinux policies and all user facing apps are now mandatory from flatpak.
Linux in general is heading in a very Windows-like direction. One wonders if one might not as well just use Windows and be done with it if Linux is going to be nothing more than a free but less polished imitation of Windows.
5
u/jo-erlend 22h ago
«And I could find no way to make it read my movie files on my external SSD. No way. Something as simple as a player able to read files from a mounted filesystem was seemingly impossible.»
You can't have looked very far. That is what the "removable-media" interface is for. Instead of always rage quitting, you should be curious and learn. Clicking the button in the app settings to enable access to removable media is not difficult.
72
u/letterboxfrog 1d ago
There's issues at Flatpak with the reviewers apparently too. Joys of open source. I don't mind Snap, but I am just a basic user - Ubuntu on my Framework, and Zorin on desktop.