Why We're Moving on from Nix

A lot of work about packaging specifics reads like inside baseball because it is. Most people manage to avoid getting into the specifics of packaging because it’s stuff that mostly gets in the way of the problem they’re trying to solve. But for blessed few packaging is either critical to the problem or is the problem itself. If you never had to learn the inside baseball terminology, it is likely that packaging is not critical to problems that you solve, and I say that without judgment. If you need to get into Nix, you will. There are lots of reasonable ways to manage personal infrastructure that don’t involve Nix. For the problem you describe, I’m not even sure Nix is a preferable solution unless you already use it.

That said, I agree with the original comment. I’m willing to believe that they had these problems and that moving away from Nix was the right decision, but there is little detail in the explanation. They’ve been pretty closed users of Nix to my knowledge, building proprietary tools on top of it without contributing back significantly, and it feels like orgs such as repl.it are contributing back more actively, but this may be a marketing difference as well.

I think you may be overthinking things. In brief;

Nix is two things: a functional programming language called Nix, and a package manager written in C++ that compiles and installs packages written with Nix expressions. Nix the language itself, and it's implementation.

Nixpkgs is a repository of Nix packages. It also contains NixOS, which is also just a bunch of Nix.

NixOS is a Linux-based operating system built on Nix. It is configured using NixOS modules, a configuration system of sorts built on top of the Nix programming language. A NixOS system is literally a single big Nix package built from NixOS modules that depends on a bunch of other packages.

If this still seems too complicated it would probably be better to just dive in and mess with it so you can physically see what's going on.

> current problem is taking a homelab server into “production” and all I really want is a way to write down a state I want the services on it to be in, have that in a git repo and be able to regenerate this server after loosing it (in a first step without any data backup). I’m still, after 2 months (wall clock, call it maybe 3 days actually getting into this project), not sure if that’s a thing Nix tries to cover! (I think it does, but..)

Yes that does sound like something NixOS can cover. Obviously, you will still need backups for your mutable data (databases, files, etc.), but if you are able to encapsulate the entire setup of a server into a NixOS config you can indeed throw a machine out the window and have a new one set up and booting the exact same services in minutes.

This is pretty much the original thing that drew me into NixOS, especially because at the time I was highly interested in qemu GPU passthrough setups and I really liked how with Nix all of the complicated setup bits could be expressed in a single file, with about 20 lines of Nix, all accounted for and version controlled. A lot better than just hoping you remember to keep things documented.

I won't lie, learning NixOS and using it for a real machine setup was very painful for me at first. I struggled with many things over time. Still, I really think because the scope of things these projects do is huge it's really easy to overcomplicate things. All of the explosive scope of Nix comes from relatively simple primitives applied in large systems.

I really don't want to encourage people to suffer with Nix if they feel like it's just too convoluted and hard to work with. I am not trying to convey that Nix is simple or easy on the whole. I was only ever trying to explain why I felt the issues raised by this post were confusing to me, not trying to tell people that Nix is generally easy. I think a lot of replies genuinely continue to misunderstand this, but the point of saying that it's easy to do that in Nixpkgs is not to dunk on people who struggle with Nix, it's to say that it's not clear why Nixpacks would struggle with these particular issues. You can literally just split the /nix/store paths into separate OCI layers. There is no obvious reason why this strategy can't be used, and the blog post doesn't go into the background behind it. I bet there actually is background, it's just left unsaid.

I think that's kind of sad. There are a lot of good technologies that require some investment to understand them and a lot of worse is better approaches that end in a mayhem that is ultimately a terrible work environment.

For a while it seemed like investment would win but now I think we will have massive tombs of poorly written stuff that can only be worked around with even more LLM generated solutions. It is like the software bloat problem we've had recently but on steroids.

The problem is that "should" is papered over a system not designed that way from the start, and in a heterogeneous world which operates in its own way, not Nix's way.

So it's just an eternal battle between the real world and the fantasy Nix world, built on an army of thousands of volunteers writing up .nix files and contributing packages, and trying to tame the beast of Unix complexity.

Except most of us are just trying to get things done and now I work in a shop where I can't even run a development setup with my favoured IDE, or just "cargo run" my package, because Nix has been placed in the middle of everything.

Clearly in a sincere effort to tame complexity, but in the process creating a whole new world of it, with a lot of normative lifestyle assumptions.

To me... in my experience... Nix promises a lot more than it can realistically deliver, comes with a totalizing world view, and in practice ends up making life more complicated unless you completely and totally buy into its way of doing everything, and are willing to leave many of your old tools and practices behind.

The right way to tame complexity is not that much of a hassle. This is why virtualization and containers have been so successful. Make the OS immutable by converting into a nested Russian doll of OSes with specific instances being mutable but also disposable.

It’s ugly in its own way but it has the virtue of not exchanging one ugly complexity tax (OS rot and manual admin) with another (a complicated “manager” that wants to get in the way).