Nowadays, I just use nix (the package manager) on top of PopOS.
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.
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.
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.
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.
Even so. Removing the packages you talk about Nix is still largest. So again not misleading.
Most Haskell packages are not included in the AUR and haskellPackages alone makes up over 17,000 packages on nixpkgs compared to ~1,100 on AUR - subtract just that and Arch pulls ahead. Nixpkgs also has almost twice as many Python packages because python310Packages is separate from python311Packages.
I bet there are lots of other non-language examples too: a quick search found emacsPackages which contains six thousand packages.
You have to prove that it has less of the software available on other distros. Even if you could find a billion small packages that represents only a single package in every distro this is not evidence or a proof that support your claim.
Simply put, you need to show where nix does not have a larger number of packages that are available on other distros.
Given that nix is mostly automated and pulls from the same root sources as every other distro you are going to be hard pressed to find a significant number of cases where nix lacks a package.
Not misleading.
I think nixpkgs is probably so much larger for two reasons:
1. running unpackaged software on nixos is painful. 2. it’s very easy to contribute to nixpkgs (standard github pr to a monorepo).
It makes little sense if you compare it like this. It would be stupid for any other package repo to include those package since they already exist. The only reason nixpkgs needs to do it is for purity reasons.
The metric that matters is "how many packages can I easily install on this distro". And nixpkgs most certainly is not in the lead here.
If you want a non-misleading comparison you have to remove all these packages, which are actually managed by a different package manager every. from nixpkgs and put that into repology.
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.
Edit, I put in the request if you feel like upvoting: [0]
[0] https://www.reddit.com/r/3Blue1Brown/comments/133zoxd/commen...
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")])
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.