• Is it though? is it integrated by default in your desktop environment? Can you easily add 3rd party repos from GUI? Can you finely edit the sandboxing settings for an app from GUI?

      Hell, i can’t even find how to make flatpak apps respect my keymap for keybindings. Inside a flatpak run’ed app, typing respects AZERTY but pressing Ctrl+A will trigger quit dialog (Ctrl+Q) as if i used QWERTY keymap.

  • There has never been a better time to ship a binary app that targets the Linux desktop. And I don’t mean targets its own bundled runtime; I mean truly targets the user’s runtime environment. The time is now.

    I have my doubts. If I compile something for Linux today, I don’t believe the chances are great, that this binary will run on an arbitrary Linux.

    If that is true, am I able to download some binaries from any distributing package repository unpack it, and run it? Can I just run an Arch-Linux KCalc and run it on an Ubuntu 20.04? Will it be able to run in 25 years?

    I think this is the one thing that those package managers will be able to solve.

    I understand the critics, but I do not see an alternative as of now.

  • Mass containerization and alternate runtimes cannot possibly be the future of desktop apps on Linux. If this is really the direction it’s going, the future will be so shitty that we’ll all end up back on macOS or Windows.

    This posts features great complaints but really shitty reasoning. Very immature perspective on things.

    If you are so upset about it, name the perfect alternative, contribute to one, or go make one. This post barely approaches solutions and spends all of it’s time whining about the outcome of technology choices without even touching on what they would change.

  • As a user of arch btw for many years, does anyone have any link to anything that fully goes into why a lot of distros such as arch don’t have this problem? Packages, runtimes, and dependencies have been a non-issue on arch (and I’m sure other distros with proper package managers) for a long time.

    • If you use your distro’s up-to-date built and packaged from source applications it’s unlikely you’ll have a problem. Those start when you want to use old packages or packages from a different distro (with different or patched libs) with your system.

      Flatpak, AppImage etc. packaged apps will run on (almost) any system and you only need to build them for different processor architectures. So it’s the ovious choice for lazy or profit oriented developers.

    • Dependencies can absolutely be a problem. Let’s say you have a Python program that relies on an older version of a package due to a breaking change. With Arch those packages are installed in a per-Python interpreter global namespace. So if two applications have conflicting version requirements for a package, you’re kind of screwed. Yes, there are ways around the issue, but it’s not customarily used in Arch.

      This is just not a problem with Flatpak. The dependencies can be installed directly with no fears about causing a conflict. Even if the Flatpak itself uses a runtime, that runtime allows the Flatpak to add its Python dependencies as a simple layer on top. This happens independently of any other Flatpaks.