NixOS is not reproducible

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 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.

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.

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.

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.

Read the page again.

What are they testing? 99% of what exactly?

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

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...

Thank you for your valuable comment.

> 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.

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

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.

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.

> 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.

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?

its

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.

>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.

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.

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.

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.

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.

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.

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.

    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.

I like the benefits too, but honestly these are all problems that I simply don't have and the "costs" in learning the new system in the face of the terrible docs and fragmented community are quite high.

I get a new computer once every few years and getting my usual programs installed is no more than a few hours work at most. I have 2 computers, one for work and one for private. Syncing installed programs is neither necessary nor particularly wanted; I don't want Steam on my laptop, nor do I want to run postgres on my private system. The only time an upgrade breaks stuff these days is when a kernel update needs the drivers to be recompiled. The command for that is stored in a file on my desktop and takes less than a minute to find, type in and wait until everything is fine again.

Regarding unwanted packages and "namespace pollution", every once in a while I install a program that is used once or twice and then forgotten about. This doesn't impede my normal workflow at all.

So the benefits of NixOS would be minimal for me, while the onboarding materials and documentation are pretty atrocious. The effort/reward ratio is just not there.