Distro agnostic packages like flatpaks and appimages have become extremely popular over the past few years, yet they seem to get a lot of dirt thrown on them because they are super bloated (since they bring all their dependencies with them).

NixPkgs are also distro agnostic, but they are about as light as regular system packages (.deb/.rpm/.PKG) all the while having an impressive 80 000 packages in their repos.

I don’t get why more people aren’t using them, sure they do need some tweaking but so do flatpaks, my main theory is that there are no graphical installer for them and the CLI installer is lacking (no progress bar, no ETA, strange syntax) I’m also scared that there is a downside to them I dont know about.

    • TheEntity@kbin.social
      491·
      10 months ago

      In terms of the memory usage, it’s a reasonable approach these days. It gets hairy when we consider security vulnerabilities. It’s far easier to patch one system-wide shared library than to hunt down every single application still bundling a vulnerable version.

      • Ferk@kbin.social
        23·
        10 months ago

        The nice thing about Nix/Guix is that each version of a library only needs to be installed once and it wont really be “bundled” with the app itself. So it would be a lot easier to hunt down the packages that are depending on a bad library.

    • MilkLover@lemmy.ml
      25·
      10 months ago

      Nix is a bit of a middle ground. Each package has a specific set of dependency version. It calculates the hash of each dependency and compares it to those that you have installed. If it is installed, it uses that, if it isn’t, it installs it. This means that packages can have different versions and dependency hell is impossible, whilst also reusing existing dependencies if they’re the exact same.

    • cai@kbin.social
      16·
      10 months ago

      If you use any accelerated graphics (GTK4 anyone?), you cannot and must not bundle all your dependencies.

      Conceptually, graphics drivers have two parts: The part in the kernel (e.g. amdgpu), and the part loaded as a library from the system into the application (e.g. Mesa).

      Mesa - or any other GL/Vulkan implementation - is loaded from the system into the application as a library. Mesa relies on system libc, system LLVM (!!!), a particular libc++, etc.

      If you ship libGL (and LLVM etc), you must re-release your software with upgraded deps whenever new graphics cards are released (and should whenever bugs are fixed). Your software is literally incompatible with (some) newer computers.

      For the proprietary Nvidia libGL - which, again relies on system glibc - you can’t legally include it.

      Flatpak solves this by separating out ‘graphics driver libraries’ as a unique type of runtime, and having a shitload of special rules & custom hacks to check the system libGL, open source or proprietary, maybe substitute a Flatpak provided libGL, with all the deps that libGL needs, and make it compatible with whatever app & whatever app runtime.

      Actually correctly solving the libGL debacle is half the value of Flatpak to me.

    • clemdemort@lemmy.worldOP
      5·
      10 months ago

      Well the issue for me is internet speed, yesterday night I had to leave my pc on for two hours to update my flatpaks, I don’t even have that many of them, but the updates were mostly drivers and runtimes.

    • Avid Amoeba@lemmy.ca
      51·
      10 months ago

      Windows apps have been doing this for ages with disasterous security results due to the lack of mandatory OS sandboxing. E.g. CVE for admin level RCE via Adobe Flash. This model works with third party apps only when sandboxed. This was done from the get go on Android and now with Snap and Flatpak (I assume). It’s absolutely the way to go once the security framework is in place.