The thing I hate most about snaps is how they pollute the mount namespace with loop mounts. Install a few apps and 2/3rds of your `mount` output will be /dev/loopX devices. Especially annoying since I often do loop-mounts myself and picking them out from the flood of unrelated snaps is a pain.
If they could somehow hide the mounts (in a different mount namespace maybe?) that would be cool. I mean still, I would prefer more open formats such as flatpack and appimage (since with snaps you buy into the Canonical ecosystem with no way to provide alternative appstores) ......
Nix is the "worse is better" approach, it's just symlinks and environment variables and bash scripts under the hood. (Not even a single container in sight!)
I use Ubuntu and i'm sick of having snaps forced on me. When I next install, i'm either completely ridding the system of snap or i use another distro. I'm fed up with it.
The kicker is sometimes when you use apt to install a package, sometimes it installs a snap! It's madness!
Oh don't let me get me started on this. I use Firefox on a work machine and I spent a number of hours troubleshooting why it couldn't access the Internet when I was connected on VPN.
I suspected it had something to do with snapd, so I downloaded the .tar.gz release of Firefox and it worked. I kept investigating and figured it must have something to do with snap.firefox.firefox apparmor profile because the VPN client was symlinking the /etc/resolv.conf to /opt/.../resolv.conf
However, updating the apparmor profile didn't help so I ultimately realized that snap has a hardcoded list of paths that get mounted into the app container [1] and there's no way to change this.
There are a number of reasons to hate on snapd, but this almost made me flip the table.
Also, as a bonus point, if you look at the apparmor profile I mentioned it has a ton of comments about chrome, so someone must've just copy pasted it and modified to work with Firefox. GrEaT SeCuRiTy!
One of the experiences that formed my hatred of Snap was when trying to install Notepad++ while trying to find a worthwhile editor to migrate to. Running via WINE it was 20.6MB installed, and even WINE itself was 1.2GB, but that 1.2GB was shared by other programs. On one machine due to package conflicts preventing an appropriate Mono install and laziness in sorting my multitude of prefixes I couldn't get Notepad++ to run via WINE and had to install it via Snap. The Snap install of Notepad++ took up 1.3GB all by itself. On a 32GB drive.
It hasn't gotten any better in the five years since for total Snap install sizes, because with the way they work they often install every single dependency siloed. Imagine if you had to install a new instance of DirectX12 for every game you had, or install a new instance of Python 3.12 every time you wanted to set up Tensorflow. Firefox when installed via apt is currently 63MB and its total size after being run and configured with things like session data and add-ons is 243MB. If I install via Snap its somewhere around 190MB in size and when actually run and configured jumps up to around 550MB for reasons I don't understand. And that's not even including the /var/ spam which actually managed to fill both the 32GB drive and a later replacement 80GB drive to the point where Linux had 0KB of free space. It happened so often I copied a shell script just to clean /var/ and edited it to run every twelve hours, like cleaning calcium buildup out of a fountain pump before it clogs.
Re: NPM, how does that work? Do you manually unpack tarballs? I believe some distributions package popular NPM modules, but certainly not all of them -- not using npm doesn't really seem feasible.
(Not to mention that, in the case of pnpm at least, everything's installed into a store directory in your HOME. Seems fine to me.)
Other than the clickbaity title, the second paragraph begins “ Traditional package managers are perfect” - which is untrue. Then the post ends “ Educate me.” - such a “change my mind” attitude seems rather trollish.
I dislike snaps as much as the next person but I wonder if we do need another discussion about it.
My concern is that a lot of laptops come with soldered in, non replaceable hard drives and all these sandboxed programs take up a lot of space. So if you buy cheap laptop with 256GB storage and start installing snap/flatpak/appimage eventually you’ll run out of disk storage and won’t be able to upgrade it (storage, that is). And the only solution is to buy upgradable laptop or a laptop with a lot of storage upfront.
That’s just one of the things that is messed up and annoys me.
It’s fine. I don’t know about Snap, but Flatpack uses shared runtimes. Sure, there is also vendoring, but sharing takes a lot of dependencies out already.
This model has been used on phones and Macs for ages, and for most people it’s not an issue. Photos, videos, and game assets are taking up all the space.
And don't think you're going to get away with just 3 copies of a snap like 'core' or 'gnome' - you're getting three copies of core18 and three copies of core20 and three copies of core22 and three copies of gnome-3-28-1804 and three copies of gnome-3-38-2004 and three copies of gnome-42-2204. At 497MB each.
You might think you could avoid that by reducing the setting to 1, but you're not thinking like the creators of snap - they've decided the minimum value of refresh.retain is 2.
Meh, that's just one model out of dozens form one of a dozen manufacturers. Hardly conclusive to validate the "a lot of laptops" claim. I'm sure someone else in the comments will point out some other obscure laptop from Acer or Lenovo that's thinner than a razor blade and has soldered storage. Fine, but still not "a lot of laptops". Just don't buy those 3 models in the world that solder their storage and you'll be fine.
>Most (all?) Chromebooks use eMMC storage attached to the board.
Thanks but Chromebooks are just ChromeOS devices akin to your tablet or phone, not actual laptops, nor do I buy garbage laptops with eMMC, nor would I know where to find one even if I did want to buy a laptop with eMMC since I haven't seen one for sale since the Asus EEPC from 2011, so no issue there.
>Even laptops with M.2 connectors still require a hundred screws, guitar picks, heat guns, and other insane things to "replace" storage.
That's a gross overexaggeration. I fiddled with the innards of several models of laptops from several brands and all of them are easy to replace the M.2 SSDs without special fancy tools and pain, just a screwdriver. Only Microsoft glues their machine together but nobody buys them anyway so don't you do it either and you'll be fine.
Conclusion: Myth busted. Most laptops on the market DON'T have soldered storage, and they're also quite easy to replace. Keep calm and carry on.
Yes I'm sure all the three Surface Go owners in the world will be devastated.
>Basically anything under $700 has a chance to be an eMMC laptop.
You must be joking. Maybe like sub 300 USD. I have a 700 Euro Laptop and it came with a 1TB NVME and most cheap sub 500 Euros laptops I find are all still with SSDs not eMMC.
SSDs are now so cheap you'll find them everywhere instead of eMMCs. You really need to go out of your way and scrape the bottom of the barrel to find them today in new products.
> by actively searching for them on Amazon doesn't mean anything.
No, I didn't 'hunt down', 'actively searched' or whatever. I just typed it in. Also it means what you are didn't bothered to visit that link and you are in denial, because it doesn't suit your views.
> How many consumers actually buy them?
Ah, yes, let me call MS/ASUS/whoever president and tell him to handover the stats, because noname from the Internet demands them or 'didn't happen'
>trying to spin it into an overexageration
Ah, yes, multiple models with eMMC sold everywhere is just an overexageration, it's like a special plot from vendors to... what for, actually?
How come there are models on the market with eMMC when nobody buys eMMC laptops? Can you explain that without overexagerating your snobism?
> Emmc laptops are by no means a majority in consumers hands.
Yes, and this is addressed in my first comment in this thread.
eMMC is such a nasty invention! We could have just had microSD cards as core storage on all these tiny thin devices! They make cards with good wear leveling.
The tech is already there, no need for soldered on stuff.
Soldering is kind of a "Worst possible solution except all the other ones" kind of technology.
Totally understand the value in a distribution model like Flatpaks and am willing to adopt them but I haven't had the smoothest experience with them in the past so I tend to avoid them right now.
The last time I tried them was longer than 12 months ago - I installed Discord and it was missing some features at the time due to sandboxing (I don't remember exactly, it was either push-to-talk, hot-mic, or showing what game you were playing that didn't work).
I also had some other issues with other Flatpaks - I think there were theming issues.
How is it today? Can I install VSCode, Chrome, VLC, Steam, Discord as flatpaks and have no idea they are Flatpaks?
I used to have issues with Steam flatpak, but it's been 2-3 years now without any issues.
Discord also works, it doesn't support some features, but that has nothing to do with flatpak and everything to do with Discord on Linux in general.
I've got a dozen or so other flatpak apps that work flawlessly.
One major complaint though is it can keep old unused versions of runtimes around and you manually have to remove them, Nvidia and Mesa runtimes for some reason consistently have this issue. Even running `flatpak uninstall --unused` does not remove them.
In my experience you'll sadly still run into issues when running apps that weren't designed by the original authors to be used as flatpaks due to the permission issues you mentioned.
I see it as a necessary evil since a proper permissions system will make the attack surface for desktop apps much smaller in the long run, and the flatpak portals have the advantage of being much more visible and controllable by ordinary users than AppArmor or selinux (if there were even profiles) before them.
I’ve found using FlatSeal eliminates my issues with flatpak. And that’s despite me running flatpak on an Ubuntu install which I try hard to de-snap (yeah, I should switch to another distro but I’ve been using Ubuntu off and on for 2 decades and old habits die hard).
That being said I don’t see FlatSeal as a solution to the permission issues but merely a bandaid until a proper first citizen solution is developed by flatpak.
Snaps were one of the main reasons I moved from Mint to Ubuntu.
Traditional package management is a terrible fit for modern systems and apps.
If you have dozens of apps and they each have dozens of dynamically linked dependencies, you'll probably get an occasional compatibility issue.
At first I really liked Flatpak, but the ecosystem isn't there. Everything I use is in Snapcraft, with Flatpak I still would occasionally have to hand install something or add a custom deb repo.
My only real complaint is the proprietary backend. It doesn't directly affect me much, since it's not like I'd want to use an alternate store when the official one has everything, but it does get in the way of adoption without seeming to benefit canonical that much.
Companies are way too afraid of FOSS competitors, they forget how much users like convenience and standardization and sticking with stock settings.
In my experience - using Linux since 1992, Debian since 1997 - "traditional" package management is quite capable at avoiding compatibility issues related to dynamically linked dependencies. Linux has had library versioning for a very long time - something which made it stand out compared to the 'DLL Hell' Windows users were used to - and it is quite common to have multiple versions of libraries installed and in use. Given these conditions I do not consider package management a "terrible fit" for "modern systems and apps" - whatever those might be. I do see a use for systems like AppImage which come in handy for applications which are only used occasionally (or even only once) where the increased start-up time and reduced integration do not matter.
It does seem to work 99.9% of the time, but when you have a dozen programs with more dependencies than you can count, some are not in the official repos, and you want more up to date stuff, being able to reproduce the whole environment of a package seems like the best option to me.
Deb packages are rock solid for the most part if you use standard distro packages, but the moment you want something newer or third party, there's no guarantee it will work well with some other random third party thing you also have.
Especially when sometimes apps might even depend on bugs and break when they get fixed.
Snaps mostly solve the reduced integration issues(Or at least try to, some stuff isn't perfect yet?) with all their plugs and interfaces and whatnot.
I think what really put me off when it comes to Snap was when I wanted to use a yubikey with Firefox, but Snap tries it hardest to make it difficult to add a pkcs11 device.
Nobody is forcing you to use distro that includes snapd by default.
Snap has advantages for server software that are using Snap strict sandbox:
- Strict sandbox does not allow read access outside of /var/snap/APPNAME/common . Only common directory is writeable.
- Snap code at /snap/APPNAME is read-only and can not be modified
- When new version is released, for example with security fixes, it is automatically updated worldwide, keeping servers secure.
Linux Mint has MintUpdate, that has options to enable automatic update of .deb and FlatPak packages, keeping everything up-to-date and secure without any clicking. Windows and Mac does not have that, you need hundreds of clicks to update each software separately, having many apps still vulnerable.
I have ~8 self-hosted services with docker-compose and one with snap (nextcloud). While I get that snap gets some flak for how cavalier it can be with your system, ultimately my nextcloud is always up to date and I've had very little effort to put into it in over 7-8 years, which is not something I can say from my running docker containers. It might not be for everyone, but from a security standpoint it's much less fussy than basically everything else that I've tried.
Snaps have some cool use cases, like the one you mentioned. flatpak isn't there yet for CLI apps or hosting stuff from when I last checked, and the snaps for things like nextcloud just work. On a desktop system though, it's clear that everyone should just adopt flatpak for a universal app standard for the time being.
Why not just write something (or use a pre-existing tool) to update your docker containers? I know on Kubernetes there's plenty of tooling around Helm.
I redid my docker stuff with podman and quadlet recently and it's been great. Quadlet turns the containers into behaving like regular systemd services (i.e. you can trigger them with timers), and "auto update" is just setting Pull=true when the container re-runs (there's a heck of a lot of good reasons to also not do this).
To the point, I completely agree that snap seems to work quite well for server software.
Which makes it additionally frustrating that Canonical is insisting on forcing it on all the desktop users.
No one is installing server software through the Software Center. So why does that have to prioritize Snaps?
Canonical could very well have promoted snap as an option to package server software and used flatpaks or even debs for desktop software. There is no reason the 2 couldn’t exist as primary options at the same time for different use cases.
unless you have a lot of free time for debugging - none. We had a project where managment team force everyone to use snaps (cause of some weired company relations with Canonical) and guess what? They did not make it. I think we just wasted 6 months in order to get to be able to do stable prod releases with snaps and it felt like docker more mature and stable in every aspect. I guess that time and money could easily stream to do actually usefull things for end-users.
I had Debian installed. Wanted LXC and LXD. And it brought snapd with it. Immediately my server went from a load of 0.3 to 2.5+. Continuously for months. Snapd always in the top cpu. No idea why or what it did.
I finally caved and gave up on LXC. Removed it and snapd. Load immediately dropped to 0.5 again.
Snaps are one of the two main reasons I'm ditching Ubuntu for basic Debian. The other is apt spam berating me to upgrade to their pay security service.
I now routinely install fake-ubuntu-advantage-tools.deb to remove Ubuntu "Advantage". It's an empty package that satisfies the dependencies.
I also remove some of the crap that Ubuntu put in /etc/update-motd.d. From memory 10-help-text, 50-motd-news, 88-esm-announce, 91-contract-ua-esm-status are pointless and annoying.
Same here, and the fact that it's way too easy to get in "you can't upgrade" -limbo with Ubuntu on servers I haven't touched for a while.
Went back to Debian stable and zero issues. The main reason I went to Ubuntu was that stable Debian used to be veritably ancient. But nowadays I run most of my software in Docker anyway, so it doesn't matter.
snaps is starting to give me a headache. I installed chromium in my ubuntu and it installed it as a snap (even through apt, it just a transitional package that installs the snap.), and for some reason it has a dependency with cups (printing software). Every time i delete cups it is reinstalled..again and again, i couldn't find any solution.
Although cups has a hardwired dependency on libsnapd-glib1 so you can't remove that library, but the nosnap.pref file will prevent snapd from ever being installed again.
Hear hear. It's really inexcusable — if there's a bug in a shared library, that library should be fixed across the board. That, and the implementation is cartoonishly bad, for example you can't extend a partition while the system is running the way that you could before, because you've got random read-only file systems mounted over root.
If the money spent on the salaries of the CADT developers making this were spent on the Debian package maintenance, many problems would vanish.
The last time I used Ubuntu, I ended up installing either bitwarden or discord through snap. Some electron app anyway.
My system logs bloated into the gigabytes with constant errors about some snap or other having faulty security settings. Absolutely no user-facing indication of any type that there's an error, just endless log messages.
I use Arch now. It's still just as miserable, but at least my problems are my own fault this time.
Why? Simple: because commercial sw want them, they need something they can made at home without giving ANYTHING to the community, ESPECIALLY if the software is crap, as 99% of commercial sw are, to avoid being depicted for what they are: vendor of crapware.
Why all such systems state they add security while they do the contrary? Because they demand to the upstream handling all deps, witch means that a generic student who have write a simple chat client need to take care of new releases of SSL who he/she do not even know much because that's just a deps of some wrapper he/she use. They state "but they are isolated", true, but they need to punch holes here and there because your snappyfied firefox need to download files, let's say pdfs, your external reader can read and so on.
That's just playing the Windows game not knowing it and refusing to know what a modern FLOSS system should be, like Guix or Nix.
Unfortunately most FLOSS devs see commercial software and try to mimic it without understanding that ideas behind it might be also technical but in general they are economical, and to support a business model they accept technical crap. Much FLOSS devs fails to understand that FLOSS model is superior IF done the FLOSS way, inferior if it try to mimic some other models not knowing why.
If only people knew the past, the classic desktop OS with the OS as a single application where anything is just a bit of added code in the hand also of the end users, no commercial software today would be able to compete. But most do not even know the past, do not even know that some modern tech was invented in the past in better ways than today and do not understand that the Conway's law is more generic than it appear, goes beyond Lisp and have a generally valid meaning in paradigmatic terms.
AFAICT snaps and flat packs are a way to push package management upstream. That might not have been bad if there weren't more than one such thing to support.
Dependency issues usually only appear on Ubuntu when you start adding third party repos, especially for software that has a version in the main repo. If you stick to the main repo you will basically never have them.
I would have thought it's obvious, but it's clearly stupid to expect all software vendors to package their software for every distro in existence. That's just not a realistic way to distribute software.
You’re a company and your software actually runs on Linux. You want to reach as many people as possible. So you make a .deb for Ubuntu. Or you go with a package manager that is cross-distro.
And snap doesn't address the fact that the server components that talk to the snap 'store' software is closed-source and only available from Canonical.
Never claimed it did. Snaps are yet another half baked Canonical tech...
Those of us using immutable distros would love a "flatpack for cli utils". OS-tree layering defeats many of the points of immutability, and pet containers are a bigger pita than they should be. There has to be a better way.
ehhhh.... If I want to reach as many people as possible I would build rpm, deb, docker images, provide source code. I would not use snaps because it would imply more effort from the end user -- they first need to install snapd and only then my app.
Yup. This is what's true in my experience (working for companies that sell software that runs on linux distributions).
I don't have any gross snaps or unpackaged stuff on my laptop, how could I expect paying customers, with an operations department, to accept anything less.
> they first need to install snapd and only then my app
This is a reductive argument.
It's not more effort if Snap is already included in the Linux distribution.
This argument only applies if Snap is your only distribution channel.
Otherwise, you could say that distributing a Linux version of the software implies more effort from the user, because they'd need to install Linux first. We're talking alternatives here.
But they also move the gatekeeper from the distribution to Canonical, and only Canonical (sideloading does not count when the repo is hard coded and server is closed source).
Package managers are not a sustainable solution to application distribution. It puts way too much on package maintainers, which is a thankless job. Whether or not you like Flatpaks, Snaps, etc, it's clear that we need some sort of cross distro (and preferably cross platform) application format that's simple for developers to target.
Personally I ship static executables, but that doesn't work for GUI apps.
I think having a standard way to specify exact program dependencies (not package names, but e.g. pkgconfig files, command binaries, deps for specific languages, etc, so they can be translated back to the package name for each distro), as well as allow packagers to check for updates, would go a long way in easing sustainability. We already have other metadata covered by metainfo.xml files.
Packaging software is almost automatic these days. If the program uses the standard build system for their language, and the language's build system cooperates with the way of linux (e.g. C, C++, python, perl, ...), packaging software is as easy as telling the package manager what build system to use and giving it a download URL.
I figure that if we manage to have some standard like that, you could easily have a set of docker containers build your program for every major distro and publish it in a repository, without much distro-specific fuss. Of course, flatpak is probably better if publishing to all distros is your specific goal, but it'd make the life of distribution developers significantly easier.
My biggest fear with regards to flatpak is that people will use it as an excuse to create bespoke and broken build systems that only work on a very specific system, patch all their libraries or require very specific git versions that cannot easily be updated, or etc etc. I've already seen this happen with a few flatpak apps I've tried to package.
Do you have a link to instructions on how to do this? I don't think I've ever seen a GUI app on Linux that wasn't dynamically linked to X11 or Wayland.
There are so many half baked takes, but this is my favorite:
> There will always be a market for stable-over-latest software, especially for businesses.
That market is called the nvd.nist.gov at best and 0 day brokers at worst. Why do people stil not accept the fix forward supremacy and patch their mess?
If they could somehow hide the mounts (in a different mount namespace maybe?) that would be cool. I mean still, I would prefer more open formats such as flatpack and appimage (since with snaps you buy into the Canonical ecosystem with no way to provide alternative appstores) ......