By default, Ubuntu ships with a bunch of snap packages. If, like me, you don’t like snap and Flatpak infecting your clean deb/apt-based system, here’s how to remove them.
Now this all sounds great, and it is in some ways (especially for app developers), but it comes at a cost: and that is generally performance and annoyances with application theming, access to user folders, and the like. I personally find that if I want to run a sandboxed application I lean more toward Flatpak as it is more performant and seems a bit more mature than Canonical’s snap system.
In any event, I usually disable snaps entirely on a fresh install of Ubuntu, and I’ll show you how to do that in the new Ubuntu 20.04 release.
I really hope Snaps and Flatpaks take off. I never understood why a silly media player should be allowed to work itself in the operating system and why it should require sudo/UAC (and run post-install scriptlets with those elevated permissions!), instead of just copying all the required files to a single location, add a desktop icon and be done with it. And yes, apps should use default APIs to change system configuration like file associations, instead of “just doing it” (=setting themselves as default) or use some idiosyncratic UI in the installer to set the file associations (I am looking at you VLC).
And Snaps and Flatpaks should also solve the dependency hell issues often preventing the latest version of VLC from arriving to LTSes.
Only (non-userspace) drivers and antivirus software should be apt-managed, there I said it.
It is not that simple. Snap comes to solve some problems and to make the life of developers a bit easier. And it is improving. It solves the sandbox problem, and compared to APT it is better because of dependencies. For example, as of today (April 24) I would not have ready debs for Ubuntu 20.04 for some of the applications I need. Installing debs from older Ubuntu versions probably would give a lot of missing dependencies. This is not a problem with snap: a snap made on Ubuntu 18.04 will work on practically any system. All the dependencies are inside the snap? Yes. It is storage-consuming? Yes. It does not integrate well with the system theme and so on? Yes. Personally, I deal with a keyboard problem where accented characters do not work. My native language (Portuguese-Brazil) demands the use of cedilla (c) that is not supported on snap applications. Trying to solve it on my own snaps I discovered that the cedilla issue was solved in Linux via scripts all that time. Yes, some ugly workarounds. So you can see that Snap is dealing with some problems from an operating system that maybe was not designed to be “sandbox friedly” or to have just one available GUI toolkit. In the beginning I was very frustrated by the fact that Canonical was forcing developers to use snap in order to have their applications available on the store. But this is the way to go, snap will be the default software packaging system on Ubuntu. I believe that it is better to learn about it and help in any way we can.
Does it start 20 x slower than deb package? Yes! At 18.04 (or 19.04 ?) I was thinking, that there is something bad with my HDD, but I`ve read somewhere, that some apps are snaps by default and they were. Now I always purge system apps from snaps. I see difference even on SSD. And 3 non-ubuntu dev apps I`ve tried never worked correctly.
I agree fully with the quote. I’ve never had a good experience with snaps and I also don’t like how they clutter up my
mountoutput with a forest of loopback mounts that tend to get stuck mounted until you reboot.(Heck, it wouldn’t surprise me if the anti-sandboxing zealots I see on places like Phoronix formed their opinion of application sandboxing based on snaps.)
When it becomes unfeasible to kick snapd off my Kubuntu and Lubuntu systems and use a mix of APT and Flatpak, I’m switching distros.
(Note that I’m anti-snap, not anti-sandboxing. The sooner we can get broad deployment of a well-designed, mature application sandboxing solution with permissions manifests and portals, the better.)
Exactly what I was going to write. Snaps are a no-no for me.
Yeah, how typically Canonical: take something seemingly simple and overcomplicate it to death. Why the heck did they decide it was a good idea to have each snap be its own damn mounted squashfs? It creates no end of trouble, and it gets worse the more of them you use. Anyone who had ever used loopback mounts and gotten the dreaded “device or resource busy” error when trying to unmount them would have seen where this would go. Were they trying to be clever for the sake of it? I do not understand the design rationale here.
darknexus,
Yeah, this bothers me quite a bit with some recent distros. Mounting used to be quite nice in linux, but It is getting unmanageable at least using the standard commandline tools.
This is a major gripe of mine too! Honestly I’m really surprised that this continues to be a problem with linux since it’s been plagued with busy & unmountable mountpoints forever. The -f force option never works in these cases. The -l lazy option works to remove it from namespace but it doesn’t technically unmount the file system in the kernel, which virtually guaranties dangling references.
When I issue “umount -f” as root, that’s an order to do it immediately, not a request to do at the kernel’s leasure. “fuser -k” doesn’t always work either. These bugs should have been fixed eons ago, but it’s actually a shortcoming of the driver model used in linux. The kernel uses threads for IO, and many of these cannot be killed until they’ve completed. The associated resources and file systems can get locked with no way to administratively override or kill the locked kernel threads. It’s awful, but sometimes rebooting or disconnecting the media is the only way to get the kernel to unmount it.
To make matters worse, the userspace events can get blocked as well. Sending USR1 signal to the “dd” command is very useful and tells dd to print it’s progress. But when you need it most to check if it’s making progress, like writing a large image, signals won’t reach the application due to these linux locking issues.
I think you’re still referring to squashfs mounts. My OS uses one such mount, but that’s for the whole OS. I think it’s unweildly in ubuntu because increasingly applications need their own mount points, which gets ugly.
Yeah, I was referring to the implementation of mounted squashfs in reference to snaps specifically with
my final question. No matter how I think about it, I do not understand the rationale to use this design when Linux has been so plagued with mounting issues.
As for why it happens, unfortunately I’m all too aware of the reasons. I’ve seen the signal problem as well. The thing is, while I understand why, it makes it no less annoying. And, from a user’s perspective if Canonical actually want Linux to gain in popularity, it doesn’t matter why. They don’t care why it doesn’t work the way it should, they only care that it doesn’t and someone had better fix the darn thing or they’ll use something else. This is a fundamental problem of understanding between developers and users in my mind, and it’s only getting worse as more and more developers become ideologs tied to their particular philosophies/religions/licenses.
I’ve had a good experience with snaps, but they strike me as… betraying one of the coolest features of Linux systems, package management.
My mind was completely blown when I saw apt/dpkg for the first time in 2005 (Ubuntu 5.10).
How is linux package management any good? You need sudo to install a frickin’ tetris game. You see, package managers don’t like it when more than one people try to install things, so they “solve” the issue by making the lock available only to the root user. Feel free to draw any conclusions about what that means, or if you can’t be bothered to let me save you some time: Basically it means you either have to disallow regular (non-sudo) users from installing any package-managed apps, even for own use, or give them sudo. Or make the lock file available to other users than root, which is against recommended practices. All this so regular (non-sudo) users can install a tetris game for their own use! if you are a programmer, better distribute that tetris game as a .tar I guess.
And then there is the whole dependency hell issue, which is the reason why you cannot install the latest version of Kodi in Debian, unless the Debian version you run is Sid. Which is a problem if a plugin you want to use requires the latest Kodi.
Yes package management saves some space. Such a big deal… in 1999.
> How is linux package management any good?
No dependency hell, a single command updates everything, I can easily roll my own packages, I’m not bound to Canonical’s whims…
> You need sudo to install a frickin’ tetris game.
What’s the problem? If you can’t use sudo in your own personal machine, something is wrong with you. If you’re using another person’s machine, you’re supposed to ask them for permission.
> Basically it means you either have to disallow regular (non-sudo) users from installing any package-managed apps, even for own use, or give them sudo.
Again: if you’re on your personal machine, you have sudo. If you’re on a non-personal machine (e.g. work machine), you’re supposed to ask your sysadmin to install stuff.
In most companies I’ve worked in IT, bringing software from the outside or trying to bypass admin/root permissions is a fireable offense.
nabru,
I’d say that whether or not you experience dependency hell on linux depends on whether you ever need to work outside of your distro’s repository. If you do, then you risk openning the gates of dependency hell.
To be fair, many people don’t need to do that, but sometimes it can’t be helped. For example I needed to install a newer version of open ssl than what was available through the repo and it broke other things that had been working. I had to fix everything by manually installing the latest versions of all the software that was broken. This was an instance of “dependency hell”.
I think kurkosdr makes a good point, it should be easier to give a normal user permissions to install their own software at least for their own user account. Consider that sometimes it makes sense for employees or housemates to install their own apps, but it doesn’t imply you want them to have root. Obviously the linux repos don’t work this way, but it doesn’t mean it wouldn’t be useful.
You’re suggesting a binary solution (you either have full access or no access), but sometimes you want more flexibility. It’s not uncommon on windows networks for employees to be able to install software in their own accounts without having to go to sysadmins every time. Linux technically allows users to install their own software in their personal directories. It’s not a usecase that’s supported through the repos, but maybe it should be. This seems to be what kurkosdr is referring to by resorting to tar balls.
That really depends on one’s position and local policies. I’ve seen both, but as a technical worker I feel that restricting local user accounts practically always results in lost productivity and more overhead. A library serving the public might want to lock down everything. A company might want to give their trusted employees more flexibility to encourage innovation and automation. A college computer lab might require students to get software on their own in order to do their course work without having to go to the sysadmins all the time, but they obviously don’t want to give students root access! And that’s the thing, there isn’t a one sized fits all solution. It would be very nice if repos offered more flexibility.
Maybe we can agree that repos could handle this better?
How is linux package management any good? […]
Package management is one of the reasons, if not the main reason, Linux has been a fairly secure platform for decades: instead of downloading some application from some random site, you typically download packages from your distribution’s central repositories, or some other well-known repository.
In fact, I consider package management as a precursor to app stores. In the end, it’s the same thing: centralized download place.
Don’t forget the benefit of having shared libraries instead of the “dump everything inside the application directory”.
Most of the time, people complaining that they “need the latest version currently available” have no idea what they are talking about.
Of course, browsers are the outliers, because of the risks involved, but any decent distro keep them up-to-date nowadays.
acobar,
Obviously I agree, this is one of the benefits of repos. On top of other benefits like automating systemwide updates. This is extremely valuable.
I have to disagree here though. The repos take care of the vast majority of software sure, but sometimes you really do need the latest version because it specifically contains a feature or fix you need and it turns out this is a very real limitation of the repos. I understand why they do what they do, but I think we should at least acknowledge their faults. They have to keep a balance between stability and cutting edge releases, both of these goals can be contradictory. I like LTS & stable branches most of the time, but during times when I’ve needed a fix or a new feature, the repos aren’t much help.
> kurkosdr How is linux package management any good?
Take your blinkers off for one min. You are fairly much 100 percent focus on desktop.
> Yes package management saves some space. Such a big deal… in 1999.
This is still a very big deal today in server and embedded. Because Linux current package management is not just saving disc space it saving ram space. If your docker image use too much ram you may need to pay more. So server side being over sided cost you money. Embedded you need bigger storage chips this costs again money.
I will give you for desktop historic package management has not been great but you have also rose glassed over the problems.
> Basically it means you either have to disallow regular (non-sudo) users from installing any package-managed apps, even for own use, or give them sudo.
Think servers and embedded regular uses being able to install what ever can be bad.. This is not exactly as bad as you are making out.
> And then there is the whole dependency hell issue, which is the reason why you cannot install the latest version of Kodi in Debian, unless the Debian version you run is Sid. Which is a problem if a plugin you want to use requires the latest Kodi.
I am on debian and I use flatpak to install Kodi for that reason. Duplicating up libraries does end up costing you ram. You don’t have to give users sudo to install packages packagekit by policykit can grant it for apt and flatpak allows installing system wide by dbus and policykit as well..
>if you are a programmer, better distribute that tetris game as a .tar I guess.
Turns out there is a reason why you want to split user from application install in a lot of cases. zeroinstall and other user based package management found out users would get busy cleaning out their home directories and go I don’t identify that I will delete and then be posting bugs that X application does not work any more and that is right they deleted it. Do not underestimate the size of the Problem Exists Between Keyboard And Chair so having to sudo or polcykit/dbus to modify installed packages is not exactly a bad thing as it does reduce PEBKAC problems.
Flatpak ostree usage does auto de-duplication so keeps memory cost of flatpaks as low as possible using alien run-times. Of course it not zero.
I don’t like snapd using images of squashfs as.
1) it cost you a lot more memory using file system drivers on loopback
2) you don’t get good de-duplication so running multi applications costs you more ram than running the same applications by flatpak.
3) snapd mounting and unmount the images slow down boot up and shutdown time. Remember if you use no flatpak applications and you have them installed other than disc space it costs you nothing yet you have snap applications installed and it always costing you on bootup and shutdown..
Then we have the snap store issue that you are not meant to setup your own local mirror. If snap packages were as good as flatpak packages on the effect on system users removing them would have very little grounds. But snap packages are not as good as flatpak packages so users do have very valid grounds to want to be rid of them.
Also what Ubuntu is doing you have a local Ubuntu minor you are installing from they change a apt sourced deb package to install a snap package now your non internet connected computer is now magically missing an application because it could not connect to the snap store. Remember you cannot create your own snapstore. With flathub you can create your own mirror of it and flatpaks are not being used this way. So there is a bate and switch problem here as well.
Snaps get in the way of what I do with Ubuntu server. My corporate network uses an SSL proxy. Apt can download from it’s repo but not snap. This breaks Ubuntu upgrades from 18.04. There’s probably a way to import my corporate SSL certs into snap but it’s not worth the time investment for a packages I don’t use anyway. Maybe with it removed, my future upgrades from 20.04 will work without issue.
I’m an average Ubuntu desktop user, so my comments are based from that perspective.
First off, I just haven’t had many issues with Snaps. Perhaps it’s because I really only started using them during 19.10 and now during 20.04 when a lot of issues have already been ironed out. As far as me just using my applications, they have been great. They’ve even solved some problems. I haven’t had many issues with apt, but I did have one a few months ago where libreoffice broke on a normal apt update. I tried to fix it for a bit, and just gave up. I uninstalled it, and installed the SNAP version and that was that. Problem solved.
As I worked with it, there are a few issues that I got curious about. Some of which I think they have addressed properly. Other’s I think still need work.
1. Application size
No, all libraries are not bundled with each application everytime. For lack of a better word, you can specify a standard set of libraries to use as a base. So things like GNOME, KDE… are not bundled each time. If two applications use the same base set, they are only downloaded once. This can be user-unfriendly at first. You go to the store to download some small app that should be like 5 MB, but it needs to be download a 1 GIG runtime. I wish they made things more clear somehow, but that’s all good.
How that impacts runtime memory use, I really don’t know. Again, it’s my desktop system with plenty of memory, so I haven’t had any issues. I’ve googled a bit to see how it works, but I haven’t gotten a firm answer.
2. Trust
This is probably my biggest outstanding problem. And no, i’m not talking about there being just one main Snap store. That is an issue at some level, but if you’re using Ubuntu, I think you have kind of signed into trusting Canonical. I do wish they made it easier to point to another Snap Store, but I digress.
My biggest problem of trust is actually knowing which SNAPs to trust in the Snap Store. This is not only a technical problem as they do have ‘verified’ sources. The problem is that so many SNAPs are made by just random people. I have no idea if I can trust these people or not. For example, at some point, I got nostalgic about my favorite text editor (notepad++) for windows. The snap for it is provided by Taqi Raza. I have no idea who he is, or if he actually made it. I did try it, but eventually deleted it, and decided to stick with gedit. This is something that needs to be fleshed out from a business process/technical level. Especially since SNAPs auto update. Maybe one day Taqi gets really depressed and wants to take it out on the world, and he pushes a bad update for notepad++ that infects everyone’s computer with malware or something. Maybe some way of ‘trusting’ providers or a rating system. A rating system or something like that. Right now, unless it’s an official snap provided by the developer of the application, I just don’t use it. For example, VLC is provided as a SNAP by videolan (the offcial) developer.
I don’t think Canonical can just side step it and say and it’s your responsibility to trust. It’s their snap store, At the least they should be warning about untrusted sources or making things more clear. RIght now, aside from the little star next to a verified developer, there’s not much else.
3. Auto-update
I understand their goal of making sure applications stay up to date to avoid security issues. Their use of versions and tracks can mitigate it somehow. Yet, just from a trust perspective, nothing is better than a switch to say UPDATE or NO-UPDATE. Also from a business perspective, this can be an issue. I’ve worked for organization where everything goes through a formal change management process. You want to update an application, there’s a process. This kind of makes it a non-starter for those setups without additional work.
As a desktop user, I’ve come around to accept this with the caveat based on point 2 that I just avoid non-official snaps.
4. Application Performance
I haven’t noticed any issues with application performance once the SNAP is up and running. The first time a SNAP is run after an install, there can be a small perceived delay, but it’s not really impactful for me. Yet, i take that as a given for any application when it first installs… things need to be done.
Overall, I think Snaps/flatpaks are a really good improvement, but they definitely have a lot of work to do, and not just from a technical level. There’s a lot from a business process level as well.
https://verummeum.com/portable-package-formats/
This is from 2018 but the internal operations really have not changed between flatpak and snap. You are look at somewhere between 50 -100Meg memory hit per application you have running with snap over running the same thing with flatpak. Good percentage of that hit is the loopback filesystem stuff snap users. Flatpak ostree and namespace stuff is very memory effective.
Yes both are using shared runtimes between applications. Ostree in flatpak is smarter on the de-duplication that stuff the same inside the application package with other application packages are de-duplicated on disc so saving in memory.
Application performance flatpak vs snap vs native there is minor differences more loading but fast SSD these days make that mostly a no issue.
The scary is like 5 snap applications open that can be 0.5 G of ram extra gone and if you are running tight on ram that can well and truly push you into out of memory hell. Of course until you hit out of memory hell this issue is basically invisible. Result is you may end up by using snap doing less thing with your computer than you could because you are limiting yourself.
Yes I do agree flatpak and snap are good for end users to get current versions of applications simply. But you want this done with serous consideration to memory usage so you don’t end up doing less with your machine because you choose to-do this.
Yes flatpak does work out slightly most costly in over all memory usage than using proper distribution package as well. Basically flatpak and snap are not free lunches you are trading ram for the functionality compared to history package management of course you want to trade the least ram for the functionality and the current winner here is flatpak.
The disc space cost of flatpak and snap with modern storage for desktop users I most class as a non issue the ram one is a fairly big one since that issue can alter how much productivity you get out your computer.
The system start up and shutdown time lot of users don’t notice that snap packages extend that but it is there.
I’m not a fan of Snap. If it becomes that part of the O/S requires it for basic functionality, I’ll go elsewhere. I feel this would be a great pity. I’ve liked Buntu since Warty. Really like that it’s optional and I can remove it. It’s caused a bit of trouble for me when it breaks and additionally it’s annoyed me using a dozen or more loop devices instead of a single directory structure. Problems aside, it’s damned annoying when I’m in for example nmon and hit ‘D’ to see disk activity .. and there’s so many damned /dev/loop mounted that I can’t see the volumes I want to watch and monitor in cap mode that I end up defining custom disk set groups and hitting ‘G’. Frustrating to do this on every system. So, I’m extremely pleased that this buggy P.O.S is removable and the inconvenience of it cluttering up various monitoring and command line tasks is gone. Great idea Canonical, rubbish implementation. Sorry. Love you guys but .. bad move.