You know what I just realised? These “universal formats” were created to make it easier for developers to package software for Linux, and there just so happens to be this thing called the Open Build Service by OpenSUSE, which allows you to package for Debian and Ubuntu (deb), Fedora and RHEL (rpm) and SUSE and OpenSUSE (also rpm). And then the dudes that do AUR packages can take a deb package and write a PKGBUILD that installs it on Arch and Artix. I think I just solved the universal packaging problem.

And maybe we can get OBS to add PKGBUILD support…

Also, feel free to let me know what you think about it as I’m genuinely curious: did I miss anything obvious? Thanks

  • MrSoup@lemmy.zip
    192·
    7 months ago

    The universal packaging problem is having all the dependencies for all the software, making it all available for end users, in one place and easily make those packages for virtually every distro by developers wanting to target Linux systems. A lot of companies do not support Linux for this reason: there is no one single format to distribute software (not considering tar.gz).

    Having a tool that convert packages to other distro’s package format does not solve this, it’s just a long chain which original devs of a software are not in control of. The idea of Flathub and Snapcraft (the repos, not flatpak/snap) is to make one place for third party devs to publish their software (foss and not).

    Also, flatpak is trying to make a “standard” api to interact with the host system thru the sandbox for privacy/security reasons (like android).

    • theshatterstone54@feddit.ukOP
      72·
      7 months ago

      Yeah, but

      1. Using a tool that allows you to build using OBS once, and distribute for all distros is already a solution that makes it possible to target all of Linux.

      2. Flatpak’s sandbox isn’t really doing much for security/privacy as addressed by this: https://flatkill.org/2020 (Main concerns relate to pretty much every app escaping the sandbox making the sandbox essentially useless, and concerns that application runtimes bundled with flatpak are far less likely to be updated and patched than dependencies on your host system, and runtimes often actively contain security holes that are unpatched for runtime versions still used by applications.

      BUT BUT

      I have to agree that if it gets companies to support more Linux software, then I’m sure we can deal with it. HOWEVER, there is another issue, the issue of confusion. After all, isn’t one of the main reasons for trying to get more software on Linux, to use that software to get more people to use Linux? For that we need a more user-friendly approach, we need to figure out how to get less permissive, well, permissions, to applications, as well as to apply system theming by default (I know theming is controversial with the whole “don’t theme my apps” debacle but I think it would be great to have

      AND YES, this post was mostly an experiment to see what people think and how they’d react to differing opinions different from the status quo. I’m actually team Flatpak. I think what Ubuntu has recently done to improve Snap speeds is great (now if only all the apps on Snapcraft updated to implement it all), but almost no apps have taken advantage of it. AppImage shows some promise in its simplicity, but that sacrifices a lot of usability and makes a lot of the improvements seen in snap and especially in Flatpak near-impossible (for example theming and .desktop file support).

      I’ll be honest, probably the only issues I have with flatpak are:

      1. having to type the whole thing. What I mean is running “flatpak run one.ablaze.floorp” instead of just “floorp”, for example. How about we do away with the whole “org.ablaze.floorp” and make it possible to just use “floorp”, the same way you can do that during an installation! If it’s been implemented for “flatpak install”, why not “flatpak run”, and even better, why not make it into some sort of alias, where you can run, say, “floorp-flatpak” from Terminal or a Run launcher?

      2. Flatseal. I mean, Flathub has THE control center for Flatpak apps and nobody has taken it upon themselves to make this more official (this should be like a standard package imo).

      3. Also for Flatseal specifically, can we make it easier to theme (gtk and qt) apps, (like a dropdown or something?) instead of having to look up the envvar name because I can’t remember it?

      4. Can we find a way to force apps that don’t really need full filesystem permissions to remove that? Maybe just have certain user folders, like Downloads and Pictures instead of the entire home directory as most apps simply don’t need this level of access? Maybe make the Flathub team decide on a case by case basis if the app really needs all that access and ask the dev to restrict that as a requirement for being added to Flathub? If you claim to offer security and privacy, might as well prove it.

      I think that’s about it.

      • joojmachine@lemmy.ml
        2·
        7 months ago

        Can we please, in the year of the lord and savior, stop linking to flatkill for once? They have been debunked at least 5 different times at this point, so let me link to a couple of them: https://orowith2os.gitlab.io/posts/Flatpak-an-insecurity-nightmare/

        https://theevilskeleton.gitlab.io/2021/02/11/response-to-flatkill-org.html

        Some of your points aren’t bad, just not up to date to what most of the ecosystem has been doing for a while now.

      • MrSoup@lemmy.zip
        21·
        7 months ago
        1. Using a tool that allows you to build using OBS once, and distribute for all distros is already a solution that makes it possible to target all of Linux.

        There are projects using this method, but bigs like BlackMagic would prefer shipping one package (like he does right now with DaVinci Resolve). Anyway, after installing a package downloaded from a site, how do you update it? Who publish that software should make a repo for every package type or making app update itself (like apps on Windows do).

        Flatpak’s sandbox isn’t really doing much for security/privacy as addressed by this: 

        Thanks for the link, I was aware of those issues but wasn’t aware of this website. Anyway, the major issue here is old bundled libraries, with further spreading of flatpak other issues should be trivial to fix, I hope.

        we need to figure out how to get less permissive, well, permissions, to applications

        Libportal should fix this.

        as well as to apply system theming by default

        My flatpaks apps follows system theme by editing global vars, there are a bunch of guides to do it. Distros could add them by default, but (as you said) theming is still controversial.

        AND YES, this post was mostly an experiment to see what people think and how they’d react to differing opinions different from the status quo.

        Next time just ask. Would make more people engage in commenting rather than just downvoting.

        having to type the whole thing. What I mean is running “flatpak run one.ablaze.floorp” instead of just “floorp”, for example.

        That’s to avoid conflicts, flatpak install looks up for entries that’s why you don’t have to write the whole thing.

        Flatseal. I mean, Flathub has THE control center for Flatpak apps and nobody has taken it upon themselves to make this more official

        What flatseal does is giving a GUI for configuring flatpaks, you can just use flatpak command itself from cli (that’s the official way). That should be embedded in system settings (gnome-control-center for gnome).

        Also for Flatseal specifically, can we make it easier to theme (gtk and qt) apps, (like a dropdown or something?) instead of having to look up the envvar name because I can’t remember it?

        This is entirely feasible, try ask flatseal devs by opening an issue.

        Can we find a way to force apps that don’t really need full filesystem permissions to remove that?

        Maybe like Android does: first time you open an app it asks you to grant permissions to that app without giving them all the permissions it asks by default. That way you can just opt which permissions would like to give to an app on installation or first launch, tho this is not what happen right now because can entirely break some apps so it’s up to power users to tweak it.