Who does flatpak/snap benefit?

BaumGeist@lemmy.ml to Linux@lemmy.ml – 77 points –

As a user, the best way to handle applications is a central repository where interoperability is guaranteed. Something like what Debian does with the base repos. I just run an install and it's all taken care of for me. What's more, I don't deal with unnecessary bloat from dozens of different versions of the same library according to the needs of each separate dev/team.

So the self-contained packages must be primarily of benefit to the devs, right? Except I was just reading through how flatpak handles dependencies: runtimes, base apps, and bundling. Runtimes and base apps supply dependencies to the whole system, so they only ever get installed once... but the documentation explicitly mentions that there are only few of both meaning that most devs will either have to do what repo devs do—ensure their app works with the standard libraries—or opt for bundling.

Devs being human—and humans being animals—this means the overall average tendency will be to bundle, because that's easier for them. Which means that I, the end user, now have more bloat, which incentivizes me to retreat to the disk-saving havens of repos, which incentivizes the devs to release on a repo anyway...

So again... who does this benefit? Or am I just completely misunderstanding the costs and benefits?

41

So again… who does this benefit?

It benefits me because I can install 32 bit software as Flatpak without any troubles and without messing up my whole system with 32 bit libraries dependency hell.

It benefits the end-user.

People do not want to be in dependency resolution hell; where they have three programs that all use different versions of libssl and require them to install all of them properly and point each application to the correct one. Most users have no ability to resolve problems like that. By not bundling, the application developer is forcing them to either try anyway or just not install their software.

Bundling dependencies with Flatpak or Snap helps the end user at the cost of only a few extra megabytes of space, which most users have in abundance anyway.

Traditional distro repositories also solve these dependencies for the user.

Only if everything you need is in the repository. If you have a application you want to install that doesn't work with your repo supplied version of library, then you are gonna have fun making it work without messing other stuff up. And end users don't really want to deal with that. Also disk space today is cheap, compared to the time it takes to learn and fix such issues.

Not really; they will try to automatically download dependencies, but they don't provide the application with resolution to the correct dependency. So upgrading libssl for one dependency could still break another.

That hasn't been my experience in Debian, which is the example OP gave.

I've run into this in Debian. Not sure what to tell you -- the base repo does not have an explicit contract that everything in it uses the same version of all available software.

Distro packagers solve the issue for the user. And it takes a lot of work

It benefits both devs and end users.

Many people don't have the time or resources to manage a broken application especially devs who have to deal with that on several Linux distributions simultaneously.

Many distros use different package install scripts and repos to suit their specific needs. If I were to use a Debian-based distro, I would need to use apt to grab from a Debian-compatible repo. If I somehow got apt to work on Fedora, then not only would the program I installed not work, it would likely annihilate many of the preexisting dependencies and possibly brick the system.

I personally use Arch Linux which uses pacman, my package manager of choice, and a lot of times I'll find an application that doesn't work on my system due to mismatched dependencies. Arch is incompatible with .deb and .rpm files and does not use the Debian repo and its derivatives. It uses the AUR and its own derivatives of that repo. I don't have the time or skill to get a program to work with a newly updated dependency on one distro nevermind however many exist on the internet. Many devs do that for free after they've been working at their job for hours and/or taking college courses.

What a Flatpak or appimage (ignoring goofy aah snaps) really does is allow a developer to update dependencies for their application at their own pace without having to play catchup when something inevitably breaks due to an update. It allows for a more stable system. As a Debian Bro, you might not need that, but on rolling-release distros like Arch and funky distros like Manjaro that can be very much welcome.

Yes I enjoy that extra stability and organization, especially as I use a rolling distro as a gamer. Hearing talk about Flatpak I disliked it but I decided to try it out after Steam Native bugged due to a system library update. I enjoy it now also because it feels good that installing apps don't get a root password and scatter files everywhere they please in the system.

Bloat is often held up as the ultimate evil without further ado, scaring everybody. I think a little extra disk space would be more concerning on an embedded system. Snap is also aimed at embedded systems btw.

Snaps benefit Canonical. They're trying to build their own walled garden, and anyone else benefiting is not a consideration.

Flatpaks are different, because they aren't purpose-built to benefit a single company. I wouldn't use them to install most things, but there's a few places where there's benefits for at least some people. It's a lot easier to maintain large projects like Firefox on older distro releases for example. You get sandboxing, so that say a bug in Firefox won't let malicious javascript take over your system. It lets vendors release closed source software that would never be included in your distro's repos. These are all things that may not benefit you, but in theory they'll benefit enough people that it's worth it.

I've also moved onto NixOS so don't use either one anyways. I think Nix or something like it is the future, even if you're running a more traditional distro, though that might just be misplaced optimism, see the success of worse is better.

That's a fascinating topic, and I wonder how AppImages sit in this argument.

OH I asked a question like that not to long ago. Appimages do tend to be smaller, they have sandboxing, and getting updates can be hard. Sometime you have just download the new appimage and delete the old one. Other then that is does serve the same function of universal install format.

AppImages are the Linux equivalent of portable .exe's.

1 more...
1 more...

As for Flatpaks: Me. It's easier, simpler, cleaner, more secure and overall more convenient. It's like on mobile, permission based. But without the shady corporations behind it.

About Snaps: some edge devs but more importantly: Canonical.

Benefits any software dev on Linux, as flatpak ships all your dependencies in one "container". This allows you to deploy once and forget about whether some Ubuntu system dependency is on the same version/compatible with your test environment. Software that works everywhere is the biggest win of flatpaks. One could also make the same argument for snaps except the package repository is closed-sourced.

For me, it allows an easy configurable sandbox with Flatseal. This is the main reason I use flatpaks TBH, software is packaged with too much express permissions on Linux. You also get delta updates. Plus I don't have to worry about mucking around with system packages if for example some dependency is not available or needs building/installing.

As a Steam Deck user I really like flatpak, because it allows me to install third party apps while my system remains exactly the same as every other Steam Deck on the same version.

That means just like other "consumer" devices and unlike most PCs, updates are simple and risk free. There is no risk of having an update break because I installed some app that broke system level stuff.

It helps distributing applications that don't break left and right. Deepin is creating its own thing as well and they said they are gonna check host system first then supplement missing components if needed. This should result in maximum space saving, but allow developers to cherry pick dependencies.

How this is gonna play out remains to be seen.

thanks you for explaining that. I had asked around a few times about Linglong but there is nothing that really talked about them.

I think it benefits the distro maintainers. They can vet and ship version 0.13.1 of some multi-player video game, and support that for two years without bothering to package multiple backward-incompatible releases from the game developers. People won't come demanding that they break their distro's stable version no major version upgrades rule because everyone actually playing the game can just use the snap/flatpak published by the developers.

But then why bother to package the game for the distro in the first place?

I think it's usually because someone asked for it, or the maintainers thought it would be wanted. Or to pad out the games section of the repos.

Mainly software vendors.

The fact that you can build a package with all dependences built in etc. Means software vendors can release a product for Linux. Without worring about all the different versions of library's out there.

This is useful for os when trying to support less common distress. As you are not rellying on the distro to package everything. Then destros that wish to may compile more efficient versions based on there own dependencies can. But other distros are supported if they do not want to compile. Without your team having to compile for every distress.

But it also allows commercial closed source vendors to package once and know every linux system (on the hardware they choose to support) will have the dependencies expected. No matter the distro choice or other software requirements. Removing the issue with supporting every distress. As this is a common reason commercial software avoids Linux. As 100s of different distress divided between a relatively small customer base. Means support is often not cost effective.

The main benefit of Flatpaks for me as a user, is that I can upgrade my system without fear of anything breaking (I use Silverblue, which relies heavily on Flatpak to enable this).

I think you should look at the runtimes basically as a repository. There are a bunch of libraries in there, and you make sure that your application works with those versions. Except that now, these libraries and versions are consistent across distributions, so you can support multiple distributions in one go. Additionally, it's the application developer, who knows the application well, who ensures this compatibility, rather than a packager. Which, again, benefits me as a user, in that I can use the app even if my distro doesn't have someone to package it.

Me. A flatpak Firefox means not adding a repo to install non-free codecs. A flatpak steam means not installing a hideous number of 32 bit libs. Can’t remember what software it is because I rarely use it, but another flatpak prevents me needing to build it from source.

this is just my opinion but if you aren't after the sandboxing benefits then don't bother with them. if you want to avoid dependency hell go with nix, if you are worried about storage space use your standard package manager, and if you want higher security without the knowledge/effort to manually do it, go with flatpak or snaps (although many flatpaks need to be further hardened via Flatseal as the dev gets to configure the sandboxing. I'm unsure how this operates under snap as I refuse to use it.)

There are a few runtimes which provide quite a few things already (for desktop and system integration) and there are a growing number of modules for other commonly used stuff, example ffmpeg (de/encoding) which other flatpaks can reuse. Also flatpak uses OSTREE to try and prevent duplication.

The more the devs work with it the better their packaging and bundeling is gonna get. At the moment it is new and they have to re-learn some things and not everything might be done in the best way possible, but that will improve with time.

And i think it benefits everyone. Devs and distro maintainers dont need to repackage, test and integrate stuff for all distors and users have stuff that has an almost 100% chance of working out-of-the-box that is also quicker with updates/fixes.

IMO, overall an improvement in comparision to the current state with deb/rpm/pkgs/... for userspace applications.

I'd agree with mainly the developers. And maybe sometimes me, when there isn't a packaged version available.

But you'll certainly lose the benefits your distro's maintainers provide. They coordinate all the software and make sure it works together. Give it some polish, keep things updated, patch things when there's a vulnerability. Strip tracking libraries and change default settings so it fits into your distro's politics. And a flatpak doesn't use the distro's libraries which get maintained painstakingly by the maintainers. And distros oftentimes promise to maintain software for a certain timespan and not abandon it. (Of course in case you use a distro that does these things properly.)

You're now at the mercy of whoever made that flatpak.

And like mentioned in this post you now have multiple sources of software and you have maybe 3 things to keep up to date instead of 1 that does this on its own.

And if there is a vulnerability in some library like there was with webp this week... The distros are likely to do something about it. And if you have several independent other versions of that library on your system, maybe you'll stay vulnerable until a developer chooses to release a new version with a new or patched library. Some library package managers will show you open vulnerabilities while programming. But I'm unaware of such a thing being included into flatpak, snap etc. Your distro will have a mailing list or something like that.

I benefit from using flatpaks they are up to date and stable I use flatpaks on debian so that I can have both stability and up to date software, I also get more control over permissions which I've definitely used (I nearly fully restrict discord access to my system)

The main downside to me is the package size but this gets wayyyy better after you install the runtimes.

I'm grateful to be able to use AppImages for everything that's not in the repos or for anything that I need updated as soon as upstream updates. So far it has worked seamlessly. It's the most user friendly solution of the lot and I don't need sandboxing.

How do you know when to update an AppImage? I would use the Krita AppImage but I would have to hunt down the file in my file manager to open it and I can't find a way to update it without straight up replacing the thing manually.

In flatpak land it's just 'flatpak update'. Is there not an AppImage equivalent ? Otherwise the usual pattern is to find a RSS feed.

Usually they update automatically. I have AppImage integration and most packages tell me of newer versions.

I'm an Ubuntu user, I've never bothered to try any other distro and probably never will. in essence, I just want my apps to work.

I have spent countless hours hunting down specific debian packages that the application that I want needs. I never wanted to worry about installing dependencies and worrying that they don't interfere with each other in the first place. I really just want my apps to work.

People have complained that snaps have so much bloat, it runs slower, blah blah blah, I don't care. It works and I'm happy.

I don't care. It works and I'm happy.

This is the usability aspect I occasionally see people overlooking. It's hard to sell me on a solution with ideology alone, if the user experience sucks.

flatpak basically does the same thing but with a much better performance and less memory footprint, you could try it on ubuntu.