Nix and NixOS, my pain points
I switched my personal dotfiles to nix recently, and the “poor documentation “ comment here really hits home.
Trying to learn /how to use/ nix was awful. I found lots of guides, almost always incomplete, and oftentimes directly contradicting each other. It took me weeks to get a working build and much of that time was anything but fun.
I like the outcome, and I’m glad I took the time now, but it was a slog that I don’t think I could really recommend to any of my peers.
It’s too bad guix went full hardcore FOSS and refuses to support macs, because they seem to have better docs and using a language that I can use outside of my package manager makes a lot more sense to me.
Slight misunderstanding in the blog post there.
> Archlinux is 78% reproducible on amd64 packages
> Debian is 95.7% reproducible on amd64 packages
This references the "fuzzing" infrastructure hosted by the Reproducible Builds project, and doesn't show "true" reproduction of binaries. It's designed to help us figure out where impurites occur in builds.
Proper package reproduction is much better in Arch because we don't have to care about all differences that can occur since our build systems are mostly static.
The true number hover around 86%-90%, which is better than the CI system.
https://reproducible.archlinux.org/
The main issues here is regressions in compilers, build tooling and leaky abstractions that needs to be found and patched. An example is how i spent a month tracking down a gcc bug that caused cgo builds to be unreproducible.
> When we use NixOS, and we want to use a package that is not available under NixOS / Nixpkgs (which happens quite often), we have only one choice: pack it into NixOS.
That's not the only way. It's definitely the easiest option, but you can also create a temporary fhs environment https://github.com/ElvishJerricco/nixpkgs/commit/05742c15d5a...
The real pain points are:
1) Abysmal contributor experience
2) Lack of typing in nix language and very limited debugging capabilities
3) Lack of interface concept in nix language
4) Lack of any markings on dependency graph edge
5) (3) and (4) makes impossible to have anything alike to gentoo's slots. Nix might be the only right way of doing slotting but it's effectively incapable of that.
I agree with all the points in this post.
And, I love NixOS. It's really special and very different than the other Linux I've used for 20 years.
I have been curious to try Guix at some point. Does anyone know if there is a good comparison write-up?
Also, can anyone speculate why the community has had such a hard time documenting this incredible technology? There are great posts like this from Xe: https://xeiaso.net/ but not generally getting started guides that are up to date. Why is this so hard to do? I mean, I'm not doing it because I personally feel like everything I do to get something working on Nix is a quasi-hack and not the standard and most up-to-date way to do it, so I'm hesitant to share. But, surely there are experts that like to write. Is this a problem with a simple technology solution (choose a better documentation tool)?
I've only used nix at home for 2 months but my biggest pain point is just dealing with testing out random GitHub projects where I need to install dependencies from some language's package manager.
There is usually a nix way, but I don't wanna build a custom nix script every time I want to test something out.
However I found that using distrobox solves this problem for me quite well. It's a way to easily create and enter another distro from the terminal while it inherits everything else from the host.
So whenever I want to try a random python project I just do it there and don't care about making a mess, while my host system is clean.
I'm sure there are better ways to do these things, but I can't seem to find answers that don't seem to involve a lot of work.
My very personal main pain point is documentation: Nix/NixOS do have some, but mostly or too little or deprecated.
Where is a proper Flake documentation? Where is a proper $newNixFeatureInVogueNow?
The second pain point is: Nix might sound nice to read and write as a language for Haskellers, but most people actually aren't haskellers...
The third is essentially the fists, more specified: target. If the target is desktop, or server, or HPC, or development docs should be shaped per target. Actually NixOS is designed mostly with dev desktops and infra target, but docs are not even for new devs, more something added aside just because it's part of the duty provide them in some form...
> The documentation of Nix and NixOS is rather poor. To understand how a service or an option works, it is very often necessary to read the source code (`.nix’ files) ...
I think this is also a plus point, for Guix and Nix, how easy you can check the parent file dependencies, which are the same language as the configuration you're creating, and are easy to understand
https://devenv.sh/ covers most of these points as none of the complaints mentioned are design flaws, but they are just something we have yet to reach.
My main problem is that Nix is based on one version of libc. If your system already has vendor-locked libraries based on a different version of libc, then it is quite difficult to get the rest of the system on that same version of libc.
The article mentions Guix several times but never once mentions as a pain point that Nix lacks a well-founded programming language.
Now I may be a total outlier here but it seems to me that while getting the fundamental concepts right is a good thing, having powerful means of combining them becomes more important in the long run.
Does that not speak in Guix' favour?
Been using nixos for about a month. It took me about a week to really start to grok Nix a tiny bit, I had to spend a lot of time on the forums asking questions or searching for questions because the discoverability of the documentation is low when you don't know the lingo.
I'm loving it now though, I have 3 computers running it and a flake that I push to github. I can push changes to my flake and have all my systems reflect the changed with a quick nixos-rebuild. Also being able to roll back is invaluable.
I reformatted one of my systems the other day and it only took about an hour to have my whole system in the exact same state it was before with all my tooling and files.
Regarding the second point, ("it's not enough to have the same /etc/nixos/configuration.nix file, because of environment variables, other files, and commit revisions of repos used"), this is one thing which Nix Flakes solves.
With nix flakes, all the Nix sources you use must be checked into source control, and impurities like environment variables can't be used (by default).
You actually can search repos in their entirety on github now, think it’s a beta-feature you can enable or use. In other words, congrats, they’ve already indexed your entire codebase because they needed to for copilot.