I find this to be a particularly interesting point in the context of the Nix alternatives/forks that are popping up.
Maybe this is a good argument to not build something almost like Nix that always has to “keep up” to stay relevant, and instead build something new that fixes problems Nix can’t because of its legacy?
On the other hand, I would be very curious to see a branch-off from Nix2.3 and see what other paths (other than flakes) could’ve been chosen.
well, guix has existed for a while, but i guess those of us still here are here in no small part due to nix’s killer app nixpkgs. that kind of network effect makes it hard to make radical changes, making it less of a surprise we’ve seen forks pop up.
but yeah, the moving target part may indeed make things harder for them.
I think the “AIP” is not relevant here.
His main point is that you shouldn’t put yourself in a position where you’re forced to compete if you don’t have to.
I don’t think any fork made themselves in that position.
Those forks have different basic fundamental values, here, we are done. This is completely different from the original implementation.
If we want to look at technical details, well, from my understanding of a Nix maintenance team meeting, for example, the Lix team has more resources than the Nix maintenance team for the time being. We are already carving our own path anyway.
For Aux, I cannot speak for them but I was under the understanding they were looking into different models of nixpkgs, so… Same.
This is mostly about alternatives, but with many forks, the best hope that forks can have is that the current upstream becomes the “alternative”, by virtue of the fork(s) taking most of the contributors and users with them. Of course in practice, it’s usually not likely in the long run: robust adoption really requires the community to unanimously agree that such a step is the best way forward. Doesn’t mean it never happens, though; I suspect it will happen with Redis.
Forks can be driven by many things. Some forks are not destined to outlive their parent project, but still have large impact, like the io.js fork of Node.
It does seem like forking Nixpkgs seems like it may not be desired, at this point. Forking Nix, maybe more interesting. Forking communities, personally I definitely feel like this is valuable, because the official Nix venues, GitHub, Discourse, Matrix, necessarily need to cater to the widest group of people, and need to serve the purpose of discussing development and providing support. If you view breadth of discussion scope on one axis and breadth of participants on another, you want them to be balanced inversely to each-other to some degree. I’m curious to see if things naturally tend toward that direction as things shake out further.
Nixpkgs is still immensely valuable, though, so I hope that after some reshuffling, more concerns can be addressed and work can move forward. I think that if anyone hits on a much better way to handle something like Nixpkgs, they will “win out” in the end. Personally, rather than split the monorepo, I’d like to see what would happen with a more distributed structure of maintainership. I suppose we’ll probably see eventually.
My understanding is that the central problem of nix is the opposite at the moment — it is stuck in a self-inconsistent status quo and can’t get out of it.
It’s useful to think about Kotlin here, which, I think, both succeeded thanks to general stagnation of Java and also kicked it with sufficient force that Java has pattern matching this days 
When it works it is because there is no dominant implementation and there is a spec everyone takes seriously that no implementation controls. GCC vs Clang vs MSVC is a great example.
Forks are a good solution to social problems, but they are bad way to get diverse implementations, unless that code-base is so small that it’s possible to rewrite everything. Lix could succeed in replacing every last line of C++ with Rust, which would be fantastic, or or it could not, in which case we will have all the costs of duplicative efforts without all (just some) the benefits of very different implementations with different assumption in the code.
Those forks have different basic fundamental values
I don’t think that is true at all, and also it doesn’t have anything to do with the blog post.
- A safe community for developers of all backgrounds.
Lix is developed by a diverse group of users – and accordingly is committed to providing a space that’s safe for users and developers typically underrepresented in technical projects. We take moderation seriously, and are committed to preventing bad actors from driving out marginalized groups.
Nothing against Nix per se, this is beyond the control of Nix (well it’s more complicated but I will admit that to make a stronger argument), but this is currently not a thing.
More generally, the project cannot agree on fundamental values, see Zulip.
Can you articulate how you believe this is not “true at all” ?
BTW, the blog post mention problems about competitions, I’m just saying that those forks are mostly incomparable because some folks does not want to work in the other project for reasons beyond technical matters, thus, it’s a useful argument to substantiate that indeed, there’s no competition, those forks do not live in the same social space for the time being. That could change! And I would love to see this change, then we would be back in the conditions of that blog post and we could discuss about AIP.
I don’t want to derail a conversation on the blog post which, again, doesn’t go into the social matters of why people fork at all, so I will keep this diversion brief.
I agree that is true, the most fundamental thing, and I am also hopeful it can change.
I am quite confident “social space” is a matter of values but of comradery. People want to work with people that they can relate to — dare I say for volunteer projects people want to work with their friends, or become friends with their volunteer coworkers. Diversity and representation is important not because the above doesn’t matter or should matter less, but because it does, and we don’t want some contributors to feel more lonely/isolated than others, especially new or potential new contributors.
Talking about values falsely implies this a matter of the head, not the heart. Quoting “A safe community for developers of all backgrounds” needlessly implies that current CppNix developers don’t care — or worse. Nothing in the above depends on what, we the current Nix team, care about or think, and everything on simply who we are. That’s OK! We don’t need to pretend otherwise because it feels like a cleaner morality tale or stronger, more mobilizing story.
Please don’t read subtext into this, because there isn’t any: it is my understanding that the Nix team disagrees internally on whether large-scale behaviour changes like lazy-trees should be acceptable to merge, and has decided to merge them in spite of this disagreement.
The Lix team has internal agreement about values, which notably include that we should make our foundations stabler before we can do any serious feature work. This is at odds with the demonstrated value of the Nix team prioritizing features.
I would strongly recommend considering the impact rather than the intent. We don’t think that the CppNix developers are malicious, but their actions have had significant negative impact to the point that a large number of external contributors have left the project. This has nothing to do with intent, just, the impact of behaviour patterns regardless of how they were intended.
I also echo the issues mentioned by Raito about the Nix project as a whole (CppNix, nixpkgs, nixos) failing to curb abusive behaviour and produce effective communication. This is not talking about any specific person; the tolerance for bad behaviour is systemic throughout the entire project and we could name at least a dozen people who have driven people away by the impact of their actions. For the avoidance of doubt this isn’t even talking about the bigots, this is general collaboration problems and issues managing power differentials, but of course the bigots are also a huge problem.
I think lazy trees is a great example of where we think we understand each other better than we might actually do!
I hope I am at least clearly on the record as a Flake skeptic. I however, and quite pleased with the lazy trees work that has happened so far because to me it felt that unlike the flakes so far, they were a foundational cleanup — no new features yet, all refactors to have a “VFS” layer (like Tvix also has) with which we could make those features, or other features.
That the thing I love — foundation cleanups, refactors — ended up causing the breakage has been quite sad to me!
This makes me think again the problem is not values or objectives, but more boring things like execution and not enough person-hours.
My guess is that from the outside lazy trees appears as “ugh, yet more flakes bullshit, this is the straw that is breaking the camel’s back”, which is a very different view.
I agree, completely.
but their actions have had significant negative impact to the point that a large number of external contributors have left the project.
My read is that Nix failed at having any contributors for years, and is only recently getting better. I have less a sense of people leaving than of being less joining than I wished there would be. I don’t mean to foist blame on the would-be joiners in the slightest, but rather say the Nix Team failed to recruit more than it failed in pushing people away.
I would very much like to hear more about everything that we did which was annoying first-hand from the people who tried to contribute and changed their minds and also the people who never bothered contributing in the first place.
I also echo the issues mentioned by Raito about the Nix project as a whole…
To me, there are Nix community issues, and there are CppNix issues, and they are both very real, but also rather separate. For example, I struggle to think of e.g. a moderation issue that affected the Nix repo, the #nix-dev:nixos.org channel, or any other clearly CppNix. Most of that stuff is just lower traffic / lower visibility, and so doesn’t attract the same amount of divisive behavior.
There is an intersection around a certain rudderless and lack of divisiveness, but I don’t think that is what is pushing people away. Rather, that should be seen as a bigger enticement to get involved haha (“hop on the ship and you can just grab the tiller!”).
Is that the case? I don’t necessarily disagree, I’m genuinely curious. I don’t want to argue about the existence of difference in values, but I wonder if that matters for whether a project succeeds or not?
For me as a user, what matters is functionality, reliability and feature-set. On that plane, CppNix, Lix, Aux, tvix and guix are competing with each other, and the values of the maintainers don’t matter. Saying they don’t compete is not a useful argument here.
Now if the values of the maintainers lead to contributors putting their work into one of these competitors, and it becomes so attractive to users that they decide to switch as a result, then the difference will have mattered. But it’s much too early to say whether that happened, and in that case they still very much competed, so saying there’s no competition still isn’t a useful argument.
That’s a good point. It seems the “canonical” version of Nix is defined by nixpkgs (as nix upgrade-nix will upgrade to whatever nixpkgs#nix is) and that ships CppNix 2.18.1 right now. The newer versions of CppNix and all alternatives have to compete with that old version, which is a very real opportunity for alternatives to prove that they are better than CppNix, simply by not including the most recent breaking changes and adding features on top of that, which is exactly what Lix seems to be doing.
In theory, if an alternative were strictly better than CppNix, the nixpkgs maintainers could decide to just ship that by default as the nix package, though that would probably be a very controversial move.
That I agree with, and I feel like that is precisely what Lix and Aux are trying to achieve.
Yeah this is a real pain-point, and I know there have been efforts to create a language spec especially from the tvix team, but AFAIK this isn’t really ready yet.
The best test we have right now is: “does it evaluate nixpkgs or not?”, but as we’ve seen with newer versions of CppNix, this is not sufficient at all.
I think you’re right about this. guix is completely incompatible with nixpkgs, making it much harder to switch to it.
But any alternatives that support the Nix Language can try to be fully compatible (to the point of providing a nix binary), so switching to them can have very low cost.
And if they have a faster development speed or are more reliable, contributors and users might switch faster than expected.
Though I feel marketing/awareness is also a big part of it. Nix Super has existed for a long time, but I don’t know that many people are actually using it.
I only learned about it because they merged one of my PRs months before CppNix did.
This is a bit of a contrarian opinion, but I think people in general tend to overestimate the value of existing ecosystems. There are a lot of potential contributors out there, and if you create the right structure to allow many people to contribute to the common ecosystem without directly communicating with each other, you can easily leapfrog seemingly unassailable behemoths.
For a couple of examples, VS Code now generally has more plugins than Vim and Emacs. Rust library ecosystem is top-notch these days.
What matters is not the amount of work/code, but how easy is it to parallelize the work across virtually unlimited number of potential contributors.
With Guix, I would say the main factor is not presence of nixpkgs, but rather the policy of firm rejection of non-free software, which in the current state of the world, severely restricts the area of applicability.
One “fork” of nix Id love to see is someone forking the lessons learned and starting the second system:
I would say:
@matklad i’m not well-versed in the technical challenges, but otherwise i feel like these improvements seem incremental enough to not justify ditching nixpkgs over - i think we can add most of these without starting from scratch.
The thing is, it’s not zero sum! It would be perhaps better to do both! One personal observation here is that the sets of people who ended up working on IntelliJ Rust, rust-analyzer, RLS and rustc were mostly disjoint, although they were all in some-sense forks of each other.
So, I wouldn’t phrase this in terms of ditching nixpkgs, but rather in terms of having nixpkgs and then some more:
The conversation seems to have quickly gone down a different path, but I was wondering what impact to the wider community would be if nixpkgs and hydra built debs and app images and rpms, and the like. Nix ecosystem provides a way to have declarative builds, and all other package managers have so far struggled with this.
This won’t strictly hurt nix adoption, but instead raise nixpkgs quality as original maintainers would have a reason to use it directly. The value proposition for them is either package manually for your and common systems, or learn this quirky thing and package for all systems.
I still hav ambitions to make bundlers that allow one to transform a Nix-native build into one suitable as a native .deb. We do already have a bundlers#toDeb, but it only wraps up the Nix closure instead of making it debian-native.