A lot of flatkill.org’s statements are made to incite fear in the Linux community. Given that all Flatpak packages and application build scripts are available and able to be edited by anyone, the appropriate response is to educate on why this is a problem, and then fix it. The way that flatkill.org approached this issue says a lot.

Hi,

This is a direct response to flatkill.org 2020.

I’ve heard a lot of misinformation about Flatpak spread by the community and by a website called flatkill.org. I took the time to write my own response with the help of Flatpak contributors and developers to debunk the claims of flatkill.org to stop the spread of false information.

  • southerntofu
    5·
    4 years ago

    Hello, thanks for taking the time to write this answer. The issues outlined on flatkill.org were serious enough, but seeing basically no reply (except “FUD warnings”) from the community made me suspicious.

    I understand there’s a lot of tradeoffs at play, but i’m interested in following the debates around specific tradeoffs/issues. But from the flatpak.org website i cannot find the bugtracker or the source code for flatpak ; this could probably be improved.

    I like the new UI for sandboxing status including a colored warning when the sandboxing applied is practically useless. This addresses what is in my view the biggest problem.

    Last question (sorry i’m curious :D) do you think there’s hope to integrate flatpak concepts (eg. sandboxing portals) with a consistent/reliable/reproducible build system like Nix/guix? They are an amazing approach to software packaging but in my view lack UX/integration concerns that flatpak is trying to solve.

    • TheEvilSkeleton@lemmy.caOP
      41·
      4 years ago

      Hello, thanks for taking the time to write this answer. The issues outlined on flatkill.org were serious enough, but seeing basically no reply (except “FUD warnings”) from the community made me suspicious.

      I agree that the issues are serious, but what they fail to see is that new technologies always take time to get implemented and adapted. systemd didn’t start off great at the beginning; it had many security vulnerabilities and many bugs, but as time went by, systemd has matured and has become the standard init system.

      Technologies outside of Linux have experienced the same thing: Bluetooth, SSDs, Android, and more.

      Punching holes in the sandbox (as Flatpak is doing right now) is just a temporary approach. But as time goes by, more applications will start using portals. Qt5 and GTK3 applications already use portals. Firefox uses it, Chromium uses it, Electron is being worked on.

      Unfortunately, in terms of security that is easy for the end-user, Flatpak is the best we have. Projects that are close to FreeDesktop, such as systemd, GNOME and Fedora often have been very quick in development thanks to the effort of developers, and I doubt Flatpak will be an exception.

      But from the flatpak.org website i cannot find the bugtracker or the source code for flatpak ; this could probably be improved.

      Not sure what you meant here exactly, but if you asked for the source code of Flatpak, here you go: https://github.com/flatpak/flatpak.

      Last question (sorry i’m curious :D) do you think there’s hope to integrate flatpak concepts (eg. sandboxing portals) with a consistent/reliable/reproducible build system like Nix/guix? They are an amazing approach to software packaging but in my view lack UX/integration concerns that flatpak is trying to solve.

      Yes. In fact, that is one of the areas where Flatpak is trying to solve. If you use immutable desktops like NixOS, Guix, Endless OS and Fedora Silverblue, Flatpak can be very useful as it doesn’t need to create a new image everytime you need to install, upgrade or remove something. In fact, Fedora Silverblue and Endless OS use Flatpak by default. As a Fedora Silverblue user here, I have no problem with Flatpak