Today Lix announced their public beta. I recommend that everyone go check it out, this is a very big moment for the Nix world!
Lix is a modern, delicious implementation of the Nix package manager, focused on correctness, usability, and growth – and committed to doing right by its community
The announcement resolves one of my last fears for Aux: development on Nix itself. It is no secret that the number of people knowledgeable about the project and are willing to work on this CPP codebase is small. You have probably seen me mention multiple times by now that @sig_cli needs all of the help that we can get. Lix resolves this entirely with a trusted team of experts. This means that Aux is now able to remove Nix development from our priorities and can instead collaborate with Lix moving forward.
However, Lix does not include a package set, operating system, or any other part of the Nix ecosystem. These parts are still up to us to make happen! The discussions happening in every SIG and Committee right now are still useful. Even discussion in @sig_cli is helpful as contributors can work together with Lix’s team and community to resolve issues that Aux runs into (and it may still be useful to have an aux wrapper command for convenience).
This is an extremely exciting moment and we should all be appreciative of the work that the Lix team has done and congratulate them on their launch. No doubt we will all be working together in the future!
I read the Lix announcement and I’m incredibly excited for it! reading their “Why Lix?” page made me feel like I was seeing daylight for the first time after the open letter — this is exactly what I was hoping for from a Nix evaluator fork. I’m just one member of the @sig_cli, but I’m very excited for a potential near future where we can work closely with the Lix team to combine Lix and auxpkgs into a truly community-run ecosystem and operating system.
I am massively in support of working alongside the Lix team here - many of our discussions so far have been around everything but CppNix, and having another team to work alongside on that part would be absolutely huge for us. A few names on that team are people that I’ve personally known (and worked on projects with, in some cases) for a while, and I have full trust in them to build a welcoming community and functioning governance structure around their tools.
I’m super excited to collaborating with the Lix team going forward!
also “auxolixl” just popped into my mind. is this anything
I also wanna throw in the ring us migrating the main repo to maybe Lix’ forgejo instance while still accepting PRs on github? I think thisnmayake sense governance wise to stay independent but still express a close tie to Lix.
(…also, haven’t really gotten around to work on Aux yet due to mental issues, is there a tldr on how to get invited to the gh org somewhere? :p)
If you wanna pick up some stuff, drop a link to your GH profile in this thread and we can get you invited. Also take a look at some of the Special Interest Groups and Committees for areas to start working in - we can add you to the respective teams too if you’d like.
I’d just like to interject for a moment. What you’re refering to as Lix, is in fact, Aux/Lix, or as I’ve recently taken to calling it, Lix plus Aux. Lix is not an operating system unto itself, but rather another free component of a fully functioning Aux system made useful by the auxpkgs repository, shell utilities and vital system components comprising a fully declarative OS as defined by POSIX.
several computer users run a modified version of the Aux system every day, without realizing it. Through a peculiar turn of events, the version of Aux which is widely used today is often called Lix, and many of its users are not aware that it is basically the Aux system, developed by the Auxolotl Project.
There really is a Lix, and these people are using it, but it is just a part of the system they use. Lix is the language: the program in the system that parses your .nix configuration files. The language is an essential part of a declarative operating system, but useless by itself; it can only function in the context of a complete operating system. Lix is normally used in combination with the Aux operating system: the whole system is basically Aux with Lix added, or Aux/Lix. All the so-called Lix distributions are really distributions of Aux/Lix!
As for Lix in general, I like that they want to start replacing parts of nix with Rust.
Normally, I’d propose tvix which is a pure rust implementation if I’m correct, however they are very very old-school IMO. Mailinglists and IRC with a Matrix bridge, issues are hosted on some self-developed thing with no holistic connection between everything.
Collaborating with Lix would probably be much easier and attractive to newcomers.
I see no practical downside in adopting Lix for Aux, and also it just… Feels right, to support an effort that aligns with our goals but also fits like a missing puzzle piece for us.
Also, Lesbian-colored Lix + Nonbinary colored Aux would be an interesting combination if we adopt that proposed color scheme and not the other ones.
I just updated my machines to use Lix (plus aux pkgs!) and it seems to work pretty great!
Personally, I’m all for adopting Lix as our main Nix implementation, the team behind it seems highly competent and the values between the two projects align almost exactly, it seems.
Also they have plans to slowly sprinkle in Rust into it, which honestly sounds very exciting!
Among all the good vibes the Auxlotl project gives me I was also low key deeply worried about NixCpp maintenance. This not only solves that problem but also solves it with fashion.
I mean, I do believe both project share a majority if not all major goals and foundational ideas. Having interproject collaboration would be great and could lead to a nice relationship so we should leave that door open.
Formal politics aside I think we would greatly benefit from adopting it, we should open a discussion for it.
Loving the latest developments in the space so far.
