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
    182·
    6 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·
      6 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·
        6 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·
        6 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: https://flatkill.org/2020

        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.

  • Shareni@programming.dev
    9·
    6 months ago

    standards

    Also, different solutions have different benefits and downsides, and are better in different scenarios.

  • coolmojo@lemmy.worldEnglish
    114·
    6 months ago

    FlatPak and snaps are not only solving the universal packing problem, but in addition: providing necessary libraries which are not present on the main system; an be installed on multiple architectures (x86, arm, etc); sandboxed.

  • Fredol@lemmy.world
    84·
    6 months ago

    I can’t believe sometimes I am part of the same community as people like you

  • Max-P@lemmy.max-p.me
    3·
    6 months ago

    The problem is that you can’t just convert a deb to rpm or whatever. Well you can and it usually does work, but not always. Tools for that have existed for a long time, and there’s plenty of packages in the AUR that just repacks a deb, usually proprietary software, sometimes with bundled hacks to make it run.

    There’s no guarantee that the libraries of a given distro are at all compatible with the ones of another. For example, Alpine and Void use musl while most others use glibc. These are not binary compatible at all. That deb will never run on Alpine, you need to recompile the whole thing against musl.

    What makes a distro a distro is their choice of package manager, the way of handling dependencies, compile flags, package splitting, enabled feature sets, and so on. If everyone used the same binaries for compatibility we wouldn’t have distros, we would have a single distro like Windows but open-source but heaven forbid anyone dares switching the compiler flags so it runs 0.5% faster on their brand new CPU.

    The Flatpak approach is really more like “fine we’ll just ship a whole Fedora-lite base system with the apps”. Snaps are similar but they use Ubuntu bases instead (obviously). It’s solving a UX problem, using a particular solution, but it’s not the solution. It’s a nice tool to have so developers can ship a reference environment in which the software is known to run well into and users that just want it to work can use those. But the demand for native packages will never go away, and people will still do it for fun. That’s the nature of open-source. It’s what makes distros like NixOS, Void, Alpine, Gentoo possible: everyone can try a different way of doing things, for different usecases.

    If we can even call it a “problem”. It’s my distro’s job to package the software, not the developer’s. That’s how distros work, that’s what they signed up for by making a distro. To take Alpine again for example, they compile all their packages against musl instead of glibc, and it works great for them. That shouldn’t become the developer’s problem to care what kind of libc their software is compiled against. Using a Flatpak in this case just bypasses Alpine and musl entirely because it’s gonna use glibc from the Fedora base system layer. Are you really running Alpine and musl at that point?

    And this is without even touching the different architectures. Some distros were faster to adopt ARM than others for example. Some people run desktop apps on PowerPC like old Macs. Fine you add those to the builds and now someone wants a RISC-V build, and a MIPS build.

    There are just way too many possibilities to ever end up with an universal platform that fits everyone’s needs. And that’s fine, that’s precisely why developers ship source code not binaries.