EDIT: softened the language, not softened the point
It is very tiring how toxic DetSys is to this ckmmunity, and how it continues to post their ads despite that.
Let me put out my opinion upfront. We had some very rough months after the open letter last year. It called for temporary ban for Eelco’s participation in community and stripping him of all formal positions.
A half-measure was done, instead: resignation from Foundation only. Well, Eelco is still around, and he’s still destructive and toxic for the project. For Nix Project to go on, this MUST be sorted out, fast. Either Eelco and his company work on their behavior - or we as a communite step up and ban them from participation, because their behavior is unwelcome.
That was the most important part. Now I just wish to respond to some interesting things in this thread.
@roberth I don’t know much about the internals of Nix Team, but I saw you giving Eelco the benefit of the doubt. You often even went the extra mile with that. It seems that this didn’t work out - which sucks. Solving things with trust is a lot less stressful than with conflict.
I’ve seen some of those betrayals of trust for a while, and I’ve campaigned to kick Eelco out of github.com/nixos/nix. Would you like to expand on problems you’ve faced and how you see the future? I feel like we could see eye to eye on that.
There’s a lot I can say about it. But the concise explanation is: it is the difference in culture. In community projects, what we call “stable” is: not a maintanence burden, reasonably feature-complete, well-tested, what constitutes a bug is clear, and bugs are treated as critical and fixed quickly. In businesses, what is called “stable” is: the customers pay and don’t threaten to stop paying.
This difference is why DetSys insists “flakes are stable”, it’s why they “stabilize” draft and problematic PRs, why they constantly play “we’d happily help but upstream is uncooperative” card. They also get to tell specific customers to enable this or that flag to fix a specific issue: they need not care about providing equally good experience to everyone, make features work with each other, or build software that is coherent.
You could take responsibility for the feature you yourself steelmanned into the open project and actually take it to completion without dismissing valid issues as “not a bug”. You could also take responsibility by facing the uncomfortable truth, that you are in a clear conflict of interest, you steelmanned a matter concerning conflict of interest, and step down.
Both of those things were avoided by Eelco for years.
I came to believe this is by design. It’s especially evident with how Graham only ever responds to posts where he can win some marketing points. It strongly rubs me the wrong way.
It can ship it under a different name, like “determinate-nix”, or “corpo-nix”, whatever they prefer. Nixpkgs ships Lix already - there’s no issue with shipping a fork under a different name.
I think what you’re referring to is something I’m guilty of, myself - doomposting out of frustration. Flake code can’t even be called a “mess” - it is of very low quality, absurdly tightly coupled and prone to breakage on sight. It was a very long way towards getting github.com/nixos/nix to 2.24 in Nixpkgs. The versions inbetween that and 2.18 had a lot of issues.
This sucks as a user of Nix, a lot. But the reason why that happened is quite complex. There were some organization issues in Nix team, testing could’ve been better. But more importantly - the changes made between those versions touched flake-related code paths. It is nigh impossible to avoid collapse when you’re touching flake-related code. Lix team made a concious decision to stay as far away as possible from flakes and focus their efforts on fixing less brittle issues - and they STILL have several flake-related bugs, some of them not fixed yet.
I’m not saying this to downplay people’s work - I hope I haven’t offended them. I’m just trying to explain how truly dire flake code is. This is one reason why people sometimes cry out, in frustration, to delete flakes. Another factor is many organizational issues around stabilizing flakes. Well, it’s beyond hard to stabilize them, when the code is so brittle - discussing design and social issues around them is very secondary to how bad the code situation is.
In short, what I’m saying is: flakes have lots of issues, fixing them is absurdly hard, and people have mounted frustrations over years of those problems. Sometimes people blow up and call for deletion of flakes. This is a radical solution - it could work, but it will probably cause more problems than it solves. It is painfully obvious, so painfully that it’s one of the factors that causes people to blow up in frustration.
What I’m trying to say is - I don’t believe anyone will actually abolish flakes, and even doing small breaking changes is a very tall order. I don’t think anyone genuinely and rationally wants to do it, either. But unfortunately, it requires a mountain of context to reach that conclusion - it took me years. It is very understandable and valid that you, not having that context, would be worried. But worry not! There are many different opinions on how to fix flakes, but I’m sure well-meaning people want to actually fix them, without making it a huge pain for users.