Lix is a modern, delicious implementation of the Nix package manager
lix.systems
lix.systems
Oh cool, I had "rewrite in Rust" on my bingo card.
Anyway this doesn't seem to be much more than a %s/nix/lix/g so far. I'm all for the right to rage-fork something, but you should be clear that it's not a new project.
https://git.lix.systems/lix-project/lix/commits/branch/main
You can see one of their most recent contributors is Eelco Dolstra.
> Oh cool, I had "rewrite in Rust" on my bingo card
You may also be curious about tvix, which is a greenfield version in Rust, not a fork (but still pretty feature-incomplete, iiuc).
I agree the ideas behind nix should spread to how we build software in general.
Guix has a usable Hurd implementation, which is a "non-Linux platform".
That is incorrect. They're merging Dolstra commits from the nix/NixOS projects. Dolstra has not commited directly to Lix.
One of the main Lix developers is delroth, a leftist activist that was banned from the NixOS Discourse for CoC violations.
Open letter to the NixOS foundation (50 comments) https://news.ycombinator.com/item?id=40107370
The dire state of NixOS's moderation culture (87 comments) https://news.ycombinator.com/item?id=40166912
---
Additionally, these r/NixOS submissions may be of interest:
Jon Ringer: "In case I'm unable to return, wish you all the best" (348 comments) https://old.reddit.com/r/NixOS/comments/1cd5fod/in_case_im_u...
Transparency about jonringer's suspension (153 comments) https://old.reddit.com/r/NixOS/comments/1ceeg8h/transparency...
Thoughts on Jon Ringer's temporary suspension (71 comments) https://old.reddit.com/r/NixOS/comments/1ceiz36/thoughts_on_...
Moderation no-go zones (55 comments; ongoing) https://old.reddit.com/r/NixOS/comments/1cfv8vo/moderation_n...
---
Finally, the RFC to improve the situation:
Notable threads, which may be relevant to explain why these forks were created include:
- https://nixpkgs.zulipchat.com/#narrow/stream/435937-constitu...
- https://nixpkgs.zulipchat.com/#narrow/stream/435724-governan...
- https://nixpkgs.zulipchat.com/#narrow/stream/435937-constitu...
I write typed systems on purpose during my day/hobby programming, and dynamic untyped experiences are just no fun for me personally. Nickel is far more interesting to me on my checklist of UX issues.
Kinda surprises me to see larger rewrites of various Nix systems that i've not had issue with. Am i missing something?
Forks tend to be for social reasons, rather than technical. e.g. NeoVim was forked out of frustration relating to a complicated changeset being rejected. Or OpenTofu over licensing issues.
There's an open letter (https://save-nix-together.org/) which vents concerns over governance, community moderation, and involvement with Anduril.
1. Documentation doesn't really explain how NixPkgs works and thus there is a lot of magic that is unintuitive for a new user.
2. The Nix language has a number of annoying gotchas. I always go through several rounds of syntax errors before several rounds of name errors before code can run.
3. Whence this definition? NixPkgs' extreme inversion of control approach makes it hard to guess by looking at code, and I haven't found how to set up good tooling.
4. Clickability. Sometimes you just want an official way to turn things on and off or choose defaults and there is no officially-supported GUI helper. This makes it hard to expect that people will start to use Nix who aren't basically functional programmers already. I don't think I could convince people to use it.
5. Efficiency. Long-ish build times for simple changes, too much memory use to run nixos-rebuild on a small computer.
nixpkgs
It's a monolithic source tree full of disorganized interdependent "derivations". It's nigh-impossible to find your bearings, and that's before you even think about the bazillion git branches and GitHub PRs.
I started this GitHub issue about 4 years ago: https://github.com/NixOS/nixpkgs/issues/93327
The more time goes by, the more convinced I am that all of the problems I have with Nix stem from how tightly integrated everything is in the nixpkgs source tree. I came to NixOS hoping for a package manager; but what I got is something else entirely. I find it incredibly ironic that a package manager whose core feature is isolated reproducible builds, could fail so hard at isolating packages from each other.
The nix language isn't the problem. The problem is the impenetrable novel that was written in it.
I think it's reasonable to say that the nixpkgs codebase is a behemoth that can be quite difficult to understand.
I think "nix and multiple versions of a package" is more nuanced. In that thread, several of the replies are saying "just use ...". As in, it's possible to vary the version of a package built. But, nixpkgs itself only has multiple versions of some package when that package is very popular (e.g. python, nodejs).
> The more time goes by, the more convinced I am that all of the problems I have with Nix stem from how tightly integrated everything is in the nixpkgs source tree. ... I find it incredibly ironic that a package manager whose core feature is isolated reproducible builds, could fail so hard at isolating packages from each other.
Having a repository with a large number of packages doesn't prevent you from writing Nix code outside of that repository.
Taking one large codebase and splitting it up into many codebases doesn't necessarily simplify things overall.
No, but it does define how (and where) I will write that code.
It's not uncommon for a package to need complex dependencies like udev. It's definitely necessary for nixpkgs to have opinionated decisions about how dependencies are structured, and what options/defaults are available and where. The problem isn't the quality of nixpkgs, or with any of its design decisions. The problem is that those design decisions are centralized and interdependent. That's the core issue that lead nixpkgs to be so poorly documented. It's the core issue that makes it incredibly challenging to create a sensible UI/UX for Nix and NixOS.
There are definitely benefits to a monolithic source tree. You can guarantee compatibility. You can have a clear place for communication about breaking changes and security updates. The thing is: you can get all of this without a monolithic source tree. Debian has been doing it for 30 years now. If anything, Nix should be able to do it better!
If the goal is to have a diverse set of package repositories, what better way to deliver them than a purely-functional declarative package manager? Nix is the one package manager that can handle totally incompatible packages, breaking changes, etc. all without breaking a sweat; yet at the same time keeps all its packages in a single monolithic source tree where none of that is allowed to be present. I see it as a missed opportunity.
I don't follow your rationale here.
e.g. many people write packages for their own "nix user repository". https://github.com/nix-community/NUR or there are examples of fairly sophisticated programs which declare packages outside of nixpkgs, such as helix or llamacpp.
helix: https://github.com/helix-editor/helix/blob/master/flake.nix
llama: https://github.com/ggerganov/llama.cpp/blob/master/flake.nix
> yet at the same time keeps all its packages in a single monolithic source tree where none of that is allowed to be present
In a programming language, a function can be called with different arguments.
With Nix, since the packages are the result of functions, you can use these package definitions with whatever incompatibilities you like. -- I'm not sure what use case you're thinking of that Nix can't handle.
I am not sophisticated enough in Nix to say what a good roadmap would be. But I feel that if I were sophisticated enough I would be trapped in the mindset and not able to see how it could be made easier to comprehend for new users and tools. But who knows? As of now it's a very interesting puzzle and, while I take a lot longer to accomplish what I can do elsewhere, I enjoy the little aha moments along the way.
Learning how to write Nix in order to get it to do what you want can be tough, yeah.
https://www.tweag.io/blog/2024-05-02-right-words-right-place...
In this recent post discussing efforts which have been made to improve documentation, the author reckons that one of the reasons Nixpkgs is difficult to understand is that Nix's powerful expressiveness allowed different people to take different approaches to solve similar problems. (As opposed to, having to rely on a common solution).
IMO.. difficulties with Nix fall into three broad categories: with Nix's idiosyncrasies, with the Nixpkgs codebase, or with the software you're trying to get Nix to run.
On most OSs, you might not need to have a deep understanding of what's going on in order to fix a problem. With Nix (& NixOS), running into problems probably requires a decent grasp of what you're doing, as well as what Nix is doing, and maybe how the Nixpkgs code is doing it.
> the use of a GUI tool to help
I think between "easy/hard to understand" and "easy/hard to model with a GUI", GUI helps a lot with things that are easy, but not so much with things that are difficult.
e.g. with VSCode, you can get a GUI to help you set options. Emacs also has a GUI to help you customize options; but you don't get a GUI that helps you write elisp.
e.g. I'm not sure that efforts like https://github.com/snowfallorg/nixos-conf-editor (formerly "snowflake") provide much more help than what the "search nixos options" provides https://search.nixos.org/options
I think most of the time people run into difficulty, a GUI isn't going to help. (In the same way that people don't ask for a GUI for Terraform).
The issue isn't really technical. It is a conflict over governance of nix, caused by multiple factors among them involvement of US military industry companies sponsoring conferences and a general dissatisfaction with leadership.
And in general it's good to have companies like Anduril. Democracy needs to be defended afterall - as Israel and Ukraine demonstrate.
It's not helpful to misrepresent these things to try and simplify a complicated situation.
Of course there is a sizable group of people who view all MIC companies as furthering war, which had objected to the sponsorship on moral grounds. But Anduril never was the only issue.
Can we please, for the love of Flying Spaghetti Monsters, stop calling everything new "modern" as if that word adds something to the quality of the product...
> Initial release June 15, 2003; 20 years ago
So... just by calendar time, no, nix probably isn't "modern". Though I do agree that calling a new thing modern isn't the most useful description; much better to say how it's better than the thing that came before it. The steel man is probably that "modern" is shorthand for "the underlying ecosystem/tools have shifted and the old thing suffers for not being able to adopt better ways of doing things, and this new thing will therefore be easier to work on / more robust / more feature-rich / less buggy / etc.", but I'd rather have that be articulated explicitly.
I thought the mention of Rust, and versioning the language itself (like what Rust does) covers this.
That, and, the last few NixCpp revisions apparently had some significant regressions.
Apparently, the switch to Meson was approved, and coded, ages ago, but Dolstra kept dragging his heels on it.
For a discussion on this, see https://github.com/KFearsoff/nix-drama-explained/issues/1
> Single-handedly blocking Meson, which has a passed RFC, for five years because he doesn’t know meson but knows his own build system
I don't know about exact timelines, but the letter is definitely wrong about this part.
It's a mixture of many things — some people are reasonable and just want sensible change, others are dangerous neurotics who need to go outside; both can end up, deliberately or not, using it as blackmail for control — but the moment the ball gets rolling it's pretty much impossible to stop.
I'd bail if a BDFL was an avowed Nazi but the bar for some just seems to be ridiculously low to the point where it's hard to imagine any (offline) social aptitude.
I'm not sure what gave me the impression but even from skimming the nix discourse the community's emergent personality did seem a bit snowflake-ish.
I've heard people make a kind of reverse-conway argument about Rust attracting (auth-) leftists, perhaps for another time...
"Benevolent Dictator For Life", most famously Mark Shuttleworth of Ubuntu if I recall.
Your two are the first who come to mind.
He even uses `sabdfl` as his handle.