Nix alternatives and spinoffs [LWN.net]

By Daroc Alden
July 11, 2024

Since the disagreements that led to Eelco Dolstra stepping down from the NixOS Foundation board, there have been a number of projects forked from or inspired by Nix that have stepped up to compete with it. Two months on, some of these projects are now well-established enough to look at what they have to offer and how they compare to each other. Overall, users have a number of good options to choose from, whether they're seeking a compatible replacement for Nix (the configuration language and package manager) or NixOS (the Linux distribution), or something that takes the same ideas in a different direction.

To establish a baseline for the comparison, the Nix project is still operative and working on business as usual. NixOS 24.05 was released on-schedule at the end of May, and 24.11 will follow later this year. Despite that, the project has seen more contributors leave — and continuing issues with upheaval in the community. While the project seems unlikely to go away, it has definitely suffered a blow.

Auxolotl

Auxolotl (Aux) is a "proactive friendly fork of the Nix ecosystem" (according to the description on its wiki). Auxolotl was forked by Jake Hamilton, but has already seen many other contributors come onboard. Since the code bases have not had much time to diverge, Auxolotl is still compatible with Nix, and a computer running one can seamlessly install packages from the other.

While the documentation advises that "Auxolotl may make technical improvements to Nix and NixOS in the future", the main focus of the project is not on changing the fundamental design of NixOS, but on continuing development with a radically different community structure. In an introductory post, Hamilton describes Auxolotl's approach to governance:

Authority is given from a central Steering Committee that establishes the direction of the project and delegates that authority to responsible parties. The structures in the Aux governance model are:

Committees: Bodies managing logistics for the project unrelated to technical implementation

Special Interest Groups: Teams dedicated to specific parts of the Aux ecosystem

Working Groups: Teams formed for Special Interest Groups to collaborate with one another

Since Auxolotl is still so new, special interest groups (SIGs) are currently being set up just by asking volunteers to get involved. In the future, as the project grows, committees (including the Steering Committee) and SIGs will be filled using elections. Currently, the Steering Committee is comprised of Hamilton, Isabel Roses, and Skyler Grey as a boot group to get the project off the ground. The Steering Committee is supposed to leave technical decisions up to the SIGs. Of course, the NixOS Foundation board was also supposed to leave technical decisions up to NixOS's various contributors. As with any open-source project, managing the community can be just as hard or harder than working on the code, and it remains to be seen how well Auxolotl will adapt.

Still, Auxolotl has gained a lot of interest for such a young project, and has already made good progress on establishing infrastructure and promoting community discussion. The project provides a template for anyone wishing to install a new Auxolotl system, or migrate their existing NixOS system. Auxolotl is also compatible with another Nix spinoff: Lix.

Lix

Lix is a fork of Nix (the package manager), rather than NixOS (the operating system), with the goal of having a healthier community and a focus on backward compatibility. As a fork, Lix remains compatible with existing package definitions and configurations. Lix can even be used transparently as the Nix implementation for a NixOS or Auxolotl system. Recent versions of Nix have included some backward-incompatible changes that nixpkgs, NixOS's repository of package definitions, have not yet caught up with. So, in order to maintain compatibility with the package definitions that users are actually using, Lix is forked from an earlier version of the Nix code base.

While Lix is getting started, the project is being led by a core team that votes on technical topics as they arise. The project's final governance structure is not decided yet, but is likely to end up being more distributed and community-led than Nix, with the contributors soundly rejecting the idea of having a benevolent dictator for life.

Lix has incorporated some changes that have been lagging in the upstream implementation. The project has already switched to using Meson as a build system (instead of plain Make) — a change that Dolstra had been blocking for some time. Other improvements listed in the first release announcement include performance improvements, improved error messages, improvements to the interactive user interface, and bug fixes. According to Lix's web site, "Lix intends to be an evolving language – a robust language versioning system will allow the language to grow and evolve without sacrificing backwards-compatibility or correctness."

That isn't the only large-scale change that Lix is planning to make, however. The project also intends to start phasing in the use of Rust — not as a from-scratch rewrite, but as an incremental addition to the existing C++ code base. Whether this means that Lix will be able to share any code with Tvix — the existing from-scratch rewrite of Nix — remains to be seen, but the project's FAQ explicitly welcomes collaboration with other projects: "We welcome anyone who wants to develop for both Lix and another implementation – including CppNix and Tvix, and our open-source implementation absolutely allows any developer to integrate our code into any license-compatible project."

Tvix

Tvix is a project by The Virus Lounge (TVL) to rewrite Nix in Rust that started in 2021. TVL is a loose association of people who work together to develop open-source software. Any from-scratch rewrite is a huge undertaking, so it's not surprising that Tvix is not yet compatible with Nix. But the project has been making progress. The most recent development update explains how the project is using nixpkgs as a giant compatibility test to identify and prioritize places that do not yet match the behavior of Nix.

Tvix is largely able to evaluate the core language, and is now working on all the other components that go into a package manager. Recently, it added a server that can share Nix packages over the same interface as the original Nix implementation. So although it is not yet usable as a drop-in replacement, it seems likely that the additional interest from and collaboration with other implementations could make it a viable alternative sooner rather than later. Plus, using Rust does have some ancillary benefits, such as allowing Tvix to compile to WebAssembly.

Tangram and Brioche

There are also some projects that seek to build on the ideas that Nix popularized, without being direct successors. Tangram and Brioche are both hybrid build systems/package managers that use TypeScript as a configuration language. Although based on separate code bases, Brioche is being developed by Kyle Lacy, who used to work for Tangram Inc., the company behind Tangram — so the projects share some architectural similarities.

Like Nix, these package managers use a Turing-complete configuration language, sandboxing, and content-addressed storage to specify dependencies exactly and share them between computers. On top of that, they add some interesting features. For example, Brioche has built in support for producing packed executables that bundle all their dependencies in the application itself. However, the main appeal of both projects is definitely the idea of using a general-purpose language to specify a build.

Guix

Of course, Tangram and Brioche are not the only projects to take inspiration from Nix. They aren't even the projects that most closely embrace the idea of coupling Nix's model to a more general-purpose language. Guix is a package manager of the same kind that uses Scheme as its configuration language.

Guix has not been much affected by the drama in the Nix community, so the comparison that LWN published earlier this year remains valid. Guix was a smaller project than Nix, but with contributors leaving Nix for Auxolotl, Lix, and other alternatives, the comparison might be more favorable now. In any case, Guix remains a stable operating system with an approach to package management similar to NixOS's.

Conclusion

Despite the number of maintainers choosing to move on to other projects, Nix and NixOS are still receiving plenty of attention. With companies like Determinate Systems, Anduril, and many others backing it, the project seems likely to remain around for some time. But users who seek an alternative have several options.

For users who want a full-fledged operating system with a relatively long history of stability, Guix remains a good option — although the project's stance of only packaging and supporting open-source software could be troublesome for people who still depend on some proprietary software. Users who want to keep their existing NixOS configurations and make a lateral move into a community with many of the same contributors but a different governance structure may find Auxolotl suits their needs.

Users who want to evaluate Nix code (as part of an Auxolotl deployment or otherwise) but don't want to continue relying on the original Nix implementation can switch to using Lix, and expect a backward-compatible experience. Users with niche needs (such as WebAssembly support), or who feel strongly about memory-safety, could become involved in the development of Tvix.

And users who want the benefits of Nix as a build system, including precise dependency management and better caching, but who don't have a vested interest in the Nix ecosystem might try Brioche, Tangram, or one of the other systems that has embraced ideas from Nix.

to post comments

No compilation, please?

Posted Jul 11, 2024 19:43 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (18 responses)

Are there any Nix-like projects that use binary artifacts only, instead of recompiling the world? I love the idea of Nix, but recompilation just kills me. And no, object caches are not the solution.

I guess Flatpaks are probably the closest we can get to this?

No compilation, please?

Posted Jul 11, 2024 20:03 UTC (Thu) by atnot (guest, #124910) [Link] (1 responses)

I've used NixOS and Nix for a few years now and the only time it's compiled anything from source was when I enabled MGLRU in the kconfig to see if it would help on a low memory device. As long as you don't start messing with build options, it may as well be binary.

No compilation, please?

Posted Jul 11, 2024 20:19 UTC (Thu) by jhe (guest, #164815) [Link]

My experience was the opposite - the amount of local recompilation and hosages due to full disks (back then with btrfs...) was what made me drop nix in 2017. This was around the glibc 2.26 update which apparently required a full rebuild of the world.

No compilation, please?

Posted Jul 11, 2024 20:32 UTC (Thu) by ericproberts (guest, #139553) [Link] (1 responses)

My reading of the nix philosophy pretty emphatically points to binary caches as the solution. You could use fetchurl and friends, but then you lose the connection between build instructions result. A nixpkgs of binary packages seems like having a cache but with extra steps.

Maybe there's something I'm missing. Is there a specific problem you're trying to solve?

No compilation, please?

Posted Jul 11, 2024 20:36 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I want replicable environments, but I'm fine with not getting a fully flexible specification. Something like Debian snaphsots, but more flexible.

No compilation, please?

Posted Jul 12, 2024 8:55 UTC (Fri) by spacefrogg (subscriber, #119608) [Link] (12 responses)

I use NixOS as a daily driver since 2015 and there is no such thing as recompile the World under normal usage. Whoever told you this was setting you up. If, however, you come frome Gentoo-like systems, you have to accept that you can neither touch the kernel nor libc or GCC build flags, otherwise, you DO end up in endless recompile the World scenarios. That is true for any other distribution platform in existence, though. So, I am not sure where you are coming from. Recompilation just does not happen massively, only small things here and there, on a released nixpkgs channel.

No compilation, please?

Posted Jul 12, 2024 11:18 UTC (Fri) by ms (subscriber, #41272) [Link]

Yep, I'm also daily-driver of NixOS on several machines. I have a few custom bits and pieces, e.g. a tweak to the configuration of sqlite-as-used-in-audacity so whenever either of those change, I get a recompile _of just those bits_. I have once or twice (in a few years) triggered a kernel recompile, but even that didn't result in a rebuild-the-world. I would certainly not dare touch things like libc though.

No compilation, please?

Posted Jul 12, 2024 14:23 UTC (Fri) by intelfx (subscriber, #130118) [Link] (10 responses)

> you have to accept that you can neither touch the kernel nor libc or GCC build flags, otherwise, you DO end up in endless recompile the World scenarios. That is true for any other distribution platform in existence, though.

Well, that is just blatantly untrue. In any other distribution platform in existence, changing kernel configuration, or patching the libc, or even changing gcc build flags will never result in rebuilding the world — so long as you maintain the ABI of the component in question, which is pretty much always.

The only distribution that has a problem with it is NixOS (and its derivatives/equivalents). And *that* is the problem with Nix{,OS}.

No compilation, please?

Posted Jul 12, 2024 15:39 UTC (Fri) by atai (subscriber, #10977) [Link] (6 responses)

> The only distribution that has a problem with it is NixOS (and its derivatives/equivalents). And *that* is the problem with Nix{,OS}.

Really? Gentoo should have the same "problem" and unrelated to NixOS or derivatives

No compilation, please?

Posted Jul 12, 2024 18:03 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

It is not a problem for Gentoo, because "I want to compile everything locally" is Gentoo's entire raison d'être (i.e. it's not a bug, it's a feature). This is not the case for NixOS, because Nix is all about containerization and isolation, which does not (in principle) require compiling things locally.

No compilation, please?

Posted Jul 12, 2024 18:17 UTC (Fri) by intelfx (subscriber, #130118) [Link] (4 responses)

> Really? Gentoo should have the same "problem" and unrelated to NixOS or derivatives

No, because Gentoo does not require rebuilding anything **as a consequence** of patching the libc or changing toolchain build flags.

As NYKevin says, when Gentoo _does_ require rebuilding things, it's because you deliberately chose to use a source-first distribution. Or you might choose to use Gentoo's binary cache, which is (unlike Nix's) not predicated on never touching or altering the dependencies of packages involved. So it's a feature (that you might or might not choose to use), not a problem.

Nix, on the other hand, will force you to rebuild the world exactly **as a consequence** of changing some definitions at the bottom of the dependency graph, even if it is not technically necessary.

No compilation, please?

Posted Jul 12, 2024 19:10 UTC (Fri) by NightMonkey (subscriber, #23051) [Link] (3 responses)

+1. I'll just add: I've been a satisfied Gentoo user for the last 18 years. Early on, yes, there was a good amount of world rebuilding needed. For production, this meant investing in creating temporary systems to handle the build and storage of binaries was worth it.

But, the times I've had to rebuild world all at once in the last 5 years has been zero. The work to create centralized binary caches at Gentoo HQ and making binary-only versions of some of the most brittle builds (major web browsers, office suites, multimedia players, etc.) has taken the pain out of everyday upgrades.

And, if you have a farm of dozens, hundreds or thousands of machines, you can easily create the infrastructure to reduce the pain of recompiling to a temporary build farm that creates a local binary cache, and distribute the built binaries to the fleet. Modern CPUs and ramdisks handle this task well.

Gentoo is a *metadistribtution*. This means that it can be used to create *your own distribution*. It has the tools to enable you to do so. With the care and attention, it can reward you greatly.

Let's not slag Gentoo reflexively when we want to just complain about inefficiency generally.

Cheers!

No compilation, please?

Posted Jul 12, 2024 19:59 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

> But, the times I've had to rebuild world all at once in the last 5 years has been zero. The work to create centralized binary caches at Gentoo HQ and making binary-only versions of some of the most brittle builds (major web browsers, office suites, multimedia players, etc.) has taken the pain out of everyday upgrades.

You haven't upgraded your profile recently?

Mind you, that was the upgrade from 2017 to 2024, and it was also the upgrade where you were sort-of forced to merged-usr, and it was sort-of the upgrade where you felt pushed forward to get the distro into the third decade.

I think it was only my second profile upgrade in however many years (Istr the one before was 2014), and this upgrade the instructions did say "finish with 'emerge -e @world' " ie "rebuild everything", But how long have I been using gentoo? And this is the first time.

Cheers,
Wol

No compilation, please?

Posted Jul 12, 2024 21:45 UTC (Fri) by NightMonkey (subscriber, #23051) [Link] (1 responses)

Ah, yes, you're right, Wol - I did have to do that migration-related rebuild of world. I was able to skip the merged-usr, tho, with the "split-usr" profiles, as I'm using OpenRC. So, not zero. Once, across all my local systems. I do have distcc and other optimizations set up so it makes doing so less painful in terms of time.

No compilation, please?

Posted Jul 12, 2024 22:26 UTC (Fri) by Wol (subscriber, #4433) [Link]

I didn't go to merged-usr, because both my systems are reasonably recent, and systemd. So they were merged-usr from the start.

I went systemd for the same reason I chose gentoo - it's a deliberate choice of a learning curve. My old OpenRC system was just that - too old. I used to have distcc, but I just haven't got round to setting my new systems up the way I would like. I want to share the build directories over the network, and then I'd uprade the faster system (I build binary packages as a matter of course), and then upgrade the slower system with the "use packages if they're there" option.

Cheers,
Wol

No compilation, please?

Posted Jul 12, 2024 21:07 UTC (Fri) by bauermann (subscriber, #37575) [Link] (1 responses)

> so long as you maintain the ABI of the component in question, which is pretty much always.

The aim of Nix and its derivatives/equivalents is to do away with the "pretty much" part of the sentence, because "pretty much" isn't reliable enough. It's very hard to guarantee that an ABI hasn't been broken, and subtle changes in the input can affect a package build in unexpected ways.

The principle of Nix/Guix/etc is that the inputs to a package build are painstakingly tracked so that if anything changes in any of the inputs (or the inputs' inputs, etc down to the last turtle) then a new build is made. Which is why changes deep in the dependency graph trickle down to everything. Eelco Dolstra's PhD thesis has the details. It's an interesting read.

This is the cornerstone of the functional package manager's reproducibility and rollback guarantees.

Guix has the graft mechanism to replace a dependency without propagating the changes to the dependant packages, assuming that the ABI is the same. It's used to apply security fixes without requiring world rebuilds or downloads of updated cached binaries for everything. But it's a practical concession that goes against the underlying model.

No compilation, please?

Posted Jul 12, 2024 22:33 UTC (Fri) by Wol (subscriber, #4433) [Link]

> The principle of Nix/Guix/etc is that the inputs to a package build are painstakingly tracked so that if anything changes in any of the inputs (or the inputs' inputs, etc down to the last turtle) then a new build is made. Which is why changes deep in the dependency graph trickle down to everything. Eelco Dolstra's PhD thesis has the details. It's an interesting read.

I haven't looked ... but that is a plentiful source of gentoo bugs I suspect. I'm sure I've been bitten by missed dependencies in the ebuilds, I've seen bug reports ... and of course, they're a right pain to actually track down because they're obscure and don't bite that many people.

Cheers,
Wol

No compilation, please?

Posted Jul 13, 2024 9:05 UTC (Sat) by JanSoundhouse (subscriber, #112627) [Link]

It all comes down on how dependencies are managed. Your build system has to be pretty sophisticated in order to avoid rebuilding the world when some as basic as the libc changes (c makes it pretty hard to determine what actually changes). With something like bazel its possible to avoid the unnecessary rebuilds completely. But thats because every dependency has to be declared - on the consumer and provider side and its actually enforced by building everything in isolation.
For example if a flag for the libc is changed, the depending packages must be able to infer whether that change needs a rebuild on their end. You cannot rely on make to do it for you, as it only looks a file dates and not the actual content.
For a human it might be possible to tell that a certain flag added or removed will result in a compatible binary, but if you want your builds to be always correct (and you dont have a perfect declaration of _all_ dependcies) rebuilding is the safest bet.

No compilation, please?

Posted Jul 12, 2024 13:42 UTC (Fri) by RaitoBezarius (guest, #106052) [Link]

FWIW, cache.nixos.org contains already more than 700TB of cached packages. Unfortunately, the number of possibilities and combinations using all of nixpkgs necessarily contains more than 700TB of cached packages (across revisions), there's a balance to strike. The philosophy is to aim for a "95 % of the time, you will get a cache hit".

Managing the community

Posted Jul 14, 2024 14:56 UTC (Sun) by marcH (subscriber, #57642) [Link] (3 responses)

> As with any open-source project, managing the community can be just as hard or harder than working on the code, ...

BTW this is not specific to open-source (or to software for that matter).

Open-source has this "let's focus on the code" spirit which is great and does help in many ways. But it's not enough to turn humans into robots.

Managing the community

Posted Jul 14, 2024 15:36 UTC (Sun) by Wol (subscriber, #4433) [Link]

> > As with any open-source project, managing the community can be just as hard or harder than working on the code, ...

> BTW this is not specific to open-source (or to software for that matter).

Sadly that's only too true.

Working with minimum wage (near enough) pickers and drivers, you wonder why management can't see the reason they can't get staff is they treat them like replaceable robots, not human beings. And then management wonder we can't hit our targets, when we haven't got the staff ...

Cheers,
Wol

Managing the community

Posted Jul 18, 2024 2:22 UTC (Thu) by milesrout (subscriber, #126894) [Link] (1 responses)

If only this were true. It used to have this focus. The whole reason this post exists is that some people have declared war on "just focus on the code". Note that on the last LWN post on this topic, someone was throwing around terms like 'fascist'.

Managing the community

Posted Jul 22, 2024 14:34 UTC (Mon) by marcH (subscriber, #57642) [Link]

There has to be a balance somewhere between pretending that code is written by robots in a socioeconomic vacuum and spending more time discussing diversity and CoC than programming code.

In practice the pendulum will keep swinging back and forth as it usually does?

No matter what happens, open-source has an amazing evolutionary and longevity trick up its sleeve: forking. Better have too much of it than none at all. The latter has extremely often meant: extinction.