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.

    • ZephrC@lemm.ee
      link
      fedilink
      arrow-up
      0
      ·
      9 months ago

      By not being a universal packaging format. It uses your system libraries, which completely eliminates the main reason devs are pushing for things like Flatpak, Snap, or Appimage.

      • Ferk@kbin.social
        link
        fedilink
        arrow-up
        0
        ·
        9 months ago

        Huh? as far as I know it has its own libraries and dependency system. What do you mean?

      • TheEntity@kbin.social
        link
        fedilink
        arrow-up
        0
        ·
        9 months ago

        It doesn’t use the system libraries, unless the system on question is NixOS. It still provides its own dependencies. Arguably in a more elegant and less wasteful manner, but they are still distinct from the ones used by the rest of the system.

        • ZephrC@lemm.ee
          link
          fedilink
          arrow-up
          0
          ·
          9 months ago

          To be more clear, it uses a weird combination of your system libraries, installing its own libraries into your system on its own without informing your primary package manager, and using some specific library versions separate from your system libraries for some apps.

          If you want to call that more “elegant” than other solutions… Well, I can’t tell you how to feel about something. It still doesn’t actually solve the problem that universal package formats are trying to solve unless the package dev explicitly requires so many specific library versions that the whole thing just ends up being an AppImage with extra steps though.

          • Ferk@kbin.social
            link
            fedilink
            arrow-up
            0
            ·
            9 months ago

            The packager always should “explicitly require” what are the dependencies in a Nix package… it’s not like it’s a choice, if there are missing dependencies then that’d be a bug.

            If the package is not declaring its dependencies properly then it might not run properly in NixOS, since there are no “system libraries” in that OS other than the ones that were installed from Nix packages.

            And one of its advantages over AppImages is that instead of bundling everything together causing redundancies and inefficient use of resources, you actually have shared libraries with Nix (not the system ones, but Nix dependencies). If you have multiple AppImages that bundle the same libraries you can end up having the exact same version of the library installed multiple times (or loaded in memory, when running). Appimages do not scale, you would be wasting a lot of resources if you were to make heavy use of them, whereas with Nix you can run an entire OS built with Nix packages.

    • clemdemort@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      9 months ago

      From what I gather it goes something like this:

      • every package is assigned a hash
      • every package lists their dependencies through their hashes
      • different versions of packages have different hashes
      • when you launch an application it creates an environment with all its dependencies, this means that two applications that both use the same library at the same version share that library. However if they both require the same lib but not the same version of that lib they don’t share it.

      Which solves DLL hell as far as i understand it.

      • clemdemort@lemmy.worldOP
        link
        fedilink
        arrow-up
        0
        ·
        9 months ago

        Could you elaborate? I was under the impression that NixPkgs stored the hash of their dependencies and when launched create an environment to use them, this way two apps can share the same library when the version is the same.

        • chayleaf@lemmy.ml
          link
          fedilink
          arrow-up
          0
          ·
          9 months ago

          Nix doesn’t do anything special when launched.

          The way it works is very simple - instead of e.g. /usr/lib/libssl.so.3, binaries use /nix/store/openssl-…/lib/libssl.so.3. This is done at build time, not runtime.

  • mosiacmango@lemm.ee
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    9 months ago

    Inate complexity that keeps moving as they introduce things like flakes.

    Its a declarative configuration management system as package manager. Thats a lot more to handle off the bat than normal linux + flatpak.

    • 2xsaiko@discuss.tchncs.de
      link
      fedilink
      arrow-up
      0
      ·
      9 months ago

      Inate complexity that keeps moving as they introduce things like flakes.

      Flakes solve the problem of reproducibility for which nixpkgs (or other external input) revision to use (e.g. in a software project). The main thing they bring is a npm-like lock file and a predictable interface. You don’t have to use them if you don’t want that.

      Its a declarative configuration management system as package manager.

      No it isn’t. That’s NixOS, which is another thing built on top of Nix and nixpkgs. nixpkgs is first and foremost a package collection.

    • MilkLover@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      9 months ago

      It is a whole ecosystem:

      • Nix the package manager
      • Nix the functional language used to declare packages and configurations
      • NixOS that has the package manager and a system configuration in the functional language
      • Home Manager, which provides a configuration on the user level and can be used on NixOS as well as other distros and MacOS

      To start out it’s completely fine to just install Nix the package manager on a regular distro or on MacOS and use the nix-env command to install some packages. It will automatically use nixpkgs and use working dependencies for each package, whilst also checking if the depency is already installed to avoid installing the same one twice. This is pretty much the same thing as using Flatpak

      Flakes explanation:

      The Nix package manager has channels to manage package repos. It works like package managers on other distros where you simply have a list of urls to pull packages from, with Nix it would just be the nixpkgs release either a version number for stable or unstable for the unstable rolling release. Any time you install through the package manager or the config in NixOS, it will get the packages from the channel.

      The problem is that the channels aren’t very reproducible. The repos get updates regularly, especially unstable which updates even faster than Arch. Channels don’t provide an easy way to specify a single commit of the repo, except for entering a url with the commit version in it. For stuff like a shell.nix, you’d need to either import nixpkgs from the system’s channel or import the url of nixpkgs with a specific commit ID.

      Flakes is a feature that for some reason is still experimental after years, but many are already using it. It works like manifest.json and package.lock in a JavaScript project. You have a directory or git repo with a flake.nix file in which you specify your external dependencies like the nixpkgs release in the “inputs” section and your outputs in the “outputs” section, like a NixOS/Home Manager configuration, a shell or a package. Then when you use an output, Nix pulls the inputs and builds the output, it then generates a flake.lock file that contains all the inputs with their specific commit and hash. Now if you use an output again later with the same flake.lock, it will still use the exact same version as last time and should generate the exact same outputs. You just run nix flake update to generate a new flake.lock with new dependencies. You can’t use flakes with nix-env simply because installing packages imperatively without a config file defeats the point of reproducibility with flakes.

      Flake example with Home Manager:

      My Flake Repo/
      ├── flake.nix - nixpkgs input and home manager configuration output
      ├── flake.lock - generated by nix
      └── home.nix - home manager config import from flake.nix
      

      Here the home.nix file contains the config with the list of packages to install as well as configuration options for those programs. The flake.nix contains the nixpkgs input and a homeManagerConfigurations output that import the home.nix. You can run home manager switch --flake ./My Flake Repo to use that config from the flake. To update run nix flake update.

      • mosiacmango@lemm.ee
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        9 months ago

        I appreciate the breakdown, but you’ve basically made my point for me.

        The above, with its many advantages, versus:

        Sudo apt install X Y Z G F P -y

        Simple, clean, gets it done for near anyone.

        • Shareni@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          9 months ago

          Sudo apt install X Y Z G F P -y

          Debian 12 came out last June. In December the version of docker that’s shipped by Debian stopped being supported, and is now like 4 major releases behind nix. Debian won’t update it for at least a year and a half unless there’s some major security patch.

          Besides that, when Debian 13 gets released and I reinstall, I can just clone my dotfiles and use a single line to reinstall all of the packages I need. All of the packages are in a single list, and so there’s no more need to run health checks because I forgot to reinstall some random editor dependency for a language I use once a year. If I added it to the list it’s going to be on every machine running that list.

          • mosiacmango@lemm.ee
            link
            fedilink
            arrow-up
            0
            ·
            9 months ago

            Like most complex things in life, if you devout time to it and engage with it deeply you gain an advantage over a simplier version of the same thing. The question we all have to ask ourselves is “is this worth it?”

            I’d say in your specific “docker centric while using debain” use case, sure. Most people who use linux as a daily driver? Maybe not.

        • lemmyvore@feddit.nl
          link
          fedilink
          English
          arrow-up
          0
          ·
          9 months ago

          Not to mention that the most common problems it solves can be solved by installing packages from source in a prefix like /opt or ~/.apps and symlinking them from a central place like /opt/.system or ~/.apps/.system or whatever.

          I had a bash script 15 years ago that automated most of this. (Which gradually fell out of use when Arch and makepkg came along, but I digress.)

          I can’t help but feel like nix is a solution looking for a problem and solving it in a way that appeals to a certain kind of hobbyist but not so much to any practical purposes. Otherwise it would have been adopted more widely by now.

  • cybersandwich@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    Nix is the vim of package management but without good documentation. So it’s incredibly powerful and useful once you get into it, but imagine trying to learn vim without any docs or guidance. Vim has a steep learning curve with good documentation, YouTube tutorials, blog posts, and forum guides.

    Nix doesn’t really have a wealth of that.

    That’s nix package management and nixos in a nutshell.

  • Daniel Quinn@lemmy.ca
    link
    fedilink
    English
    arrow-up
    0
    ·
    9 months ago

    My guess would be that it’s because Flatpaks are easy. You have a handy GUI tool often pre installed that includes search and one-click install.

    If you want something lower level, Arch users have the AUR, and others may actually do that horrifying curl https://... | sh pattern.

    Nix pancakes on the other hand… I have no idea how to use them and generally assume it’s the thing NixOS uses. Since I don’t use NixOS, I’ve never given them a second thought.

  • onlinepersona@programming.dev
    link
    fedilink
    English
    arrow-up
    0
    ·
    9 months ago

    Because it has abominable documentation. Some tools built on top of nix on the other hand have stellar documentation (devenv and jetbox come to mind). The tools even try hard to hide nix because they know it’s a goddamn nightmare for beginners to use it.

    The CLI is a mess due to the indecisiveness of the nix maintainers whether they want flakes or not. So much so that the official manual doesn’t use flakes, but many guides on the internet immediately go into nix dev#yadadada which leaves beginners and mid-term users alike very confused.

    Another point is that graphical applications can’t use OpenGL without dirty hacks like nixgl. Not only that, installing GUI applications using nix doesn’t make them show up in your desktop environment (start menu, finder, whatever). No, you need to either manually create .desktop files or install another tool like home-manager to have them show (and not work properly because of OpenGL).

    To top it off, unless you know better, it’s command-line only. SnowflakeOS is building GUI tools around nix, but they aren’t like say Discover or the Gnome Appstore: you can’t install the GUI and have everything working - no, you need to figure everything out.

    In short, nix is absolutely nowhere close for desktop user adoption, much less mainstream linux adoption (dev, sysadmin, tester, or whatever other technical role exists).

    CC BY-NC-SA 4.0

    • caseyweederman@lemmy.ca
      link
      fedilink
      arrow-up
      0
      ·
      9 months ago

      Flakes confuse me.
      Guides online say “oh yeah just do this, it’s easy” and don’t mention flakes at all.
      So I try the thing and it says ARE YOU FUCKING SURE, YOU IDIOT, YOU ABSOLUTE MORON, YOU CAN’T DO ANYTHING WITHOUT ENABLING FLAKES AND YOU HAVEN’T DONE THAT SO YOU CLEARLY DON’T DESERVE NICE THINGS but like, is there just no non-flakes version of that thing, what’s the point of having an option that’s not enabled by default if you can’t do anything without it on

      • Drito@sh.itjust.works
        link
        fedilink
        arrow-up
        0
        ·
        9 months ago

        Flakes is still experimental. NixOS devs takes a bunch of time to release that. So most experienced users have enabled Flakes since years. Two different systems are available, which does not help ease of learning.

    • Matej@matejc.com
      link
      fedilink
      English
      arrow-up
      0
      ·
      9 months ago

      Dont know where you are getting this. Nixpkgs is a breeze to manage compared to apt repo. Also it does not matter if you are on nixos or non-nixos system, the only difference is that nix does not take care of services on its own. What kind of docs do you miss? Nix has its own extensive nix docs page, and for packaging you also have nixpkgs documentation page - also official and not much related to nixos itself. Also nix has quite good man pages.

      • neo (he/him)@lemmy.comfysnug.space
        link
        fedilink
        English
        arrow-up
        0
        ·
        9 months ago

        I’m not saying it’s not easy, I’m saying there’s not really any documentation about it.

        I had to figure out for myself that I needed to do symlinks to get menu entries for nix packages

        • Shareni@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          9 months ago

          I had to figure out for myself that I needed to do symlinks to get menu entries for nix packages

          Home-manager: I didn’t have to touch anything to get PATH and XDG working, it’s all automated.

          • moonpiedumplings@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            9 months ago

            But you don’t get hardware graphics acceleration unless you use nixgl, and if you want to integrate it into home manager that breaks XDG entries, which I never figured out.

            Also, you are illustrating the point of the commenter you replied to: nowhere on the official docs does it recommend home manager for non nixos systems, at least not when i was scrolling through them. I learned about home manager, nixgl, and the like via forum posts, either by finding them via a web search, or by asking myself.

            For example, I only found code to integrate home manager with nixgl on the nixos discourse.

            • Shareni@programming.dev
              link
              fedilink
              arrow-up
              0
              ·
              9 months ago

              Nix docs are hot garbage, but I’m pretty sure it tells you to reboot when you finish installing either nix or home-manager. It didn’t appear to me in a dream.

  • LalSalaamComrade@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    9 months ago

    TL:DR; they’re the package managers of the future, and I shill for them, but they’re still buggy in some areas.

    Guix and Nix user here. For all I can shill about store-based file hierarchy, ephemeral environment isn’t perfect yet in both of these apps, at least from a GUI application perspective. It’s a bug that I’ve found in Nix, but that should also reflect in Guix. Basically, what’s happening here is that due to some impurity in the environment, it uses libraries from the system instead, and apps may stop working. This is a very serious issue, and is directly related to what you’re talking about. This problem hides itself when using GuixSD in Guix or NixOS in Nix, but in other foreign distro that have dated libraries, it is very much visible, and you’ll be forced to use outdated channels.

    • root@precious.net
      link
      fedilink
      arrow-up
      0
      ·
      9 months ago

      Of the future? They’re a duplicate of what Apple was doing with software as far back as the mid 90s.

      Every ounce of performance we squeeze out of our hardware is replaced with pounds of bloat like this.

      It’s fine for a utility or something you’ll hardly ever need to use, but running every day software like this is a complete waste.

      • excitingburp@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        9 months ago

        What do you mean? Apple doesn’t have a package manager at all. Brew is a fucking mess that takes ages to do anything.

        • root@precious.net
          link
          fedilink
          arrow-up
          0
          ·
          9 months ago

          Having every application load their own version of a library into memory is bloat.

          • iopq@lemmy.world
            link
            fedilink
            arrow-up
            0
            ·
            9 months ago

            They don’t, they share the same library version if they were built against it.

            Lots of software won’t even work if the library version is different, so it’s a benefit, not a downside

          • AgileLizard@lemmy.ml
            link
            fedilink
            arrow-up
            0
            ·
            9 months ago

            The garbage collector removes all packages/derivations that are not (transitively) used any more. So it is similar to apt-get autoremove. I don’t think that classifies as bloat. You could just regularly run the garbage collector.

          • Shareni@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            9 months ago

            Rollback, reproducibility, safety.

            Would you call btrfs snapshots or some other backup system bloat?

            It actually serves an important purpose for the user. Meanwhile apt is leaving around random libraries and man pages you need to autoremove.

  • corsicanguppy@lemmy.ca
    link
    fedilink
    arrow-up
    0
    ·
    9 months ago

    Because nixPKGs have the same Single-Source of Truth wrecking problems as flatpaks and appimages and all that junk.

    There’s only so much room in the ecosystem for best-practice-violating product, and systemd takes up a lot of that. And until systemd collapses under the weight of doing a thousand things poorly for all the wrong reasons and delivering on none of its brochure features, the other entrants have to wait outside.

    • Cris@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      9 months ago

      As a largely non-technical linux enjoyer I have such a hard time understanding why people hate systemd so much. If I switched to a distro that uses another init system would my experience be better?

      Like I get that the complaint is partially the philosophy, but it sounds like you also have problems with it in practice and I just can’t really relate to that. I dunno, maybe I just wouldn’t notice if there are problems happening with how my init system is working 🤷

  • excitingburp@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    9 months ago

    I use NixOS on my personal machine and nixpkgs on my work Ubuntu (22.04 LTS). In the absence of NixOS I would not be using it: it somehow breaks all the file (open, save, etc.) windows, causing any app that tries to open one to crash (particularly annoying for browsers).

    Not to mention the wrapGL issue.

    It needs more polish on “genericlinux”. I did previously use it on MacOS, and it did make MacOS almost bearable - definitely years ahead of brew.

  • Adanisi@lemmy.zip
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    9 months ago

    I’m going to go against the grain and say that the Nix and Guix package managers are very good, but they really belong in their respective distros where they’re a core part of the system. That’d be Guix System for Guix and NixOS for Nix.

    They may have advantages for a foreign distro too, but they are lesser (Guix System can boot into a backup of the system before the last update, for example, but that advantage doesn’t exist on, say, Debian.

    Also, can we agree to not recommend these systems to new users for the time being? While they’re very powerful, they’re absolutely designed for power users, and until they’re more polished and they have fancy GUIs and stuff for installation and package management, I think it’d be best to keep recommending normal distros like Debian for now.

    • Shareni@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      9 months ago

      Guix System can boot into a backup of the system before the last update, for example, but that advantage doesn’t exist on, say, Debian.

      Yeah, why would I ever want to have bleeding edge userland packages on Debian? Nobody needs something like that or the option to rollback the entire update or pin specific versions of packages…

      Also, can we agree to not recommend these systems to new users for the time being?

      Did anyone do it in this thread? OP is literally just asking about a list of packages to home-manage. Beginners can most certainly handle it if they don’t need a gui to update their system.

      • Adanisi@lemmy.zip
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        9 months ago

        No, nobody did mention it, I was just making a side-point.

        I also said there are advantages to Guix/Nix on foreign distros.

  • Shareni@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    9 months ago
    1. As you can see from the state of this thread, people see nix or nixpkgs but read nixos. There’s no momentum from the community to push it as an extra package manager, while every thread is spammed with nixos.

    2. No gui integrations for casuals. For example Discover integrates flatpaks and snaps, but for nix you need to use the terminal.

    3. The documentation is abysmal. I spent days trying to figure out how to use nix as a declarative package manager before I accidentally came across home-manager. Even the manual leads you down the wrong path. A quick start guide with a few examples for home-manager and flakes, and a few basic commands, would’ve had me going in 5 minutes. That problem is made worse by the fact that almost all sources of info focus on nixos instead.

    • jayandp@sh.itjust.works
      link
      fedilink
      arrow-up
      0
      ·
      9 months ago

      Yeah, if it wasn’t for my niche needs and desires of using my SteamDeck without touching the system partition, I probably wouldn’t have messed with Nix because of how much of a confusing mess of modes and switches there are, and I’ve used terminal based package managers for years. It’s very far from the simple “it just works” of Flatpaks.

      • Shareni@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        9 months ago

        Imagine this: a quickstart script to install nix and home-manager, and generate an example home.nix and it’s flake. If those files included a few comments on basic usage and what commands to run in order to install and update everything, I legit wouldn’t have had to google anything.

        Literally: here’s a list, this is how you add packages to it, this is how you ensure everything on it is installed to the newest possible version, enjoy!

        It’s not click flatpak in a GUI level of simplicity, but it would’ve saved me days of frustration.

        • Fungah@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          9 months ago

          The more ive learned to code and the better I’ve become at solving my own problems on Linux, the more I’ve been absolutely fucking bewildered about how so many people can spend so much time and effort into projects they care deeply about and fail to include even the most basic of necessary instructions. Like “this one simple step is crucial and you can’t do fuck all else if you don’t do it”, kind of necessary

          I think they want people to use the things they built, right? And yet, here’you are in a Kafkaesque nightmare with no visible exit, seemingly alone as if you’re the only person to ever actually need the crucial but of instructions necessary to make this thing work.

          You wonder: am I just an idiot? Iss everything else in on something that I just don’t get? So you spend hours pissing into the wind as Google tantalizingly dangles tangential words at you, having become the internet equivalent of a bully snatching away the toy you brought for show and tell while swearing THIS is the last time, and you soldier onwards for hours, determined that you’re going to get this fucking thing working even though you know that for the sake of your sanity and our limited time on earth the better choice would be to give up. You make a point to leave a comment about your struggle on GitHub, just in case someone else finds themselves in your position one day, feeling less like an accomplished problem solver and more like someone who’s had to pop their own dislocated shoulder into place after dropping a piping hot pizza and falling on black I d. You’ve learned something, you’re more self reliant, this will be less serious in the futurre, but you can’t shake this weird feeling growing ever more insistent, a question you just can’t seem to answer: why? You’ll never know, and though it bothers you, you set to work trying to get this new image generation model to make you some anime women with comically oversized tits and worryingly unnaturally thin waists.