Skip Navigation
Linux @lemmy.ml
lemmyreader @lemmy.ml

Lix - a new fork of Nix

lix.systems Lix

Lix is an independent variant of the Nix package manager, developed by a team of open-source volunteers, and maintained by and for a passionate community of users.

https://chaos.social/@ktemkin/112392108881500298

https://chaos.social/@ktemkin/112392108893774195

This isn’t just a fork of Nix—this is the work of a team of 10+ people near-constantly since early February. (Technically, us too — but our task is really just enabling others.)

Some serious work has gone into ensuring it improves on upstream without having the regressions that have plagued them last three major versions!

And, since this will matter to some — it’s not a project of the NixOS foundation, but an independent organization that takes its responsibility to its community seriously.

33 comments

  • i really want to like Nix.

    gave it a shot a few years ago, but i felt like documentation and community support wasn’t really there yet. this was long before Nix surpassed Arch in terms of number of available packages. now people still complain about documentation, especially of the Nix language. i see a lot of package authors using it, and that kind of tempts me to start using at least the package manager. but a lot of packages don’t. the allure of GitOpsing my entire OS is very tempting, but then there’s been these rumors (now confirmed) of new forks, while Guix splintered off much earlier. for something that’s ostensibly supposed to be the most stable OS, that makes me nervous. it also seems to have some nontrivial overhead—building packages, retaining old packages, etc.

    the pitch for Nix is really appealing, but with so much uncertainty it’s hard to pull the trigger on migrating anything. heck, if i could pull off some PoCs, i think my enterprise job might consider adopting it, but it’s a hard recommend for me today as it was 5 years ago.

    • The problem with Nix and its forks, imho, is that it takes a lot of work, patience, time and the willingness to learn yet another complex workflow with all of its shortcomings, bits and quirks to transition from something tried, tested and stable to something very volatile with no guaranteed widespread adoption.

      The whole leadership drama and the resulting forks, which may or may not want to achieve feature parity or spin off into their own thing, certainly doesn't make the investment seem more attractive, either.

      I, too, like the concept of Nix very, very much. But apart from some experimental VMs, I'm not touching it on anything resembling a production environment until it looks to like it's here to stay (predictable).

  • Another one?

    • This is a fork of the evaluator/language implementation/daemon/builder/whatever you want to call it. The other one (Auxolotl) is a fork of Nixpkgs, the repository of build scripts and all the NixOS misc pieces.

      Or put into other terms, this is a fork of APT/RPM as well as their associated builder tools, while Aux is a fork of Debian/Fedora/whatever. The Nix evaluator is a much more complex piece of software than most other package managers so it does benefit from having a dedicated team working on it.

  • (as a side note, Lix (and Aux and whatever else) is going to need an easy, clear, DOCUMENTED (and preferably automated) migration path)

  • At least, for me, Nix was never attractive, and it should be by all means, the features it provides. I still see this as an alternative, where I'm more than satisfied with my bash scripts and git repos, syncthing backups to rebuild the whole system.

    And, on the second part, this schism that happened in Nix is the same recipie that happened in other projects. I just find it funny.

33 comments