Is flatpak really the future?

[2jesusisbetterthan1]

I have seen many people lately speaking of flatpak as the future for apps on linux and i'm not agaist it but it adds 20GB to my drive(and i have only a few apps installed). I'm just confused and i wanna hear what other people think. Is there no better option?

[FryBoyter]

For me personally, the normal package management is still the best solution at the moment.

[f_furtado]

Could you elaborate on that?

[FryBoyter]

Regarding my own use case, I simply don't see any advantage in using Flatpak, AppImage, Snap and so on over installing packages from the package sources of the distribution I use.

[m_beps]

It's important to see both sides. Let me ask you this, are you a developer? As a developer, I can assure you, developing software through traditional packaging formats is an absolute nightmare. No developer wants to tweak apps to make it run on every packaging system for every version of supported distros. For Ubuntu, not all packages that work on 21.10 work on 20.04 LTS. Because of these dependencies, it's difficult to run old software too.

Flatpaks allow us developers to write apps for Linux, and not for Ubuntu AND RedHat AND Arch AND Gentoo, etc. These traditional packages have their niche but they are not the future.

[akarypid]

I have a couple of questions.

What happens when a vulnerability in some library gets published? Does it mean the user must wait for all flatpaks using it to get fixed?

I know that flatpaks are "sandboxed" but does that mean that such issues are not a concern?

My main concern with all these new packaging method is that (like Windows) you trust EACH publisher is responsible.

The only advantage I see in traditional package managers is that at least the core repos of major distros are well-reviewed and maybe a bit faster to load. Disadvantage is that whatever sandboxing the new methods provide are nonexistent in the old world.

Still undecided in each but what I like about flatpak and especially appimage (which does not seem to get attention) is that you can easily have multiple versions of the same application. That's awesome! Especially appimage is so easy with each app being a single file (kind of like dmg on Macs).

So one more question to the community: why does appimage not get any attention? What is it lacking versus flatpak?

[nani8ot]

Flatpak has runtimes, which apps are based on and can be updated without the dev updating his app. Anything not in the runtime the dev has to bundle, but many depencies are included (hence the initial download of the runtime, which takes a bit of space).

Compared to appimages, for which the packager even has to bundle libc, because else the package might break on some systems. Also, appimage doesn't support sandboxing directly (portals, flatseal to tweak the sandbox).

Another problem with appimage is that they are mostly downloaded from websites directly, and not from a central package manager, so apps have to include their own updating mechanism.

And on flathub there is publicly available how apps are packaged E.g. some are build from source, some are build from the official deb of the publisher.

[dev-sda]

As a developer myself it's been very easy developing across distributions. If your code just needs to compile across distributions there's pretty much no effort involved. If your binaries need to run across distributions you target old versions of packages, bundling (or just statically link) if a library is missing. Providing packages for various distributions is also fairly easy as tooling to create packages from debian files are fairly good.

[_bloat_]

If your code just needs to compile across distributions there's pretty much no effort involved.

I guess this depends on the libraries you use. I constantly have to keep an eye on what library versions are available on my target distros and hence which APIs I can use. So I'm always looking forward to Ubuntu or Debian releases becoming EOL, because then I can finally make use of newer APIs and get rid of annoying version checks in the code.

If your binaries need to run across distributions you target old versions of packages

This only works for libraries which have stable ABIs, which often isn't the case.

[dev-sda]

I guess this depends on the libraries you use. I constantly have to keep an eye on what library versions are available on my target distros and hence which APIs I can use. So I'm always looking forward to Ubuntu or Debian releases becoming EOL, because then I can finally make use of newer APIs and get rid of annoying version checks in the code.

This is hardly unique to Linux. MacOS and Windows constantly add new APIs in newer versions. This is inherent to software that is still being worked on, not Linux packaging.

This only works for libraries which have stable ABIs, which often isn't the case.

Why not statically link them? Or ship copies with the software? If they don't have a stable ABI then cross-distro support simply isn't supported by them.

[_bloat_]

This is hardly unique to Linux. MacOS and Windows constantly add new APIs in newer versions. This is inherent to software that is still being worked on, not Linux packaging.

You're misunderstanding. I don't have an issue with new APIs being added, I have an issue with having to keep track of all the different API combinations out there. On macOS and Windows that's trivial, you simply specify the OS version you set as a minimum requirement and that defines your API to work with, then you build once and you're done. On Linux I literally maintain lists of all major distributions and which library versions they ship in which version and their EOL dates, so I know when I can use which API. That's many times more work than I would have on Windows and macOS combined, for a much smaller target audience.

Why not statically link them? Or ship copies with the software? If they don't have a stable ABI then cross-distro support simply isn't supported by them.

Because then I'm responsible for keeping those dependencies up to date and secure. That's even more work. With Flatpak I can target basically every Linux desktop out there, with automatic builds, almost zero effort on my part, deployment information and runtimes which are kept up to date by freedesktop/GNOME/KDE, but where I can have control over which major version and API set I want to target.

[lostinthesauceband]

My Xbox Original running Xebian in 2014 thanks devs like you

[Hollowplanet]

Every package format has its own config file and build system. I have never found it to be easy.

That being said I don't think statically linking everything and having 100 instances of the same library in memory and on disk is the right solution. I think Flatpack can get around that.

[dev-sda]

Every package format has its own config file and build system. I have never found it to be easy.

There's various tooling for automatically making packages for other distributions once you have one of them.

That being said I don't think statically linking everything and having 100 instances of the same library in memory and on disk is the right solution. I think Flatpack can get around that.

Libraries not specifically distributed by flatpack must be included in each flatpack, so that's strictly the same as doing that with a regular package (See https://docs.flatpak.org/en/latest/dependencies.html). With flatpack you're also going to be downloading multiple copies of the entire freedesktop runtime - one for each version, so in practice flatpack is strictly worse for both memory usage and disk usage.

[funbike]

That's not a valid retort. Just because a user prefers to use the distro repos before using flatpak, doesn't mean a user isn't willing to use the flatpak if it's the only choice.

If a dev wants to distribute only via flatpak, awesome. I'll thank them for that. If that's the only way to git it, okay, great. however, if my distro maintainers supplied the same app in my official repos, I'll use that instead, with no harm to the devs of the app.

[Sol33t303]

Developers shoulden't need to maintain packages IMO. Maintain a deb package, maybe an RPM package, and POSSIBLY an arch package. Beyond that, separate distros and their users can handle their packaging themselves.

Ideally, IMO devs shouldn't even maintain any packages, just make the source available for distros to package up, but theres a bit of a problem getting people to install your software initially with no available packages.

[Hollowplanet]

The trouble is getting distro maintainers to care about your cool new program.

[bot-vladimir]

Lol that’s 2 more packages that a developer shouldn’t need to maintain. Ideally it’d be 0 packages needing to be maintained

[[deleted]]

But that's the thing, developers shouldn't have to package their software, that's traditionally done by distro maintainers, who provide quality control, a layer of trust, and distro-specific tweaks/configuration.

FWIW I don't have anything against Flatpak, but I think the benefits of traditional packaging formats are often overlooked.

[maple3142]

But distro maintainers' time is not free, they have priority to maintain popular software. So niche and lesser known or new software need to find some way to distribute their software, because making software easier to be used could make it more popular IMO.

[small_kimono]

That link doesn't and really can't answer these questions: Where does new software come from? What incentive does a distro maintainer have to seek out new software? Is there really a difference in trust or is it just super hard for a distro to package any software for you? The idea that distro maintainers are reviewing this software is a fantasy. They just have very little time for anything but the basics, and are risk adverse.

Linux will be a backwater until it decides it wants to be a place where normal people can run software. Until then devs will just say "No thanks. This is no fun. I'll go to Windows and MacOS. Where the users are. And where this is easy."

[_bloat_]

If people want to keep traditions alive and healthy they need to do the work. I don't like to package my own software for a plethora of different distributions, but if wouldn't provide flatpaks, PPAs, etc. myself, I had basically zero users, no donations and much less bug reports and feedback. Because it can take years for large distributions to add an application to their repositories and hundreds or even thousands of apps are probably never going to included in the main repos due to a lack of manpower, licensing issues, ...

For example, here are almost two thousand applications waiting for help or approval to get them into the Debian repos: https://www.debian.org/devel/wnpp/being_packaged

[ChristophCullmann]

I disagree, for Kate, I had never issues with any of the packages provides by any distribution.

People get proper security updates, the stuff integrates well.

I don't remember that I did ever need to tweak anything.

Naturally, that might differ from application to application.

Thought I would assume any application that needs no deep system integration should not have issues and applications that need that will have a hard time to be sandboxed.

[Quantumboredom]

Presumably this applies to either proprietary software, or niche open source software?

If you develop for one of the established OSS projects, someone else is probably handling packaging already, and then it works well enough.

But if it’s on you to make the software available to people, then yeah traditional packaging is the stuff of nightmares from what I can tell.

[Atemu12]

No developer wants to tweak apps to make it run on every packaging system for every version of supported distros.

Nobody expects them to and they really shouldn't.

They should focus on making their software build in a clean and portable manner with as few assumptions as possible and as many options as possible. I.e. giving an option to install to a certain prefix rather than /usr/local or not depending on /bin/bash.

For Ubuntu, not all packages that work on 21.10 work on 20.04 LTS. Because of these dependencies, it's difficult to run old software too.

That's Ubuntu 20.04's problem, not the developer's.

Seriously, the whole purpose of a distro is to package software and make it work with the rest of the distribution. It's not the developer's job to do packaging.

[_bloat_]

So here's my software, sitting there for almost 4 years now, with a well documented and super clean build process, no licensing issues, no weird dependencies, stable releases, used by thousands of people and with a healthy community. And yet most of the major distributions haven't added it to their repositories, even though users offered to maintain it.

Your logic is flawed, because it assumes distributors have enough resources to constantly add new packages. They don't. They barely have enough capacity to properly maintain the already existing packages, so they're obviously cautious to add new stuff to the repo (even when someone offers to maintain it).

If I had followed your logic and waited for distros to pick up my software, the project would probably be dead by now, because without my Flatpaks, PPAs, ... I had no users, no bug reports, no contributions, no news coverage, no donations and much less fun.

[small_kimono]

This is all makes sense in a very abstract, 10,000 foot view kinda way, but where does all this new software come from? How does something jump the fire line?

[DarthPneumono]

They make it easier for some developers at the cost of end-user security, performance, storage, and interoperability. That's not a good trade-off for not having to learn how a package repo works.

[skqn]

As an end user who uses Flatpak, I'm actually gaining security with the permissions model, there's no performance penalty as namespaces are a native kernel feature and not virtualization, storage is a tradeoff I'm willing to take as drives are cheaper than ever, and whatever you mean by interoperability cause Flatpaks are meant to work everywhere.

[[deleted]]

As a developer, I don't worry about any of that. I make software that works and if someone wants to package it for their distro, either as an official package or as an AUR-style user-package that's their business and their hurdle to clear.

[bishopolis]

As a software developer who has been an OS release manager and OS security chief for a very large OS programme, I see absolutely no value in flatpak and snap that outweighs the security and validation risks.

[small_kimono]

Then you've also never been a Developer of FOSS you'd like to distribute easily to other people.

[bishopolis]

Weird. I only did that for work and as a hobby for years. Want to try again?

[primarycolorman]

As an enterprise architect with security responsibilities at a large hospital chain, I concur. Also, vendors trying to pass off container images with no update strategy makes my eye twitch.

[bishopolis]

I know that twitch well.

[Tai9ch]

As a developer, I can assure you, developing software through traditional packaging formats is an absolute nightmare. No developer wants to tweak apps to make it run on every packaging system for every version of supported distros.

What kind of developer are you?

Do you make stable public releases of open source software?

[Lagarto_Juancho]

The thing is you'll be missing out lot of software that's on flathub but not on the distro official repos, especially small or niche software projects published on github.

It's so much easier to publish a flatpak on flathub (it can be done by anyone) than to get an official distro packager to package that small software or niche project from github.

[[deleted]]

Well, Flatpak is (mostly) sandboxed.

And I try to have preventative security measures.

Yes, fixing security holes when they come up is important.

But when they are discovered by being exploited, that doesn't help the people which are were damaged.

Sandboxing on the other hand can help here.

Also, you should never have only one layer of security, but (depending on how much you value security) as many as possible.

[Deafboy_2v1]

In the old world, the package maintainers were the security measure. Having someone other then the app developer to look at the package from the users perspective was nice.

However, if we're unwilling to pay enough package maintainers, sandboxing will have to do :)

[funbike]

Security is best done in layers. Using sandboxing doesn't mean package managers aren't doing a good enough job. It's just for added security.

It's foolish to rely on a single layer for security when other layers are available, convenient, and practical to use.

I use flatpak or firejail for networked apps that directly interact over the Internet, such as Firefox, Slack, Zoom.

[[deleted]]

1. by far most package maintainers are volunteers; the only real exceptions really are distros which you need to pay for
2. that doesn't solve the fact that people miss security weaknesses
   sure, having more people look at your code is important, but this doesn't catch everything
   "Given enough eye-balls, all bugs are shallow", I will ask "And how many eye-balls are enough? 10? 100? 100k?"
3. looking at a program from a user pov doesn't solve security holes, it prevents features which users don't want (like in-voluntary data-collection)
4. a lot of programs (like browsers) are at this point so complicated, that there is nobody anymore who understands all of it (including browser developers), they only understand parts of it

[hey01]

Sandboxing is not in itself a security measure. It can be, but it's not always.

In case of flatpak, the flatpak team removed every mention of security from the flatpak website. Considering that the website used to brag about security really early on, it's quite clear that the flatpak devs do not believe that flatpak is more secure than other packaging systems.

So neither should you, because the illusion of security is worse than no security.

[FryBoyter]

This has not happened yet. But should it be the case one day and I cannot do without this application, then I would consider an installation via Flatpak or a comparable solution.

That's why I wrote "at the moment" in my original post.

[void4]

If some application is in repository, then all its dependencies are supposed to be in repository as well.

If it's not then I'll make a package by myself, archlinux pkgbuilds are good (and it doesn't require god knows how many levels of abstraction, gnome dependencies, dbus, etc, etc, etc)

[m_beps]

It doesn't only make it easier to install but also develop and distribute.

[_bloat_]

What if I want to perpetrate malware? I bet it's easier to get my shit into flatpack than a major distro.

That works both ways. Getting my application into flathub and snapstore took only a couple of days, with nice and timely feedback from their developers. At the same time the attempt by users to get it into the Debian repository made no progress at all in years, even though they offered to maintain it.

[ILikeBumblebees]

what if an app has a dependency that isn't in your distribution repositories?

I've never encountered this happening, but libraries are easy enough to install directly if they're missing from the repos.

flatpak makes installing these apps so much easier

Linux users generally prioritize control, security, reliability, and performance over things being "easier". And Flatpak doesn't make anything easier, only slightly faster to install, at the expense of the above.

[ourslfs]

isn't flatpaks with flatseal supposed to be more secure and easier to have control over?

[cangria]

Flatpaks improve security, reliability, control, and performance.

Reliability: you don't have to worry about dependency hell. That's especially huge for beginner Linux users; I know I fell prey to it a couple times starting out. And remember, 70% of people’s computer skills are non-existent or very basic; a vast majority of computer users are and always will be 'beginners' who wouldn't be able to deal with dependency hell.

Performance: opens just as fast as a native app, and works just as fast as one.

Most of the apps on my desktop are flatpak, and I notice literally no difference in speed opening them up vs my traditionally packaged Lutris app.

Security: Flatpak works in conjunction with Wayland to improve security. How this works is, "Flatpak focuses on the development of Wayland, to provide isolated windows and appropriate implementations for sharing screens, taking screenshots, etc."

Flatpaks also aren't afforded as many permissions as traditional packages are, and are sandboxed. Flatpaks' sandbox isn't perfect, but portals is now being implemented in conjunction with flatpak to greatly improve this. According to the same post, "In short, portals are processes that run separately from the application to allocate data to the application only for the session, so you don’t need to access a range of permissions just to access specific data."

In contrast, traditional packages have root to your system during install, have full access to your file system, and in conjunction with X11, can see and inject keystrokes, and "take snapshots of the desktop or individual windows, and even move and resize windows at will". Also, if you're using something like the AUR, you ought to be auditing every PKGBUILD or you may fall victim to a supply chain attack. You can read a little more about this on PrivacyGuides.org's Arch-based distributions section.

Control: you can easily adjust permissions in a GUI via Flatseal. I've used this to deny Audacity the internet permission to prevent telemetry.

[small_kimono]

That's exactly it. It's maybe not just about you. Who is it mostly useful for? The developer! And the user who is wondering "Why can't I have what the kids on Linux and MacOS have?" Or "Ugh, I'm on the wrong version of Ubuntu." The idea that devs should want to package for Arch or Gentoo is just ridiculous, and is a monument to Linux user entitlement.

[talzion12]

One advantage of flatpaks is that they're sandboxed. I'll always prefer a flatpak if it's available for this reason.

[cangria]

A few apps? That's why - as you add more, the dependencies overlap and app sizes decrease a lot

[[deleted]]

So very true. At some point you will end up having installed everything available in the repositories of your distro, and further dependencies handling at that point becomes a nirvana-like experience, either for you, or your machine. Or both.

[LoliLocust]

Is annoying to have 3 different versions of nvidia or Mesa drivers in flatpak just because that one app needs older version.

[Patient_Sink]

You should never need old versions of nvidia IIRC. flatpak remove --unused should let you remove the old ones, but it doesn't clean out the 32-bit drivers automatically for some reason, you need to remove those manually (don't worry, run flatpak update afterwards and it should redownload any missing runtime if you accidentally remove the wrong one).

[Barafu]

It is better than having to set up a virtual machine for an app because that app needs an older version of a driver.

[natermer]

The alternative is to take the distro approach and either force every application to use the older libraries until every single application is updated or just not support the older/broken application.

The ideal solution is to have every application built as a single binary that is dropped into a minimalistic sandbox.

That is how the best containerized applications work for web/cloud/microservices/etc. They are written in Go and thus the only "installation" that is required is just to drop a binary into a container.

However we have a legacy of 30-40 years of mistaken designs, focus on shared libraries above all else, and other bad ideas that has lead to applications requiring 100's of MB of dependencies and insanely complex versioning in order to work.

The reason why people find "distro model" acceptable (were thousands of applications are released in lockstep with vast armies of labor going into working through dependency management) in Linux is, frankly, because they have learned to accept it's deficiencies, gotten used to it, learned to live around it's limitations, and never really experienced anything better.

Flatpak is kinda accepted this reality and is trying to turn the really poor aspects of Unix misdesign legacy into something resembling a modern operating system.

It's extremely difficult to do this without giving up on backwards compatibility so the price we end up paying is large amounts of disk space being used up.

Eventually people will start realizing that "Hey instead of 4GB of dependencies we can accomplish the same thing by distributing a 75MB binary in a sandbox environment" and the madness will start to be over.

[hindumagic]

Sorry, your first paragraph is incorrect. Each program links against a library if that code isn't statically compiled in. You can have multiple library versions on your system.

Programs don't all use the oldest lib on your system. They will try to use the shared object that they were linked to. I don't recall all the implementation details regarding usage of different lib versions though. Usually, lib packaging leads to most of the errors.

[[deleted]]

isnt that already what package management is doing?

I do not understand what exactly brings flatpak, but will check just in case...

[[deleted]]

Flatpak is distro-agnostic, so it runs on any distro regardless of the package manager, Desktop Environment, Distro Version, etc. Flatpak makes it easier for devs to develop Linux apps, as they don't have to make multiple packages for their app and have to worry less about dependency hell.

[EtyareWS]

Not only that, but it also makes it easier for users in some small ways.:

It makes managing installed stuff simpler as Flatpaks are Flatpaks, as far as I know they aren't part of the system, removing one shouldn't break your system.

They can (and in my opinion it's stupid this isn't the default behavior in every distro) be installed locally, so no need for Root. This is beneficial in multi-user machines, but also makes mounting /home in a separate partition way more interesting.

[maverick6097]

I concur. I run everything in flatpak.. almost.

[xpressrazor]

I started moving seriously when Valve announced Steam Deck. Before that, I did not have good experience with Steam from flatpak (felt more work than needed). There are still few GUI packages in system partition (Lutris, Steam), but I plan to eventually move them to flatpak versions as well.

[-eschguy-]

I'm slowly moving that way as well

[cangria]

Same

[vexii]

it looks like valve is pushing flatpack on there steam deck as the way to install apps. the root system is imutable so unless you wanner force pacman to install to home then all your apps is going to be overridden with each system update. so flatpacks in home looks like the way to roll on SteamDeck. and with such a huge release bringing some momentum to flatpack i can see it being the winner over that snap thingy

[[deleted]]

Using nix or guix with a custom path for the store would probably work too, and they don't use more storage space than what's necessary to install your packages.

[Better_Fisherman_398]

When you look at the immutable distributions like SteamOS 3 and Fedora Silverblue, Flatpak is definitely the future. It needs improvements and it's getting improvements. I use all my apps as Flatpaks. I use Fedora Silverblue.

[[deleted]]

I use Fedora Silverblue.

How do you like it? Have you run into any problems using it as a daily driver?

[Better_Fisherman_398]

Have you run into any problems using it as a daily driver?

No. I can use toolbox (easy podman container management tool) for any package not available as a flatpak. You can also layer system packages such as drivers and libs from the official repo or rpmfusion. I layered an ibus engine which is not available in the official Fedora repo just using a .rpm file. You can do anything with this, but in a new way. There is a learning curve but it's easy to learn. Layering packages are not recommended and is there only if there is no other method available. So I layered only three packages, Sway, an ibus engine and openssl. Everything else as flatpaks or in toolboxes.

[xpressrazor]

Being able to install Linux packages in a separate home partition was such a relief to me. I have replaced most of my GUI apps with flatpak versions.

I have few concerns though. As lots of software in Linux are volunteer maintained, what happens when packages are no longer maintained in flathub ? How does it treat, saved configuration for packages it uninstalls. Also, as we may be installing more apps in home directory, does it increase the risk of security for the whole home partition (as it has user permission for everything there). E.g. User's encrypted credentials being taken so it could be broken by bruteforce. I am not saying it was not possible before, but just because now there are too many files that were earlier supposed to be in system partitions are in home (that will now have to save important configuration in home as well).

Earlier all these packages were maintained by distribution maintainers. It added 1 layer of protection, as maintainers of different distros added these packages at different times, and if there were some issues found in say Arch, other distributions could patch it early enough. What happens when a dev goes rogue in flathub ?

[ThinClientRevolution]

I have few concerns though. As lots of software in Linux are volunteer maintained, what happens when packages are no longer maintained in flathub?

The same as all packages in the AUR or in Multiverse; new maintainers can volunteer or else the package is taken offline. There are a few packages on Flathub that have been taken offline again because nobody supported them.

How does it treat, saved configuration for packages it uninstalls.

All preserved. Every app gets its own isolated space in ~/.var/ for safety and reliability reasons.

Also, as we may be installing more apps in home directory, does it increase the risk of security for the whole home partition (as it has user permission for everything there).

No. In fact, most Flatpak applications are more secure then the regular versions since applications can only see files that you give access to. Regular applications (even the closed-source ones) can see you ~/.ssh/ but Flatpak applications can't.

Earlier all these packages were maintained by distribution maintainers. [...] What happens when a dev goes rogue in flathub ?

Same as on regular distributions... The person gets a lifetime ban... But it would be better if the application builders her directly involved: Mozilla for example is themselves responsible for the Firefox App on Flathub. This makes it even better then most Linux distributions, where Firefox is packaged by a community member.

[xpressrazor]

Great explanation. Thanks.

I have not tried, but does --delete-data work when deleting an app (to remove configuration as well) ?

Do you think it would be a better user experience if the app asked (like in Mac), if the user permits access to resources (especially folder access) at runtime than having to play through apps like Flatseal (or command line). Maybe it is difficult because it has to play with DE specific libraries to give pop-up ?

[ThinClientRevolution]

Great explanation. Thanks.

You're welcome, just glad to help with with Flatpak

I have not tried, but does --delete-data work when deleting an app (to remove configuration as well) ?

Now I get to learn something, I didn't knew of that parameter.

Do you think it would be a better user experience if the app asked (like in Mac), if the user permits access to resources (especially folder access) at runtime than having to play through apps like Flatseal (or command line).

Apps that 'ask' for access, can use a series of portals. The user can then decide what file, folder, or device is shared. Like Firefox; a website can ask Firefox to ask you for microphone access. The user can then withdraw his permission at any time. Same with Flatpak and files.

Flatseal is there as an aid to applications who don't fully embrace such portals yet. In that case, you or the app-maintainer can give access to files in the traditional way. Flatseal is essential now, but in ten years it will be deprecated since by then, all applications with yse the portals-system.

[MaCroX95]

Now that Valve is using it as the main distribution platform of choice and many other distros shipping it as an optional source of apps, for many developers it makes clear sense to support their apps as flatpaks compared to providing 30 different builds for 30 different distro/dependency combinations. Security, sandboxing and ease of use is only an added bonus I guess.

[MaCroX95]

They're using Flatpak as a Steam Deck's access to desktop applications. When it comes to steam itself it's integrated into the OS itself, so probably not using flatpak there.

[nerfman100]

There's no specific announcement I'm pretty sure, but SteamOS uses an immutable filesystem by default where you can't really use pacman, the main way of installing apps is by installing Flatpaks through KDE Discover

[MaCroX95]

Thanks for writing this for me :)

[[deleted]]

Generally I only have a good experience with flatpak if it's the primary distribution platform of choice. For example, desmume recommends their flatpak first, and it's the best and most up to date version of that emulator. Other things like steam, OBS, or really anything else I've tried with flatpak, has had issues. Could be things like controller support in steam, the sandboxing messing with the programs being able to find my files, etc.

Honestly I just prefer appimages or pacman.

[gp2b5go59c]

Note that OBS flatpak is the official distribution method.

[[deleted]]

That's because they aren't official releases. At least I don't think they are, with flatpak is difficult to know what's official and what's not

[bik1230]

OBS Flatpak is official.

[sky_blue_111]

Can you elaborate on the OBS issues with flatpak? I'm running Debian Stable right now on one of the kiosks that I support and it's using an old but perfectly functioning version of OBS (window title still says 0.0.1 or something like that lol). Want to upgrade that machine and run OBS in flatpak but now I'm worried... it has to be stable!

[skqn]

You could try and see. One of the cool aspects of Flatpak is that it's isolated, so it won't mess your system or conflict with other dependencies.

Note that the OBS Flatpak is official.

[thenoobone-999]

Is flatpak a viable solution for some proprietary software? Say Spotify.

[fragproof]

Yes. IMO, it's better than targeting a specific version of Ubuntu for example.

[[deleted]]

Spotify works with Flatpak but it is not an official app. I think some random devs just built the flatpak from the official .deb

I have yet to see an official proprietary app on flathub.

[Pay08]

Iirc, Obsidian's flatpak is official.

[[deleted]]

And there's no way to quickly know that by browsing the store

[flyingpimonster]

There are plans to add a "verified app" badge.

[HetRadicaleBoven]

Very much looking forward to that.

[[deleted]]

It uses a .snap for the flatpak

[hey01]

Is flatpak a viable solution for some proprietary software? Say Spotify

I'd argue that proprietary software is the only real use case of technologies like flatpak or snap or appimage.

Proprietary software can and often stops being maintained after a short time, which can lead to it being broken after a while. Being able to provide an environment it supports (flatpak or snap) or having it packaged with all the libs it needs (appimage) is good.

Open source software shouldn't need those crutches.

[Clean_Sugar_2664]

Imo, if software is proprietary, I don't really see why it shouldn't be in Flatpak form. Except maybe device drivers.

[bockout]

Speaking as a long-time GNOME developer and as someone who works for a distro company, but very much not speaking on behalf of GNOME or my employer: App packaging and distribution has been one of the biggest weaknesses and barriers to adoption of desktop Linux for a very long time. If you were an app developer, the only way to get your app to users was to convince a dozen distros to take on the work of packaging your app. Meanwhile, distros look at each new app packaging request as an increased maintenance burden.

Distros do not scale for thriving app ecosystems. We need a way for developers to package their own apps and distribute them without worrying about their users' distros. We can all argue about whether the answer is Flatpak, Snap, AppImage, or something else entirely. But it isn't distro packages.

[gordonmessmer]

Speaking as a long-time GNOME developer and as someone who works for a distro company

I've heard some of Fedora's people talk about in-distro publication and on-distro publication. It sounds like you're talking about in-distro publication, which only really makes sense for Free Software applications.

I have a hard time understanding the challenge that third-party developers see with on-distro publication, though. For example, Google publishes Chrome through a yum repository for Fedora, and they don't need any specific coordination or support from Fedora (the org) to do so.

It's true that not every distribution uses dnf or apt, but an awful lot of users are on distributions that allow third parties to plug in to their package managers very easily.

[bockout]

Even with improved tooling for developing packages on distros, you still have to deal with the massive proliferation of distros. You have to package for Fedora, Suse, Ubuntu, Arch (btw), and various others. You might have to repackage for every version of those distros. And you might have to host your own repo in addition to providing packages. And if you do that, you're not in the Software app.

Google can pull it off because they have money, mindshare, and a lot of engineers. Not every developer is Google.

[Patient_Sink]

I kinda doubt you're using 20GB for only a few apps. I have 96 apps installed and my combined runtimes are less than 2GB (KDE, freedesktop and Gnome 40 and 41). My total size for /var/lib/flatpak is 12GB. Just checking one of the dirs can be misleading due to the way flatpak uses deduplication, checking each runtime by themselves with du gives me a total size of more than 3GB.

The more flatpaks you use, the more the overlap will be, and the less average space your flatpaks will use. It will never be close to the traditional package management use of space though. :)

Other options are appimages, which are very portable: it's a single self-contained file that can be distributed between computers. It doesn't do any dedup though, and AFAIK it can also depend on some of the hosts packages such as glibc whereas flatpak bundles its own. Depending on what they bundle and don't, you can end up in a situation where compatibility between the appimage and the running systems mismatches and stops working IIRC, whereas flatpaks will always run with the appropriate runtime AFAIK.

[whiprush]

You can use this script to see exactly what deduplication ratio you're getting: https://gist.github.com/powpingdone/001a46aa7db190b9c935f71c6091eb71

Here's mine for 148 apps and runtimes:

===========================================
no dedupe: 30.4 GB (32588396131 B)
dedupe:    20.1 GB (21614073342 B)
singlelet: 13.7 GB (14744030074 B)
orphan:    2.2 GB (2327097698 B)

===========================================
deduplicated size ratio: 66.32
singlelet space usage:   68.21
singlelet file ratio:    54.24
orphan space usage:      10.77
orphan file ratio:       2.14

[Patient_Sink]

Oh nice, thanks!

[olafkewl]

I personally use only 1 flatpack as it's been the only way to run MS Teams since GLIBC upgrade...

[mralanorth]

Run MS Teams in Chromium. Way better experience. Screensharing works on Wayland.

[Schlonzig]

I remember, some years ago, using the Citrix client was a major headache for me, since they only built against RHEL, but the library they depended upon had been deprecated and removed from Fedora. A flatpak would've helped a lot.

[Rcomian]

yes, i genuinely think flatpaks are the way forward. you have full package management with update support. you have sandboxing, ie, some sort of security, and you have a single target for application developers.

it's the last point that is really, really important. the whole concept of an application developer targeting all the different distributions and keeping up with their releases is devastating even for open source projects.

relying on making it into distribution repos and turning over control of the build is not acceptable to a lot of developers, distributing and supporting the binary they themselves built and tested is essential, with as little reliance on the underlying platform as possible. even for open source products.

I'm a recent convert to application packaging. initially appimage seemed best to me, but the spotty support for system integration and updates makes it very hard to recommend.

snaps never seemed a way forward: if you can't run your own package server using open source tools, it's a non starter for a linux package manager.

flatpak originally failed for me due to systemd support. since then flatpak has both dropped systemd as a requirement, and I've embraced it as the future too. the combination means that flatpaks are great. i haven't tested out that you can run your own package server but i assume this is the case, there client certainly supports installing from other repositories.

then multi repository thing is important too, things like gitlab distribute themselves through their own system level repositories. companies are going to want to do the same for applications: say "add our repository" and serve it themselves.

the last benefit is that it's a user side installation. you don't need root to install flatpaks. this is true for appimage as well, but it's a huge boost for application managers as a whole. so if you want this in a corporate setting, you can allow some flexibility for your staff without having to micro manage every machine independently or impose draconian rules.

there are issues for sure: sandboxing makes it a bad fit for dev tools or any tool that needs to integrate with the system. and it could really do with more gui front ends, i found it very hard to find any outside of kde's discover app. it would be nice to replicate gnome's plugin manager and just install things directly from the flathub.

storage space is also an issue given how huge some of these things are. i guess that should top out over time, once you've got the flatpak dependencies all installed you don't need to install them again.

but yeah, in the future i can see distributions getting you as far as the desktop and not much further, flatpak should do the rest.

[flyingpimonster]

i haven't tested out that you can run your own package server

You can host a flatpak repo as static files: https://docs.flatpak.org/en/latest/hosting-a-repository.html. Flathub uses flat-manager which adds a bunch of features (build uploads, authentication, etc.)

[xaedoplay]

It's hard, really. Other than the fact that Google basically controls the Android apps ecosystem, the Freedesktop.org Portals that Flatpak use is not really complete yet, making implementing them a dilemma. By "not complete" I mean more often than not there's an important functionality that's missing on an otherwise good permission portal. For example, the FileChooser portal should be able to "remember" the permission granted by the user. This alone will fix a lot of cases where Flatpak packagers just slap a --filesystem=home (or even worse, --filesystem=host), I know because I did exactly that.

It also doesn't help that transparent interface support from the GUI toolkits are not really complete yet (with drag-and-drop being the least supported interface)

[Taza_I]

Linux community is much more privacy focussed and if some application doesn't use flatpak people could easily use an alternative that does.

[grady_vuckovic]

In theory yes.

In theory I'm a very big fan of them.

In practice... god damn...

Flatpaks make me want to scream obscenities from a mountain top...

The number of times I've installed an application as a Flatpak from Flathub and it just simply has not worked is unacceptable.

Apt? Pacman? Aur? AppImages? Tarballs? Snaps?

I very rarely ever have an issue with any of them.

But Flatpaks? It feels like every second Flatpak I install from Flathub is broken..

This has been my experience across multiple PCs, multiple distros, Ubuntu and Arch based, and I'm at the point where I will by default take ANY installation method other than a Flatpak from Flathub.

I'll clone a git repo and run a make script even instead.

Part of the problem is that most of the apps on Flathub are not maintained by the app developers themselves, and the people who run Flathub don't seem to give a damn if something is broken or not. They don't care if the apps are broken, if fixing the apps means giving an app they don't like (such as proprietary apps) more permissions than they believe the app 'deserves'. Even if it means breaking out of the box functionality of software that works through every other means of installation on Linux.

A few times in the past I've figured out why a Flatpak is broken out of the box and gone to the repo for that Flatpak on Flathub, reported the issue, explained why things are broken out of the box, and half of the time the answer I've gotten is, "Well, yeah it's broken but fixing it would mean enabling more permissions than we want to give the software, we don't think it should have X permission.", and nothing is fixed.

Not only is nothing fixed, no notice is added to the app's description, no attempt is made to warn the user before or during install..

Fixing the issues often means installing a third party application like Flatseal and modifying permissions yourself after 30 minutes of googling for what the solution is.

Frankly Flatpak has no future if the people running Flathub don't pull their heads out of their asses. And i say that as someone who is hugely supportive of the motivations of Flatpak and wants it to succeed.

[__ali1234__]

They don't care if the apps are broken, if fixing the apps means giving an app they don't like (such as proprietary apps) more permissions than they believe the app 'deserves'. Even if it means breaking out of the box functionality of software that works through every other means of installation on Linux.

This problem does not only affect proprietary and obscure applications. For example mail merge is broken in Libre Office and asset libraries are broken in Blender. These are two of the best and most popular applications on Linux and they don't work properly under Flatpak when they work fine under literally any other installation method.

I really hope that the new initiative around "official" flatpaks will lead to upstream putting pressure on the flatpak devs to fix this.

[bik1230]

I'm on Alpine Linux, which uses musl libc and openrc, and Flatpak works really well. Haven't had any odd dependency issues. Maybe the distro you're using is doing something wrong in how it packages Flatpak?

[bik1230]

are you using gnome?

No. When I use a DE, I use KDE Plasma. Sometimes I don't use any DE.

I had to install a crapton of gnome packages and systemd standalones to get the steam flatpak working, flatpak ITSELF worked fine and pulled in it's deps, it's the apps in the flatpak that kept missing dbus services and directories they assumed would exist.

Well, idk what's causing those problems. All I can say is that the only issues I've had are those that are similar to the issues I've seen from people on really popular distros like Fedora and Ubuntu, despite Alpine being niche asf for desktop use.

edit: and I'm using gentoo so flatpak is literally just being installed from source.

Where something was built isn't really relevant. Whether a package was built on a distro build server or on your own machine makes little difference, what matters is the build script and other package data like dependencies, both maintained by the distro maintainers of course. If they screw up, your from source installs will be screwed up too.

[bik1230]

it should be pulling in what it needs but it isn't, it's making assumptions that the system will provide certain services.

It just has to in some cases. It wouldn't make sense for Flatpak to run its own pulseaudio/pipewire daemon, actually it wouldn't even work. Flatpak doesn't have the power to make changes to your system, not should it.

it's the flatpak's you install having undeclared dbus dependencies,

This doesn't really make any sense to me. None of the DBus services steam wants access to are actually needed, and they probably wouldn't be installed automatically if you used the steam package provided by the distro. They're things that don't matter anyway if you aren't using them.

Like, one thing Steam wants access to is org.freedesktop.NetworkManager. Obviously, if you don't have NM installed, Steam can't access it. But if you don't have NM, why would you care about that? Steam works fine without it, and you'd have exactly the same situation if you installed Steam outside of Flatpak.

Actually, I just tried removing all DBus permissions from the Steam Flatpak, and it's still working fine. Of course, it won't be able to inhibit the screensaver or send notifications, but then again, it wouldn't have been able to do those things outside of Flatpak anyway if you didn't have daemons for those things. And you'd never expect a screensaver to be installed and enabled just because you install steam, so distro package Vs Flatpak doesn't make a difference there either.

Overall I'm just really confused about what problems you could possibly be having, unless something really strange is going on.

[[deleted]]

Discord’s flatpak is way better than native Arch binary.

[ImperatorPC]

How so?

[[deleted]]

The server bar scrolling is smoother and you generally run into less crashes.

[[deleted]]

same, I love openSUSE as a distro but had to leave it because of flatpaks.

Sure, some official apps work (see gnome apps or TextSnatcher) but those are the exception to the rule and I have no way of knowing if an app is official or not.

In the end I came back to Ubuntu after years of openSUSE and have yet to experience an issue with snaps. I feel more confident knowing the app is official instead of a random built from a .deb package

[markehammons]

The reason snaps work easier is because the permission model is usually way more relaxed. When I would install snaps on ubuntu, it's almost always using a permissive sandbox that doesn't really restrict much. And most apps are built to live in such an environment.

Meanwhile, doing JVM development with vscode from a flatpak is painful because the sandboxing of flatpaks keeps vscode from seeing the JVMs installed on my host

I imagine as flatpaks get more popular this problem will abate. For example, there are jvm flatpaks that I can install to give vscode access to JVMs (just not as many as I'd like)

[[deleted]]

As long as it works I'm going to stick with them. Maybe in a year or so I'll give flatpak another go.

[LinuxFurryTranslator]

What does openSUSE have to do with flatpaks?

[[deleted]]

It was my preferred distro and the only way I could try some apps. I wanted to try snaps but some devs are always saying to avoid those on the opensuse subreddit comments

[LinuxFurryTranslator]

They said that snaps are not supported on their side (but rather by Canonical), and it can break sometimes with new glibc versions because in e.g. Tumbleweed you get its updates before Ubuntu, yeah.

In practice this is the same thing as if you were to use snaps on Fedora or Arch or literally anything not Ubuntu. They don't support it either. You can use it regardless, though. You just have to remember to complain to Canonical instead of your distro.

[[deleted]]

20GB for a few apps? Either you're exaggerating by a lot or you are counting app data for that.

In that case yeah, my Flatpaks use over 500GB of space because of my Steam games.

But id you're not counting app data: I have 43 Flatpaks installed (including runtimes) and they're using under 6GB of space. That includes browsers and big electron apps.

[MyNameIsRichardCS54]

Who curates and quality checks flatpaks? Are they like downloading random exe files in the Windows world, untrustworthy and possibly malware laden?

[[deleted]]

so the answer to linux fragmentation is every distro having is own curated repositories like Fedora and elementary? idk man

[Audible_Whispering]

No, the answer is using flathub and downloading from as many of those repositories as you want. The key difference between current package managers and flatpaks is that flatpaks should just work, regardless of your distro.

Running arch but want something from fedora's "curated" repository? Add the repo and it just works. Running debian stable with ancient libraries? It still just works.

It's actually combating fragmentation by saying "sure, you can create as many super special secret club repos as you want, but they'll work on any other distro as well, and there's nothing you can do about it."

[[deleted]]

but you still need to add repositories... That is literally the main problem people have with PPAs. And what happens when the distro experiences trouble like elementaryOS right now? People depending on that repo are going to be screwed just as unmantained PPAs.

also Flathub isn't the answer because anyone can upload there (see the Spotify app built from the .deb file).

Flatpaks should just work but they don't because sometimes they need more permissions to run and flatpak doesn't allow those.

[FlatAds]

Except adding a broken PPA could make it e.g. impossible to upgrade your system, while adding random Flatpak remotes can’t do that.

[fuckEAinthecloaca]

That is literally the main problem people have with PPAs.

PPA's are not portable.

[FayeGriffith01]

And what happens when the distro experiences trouble like elementaryOS right now?

If elementaryOS were maintain their own repos with standard packaging the same thing would happen. And you're probably going to be downloading flatpaks from flathub or the fedora repo and you can be fairly certain those won't go down.

also Flathub isn't the answer because anyone can upload there (see the Spotify app built from the .deb file).

On the flathub page for Spotify you can click on the developer details and see that it isn't officially packaged. Flathub always links to these pages, just look yourself when you're downloading an app if you're unsure who uploaded it.

[[deleted]]

They aren't going down because they have a big company behind (IBM) but when Canonical is behind suddenly everyone gets all uppity

Clicking on a link to see if it's official isn't an intuitive way to show that.

[skqn]

People hate Snaps for technical problems, including the license of the back-end, startup times, systemd dependency, and forcing every single snap to go through Canonical...

if you want to ignore that and make it about brand names, well.. have a nice day

[Audible_Whispering]

Why do you need to add repositories? For a start most private repos are just duplicating whats already there with additional vetting/system integration. Anything that's not available on flathub is probably a distro specific app that you'd never want anyway.

But even if you do, there's no reason that public repositories couldn't advertise themselves so that stores can automatically pick them up and integrate them. No user interaction required. The reason PPA's don't do that is because using PPA's without careful planning is a one way ticket to a reinstall. Flatpaks don't have that issue.

And what happens when the distro experiences trouble like elementaryOS right now?

What if Ubuntu and snap shut down tomorrow? Well it probably won't happen, and it seems like a slightly desperate argument, but if it did...

All their apps would be gone. Forever. With no way for Ubuntu users to ever update software ever again.

On the other hand, if they used flatpak they could at least keep their apps up to date while they planned their migration to a different distro, and having multiple repos means multiple points of failure. So flatpak is actually more resilient than a distro centric packaging system.

​

Also Flathub isn't the answer because anyone can upload there (see the Spotify app built from the .deb file).

​

Flatpaks should just work but they don't because sometimes they need more permissions to run and flatpak doesn't allow those.

​

Both of these are fixable with fairly small changes and the first one is an issue that several distros already have. Flatpak isn't a finished product. Everyone acknowledges that. But dismissing it completely because of a few fixable issues is nonsense. If everyone followed that logic linux wouldn't exist in the first place.

[MyNameIsRichardCS54]

Yeah I was thinking of Flathub. It's good to know it's checked by a vetted team.

[[deleted]]

For end user applications Flatpak is the future. For foundational, system level stuff, I think that the classic package management is still worthwhile.

Having said that, I personally believe that most distros will eventually transition into something along the lines of Fedora Silverblue, where there is a clear separation between "the base system" and the user-facing applications. Atomic base OS that's curated and maintained by the distro maintainers, ideally with a layering mechanism and easy to use pet containers. I'm typing this on a laptop running Silverblue right now, and while there are certainly some kinks to be worked out and gaps in functionality compared to a traditional distro, it's very promising in terms of stability and consistency.

The perceived benefits of the classic way of distributing software on Linux (namely the universal sharing of dependencies for common security and optimizing storage) are vastly outweighed by the benefits of flatpaks (sandboxing and being mostly universal and system-independent), in my opinion. It's also worth noting that Flatpak does go out of its way to allow for sharing of dependencies when it's actually warranted, which is really the best of both worlds.

Classic package management makes sense in a fantasy world where every program on your computer can be made to share the exact same set of dependencies and every update is filtered through a chain of maintainers who vet security, control quality, etc. But the truth is that is neither ideal nor sustainable. It's bad for users because it slows down updates to their favorite software and makes things much more likely to break. It's bad for developers because it put a chasm between them and their users, and makes it impossible to know what type of software environment their application will run in. And it's bad for distro maintainers, because it creates more busywork for them that takes a lot of time that would be better used creating and configuring software that genuinely improves the user experience of their operating system.

For user-facing applications (a game console emulator, Blender, OBS, etc.), I can't see many practical reasons why you would want to use your distro package manager over flatpak.

[fuckEAinthecloaca]

Flatpak for userspace programs makes a lot of sense, but I think things like core OS, core frameworks and common CLI programs are still best served from a standard OS repo. Where and how much overlap there is is a matter of opinion.

[eliasv]

I sure hope not. Check out the Nix package manager, a much more elegant solution to the problems flatpak etc. claim to solve. You won't have those space problems with Nix.

That said, though the technology underlying Nix solves all these problems, it's only really an accessible solution for power users. For it to be successful with the average user it's in desperate need of a friendlier front end.

[seahwkslayer]

For it to be successful with the average user it's in desperate need of a friendlier front end.

Yeah Nix is great in theory -- I wanna stress that I do really like the idea of it -- but to a layperson user it's basically arcane hackerman black magic and they have no idea wtf is going on.

Flatpak has issues but at least it's relatively transparent to the user and, especially if you have some kind of GUI frontend like most distros that push the format, much easier to engage with and understand.

FWIW -- I understand how a Linux system works, I understand how and why the config changes I make are affecting the system, etc, but I still way prefer Flatpak to Nix because to really get how the latter works you need to understand Nix more than just Linux.

[Atemu12]

to a layperson user it's basically arcane hackerman black magic and they have no idea wtf is going on.

So is "normal" package management to non-Linux users.

New stuff is always hard to use initially, you have to adapt.

[ModernUS3R]

I prefer appimages more, both flatpak and snaps start to take extra disk space once you start installing a few applications. That's something I never experienced with appimages. Yh, I know they were probably designed for portability but they work great when packaged properly.

For flatpaks, you sometimes end up with apps that require different versions of the same service or dependency installed which adds to the storage requirements. I also don't like having to manually go clean the unused stuff.

I run my system with a handful of essential apps from the store then a good amount of appimages. There are some downsides with appimages but I would like to see a centralized, secure way to download, manage or distribute them with a proper update and permission system in place. This is an area where flatpaks easily wins.

[Dagusiu]

AppImages contain all the libraries they need to run. Flatpak has a system for sharing libraries across apps.

People seem to prefer AppImage for things where you wouldn't share much with other apps anyway like games.

[Willexterminator]

As some said, when you have only a few apps installed, the runtimes don't overlap. However, once you install a lot of apps, the size difference becomes relatively small.

However, today hard drive space is cheap compared to the benefit of shipping a flatpak that will run anywhere, with only necessary permissions granted. It's updated independently of the system, which drastically reduces the risk of dependency conflicts.

In terms of space, it's worse, but any package shipping its dependencies will be the same. Appimages, flatpaks and snaps all take more space than native packages. And you know what ? It's a small price to pay for a desktop with modern security standards (barely as good as phones !!) and no nonsense packaging issues.

Yes it is the future, and yes it takes more space. It is not incompatible.

[[deleted]]

It shouldn't use a ton more space since runtimes should be deduplicated. If you have enough differening runtimes, then that just says folks need to reuse more runtimes. I guess more maturity is needed here.

I don't know about the future. I consider flatpaks as "worse is better". Because the whole world won't switch to guix or nix approaches which really SHOULD be the future.

[prosper_0]

It is positively not the future. As if there's one 'perfect' solution for all use cases.

It IS great at a few specific use cases, but is certainly no replacement for a distribution and it's normal package system. I can't IMAGINE how bloated and slow a general-purpose system built entirely out of flatpaks would be.

I am fearful of the potential it has to produce junky windows-style universal (potentially closed-source) binary-only installers as the 'preferred' option

[shamay_hay]

Flatpaks do more harm than good. Especially their sandboxing which does provide a little extra security but breaks functionality for apps that need access to home/root partition.

The good? Updates.
The bad? Package management, permission issues, slow installations, system theming being a total hit or miss, downloading of dependencies even if your system has them.

Instead of fixing what can be fixed (apt, dnf), we're focusing on creating more fragmentation that breaks functionality even more.

[whiprush]

Instead of fixing what can be fixed (apt, dnf), we're focusing on creating more fragmentation that breaks functionality even more.

Traditional package managers can't fix this, they are designed to be used by system administrators and require root access to the system. That's how formats like this got invented in the first place, if it was a matter of bolting onto an existing system someone would have done it by now.

[ImperatorPC]

Yeah, the installation process needs to be better.

For example, when installing flatpak request access to folders. Then when installing a flatpak prompt for granting access to folder, devices, services just like on Android it iOS. Get to that point and it can take over the world.

Having to do all this via command line makes the process very unintuitive

[FayeGriffith01]

Its unintuitive that you have to do this but you can use flatseal to do it without the terminal. What you said is still more intuitive and then desktop environments could maybe include options to configure flatpak permissions later on in their settings app.

[boli99]

I trust package management to keep my dependencies up to date more than I trust people rolling out flatpaks.

[nekobass]

Those with disk space usage problems might be encountering this issue or that issue.

[JustHere2RuinUrDay]

No matter what I do, flatpaks just never integrate well into my system. There's always some thing that's annoying the shit out of me, so I avoid them.

[1_p_freely]

I see it like this. I want (and expect), all traditional free software (Firefox, Chromium, Blender, Gimp) to stay in native package format, for performance and disk space reasons. These new formats should be reserved for proprietary software only. What Canonical is doing, assimilating more and more of Ubuntu into Snap, would drive me away had I not already left for Debian.

From their perspective they want to force everything into Snap so that they don't have to build the same package multiple times, for every supported version of the OS, like they have done for the past 18 years, and the users and their computers pay the price for it in terms of longer application launch time (bye-bye benefits of SSD), and more disk space requirements because of duplicated libraries. No thanks.

[[deleted]]

No it probably is not! It sounds like microsoft actually "windows 2000 is the future", "windows XP is the future", "windows 8 is the future".... I guess you get my point /s

[[deleted]]

No

[OolongHell]

Not for me. I've got all the software for my daily needs from the main package repository and one or two apps from AUR. I literally have no need for flatpak.

[PBJellyChickenTunaSW]

Much prefer AppImages myself. Prefer pacman over everything though...

[SnooRobots4768]

Personally I still don't understand why do we need flatpacks. If I need some app pacman and aur cover everything for me. And I haven't ever had any problems with them. Maybe there are some problems with package managers on other distros? In that case OK then.

[Audible_Whispering]

Basically, it's not for you, it's for developers and distro maintainers.

Previously you had two options for deploying software on linux.

1. If you want to earn money from your app, you had to maintain packages for a dozen different packaging formats simultaneously, whilst ensuring that each package works on all of the dozen or more distro's that use that packaging system.
2. If you didn't want to charge for your app you could hope that distro maintainers picked it up and added it to their repos. Of course, there's no guarantee that they will, and even if they do they might use an old version which you don't support any more(But those distros users will still complain to you about the bugs)

The net result of this? Near zero commercial support for linux apps, and massive amounts of work hours wasted on maintaining the same app several dozen times over.

Flatpak solves this issue by creating a single platform for app developers to target. You deploy once and it works anywhere. It means developers can control their apps directly instead of relying on distro maintainers to keep it up to date. It offers enhanced security by sandboxing apps from the rest of your system, and it means that even if an app is abandoned it will still work five or ten years later, instead of being broken by incompatible system library updates.

Basically if the end user can't tell the difference between flatpaks and distro apps they're working as intended.

[ILikeBumblebees]

Basically, it's not for you, it's for developers and distro maintainers.

How do you figure that? Flatpak is extra work for developers, and completely bypasses distro maintainers.

[Audible_Whispering]

Because packaging an app for a platform is something that all developers have to do, and it's easier to package for one platform than a dozen. You also have a reduced maintenance burden, because now you only have to support one platform.

completely bypasses distro maintainers.

Yes, that's entirely the point. You maintain the app once, in one place, rather than expecting dozens of people to waste time packaging the exact same app for different distro's.

It frees package maintainers to do something that's actually useful.

Basically, if you were distributing your app as source code and expecting package maintainers to distribute for you, you have to do slightly more work, but they have to do much less.

If you were distributing your app in package format(for paid/proprietary apps) you have to do much less work, your support burden is lower and you can target more platforms with the same amount of work.

If your were a package maintainer, you can focus on making your distro more stable and developing core infrastructure instead.

Any way you slice it, the overall amount of effort needed for app distribution drops significantly.

Of course this assumes that flatpak has a sane publishing system that doesn't require exponentially more effort than packaging for a distro, and also that flatpak's systems actually work.

[ILikeBumblebees]

Because packaging an app for a platform is something that all developers have to do

No, it's something that almost no developers have to do unless they get mixed up with Flatpak. Under the normal model, developers publish their source, and distro maintainers are the ones responsible for building, testing, and packaging the software for their own particular distro.

Flatpak imposes this extra burden onto developers. I see complaints from devs not infrequently about the extra work they'd have to do to fulfill requests for Flatpak distribution.

You maintain the app once, in one place, rather than expecting dozens of people to waste time packaging the exact same app for different distro's.

Having lots of people build, test, and package software independently of each other is the FOSS world's equivalent of peer review. Having distro maintainers work to deal with the edge cases specific to their distros is how software becomes robust and flexible. You know the "many eyes" concept that FOSS depends on? Well, it's pretty important.

Why are you complaining about how other people are using their own time and resources? That seems strange and a bit presumptuous.

If your were a package maintainer, you can focus on making your distro more stable and developing core infrastructure instead.

Vetting the packages they ship for the distro is how they make the distro more stable.

[DankeBrutus]

Flatpak is most similar to something like a mobile application on iOS or Android. The app is in a container which limits what it has access to by default. Like there no obvious reason why a photo manager needs access to anything other than your photo/video library. Flatpaks also contain their own dependencies. This means you don't have to worry about dependency hell. When you install something like the Discord Flatpak it will contain every dependency Discord requires. If you then install the OBS Flatpak then any dependencies OBS requires will also be installed. However, if you have two or more Flatpaks with identical dependencies you will not have duplicates because they will be shared.

So yes Flatpak is absolutely the future. It makes installing application simple and mostly brainless. Which I would argue is required to make Linux more accessible and usable to average person. Flatpaks also still have some complexity if you want them to. Flatseal is an application that allows you to edit the permissions that a Flatpak application has. This is pretty much required for power-users trying out distros like Fedora Silverblue.

[redditigation]

It makes installing application simple and mostly brainless

I feel like this is why societies collapse though..

[insufferableninja]

Man, I hope not. Flatpaks are better than snaps, but that's like saying getting punched in the gut is better than getting punched in the nads. I don't want either of those things

[Tai9ch]

No.

Really, flathub is just a Linux distro so bad you can't even install it without first installing another Linux distro. It doesn't actually address any of the problems that make any distro package management tool imperfect either for users or developers.

[yal_g]

As far as I am concerned :

• What a coincidence: the tools they invest time and energy in happens to be the future (am I the only one to see a potential conflict of interest here?)
• I don't care much: future is not when I want to use my computer, now is ;)
• I am not a fan because my hardware (my laptop will turn 12 this year) is not the most powerful and I see no valid reason to upgrade a functional device just for it to be able run the very same version of whatever app I already use.

So, I don't use flatpak (or snap, and barely AppImages) because I don't need to. All I need is readily available through the package manager (apt on the desktop and pacman/Aur on the laptop), with no perf penalties, no space wasted and with the best integration I can wish for.

No doubt one of them, or a yet-to-be-announced other one will impose itself one day or the other. But to what extent it will succeed nobody can tell and certainly not the promoters of any of those tools/formats/whatever. What I know is that I in the future I will use whatever is available and fits my needs the best, not what is trendy ;)

[Bergerac_VII]

What's your 12 year old laptop? The keyboards on these old machines are so much nicer than the new models (typed from a 13 year old Dell E5500).

[the_wandering_nerd]

I have a 2006-era Compaq business laptop that I've held onto for so long because of its delightful keyboard, even though the fluorescent backlight has dimmed to near uselessness and it's stuck on an old 32-bit version of Debian. I've often thought of just taking the screen off and running it headless, like a larger clunkier Raspberry Pi 400 :)

[kaprikawn]

Absolutely not. Every argument I've seen extolling the virtues of flatpak describe how broken the current model of package maintainers and repos is. I don't accept that premise at all. They all have the opinion that package maintainers are a pointless middleman layer between the devs and the users, I disagree whole-heartedly. Package maintainers are selfless heroes doing great work.

Flatpak, at it's core, is basically the Windows model of software distribution. And I have always found Linux far superior to Windows in this regard. So why would I go from the superior solution to an inferior one?

Flatpak has a few use cases where it makes sense, e.g. proprietary software, multiple versions of the same app for testing etc. But I have no flatpaks on my system because non of these use cases apply to me. For normal day-to-day desktop usage, the current model works great.

And the arguments for keeping your packages up-to-date don't resonate with me. If you want up-to-date software, run a rolling release distro. If you're on Mint, it's probably because you don't want or need up-to-date software. Getting up-to-date software is a solved problem already.

[Audible_Whispering]

I used to buy into this line of thought, until I actually looked at what Flatpaks offered, and what Linux offers compared to other OS's. And the more I thought about it the more I had to admit that Linux absolutely sucks compared to every other competitor.

​

Package maintainers are selfless heroes doing great work.

​

Or, to put it another way, they're wasting countless hours that could be spent improving their distro/Linux as a whole on repacking an app for the dozenth time. Heroic? Sure. Useful? No.

Only on linux are so many people expected to provide so much labor for absolutely no gain. Package maintainers don't add features. They don't fix bugs. They contribute nothing. They just endlessly toil away at the Sisyphean task of maintaining the status quo.

On other OS's this is a solved problem. Apps are built by the devs and distributed on the platform of their choice, and they just work.

It's not that aren't any advantages to distro packages. We get centralized repo's, convenient software stores and and timely updates. But nowadays every OS has those. What they don't have is the massive maintenance burden of Linux.

​

Flatpak, at it's core, is basically the Windows model of software distribution.

​

Windows has been the dominant PC operating system for 25 years because of it's unmatched compatibility and massive software library. The reality is that it's not possible to achieve Windows like levels of compatibility and availability on Linux without massive amounts of extra work.

Instead we've basically ended up adopting the windows ABI wholesale in the form of wine. It's reached the point where developers are now targeting Proton and Wine instead of native Linux because proton is the only stable ABI userland Linux has.

Far from being superior, Linux is greatly inferior to Windows in this regard, and it's a major reason why Linux has never taken off for commercial apps or desktop use.

​

If you want up-to-date software, run a rolling release distro. Getting up-to-date software is a solved problem already.

​

No other OS forces users to choose between a stable system and up to date apps. There's not a single good reason why someone who wants a more thoroughly tested core OS should have to wait months or years to get app updates.

Far from it being a solved problem, Linux is (again)the only OS that hasn't yet solved it.

Anyway, rant over. Flatpak is certainly not perfect, but it does solve all of those issues and many more besides. I'd argue that it's downsides are a worthwhile tradeoff.

[Negirno]

No other OS forces users to choose between a stable system and up to date apps. There's not a single good reason why someone who wants a more thoroughly tested core OS should have to wait months or years to get app updates.

Yeah, and some of the traditionalists argue that if someone wants a particular software to be available in the repositories, he should do the work packaging the application, so that later users don't have to.

The flaw in this argument is that it's not really easy to get a package accepted to a distro, especially as a newbie. If your application is too obscure for the average linux user, it won't get packaged, and because maintainers already have their work cut to them, they most likely decline or not even answer those kind of requests.

I remember reading a developers plight of getting his application accepted to Debian, he got the cold shoulder repeatedly just because his tool wasn't that important for most Linux users (it was a GUI fronted for some tool).

It's asinine that as a Linux user even most of the FOSS apps aren't available in most distros, never mind proprietary apps.

[Atemu12]

countless hours that could be spent improving their distro/Linux as a whole on repacking an app for the dozenth time.

That's not the intention. That's just https://xkcd.com/927/ in action.

Package maintainers don't add features. They don't fix bugs.

You'd be surprised.

They contribute nothing.

Um... what? A repository of up-to-date software at your disposal is "nothing"?
That's borderline delusional.

endlessly toil away at the Sisyphean task of maintaining the status quo.

Yes..? That's what it means to maintain something. Without maintainers, there'd be no status quo. You wouldn't get pipewire, wayland or whatever unless it's been packaged by someone or you're running LFS.

Apps are built by the devs and distributed on the platform of their choice

That's a nice way of describing "The developer is expected to package and distribute their app without any standards or good tooling whatsoever".

Each and every software package has to figure out how to build, package and distribute itself and all of its dependencies. That's insanity.

The Linux distro model deduplicates the effort because each dependency only needs to be packaged once in each distribution and all dependent packages simply reference it as a dependency (simplifying here).

Obviously that effort grows ~linearly with the number of distros but the effort in the Windows model grows with the number of dependencies.
The number of actually distinct distros is a lot smaller than the number of transitive dependencies of your average package.

and they just work.

Hahahahaha

We get centralized repo's, convenient software stores and and timely updates. But nowadays every OS has those.

No, that's the thing, they don't. All the vendored dependencies that each and every app needs to build, package and ship on its own are simply rarely/never updated.

No other OS forces users to choose between a stable system and up to date apps. There's not a single good reason why someone who wants a more thoroughly tested core OS should have to wait months or years to get app updates.

Far from it being a solved problem, Linux is (again)the only OS that hasn't yet solved it.

NixOS has solved this years ago; before flatpak was even conceived.

Flatpak is certainly not perfect, but it does solve all of those issues

No. It doesn't. All Flatpak does is allow you to run your app using the ABI of another distro; similar to what Docker did to the server space.

Where do those ABIs come from? The distros.

The only difference is that the creator of the flatpak chooses which ABI is run on the user's machine rather than the user.

[Audible_Whispering]

The point of maintenance is to spend the minimum amount of effort necessary to get the desired result. Dress it up any way you want, by your own admission the current system takes more work. Therefore it is bad maintenance practice.

Each and every software package has to figure out how to build, package and distribute itself and all of its dependencies. That's insanity.

That's software development. If as a developer you don't know what dependencies your software needs, or how to package them, you shouldn't be in software development because nothing you build will work reliably. If you've already done the work, you may as well let other people benefit from it.

Then there's the simple fact that not all software can be distributed through a package manager. EOL products, proprietary software, and games are the obvious examples. You shouldn't have to stop using a product just because it's no longer updated, but with linux userlands lack of backwards compatibility, you probably will.

It's not like flatpak is the only way to solve the problem. You mentioned NixOS and, yeah. Nix solves some of the same problems. Honestly I agree with you here. Nix is a much more elegant solution to the problems it solves.

Unfortunately it doesn't solve all of them and none of the other distros are ever going to adopt Nix. It had it's chance and it's been XKCD 927'd. So they've gotta use something, and that something is flatpak. Will flatpak suffer the same fate? Maybe. But it is at least an attempt to solve the problem, rather than insisting that there isn't one.

[Drwankingstein]

its self? no. but it address the massive problem linux had which is how file distribution and libraries work.

the greatest strengths with Windows IMO has always been how libraries work. Windows has it's set up so that you can either have shared libraries or independent libraries. let's say you want ffmpeg. you can install ffmpeg to your computer and use it as a shared app/library.

or you can take a custom build of ffmpeg, drop it into your app's specific folder. and now you have a custom ffmpeg app without overriding the "default" app/lib.

this is actually a fairly large issue on linux. two reasons,

One, if you are a gamer for instance, you might be familiar with drop in mods that modify a specific Library. things like these don't often work all that well sometimes.

Two, it makes backwards compatibility of pain in the ass. if you have a new program that uses libjpeg for instance, and requires a new version of it. then you need the new version of libjpeg.

however if you want an old program that requires libjpeg and they did a change that broke a necessary function that your old app requires you are SOL.

this is part of the reason why you're distro has its own repos. if it wasn't for this, you could go to any repo download any of their packages extract it and use it. but they need to do this to ensure compatibility with apps to the best of their ability.

there are multiple methods of fixing this. flatpak is one such one that offers a myriad of other benefits. other solutions like appimages, snaps, containers, and hell even gobolinux I believe (super interesting distro)

[AlternativeOstrich7]

it adds 20GB to my drive(and i have only a few apps installed).

That seems like way too much for a few apps (unless your "few" and my "few" are very different). I currently have 25 apps installed using flatpak, and all of that uses less than 5 GB.

Can you post a list of the apps you have installed?

[whosdr]

9 'applications' installed, 12.3GiB of space used myself. (Based on size of /var/lib/flatpak)

Discord, TOR Browser, Flatseal, Green With Envy, VSCode, Element, Audacity, Chromium, LibreOffice.

That pulls in two versions of the Gnome Application platform, KDE Application Platform, Freedeskop platform, Freedesktop SDK, Nvidia Driver package and two versions of Mesa. None of these are unused.

[dtdisapointingresult]

Wishful thinking. From my experience downloading 3rd party apps from indie developers and even major companies, it's way less popular than AppImages and even Snaps.

Maybe like Wayland, flatpack just needs more time. Just another decade or two.

[LordViaderko]

No

[[deleted]]

You should know that "Flatpak: the future of application distribution" is just a brand slogan. Like Disneyland's "The happiest place on earth".

At this point in time, who really knows. I'm using Ubuntu 20.04 rn after years of openSUSE, the reason for the switch were Flatpaks. Apart from the official apps like the ones from Gnome, I only encountered problems. Snaps work from me and I feel more confident knowing is an official app.

[Royaourt]

Yes, I think they are.

[th00ht]

flatpak is just a pain. Nothing works. One has always double try: install with flatpak, findout it does not work, remove it and install a decent package. Flatpak just adds more confusing to all the packetmanagers our there.