27
votes
Do technologies like Snap and Flatpak have a future?
I just gave up on installing Gimp via flatpack because it required a 2GB download. I run i3 on top of Xfce. I have lots of Gtk libraries already. Storage is cheap and my internet has no limits, but this seems very inefficient to me. What if I had to install all my software that way?
I run Debian Stable I wanted the newer version.
NB: you still have to trust the Snap maintainers, who are frequently not the same people that develop the software being packaged.
There are three things I build from source on Debian Stable: Neovim, Emacs and the st terminal. I wanted to check out the new stable version of Gimp, but the process of building it was a bit too complex, requiring me to install many new libraries from source too. So I tried flatpak. It is not an unreasonable solution if you just want to install one thing, but it made me wonder on the viability of the technology for the foreseeable future, hence the question.
Do Snaps/Flatpaks keep themselves up to date? I have a few AppImage things installed for bleeding edge versions and I have to manually update them every so often, it's very annoying.
If you want a different version of something that's not in your version of Debian you can just apt-pin it to a higher version and then it'll track properly. That sounds like the best solution for your particular use case.
Yes, snaps update themselves (which is the source of many complaints about them, because there's no way to turn auto-updates off, and IIRC until recently they'd update even on metered connections).
You can also add the sid repository to your
/etc/apt/sources.listfile and then install gimp withsudo apt install -t sid gimp.No. Bad. Will break system.
Well, yeah, but then I'd have a Debian Unstable from now on, right?
Do NOT do this. It is very bad to mix Stable with Unstable.
As long as you also set stable as the default then no. Only the packages installed with
-t sidwill be unstable.Some say this is a bad idea and you should just run sid or Ubuntu instead. I only did it for Firefox, and probably as long as I keep the amount of unstable packages low I'm fine.
I didn't know they shared libraries and this information totally changes my perspective on this technology. Thanks!
The thing with the GIMP/FLATPAK thing is that it's also downloading an X library; which it shares among all of your flatpak programs that require the same thing, FYI.
Honestly I'm not a huge fan of the solution, but it's interesting to me. Solves the "Getting a Virus" thing almost entirely, not to mention "WAIT I JUST INSTALLED A CURSOR PACK WHY ARE ALL OF MY FONTS COMIC SANS NOW" problem that some people tend to spam forums with.
That is good to know. Changes everything.
I will admit I haven't dug a ton into Snap/Flatpak, but if they support sharing layers for common libraries, then I think that while your first image would be heavy, subsequent images should be much smaller.
I can see how, as an app developer they solve a huge problem of creating a distribution-agnostic application deployment mechanism (but we definitely start approaching the standards problem ). While projects like FPM exist to allow application developers to build their software for all the distros, I can definitely say that it would be nicer to just package an application up in one way that works on any Linux distribution without having to maintain a dozen different binaries.
I think it's going to be the future of application deployment, but I don't know that we're there yet with these tools.
Yep, that's how it is IRT Flatpak at least!
The fraction of people who care about lightweightness over convenience is not so large, and it will decrease as Linux gains more mainstream market share in years to come. Snap and Flatpak are not ideal, but they are far preferable to not having software available on Linux at all.
Yeah, and if you don't back Flatpak/Snap then AppImage would win, and I don't think anyone would want to use AppImage, it's the worst format out there, but it is a lot more convenient for the developer.
What do you think makes it the worst?
It is a single container file, that acts much like portable exe files work on Windows, and that brings in a ton of issues - there is no source that you can trust, you have to download appimage from a website of the developer or their github, and that means if one of the developers gets hacked you can easily download malware, and there is no update mechanism, meaning each app must either implement its own or rely on users checking out their websites. The next big issue is how runtime works with an AppImage - you bundle it with your app, meaning every developer is responsible for the runtime that gets bundled, and inevitably that would mean that some developers would neglect runtime updates and security patches, this also means that apps can't share a runtime (which is the case with Flatpak and Snap), and that means more storage wasted and worse memory footprint. And, of course, you can't support multiple runtimes. The last part is cultural - on Linux we have a neat packaging system that promotes having a clean system and healthy packaging, and that would also go out of the widnows the moment people would start placing their apps wherever they want.
Thank you for explaining. Those are very good points.
I've been hearing this on a daily basis for literally decades. I wouldn't count on it ever happening.
Others have already given good answers, but one important feature of Snaps that I really like is the permissions system. They’ve made it really easy, and I think encouraging more sandboxing and security is always a good thing.
OTOH, I think the majority of the snaps on my system are "classic" snaps, which provide significantly fewer security guarantees...
True, I believe in a lot of cases the software itself has issues that can’t be fixed solely by configuring the security permissions.
In other cases, maybe they were packaged as classic to get it out there quickly.
Either way, the project looks very active, so that’ll (hopefully) change soon.
Edit: another issue is that, when I last packaged a snap, which was a while ago, you could only do it on Ubuntu, so I had to use an Ubuntu VM.
I won't comment on the specific of the solutions because I haven't used them, but I think Flatpaks/Snaps/AppImages come from a very real issue. Since the burden of packaging is so high (since there are many different package systems), meaning it is up to someone who uses the distro you like to package it. That's fine if you're using a popular distro like anything Debian-derived, but if you want to run smaller distros like Void (as an example) you will either have to compile from source or package it yourself. If you are the sort of person to run a distro like that it is likely not a big issue, but it means it's harder for alternative distros to become a usable option because of limited package selection. I would very much like it if there was a standard way for upstream to [expose metadata to?] package their programs with minimal effort, that would work cross-distro.
That is a very difficult problem to solve, and there may not be a perfect solution; distros can differ wildly in architecture so it often is only sensible that the distro should have its own packages that conforms perfectly to the way that system works. The solution isn't as easy as on other systems, as (for the sake of this discussion) there is effectively "one macOS" and "one Windows".
I suspect as we start to see microservices increase, and the ABSURDLY massive advances in cloud computing and a corresponding increase in internet bandwidth and reliability (limited by corporo-government incompetence and malicious behaviour, but increases all the same) we will see an increase in software which leaves that 2gb on the server and you pluck out relevant 1mb snippets every few seconds, or even remote process where you upload data for cloud processing before receiving a result.
An interesting observation that implies is a parallel market for developed and developing countries where disadvantaged communities suddenly find they're locked out of new software until their infrastructure can catch up.
I think yes, I've been using Flatpak more and more lately. It really makes it easy to install proprietary software, without having to deal with bad packaging and runtime errors, plus sandboxing is a good bonus.
I think that even if their future is short lived, the idea of bypassing the system package manager and reinventing the wheel is going to be with us for many many years. First it was AppImage and it had its own limitations, the landscape seems to have improved with Snap and Flatpak, but as you said they seem wasteful. I've used AppImage in the past (as a user, not as a package distributor) and it was a pain, especially when it involved software using OpenSSL (which it failed to load). I am now using Flatpak for testing the latest versions of Epiphany (GNOME Web) and while it gets the job done and doesn't cause any OpenSSL issues, I feel like I am using a poorly designed and unoptimized npm port that distributes compiled software instead of Javascript code. And npm is already pretty bad and painful to use.
So here's my opinion about this topic: AppImage had its run (and it was a pretty long run, 14 years) and we are starting to see (and suffer) its flaws, I personally consider it obsolete. We are already starting to see the flaws in Flatpak, but we are not suffering them yet. The average user may never suffer the flaws as disk space continues to increase in modern systems so I think Flatpak going to live for several years. I can't say anything about Snap because I have never used it.
I'd like to get a handle on what solution works best for needing newer programs than the ones offered in Debian Stable. They should be open source and trusted, for applications that aren't proprietary. Are Nix packages good for this?
Sriram Ramakrishna wrote an article showing a potential future of post-distro software distribution.
I think they have a useful future for folks on stable distros who need that one killer app, or want to get software directly from upstream, as well as a way of sandboxing proprietary software in a user-modifiable context while also ensuring it will work with everything from Debian Stable to your cobbled together LFS install. I would even be excited to see it work in Windows ans MacOS or linux-sandboxing BSDs, with the vendor (or distro packager) maintaining the base system and whatever packages the commumity/company wants to support.
I think a single technology (snap, flatpak/appimage/zeroinstall (lol)) must be chosen because we don't need the rpm/deb/pkg fragmentation on yet another level.