NixOS is not reproducible

It's more like the whole upgrade is either successful, or it is not, and you are not left in an indeterminate state.

E.g. A depends on B. In a large update, B updates, something unrelated fails to install and the update fails, and now A doesn't run because it wasn't upgraded and the still installed old version of A depends on the no longer available previous version of B.

In NixOS, you either enter the new environment with all packages updated, or you don't. In the situation where you discover run-time - not install-time - errors, you can simply roll back to the previous set of packages. If the new packages cause a system crash, you can enter previous states from the bootloader.

Now none of this magically solves the software defects themselves. But it gives you a consistent system state that can be transactionally upgraded, or reentered at any time. And then you can raise the appropriate bug tickets.

Your system configuration is in a single file and the need to reconfigure different services in a particular order is gone.

Also your dependencies are all nicely pinned with Flakes. This makes importing arbitrary dependencies - open-source or proprietary - a breeze. This has removed any previous appetite we had for a monorepo, which was primarily to ease access to our other libraries.

It's all very nice, once you are over the not insubstantial learning curve that is.

You can update both of them, but Arch breaks then you have to figure out how to manually roll back the packages that broke it. If NixOS breaks, you reboot and select the previous generation and it's all reversed for you.

Updates are reversible and you have a list of every update you have ever tried to revert to.

Not quite the same but very useful for me. Sometimes small patches to programs have big usability wins. In nix you can still update automatically, it adds your patch, automatically downloads the programs needed to compile (but still can be garbage collected afterwards), compiles and done

Maybe not great for production but for personal use, since I guess this patch could break. But in exchange for a few times it breaks, I get automatic patched updated

(Except for emacs where takes 40 minutes to compile, but schedule updated for night)

My general experience with Arch is that the up-to-date-ness is a double-edged sword, and you some times hit new bugs or incompatabilities. If it happens in nix i can simply just revert - you can select which OS build version you want to boot at startup - and wait a few days.

And for my eGPU setup it also gives me a lot more confidence to tinker and reboot - the barrier for me to do so is a lot lower when I know i can simply boot an older build of my OS instead of having to whip out the arch installer USB and arch-chroot into my root drive to fix a bricked install that no longer boots.

Idk, in terms of installation difficulty NixOS is about the same as any other distro I've installed. The process is roughly: boot the LiveCD, verify disk config, run nixos-generate-config, add some basic packages to configuration.nix, run nixos-rebuild switch, and restart. The first time I did it, I didn't even understand the most basic aspects of the language.

I agree. If all you need is Linux on a bog standard machine and would rather spend your time doing something else than tinkering on your OS, nix is not for you. Life is short and there are lots of things to do - we all have different priorities.

I pressed C-c accidentally during the upgrade(wrong terminal) and it broke the entire system(had to manually change a few files rebuild initramfs to be able to boot). I would take the complexity of Nix without a thought.

You would think so, but after close to 10 years as a package maintainer it's clear to me that people don't know how make works when you do start doing anything else than `-j1`.

The gcc compiler also fails to reproduce binaries with the LTO streamer backend if you use certain macros. This has the consequence of making cgo binaries unreproducible.

As for Debian, we don't really know how many packages are reproducible. The CI they show is for fuzzing out issues, there are no system currently reproducing distributed packages.

Usually they aren't because of timestamps, processor features etc. After quite a bit of work Debian is now at 96% (or 93% when varying a few more things)

https://tests.reproducible-builds.org/debian/reproducible.ht...

Read the page again.

What are they testing? 99% of what exactly?

What does "path" mean, does it inflate the number?

Sure, but it won't successfully connect to a real device unless you somehow know to also set `programs.adb.enable = true`.

> Many packages are broken or unsupported on one OS or the other.

Report them. There's thousands of packages. Efforts like Zero Hydra Fails help, but there's still a lot to fix. If you raise an issue, it will be prioritised, because we'll know someone actually cares about it.

Keep in mind that's compared to a small percent of those packages available in other systems where you're on your own - not much different than on nixos with a broken package.

A good summary of the pain points I have with Nix. I was introduced to it recently at DayJob because one of the engineers I work with is a huge advocate for it.

I think there's a good use case for a small subset of Nix + direnv to manage system packages for repositories. That's essentially what we use at DayJob - but all it does is install system packages necessary for a containerized workflow. However, even that level of complexity, even if it's just a small flake.nix and .envrc, can be cumbersome to end users and we actively seek to hide away that complexity as much as possible because anyone not a Nix expert that is presented to work with Nix is entering a deep rabbit hole of complexity that is probably ultimately unrelated to the problem they are trying to solve.

Part of this I think is a branding and documentation issue with Nix. As a counterexample: I work with Argo a lot and they handle this sort of situation better. There is ArgoCD, Argo Workflows, Argo Events, and Argo Rollouts. They are all under the Argo umbrella that do distinctive things with clearly demarcated roles. Unlike Nix, I never get confused when I'm searching for ArgoCD related docs. I don't have to worry that I'm going to happen on Argo Rollouts related stuff and somehow not understand that Argo Rollouts is not the piece of Argo that I'm trying to use right now. The lines between each of the technologies are clearly demarcated and there is no confusion about the best way to do XYZ in each of them.

Not so with Nix - if I'm new to Nix and I'm looking up how to structure something in a flake, not only is there different setups/configs for a build tooling setup vs a package management setup, but even within a build tooling setup for instance there are probably 4-5 canonical different ways to configure things, all with a ton of decisions. Heck, if I'm new to Nix it is probably not even immediately obvious that I should be doing it with a flake instead of The Old Way, and I might even start implementing something using The Old Way before finding out buried in some Github issue from years ago that I'm Doing it Wrong

Thing that makes Nix amazing: It's infinitely customizable and welcomes that philosophy

Thing that prevents Nix from succeeding: It's infinitely customizable and welcomes that philosophy

TL;DR Nix favors configuration over convention, oftentimes to its detriment

Final footnote. I am writing this on a personal x86 machine managed with nix-darwin. It functions, but the amount of nondeterministic calls out to homebrew and kludges required for it to work essentially defeats the purpose of managing the machine declaratively in the first place. All of the following extremely popular softwares available in nixpkgs - 1Password, VSCode, Firefox, Docker Desktop - don't work out of the box on this machine and require either compiling the package yourself, jumping through some hoops to get it to work with MacOS code signing, or require you to just entirely ignore the Nix aspect and have Nix shell out to Homebrew. There are also quite a few binaries of packages that are simply unavailable in Nix.

Thank you for your valuable comment.

My writing was imprecise, I meant to communicate that it makes it possible to trust the contents of a derivation, given that you know that the hash is correct, which can be verified independently in the cases where the derivation is reproducible. Content addressability makes it easier to establish and verify trust across systems.

Given the degree to which the post is referenced, I do feel that it misses out by only describing input addressed derivations and not CA.

The issue has more to do with Nix poor onboarding, dreadful documentation and difficulty articulating its value proposition.

I personally think that the idea of Nix is fine but the execution is not there.

Look even Bazel which is built on fairly similar concepts but only targets built where it makes more sense and has a far better configuration language still struggle with adoption. It’s clear that Nix which wants to make immutable something people actually mostly never tinker will have to fight an uphill battle.

This is one of my main gripes with Nix. When something it's hard or unintuitive it's not Nix's fault, it's a skill issue on your part because you just "don't get it". It gets tiring quick.

Saying it's a skill issue just shows lack of imagination and ambition to make it better.

Not the parent, but you can have a base image + set of offline only setup scripts.

We know the beautiful theory. Show me something easy to onboard and use. I've learned no less than 500 separate tech pieces in my life, Nix and any others will have to make it worth my while in the first 10 minutes.

Yeah. I had been wanting what Nix does for years, but didn't know what Nix was until 2020? I always had this desire to create a shell script that would allow me to install a clean version of my system, but always got stuck at the part where you try to reverse your current OS state (config and packages) into a shell script. It's just too easy to do "apt-get install..." and then forget about your original intent of having a thing that produces your OS state. NixOS (and its relatives) is way more annoying about getting you to declare your config to get the OS state, which is perfect for a person like me. Being able to rollback packages (no, not individual files or groups of files, but discrete packages) is nice too.

> it's so easy to modify/remove/overwrite something

For some reason, out of the corner of my eye, I thought you were describing this as a feature of Nix because I missed the "mess up your install" part. It's easy to modify/remove/overwrite a package in Nix in a non-destructive way though. Of the few packages that have been broken for me, I feel empowered to pull them down and modify them to add needed functionality. And as I've gotten more confident, doing overlays or whatever they're called instead.

WIth Guix you can export these declarative files to docker coutainers, TGZ's ready to deploy everywhere (guix pack), vm's, build systems...

Did you try using „immutable“ infrastructure? I mean instead of updating existing container, you just spawn a new one with the new configuration, add it to the load balancer and decommission the old one?

> While building those images through Dockerfiles is pretty declarative [...]

There is nothing declarative about Dockerfiles, they are a list of imperative steps. Same for ansible playbooks, which are also often called declarative when they really aren't.

its

Our contributor graph is still growing exponentially and seems mostly unaffected. I'm not too scared about it. There is a lot of work to do though. Especially if we want to go mainstream

>on the technical front the switch to new Nix commands and flakes has left the documentation in a horrible mess

Did it ever happen? Last I've checked flakes were still experimental.

I think one of the issues with Nix's community is that they see using Nix as a goal on its own, not as a means to an end.

99.5% percent of people don't use Docker because they have a passion for writing dockerfiles, or because they find the ideas behind Docker elegant. They use it as a tool to help build other things. Meanwhile, the Nix community keeps pushing out these ideas about how Nix _works_ ("reproducible builds!", "lazy evaluation!") but they don't seem to particularly care about making Nix easy to use for the majority of the population out there who may want to use Nix as tool and don't care about its technical merits.

On top, I think most projects would benefit from having more functional programming advocates in them. Nix suffers from the opposite problem: it would benefit from having _less_ passionate FP people in it. Nix the language is pretty inscrutable for lots of people.

Guile and Nix are horrible languages with shitty syntax, the difference is that one is general purpose (Guile) and the other is a mix of yaml and json, while Guile (Lisp) abuses parentheses and you end up lost in spaghetti code, in Nix you end up not knowing what it's doing even if you're an "expert". They are bad solutions and not very reproducible, because in NixOS you have to change every so often the shitty variables they use to set garbage and in Guix you have to fight if you need non-free software with the NonGuix channel and other kind of nonsense.

I enjoyed thinking about the "how would I do it differently question", note would, as I have never actually tried it.

Maybe something like this? All packages are defined as a tuple (dependencies, dev dependencies, base image, command list, file list). Builds are done by loading the base image into a virtual machine, copying the dev dependencies into the vm, running the commands, and then pulling the listed files out into the host. All packages of a given OS edition would use the same base image, I suppose.

If a user wants to configure a package it will be done by putting a patch file in his configuration directory. The patch is applied to the built files.

I know it's not a proper measurement, but I can't remember the last time I missed something in AUR, but in my short time on NixOS I missed 2 apps and 1 app that disappeared in the NixOS channel upgrade.

NixOS has very limited usage, with few companies adopting it for critical or commercial tasks. It is more common in experimental niches.

One of the main issues with nixpkgs is that users have to rely on overlays for a package. This can lead to obscure errors because if something fails in the original package or a Nix module, it's hard to pinpoint the problem. Additionally, the overuse of links in the directory hierarchy further complicates things, giving the impression that NixOS is a patched and poorly designed structure.

As someone who has tried Nix, uses NixOS, and created my own modular configuration, I made optimizations and wrote some modules to scratch my own itch. I realized I was wasting time trying to make one tool configure other tools. That’s essentially what NixOS does through Nix. Why complicate a Linux system when I can just write bash scripts and automate my tasks without hassle? Sure, they might say it’s reproducible, but it really isn’t. Several packages in NixOS can fail because a developer redefined a variable; this then affects another part of the module and misconfigures the upstream package. So, you end up struggling with something that should be simple and straightforward to diagnose.

I'm a bit surprised to read it - for me I configured my system years ago and it just "keeps working" (I very rarely need to edit my configuration, for trying new programs I just spawn a nix-shell). Though I agree that first time doing anything has an additional cost - for example configuring my HP printer was maybe three lines of nix code, but I had to spend some time with forums to write them. On the other hand, I now just reuse these lines everywhere and don't have to think about it at all. For me that's a lot of time saved. It's entirely possible you're using OS differently than I do, and cost/benefit calculation is different for you.

With NixOS, you simply use Nix to configure a file that in turn configures other files that configure other packages, and you have to rely on the new path and variable definitions created by the maintainers of NixOS for upstream programs. So, you need to learn that if the program used A, in NixOS it's B -> A -> does the job (although it's not that simple). That's why, when you use NixOS, you feel like you're working twice as hard, while Arch Linux aims to be transparent by exposing the system structure without adding a ton of crap complexity like NixOS does.

    assuming that "build environment" includes more things than the author does (*it's* *not* *exactly* *a* *well-defined* *term*)

It is exactly my point. What is "build environment"? This definition is crucial for defining "reproducible builds" and we cannot handwave it away.

Randomly ordered lists (and randomized hashmaps) typically relay on PRNG. Seed of PRNG is part of environment. If you use hardware RNG, it is part of environment and should be "the same". Same with timestamps. If you download files from Internet, whole Internet is your environment (and by pre-condition it must be "the same"). Of course, it is unrealistic. So...

My point is: without very precise definition of "same build environment" all discussion of reproducible builds are almost meaningless.