Nix alternatives and spinoffs

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.