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.
So why should we use this instead of just saying lixmaballs and using nix/aux/nux/whatever other fork?
This is a fork or other form of replacement for nix as in the package manager. It does not replace NixOS, but can be used on NixOS and Darwin.
What makes this different from https://aux.computer? And with just ten people - such a small community, to maintain what, a parallel fork that will eventually be forced to accept patches from Nix repos? How does it protect against, let’s say, corporate decisions? Wouldn’t that seep into their project too? Not trying to demotivate them, but I fear that this could be the fate of their project.
There’s Guix, which is an official GNU project. If anyone is willing to learn a little bit of Guile Scheme - look, the language is great, the project isn’t contaminated with multiple scripts, project skeleton is much better, the modules are well written, so why not move over there? Sure, it’s still in the early version, so some stuff will be hard to work with, but personally, I think it’s a really nice hard-fork.
https://forum.aux.computer/t/the-future-of-nixcpp-lix/483
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.
Oh, so from what I see, Aux is responsible for working on the Aux tooling, which is basically Nix CLI fork. And Lix is the operating system itself, including infrastructure and clones of Nix essentials like Nixpkg, Hydra, etc? I could definitely see these folks collaborating with each other.
I think that’s backwards. Lix is a replacement for the nix package manager, while aux is a replacement for NixOS.
Aux looks like it will now use Lix for it’s package manager, instead of trying to make its own fork of nix.
Lix is the Nix CLI, Aux is everything else.
If anyone is willing to learn a little bit of Guile Scheme - look, the language is great, the project isn’t contaminated with multiple scripts, project skeleton is much better, the modules are well written, so why not move over there?
The language is great, but the ecosystem is on life support, and I don’t see it getting anywhere close to nix soon. I believe it’s especially crippled by being Linux only and forcing free software to the point you’re not allowed to even mention the non-free repo in the guix irc.
Random Devs and companies aren’t going to use it for their projects, and so there far less maintainers to solve issues like having a node version that’s not in maintenance for half a year and 4 major versions behind, or having automated npm package conversions.
Realistically it’s currently only useful for a few languages with abysmal PMs, most of which are lisps, and like Haskell.
Right now, I am struggling because of unemployment and job shortage in the tech-market, but I’m planning to share my own patches to essential software, like you’ve mentioned - probably within the end of this month. I think projects like Node, Ruby and Python need to be maintained well enough.
So if I have a chance to, I’ll probably work on either one of them, especially Node - that seems to be quite dated, and they’ve also skipped on v16, which hurts people who are still on it and don’t want to migrate immediately - because there’s no inferiors to pin to - while there’s multiple commits at least for 10, 14 and 18. Working on it would make Guix convincing as a third-party system package manager. I don’t know the state of Ruby or Python, but Zig seems to be in a decently good condition. Rust may be removed probably to avoid trademark violations, or they’ll probably create a fork and rename it.
About the FOSS extremism, it is not that bad, and I honestly like it the way they’ve maintained it - in a way, it is very similar to how Fedora separates their free and non-free repositories. This is not to say that there’s provisions for no non-free drivers - in fact, I personally use them for my Wi-Fi drivers to work correctly. Given the state of FLOSS-respecting Wi-Fi hardware, Wi-Fi 5 devices still don’t have their respective open-source drivers, so 6, 6E and 7 are still going to be unsupported for a long time with the libre kernel. For folks who want to setup a working system easily, nonguix ISOs are readily available, so that would probably be the best place for anyone to start at.
