NixOS is not reproducible

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.

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.

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)

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?

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

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

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.

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

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.

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.