6mo ago

Flatpak haters seem to believe that if an app isn't on their distro's repos, it's the developers' fault.

200 comments

Flatpaks aren't perfect, but I think it's a good solution to the fragmentation problem that is inherent to Linux.
- Precisely. Flatpaks solve an important problem. Perfect should not be the enemy of good.
  Binary compatibility is a sad story on Linux, and we cannot expect developers — many of whom work for free — to package, test, debug, and maintain releases for multiple distributions. If we want a sustainable ecosystem with diverse distributions, we must answer the compatibility question. This is a working option that solves the problem, and it comes with minor security benefits because it isolates applications not just from the system but from each other.
  It’s fair to criticize a solution, but I think it’s not fair to ignore the problem and expect volunteers to just work harder.
  
  Also companies are lazy and if we don't want to be stuck on Ubuntu for proprietary app stability. We should probably embrace something like flatpak. Also when companies neglect their apps, it'll have a better chance of working down the road thanks to support for multiple dependency versions on the same install.

I like Flatpak just because it isn't Snap
- The enemy of my enemy, eh?
  
  ...is my enemy's enemy, no more, no less. (Maxims of Maximally Effective Mercenaries #29)
- Fair. Also, flatpak does not try to break everything by default, which is a plus.

Laughs in AUR
- Laughs in nixpkgs
  
  Laughs in confusion
  (I dont know how i got here)
  
  Cracks up in ebuilds
- I like the aur too but a proprietary app that isn't updated to support newer dependencies, it most likely won't run anyway. At that point it's either broken app, broken system, or you don't have anything else installed using that library(yet).
  
  Not an issue on NixOS, you can ship old deps with it
- Not great to laugh at the mess Linux is in, due to people paddling in different, incompatible, directions. Users can't choose the package format. They have to take what they are given. Good or bad. I don't care which format. As long as it works. But this is a good way to scare more people off of Linux.
  
  laughs at people scared of choice and "mess" . . .
  If they're switcing to linux they should first come to know about open source forking around - arguably - one of the most important features of the whole thing.
  If they don't wan't that choice and all that inevitable open source forkery, they probably should go for an apple mac or windows or something like that. And maybe they will have to pay for some software for the privilege because it takes work to do those things. They can of course try plain old ubuntu and do stuff the way canonical wants, that removes quite a bit of choice if it is otherwise too terrifying for them.
  But in general, I don't think its a good idea to to try to sell pig-carcasses to vegans by painting them the colours of broccoli.

Lol who the fuck is blaming app devs? Also something something arch
- aur is the only thing I miss. I do like fedora with i3 very much but rpm can be pain in the ass sometimes
  
  could you perhaps run them with Distrobox? i was always wondering that.
  
  distrobox?, i also installed nix and works perfectly
- ...btw

Flatpak is nice but I really would like to see a way to run flatpakked application transparently e.g. don't have to
undefined

flatpak run org.gnome.Lollypop
and can just run the app via
undefined

Lollypop
- You could make aliases for each program, but I agree, there should be a way to set it up so they resolve automatically.
  
  You could possibly also make a shell script that does this automatically. I believe most flatpak ids follow a pattern such as com.github.user.package, for github projects for example. So you could loop through all installed flatpaks, extract the name, and then add the alias.
- You can symlink /var/lib/flatpak/exports/bin/org.gnome.Lollypop (if you are using a system installation) or ~/.local/share/flatpak/exports/bin/org.gnome.Lollypop (if you are using a uset installation) to ~/.local/bin/lollypop and run it as lollypop.
- Well, Flatpak installs aliases, so as long as your distribution - or yourself - add the <installation>/exports/bin path to $PATH, then you'll be able to use the application IDs to launch them.
  And if you want to have the Flatpak available under a different name than its ID, you can always symlink the exported bin to whatever name you'd personally prefer.
  I've got Blender set up that way myself, with the org.blender.Blender bin symlinked to /usr/local/bin/blender, so that some older applications that expect to be able to simply interop with it are able to.
  
  Is there some way to set an install hook that automatically makes those symlinks when you install a flatpak?
- put flatpak in your PATH and you can youse the app name like normal
- I just run them raw, like just
  org.gnome.Lollypop
  Not ideal, but it's what I do
  
  It's fecking raw!

If I can choose between flatpack and distro package, distro wins hands down.
If the choice then is flatpack vs compile your own, I think I'll generally compile it, but it depends on the circumstances.
- Why?
  
  Because it's easier to use the version that's in the distro, and why do I need an extra set of libraries filling up my disk.
  I see flatpack as a last resort, where I trade disk space for convenience, because you end up with a whole OS worth of flatpack dependencies (10+ GB) on your disk after a few upgrade cycles.
  
  Stubbornness
- I'm 100% on this camp.
- I change my opinion depending on which app it is. I use KDE, so any KDE app will be installed natively for sure for perfect integration. Stuff like grub costumizer etc all native. Steam, Lutris, GIMP, Discord, chrome, firefox, telegram? Flatpak, all of those. They don't need perfect integration and I prefer the stability, easy upgrades and ease of uninstall of flatpak. Native is used when OS integration is a must. Flatpak for everything else. Especially since sometimes the distro's package is months/years old... prefering distro packages for everything should be a thing of the past.

Flatpak haters hate new apps anyway.
- glibc 2.36 is all you'll ever need, okay? Go away with those goddamn backports!

Haters aren't worth listening to. Doesn't matter if it is flatpak, systemd, wayland, or whatever else. These people have no interest in a discussion about merits and drawbacks of a given solution. They just want to be angry about something.
- I know, right!? Add gimp to that list as well. I can go on and on about shortcomings of gimp despite being a happy user. The average gimp hater, on the other hand, doesn't have anything to say besides "the UI is dumb and I can't figure out how to draw a circle"
  
  "The UI is unintuitive" is a legitimate complaint
- Wayland gets the hate because compositors are authoritative so you cannot e.g. install your own window manager, taskbar, etc. It would be good if there were specifications governing these, but there isn't.

I'm a Debian fan, and even I think it's absolutely preferable that app developers publish a Flatpak over the mildly janky mess of adding a new APT source. (It used to be simple and beautiful, just stick a new file in APT sources. Now Debian insists we add the GPG keys manually. Like cavemen.)
- Someone got to say it....
  There is no Debian if everything was a pile of Snaps/Flatpack/Docker/etc. Debian is the packaging and process that packaging is put through. Plus their FOSS guidelines.
  So sure, if it's something new and dev'y, it should isolate the dependencies mess. But when it's mature, sort out the dependencies and get it into Debian, and thus all downstream of it.
  I don't want to go back to app-folders. They end up with a missmash of duplicate old or whacky lib. It's bloaty, insecure and messy. Gift wrapping the mess in containers and VM, mitigates some of security issues, but brings more bloat and other issues.
  I love FOSS package management. All the dependencies, in a database, with source and build dependencies. All building so there is one copy of a lib. All updating together. It's like an OS ecosystem utopia. It doesn't get the appreciation it should.
- And then change where we put them.
- Now Debian insists we add the GPG keys manually. Like cavemen.)
  Erm. Would you rather have debian auto-trust a bunch of third party people? It's up to the user to decide whose keys they want on their system and whose packages they would accept if signed by what key.
  
  Not "auto trust", of course, but rather make adding keys is a bit smoother. As in "OK, there's this key on the web site with this weird short hex cookie. Enter this simple command to add the key. Make sure signature it spits out is the same on the web page. If it matches, hit Yes."
  And maybe this could be baked somehow to the whole APT source adding process. "To add the source to APT, use apt-source-addinate https://deb.example.com/thingamabob.apt. Make sure the key displayed is 0x123456789ABC by Thingamabob Team with received key signature 0xCBA9876654321."

If you're separating your application from the core system package manager and shared libraries, there had better be a good and specific reason for it (e.g. the app needs to be containerized for stability/security/weird dependency). If an app can't be centrally managed I don't want it on my system, with grudging exceptions.
Chocolatey has even made this possible in Windows, and lately for my Windows environments if I can't install an application through chocolatey then I'll try to find an alternative that I can. Package managers are absolutely superior to independent application installs.
- Typically Windows applications bundle all their dependencies, so Chocolatey, WinGet and Scoop are all more like installing a Flatpak or AppImage than a package from a distro's system package manager. They're all listed in one place, yes, but so's everything on FlatHub.
  
  This is true, the only shared libraries are usually the .NET versions, but so many apps depend on specific .NET versions that frequently the modularity doesn't matter.
- I'm not sure where you're getting the idea that Flatpak aren't centrally managed...
  
  Can I sudo apt upgrade my installed flatpak apps?
- I think containerization for security is a damn good reason for virtually all software.
  
  Definitely. I'd rather have a "good and specific reason" why your application needs to use my shared libraries or have acess to my entire filesystem by default.
  
  emerge sec-policy/selinux-*
- I think stability is a pretty good reason
  If an app can't be centrally managed
  Open Discover, Gnome Software etc -> Click update?
  
  undefined
  
  flatpak upgrade
  
  Oh no, no GUI nonsense. Single, simple shell command update for the whole system so that it can be properly remotely managed, please. Something equivalent to sudo apt upgrade
- Flatpack can be centrally managed, it's just like a parallel distribution scheme, where apps have dependencies and are centrally updated. If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.
  "App image" and " install from tarball" violate those principles, but not snap or flatpack.
  
  Um, if it's "parallel" (e.g. separate from the OS package manager) then it's not centrally managed. The OS package manager is the central management.
  There might be specific use cases where this makes sense, but frankly if segregating an app from the OS is a requirement then it should be fully containerized with something like Docker, or run in an independent VM.
  If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.
  That feels like a load-bearing "if". I never have to worry about this with the package manager.

If you really hate flatpak just make an arch distrobox and download off the AUR. Or install Nix or something
- I do sort of wish Nix was a more popular distro agnostic solution
- That's what I've done with my deck. Some things just aren't available through discover, and the Firefox build on there has behavior that I don't like or know how to correct. Distrobox gives me access to the Arch repos + AUR with persistence that you can't get on SteamOS without it.
  
  SteamOS is an arch derivative, so you could also just install arch, add the SteamOS repos, and set the steam UI in gamescope to launch on login
- Or just use Arch... only for half of your AUR packages to be broken and end up still using flatpaks anyways.
- Install Gentoo and put the package on GURU, it's really easy (and .ebuild > PKGBUILD)

I'm new to Linux. Every time I've had a major issue with an application it turned out to be due to a flatpak. I'll stick with other options for the time being.
- Also at least let me compile it myself if not in a repo 😩

They do? I've always seen that as being up to distro maintainers, and out of control of the devs.

And this, this is why I love the AUR
- I think no one said it needs to be ON a distro's repos. That's a straw man.
  A package should be available in a native package format in a way that doesn't cause conflict with what's in the official repo. The reasons for a single source of truth on installed status should be obvious; but given the format of some packaging and the signed assurance of provenance, thr advantages to a native format can be leaves ahead of even that.
  Wow, is this meme a really naive take that is contradicted by - oh god, everything. Can someone know about enterprise Linux and also be this naive?
  
  The responsibility to figure out the dependencies and packaging for distros, and then maintain those going forwards, should not be placed on the developer. If a developer wants to do that, then that's fine - but if a developer just wants to provide source with solid build instructions, and then provide a flatpak, maybe an appimage, then that's also perfectly fine.
  In a sense, developers shouldn't even be trusted to manage packaging for distributions - it's usually not their area of expertise, maintainers of specific distributions will usually know better.
- "oh this is a flatpak or hell even a windows exe..." proceeds to search for it on AUR "ah there it is, wonderful!"
  Hell I've found a god damn windows gaming cheat trainer on AUR and it worked.
  
  The AUR is basically just a script that describes best case scenario for building something under Arch. They don't have any specific quality rules they have to meet.
  It's super easy to make and publish an AUR script compared to a regular distro package (including Arch packages).

laughs in appimage.

Are those flatpak haters that say that in the room with us right now? The main difference with distro repos is that packages in it are packaged by the distro packagers and everyone who has an opinion on flatpak should know that this is how it works.
- The main difference with distro repos is that packages in it are packaged by the distro
  Uh... Yes? That's what the meme says?

False, if it exists in the Linux ecosystem it also exists in AUR
- The broader meta point is that X thing you want isn't the devs job, btw.
  
  X thing you want isn’t the devs job
  Well, it is if they decide it is, and it isn't if they decide it isn't.
  That said, I do appreciate devs who put up native deb or rpm repos for the most common distros.

Just compile from source?
- Back in the day, when I installed my very first Linux OS, I had a wireless stick from Netgear. Wireless Drivers back then were abysmal, so I had to compile them from source (literally 15 mins after seeing a TTY for the first time). After I had found out how build-dependencies and such worked somehow and ./configure completed successfully for the first time, the script ended with the epic line:
  configure done. Now type 'make' and pray
  
  Ah, I had one of those wireless sticks from Netgear as well, probably a different model but still a royal pain to get it working.
  Luckily ndiswrapper has become a thing of the past nowadays.
- Because it's always so easy to compile everything you need from source! Just make sure to download, compile and install the dependencies first as well. Oh, and the dependencies' dependencies. And the ones from them. And so on. Unless you're lucky enough that there are already packaged dependencies available for you. Don't know how to compile? No problem, just read the documentation. You can be absolutely 1000000% dead serious sure that everything you need to know is documented and extremely super duper easy to understand if you don't know the source code or barely know how to code at all. And if not, maybe you can find the bits of information on the respective Discord server. It will probably be also very intuitive to know which build options you have to set in which way and which ones even exist. And that without causing conflicts with other packages you need to compile. Still got got problems with compiling? EZ, just open a bunch of issues on the respective GitHub pages. (If present. Otherwise, try to find another way to contact devs and get support, Discord for example.) Maybe, about six months later you're lucky to get a response. And if not, don't worry. Some will tell you, you should RTFM or are an idiot. Some will just close the issue because your platform isn't supported anyway. Then you know, what you did wrong. Also don't mind if your issue gets ignored.
  If you finally managed to compile everything from source, congratulations! Now run the program and test if everything is working. If it's not or if it is crashing, don't worry! In developed and civilised countries you can just buy a shotgun and blast your own head away to end this suffering.
  EZ! Just compile from source! /s
  
  I just complie from source some lightweight programs that are too niche for repositories. I am in no way advocating for full source compilation of every program in your system, that's a security and usage nightmare. Flatpack does have its use for sandboxing an environment. I personally use it for windows applications in bottles.
  
  My workflow always definitely includes multiple weeks to debug random issues with building the tools I need to use. Totally a scalable and good solution to dump this work on the end user.
  
  You have rediscovered LFS
- This doesn’t scale. If I have a bug and my package has about two dozen dependencies which can all be different versions, and the developer can’t reproduce my bug, I’m just screwed. Developers don’t have the time and resources to chase down a bug that depends on build time variables.
  Ask me how I know this happens.
- I like the ports tree that only compiles from source, yes it's slow, but you know the binaries you make are pure.
- Not optimal
  
  Yes, it would depend on your flatpack usage. For me I only have like 5 programs compiled from source and one flatpack (bottles) because of the sandboxing

Meanwhile almost everything I ever wanted is either in main Gentoo repo or in there is overlay with it.
- Honestly, main + guru has not made feel like anything's missing at all.
  
  Main + kdab + steam

I just distribute it as a self-contained executable/archive. ¯(ツ)_/¯
- Valid solution, but I miss unified updates with appimages and such
  
  Yeah, that's the fun part. Hooking into some auto-update mechanism would be useful to me.
  But my stuff is mostly in the scratching-my-own-itch stage, so setting up a FlatHub account, Flatpak metadata, sandbox rules, probably an icon and screenshots and whatnot, and automating the build+releases, just to get auto-updates, yeah... no.
  I could code a whole nother project in the time that would take.
- As long as your application is statically linked, I don't see any issue with that.
  
  So, like, dumb question. People here assumed that I mean AppImages, whereas I actually meant just a statically linked binary. Is that really the only reason why AppImage exists? So, that dynamically linked applications can be distributed like statically linked ones?
- AppImage for the win!

https://openbuildservice.org/

Nix: you package it yourself and do a pull request
Sadly, many flatpaks don't even work on NixOS properly because of assumptions about the file structure or similar
- Exactly. And even if one doesn't know how to package it, they can just open a request issue.

I don't wanna be that guy, but someone has to say it: Nix Flakes
- I have both nix and flatpak lol. Different usecases: flatpak for stuff that I would rather have sandboxed (browsers, games), nix for stuff that I would rather be integrated into the system (command line tools, etc). Tho I still have to learn about flakes, right now I'm just using nix-env for everything like a caveman lol

Bottle's developers disagree with this meme
- I cannot use bottles since months due to their faltpak monogamy policy :/
  
  ..explain? It literally has Flatpak as first-class support, i.e. it's guaranteed and only guaranteed to work on Flatpak

You don't need the distro to package your sodtware through their package management systems though. Apt and dnf repositories are extensible, anyone can publish. If you go to copr or ppa you can have a little extra help too, without distro maintainers.
The headache comes up when multiple third party repositories start conflicting with each other when you add enough of them, despite they're best efforts. This scenario starts needing flatpack, which can, for example concurrently provide multiple distinct library versions installed that traditionally would conflict with each other. This doesn't mean application has to bundle the dependency, that dependency can still be external to the package and independently updated, it just means conflicts can be gracefully handled.
- The headache comes up when multiple third party repositories start conflicting with each other
  Which is traditionally why you needed the distro to package your software...
  
  Depends on if you stick to distro provided dependencies, then you are generally good, unless a third party repo decided to supersede that dependency.
  I have spent a long time carefully packaging as a third party repository and it's generally doable. Just sometimes another repository isn't as careful and blows away the distribution provided libraries.

I've never used it. Its like all the others though and I have been forced to use snaps. Those I slowly replace every time I decide to start fresh.
- Try linux mint, it's basically ubuntu but without snap (you can install snap if you want to, but it's not forced on you)
  
  Oh I have. I have it running on some older hardware.

flatkill.org
- that website is such a joke, I can't believe the guy's still paying for the domain name... The whole argument boils down to "Many flatpak apps don't make use of the sandbox by default, which is
  <somehow>
  less secure than not having a sandbox at all" and "this one app I like doesn't work in flatpak, therefore all of it is bad".
  ...unless it literally is a joke and I'm just missing out on the sarcasm?
  
  Its only worse than not having it at all in the sense of giving users a false sense of security. Imagine if apps on mobile could decide what permissions they want automatically granted without the user opting in. The sandbox HAS to be enforced by default to be good. And the other issue with flatpak is the security, which we had several problems with in the past. On the same note, people criticise snap but its a much more competent solution from a technical standpoint regarding security and since people get all their apps from flathub anyways, the "propreitary" backend is mostly irrelevant. And before anyone says "snap store had malware hosted" that is not an issue with the format itself but the infrastructure.

I know nothing about how flatpak works other than that it's containerized. But this meme tells me it's the OS's responsibility to create the flatpak, and not the developer's? Is that right?
- No the most common way is for devs to package their own software as a flatpak since you can typically choose your preferred packaging tool to use inside of the flatpak.
  Traditional package management typically is done by the distro maintainers.
  
  Oh I see, I've got it backwards.

People always forget about appimages.
- Your security people have not forgotten about appimages. It fills their nightmares.
- Same app in native format: 2MB. As a flatpak: 15MB. As an appimage: 350MB.
  Appimages are awesome, rock solid, and I have a few on my system, but flatpak never gave me any problem and integrates better with my KDE, and is smaller. Both have their advantages tho. I'm fine with using both. If you are a developer, make a flatpak or an appimage i dont really care just make your software available for linux. Both are fine, choose the one that fits your specific app the most.
  But I also think appimages deserve the same attention and great integration with the OS as flatpaks. Stuff like that AppImageLauncher functionalities should just be integrated inside the DE itself.
  But we need an universal package format for linux asap. Flatpak is on the front in this race, and I'm fine with it. Appimages second, for sure.
  
  If you don't run your install off a 12 zetabyte NAS are you even a real linux user?
- As they should /s
  Honestly its neat but I don't see why I would want it over flatpak ever

200 comments