I feel you (like many people) got burned by the steep learning curve. Empirically some pretty high powered companies use nix successfully. It's of course always difficult to know the counterfactual (would they have been fine with ubuntu) but the power to get SBOMs, patch a dependencies deep in the dependency stack, roll back entire server installs etc. really helps these people scale.

nixpkgs is also the largest and most up to date package set (followed by arch) so there's clearly something in the technology that allows a loosely organised group of people to scale to that level.

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 agree with everything you just said. I really like the idea behind NixOS - write a config and apply it, all containerised, but I never had a chance to try it until recently when I got a new laptop at work. But after 3 months I updated my Ansible playbook, added things I needed for work, went back to Arch and couldn't be happier. With NixOS it felt like there was an extra maintenance fee for doing regular Linux things. It just wasn't worth it for me.

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.

If NixOS works well for you, that's great! But from my perspective, the whole NixOS model adds unnecessary complexity and makes you learn ways to do things that don’t really translate to other Linux systems. The directory structure in NixOS is different and doesn't follow the FHS (Filesystem Hierarchy Standard) and the system uses a bunch of symbolic links that feel like "hacks" to keep some kind of compatibility with the FHS.

For example, if you want NixOS to recognize paths like /bin or /usr/bin in your scripts, you have to enable services.envfs.enable in your configuration.nix or in a .nix module. If something goes wrong in NixOS, you might run into multiple issues because the problem could be within NixOS, the underlying system, nixpkgs, upstream packages, or a mix of all these factors.

Sure, it might save you time in some situations, but when a problem pops up, you'll find yourself in a tricky spot since you’ll have to dig through all the layers of the system to find the root cause. On top of that, you’ll have to sift through the options and the documentation, which can often be pretty confusing.

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.

Can you recommend tools you prefer/use for achieving reproducibility/determinism?

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.

You're describing nixpkgs with an external builder in a VM. That's exactly what it would do. And that tuple is what nixpkgs packages really are (with some macros on top, but you're not forced to use them).

My impression of configuration in nix is that a lot of configuration that in any other distro would be handled by changing some /etc/file is instead done in a completely separate way by editing some nix file. So that's one user-visible way it differs from what I mentioned of using a patch for the /etc/file.

Some simple example I found just now:

https://unix.stackexchange.com/questions/489509/how-do-i-mod...

There are patches which need to live in the repo by default anyway, so that's already supported, just not as random /etc location. https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/aw...

Guix, as NixOS, exists when an scientific experiment should have reproducible builds in every stage.

On config files, Guile is not that difficult.

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 agree. I really think Nix would be a lot more approachable if it didn't have such a weird language. The fact that it is dynamically typed and declarative also means it is completely undiscoverable.

Those things (parentheses and free software) don't make Guix a bad solution. It's just not for you.

If Guix were an optimal solution, many companies would be using it, but that's not happening. It's just a niche experiment. And parentheses don't seem so bad when the code is one line, when tens or hundreds of lines won't be so fun.

HPC under Inria. Giving how young Guix is, lots of companies rely on it.

>Tens or hundreds

You never wrote a single line or Scheme or Common Lisp and it shows.

No one writes thousands of nested lines down. They modularize it into functions because Lisp was basically made literally for that.

Get some Emacs modules and code, such as Mastodon.el. Look at the source code. Far easier to understand than any C or C++ codebase, not to mention Rust.

> you end up not knowing what it's doing even if you're an "expert"

Oh you've tried Haskell then?

Well, with Haskell you know what it is oriented towards and you know what to expect, but Nix wants to control everything in the system by adding unnecessary complexity to the simple and making the complex even more complex.

Sounds like you want MacOS.

No, I like it practical and without such stupid design choices.

If only there were alternatives...

Losing parentheses is not an issue for any Lisp programmer.

I remind you this is HN, guess on what was built on.

>non-free software

Non-free software should be the issue, not Guix itself.

Not free software by default is NOT reproducible. Period. Useless for science.

>Non-free software should be the issue, not Guix itself

Not the parent, but this approach from Guix maintainers is the reason why it's not an OS I would consider. I use free software almost exclusively, but I appreciate that nixos doesn't try to play the moral police and will let me easily run any non-free software I want. I don't like it, but sometimes using a non free tool is the easiest way to get the job done, and life is too short to get stuck on software idealism (at least for me).

You are free to use non-free software on Guix System, it's just not in the main channel or officially recommended. You'd likely figure it out fast enough if you wanted.

The reproducibility crisis in science has nothing to do with the supporting software itself not being reproducible.

Both are needed. Look what happened with Excel in genomics. Once you can control every point of the pipeline, you are set. That means a discrete set of versions, dependencies and being able to rebuild and fix every point of software if bugs show up.

> Not free software by default is NOT reproducible.

Changing a licence on some software doesn't change the compilation. The licence is completely orthogonal to whether software is reproducible or not.

How do I recompile binary blobs?

You don't. So the blob that is packaged and installed is identical to the one in the repository. Hence, it has no reproducibility issue.

Non-free does not mean compiled. Here's a non-free script which I grant you the right to view but not execute or copy:

    echo foobar

Reproducible, compiled and free are all orthogonal.

Isn't most non-free stuff installed in /opt or in the user homedir these days anyway?