Ask HN: Is it safe to remove snap from Ubuntu 22.04 LTS completely?
I was told that by removing snap on a fresh install of Ubuntu 22.04 LTS you are also removing containerized software and live kernel updates features. Is this true? It was my belief you just have to find replacement apps and make sure to enable unattended updates.
55 comments
Have you considered POP!_OS instead? It's based on Ubuntu 22.04, but it comes without snap by default [1].
As I mentioned before [2], snap is a hill I'm ready to die on, so after being a user for almost 15 years, I'm parting ways with Canonical. I respect their (likely commercial) decision to push forward with snap, but it's a compromise I'm not willing to accept, so I'm actively testing Debian and POP!_OS. I'm leaning towards the latter.
[1] https://www.theregister.com/2022/04/28/pop_os_2204_is_here/
[2] https://news.ycombinator.com/item?id=31103834#31105526
As I mentioned before [2], snap is a hill I'm ready to die on, so after being a user for almost 15 years, I'm parting ways with Canonical. I respect their (likely commercial) decision to push forward with snap, but it's a compromise I'm not willing to accept, so I'm actively testing Debian and POP!_OS. I'm leaning towards the latter.
[1] https://www.theregister.com/2022/04/28/pop_os_2204_is_here/
[2] https://news.ycombinator.com/item?id=31103834#31105526
I'm really happy with Debian. Ubuntu always felt like it had these unfortunate decisions I had to battle to get it the way I wanted, meanwhile Debian has had nothing but sane defaults and a smooth experience.
It comes with flatpak instead, which others dislike as well. I've never had issues with those though.
I've been keeping an eye on this OS, but will wait for their Rust desktop to try POP! out.
I've been keeping an eye on this OS, but will wait for their Rust desktop to try POP! out.
I feel exactly the same, and my choices for replacement were the same as yours. I ended up going with Pop because it just seems "cleaner".
I see a lot of things to like - including pipewire by default. But I'd prefer zfs native encryption to luks, and wayland to X11 - so I don't think I'll jump to Pop on the 22.04 release.
[deleted]
You will lose access to any software installed via a snap package. Snap software is "containerized" (to varying extents depending on the install mode and permissions) so you would lose access to "snap" containerized software speifically. There are other ways to run containerized software you wouldn't necessarily lose access to though are not installed or used by default and that can also be used at the same time as snap packages (e.g. flatpak, docker, etc).
There is some software installed by default on 22.04 by snap that has no Ubuntu-provided alternative "deb" package. This includes firefox and the "Ubuntu Software" store app (installed by default) and LXD (not installed by default, but if you want to use it, there is no deb package). If you're not using any such snap software, it may not matter. In some cases you may be able to install software through some other non-snap method from a non-Ubuntu source (e.g. you may be able to install firefox using the standard linux installer, though I have not tried that).
With regards to the Ubuntu live kernel update feature, this is powered by the 'canonical-livepatch' snap. When you run "ua enable livepatch" it installs the snap. Without snap, it won't work, hence you won't get live patches. Livepatches are not automatically enabled by default for a standard install on your own hardware, you need to attach it to your ubuntu account with "ua attach" and then "ua enable livepatch" (it's free for 3 personal machines and requires a paid subscription otherwise). You can read more about that at https://ubuntu.com/security/livepatch. The snap package is the only canonical-livepatch client package hence if you removed snapd you would lose access to use livepatches.
Disclaimer: I work for Canonical (Ubuntu).
There is some software installed by default on 22.04 by snap that has no Ubuntu-provided alternative "deb" package. This includes firefox and the "Ubuntu Software" store app (installed by default) and LXD (not installed by default, but if you want to use it, there is no deb package). If you're not using any such snap software, it may not matter. In some cases you may be able to install software through some other non-snap method from a non-Ubuntu source (e.g. you may be able to install firefox using the standard linux installer, though I have not tried that).
With regards to the Ubuntu live kernel update feature, this is powered by the 'canonical-livepatch' snap. When you run "ua enable livepatch" it installs the snap. Without snap, it won't work, hence you won't get live patches. Livepatches are not automatically enabled by default for a standard install on your own hardware, you need to attach it to your ubuntu account with "ua attach" and then "ua enable livepatch" (it's free for 3 personal machines and requires a paid subscription otherwise). You can read more about that at https://ubuntu.com/security/livepatch. The snap package is the only canonical-livepatch client package hence if you removed snapd you would lose access to use livepatches.
Disclaimer: I work for Canonical (Ubuntu).
Thanks. This is mostly what I thought. Thanks for clarifying and adding details.
As a long time Ubuntu user that's not anymore, I'd suggest you find an alternative distro. I understand adding things to your OS, but if you are at the point you are removing things by default, that's usually an indication it's not the best distro for you. RHEL family is a pretty good choice. Also Manjaro.
Edit: Another poster suggested PopOS - that's probably a less radical change.
Edit: Another poster suggested PopOS - that's probably a less radical change.
What's left in the RHEL family? CentOS is dead, Scientific is dead, Rocks I guess? It's not a lot of fun using these as a workstation, and even as servers they're quite a pita if you need any kind of up-to-date language runtime on them (e.g node or elixir or something).
I use Void on my clients, and ubuntu server for servers, hopefully snap won't get in my way there too much :}
I use Void on my clients, and ubuntu server for servers, hopefully snap won't get in my way there too much :}
Fedora is excellent.
If you like Fedora's default Gnome, probably.
If you're a KDE user, Fedora isn't friendly at all. And you'll still have to have all the Gnome binaries to support the Fedora tools that are Gnome-only.
If you're a KDE user, Fedora isn't friendly at all. And you'll still have to have all the Gnome binaries to support the Fedora tools that are Gnome-only.
Fedora + Rocky
[deleted]
It's probably less hassle to just dump them for Debian or Pop. By removing snap, you're now taking on a maintenance project, and will have to continue maintaining it for any unintentional breakage that occurs from an update or upgrade.
Linux Mint has a Debian edition that I've been using for awhile now. It's quite nice! https://www.linuxmint.com/download_lmde.php
Linux Mint has a Debian edition that I've been using for awhile now. It's quite nice! https://www.linuxmint.com/download_lmde.php
I’ve removed snap and had absolutely no issues. My Ubuntu install now upgrades software in the same way as before snap became the default install method. This script seems comprehensive https://github.com/grobo021/snap-nuke
[deleted]
I remove snap as the first thing on most of my installs.
I hate hate hate hate hate snap. It's a bad idea, badly done.
I hate hate hate hate hate snap. It's a bad idea, badly done.
I'm not crazy about it. I put snap onto a Debian server recently because of certbot. There are other ways to handle SSL cert renewal, but that seemed to be the path of least resistance.
And ironically, on my servers, I'm running Ubuntu, with snap removed, with certbot working just fine from the .deb. :)
Can you TL;DR the reason that snap is so terrible? I'm a casual Ubuntu user and never really had any issue with it (that I know of). The disdain for snap is fairly pervasive here on HN, so I'm genuinely curious.
Among several other less obvious ones, the unavoidable automatic updates were what finally pushed me to disable it, especially with bits of software that introduced breaking changes between versions that are now much harder to roll back and prevent a roll forward.
For reasons I don’t fully understand, they’re also quite slow to launch compared to equivalent ‘natively’ installed packages.
For reasons I don’t fully understand, they’re also quite slow to launch compared to equivalent ‘natively’ installed packages.
The main arguments against them I have seen are:
- Slow snap startup time
- Pollution of home directory with snap directory
- Automatic updates which can't be disabled
- No support for 3rd party repositories
- Slow snap startup time
- Pollution of home directory with snap directory
- Automatic updates which can't be disabled
- No support for 3rd party repositories
Really, automatic updates?
If people wanted automatic updates they'd just use Windows...
If people wanted automatic updates they'd just use Windows...
To quote much Microsoft documentation: "This is by design."
I'm no fan of snap but I do use snap on Arch and it's pretty simple - you limit snap to nonsense (in my case Spotify and slack for corporate im) you should never use it for anything important - I don't really notice the startup time difference but Ubuntu is wrappers upon wrappers so maybe it's just badly implemented in Ubuntu
Why wouldn't I want automatic updates?
I had a VPN app distributed as a snap - one day it auto-updated and came with a huge memory leak. Apparently all the update did was adjust some functionality in the apps UI, so it was totally non-essential but it still installed itself and broke all my stuff for a day or two.
Updates often break things, especially in Linux land. I don't want things updating until I do it manually, when I've decided that I have time to sit down and possibly spend time fixing breakages.
I run a lxd cluster in my home lab. At one point while I was away on vacation one of the nodes failed. Once I returned from vacation I fixed the hardware issue and brought the node back online. This caused the entire cluster to fail because also while I was gone unknown to me the lxd snap was auto-updated on the other nodes. The node I brought back up was therefore on a different version which lxd. lxd doesn't allow nodes running different versions and will shutdown the cluster if a all the nodes are not on the same version.
QA is never perfect. Sometimes the new version breaks things, and you have to deal with it. With automatic updates, breakage happens randomly; with manual updates, potential breakage is limited to moments when you decide to accept the risk.
Shit breaks on upgrades sometimes.
TL;DR: They help Ubuntu developers maintain short-term productivity, in return for bloat and a collapse of the system architecture.
Longer version:
1) They encourage bad engineering
Unix is based on designed, long-lived, standard APIs like POSIX, and it works really well. The "problem" Snap is intended to solve is the ability to pull a JavaScript, where APIs are completely reinvented every 18 months by having each component lives in an isolated space with its own libraries and subsystem.
Debian worked perfectly fine 25 years ago, and for the most part, programs from then work fine today. A lot of us value that stability.
If each program relies on different versions of libraries and APIs, you can no longer remix and mix-and-match pieces. I can't pull out a few functions from one program, a few from another, and use them together.
Not needing to maintain backwards-compatibility or think through API design is a huge boost to short-term productivity, but leads to unmaintainable systems. That's true for a lot of the ways tools like Docker are used as well, for that matter.
2) They explode package sizes
In the era of terabyte hard drives, blowing up a package from 50kB to 50MB might not seem like much, but it makes a huge difference. Debian and Ubuntu have thousands of packages. Things like download and install times make things like dev-ops (or just setting up systems) a pain.
3) They murder performance
Again, this might not seem like much, but the end impact is that you can't use tools inside of loops or workflows since startup / shutdown / install time is up many-fold. Unix tools are designed to plug together. <100ms run times and small sizes means you can do that practically.
4) They discourage consistency and backwards-compatibility
I learned to use Unix decades ago, and my child is learning to use Unix too. It's a bigger learning curve, but it's much less overall time than learning DOS, Windows 3.1, Windows 95, Windows NT, etc.
Broken things are worth fixing. If something isn't broken, it's usually not worth replacing. In most cases, rewrites are easier than refactors or fixes, but tend to move things sideways, going backwards as often as forwards. That's especially true of things engineered to last versus thing hacked together in 6-month agile sprints.
See second-system syndrome, and Joel's classic "Thing You Should Never Do, Part 1."
Longer version:
1) They encourage bad engineering
Unix is based on designed, long-lived, standard APIs like POSIX, and it works really well. The "problem" Snap is intended to solve is the ability to pull a JavaScript, where APIs are completely reinvented every 18 months by having each component lives in an isolated space with its own libraries and subsystem.
Debian worked perfectly fine 25 years ago, and for the most part, programs from then work fine today. A lot of us value that stability.
If each program relies on different versions of libraries and APIs, you can no longer remix and mix-and-match pieces. I can't pull out a few functions from one program, a few from another, and use them together.
Not needing to maintain backwards-compatibility or think through API design is a huge boost to short-term productivity, but leads to unmaintainable systems. That's true for a lot of the ways tools like Docker are used as well, for that matter.
2) They explode package sizes
In the era of terabyte hard drives, blowing up a package from 50kB to 50MB might not seem like much, but it makes a huge difference. Debian and Ubuntu have thousands of packages. Things like download and install times make things like dev-ops (or just setting up systems) a pain.
3) They murder performance
Again, this might not seem like much, but the end impact is that you can't use tools inside of loops or workflows since startup / shutdown / install time is up many-fold. Unix tools are designed to plug together. <100ms run times and small sizes means you can do that practically.
4) They discourage consistency and backwards-compatibility
I learned to use Unix decades ago, and my child is learning to use Unix too. It's a bigger learning curve, but it's much less overall time than learning DOS, Windows 3.1, Windows 95, Windows NT, etc.
Broken things are worth fixing. If something isn't broken, it's usually not worth replacing. In most cases, rewrites are easier than refactors or fixes, but tend to move things sideways, going backwards as often as forwards. That's especially true of things engineered to last versus thing hacked together in 6-month agile sprints.
See second-system syndrome, and Joel's classic "Thing You Should Never Do, Part 1."
Great explanation, thank you. Looks like I will be moving back to vanilla Debian. Also need to look into the differences between that and Pop!_OS.
I'll just mention that all my systems do run Ubuntu, but with Snap removed. It works just fine. Ubuntu does doing a lot of obnoxious things like snap, but they're not mandatory.
Removing snap is 5 minutes. Ubuntu has come to the threshold of making design decisions which would have forced me to switch off many times, but has never quite crossed that threshold. They've pushing a variety crappy cloud-based offerings. There were many half-start attempts to replace system components (display server, startup system, audio, etc.) with half-baked ill-designed options.
Despite scary announcements, none of these actually came to pass as mandatory components, at least while they were half-baked bad idea stage. They're either dead, optional, or were incrementally improved to be usable before they were integrated to where they were necessary for Ubuntu to function.
For me, I think the roughly hour or two I'd need to invest in getting a Debian working correctly on each machine is still less than the 5-minutes per Ubuntu bad idea I need to remove. Debian makes a great core system, and Ubuntu still does a pretty good job with providing a layer of polish around things like hardware support.
So yeah, I wouldn't advise moving back until things break. If it ain't broken yet, don't pre-emptively fix it. If snap replaces apt, or becomes mandatory, I'll be gone. That's not on the horizon yet.
Removing snap is 5 minutes. Ubuntu has come to the threshold of making design decisions which would have forced me to switch off many times, but has never quite crossed that threshold. They've pushing a variety crappy cloud-based offerings. There were many half-start attempts to replace system components (display server, startup system, audio, etc.) with half-baked ill-designed options.
Despite scary announcements, none of these actually came to pass as mandatory components, at least while they were half-baked bad idea stage. They're either dead, optional, or were incrementally improved to be usable before they were integrated to where they were necessary for Ubuntu to function.
For me, I think the roughly hour or two I'd need to invest in getting a Debian working correctly on each machine is still less than the 5-minutes per Ubuntu bad idea I need to remove. Debian makes a great core system, and Ubuntu still does a pretty good job with providing a layer of polish around things like hardware support.
So yeah, I wouldn't advise moving back until things break. If it ain't broken yet, don't pre-emptively fix it. If snap replaces apt, or becomes mandatory, I'll be gone. That's not on the horizon yet.
Short answer: yes.
Long answer: if you want to use Firefox you’ll have to find an unsupported way of running it. Chromium is also a snap in the repositories ( it is a meta package)
I’ve had a good experience with setting up the Brave repository from the official website and using that.
Live patch is a commercial product and I don’t think many home users of Ubuntu use it.
If doing a fresh install is viable for you, I recommend PopOS 22.04 they ship and support their own build of Firefox as a native package and flatpak and flathub are configure out of the box and are preferable to snaps (but not forced on you)
Long answer: if you want to use Firefox you’ll have to find an unsupported way of running it. Chromium is also a snap in the repositories ( it is a meta package)
I’ve had a good experience with setting up the Brave repository from the official website and using that.
Live patch is a commercial product and I don’t think many home users of Ubuntu use it.
If doing a fresh install is viable for you, I recommend PopOS 22.04 they ship and support their own build of Firefox as a native package and flatpak and flathub are configure out of the box and are preferable to snaps (but not forced on you)
>Long answer: if you want to use Firefox you’ll have to find an unsupported way of running it. Chromium is also a snap in the repositories ( it is a meta package)
If you do not mind flatpak, there is an official flatpak:
https://support.mozilla.org/en-US/kb/install-firefox-linux#w...
If you do not mind flatpak, there is an official flatpak:
https://support.mozilla.org/en-US/kb/install-firefox-linux#w...
Is not an official PPA managed by Mozilla, they are not affiliated with Mozilla the corporation or employees.
Do not use this PPA, it is not trustworthy.
Do not use this PPA, it is not trustworthy.
They are the "Mozilla Team at Canonical", as described here https://wiki.ubuntu.com/MozillaTeam
Why do you claim they are not trustworthy? Do you not find Canonical trustoworthy, then don't run Ubuntu at all.
Why do you claim they are not trustworthy? Do you not find Canonical trustoworthy, then don't run Ubuntu at all.
Nowhere on that page does it say they are Canonical employees. Ubuntu wiki is jus that - a wiki. The page hasn’t even been edited since 2015.
If they were Canonical employees, I wouldn’t expect this PPA to last much longer anyway because the entire reason Firefox has been snap’d is so that Mozilla will be handling updates and Canonical doesn’t want to handle packaging it anymore.
If they were Canonical employees, I wouldn’t expect this PPA to last much longer anyway because the entire reason Firefox has been snap’d is so that Mozilla will be handling updates and Canonical doesn’t want to handle packaging it anymore.
This is bat shit crazy level of conspiracy.
Hosting content on a wiki does not automatically grant anonymous the right to edit said wiki. This particular wiki is not open for editing. Assuming an organization uses a wiki would mean content on said wiki is not to be trustworthy is not factual.
The group members and their roles within Canonical is available for anyone to see.
You can see on their launchpad they are pushing official Firefox PPA:s for Canonical. It is updated to this day.
You can see on launchpad this group is maintaining the whole Firefox package for Ubuntu.
See https://launchpad.net/ubuntu/+source/firefox/
See https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-n...
And so on.
> Nowhere on that page does it say they are Canonical employees.
Maybe not on the exact wiki, but on their launchpad which is the original link you were making things up about.
Stop making sh-t up.
Hosting content on a wiki does not automatically grant anonymous the right to edit said wiki. This particular wiki is not open for editing. Assuming an organization uses a wiki would mean content on said wiki is not to be trustworthy is not factual.
The group members and their roles within Canonical is available for anyone to see.
You can see on their launchpad they are pushing official Firefox PPA:s for Canonical. It is updated to this day.
You can see on launchpad this group is maintaining the whole Firefox package for Ubuntu.
See https://launchpad.net/ubuntu/+source/firefox/
See https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-n...
And so on.
> Nowhere on that page does it say they are Canonical employees.
Maybe not on the exact wiki, but on their launchpad which is the original link you were making things up about.
Stop making sh-t up.
Just go with Debian bro. Saves you the hassle and it’s the same thing with less Conanical.
I kept my work computer on Ubuntu while testing Debian stable on my personal one, which I allow myself to make mistakes on. I did this because some snap packages were flaky for me (it's been awhile, I don't remember what it was.) Debian stable is quite stable. :D The only bad time I had was caused by me trying to move to Debian testing - KDE would keep crashing :)
Given this experience, I feel like moving everything that needs to be stable onto Debian and finally get off of Ubuntu.
Given this experience, I feel like moving everything that needs to be stable onto Debian and finally get off of Ubuntu.
Debian is wonderful but I’m not sure how I feel about their LTS support basically being only volunteers. As opposed to Ubuntu or Redhat that have FTE doing support.
Debian vs. Ubuntu is basically the same these days. Ubuntu is 98% just pulling from the Debian upstream. There are a few apps that need to be more bleeding edge, but to me Debian is just a "stable" Ubuntu. Without Canonical drama (just Debian drama).
If you're used to Ubuntu, transition to Debian or another Deb-based distro is pretty much invisible. What few things you may notice are the places where Ubuntu went off-roading and once the transition is made, it ends up more mainstream anyhow. So the I end up even more pissed off at canonical.
RHEL has an army of FTEs busy backporting patches to 5+ year old baselines. So it's buggy, quirky, AND perpetually out of date. But "stable" - meaning always and perpetually so, not meaning secure or runs well.
The key thing is that those "volunteers" are doing the lions' share of the work for all Linux. RHEL and Canonical's (and Oracle and etc...) contribution and value added is poor. All those FTEs are being paid to do things you don't need and don't want that screw up what was better off without them - but Enterprise!
If you're used to Ubuntu, transition to Debian or another Deb-based distro is pretty much invisible. What few things you may notice are the places where Ubuntu went off-roading and once the transition is made, it ends up more mainstream anyhow. So the I end up even more pissed off at canonical.
RHEL has an army of FTEs busy backporting patches to 5+ year old baselines. So it's buggy, quirky, AND perpetually out of date. But "stable" - meaning always and perpetually so, not meaning secure or runs well.
The key thing is that those "volunteers" are doing the lions' share of the work for all Linux. RHEL and Canonical's (and Oracle and etc...) contribution and value added is poor. All those FTEs are being paid to do things you don't need and don't want that screw up what was better off without them - but Enterprise!
This is a great explanation, thanks!
Fresh install? There is an easy way to find out :)
I had no issues when tested. But still wanted to CMA lol
nice to hear ... i just got into snaps for local displays. I always uninstalled snap before otherwise. thanks for testing :)