[Aaronmacaron]

I use nix on my laptop because it's absolutely brilliant when it works. To me it's a fascinating technology. Being able to easily use different versions of some tool in two different projects, declaratively defining my dotfiles using home manager or quickly trying out some software using nix-shell -p is almost magical to me.

Eventhough I've used nix for years now, I have no deep understanding of nix and I'm a very curious person who always tries to understand how stuff actually works. Nix makes me feel really dumb. It makes me feel like when I was twelve and I "programmed" by cluelessly stitching together code examples from online tutorials. I don't really understand what's going on outside of the really common use cases for nix.

I read the entire nix docs but I think it's the kind of documentation that's only useful if you already kind of get what's going on. It feels like you have to gather the knowledge from various random blogs. Last time I checked there surprisingly was not a single book which covers nix. I feel like a comprehensive book which teaches nix from the ground up and explains all the different ways of using nix would really help me and I would purchase such a book without hesitation if it existed.

[teekert]

This is very well worded, it's how I feel... We may need some 3blue1brown type animated video about the internals of Nix(OS)...

Edit, I put in the request if you feel like upvoting: [0]

[0] https://www.reddit.com/r/3Blue1Brown/comments/133zoxd/commen...

[whatwhaaaaat]

When you say run it on your laptop do you mean as the base operating system or on something else through a vm?

[Aaronmacaron]

I used to run NixOS on my main computer for a few months until I encountered some situation that I couldn't resolve using my nix skills. I think I needed to run some software that wasn't on nixpkgs.

Nowadays, I just use nix (the package manager) on top of PopOS.

[throwup238]

This has always been the death of any attempt I make at using NixOS. The first time I tried over a decade ago I think it was VMWare Workstation, then CLion or some other Jetbrains package a few years later - things that aren't particularly esoteric to linux users. Completely opposite the experience that I've had with ArchLinux.

Maybe I should give it another shot if ChatGPT can provide better guidance than reading a dozen blog posts, 11 of which are out of date.

[tripdout]

Checking nixpkgs now, it looks like the entire suite of Jetbrains tools are well-supported (except for the newest one, Fleet, since it looks like the people who tried ran into some issues they didn't know how to solve), as well as VMWare Workstation.

Coming from Arch, almost every package I want is on NixOS. The couple I can remember that weren't there are Android Studio for Platform (I packaged it myself following the derivation for the regular Android Studio), Obsidian.nvim (which was packaged a week or two after I mentioned it), and there's been a couple smaller tools that I can't remember.

[throwup238]

According to the Github issue [1] they added VMWare Workstation in 2022 so the ship has long sailed. Last time I tried (2020 I think) I also couldn't get Xilinx installed and that was just the first in a long list of tools. Even now it requires an FHS workaround.

NixOS is great if you never tread from the happy path but it seems most of my work requires tools way off the happy path.

[1] https://github.com/NixOS/nixpkgs/issues/56814

[rowanG077]

TBH every linux disto will sometimes leave the happy path. The difference between nixos and basically all other distros is that all other distros at least do most thing somewhat in the same way. So even an install for example for Ubuntu can relatively easily be translated to Arch. But that's unfortunately not the case with nixos. It's just too different. So once you are off the happy path you sometimes need real skill in nix to even do some, at first glance, simple things.

[nani8ot]

In my experience ChatGPT learns from those 11 out of date blog posts, and merges it all into a totally wrong mess. At least I didn't have much luck with solving nix problems with chatgpt.

[__MatrixMan__]

I'd say that chatgpt can solve half of the nix problems that I bother confront it with. Half of them it solves it on the first go, for the remainder I have to go back and forth with it for 4x longer than it would have taken me to solve it on my own.

Typically these are troubleshooting a flake for a project. I think it works because flakes are nice and self contained: you can paste the whole flake. I find it does significantly worse when trying to help with contributions to nixpkgs, presumably because the context is not bite sized.

[tkz1312]

nixpkgs is (and has been for many years now) by far the largest and most up to date package collection of any linux distribution (including the air).

ref: https://repology.org/

[rowanG077]

This is misleading. Because nixpkgs repackages all of npm, pip, hackage etc. packages. Stuff that on other distros are managed by their respective tools seperate from the distro packaging. Still nixpkgs is pretty vast.

[mbrumlow]

Not misleading. Othet distros do similar or even the same. For example many if not all python modules are separate packages.

Even so. Removing the packages you talk about Nix is still largest. So again not misleading.

[mikepurvis]

For other people in this situation of running Nix the package manager on a non-Nix OS, a nascent Numtide project you may be interested in is system-manager:

https://discourse.nixos.org/t/github-numtide-system-manager-...

The idea is to provide some of the NixOS whole-system management niceties (especially controlling systemd units) but on non-NixOS systems like Ubuntu, in a way that behaves more like puppet/chef/ansible rather than competing with the native package manager.

[teekert]

I ran into this situation when I needed Conda (for work).. But I may have found a solution: Distrobox (Conda expects certain folders in certain places and NixOS folders are all random strings.)

[thomastjeffery]

I can't speak for them, but I can tell you I'm running NixOS directly on my own laptop (and desktop and server).

[ParetoOptimal]

Same. Also recently added a steam deck to the fleet with https://jovian-experiments.github.io/Jovian-NixOS/

[rustybolt]

Thanks for saying this, I felt the same every time I tried Nix.

[chriswarbo]

> Eventhough I've used nix for years now, I have no deep understanding of nix and I'm a very curious person who always tries to understand how stuff actually works. Nix makes me feel really dumb. It makes me feel like when I was twelve and I "programmed" by cluelessly stitching together code examples from online tutorials. I don't really understand what's going on outside of the really common use cases for nix.

Nix is fundamentally just a build system. It's based around `.drv` files ("derivations", which are like a Makefile rule). These are text files containing a system type (e.g. x86_64-linux), the path to an executable, a list of string arguments to give it and a key/value map of strings to use as environment variables. Those basically form a declarative version of an `exec` syscall.

Each .drv file also specifies some paths as its "outputs", and may optionally specify some "inputs": an input is either a raw file path, or a pair of [path to another .drv file, name of output].

The basic operation in Nix is a "build", like `nix-build /nix/store/...foo.drv`, which tells Nix to produce that derivation's output paths. Nix does this as follows:

- Look in that .drv file to find its output paths. If they already exist on the filesystem, print the paths and halt.

- If some of the output paths don't exist, query any configured binary caches to see if they have those paths. If so: download them, print the paths and halt.

- If some outputs don't exist, and aren't in any configured cache, then Nix will need to execute the derivation's command...

- First Nix checks that all the inputs referenced as raw files exist; if not, it exits with an error.

- Next Nix checks whether all of the inputs which reference other .drv files exist. Any which don't exist will first be built by following these steps (and so on, recursively).

- Once all of the "inputs" exist, Nix will run the derivation's executable (maybe in a sandbox, but that's not important)

- When the executable has finished, Nix will check whether all of its output paths now exist. If not, it prints an error message and exits. If they do exist, it prints the paths and halts.

That's the core idea of what Nix is doing: it's a way to specify individual command invocations, create dependencies between commands using the paths of their outputs, and allowing parts of such dependency trees to be skipped by downloading the desired outputs directly from a cache instead. It's like Make, but spread across multiple files.

The "magic trick" that makes Nix special is that the path of every .drv file must contain a hash of its contents. Since .drv files can reference each other by their paths, these hashes form a Merkle tree which completely specifies the entire dependency graph of each derivation (similar to how a git commit includes the commit ID of its parents, and hence specifies its entire history).

This is a remarkably powerful and general approach to specifying the contents of files/folders. The downside is that it's tedious to write all of these .drv files by hand (especially calculating the hashes), so Nix comes with a simple scripting language to generate them. We can use the -E argument of nix-build to specify a "Nix expression", which will generate a .drv file to build (the `derivation` function will default to specifying a single output called "out"):

  $ nix-build -E 'derivation { name = "myName"; system = "aarch64-linux"; builder = "/bin/sh"; args = [ "-c" "echo foo 1>&2 && echo bar > $out" ]; }'
  this derivation will be built:
    /nix/store/irxpvx4cs8jmyysrd5hhqjx66blg4b8k-myName.drv
  building '/nix/store/irxpvx4cs8jmyysrd5hhqjx66blg4b8k-myName.drv'...
  foo
  /nix/store/mdaw1ajdd6zp8dnbcbxvay4lw9dssaqp-myName
  $ cat /nix/store/mdaw1ajdd6zp8dnbcbxvay4lw9dssaqp-myName
  bar
  $ cat /nix/store/irxpvx4cs8jmyysrd5hhqjx66blg4b8k-myName.drv
  Derive([("out","/nix/store/mdaw1ajdd6zp8dnbcbxvay4lw9dssaqp-myName","","")],[],[],"aarch64-linux","/bin/sh",["-c","echo foo 1>&2 && echo bar > $out"],[("builder","/bin/sh"),("name","myName"),("out","/nix/store/mdaw1ajdd6zp8dnbcbxvay4lw9dssaqp-myName"),("system","aarch64-linux")])

Other projects, like Nixpkgs, build on top of this foundation, by defining elaborate libraries of Nix expressions to generate .drv files for the build commands of thousands of different software projects. (Note that Nixpkgs doesn't use `/bin/sh` like I did; it specifies the URL and SHA256 of a few "bootstrap binaries" for Bash, GCC, etc. and those are used to define everything else)