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.

  • @j4k3English
    2•10 months ago

    I can respect all of that.

    That’s your ignorance’s fault, not any distro’s. If you can’t be bothered to plug in your own keys, you limit yourself to the set of distros that are indirectly officially approved by M$.

    Harsh. I tried signing my own keys. I replaced them in the bootloader, but when I do the final step to lock them down, the TPM chip flushes the new keys and reissues fresh keys again. The only guide I have found for Keytool is on Gentoo. I love Gentoo’s documentation for a lot of things, but it assumes a high level of competence, and I haven’t seen anything visually showing exactly what to do and how Keytool works in practice. I don’t feel very confident taking that step for the first time on a machine I must keep working.

    Indeed there are many times I “need my hand held” in order to take my first steps into a subject. I need an intellectually-intuitive foundation that is stable and I can build upon.

    You say there is no security issue with a user owned directory in root, but intuitively, that shakes a lot of my understanding that is not grounded in formal CS as you likely seem to be. Like I don’t understand:

    • why a user owned directory in root is needed
    • What it means for NIX in reference to configuration files, dot files, and my mental model of mess that belongs in /home/$user. While unfounded, I immediately worry root will somehow get cluttered with junk too. It is probably wrong, but I think of $user being largely sandboxed in /home/$user/
    • I don’t know what the SELinux context is for NIX, but I only have a limited grasp of SELinux from hacking around on Android to add things like busybox, and I know it is permissive but enabled in Fedora.
    • I question how anything placed directly in the root directory of another distro will impact future updates from the packagers of the distro.
    • Isn’t this against the Unix framework to place something directly in root?

    I think those are all of the intuitive thoughts and questions that resonated in my mind when I saw /nix and noticed its user context.

    When I am working on some other project, I don’t want my OS to force me into some peripheral rabbit hole in some large gap within my understanding just to run an update for a package I need, like what I experienced with pacman. My negative experiences with Arch many years ago makes me default skeptical. While I understand that NIX and NIXOS are different, I still associate them when it comes to developing trust.

    Last thing worth mentioning since I have been thinking about it. I was motivated to try NIX, enough to install it, in order to try a preconfigured version of KoboldCpp, as I mentioned. However, I recall it was posted on a website somewhere and was described for a WSL NIX Flake. I was curious to try it because I have had trouble with Nvidia with a mainline kernel and kobold. I thought maybe the flake was just described for WSL and I could easily sort out a Linux version, but that didn’t happen. The flake was not in any native repo, and altering it to run in Linux did not feel very approachable in documentation as far as a first time experience with NIX. I don’t think kobold is compatible with a DKMS built Nvidia module anyways so that stopped my effort.

    • Atemu
      2•10 months ago

      I tried signing my own keys. I replaced them in the bootloader, but when I do the final step to lock them down, the TPM chip flushes the new keys and reissues fresh keys again

      It may just be that the firmware of your particular board is buggy to the point of being broken.

      You could try updating it but sometimes it’s futile and the firmware is just the biggest pile of crap.

      Indeed there are many times I “need my hand held” in order to take my first steps into a subject. I need an intellectually-intuitive foundation that is stable and I can build upon.

      Absolutely reasonable expectation. I wish we had that.

      why a user owned directory in root is needed

      I initially glossed over the fact that you said “user-owned” here. It still shouldn’t affect anything because nothing uses /nix for anything security-critical at any point but it’d certainly be smelly.

      User-owned /nix is only the case in single-user installs which I believe have been deprecated for a while and certainly aren’t the way to go anymore.

      These days the preferred and default method is a multi-user install where /nix is owned by root there and exclusively managed by the privileged nix-daemon.

      What it means for NIX in reference to configuration files, dot files, and my mental model of mess that belongs in /home/$user. While unfounded, I immediately worry root will somehow get cluttered with junk too. It is probably wrong, but I think of $user being largely sandboxed in /home/$user/

      Nix (the package manager) itself does have some limited local state (cache, current profile link) that is put into the appropriate XDG user dirs. It will never touch anything outside of those specific state dirs, the TMPDIR and /nix.

      Nix is designed to be fully contained in /nix. This property enables you to even wipe their entire root on every boot under NixOS.

      Apps installed via Nix behave as they always do w.r.t. cluttering directories. openssh will still create and manage its ~/.ssh directory for instance, just like on other distros. If you ran some daemon that you installed via Nix with sufficient privileges, it may try to create its state directory in /var or whatever; just like the same daemon from any other distro’s package would.

      That is all to say: Nix does not do anything special here. Its packages largely behave the same as they do on any other distro and that behaviour includes state directory cluttering behaviour at runtime.

      I don’t know what the SELinux context is for NIX, but I only have a limited grasp of SELinux from hacking around on Android to add things like busybox, and I know it is permissive but enabled in Fedora.

      No SELinux support whatsoever.
      There is somewhat explicit non-support even as Nix’ model of files and directories does not include xattrs; you cannot produce a Nix store path that has special xattrs for SELinux purposes.
      Metadata like permissions, dates and owner information are all normalised in the Nix store. The only permitted metadata apart from the file name is whether regular files can be executed.

      If your system uses SELinux, you must add an explicit exception for the Nix store. (Installers may do that automatically these days, I haven’t kept up with that.)

      question how anything placed directly in the root directory of another distro will impact future updates from the packagers of the distro.

      Other distros simply do not touch /nix; it’s not their domain.

      FHS distros control FHS directories such as /usr or /bin depending on what individual packages contain but no sane package of an FHS distro will try to control /nix/store/hugehash-whatever/.

      Isn’t this against the Unix framework to place something directly in root?

      Nix does many things that go against original design principles of Unix and that’s a good thing. It’s not the 70s anymore and some aspects of Unix have not aged well.

      https://economicsfromthetopdown.com/2024/02/17/nixing-technological-lock-in/

      trouble with Nvidia with a mainline kernel and kobold.

      Using Nix for applications that have userspace driver dependencies on non-NixOS requires a hack unfortunately: https://github.com/nix-community/nixGL

      • @j4k3English
        2•10 months ago

        Thanks for taking the time to answer all of my questions. I’m much more likely to try NIX again now.