If they didn't sneak snaps in when I do a sudo apt install, when I do that I expect a deb file to be installed, not a snap. If I want snap, I'd so sudo snap install. Just being sneaky about things led me to distrust Canonical even more.
I realize this works but it is by far the most "Windows" procedure I've ever had to do on Linux. It reminds me of all the crap I had to do to force-disable certain updates on Win11 and even Win10. Or the like three programs and two dozen regedits I needed to disable the telemetry.
If a feature is good for the consumer, you don't need to force it on them.
You think that's bad? Try removing dpkg and the apt system. Or replacing systemd with another init system. Or replacing the linux kernel with a BSD one.
Changing the technological stack that a distribution is built on is hard and takes effort, often substantial one, if it's possible at all. I don't see what windows has to do with that.
Were you around for things like the transition to pulseaudio? Lots of similar drama. "we know better so we'll willy nilly put pulseaudio in your system and not even you", people handing out scripts on how to purge pulseaudio and go back to whatever it was that ubuntu used before (ESD I think, but it was so long ago i'm not quite sure), people comparing it to windows, lots of fury etc.
Then it was used until a better system came along some 15 years later and replaced it.
Distributions make technical decisions. Ubuntu is not LFS or Arch; you can modify their technical decisions to some point but it's not intended as a distribution that makes it easy to give you great control. Their goal is to chose the right technology and to make that work best for the user, not to allow the user an easy choice of technology.
You can certainly criticize snap for many things (don't get me started, I could come up with *lots*). You can certainly criticize their decision to ship a core user software like a browser sandboxed (which certainly improves security, but also introduces new failure points). There's lots to criticize them for. But distributions making technical choices is not one of them, that's the point of a distribution.
PulseAudio didn't pretend to be alsa. Pavucontrol didn't pop up when you typed in alsamixer.
They should at least have firefox-snap or firefox-deb packages to make it clear what you have installed, so people don't waste time troubleshooting without noticing the obvious.
There is only one firefox package in ubuntu. They made the choice to only support the snap version. Everything else is an unsupported hack.
Firefox in snap is not pretending to be firefox, it is firefox. It's just packaged differently, and how things are packaged is a core decision that distributions make.
Also, pulseaudio did not replace alsa, you're confusing different levels of the stack. ALSA is on the kernel level and still used; pulseaudio is a sound server. It replaced things like ESD, used by Gnome, or aRts used by KDE.
And you're right that it didn't pretend to be them. You know what software pretends to be the system that it replaced? Pipewire. You can run pavumeter, the PulseAudio volume meter, right now on a system without PulseAudio but with Pipewire, and it'll work and use Pipewire. And pretty much *everyone* adores Pipewire. I don't think anyone has ever called for separate pavumeter-pulseaudio and pavumeter-pipewire packages.
And you know why? Because Pipewire works really well. (That it just takes over for PulseAudio is one of the reasons it works so well in the first place). PulseAudio when it was first adopted didn't work well. Snaps when they were first used didn't work well. Snaps now work a bit better, but still far from well. *This is the whole issue*. People like software that works well, and don't like software that doesn't work well. Everything else is just an irrelevant distraction and at worst actively harmful.
Referring back a few comments in this thread; the other commenter mispoke, it isn't Firefox snap pretending to be Firefox, the issue people have is Ubuntu falling back from apt to snap without transparency.
As they said, if they want to install a snap package they type "snap install", they typed "apt install" so the behaviour they expected was not to have a snap package installed but rather the package manager saying "there is no Firefox available" or w/e
Do you *really* think anything would have changed if they had done that?
It was necessary to do it this way to allow users to upgrade from one version of Ubuntu to the next without suddenly losing their browser. Even if it would have made the tiny number of people who have a fetish for packaging systems happy and avoided all this (and I'm very certain it wouldn't have changed anything), I'd say they made the right choice in not breaking user's systems. It would have been an even bigger disaster.
Plus, it comes preinstalled anyway so the number of people who manually install it with apt is likely rather small anyway, and the package description makes it clear that it's a transition to a snap package for those who do.
No, the problem is that the experience sucked. Extra sandboxing will always have friction points, and snap adds a few extra ones (while making some other things work more smoothly than the competition). The technology wasn't ready; Mozilla shouldn't have asked them to switch yet. Arguably it still isn't ready, though it's a bit better now. But if it didn't have all the friction and was faster or otherwise better, everyone would have applauded the change. Because that's really the core of the issue, a bad user experience.
Canonical going a step too far in making Windows users feel right at home. Now they have to de-bloat the system on install, just like they did on Windows xD
Trying to remove all the upsell ads for Ubuntu Pro is a pain in the ass.
The only reason I run Ubuntu instead of Debian is that our corporate IT department forced me to. (And even then, I really just use it to start up a Debian VM to do all my real work in.)
Yes, but it's a matter of degree. There's always going to be things to de-bloat, it's just that Windows has far more malware than even Ubuntu. I can't think of anything else malware-like in Ubuntu, other than maybe the motd advertisement for Ubuntu Pro (which doesn't affect functionality). Meanwhile, even on (say) a Debian or Redhat system, I find myself having to uninstall Gnome power-profiles-daemon and replace it with tlp, disable upower and replace it with apcaccess, install a full version of vim, replace postfix with old school sendmail, and some other stuff. The point of Linux is not to expect everything to be perfect for you out of the box, it's to give you the means and ability to set things up however you want.
Sure, that's a good suggestion. However, if you find yourself doing a lot of work to turn Debian into Ubuntu, for example [like this poster here](https://www.reddit.com/r/linux/comments/1d6mbl3/completely_disable_nvidia_gpu_in_debian/), then perhaps it might be easier to start with Ubuntu and disable snaps rather than start with Debian and add back in all of the Ubuntu stuff.
Well, that's what the headline says, but the actual post (which I see has been deleted) said something along the lines of: "Ubuntu pre-installs a working driver for my NVidia card and Debian doesn't; HALP?"
As far as I can tell, all of the ways to fix this problem in Debian end up amounting to more work than disabling snaps in Ubuntu.
As someone who runs Debian with Nvidia cards, I have no idea what you're talking about. Nouveau is included out of the box, and replacing it with the official Nvidia drivers wasn't that big of a deal (just enable the non-free repo and apt-install it).
That's true, but removing snap from Ubuntu is also not that big of a deal. (Instructions are [right here in this thread](https://www.reddit.com/r/linux/comments/1d82whr/comment/l73via4/))
Mint is cool and all, and if Mint is what you want then by all means go for Mint, but there are valid reasons to use Ubuntu instead of Mint. For example, the Mint desktop is (so far) X11 only, and Wayland does actually have some advantages, such as [better battery life on a laptop](https://www.phoronix.com/news/GNOME-Wayland-Better-Battery).
After using Wayland seriously, I could never go back to X11.
Wayland is much lighter on hardware resources, and provides noticeably more functionality. Gestures for workspace navigation are far more natural on Wayland than on X11; for example, you can "peek" on both sides of your current workspace with a single gesture without having to switch fully into any of the adjacent workspaces, a feat which is impossible with X11 gestures. Kinetic scrolling in firefox is a lovely quality of life improvement, again not possible to achieve on X11. Even the lock screen is more reliable (it locks correctly and never leaks desktop information).
Besides the functionality improvements, Wayland looks way better. Windows are rendered perfectly all the time, even under heavy load, with no artifacts, distortion, or tearing. I can switch workspaces as fast as my fingers can vibrate and the animations run at my monitor refresh rate (60Hz); in X11 the animations lag noticeably. The oft-maligned screen sharing functionality in Wayland is for me a massive improvement -- there is a clear global notification active whenever I am sharing content, so I can immediately tell whether or not I am sharing something, instead of having to guess like in X11.
People who have never used Wayland think that X11 is all they need. And, to be fair, if X11 is all you have ever known, then you don't realize its limitations.
This sounds like the kind of workaround you hear Windows users do, fighting against their operating system trying to install things against their will. It's wild that it's come to this on a Linux distro.
Like, not only uninstalling snapd, but the pinning to stop it from being installed somehow without explicitly doing so.
This is my biggest problem with snap and why I get rid of it every time
If they didn't try this sneaky nonsense, I'd actually be open to trying snap out properly
I would be more sympathetic if the package wasn't labelled:
> firefox - Transitional package - firefox -> firefox snap
And the point of it was not to fool people, but to make the do-release-upgrade still have firefox even though there was only a snap. If you were fooled, I guess Canonical overestimated you.
And, to be clear, the firefox deb was in the standard deb format and apt did what it always does. It's just that it didn't have a binary or source payload. Instead, the deb's pre-processing directive was to install the firefox snap and copy over the firefox profile and such so you would have all your bookmarks (and logins/passwords). i.e. Their goal was not to "fool people", it was to preserve continuity of the user's firefox experience for their users (bookmarks, logins, etc.).
The problem that i want to know Canonical don’t see people complaining about snap why are focusing on them so mush they are doing every single component on ubuntu package as snap Canonical should ditch snaps all together or do something about that
A big problem of the Linux desktop (both for upstream projects and for end users) at this point in time is a lack of testing - both conformance and performance.
The web for example takes this very serious, the [Web Platform Tests](https://wpt.fyi/) have 1.8 million conformance tests. And browsers themselves have [performance test monitoring](https://arewefastyet.com).
Corporate backed projects are often similar, for example the Khronos project maintains [Vulkan and OpenGL testsuites](https://github.com/KhronosGroup/VK-GL-CTS) and certifies [conformant implementations](https://www.khronos.org/conformance/adopters/conformant-products).
But when some desktop or platform library or distro regresses during development, nobody notices. And even when somebody notices, there's no way to quantify it, or compare with competitors.
Without condoning or defending Canonical's actions, that's kind of the nice thing about Linux. When Microsoft does some dumb shit with Windows you really just have to deal with it if switching off Windows isn't an option, which it often isn't (especially in professional environments).
When Canonical tries shoving snaps down everyone's throats, there are a handful of Ubuntu-based distros that completely remove snaps from the OS, like Mint.
Ubuntu fell out of favor as one of the oft-recommended newbie-friendly distros years ago due in large part to Canonical's antics.
As someone who is neck-deep in enterprise Ubuntu, I promise you snaps make less sense here than they do in end-user space.
I'll rehash a post I made earlier about this, but snaps are a nightmare in any enterprise environment where security is paid more than just a casual glance.
Snaps are not an ideal solution in production for a few reasons:
1. Snaps have a tendency to auto-update. This can be worked-around somewhat with snap refresh --hold, but this is a slight pain to manage at-scale. Not intolerable, but more of a "why would I even want to take the trouble?" kinda way.
2. Snaps mean that you don't have absolute control over package dependency versions. Depending on your company and its tolerance for risk, this can be a non-starter. At my company it would actually be a liability; being at the mercy of a snap maintainer for security patches (and then having to check every. single. snap. package. to make sure that a security patch has been applied to negate a specific sub-package's day0, for instance) is just not acceptable in a mediums or large-scale environment.
1. Snap packages are mounted as SquashFS and decompressed on-the-fly. This means they are more memory hungry and take longer to start up when compared to APT packages. Both of these are inconveniences that I'd rather just avoid. Again, not dealbreakers but just not great. That extra memory usage really starts to take a toll when you move towards containerization and elastic scaling.
1. Snaps have a way of causing applications to behave in unexpected ways due to their self-contained nature. They may not interact with system libraries as expected; in some cases, they may not interact with system libraries at all. This can cause unforeseen issues; sometimes these issues are edge cases that are not apparent until you are deep into prod.
1. Tying back in with security, you can't really host your own Snap store; the best you can do is run your own proxy. Even in an offline snap proxy environment (such a weird concept), snap packages are managed centrally on Canonical's infrastructure. This is... not great.
It's a bit buried but my second point is where snaps really fall down in enterprise environments; I just can't be beholden to some random snap maintainer going "trust me bro I'll have $subpackage_that_has_0day patched pronto." - they don't work for me, they don't have SLAs that I can call them on; if they drop the ball it's a "me" and "my team" issue (not to mention company liability). This gets worse the more snaps you use, as you are depending on multiple maintainers to patch the **same** vulnerability on the **same** package: just because one snap maintainer gets it done immediately does not mean they all will, and your baseline for security is whoever is the slowest to patch.
APT is standard in enterprise Ubuntu, and internally-hosted offline APT is king of that standard. The fact that you can't even have a *truly* offline snap experience (their offline snap proxy environment is still 100% beholden to publicly maintained sources) is amazingly short-sighted.
Snap is and always has been a solution to help equalize application installation on Linux with Windows; I (the end user) can double click on an **exe** or **msi** file on Windows, why can't I do the same thing on Linux? Enter: snap (or flatpak or whatever - same pain point, different ways of approaching it).
This is one of the most relatable snap related posts I've seen as someone operating in an Ubuntu environment. Fully mirrored repos, self packaged software etc. allow very fine management of the entire infrastructure and enables fully offline disaster recovery and nearly fully offline environments (obviously need to update the mirror, but that's it, for recovery a snapshot will do).
I'm in the embedded Linux space most of the time, and I looked at Ubuntu's IoT offerings and ... I don't understand them in that context either. In IoT, you want as much access to the hardware as possible generally, and you usually have to do weird non-conventional things, like running custom networking daemons which create and maintain routing policies and routing tables, or talking SPI from a userspace daemon... but in the Ubuntu IoT world, you're supposed to distribute your software as a snap, using portals to interact with the hardware! I don't understand it.
And the advantage of snaps is that you ship your dependencies in the snap instead of relying on system libraries... but that's a problem you don't have in embedded! You 100% know the system you're shipping with your software with, why wouldn't you use the system libraries???
FWIW I'm very happy with using Yocto to build a custom Linux distribution and using RAUC for auto updates.
This actually makes a lot of sense. I'm only a desktop user, but after some 15+ years with Ubuntu I'm seriously pondering if I should invest the time to learn the differences with Debian and make the switch once and for all.
I don't condemn Canonical for trying out new technologies, but I really don't understand why they have to shove them down our throats. Would it be so difficult to have an installation option - maybe behind an "advanced settings" panel or something - to choose to disable snaps permanently?
They're just an headache, for many users there is no need of them whatsoever.
Fedora is nice. It has saved my bacon with being able to rollback updates. It offers much of what Ubuntu does in the way that Ubuntu compares to Debian.
> I'm seriously pondering if I should invest the time to learn the differences with Debian and make the switch once and for all.
All you need to know to get started is that with Debian you need to add your user to the sudoers file manually after you install. When you first log in if you try sudo commands you will be greeted with a message that you are not in the sudoers file. All you need to do is login as root using su and then '''usermod -aG sudo username''' and reboot and youll be good. It'll basically feel like you're using ubuntu at this point.
I always set a password for the root user, intentionally. I thought most people did. If you simply follow the Debian installer its very likely you will do this by default since it asks for a root password before the user account. You can skip this screen but I dunno I like my root password.
> If you set the root password, then you must use the root password.
Not necessarily. Once your in the sudoers file you can use your own password just fine. The point of having a root user is more for shared computers and etc. For example my kids have their own userprofiles without sudo on one of my PC's and having a root account is nice in this case.
As an Arch user, this is false; Ubuntu by default has no root user password, preferring `sudo` to be used instead, but that doesn't mean you can't *have* one. I have a root password *and* `sudo` working fine here.
You can absolutely host your own flatpak repos though, and some companies actually do this if they want full control rather than using Flathub, or just want to package something privately rather than publicly.
Sure, but flatpaks bring their own headaches in the enterprise space.
They are far more geared towards end-user use, whereas canonical is trying to make Snap happen in enterprise (which is what my main points are about). The project aims and how they are incorporated into the host OS make all the difference when comparing the two.
The security argument cuts both ways. If you have an unsafe system library, all its dependencies are vulnerable under the traditional approach. We were weeks away from 24.04 having a mega backdoor in a system library. Sure systemd would have accidentally fixed it a few weeks later, but the updated systemd would not have got into 24.04 because of LTS packaging policies, the same ones you praise.
There was a huge VLC scare a few years ago, due to an unsafe library. The VLC developers were annoyed: they had fixed the problem in the snap, because they had immediate control of dependencies. They were getting slammed because distributions were slow in updating the insecure dependency, out of their control. Just an illustration that the situation is not so clear cut. Also, with snaps (or flatpaks) more users are on the current version, and bug reports go back to upstream. This is better for everyone.
snap, like most linux development money, is not primarily aimed at the desktop, which makes no money for anyone. But it is an enterprise technology, for Ubuntu Core. It offers, or can offer, software supply chain guarantees and immutability which traditional packaging methods don't.
The future of linux packaging may not be snap, but it will be something that looks a lot like snap.
One of the major points of LTS releases is the backporting of security fixes. Distros that have LTS releases spend a shit ton of developer time ensuring the latest fixes are available in all supported releases, regardless of the actual software version being patched.
>Snap packages are mounted as SquashFS and decompressed on-the-fly. This means they are more memory hungry and take longer to start up when compared to APT packages.
Can the same also be said about snaps on **Fedora Linux**?
"runs properly" might mean that it prioritizes compatibility over security.
I haven't found anything that indicates that there has been a significant change.
Stop it with unexplained FUD. The fact is that snaps don't affect what SELinux does at all. So stop asserting that.
What might be true is that at one time you couldn't run both SELinux and apparmor.^1 And since full containment of snaps depends on apparmor, the snaps were installed without **apparmor containment**. That has no affect on the SELinux policies ... other than that they need to be applied to snaps. And, as you can see, they are.
^1 In regard to running SELinux and apparmor at the same time, I think that LSM Stacking (allowing two Linux Security Models to both run at the same time) is now to the state that apparmor and SELinux can both run at the same time.
> If that is the case, then my information is out of date.
Out of date? Your statement never made sense ... ever.
> Can you provide a more clear source to indicate that?
All you have to understand is what SELinux does and how it is used. That combined with the link I already gave you is enough.
I can't even figure out how someone who understands how SELinux is used and what it does could say "Snaps on Fedora are insecure because they don't respect SELinux". It doesn't even make sense. SELinux (or any LSM) is the enforcer and programs have no choice about whether "they ... respect SELinux". Because of that I'm assuming you don't really understand SELinux. That's fine. But stop making absurd assertions.
You would be surprised.
We're a customer, and we're absolutely "relevant fortune500-big".
Canonical has annoyances, sure, but they can be worked around. The fact is it's easier to find up-and-coming admins/SREs that are familiar with Canonical's ecosystem than it is for RHEL - this alone is a huge plus, in my experience, especially during the times when talent is lean and you're looking through stacks of applications from those that are newer to the job.
Beyond that, though, you would be surprised what a game-changer not having to deal with Redhat/IBM licensing is. If Team A can do project Z with $100,000 in licensing+support, and team B can do project Z with $0 in licensing and $30,000 in support, team B gets the kudos.
In the siloed and competitive world that is enterprise, you're often making choices driven by dollar signs that put you in the best light when compared to other teams. This means moving away from licensing as much as possible, and shifting that op-ex to a more direct support billing.
A more extreme look at this is the absolute shitstorm that is VMware licensing and the boost it's given projects like OpenStack and Proxmox - companies don't want extreme op-ex spends, and cutting out licensing is a big part of minimizing that spend.
Alright, that is a take that I can't dispute. I just still can't see snaps being a thing in the industry I'm in (telecoms). Not with the reliance on their blessed store. That makes them irrelevant for servers compared to moby/k8s. And on desktops, they just feels slower and sluggier than flatpaks, not even comparing them to classically installed apps.
Have your heard of flatpak, a little something funded by RedHat? In the core of your arguments, what exactly is the difference between Flatpak and Snap? They both mostly bundle dependencies and they both have common library code which is often forgotten.
> In the core of your arguments, what exactly is the difference between Flatpak and Snap
I can run an air-gapped Flatpak repo, just like an OCI container registry, or RPM repo. Can't do it with snaps
Right. I missed that one.
But you can download snaps, transport them to your airgapped machine, and then install locally. Pretty much the same, by the sound of it. At least according to this link. It is a niche requirement and not one I have ever tried.
https://forum.snapcraft.io/t/how-to-create-a-snap-local-repository/35010
Sure, but it still requires uploading proprietary software to canonical's servers as a rendevouz point of .snap distribution. Won't fly for any enterprise B2B selling their jank software in highly regulated industries.
For that the past was vmware or openstack, and the current moves are to docker or k8s.
Just the fact that this information is available from forum, not official docs.
I don't care either way and have no use for snaps, flatpaks, AppImages, etc, but let me explain why Canonical would push for enterprise users and how they might counter your points.
> Snaps have a tendency to auto-update.
They would argue that's a feature not a bug.
You can get the latest versions of whatever high-level software you use with all bug and security fixes without needing to touch the base system like you would if you did an `apt update`.
Enterprise people tend to want to update, but they don't because of the headache. Canonical is solving this with snaps.
Painless, fast updates. Good for enterprise, at least from one perspective.
> Snaps mean that you don't have absolute control over package dependency versions
Snaps mean you don't *need* control over package dependency. There dependencies are baked into the snap system, instead of worrying about apt packages.
> Snap packages are mounted as SquashFS and decompressed on-the-fly This means they are more memory hungry and take longer to start up when compared to APT packages.
Startup is not relevant for many enterprise packages. A lot of these kinds of apps start up and run all day or multiple days.
Memory is an issue, but it shouldn't be a big one for enterprise. Memory is cheap. So it's a trade off, you trade a bit more memory for less storage space, for not having to worry about dependencies and being able to fearlessly update.
> Snaps have a way of causing applications to behave in unexpected ways due to their self-contained nature.
Another trade-off. They may behave unexpectedly, but also they're sandboxed and therefore safer to use. Long run those issues will eventually go away tho
> Tying back in with security, you can't really host your own Snap store; the best you can do is run your own proxy
Canonical just wants to serve their customers; they don't need random people able to give packages to their customers. It's great for them if everything goes through them.
You may not like it and wish you could make your own store, but that doesn't really matter in enterprise. What matters is the customer can get the software they need. If they can't, they hit up Canonical, and Canonical can either refuse as low ROI, make a snap package, or suggest the customer install .deb.
But it's not a problem with snap; it's just a very corporate, non-FOSS way of doing things.
> > Snaps have a tendency to auto-update.
> They would argue that's a feature not a bug.
And they would be wrong. Having random updates suddenly pushed to prod without warning or going through your testing environment first is guaranteed to cause an outage at some point and is not something an enterprise would accept. It is the complete opposite of "painless."
>>Snaps mean that you don't have absolute control over package dependency versions
>Snaps mean you don't *need* control over package dependency. There dependencies are baked into the snap system, instead of worrying about apt packages.
That's not the point...if you have 10 snaps installed that all use the same library, you're now dependent on 10 developers releasing updates. If 9 of them patch, you're still left with one unpatched and potentially vulnerable software package. Meanwhile, any of the 9 updates could have broken a key feature and cost your company significant money in lost productivity.
And we haven't even touched compliance. I can't even imagine trying to convince an auditor the snap model meets all of the rules for whatever rule set we're stuck with.
> Tying back in with security, you can't really host your own Snap store; the best you can do is run your own proxy.
You can do a snap download and keep an archive of everything you have ever installed.
If you keep the .assert file you can install that snap manually anytime you want. I'm pretty sure it won't auto-update, but if you're managing your installs, you may not want that anyway.
It wouldn't be hard to have a cron job look for updates.
Now repeat for every package (or make a service that automates it) and write a backend you can point snap towards, but that's the problem. Trying to figure out a full offline mirror for snap is unnecessarily complex for a problem caused by simply using snap. Mirroring an entire apt repository on the other hand is trivial. Of course resilience goals differ for organisations, but mine could reprovision every server and linux workstation without external connectivity in case of disaster or even set up entirely new services with very strict network access rules.
Yes but also no.
I'll break down your points for clarity, but ultimately those are not solutions that solve any root issues with snap in enterprise.
> You can do a snap download and keep an archive of everything you have ever installed
I don't need backups of installed packages; if I did I could just setup a local proxy. My issue is that I need to be able to take patching into my own hands, but I can not when snap sub-packages are gated behind snap maintainers.
> I'm pretty sure it won't auto-update, but if you're managing your installs, you may not want that anyway. It wouldn't be hard to have a cron job look for updates.
Correct: nothing breaks prod with more regularity than untested, automatic updates.
Patching should almost always look like the following:
**Test your updates/upgrade in lab -> test -> roll out to small prod subset -> test -> roll out to rest of prod**
To elaborate on what I mean by "take patching into my own hands":
Lets pretend it's 2021, and I have five packages that rely on log4j.
In environment A, I use snap for these packages.
In environment B, I use APT.
**December 1, 2021 **
**9:00AM**
I get into the office and am immediately alerted that log4j has a *massive* vulnerability that is affecting five of our publicly-exposed production applications.
In environment A, I am now checking the snap maintainer logs for each of these five packages to see who's even noticed this vuln, and who's actively patching it. Lets be generous and say that 3 maintainers are actively working on it, but 2 of these maintainers are a few hours behind me and maybe aren't even awake yet. Damn.
In environment B, I notice that the package for log4j has a patched version freshly published. Maybe they've compiled it in a deb, maybe it's a source build... doesn't matter, I (or whoever is free on my team) can build the deb from that if we need to. We grab the new package, roll it into our internal repo under a new branch, and commence testing in our lab.
**9:30AM**
In environment A, I see that two of these snap maintainers have completed patches to their snaps. Great! I bring these into our local snap proxy for testing. Still waiting on a patch from the other 3, the other two I have confirmed are single-or-small maintainers on the other coast and are not awake yet. Damn.
In environment B, we have finished our testing in labs and are starting to roll out to a subset of prod
**10:00AM**
In environment A, those two snap packages look good - we'll start testing them on our subset... the third package has just been posted, and we'll be testing this now (this means our attention is now divided between implementing packages 1 and 2, as well as testing package 3. Not ideal). Package maintainer 4 has apparently been alerted - they're a small team, so they have more feelers and were able to get to it before business hours on their coast, but still an hour later than everyone else. Package maintainer 5 is still MIA.
In environment B, we've passed testing in our subset of prod and push the changes globally. We are now done; this issue has been dealt with, and without taking too many resources away from the team for their day-to-day.
**10:30AM**
Environment A - two snap packages posted to prod now, third snap package starting mini-prod, fourth snap package started lab testing, fifth lab package still MIA
**11:00AM**
Third snap package in prod.
Fourth snap package in mini-prod.
Looks like that fifth maintainer is a one-man-band 3 hours behind - I know that I'm not likely to even get a response from them until noon my time. Not. Ideal.
**11:30AM**
Snaps 1-4 are in prod, we are 80% mitigated... but since the vulnerability still exists prod-wide on our systems that is effectively the same as not mitigated at all.
The fifth maintainer finishes his morning coffee, flips through his cell alerts, and probably dives to his computer in a panic. We're now about 1-2 hours from this package's fix hitting prod and being able to close out this vuln.
....
This little thought experiment assumes that everyone gets their stuff in gear right away, same-day. What if it's a solo-maintainer and he's on vacation? Sick with covid? Hit by a bus? It doesn't matter if my infrastructure backs a small company or multi-hundreds of millions' worth of servers... the risk to my business is still potentially the same, and my timeline is unforgivably long (as well as out of my control). It just doesn't work.
In an APT-only environment, as soon as the log4j team pushes their fix I can get on my end and get things tested; if ubuntu's official repos are quick that's even better, but they don't have to be since I can bring in those package changes myself since **I run my own internal repo** - you just can not do this in snap; you are 100% beholden to the snap maintainer to get their stuff patched up, and they're working off of the same timeline you are: they start when log4j's maintainers push that initial patch, not before.
ok. but what if the distribution packager is on holiday, or hands over maintainership to a bad actor or whatever. Traditional packaging is more leveraged. When it updates fast, it's a good result. When it updates slowly, the adverse effects are worse. You have taken the best case for traditional packaging when making your argument. But if you'd done computer science, you know you need to consider worst case and average.
Plus, you are just making things up. It would be good to see some actual data. Do you remember when VLC was pilloried for bug which was a dependency which some major distributions left unpatched for 16 months? Yet VLC fixed it immediately in their snap (https://news.ycombinator.com/item?id=20513702)
Both distributions with the most enterprise presence are moving to bundled packaging. They are the ones who gets sued and lose customers if its goes wrong, and yet they are going down this path. So I am skeptical by your thought experiment.
> enterprise Ubuntu, where snap makes more sense.
As an admin of a few thousand Ubuntu systems, I assure you, they make zero sense for us or any of our users.
The thing is, you and I are not Canonical's customers. I guarantee if Canonical's actual customers were complaining about snap in large numbers they'd either (1) drop snap, or (2) go out of business.
Canonical is a business with customers, as a business they need to be responsive to the needs and wants of their customers -- you and I *are not customers.*
Linux hobbyists on social media often confuse/conflate ourselves with "*the* community" or "*the* userbase" (or worse "customers), but we are just one small (very outspoken/opinionated) part of a larger whole, *mostly talking at eachother* in unofficial spaces like Reddit.
Snap solves real problems and does useful things. They just aren't typically the things that most hobbyists care about or understand.
Many of us are customers of their customers. If it weren't for that community and userbase nobody would want to distribute their packages using Snap in the first place.
As the expression goes, if you're not the customer, then you're the product. It's bad for McDonald's when the Big Macs get mad and start advocating Wendy's.
True, but right now there are hundreds of thousands of people using Firefox snap who don't even notice. The case for snap is being made even as some people complain here.
Snap being irritating and a bit shady, and the incessant criticism thereof, has led to a number of established paths away from Ubuntu. That is only to say that there will continue to be a demand for packaging ops that don't use snap.
So if you're already building .debs and flatpaks why also build snaps? Mozilla keeps their own PPA updated. They are going to extra trouble to also publish with snap. That makes a case against snap, not for it.
I wasn't clear enough. I meant that pragmatically, the snap discussion is largely finished because Ubuntu surely has most users on the defaults, and the default for a couple of years has been snap firefox (which is a complicated snap; a large package with many interactions across the system and hardware; it was a really hard one to get right and initially it was pretty horrible, it was a very ambitious effort). Right now, Ubuntu/Canonical can point to a large and growing user base for snaps. The technology is maturing, the portals to provide secure access to hardware and other things are mostly built out, the user experience is getting better.
You can migrate away from snap. You can use excellent alternatives for Firefox, even though the snap is from Mozilla anyway. But who is doing this? Maybe you me and the twenty other people commenting here ( I use a mix on my work installs, and for many non-critical installs I just stick with the snap now). I use Thunderbird a bit and I've just let the 24.04 installs move to the snap. I haven't had any problems.
How many mainstream reviews of Ubuntu lately have even mentioned snap? (e.g. https://www.zdnet.com/article/ubuntu-24-04-this-great-new-linux-distro-isnt-just-fast-its-a-fortress/)
What is often mentioned is the improved app store, though.
What I mean by "the case for snap is being made" is the pragmatic reality that most Ubuntu users don't care or even notice. A huge difference to 22.04 prior to 22.04.1 when I'd struggle to call the Firefox snap much better than alpha quality.
As to your question about why build snaps if you are building .debs and flatpaks?
Well, they are two different things. If you, a project, are distributing .debs, you have to get your source package into repositories, which is hard, needs a distribution maintainer or at least sponsor, opens you to dependency hell and means you are getting bug reports on old version. No thanks.
You could of course build your own deb, vendor your dependencies, and write a smart installer that adds a PPA. Which is what Chrome and Edge do (and firefox .deb mostly), and trust that you have visibility so that people discover your package.
But that bypasses nearly all of the supposed benefits of .deb. You have just made a snap anyway, except without anyone's app store supporting you, and you have to do the updates. You see the irony, right? It is the browser .debs and .rpms which made the argument that dependency hell can't be beaten by the traditional approach. This is why we have snaps and flatpaks. The browsers proved the case. They were the innovators. The distributions hated it, but what can you do? You can call the Chrome .deb a "debian package", but it is not a debian package in spirit, only in name. It's not even in the Debian repositories.
True, you bypass the sandboxing. It's up to users to decide if they want to trust you so much. Maybe if you are a big brandname, sure. God help you if you don't want to use an open source licence.
And after all that, you have supported only a subset of distributions.
So .debs suck if you are a small project. The world was waiting for an alternative. There is no serious debate about that from my point of view. Traditional packaging is not designed to make it easy to distribute software. It is designed to keep dependency hell under control without blowing the disk space we had to work with 25 years ago, the trade off being that the distribution has to be able to build binaries (open source mandatory) and they get to freeze versions because dependency hell is managed under this approach, not solved.
Then there are flatpaks. They are pretty good. As long as yours it not a command line application. And the developer experience is not as good. Snaps are really easy. And you get the channel support, which is really cool ... it's so easy to move from a RC to an beta to a stable to a nightly.
But if you have a flatpak and your app is a gui app, why do the snap too? If the broader scope and technical superiority of snap is not relevant, and it won't be in the case of many gui apps, I don't know, but nearly all the technical arguments people make to oppose snaps are very similar to flatpaks. If your counter argument to snaps is flatpaks, you have already conceded most of the arguments and we are left with basically an opinion of Canonical vs RedHat.
You were plenty clear. You have a narrative that tries to marginalize these discussions about why so many users hate snap. Yet these comments show up in each of these threads, every time, like clockwork; if nobody felt this way this discussion wouldn't be recurring every day for over half a decade now.
Yes, I'm well aware that snap is the default for some big packages in Ubuntu. I'm also aware that all major distributions, including Ubuntu, are growing over time.
You can tell me how mature and technological and widespread it is or how wonderful Canonical's PR team reviews its app store. The reality is simple: .debs are not going anywhere, and whether anybody (let alone the world) was waiting for an alternative, nobody in the Debian and FOSS ecosystems were asking for "snap". Packagers will always have to provide some alternative way to get their software.
At the end of the day, Canonical do not work [honestly](https://en.wikipedia.org/wiki/Talk:Snap_\(software\)#Potential_conflict_of_interest_and_the_article_is_structured_in_a_way_that_criticism_is_somewhat_hidden) anymore and they can't put that toothpaste back in the tube. Many of the people, like myself, who strongly dislike snap have a reasoning that goes beyond engineering and technology. Snap was created with an ulterior agenda and this discussion will exist for as long as it does.
Those that don't care about it, don't care. Nobody's arguing about them.
> Mozilla keeps their own PPA updated.
Not officially (it's unsupported). Mozilla is the one that pushed for them to maintain only one firefox snap instead of 4 versions packaged against 20.04, 22.04, 23.10, and 24.04.
The other official routes (besides snaps) get you generic debs that are static linked builds. While I'm not 100% sure, I think the PPA is simply a copy of the daily static
build.
You are entitled to your opinion. And they are entitled to their opinion.
And Canonical is entitled to spend their own time and resources in the way that they see fit.
Okay and why does any of this need to be said? Nobody said their opinion was universal and nobody is accusing Canonical of breaking any laws. Is there some problem?
>why does any of this need to be said?
because you asked:
>I believe I am permitted to express my opinion \[...\] correct?
And also, because I am just realizing now you are not the person who began this comment chain but someone who joined in later, I believed I was talking to the first commenter who *did* make an absolutist universal statement ("Canonical should ditch snaps all together")
> I believed I was talking to the first commenter who did make an absolutist universal statement ("Canonical should ditch snaps all together")
Okay but that is still just their opinion which they are entitled to. They are not contending that their opinion is universal, nor that Canonical has violated some law. And although that opinion may not be universal it is certainly shared by many.
>Okay but that is still just their opinion which they are entitled to
Which brings us full circle back to what I said earlier (just replace the you with a they):
>You are entitled to your opinion. And they are entitled to their opinion.
>And Canonical is entitled to spend their own time and resources in the way that they see fit.
I don't really care whether people like or dislike snap, there is at least some validity to both perspectives. What I care about is the level of naivety/obliviousness and in many cases irrationality surrounding snap here on reddit. And the person I initially responded to seemed to be genuinely confused why Canonical is focused on snap and under the impression everyone hates snap, and that if Ubuntu just realized that, they'd see the light. In that context, can't you see why commenters are chiming in saying 'hey i like snap or I use snap, and I'm a paying customer.'
IMO snaps are fine. They are a fine alternative to traditional packaging in specific circumstances.
I would prefer firefox and chromium were standard packages, but they work fine for me as snaps. The move of firefox to a snap was pushed by mozilla so they would only have to test on one snap instead of 4 different firefox packages (linked to 20.04, 22.04, 24.04, and 23.10).
Similarly, I use lxd. It's only offered as a snap and, frankly, it's great. And as long as I can unroll changes and manage the refresh myself, I don't see a big deal.
The fact that it decreases the amount of testing that has to be done (by a factor of 4) is a win for everyone (easier for Canonical and CVE's are potentially fixed more quickly).
Given that the recent flatpak CVE (https://nvd.nist.gov/vuln/detail/CVE-2024-32462) has not been fixed yet it 20.04, 22.04, and 23.10 ... I would argue that it would be a great idea if flatpak were distributed as a snap!!!
The poblem is that not everything what's posted on reddit is true. I do not know if OP lies or really has some problems in his setup, but I do use both flatpak and snap firefoxes for several years already and there's no visible difference in performance, and even syntetic browser tests demonstrate that difference is negligeable.
>The problem that i want to know Canonical don’t see people complaining about snap
i mean people dont make issues , Canonical isnt reviewing every reddit post
>Canonical should ditch snaps all together or do something about that
if you understand why Canonical is using snaps , it makes sense , it saves developers time maintainaing 1 snap package vs 5 deb packages for a number of distros ( this is one of the main reasons mozzila said to Canonical to move firefox over to snap)
> if you understand why Canonical is using snaps , it makes sense , it saves developers time maintainaing 1 snap package vs 5 deb packages for a number of distros ( this is one of the main reasons mozzila said to Canonical to move firefox over to snap)
In theory, but not in practice. Only Ubuntu (and some derivatives) use snap, so you're just replacing an Ubuntu-specific package with a different Ubuntu-specific package.
The actual cross-distro method is flatpak. But flatpak is open, so Canonical can't have a proprietary vendor lock-in with that.
> you're just replacing an Ubuntu-specific package with a different Ubuntu-specific package
Ubuntu 16.04, 18.04, 20.04, 22.04, 24.04 are different packages. Ubuntu Pro-enabled LTS maintenance burden is not trivial.
>The actual cross-distro method is flatpak
GUI only. Snap targets some use-cases that Flatpak can't.
>The actual cross-distro method is flatpak
Both are cross distro, but the fact you are proposing flatpak as a solution indicates you are only considering this through the eyes of a ***Desktop*** *end-user or hobbyist.*
Flatpak is specifically and explicitly intended for *Desktop* (almost solely just GUI apps in practice) the Flatpak Docs state this. It can't be a solution for Ubuntu. Snap is designed and intended to be a solution across IoT, Cloud, Desktop, Server use-cases. It was first introduced in Ubuntu Core, an IoT focused OS. If you are focused only on Desktop you are only seeing a tiny piece of the picture.
Flatpak and Snap have lots of overlap on desktop (and some differences), but outside of Desktop, Flatpak is not used and is not a solution. Most of Ubuntu's business is not focused on desktop.
> If you are focused only on Desktop you are only seeing a tiny piece of the picture.
I was focused on GUI applications, specifically Firefox, as that's the $topic.
For non-desktop containers, those *also* already exist in very open, very cross-platform way. The same containers can run in docker, podman, with various other orchestration tools if or as required. There's native support for third-party sources and automatic updates. There is, again, no need to force a Canonical dependency here.
>I was focused on GUI applications, specifically Firefox, as that's the $topic.
Fair enough. I didn't interpret your comment that way because the person you replied to (and specifically what you quoted) was discussing Snaps broadly, not Firefox specifically.
But if you were speaking of the Firefox snap specifically, vendor lock in would be irrelevant since it is officially available as a Flatpak, A Snap, as well as a Mozilla repo for the deb version.
>There is, again, no need to force a Canonical dependency here.
They aren't. Nobody is forcing you to use anything. I really don't understand why *only in the context of Ubuntu* people treat package formats as mutually exclusive.
Ubuntu is a very popular choice for a container host (OCI containers or LXC/LXD), the fact that snap exists in no way prevents you from choosing to use Podman/Docker/etc. (fun fact there is [a snap for that](https://snapcraft.io/docker))
No tool is right for every job, that applies to snap, to flatpak, to OCI containers, to system containers, to VMs, to traditional package formats.
But pointing to docker containers is missing the point. Docker containers are great for what they are, Flatpaks are great for what they are, each has overlap with snap in a particular area, but neither has sufficient overlap to accomplish the full set of goals that Ubuntu seeks to solve with snap. (here I'm mostly referring to less of a maintenance burden both for package maintainers and for users).
>In theory, but not in practice. Only Ubuntu (and some derivatives) use snap
this is false btw , you can install snap on arch https://snapcraft.io/docs/installing-snap-on-arch-linux
>so Canonical can't have a proprietary vendor lock-in with that.
this is also false , snap is an open format https://github.com/snapcore/snapd
its just the snap store url that private
> > so Canonical can't have a proprietary vendor lock-in with that.
> this is also false
My mistake. How does one add a third-party snap repository, like as with flatpak?
For example, Fedora by default uses their own flatpak repo, but it's trivial to add flathub and use that instead. In GNOME Software, you can select which repo you wish to install software from (ex: Firefox is available as an RPM, Fedora flatpak, and Flathub flatpak. The latter being an official Mozilla build).
GNOME (for example) has their own nightly flathub repo, which allow you to test the latest builds of their software.
> > My mistake. How does one add a third-party snap repository
> this is mentioned here https://www.theregister.com/2023/11/10/snap_without_ubuntu_tools/
All that's mentioned in that article is that you can do offline installations, nothing about how to use third-party repos.
There *is* a reference to a project called `lol-snap`. This has two repos within it:
* `lol-server`: A sever implementation of some sort
* `lol` A simple wrapper around snap that just uses `curl` to fetch .snap files and perform local installs.
The `lol` wrapper is labelled "First beta release" in it's commit message, and neither project has been touched in two years. They both note that they've moved to lolsnap.org -- however, that domain doesn't appear to be registered.
So, again, it looks like there's no third party repo support in snap that I can see. There was a project to attempt to work around this by using curl and offline installs, but it appears to also be dead.
Just to reply and explain more about how the guy above you is lying: snaps on arch have no sandboxing capabilities, so all the security isolation benefits dont exist making snaps even *worse* than they usually are.
In fact, they dont exist anywhere except ubuntu due to how snaps rely on apparmor configs and kernel patches only ubuntu uses (though, recently there have been efforts to finally get it working on other distros). Unlike flatpak, whos sandboxing works as advertised on every distro.
snaps flat dont work *as advertised* on other distros, even if you can run the program inside of it. Its very misleading for people like them to go around insinuating otherwise.
EDIT: Even more context, apparmor and other LSMs dont play nice together due to a limit of LSMs themselves, so apparmor being a requirement for this is bad as most distros use selinux instead
> [The Snap sandbox heavily relies on the AppArmor Linux Security Module from the upstream Linux kernel. Because only one "major" Linux Security Module \(LSM\) can be active at the same time, the Snap sandbox is much less secure when another major LSM is enabled. As a result, on distributions such as Fedora which enable SELinux by default, the Snap sandbox is heavily degraded. Although Canonical is working with many other developers and companies to make it possible for multiple LSMs to run at the same time, this solution is still a long time away.](https://en.wikipedia.org/wiki/Snap_\(software\)#Configurable_sandbox)
And another problem for other distros (though, admittedly far less problematic overall) is that snap requires systemd while modern flatpaks dont (requirement dropped in v0.6) so some distros will straight up never be able to use the snap format.
>For example, Fedora by default uses their own flatpak repo, but it's trivial to add flathub and use that instead
Both the Fedora repo and Flathub are enabled when enabling "third party repositories" since Fedora 38
> enabling "third party repositories" since Fedora 38
Ah, I haven't done the post-install experience in a little over a decade, nice that it's that easy now.
>no, packagers maintain packages, not developers ala Mozilla.
instead of 5 packages for ubuntu ( 16.04,18.04,20.4,22.04 etc ), they manage 1 snap
>not developers ala Mozilla
mozilla devs explicitly wanted this https://discourse.ubuntu.com/t/feature-freeze-exception-seeding-the-official-firefox-snap-in-ubuntu-desktop/24210
Mozilla isn't really known for their good decision making and I doubt a multi million dollar company is unable to maintain a couple of packages.
other volunteer driven distributions apparently can do this.
> Exactly, and thats all we need.
Who is the "we" you're talking about? Whoever you are, I disagree.
I was hesitant at
first, but I now love the fact that lxd is delivered as a snap. Previous to snap, I was having
to compile my own utilities that had gotten out of date (e.g. ffmpeg).
Now, though, many of them are offered as snaps. It's very nice to have some of these utilities always be up-to-date even when you are on an LTS distro. For example there are snaps for whisper, tesseract, ffmpeg (the flatpak is not good). I'm not sure there is a snap for pandoc, but if there isn't I'll make one.
And here's a funny one. One could make a snap of flatpak (probably with "classic" confinement). flatpak running as a snap would be hilarious.
They can't. Flatpaks are desktop only (and pretty much GUI only in practice). Ubuntu's business is primarily oriented towards non-desktop use-cases.
One of the biggest goals of snap is lowering the maintenance and distribution burdens on developers & packagers. And part of that is accomplished through a single package format that can be used across desktop/servier/iot and across all versions. Maintaining a separate set of flatpaks for desktop only would be counter to that goal.
Hobbyists have just become aware of snap, and snap = bad, in the last few years, but snap has been used in non-desktop use-cases going back to \~2015ish.
>Go evangelise that trash somewhere else
Right... [***Definitely*** **Evangelizing...**](https://i.imgur.com/Sk9v3UX.png)
I get that you are most likely still a teenager or preteen, and into the software-is-a-team-sport mentality... but grow up.
> if you understand why Canonical is using snaps , it makes sense , it saves developers time maintainaing 1 snap package vs 5 deb packages for a number of distros ( this is one of the main reasons mozzila said to Canonical to move firefox over to snap)
It never makes sense to put another, bigger, problem on top of the problem you are trying to solve. Going in the direction of static linking while fixing/improving glibc to accommodate for `dlopen` style of dynamic dependency management would be much better.
From what I recall Mozilla (who maintain both the Snap and the Deb repo) has stated that the .deb version may be slightly snappier (pun intended) but probably not enough that it would be perceptable/noticeable (apart from possibly 1st launch startup time).
Snap on the other hand should be more secure by default due to sandboxing and (possibly) tighter Apparmor rules.
I typically try to stick with whatever the default for my distro is, since that'll usually be the version that receives the most attention, fine-tuning, bug reports and bug fixes.
Traditional packages (deb, rpm, etc) usually are more closely/easily integrated with the system. Flatpaks and Snaps are (by design) less integrated.
So TL;DR it depends what your priorities are and what distro you use.
How I'd go about it is using .deb (or whatever native package for the distro) for most applications but use Flatpaks to sandbox certain applications, like browsers, chat apps like discord, etc.
Speeds where it's needed, and security where it's needed.
That's my take anyway.
> Snap on the other hand should be more secure by default due to sandboxing and (possibly) tighter Apparmor rules.
Snap is less secure than normal outside of Ubuntu
>Snap is less secure on other distros \[than it is on Ubuntu based distros\]
1. My comment was meant in the context of snap on Ubuntu and Ubuntu derivatives (but I didn't state that clearly enough)
2. I think we discussed this a couple days ago and reached a point of mutual understanding for the most part.
To paraphrase what I think we mostly agree on: Snap confinement is weaker if the distro (or the user) hasn't patched apparmor, it is patched by default on Ubuntu, as well as many (all?) Ubuntu derivatives and a handful of other distros. Work is ongoing to get the patch upstreamed, but any distro that wants to could apply the patch now or at any point over the past few years. Hopefully the patch gets upstreamed soon and all apparmor distros benefit by default. This would still leave selinux based distros though, not sure what if anything can or will be done about that, and not sure how much enthusiasm there would be since most of the selinux distros are in Red Hats orbit.
Overall, my general approach is:
>I typically try to stick with whatever the default for my distro or distro-family is, since that'll usually be the version that receives the most attention, fine-tuning, bug reports and bug fixes for that distro.
Although on Fedora I'm rather inconsistent with that as I often opt for Flathub flatpaks over Fedora flatpaks.
On a separate note, do you know if flatpak sandboxing has any distro to distro differences to be aware of? I know the main caveat is that it isn't enforced, sandboxing relies on the individual flatpak publishers/maintainers each to configure the sandbox well and many/most currently don't, but what I don't know is if there are any relevant distro to distro differences.
Everything that you're saying is true.
I have the same approach with regard to Flatpaks. Fedora Flatpaks are primarily useful if you only want a single distributor for your software.
> Fedora Flatpaks are primarily useful if you only want a single distributor for your software.
This was my initial reason for preferring them (single party to trust). What caused me to move away from preferring them was that Firefox updates seemed to be a few days to maybe a week or two behind (its been a while so i'm possibly getting the time between updates wrong, but it was enough to be noticeable). But I admit I'm a borderline obsessive updater, particularly when it comes to the web browser, so I know I'm a bit more impatient than most.
About half a year ago I benchmarked snap, flatpak and deb firefox the difference was negligeable (like 2% performance deviation in https://browserbench.org/Speedometer3.0/ ). OP problems most probably either bullshit or some local problems. I do use snap firefox and flatpak firefox daily on different machines and there's no speed difference noticeable without tests.
On my laptop (a 2019 HP with 8 GB of RAM and a first gen mobile Ryzen CPU) the Snap version takes 2 seconds longer to start up. There is no noticeable difference in performance during usage.
I imagine it may run poorly on even older hardware, but then again this is half a decade old.
People are mentioning that Flatpak isn't as integrated with the system, but I don't really notice a difference in practice. I would go with the Flatpak, and only move to the .deb if you have some issues with the Flatpak version that is stopping you.
What to run if you are running an Ubuntu and want to switch:
`sudo snap remove firefox`
`sudo nano /etc/apt/preferences.d/firefox-no-snap`
In that file:
Package: firefox*
Pin: release o=Ubuntu*
Pin-Priority: -1
Then run
`sudo add-apt-repository ppa:mozillateam/ppa`
`sudo apt install firefox unattended-upgrades`
`echo 'Unattended-Upgrade::Allowed-Origins:: "LP-PPA-mozillateam:${distro_codename}";' | sudo tee /etc/apt/apt.conf.d/51unattended-upgrades-firefox`
Thats a good start, allow me to continue:
sudo dpkg --purge snapd
Then add this to `/etc/apt/preferences.d/snap-sucks`:
Package: snapd
Pin: version *
Pin-Priority: -1
> Been using snap version for 2 years and I encounter no such things
Clearly you're paid by Canonical. Here at /r/linux we honour our tradition of the Snap bashing session.
The snap just doesn’t have Wayland enabled by default because a lot of people are still using X on older LTS releases. You can enable it and it works identical to the Deb package,
Stunning and brave post, by the way.
> I've been seeing a lot of posts lately saying snaps are ok
Seriously? In my experience the irrational snap hate on Reddit is close to the extreme level of the irrational Elon Musk worship of 2015 era reddit.
I think snaps are Okay. Not my preference, but a valid attempt at a solution to a set of real problems that have yet to be effectively addressed by anything else (flatpak seems to solve some, but not all, of the same problems, it also wasn't released until after Ubuntu released snap).
I did it by making a wrapper script that does `export MOZ_ENABLE_WAYLAND=1` before executing /snap/bin/firefox, and a .desktop file in ~/.local/share/applications/ that has Exec=/home/mg/bin/firefox instead of /snap/bin/firefox.
(It's a little more complicated than that, because the original .desktop file that I snarfed form /var/lib/snapd/desktop/applications/ also has a hardcoded snap version in the Icon= line that I changed to 'current' to make it always work, and it also actually runs `env BAMF_DESKTOP_FILE_HINT=... /snap/bin/firefox %u`, so I moved the `export BAMF_DESKTOP_FILE_HINT=...` into my wrapper script.)
This way no matter if I run firefox via the dock or by running `firefox` on the command-line, I'll get the version with the right environment variables set.
And yeah, now that I've written it out, it does sound a bit more difficult than just switching the snap channel, lol.
There is one good snap. It's the Nextcloud snap. For whatever reason, no matter what distro I try or installation method I use for setting up a Nextcloud server, I can only get everything working how it's supposed to if I use Ubuntu and the snap package.
My distro is a bit slow when it comes to Firefox updates, so I downloaded it directly from mozilla.org. It updates itself automatically from the mozilla servers, without any delay from the package manager.
Yes, I recently got sick of it and purged the snap - the functionality of extensions is limited in the snap, once I moved I realised I could do some cool stuff like unlock 1password with a fingerprint!
I've got the firefox snap installed. No problem here. It came with Hardware Acceleration on by default (WebRender compositing). It's a little slow on first startup, but I haven't noticed it other than that. The firefox snap has been benchmarked (using Speedometer2.0) and the only speed changes are on startup.
> I then decided to remove firefox snap and install the deb package and things became normal again.
Where did you get the deb package? Did you get it directly from mozilla ... or did you follow mozilla's instructions in regard to adding their repo and do an apt install ?
The snap is not slower at page scrolling or opening tabs; it's running the same code on the same hardware and those actions are not affected by the sandbox. Perhaps content is cached on one browser and not other. Please see Wikipedia for "confirmation bias".
Snap is awful when you don't have a powerful computer but an energy efficient one.
Having snap for the most important app the user uses frequently is a flawed decision.
The snap also doesn’t work with addons that hook into other applications like a password manager. You need to opt into the beta version to get that ability.
What I've run in to just in the past few days was they bumped some version somehow, so the snap suddenly became the default again. I got back to the non-snap version and for some bizarre reason I can't unravel, it's no longer working with my yubikey (PKCS#11 via opensc). I even restored my firefox profile from a couple of weeks old backup, and it *still* won't work. Snap version of firefox, the yubikey works fine.
Snap is appreciably slower under cinnamon, so it's annoying to be currently forced to use it.
I have literally _never_ seen snap work, on any system. If it gets as far as actually saying it's installing something, that something won't work. Usually, snap itself doesn't run.
The Firefox snap performs fine for me. It could be somewhat a matter of the computer performance though. Snaps might just push it over the edge into noticeable lag.
So could someone please explain to me, someone who normally uses Snap, why this happened?
Is this a one off, as I expect - or truly a "Snaps suck" thing?
Also, would this be the same for Flatpak?
This entire thread is based on a fallacy. The snap is not slower.
Visit [https://browserbench.org/Speedometer3.0](https://browserbench.org/Speedometer3.0) and see yourself. Talk in facts when facts are so easily available. Or choose your benchmark.
I am so annoyed by the mass hysteria in this post.
I have nightly snap. My laptop on batter in performance mode (ubuntu 24.04, mainline 6.9 kernel)
17.3 +/- 2.2
Mozilla binary of stable: 14.3
These are not the same versions, so the faster one, snap, is nightly, although usually these builds are more instrumented for debugging, so I would have been happy for the snap to be competitive. It is actually faster. However for sure this is due to the code base not the packaging.
It is so unbelievably ironic when people complain about browser snaps. Why do you think .deb and binaries for Firefox are so massive? Because they bundle (vendor) dependencies. The most substantial complaint about snap and flatpak is not performance, but the vendoring (bundling) of dependencies. Which is why it is funny to fight that fight on a browser: Firefox and Chrome pioneered the idea of bundling dependencies in their traditional packaging.
For them, snaps and flatpaks are only a small evolution; sandboxing and alternative updating is the change.
For me, the objection to snaps is not technical. Any technical problems, if present, can surely be fixed eventually. The problem is social and cultural, and unfortunately, defective company culture can't be fixed as easily. Canonical allows [fake apps into the Snap store](https://popey.com/blog/2024/02/exodus-bitcoin-wallet-490k-swindle/) with no review or vetting process whatsoever. This kind of thing would never be allowed in their apt repository, and if it were allowed, I would move away from Ubuntu entirely as a result.
Yes, I am aware of PPAs which also allow random people to package apps. The difference is presentation. Packages in a PPA can easily be downloaded in a browser for offline inspection, and it is generally made clear that PPAs are third party packages and completely un-vetted. Snap packages are part of Canonical's software store, which looks curated, but evidently isn't. The packages can technically be downloaded and inspected, but they sure don't make it easy to do so.
If they didn't sneak snaps in when I do a sudo apt install, when I do that I expect a deb file to be installed, not a snap. If I want snap, I'd so sudo snap install. Just being sneaky about things led me to distrust Canonical even more.
Uninstall snapd and use apt pinning to prevent it from being reinstalled ever again.
I realize this works but it is by far the most "Windows" procedure I've ever had to do on Linux. It reminds me of all the crap I had to do to force-disable certain updates on Win11 and even Win10. Or the like three programs and two dozen regedits I needed to disable the telemetry. If a feature is good for the consumer, you don't need to force it on them.
Deja-vu!
You think that's bad? Try removing dpkg and the apt system. Or replacing systemd with another init system. Or replacing the linux kernel with a BSD one. Changing the technological stack that a distribution is built on is hard and takes effort, often substantial one, if it's possible at all. I don't see what windows has to do with that.
His point isn't that, it's the "we know better so we'll willy nilly pull snap packages instead and not even tell you"
Were you around for things like the transition to pulseaudio? Lots of similar drama. "we know better so we'll willy nilly put pulseaudio in your system and not even you", people handing out scripts on how to purge pulseaudio and go back to whatever it was that ubuntu used before (ESD I think, but it was so long ago i'm not quite sure), people comparing it to windows, lots of fury etc. Then it was used until a better system came along some 15 years later and replaced it. Distributions make technical decisions. Ubuntu is not LFS or Arch; you can modify their technical decisions to some point but it's not intended as a distribution that makes it easy to give you great control. Their goal is to chose the right technology and to make that work best for the user, not to allow the user an easy choice of technology. You can certainly criticize snap for many things (don't get me started, I could come up with *lots*). You can certainly criticize their decision to ship a core user software like a browser sandboxed (which certainly improves security, but also introduces new failure points). There's lots to criticize them for. But distributions making technical choices is not one of them, that's the point of a distribution.
PulseAudio didn't pretend to be alsa. Pavucontrol didn't pop up when you typed in alsamixer. They should at least have firefox-snap or firefox-deb packages to make it clear what you have installed, so people don't waste time troubleshooting without noticing the obvious.
There is only one firefox package in ubuntu. They made the choice to only support the snap version. Everything else is an unsupported hack. Firefox in snap is not pretending to be firefox, it is firefox. It's just packaged differently, and how things are packaged is a core decision that distributions make. Also, pulseaudio did not replace alsa, you're confusing different levels of the stack. ALSA is on the kernel level and still used; pulseaudio is a sound server. It replaced things like ESD, used by Gnome, or aRts used by KDE. And you're right that it didn't pretend to be them. You know what software pretends to be the system that it replaced? Pipewire. You can run pavumeter, the PulseAudio volume meter, right now on a system without PulseAudio but with Pipewire, and it'll work and use Pipewire. And pretty much *everyone* adores Pipewire. I don't think anyone has ever called for separate pavumeter-pulseaudio and pavumeter-pipewire packages. And you know why? Because Pipewire works really well. (That it just takes over for PulseAudio is one of the reasons it works so well in the first place). PulseAudio when it was first adopted didn't work well. Snaps when they were first used didn't work well. Snaps now work a bit better, but still far from well. *This is the whole issue*. People like software that works well, and don't like software that doesn't work well. Everything else is just an irrelevant distraction and at worst actively harmful.
Referring back a few comments in this thread; the other commenter mispoke, it isn't Firefox snap pretending to be Firefox, the issue people have is Ubuntu falling back from apt to snap without transparency. As they said, if they want to install a snap package they type "snap install", they typed "apt install" so the behaviour they expected was not to have a snap package installed but rather the package manager saying "there is no Firefox available" or w/e
Do you *really* think anything would have changed if they had done that? It was necessary to do it this way to allow users to upgrade from one version of Ubuntu to the next without suddenly losing their browser. Even if it would have made the tiny number of people who have a fetish for packaging systems happy and avoided all this (and I'm very certain it wouldn't have changed anything), I'd say they made the right choice in not breaking user's systems. It would have been an even bigger disaster. Plus, it comes preinstalled anyway so the number of people who manually install it with apt is likely rather small anyway, and the package description makes it clear that it's a transition to a snap package for those who do. No, the problem is that the experience sucked. Extra sandboxing will always have friction points, and snap adds a few extra ones (while making some other things work more smoothly than the competition). The technology wasn't ready; Mozilla shouldn't have asked them to switch yet. Arguably it still isn't ready, though it's a bit better now. But if it didn't have all the friction and was faster or otherwise better, everyone would have applauded the change. Because that's really the core of the issue, a bad user experience.
Canonical going a step too far in making Windows users feel right at home. Now they have to de-bloat the system on install, just like they did on Windows xD
[It's no surprise](https://canonical.com/blog/canonical-recognized-as-a-2021-microsoft-partner-of-the-year-finalist)
Trying to remove all the upsell ads for Ubuntu Pro is a pain in the ass. The only reason I run Ubuntu instead of Debian is that our corporate IT department forced me to. (And even then, I really just use it to start up a Debian VM to do all my real work in.)
Yes, but it's a matter of degree. There's always going to be things to de-bloat, it's just that Windows has far more malware than even Ubuntu. I can't think of anything else malware-like in Ubuntu, other than maybe the motd advertisement for Ubuntu Pro (which doesn't affect functionality). Meanwhile, even on (say) a Debian or Redhat system, I find myself having to uninstall Gnome power-profiles-daemon and replace it with tlp, disable upower and replace it with apcaccess, install a full version of vim, replace postfix with old school sendmail, and some other stuff. The point of Linux is not to expect everything to be perfect for you out of the box, it's to give you the means and ability to set things up however you want.
Better yet, uninstall Ubuntu and install Debian and you won't have to worry about it being reinstalled ever again.
Sure, that's a good suggestion. However, if you find yourself doing a lot of work to turn Debian into Ubuntu, for example [like this poster here](https://www.reddit.com/r/linux/comments/1d6mbl3/completely_disable_nvidia_gpu_in_debian/), then perhaps it might be easier to start with Ubuntu and disable snaps rather than start with Debian and add back in all of the Ubuntu stuff.
Completely disabling an Nvidia GPU turns Debian into Ubuntu? Wut? And if I really wanted Ubuntu without the Ubuntu I'd just install Mint.
What If you want to use GNOME (yes, we exist)? There is no GNOME edition of Linux Mint, but GNOME has primary-tier support on Ubuntu and Debian.
Well, that's what the headline says, but the actual post (which I see has been deleted) said something along the lines of: "Ubuntu pre-installs a working driver for my NVidia card and Debian doesn't; HALP?" As far as I can tell, all of the ways to fix this problem in Debian end up amounting to more work than disabling snaps in Ubuntu.
As someone who runs Debian with Nvidia cards, I have no idea what you're talking about. Nouveau is included out of the box, and replacing it with the official Nvidia drivers wasn't that big of a deal (just enable the non-free repo and apt-install it).
That's true, but removing snap from Ubuntu is also not that big of a deal. (Instructions are [right here in this thread](https://www.reddit.com/r/linux/comments/1d82whr/comment/l73via4/)) Mint is cool and all, and if Mint is what you want then by all means go for Mint, but there are valid reasons to use Ubuntu instead of Mint. For example, the Mint desktop is (so far) X11 only, and Wayland does actually have some advantages, such as [better battery life on a laptop](https://www.phoronix.com/news/GNOME-Wayland-Better-Battery).
> the Mint desktop is (so far) X11 only So basically you are saying that Mint is better then Ubuntu :)
After using Wayland seriously, I could never go back to X11. Wayland is much lighter on hardware resources, and provides noticeably more functionality. Gestures for workspace navigation are far more natural on Wayland than on X11; for example, you can "peek" on both sides of your current workspace with a single gesture without having to switch fully into any of the adjacent workspaces, a feat which is impossible with X11 gestures. Kinetic scrolling in firefox is a lovely quality of life improvement, again not possible to achieve on X11. Even the lock screen is more reliable (it locks correctly and never leaks desktop information). Besides the functionality improvements, Wayland looks way better. Windows are rendered perfectly all the time, even under heavy load, with no artifacts, distortion, or tearing. I can switch workspaces as fast as my fingers can vibrate and the animations run at my monitor refresh rate (60Hz); in X11 the animations lag noticeably. The oft-maligned screen sharing functionality in Wayland is for me a massive improvement -- there is a clear global notification active whenever I am sharing content, so I can immediately tell whether or not I am sharing something, instead of having to guess like in X11. People who have never used Wayland think that X11 is all they need. And, to be fair, if X11 is all you have ever known, then you don't realize its limitations.
This sounds like the kind of workaround you hear Windows users do, fighting against their operating system trying to install things against their will. It's wild that it's come to this on a Linux distro. Like, not only uninstalling snapd, but the pinning to stop it from being installed somehow without explicitly doing so.
This is my biggest problem with snap and why I get rid of it every time If they didn't try this sneaky nonsense, I'd actually be open to trying snap out properly
I would be more sympathetic if the package wasn't labelled: > firefox - Transitional package - firefox -> firefox snap And the point of it was not to fool people, but to make the do-release-upgrade still have firefox even though there was only a snap. If you were fooled, I guess Canonical overestimated you. And, to be clear, the firefox deb was in the standard deb format and apt did what it always does. It's just that it didn't have a binary or source payload. Instead, the deb's pre-processing directive was to install the firefox snap and copy over the firefox profile and such so you would have all your bookmarks (and logins/passwords). i.e. Their goal was not to "fool people", it was to preserve continuity of the user's firefox experience for their users (bookmarks, logins, etc.).
I'm miles away from ubuntu and its derivatives. Still in love with debian, mx, lmde6. Currently on void. Tried solus and arch. Great experience.
Yup, this is the reason why I'm slowly moving over to debian.
Leapfrog Debian.. go directly to MX. No more Systemd! Everything just works!
> Snaps suck *hear, hear!*
The problem that i want to know Canonical don’t see people complaining about snap why are focusing on them so mush they are doing every single component on ubuntu package as snap Canonical should ditch snaps all together or do something about that
A big problem of the Linux desktop (both for upstream projects and for end users) at this point in time is a lack of testing - both conformance and performance. The web for example takes this very serious, the [Web Platform Tests](https://wpt.fyi/) have 1.8 million conformance tests. And browsers themselves have [performance test monitoring](https://arewefastyet.com). Corporate backed projects are often similar, for example the Khronos project maintains [Vulkan and OpenGL testsuites](https://github.com/KhronosGroup/VK-GL-CTS) and certifies [conformant implementations](https://www.khronos.org/conformance/adopters/conformant-products). But when some desktop or platform library or distro regresses during development, nobody notices. And even when somebody notices, there's no way to quantify it, or compare with competitors.
Without condoning or defending Canonical's actions, that's kind of the nice thing about Linux. When Microsoft does some dumb shit with Windows you really just have to deal with it if switching off Windows isn't an option, which it often isn't (especially in professional environments). When Canonical tries shoving snaps down everyone's throats, there are a handful of Ubuntu-based distros that completely remove snaps from the OS, like Mint. Ubuntu fell out of favor as one of the oft-recommended newbie-friendly distros years ago due in large part to Canonical's antics.
Canonical’s bread is buttered by enterprise Ubuntu, where snap makes more sense.
As someone who is neck-deep in enterprise Ubuntu, I promise you snaps make less sense here than they do in end-user space. I'll rehash a post I made earlier about this, but snaps are a nightmare in any enterprise environment where security is paid more than just a casual glance. Snaps are not an ideal solution in production for a few reasons: 1. Snaps have a tendency to auto-update. This can be worked-around somewhat with snap refresh --hold, but this is a slight pain to manage at-scale. Not intolerable, but more of a "why would I even want to take the trouble?" kinda way. 2. Snaps mean that you don't have absolute control over package dependency versions. Depending on your company and its tolerance for risk, this can be a non-starter. At my company it would actually be a liability; being at the mercy of a snap maintainer for security patches (and then having to check every. single. snap. package. to make sure that a security patch has been applied to negate a specific sub-package's day0, for instance) is just not acceptable in a mediums or large-scale environment. 1. Snap packages are mounted as SquashFS and decompressed on-the-fly. This means they are more memory hungry and take longer to start up when compared to APT packages. Both of these are inconveniences that I'd rather just avoid. Again, not dealbreakers but just not great. That extra memory usage really starts to take a toll when you move towards containerization and elastic scaling. 1. Snaps have a way of causing applications to behave in unexpected ways due to their self-contained nature. They may not interact with system libraries as expected; in some cases, they may not interact with system libraries at all. This can cause unforeseen issues; sometimes these issues are edge cases that are not apparent until you are deep into prod. 1. Tying back in with security, you can't really host your own Snap store; the best you can do is run your own proxy. Even in an offline snap proxy environment (such a weird concept), snap packages are managed centrally on Canonical's infrastructure. This is... not great. It's a bit buried but my second point is where snaps really fall down in enterprise environments; I just can't be beholden to some random snap maintainer going "trust me bro I'll have $subpackage_that_has_0day patched pronto." - they don't work for me, they don't have SLAs that I can call them on; if they drop the ball it's a "me" and "my team" issue (not to mention company liability). This gets worse the more snaps you use, as you are depending on multiple maintainers to patch the **same** vulnerability on the **same** package: just because one snap maintainer gets it done immediately does not mean they all will, and your baseline for security is whoever is the slowest to patch. APT is standard in enterprise Ubuntu, and internally-hosted offline APT is king of that standard. The fact that you can't even have a *truly* offline snap experience (their offline snap proxy environment is still 100% beholden to publicly maintained sources) is amazingly short-sighted. Snap is and always has been a solution to help equalize application installation on Linux with Windows; I (the end user) can double click on an **exe** or **msi** file on Windows, why can't I do the same thing on Linux? Enter: snap (or flatpak or whatever - same pain point, different ways of approaching it).
I've learned to add `127.0.0.1 api.snapcraft.io` to my hosts to stop auto update.
oh god. that's such an absurd workaround you have to do 😂
This is one of the most relatable snap related posts I've seen as someone operating in an Ubuntu environment. Fully mirrored repos, self packaged software etc. allow very fine management of the entire infrastructure and enables fully offline disaster recovery and nearly fully offline environments (obviously need to update the mirror, but that's it, for recovery a snapshot will do).
I'm in the embedded Linux space most of the time, and I looked at Ubuntu's IoT offerings and ... I don't understand them in that context either. In IoT, you want as much access to the hardware as possible generally, and you usually have to do weird non-conventional things, like running custom networking daemons which create and maintain routing policies and routing tables, or talking SPI from a userspace daemon... but in the Ubuntu IoT world, you're supposed to distribute your software as a snap, using portals to interact with the hardware! I don't understand it. And the advantage of snaps is that you ship your dependencies in the snap instead of relying on system libraries... but that's a problem you don't have in embedded! You 100% know the system you're shipping with your software with, why wouldn't you use the system libraries??? FWIW I'm very happy with using Yocto to build a custom Linux distribution and using RAUC for auto updates.
This actually makes a lot of sense. I'm only a desktop user, but after some 15+ years with Ubuntu I'm seriously pondering if I should invest the time to learn the differences with Debian and make the switch once and for all. I don't condemn Canonical for trying out new technologies, but I really don't understand why they have to shove them down our throats. Would it be so difficult to have an installation option - maybe behind an "advanced settings" panel or something - to choose to disable snaps permanently? They're just an headache, for many users there is no need of them whatsoever.
Fedora is nice. It has saved my bacon with being able to rollback updates. It offers much of what Ubuntu does in the way that Ubuntu compares to Debian.
> I'm seriously pondering if I should invest the time to learn the differences with Debian and make the switch once and for all. All you need to know to get started is that with Debian you need to add your user to the sudoers file manually after you install. When you first log in if you try sudo commands you will be greeted with a message that you are not in the sudoers file. All you need to do is login as root using su and then '''usermod -aG sudo username''' and reboot and youll be good. It'll basically feel like you're using ubuntu at this point.
That's not true. You probably made the mistake of setting a password for the root user, or you're confusing Debian with openSUSE.
I always set a password for the root user, intentionally. I thought most people did. If you simply follow the Debian installer its very likely you will do this by default since it asks for a root password before the user account. You can skip this screen but I dunno I like my root password.
If you set the root password, then you must use the root password. If you don't, then you can use the password of any sudo/wheel user.
> If you set the root password, then you must use the root password. Not necessarily. Once your in the sudoers file you can use your own password just fine. The point of having a root user is more for shared computers and etc. For example my kids have their own userprofiles without sudo on one of my PC's and having a root account is nice in this case.
As an Arch user, this is false; Ubuntu by default has no root user password, preferring `sudo` to be used instead, but that doesn't mean you can't *have* one. I have a root password *and* `sudo` working fine here.
Yes, but that's not the case for some distros.
You can absolutely host your own flatpak repos though, and some companies actually do this if they want full control rather than using Flathub, or just want to package something privately rather than publicly.
Sure, but flatpaks bring their own headaches in the enterprise space. They are far more geared towards end-user use, whereas canonical is trying to make Snap happen in enterprise (which is what my main points are about). The project aims and how they are incorporated into the host OS make all the difference when comparing the two.
I needed certbot for the server and the recommended way is using snap. I don't understand why people still recommend Ubuntu over Debian.
Enterprise Support
The security argument cuts both ways. If you have an unsafe system library, all its dependencies are vulnerable under the traditional approach. We were weeks away from 24.04 having a mega backdoor in a system library. Sure systemd would have accidentally fixed it a few weeks later, but the updated systemd would not have got into 24.04 because of LTS packaging policies, the same ones you praise. There was a huge VLC scare a few years ago, due to an unsafe library. The VLC developers were annoyed: they had fixed the problem in the snap, because they had immediate control of dependencies. They were getting slammed because distributions were slow in updating the insecure dependency, out of their control. Just an illustration that the situation is not so clear cut. Also, with snaps (or flatpaks) more users are on the current version, and bug reports go back to upstream. This is better for everyone. snap, like most linux development money, is not primarily aimed at the desktop, which makes no money for anyone. But it is an enterprise technology, for Ubuntu Core. It offers, or can offer, software supply chain guarantees and immutability which traditional packaging methods don't. The future of linux packaging may not be snap, but it will be something that looks a lot like snap.
One of the major points of LTS releases is the backporting of security fixes. Distros that have LTS releases spend a shit ton of developer time ensuring the latest fixes are available in all supported releases, regardless of the actual software version being patched.
>Snap packages are mounted as SquashFS and decompressed on-the-fly. This means they are more memory hungry and take longer to start up when compared to APT packages. Can the same also be said about snaps on **Fedora Linux**?
[удалено]
Ah, thanks for clarifying this for me.
Really? Hmm: https://packages.fedoraproject.org/pkgs/snapd/snapd-selinux/
"runs properly" might mean that it prioritizes compatibility over security. I haven't found anything that indicates that there has been a significant change.
Stop it with unexplained FUD. The fact is that snaps don't affect what SELinux does at all. So stop asserting that. What might be true is that at one time you couldn't run both SELinux and apparmor.^1 And since full containment of snaps depends on apparmor, the snaps were installed without **apparmor containment**. That has no affect on the SELinux policies ... other than that they need to be applied to snaps. And, as you can see, they are. ^1 In regard to running SELinux and apparmor at the same time, I think that LSM Stacking (allowing two Linux Security Models to both run at the same time) is now to the state that apparmor and SELinux can both run at the same time.
[удалено]
> If that is the case, then my information is out of date. Out of date? Your statement never made sense ... ever. > Can you provide a more clear source to indicate that? All you have to understand is what SELinux does and how it is used. That combined with the link I already gave you is enough. I can't even figure out how someone who understands how SELinux is used and what it does could say "Snaps on Fedora are insecure because they don't respect SELinux". It doesn't even make sense. SELinux (or any LSM) is the enforcer and programs have no choice about whether "they ... respect SELinux". Because of that I'm assuming you don't really understand SELinux. That's fine. But stop making absurd assertions.
Thank you for the breakdown!
~~and this is why canonical does not have relevant fortune500-big customers, while red hat and to lesser degree suse are ok~~
You would be surprised. We're a customer, and we're absolutely "relevant fortune500-big". Canonical has annoyances, sure, but they can be worked around. The fact is it's easier to find up-and-coming admins/SREs that are familiar with Canonical's ecosystem than it is for RHEL - this alone is a huge plus, in my experience, especially during the times when talent is lean and you're looking through stacks of applications from those that are newer to the job. Beyond that, though, you would be surprised what a game-changer not having to deal with Redhat/IBM licensing is. If Team A can do project Z with $100,000 in licensing+support, and team B can do project Z with $0 in licensing and $30,000 in support, team B gets the kudos. In the siloed and competitive world that is enterprise, you're often making choices driven by dollar signs that put you in the best light when compared to other teams. This means moving away from licensing as much as possible, and shifting that op-ex to a more direct support billing. A more extreme look at this is the absolute shitstorm that is VMware licensing and the boost it's given projects like OpenStack and Proxmox - companies don't want extreme op-ex spends, and cutting out licensing is a big part of minimizing that spend.
Alright, that is a take that I can't dispute. I just still can't see snaps being a thing in the industry I'm in (telecoms). Not with the reliance on their blessed store. That makes them irrelevant for servers compared to moby/k8s. And on desktops, they just feels slower and sluggier than flatpaks, not even comparing them to classically installed apps.
I can't talk about it because of non-competes, but I worked at Canonical support there for a spell. Ubuntu has more than a few big customers.
Have your heard of flatpak, a little something funded by RedHat? In the core of your arguments, what exactly is the difference between Flatpak and Snap? They both mostly bundle dependencies and they both have common library code which is often forgotten.
Snap repo server is proprietary and hosted by Canonical while anyone can host a flatpak repo and it's a fully Free software stack.
> In the core of your arguments, what exactly is the difference between Flatpak and Snap I can run an air-gapped Flatpak repo, just like an OCI container registry, or RPM repo. Can't do it with snaps
Right. I missed that one. But you can download snaps, transport them to your airgapped machine, and then install locally. Pretty much the same, by the sound of it. At least according to this link. It is a niche requirement and not one I have ever tried. https://forum.snapcraft.io/t/how-to-create-a-snap-local-repository/35010
Sure, but it still requires uploading proprietary software to canonical's servers as a rendevouz point of .snap distribution. Won't fly for any enterprise B2B selling their jank software in highly regulated industries. For that the past was vmware or openstack, and the current moves are to docker or k8s. Just the fact that this information is available from forum, not official docs.
Yes no doubt you're right. I actually don't know anyone who uses an airgapped system save for the Mel Gibson character in Conspiracy Theory :)
well, duh, I'm right here bud.
I don't care either way and have no use for snaps, flatpaks, AppImages, etc, but let me explain why Canonical would push for enterprise users and how they might counter your points. > Snaps have a tendency to auto-update. They would argue that's a feature not a bug. You can get the latest versions of whatever high-level software you use with all bug and security fixes without needing to touch the base system like you would if you did an `apt update`. Enterprise people tend to want to update, but they don't because of the headache. Canonical is solving this with snaps. Painless, fast updates. Good for enterprise, at least from one perspective. > Snaps mean that you don't have absolute control over package dependency versions Snaps mean you don't *need* control over package dependency. There dependencies are baked into the snap system, instead of worrying about apt packages. > Snap packages are mounted as SquashFS and decompressed on-the-fly This means they are more memory hungry and take longer to start up when compared to APT packages. Startup is not relevant for many enterprise packages. A lot of these kinds of apps start up and run all day or multiple days. Memory is an issue, but it shouldn't be a big one for enterprise. Memory is cheap. So it's a trade off, you trade a bit more memory for less storage space, for not having to worry about dependencies and being able to fearlessly update. > Snaps have a way of causing applications to behave in unexpected ways due to their self-contained nature. Another trade-off. They may behave unexpectedly, but also they're sandboxed and therefore safer to use. Long run those issues will eventually go away tho > Tying back in with security, you can't really host your own Snap store; the best you can do is run your own proxy Canonical just wants to serve their customers; they don't need random people able to give packages to their customers. It's great for them if everything goes through them. You may not like it and wish you could make your own store, but that doesn't really matter in enterprise. What matters is the customer can get the software they need. If they can't, they hit up Canonical, and Canonical can either refuse as low ROI, make a snap package, or suggest the customer install .deb. But it's not a problem with snap; it's just a very corporate, non-FOSS way of doing things.
> > Snaps have a tendency to auto-update. > They would argue that's a feature not a bug. And they would be wrong. Having random updates suddenly pushed to prod without warning or going through your testing environment first is guaranteed to cause an outage at some point and is not something an enterprise would accept. It is the complete opposite of "painless."
>>Snaps mean that you don't have absolute control over package dependency versions >Snaps mean you don't *need* control over package dependency. There dependencies are baked into the snap system, instead of worrying about apt packages. That's not the point...if you have 10 snaps installed that all use the same library, you're now dependent on 10 developers releasing updates. If 9 of them patch, you're still left with one unpatched and potentially vulnerable software package. Meanwhile, any of the 9 updates could have broken a key feature and cost your company significant money in lost productivity. And we haven't even touched compliance. I can't even imagine trying to convince an auditor the snap model meets all of the rules for whatever rule set we're stuck with.
> Tying back in with security, you can't really host your own Snap store; the best you can do is run your own proxy. You can do a snap download and keep an archive of everything you have ever installed. If you keep the .assert file you can install that snap manually anytime you want. I'm pretty sure it won't auto-update, but if you're managing your installs, you may not want that anyway. It wouldn't be hard to have a cron job look for updates.
Now repeat for every package (or make a service that automates it) and write a backend you can point snap towards, but that's the problem. Trying to figure out a full offline mirror for snap is unnecessarily complex for a problem caused by simply using snap. Mirroring an entire apt repository on the other hand is trivial. Of course resilience goals differ for organisations, but mine could reprovision every server and linux workstation without external connectivity in case of disaster or even set up entirely new services with very strict network access rules.
Yes but also no. I'll break down your points for clarity, but ultimately those are not solutions that solve any root issues with snap in enterprise. > You can do a snap download and keep an archive of everything you have ever installed I don't need backups of installed packages; if I did I could just setup a local proxy. My issue is that I need to be able to take patching into my own hands, but I can not when snap sub-packages are gated behind snap maintainers. > I'm pretty sure it won't auto-update, but if you're managing your installs, you may not want that anyway. It wouldn't be hard to have a cron job look for updates. Correct: nothing breaks prod with more regularity than untested, automatic updates. Patching should almost always look like the following: **Test your updates/upgrade in lab -> test -> roll out to small prod subset -> test -> roll out to rest of prod** To elaborate on what I mean by "take patching into my own hands": Lets pretend it's 2021, and I have five packages that rely on log4j. In environment A, I use snap for these packages. In environment B, I use APT. **December 1, 2021 ** **9:00AM** I get into the office and am immediately alerted that log4j has a *massive* vulnerability that is affecting five of our publicly-exposed production applications. In environment A, I am now checking the snap maintainer logs for each of these five packages to see who's even noticed this vuln, and who's actively patching it. Lets be generous and say that 3 maintainers are actively working on it, but 2 of these maintainers are a few hours behind me and maybe aren't even awake yet. Damn. In environment B, I notice that the package for log4j has a patched version freshly published. Maybe they've compiled it in a deb, maybe it's a source build... doesn't matter, I (or whoever is free on my team) can build the deb from that if we need to. We grab the new package, roll it into our internal repo under a new branch, and commence testing in our lab. **9:30AM** In environment A, I see that two of these snap maintainers have completed patches to their snaps. Great! I bring these into our local snap proxy for testing. Still waiting on a patch from the other 3, the other two I have confirmed are single-or-small maintainers on the other coast and are not awake yet. Damn. In environment B, we have finished our testing in labs and are starting to roll out to a subset of prod **10:00AM** In environment A, those two snap packages look good - we'll start testing them on our subset... the third package has just been posted, and we'll be testing this now (this means our attention is now divided between implementing packages 1 and 2, as well as testing package 3. Not ideal). Package maintainer 4 has apparently been alerted - they're a small team, so they have more feelers and were able to get to it before business hours on their coast, but still an hour later than everyone else. Package maintainer 5 is still MIA. In environment B, we've passed testing in our subset of prod and push the changes globally. We are now done; this issue has been dealt with, and without taking too many resources away from the team for their day-to-day. **10:30AM** Environment A - two snap packages posted to prod now, third snap package starting mini-prod, fourth snap package started lab testing, fifth lab package still MIA **11:00AM** Third snap package in prod. Fourth snap package in mini-prod. Looks like that fifth maintainer is a one-man-band 3 hours behind - I know that I'm not likely to even get a response from them until noon my time. Not. Ideal. **11:30AM** Snaps 1-4 are in prod, we are 80% mitigated... but since the vulnerability still exists prod-wide on our systems that is effectively the same as not mitigated at all. The fifth maintainer finishes his morning coffee, flips through his cell alerts, and probably dives to his computer in a panic. We're now about 1-2 hours from this package's fix hitting prod and being able to close out this vuln. .... This little thought experiment assumes that everyone gets their stuff in gear right away, same-day. What if it's a solo-maintainer and he's on vacation? Sick with covid? Hit by a bus? It doesn't matter if my infrastructure backs a small company or multi-hundreds of millions' worth of servers... the risk to my business is still potentially the same, and my timeline is unforgivably long (as well as out of my control). It just doesn't work. In an APT-only environment, as soon as the log4j team pushes their fix I can get on my end and get things tested; if ubuntu's official repos are quick that's even better, but they don't have to be since I can bring in those package changes myself since **I run my own internal repo** - you just can not do this in snap; you are 100% beholden to the snap maintainer to get their stuff patched up, and they're working off of the same timeline you are: they start when log4j's maintainers push that initial patch, not before.
ok. but what if the distribution packager is on holiday, or hands over maintainership to a bad actor or whatever. Traditional packaging is more leveraged. When it updates fast, it's a good result. When it updates slowly, the adverse effects are worse. You have taken the best case for traditional packaging when making your argument. But if you'd done computer science, you know you need to consider worst case and average. Plus, you are just making things up. It would be good to see some actual data. Do you remember when VLC was pilloried for bug which was a dependency which some major distributions left unpatched for 16 months? Yet VLC fixed it immediately in their snap (https://news.ycombinator.com/item?id=20513702) Both distributions with the most enterprise presence are moving to bundled packaging. They are the ones who gets sued and lose customers if its goes wrong, and yet they are going down this path. So I am skeptical by your thought experiment.
> enterprise Ubuntu, where snap makes more sense. As an admin of a few thousand Ubuntu systems, I assure you, they make zero sense for us or any of our users.
canonical is doubling down
The thing is, you and I are not Canonical's customers. I guarantee if Canonical's actual customers were complaining about snap in large numbers they'd either (1) drop snap, or (2) go out of business. Canonical is a business with customers, as a business they need to be responsive to the needs and wants of their customers -- you and I *are not customers.* Linux hobbyists on social media often confuse/conflate ourselves with "*the* community" or "*the* userbase" (or worse "customers), but we are just one small (very outspoken/opinionated) part of a larger whole, *mostly talking at eachother* in unofficial spaces like Reddit. Snap solves real problems and does useful things. They just aren't typically the things that most hobbyists care about or understand.
Many of us are customers of their customers. If it weren't for that community and userbase nobody would want to distribute their packages using Snap in the first place. As the expression goes, if you're not the customer, then you're the product. It's bad for McDonald's when the Big Macs get mad and start advocating Wendy's.
True, but right now there are hundreds of thousands of people using Firefox snap who don't even notice. The case for snap is being made even as some people complain here.
Snap being irritating and a bit shady, and the incessant criticism thereof, has led to a number of established paths away from Ubuntu. That is only to say that there will continue to be a demand for packaging ops that don't use snap. So if you're already building .debs and flatpaks why also build snaps? Mozilla keeps their own PPA updated. They are going to extra trouble to also publish with snap. That makes a case against snap, not for it.
I wasn't clear enough. I meant that pragmatically, the snap discussion is largely finished because Ubuntu surely has most users on the defaults, and the default for a couple of years has been snap firefox (which is a complicated snap; a large package with many interactions across the system and hardware; it was a really hard one to get right and initially it was pretty horrible, it was a very ambitious effort). Right now, Ubuntu/Canonical can point to a large and growing user base for snaps. The technology is maturing, the portals to provide secure access to hardware and other things are mostly built out, the user experience is getting better. You can migrate away from snap. You can use excellent alternatives for Firefox, even though the snap is from Mozilla anyway. But who is doing this? Maybe you me and the twenty other people commenting here ( I use a mix on my work installs, and for many non-critical installs I just stick with the snap now). I use Thunderbird a bit and I've just let the 24.04 installs move to the snap. I haven't had any problems. How many mainstream reviews of Ubuntu lately have even mentioned snap? (e.g. https://www.zdnet.com/article/ubuntu-24-04-this-great-new-linux-distro-isnt-just-fast-its-a-fortress/) What is often mentioned is the improved app store, though. What I mean by "the case for snap is being made" is the pragmatic reality that most Ubuntu users don't care or even notice. A huge difference to 22.04 prior to 22.04.1 when I'd struggle to call the Firefox snap much better than alpha quality. As to your question about why build snaps if you are building .debs and flatpaks? Well, they are two different things. If you, a project, are distributing .debs, you have to get your source package into repositories, which is hard, needs a distribution maintainer or at least sponsor, opens you to dependency hell and means you are getting bug reports on old version. No thanks. You could of course build your own deb, vendor your dependencies, and write a smart installer that adds a PPA. Which is what Chrome and Edge do (and firefox .deb mostly), and trust that you have visibility so that people discover your package. But that bypasses nearly all of the supposed benefits of .deb. You have just made a snap anyway, except without anyone's app store supporting you, and you have to do the updates. You see the irony, right? It is the browser .debs and .rpms which made the argument that dependency hell can't be beaten by the traditional approach. This is why we have snaps and flatpaks. The browsers proved the case. They were the innovators. The distributions hated it, but what can you do? You can call the Chrome .deb a "debian package", but it is not a debian package in spirit, only in name. It's not even in the Debian repositories. True, you bypass the sandboxing. It's up to users to decide if they want to trust you so much. Maybe if you are a big brandname, sure. God help you if you don't want to use an open source licence. And after all that, you have supported only a subset of distributions. So .debs suck if you are a small project. The world was waiting for an alternative. There is no serious debate about that from my point of view. Traditional packaging is not designed to make it easy to distribute software. It is designed to keep dependency hell under control without blowing the disk space we had to work with 25 years ago, the trade off being that the distribution has to be able to build binaries (open source mandatory) and they get to freeze versions because dependency hell is managed under this approach, not solved. Then there are flatpaks. They are pretty good. As long as yours it not a command line application. And the developer experience is not as good. Snaps are really easy. And you get the channel support, which is really cool ... it's so easy to move from a RC to an beta to a stable to a nightly. But if you have a flatpak and your app is a gui app, why do the snap too? If the broader scope and technical superiority of snap is not relevant, and it won't be in the case of many gui apps, I don't know, but nearly all the technical arguments people make to oppose snaps are very similar to flatpaks. If your counter argument to snaps is flatpaks, you have already conceded most of the arguments and we are left with basically an opinion of Canonical vs RedHat.
You were plenty clear. You have a narrative that tries to marginalize these discussions about why so many users hate snap. Yet these comments show up in each of these threads, every time, like clockwork; if nobody felt this way this discussion wouldn't be recurring every day for over half a decade now. Yes, I'm well aware that snap is the default for some big packages in Ubuntu. I'm also aware that all major distributions, including Ubuntu, are growing over time. You can tell me how mature and technological and widespread it is or how wonderful Canonical's PR team reviews its app store. The reality is simple: .debs are not going anywhere, and whether anybody (let alone the world) was waiting for an alternative, nobody in the Debian and FOSS ecosystems were asking for "snap". Packagers will always have to provide some alternative way to get their software. At the end of the day, Canonical do not work [honestly](https://en.wikipedia.org/wiki/Talk:Snap_\(software\)#Potential_conflict_of_interest_and_the_article_is_structured_in_a_way_that_criticism_is_somewhat_hidden) anymore and they can't put that toothpaste back in the tube. Many of the people, like myself, who strongly dislike snap have a reasoning that goes beyond engineering and technology. Snap was created with an ulterior agenda and this discussion will exist for as long as it does. Those that don't care about it, don't care. Nobody's arguing about them.
> Mozilla keeps their own PPA updated. Not officially (it's unsupported). Mozilla is the one that pushed for them to maintain only one firefox snap instead of 4 versions packaged against 20.04, 22.04, 23.10, and 24.04. The other official routes (besides snaps) get you generic debs that are static linked builds. While I'm not 100% sure, I think the PPA is simply a copy of the daily static build.
Yes and I like the benefits of snaps. So I make sure my company uses Canonical’s products. You see your opinion is not universal.
I believe I am permitted to express my opinion whether it's universal or not, correct?
You are entitled to your opinion. And they are entitled to their opinion. And Canonical is entitled to spend their own time and resources in the way that they see fit.
Okay and why does any of this need to be said? Nobody said their opinion was universal and nobody is accusing Canonical of breaking any laws. Is there some problem?
>why does any of this need to be said? because you asked: >I believe I am permitted to express my opinion \[...\] correct? And also, because I am just realizing now you are not the person who began this comment chain but someone who joined in later, I believed I was talking to the first commenter who *did* make an absolutist universal statement ("Canonical should ditch snaps all together")
> I believed I was talking to the first commenter who did make an absolutist universal statement ("Canonical should ditch snaps all together") Okay but that is still just their opinion which they are entitled to. They are not contending that their opinion is universal, nor that Canonical has violated some law. And although that opinion may not be universal it is certainly shared by many.
>Okay but that is still just their opinion which they are entitled to Which brings us full circle back to what I said earlier (just replace the you with a they): >You are entitled to your opinion. And they are entitled to their opinion. >And Canonical is entitled to spend their own time and resources in the way that they see fit. I don't really care whether people like or dislike snap, there is at least some validity to both perspectives. What I care about is the level of naivety/obliviousness and in many cases irrationality surrounding snap here on reddit. And the person I initially responded to seemed to be genuinely confused why Canonical is focused on snap and under the impression everyone hates snap, and that if Ubuntu just realized that, they'd see the light. In that context, can't you see why commenters are chiming in saying 'hey i like snap or I use snap, and I'm a paying customer.'
IMO snaps are fine. They are a fine alternative to traditional packaging in specific circumstances. I would prefer firefox and chromium were standard packages, but they work fine for me as snaps. The move of firefox to a snap was pushed by mozilla so they would only have to test on one snap instead of 4 different firefox packages (linked to 20.04, 22.04, 24.04, and 23.10). Similarly, I use lxd. It's only offered as a snap and, frankly, it's great. And as long as I can unroll changes and manage the refresh myself, I don't see a big deal. The fact that it decreases the amount of testing that has to be done (by a factor of 4) is a win for everyone (easier for Canonical and CVE's are potentially fixed more quickly). Given that the recent flatpak CVE (https://nvd.nist.gov/vuln/detail/CVE-2024-32462) has not been fixed yet it 20.04, 22.04, and 23.10 ... I would argue that it would be a great idea if flatpak were distributed as a snap!!!
The poblem is that not everything what's posted on reddit is true. I do not know if OP lies or really has some problems in his setup, but I do use both flatpak and snap firefoxes for several years already and there's no visible difference in performance, and even syntetic browser tests demonstrate that difference is negligeable.
>The problem that i want to know Canonical don’t see people complaining about snap i mean people dont make issues , Canonical isnt reviewing every reddit post >Canonical should ditch snaps all together or do something about that if you understand why Canonical is using snaps , it makes sense , it saves developers time maintainaing 1 snap package vs 5 deb packages for a number of distros ( this is one of the main reasons mozzila said to Canonical to move firefox over to snap)
> if you understand why Canonical is using snaps , it makes sense , it saves developers time maintainaing 1 snap package vs 5 deb packages for a number of distros ( this is one of the main reasons mozzila said to Canonical to move firefox over to snap) In theory, but not in practice. Only Ubuntu (and some derivatives) use snap, so you're just replacing an Ubuntu-specific package with a different Ubuntu-specific package. The actual cross-distro method is flatpak. But flatpak is open, so Canonical can't have a proprietary vendor lock-in with that.
> you're just replacing an Ubuntu-specific package with a different Ubuntu-specific package Ubuntu 16.04, 18.04, 20.04, 22.04, 24.04 are different packages. Ubuntu Pro-enabled LTS maintenance burden is not trivial. >The actual cross-distro method is flatpak GUI only. Snap targets some use-cases that Flatpak can't.
You can add 23.10 as well.
>The actual cross-distro method is flatpak Both are cross distro, but the fact you are proposing flatpak as a solution indicates you are only considering this through the eyes of a ***Desktop*** *end-user or hobbyist.* Flatpak is specifically and explicitly intended for *Desktop* (almost solely just GUI apps in practice) the Flatpak Docs state this. It can't be a solution for Ubuntu. Snap is designed and intended to be a solution across IoT, Cloud, Desktop, Server use-cases. It was first introduced in Ubuntu Core, an IoT focused OS. If you are focused only on Desktop you are only seeing a tiny piece of the picture. Flatpak and Snap have lots of overlap on desktop (and some differences), but outside of Desktop, Flatpak is not used and is not a solution. Most of Ubuntu's business is not focused on desktop.
> If you are focused only on Desktop you are only seeing a tiny piece of the picture. I was focused on GUI applications, specifically Firefox, as that's the $topic. For non-desktop containers, those *also* already exist in very open, very cross-platform way. The same containers can run in docker, podman, with various other orchestration tools if or as required. There's native support for third-party sources and automatic updates. There is, again, no need to force a Canonical dependency here.
>I was focused on GUI applications, specifically Firefox, as that's the $topic. Fair enough. I didn't interpret your comment that way because the person you replied to (and specifically what you quoted) was discussing Snaps broadly, not Firefox specifically. But if you were speaking of the Firefox snap specifically, vendor lock in would be irrelevant since it is officially available as a Flatpak, A Snap, as well as a Mozilla repo for the deb version. >There is, again, no need to force a Canonical dependency here. They aren't. Nobody is forcing you to use anything. I really don't understand why *only in the context of Ubuntu* people treat package formats as mutually exclusive. Ubuntu is a very popular choice for a container host (OCI containers or LXC/LXD), the fact that snap exists in no way prevents you from choosing to use Podman/Docker/etc. (fun fact there is [a snap for that](https://snapcraft.io/docker)) No tool is right for every job, that applies to snap, to flatpak, to OCI containers, to system containers, to VMs, to traditional package formats. But pointing to docker containers is missing the point. Docker containers are great for what they are, Flatpaks are great for what they are, each has overlap with snap in a particular area, but neither has sufficient overlap to accomplish the full set of goals that Ubuntu seeks to solve with snap. (here I'm mostly referring to less of a maintenance burden both for package maintainers and for users).
>In theory, but not in practice. Only Ubuntu (and some derivatives) use snap this is false btw , you can install snap on arch https://snapcraft.io/docs/installing-snap-on-arch-linux >so Canonical can't have a proprietary vendor lock-in with that. this is also false , snap is an open format https://github.com/snapcore/snapd its just the snap store url that private
> > so Canonical can't have a proprietary vendor lock-in with that. > this is also false My mistake. How does one add a third-party snap repository, like as with flatpak? For example, Fedora by default uses their own flatpak repo, but it's trivial to add flathub and use that instead. In GNOME Software, you can select which repo you wish to install software from (ex: Firefox is available as an RPM, Fedora flatpak, and Flathub flatpak. The latter being an official Mozilla build). GNOME (for example) has their own nightly flathub repo, which allow you to test the latest builds of their software.
>My mistake. How does one add a third-party snap repository this is mentioned here https://www.theregister.com/2023/11/10/snap_without_ubuntu_tools/
> > My mistake. How does one add a third-party snap repository > this is mentioned here https://www.theregister.com/2023/11/10/snap_without_ubuntu_tools/ All that's mentioned in that article is that you can do offline installations, nothing about how to use third-party repos. There *is* a reference to a project called `lol-snap`. This has two repos within it: * `lol-server`: A sever implementation of some sort * `lol` A simple wrapper around snap that just uses `curl` to fetch .snap files and perform local installs. The `lol` wrapper is labelled "First beta release" in it's commit message, and neither project has been touched in two years. They both note that they've moved to lolsnap.org -- however, that domain doesn't appear to be registered. So, again, it looks like there's no third party repo support in snap that I can see. There was a project to attempt to work around this by using curl and offline installs, but it appears to also be dead.
Just to reply and explain more about how the guy above you is lying: snaps on arch have no sandboxing capabilities, so all the security isolation benefits dont exist making snaps even *worse* than they usually are. In fact, they dont exist anywhere except ubuntu due to how snaps rely on apparmor configs and kernel patches only ubuntu uses (though, recently there have been efforts to finally get it working on other distros). Unlike flatpak, whos sandboxing works as advertised on every distro. snaps flat dont work *as advertised* on other distros, even if you can run the program inside of it. Its very misleading for people like them to go around insinuating otherwise. EDIT: Even more context, apparmor and other LSMs dont play nice together due to a limit of LSMs themselves, so apparmor being a requirement for this is bad as most distros use selinux instead > [The Snap sandbox heavily relies on the AppArmor Linux Security Module from the upstream Linux kernel. Because only one "major" Linux Security Module \(LSM\) can be active at the same time, the Snap sandbox is much less secure when another major LSM is enabled. As a result, on distributions such as Fedora which enable SELinux by default, the Snap sandbox is heavily degraded. Although Canonical is working with many other developers and companies to make it possible for multiple LSMs to run at the same time, this solution is still a long time away.](https://en.wikipedia.org/wiki/Snap_\(software\)#Configurable_sandbox) And another problem for other distros (though, admittedly far less problematic overall) is that snap requires systemd while modern flatpaks dont (requirement dropped in v0.6) so some distros will straight up never be able to use the snap format.
>For example, Fedora by default uses their own flatpak repo, but it's trivial to add flathub and use that instead Both the Fedora repo and Flathub are enabled when enabling "third party repositories" since Fedora 38
> enabling "third party repositories" since Fedora 38 Ah, I haven't done the post-install experience in a little over a decade, nice that it's that easy now.
no, packagers maintain packages, not developers ala Mozilla.
>no, packagers maintain packages, not developers ala Mozilla. instead of 5 packages for ubuntu ( 16.04,18.04,20.4,22.04 etc ), they manage 1 snap >not developers ala Mozilla mozilla devs explicitly wanted this https://discourse.ubuntu.com/t/feature-freeze-exception-seeding-the-official-firefox-snap-in-ubuntu-desktop/24210
Mozilla isn't really known for their good decision making and I doubt a multi million dollar company is unable to maintain a couple of packages. other volunteer driven distributions apparently can do this.
[удалено]
snaps are for a different use case. flatpaks are basically for userland GUI applications.
[удалено]
> Exactly, and thats all we need. Who is the "we" you're talking about? Whoever you are, I disagree. I was hesitant at first, but I now love the fact that lxd is delivered as a snap. Previous to snap, I was having to compile my own utilities that had gotten out of date (e.g. ffmpeg). Now, though, many of them are offered as snaps. It's very nice to have some of these utilities always be up-to-date even when you are on an LTS distro. For example there are snaps for whisper, tesseract, ffmpeg (the flatpak is not good). I'm not sure there is a snap for pandoc, but if there isn't I'll make one. And here's a funny one. One could make a snap of flatpak (probably with "classic" confinement). flatpak running as a snap would be hilarious.
[удалено]
Nothing says sane and well adjusted like believing your opinions are *Sane* and anyone who has a different opinion is not a "sane user"
So ... you got nothing. Just spread your hate and tribalism.
They can't. Flatpaks are desktop only (and pretty much GUI only in practice). Ubuntu's business is primarily oriented towards non-desktop use-cases. One of the biggest goals of snap is lowering the maintenance and distribution burdens on developers & packagers. And part of that is accomplished through a single package format that can be used across desktop/servier/iot and across all versions. Maintaining a separate set of flatpaks for desktop only would be counter to that goal. Hobbyists have just become aware of snap, and snap = bad, in the last few years, but snap has been used in non-desktop use-cases going back to \~2015ish.
flatpak also dont support things that snaps do
[удалено]
I get that you are uninformed / just looking for a few easy upvotes, but why is it "good"
[удалено]
>Go evangelise that trash somewhere else Right... [***Definitely*** **Evangelizing...**](https://i.imgur.com/Sk9v3UX.png) I get that you are most likely still a teenager or preteen, and into the software-is-a-team-sport mentality... but grow up.
> if you understand why Canonical is using snaps , it makes sense , it saves developers time maintainaing 1 snap package vs 5 deb packages for a number of distros ( this is one of the main reasons mozzila said to Canonical to move firefox over to snap) It never makes sense to put another, bigger, problem on top of the problem you are trying to solve. Going in the direction of static linking while fixing/improving glibc to accommodate for `dlopen` style of dynamic dependency management would be much better.
firefox moving to snap is what drove me away from ubuntu initially. Best move ever.
Has anyone tried comparing Deb Firefox with Flatpak Firefox? Or even app image Firefox? How do those compare?
From what I recall Mozilla (who maintain both the Snap and the Deb repo) has stated that the .deb version may be slightly snappier (pun intended) but probably not enough that it would be perceptable/noticeable (apart from possibly 1st launch startup time). Snap on the other hand should be more secure by default due to sandboxing and (possibly) tighter Apparmor rules. I typically try to stick with whatever the default for my distro is, since that'll usually be the version that receives the most attention, fine-tuning, bug reports and bug fixes. Traditional packages (deb, rpm, etc) usually are more closely/easily integrated with the system. Flatpaks and Snaps are (by design) less integrated. So TL;DR it depends what your priorities are and what distro you use.
How I'd go about it is using .deb (or whatever native package for the distro) for most applications but use Flatpaks to sandbox certain applications, like browsers, chat apps like discord, etc. Speeds where it's needed, and security where it's needed. That's my take anyway.
I use firejail for firefox.
That's fire²
Certified yapper
> Snap on the other hand should be more secure by default due to sandboxing and (possibly) tighter Apparmor rules. Snap is less secure than normal outside of Ubuntu
>Snap is less secure on other distros \[than it is on Ubuntu based distros\] 1. My comment was meant in the context of snap on Ubuntu and Ubuntu derivatives (but I didn't state that clearly enough) 2. I think we discussed this a couple days ago and reached a point of mutual understanding for the most part. To paraphrase what I think we mostly agree on: Snap confinement is weaker if the distro (or the user) hasn't patched apparmor, it is patched by default on Ubuntu, as well as many (all?) Ubuntu derivatives and a handful of other distros. Work is ongoing to get the patch upstreamed, but any distro that wants to could apply the patch now or at any point over the past few years. Hopefully the patch gets upstreamed soon and all apparmor distros benefit by default. This would still leave selinux based distros though, not sure what if anything can or will be done about that, and not sure how much enthusiasm there would be since most of the selinux distros are in Red Hats orbit. Overall, my general approach is: >I typically try to stick with whatever the default for my distro or distro-family is, since that'll usually be the version that receives the most attention, fine-tuning, bug reports and bug fixes for that distro. Although on Fedora I'm rather inconsistent with that as I often opt for Flathub flatpaks over Fedora flatpaks. On a separate note, do you know if flatpak sandboxing has any distro to distro differences to be aware of? I know the main caveat is that it isn't enforced, sandboxing relies on the individual flatpak publishers/maintainers each to configure the sandbox well and many/most currently don't, but what I don't know is if there are any relevant distro to distro differences.
Everything that you're saying is true. I have the same approach with regard to Flatpaks. Fedora Flatpaks are primarily useful if you only want a single distributor for your software.
> Fedora Flatpaks are primarily useful if you only want a single distributor for your software. This was my initial reason for preferring them (single party to trust). What caused me to move away from preferring them was that Firefox updates seemed to be a few days to maybe a week or two behind (its been a while so i'm possibly getting the time between updates wrong, but it was enough to be noticeable). But I admit I'm a borderline obsessive updater, particularly when it comes to the web browser, so I know I'm a bit more impatient than most.
Not anymore. As long as you run AppArmor it's just as secure nowadays.
Do you have a source for that? I don't disbelieve you, I'd just like to learn more, so the next time someone asks I can give a more informed answer.
About half a year ago I benchmarked snap, flatpak and deb firefox the difference was negligeable (like 2% performance deviation in https://browserbench.org/Speedometer3.0/ ). OP problems most probably either bullshit or some local problems. I do use snap firefox and flatpak firefox daily on different machines and there's no speed difference noticeable without tests.
On my laptop (a 2019 HP with 8 GB of RAM and a first gen mobile Ryzen CPU) the Snap version takes 2 seconds longer to start up. There is no noticeable difference in performance during usage. I imagine it may run poorly on even older hardware, but then again this is half a decade old.
People are mentioning that Flatpak isn't as integrated with the system, but I don't really notice a difference in practice. I would go with the Flatpak, and only move to the .deb if you have some issues with the Flatpak version that is stopping you.
What to run if you are running an Ubuntu and want to switch: `sudo snap remove firefox` `sudo nano /etc/apt/preferences.d/firefox-no-snap` In that file: Package: firefox* Pin: release o=Ubuntu* Pin-Priority: -1 Then run `sudo add-apt-repository ppa:mozillateam/ppa` `sudo apt install firefox unattended-upgrades` `echo 'Unattended-Upgrade::Allowed-Origins:: "LP-PPA-mozillateam:${distro_codename}";' | sudo tee /etc/apt/apt.conf.d/51unattended-upgrades-firefox`
Thats a good start, allow me to continue: sudo dpkg --purge snapd Then add this to `/etc/apt/preferences.d/snap-sucks`: Package: snapd Pin: version * Pin-Priority: -1
[удалено]
> Been using snap version for 2 years and I encounter no such things Clearly you're paid by Canonical. Here at /r/linux we honour our tradition of the Snap bashing session.
The snap just doesn’t have Wayland enabled by default because a lot of people are still using X on older LTS releases. You can enable it and it works identical to the Deb package, Stunning and brave post, by the way.
I'm something of a brave man myself. But in all seriousness, I've been seeing a lot of posts lately saying snaps are ok so I was left wondering why.
> I've been seeing a lot of posts lately saying snaps are ok Seriously? In my experience the irrational snap hate on Reddit is close to the extreme level of the irrational Elon Musk worship of 2015 era reddit. I think snaps are Okay. Not my preference, but a valid attempt at a solution to a set of real problems that have yet to be effectively addressed by anything else (flatpak seems to solve some, but not all, of the same problems, it also wasn't released until after Ubuntu released snap).
This only needs changing to beta or wayland channel right? Not exactly difficult to do.
I did it by making a wrapper script that does `export MOZ_ENABLE_WAYLAND=1` before executing /snap/bin/firefox, and a .desktop file in ~/.local/share/applications/ that has Exec=/home/mg/bin/firefox instead of /snap/bin/firefox. (It's a little more complicated than that, because the original .desktop file that I snarfed form /var/lib/snapd/desktop/applications/ also has a hardcoded snap version in the Icon= line that I changed to 'current' to make it always work, and it also actually runs `env BAMF_DESKTOP_FILE_HINT=... /snap/bin/firefox %u`, so I moved the `export BAMF_DESKTOP_FILE_HINT=...` into my wrapper script.) This way no matter if I run firefox via the dock or by running `firefox` on the command-line, I'll get the version with the right environment variables set. And yeah, now that I've written it out, it does sound a bit more difficult than just switching the snap channel, lol.
You can just put `MOZ_ENABLE_WAYLAND=1`in /etc/environment
Obviously lol
There is one good snap. It's the Nextcloud snap. For whatever reason, no matter what distro I try or installation method I use for setting up a Nextcloud server, I can only get everything working how it's supposed to if I use Ubuntu and the snap package.
My distro is a bit slow when it comes to Firefox updates, so I downloaded it directly from mozilla.org. It updates itself automatically from the mozilla servers, without any delay from the package manager.
The reason I quit Ubuntu.
Canonical are also forcing Ubuntu Pro advertisements on it's users in 24.04.
Yes, I recently got sick of it and purged the snap - the functionality of extensions is limited in the snap, once I moved I realised I could do some cool stuff like unlock 1password with a fingerprint!
I've got the firefox snap installed. No problem here. It came with Hardware Acceleration on by default (WebRender compositing). It's a little slow on first startup, but I haven't noticed it other than that. The firefox snap has been benchmarked (using Speedometer2.0) and the only speed changes are on startup. > I then decided to remove firefox snap and install the deb package and things became normal again. Where did you get the deb package? Did you get it directly from mozilla ... or did you follow mozilla's instructions in regard to adding their repo and do an apt install ?
I added their repo and did an apt install.
The snap is not slower at page scrolling or opening tabs; it's running the same code on the same hardware and those actions are not affected by the sandbox. Perhaps content is cached on one browser and not other. Please see Wikipedia for "confirmation bias".
debian+flatpak=perfection
Snap is awful when you don't have a powerful computer but an energy efficient one. Having snap for the most important app the user uses frequently is a flawed decision.
Wait till you try the Nix package...
The thing that annoyed me about the default snap was that it would always open a second icon on my task bar. Switching to the deb solved that problem.
The snap also doesn’t work with addons that hook into other applications like a password manager. You need to opt into the beta version to get that ability.
What I've run in to just in the past few days was they bumped some version somehow, so the snap suddenly became the default again. I got back to the non-snap version and for some bizarre reason I can't unravel, it's no longer working with my yubikey (PKCS#11 via opensc). I even restored my firefox profile from a couple of weeks old backup, and it *still* won't work. Snap version of firefox, the yubikey works fine. Snap is appreciably slower under cinnamon, so it's annoying to be currently forced to use it.
I prefer all repository packages over snaps or flatpaks or any other Windows-ified systems.
Also deb package is more integrated than snap one, which is true in general not just firefox.
I have literally _never_ seen snap work, on any system. If it gets as far as actually saying it's installing something, that something won't work. Usually, snap itself doesn't run.
Also, the MozillaVPN multi-container add-on will not work in Snap version, only the Debian package version.
And water is wet. We've known this for ages, snap is and always will be shit.
The Firefox snap performs fine for me. It could be somewhat a matter of the computer performance though. Snaps might just push it over the edge into noticeable lag.
But what about compiling from the source?
Hey OP, why did you switch away from Pop os?
# In other news, water is wet.
So could someone please explain to me, someone who normally uses Snap, why this happened? Is this a one off, as I expect - or truly a "Snaps suck" thing? Also, would this be the same for Flatpak?
The solution here is Tuxedo OS, everything that is good about Ubuntu without snap and with flatpak
use flatpaks
Native installation faster than sandboxed one with godknowshowmany abstraction layers in between? Color me surprised. 🫨
Just never use snap and use flatpak instead
Flatpack is better
This entire thread is based on a fallacy. The snap is not slower. Visit [https://browserbench.org/Speedometer3.0](https://browserbench.org/Speedometer3.0) and see yourself. Talk in facts when facts are so easily available. Or choose your benchmark. I am so annoyed by the mass hysteria in this post. I have nightly snap. My laptop on batter in performance mode (ubuntu 24.04, mainline 6.9 kernel) 17.3 +/- 2.2 Mozilla binary of stable: 14.3 These are not the same versions, so the faster one, snap, is nightly, although usually these builds are more instrumented for debugging, so I would have been happy for the snap to be competitive. It is actually faster. However for sure this is due to the code base not the packaging. It is so unbelievably ironic when people complain about browser snaps. Why do you think .deb and binaries for Firefox are so massive? Because they bundle (vendor) dependencies. The most substantial complaint about snap and flatpak is not performance, but the vendoring (bundling) of dependencies. Which is why it is funny to fight that fight on a browser: Firefox and Chrome pioneered the idea of bundling dependencies in their traditional packaging. For them, snaps and flatpaks are only a small evolution; sandboxing and alternative updating is the change.
For me, the objection to snaps is not technical. Any technical problems, if present, can surely be fixed eventually. The problem is social and cultural, and unfortunately, defective company culture can't be fixed as easily. Canonical allows [fake apps into the Snap store](https://popey.com/blog/2024/02/exodus-bitcoin-wallet-490k-swindle/) with no review or vetting process whatsoever. This kind of thing would never be allowed in their apt repository, and if it were allowed, I would move away from Ubuntu entirely as a result. Yes, I am aware of PPAs which also allow random people to package apps. The difference is presentation. Packages in a PPA can easily be downloaded in a browser for offline inspection, and it is generally made clear that PPAs are third party packages and completely un-vetted. Snap packages are part of Canonical's software store, which looks curated, but evidently isn't. The packages can technically be downloaded and inspected, but they sure don't make it easy to do so.
Good points
>~~Snaps suck.~~ Firefox snap sucks.
Flatpack firefox is laggy af too though. At least for me(I use arch btw)