I think you may be misinterpreting the meaning of this argument. It rather is saying that flakes are too tightly coupled to the rest of nix, which could be solved. IIRC there is work to decouple the new cli from flakes, for example.
As for what I think the org should do: make a github issue for people to discuss different ideas/proposals until a consensus is reached. There clearly is constructive discussion to be had, and statements to the contrary are very obviously harmful because they prevent said discussion from happening.
Do you have more details about this? AIUI you donât need to use flakes to use the new CLI, many subcommands accept -f which allows using arbitrary nix files relative to which specified expressions would be evaluated, so Iâm curious where the coupling is.
The RFC 0136 includes stabilizing the new CLI separately and bringing in flakes later. Notably the RFC only says theyâll be stabilized separately, refusing to make assertions about how/in what form flakes will be stabilized. Hereâs the tracking issue for cli stabilization.
If yâall spent a tenth as much effort on clearing and updating Nix PRs as yâall do complaining about Eelco and DetSys there is no telling how far along weâd be.
You can just do things, you know, instead of whinging and rehashing âWe hate DetSys and Eelco and want them to fail thread #23â.
And if you canât just do things, because you discover there is insufficient coordination/consensus/buy-in, perhaps it will suddenly make sense why DetSys chose to do things the way they have (and Lix the way they have, and Tvix, etc.)
I think itâs been made clear that at the very least, the marketing from Determinate systems has been incredibly toxic, whether intentional or not. I hope that you rename your fork to something that is extremely clearly different from nix, and I hope that the Nix foundation moves more quickly to register a trademark, as there is a clear problem that determinate systems has refused to fix time and time again, and at this point, can only really be deterred legally.
I also hope that determinate systems reconsiders their business model. Either, they should commit to supporting the open source version fully, and not maintain their own fork, or just fork the project and divest from nix, making it operate however they want. I want to point to how astral.sh plans to monetize their company: they are intending to maintain the open source version of their python tools, using the fact that their open source tools are so much better to be used by a ton of people, and then build tools that rely on their open source tools to sell to customers. This, to me, is the least toxic way of operating, as they are incentivized to make an amazing open source tool like uv.
Either do the hard engineering work to build a complete competitor to nix thatâs also open source to divest from the business model, or do your best to improve and invest in nix and make it as good as possible, and gain the good will and buy in from doing that. Donât just keep half-assing it by maintaining a fork that is just nix with a hat and some new clothes, and having wool pulled over peopleâs eyes when âNix 3.0â comes out. Youâre not collaborating with the nix community, youâre abusing us, and that doesnât build the goodwill you need to make your business model work very well, at least in my opinion.
I donât think people appreciate how huge the Nix code base is and much fucking work it is to get anything done. I started working on Lix roughly half a year ago and was only able to quickly become productive in it thanks to pennae being an awesome mentor. On average, Iâve been working roughly 10h/week on the code base since, and yet Iâve barely made a dent on the projects I set out to work on. At the current pace, some of them will still take years. Most non-trivial changes send you on a goose chase of side quests, other bugs to fix first, and debugging spurious segfaults at the other end of the code base.
This is not only a snarky response to something I consider a very inappropriate answer to very valid criticism. I also ask because it seems that you severely underestimate how hard it is to contribute to Nix.
I have personally attempted to backport several Nix PRs to Lix. This is a relatively easy task - the codebases havenât diverged very hard yet. Still, this was enough for me to run into so many issues:
C++ having many unergonomic semantics: it doesnât shy away from throwing smart pointers, lambdas, templates and moves in your face even in trivial code
C++ not having easy learning materials like âC++ Bookâ, docs not being easily approachable
Clang LSP being quite unhelpful: I felt more at ease even from quite barebones Python LSPs. More advanced LSPs like Java or Rust completely outclass what C++ has
The codebase being genuinely complicated and large
Some code being not very well-structured. Iâm talking about 200+ LOC functions that check CLI arguments, print logs, do interactivity with human operator, check many settings flags, and ALSO still doing a bunch of business logic
Many project-specific arcanities, like an integration test suite written in Bash, with all the footguns it comes with
And keep in mind, I donât even have much experience. Many Nix Team members worked for years before they felt comfortable with the code base. Many Lix team members have years of experience writing C++, and also years of experience with Nix codebase. Iâve been around Lix development channels for a while, and the things they complain about - async infra, RPC, logging infra - make me terrified.
Please, donât suggest solving a purely political problem by staying quiet and magically fixing the technical issues of Nix. Not only is this missing the point, not only is this unproductive, but you also donât seem to know how much youâre asking for.
A critical component of our approach here is that Determinate Nix is a downstream distribution, with a focus on improving and validating the patches weâre wanting to get accepted upstream.
It seems weird, then, that some of the harshest critics of our strategy to improve Nix in this thread appear to be users of and contributors to Lix, which is explicitly a fork without a stated goal of their improvements being accepted upstream.
Many people here have said they believe we are acting and communicating in bad faith. Unfortunately, there is not much we can do there. I am deliberately and sometimes painfully straightforward and honest. If people donât believe me, I canât really fix that without demonstrating it through our actions.
Our actions have consistently shown collaboration and a willingness to support and improve our projects and work to deliberately support our work going upstream. Despite that, when work does go upstream it is turned into a âtheyâre infecting our stuffâ conspiracy â like the above comment I already replied to.
I am rather famously easy to talk to, and am really quite happy to engage with hard conversations directly, with honesty and curiosity. People in these threads wonder why I donât engage with the mud slinging here, and Iâd like you to ask yourself if you would?
It is not fun to post about our hard work, only for it to be responded to with made up accusations of ill intent, sometimes literal deliberate lies Iâd hope would blow over, accusations Iâve somehow tricked Eelco into what weâre doing, etc. Frankly, it is incredibly rude and unpleasant, and I hate it.
People on my team wonder why I continue to insist we publish here or engage at all. Itâs because we are part of the Nix community, and we are contributing to the project, and I love Nix so deeply that I want it to succeed. The division and stagnation and anger and inability to choose are so incredibly disappointing to witness that we were forced to change our strategy about how to vet and deliver these improvements.
Some people appear to be afraid of Determinate Nix âtaking over.â That is literally not the goal. It is a vehicle for us to improve and deliver on work weâve had in flight for years, where there is no clear decision about it from upstream. Iâm not satisfied being stuck in indecision, so weâre moving forward delivering what our users and customers need and are asking for. My greatest hope is the Nix project finds its way through this. There are many hard choices to be made, and I hope a process for choosing is identified and implemented. I think a lot of the fears would simply go away if the overall project was more able to make hard decisions and execute on a plan.
Anyway, hereâs some thoughts. Itâs not edited or workshopped or anything, and on that note: one side effect of communicating clearly, honestly, and directly is it can come off disingenuous because people arenât used to it. It also means it is easy to say things people donât like. It is okay for people to not like what I have to say. Iâm open to and am very happy to engage in conversation to understand, share perspectives, and learn. I donât mind having my mind changed! But the above thread is not really a conversation.
A critical component of our approach here is that Determinate Nix is a downstream distribution
Call it what it is, a fork that violates a trademark that you donât even own.
It seems weird, then, that some of the harshest critics of our strategy to improve Nix in this thread appear to be users of and contributors to Lix, which is explicitly a fork without a stated goal of their improvements being accepted upstream.
No. Just like Lix canât tell Nix to change its name, we wonât describe our downstream distribution as something it isnât. Folks all concerned about âtrademarkâ until it has to do with Nixâs own name.
And where has anyone from the Lix project actually told Nix to change its name? Iâll remind you that the âCppNixâ name is used to differentiate the implementation from the language.
Youâre also effectively arguing that itâs fine for you to do a bad thing because someone else is, itâs childish.
Both you and @piegames have suggested that there is a significant technical component to the problem, otherwise itâd be easy to route around.
But, look, speaking from a decade and a half as both an IC and a manager, letâs talk about the political angle. Letâs pretend that it genuinely really is a purely political problem that can be solved with just soft skills.
Politics is the art of the possible. It would be great if we could just bring more people on to handle the increased usage of NIx (debugging, feature requests, etc.) For reasons mentioned (by you two) above, thatâs not feasible. The corollary to this is that we should seek to do the best we can with the people we have. One of those people, no matter how much you dislike him, is Eelco.
People do not respond well to bullying. There has been, for over a year now, a concerted effort to shame, complain about, insult, or libel Eelco (and DetSys). There is no world in which these constant attacks are going to motivate him to engage productively, and that kinda causes a problem for you given (1) above.
Politics is not about whatâs right, itâs about what you can get done. Even if the claims mentioned about Eelco and DetSys are true (which I donât believe they are, but again, we need not litigate them here), the metric for success in political matters is: âDid I get what I wanted done?â The answer so far has been no, right? Thatâs why yâall are still here, and thatâs why youâre still complaining. Do you think that the same strategies and intransigence thatâs characterized you folks for a year are worth continuing to double-down on?
Credibility is important. If you lie, continually misrepresent, or just give off bad-faith vibes, people stop engaging with you productively. In a case like this, where consensus is important, that kinda puts you in a pickleâto the degree to which Eelco and DetSys might even want to work on some of these things with yâall, the long history of abusive behavior and bullying and just general toxic shit everywhere makes everything you say suspect, and that makes the consensus process slowed.
Spite is real and has to be accounted for. If youâve been toxic enough some people will act against your wishes if it costs them less than it hurts you. If you want to get something done you have to make good until the person is no longer in a spiteful condition.
Politically, it would appearâbased only on the last year and change of skirmishingâthat this is intractable given the players, their skillsets, and their dispositions. Let us pray that we can reduce it to a merely technical issue.
Donât want to get into the political side at all, but in different projects Iâve seen that if you fork it to add functionality you need (professionally), and PR to upstream it, the energy to actually get it accepted upstream is sometimes disproportionately high (compared to the implementation effort).
Seeing that in the Nix/FOSS community thereâs not even consensus that (or whether?!) flakes are actually a good thing, I could imagine that the resulting resistance to upstream features may be an issue here. So supposing that DetSys would âjust want to get things doneâ first of all, and worry about everything else later, I can understand how things are like they are.
Not sure what to make of the historical thing that Eelco (I think?) wasnât in favour of making flakes stable anytime soon (before the âriftâ), but now DetSys has done just that? But maybe that because of real progress on that topic? In which case upstream might prioritise landing the mentioned PRâs?
No, Eelco has been ready for flakes to be stable for years. Heâs been internally advocating for us to release Determinate Nix 3 with the experimental flag removed for a long time now.
A good portion of the controversy would probably be fixed if you just renamed your version of nix, and didnât confuse people with your marketing of ânix 3.0.â lix is clearly different. Nix 3.0 is not.
And yes, determinate nix also feels incredibly confusing.
Ah, thanks, might have been other resistance and/or resources priorities then. Anyway, Iâm all for flakes and for minimal diffs between all of the nixesâŚ
@grahamc Okay, so first off: thanks for responding and addressing some of the concerns. Being on the receiving end of the stonewall treatment has been nothing short of awful, so I appreciate that you took an effort to change that behavior, and I hope itâs not a one-time offer.
Iâll offer my opinions as someone whoâs been criticizing DetSys approach for a while, and Iâll refrain from personal jabs or arguments in bad faith as a token of gratitude for taking the time to respond. Iâll offer my counters not in the order you made your points, but in order that makes for the best critical piece that I can currently muster.
Please respond to my arguments wholeheartedly and without omitting crucial pieces. If you donât have much to add to something I say, just say âyesâ or ânoâ - that is much better than staying quiet on it.
Yes, I would. Iâm of the opinion that what stands behind the frustration and complaining are valid concerns that stay unaddressed. When I see someone cry out in frustration - Iâm curious what happened there, what they are unhappy about, why they donât feel heard.
Of course, when you get some expertise on the topic, you know the common pain points. You also often get to make decisions. Some may align with problems people cry out about, and some may not. Sometimes it is for the better, sometimes it is not. Itâs part of human communication, which is hard, and I also ignore some complaints from time to time. Canât please them all when you have limited resources.
That said, I would quite definitely engage in the âmud slingingâ and try to understand where Iâm wrong and what people are concerned about, when my repeated attempts at addressing their criticism over the years failed, and the frustration only got worse.
This has been the exact opposite of my experience. People greatly appreciate honesty. People donât appreciate being dismissed or screwed over. When you are brutally honest, you tell people upfront that theyâre not a priority: and that often makes them angry, and you start to wonder that maybe it wouldâve been better to let them stay in the dark. But if that becomes a major problem - I feel this is more of a management and prioritization problem, rather than honesty problem.
A large reason as to why, IMO, is that you donât address the criticisms spoken out. You either stay silent - or fail to address the point made.
You often say that, but what does this actually mean? I havenât found any editor notes, any glossaries, or FAQs addressing what is a âdownstream distributionâ. More importantly - I donât see any of those answering whatâs the difference between âdownstream distributionâ.
Going by conventional wisdom, by impression is that âdownstream distributionâ refers to artifacts produced compiled with some additional options, and sometimes small patches, to reach some specific goal related to distribution. Examples I can think of: JDK with FIPS enabled for compliance, Debian packages that have specific rules on packageset and compilation, and software compiled with hardened memory allocators for security.
Notably, DetNix doesnât simply do that: it also includes many very large patchsets, like parallel-eval, lazy-trees, and flake-schemas. Those are major features, developed out-of-tree, and also submitted upstream. This very much coincides with what âforkâ means, except that the last part is optional.
The only project I know where it is considered acceptable to develop patches and features out-of-tree and call your project a âdistributionâ (that would necessarily be âdownstreamâ) is Kubernetes. k3s, k0s, minikube and others - call themselves âdistributionsâ. I donât know how that came to be, but it is an extremely abnormal practice.
If you still insist on saying âdownstream distributionâ - please, do the responsible thing and put a disclaimer in any nook and cranny that explains what you mean by âdownstream distributionâ, what you consider a âforkâ, and how your definitions differ from commonly understood ones. Because currently - you are just causing a lot of confusion for people by using words to mean things very different from what people usually expect.
It is, like, a good practice to agree on the meanings of the terms before you use them. Itâs common in tech, and itâs required in research. And considering that confusion that was caused by you not doing that was spreading for years - please make it a high priority issue and resolve it decidedly.
Your workflow works quite poorly for that. You submit gigantic patches that provide an E2E feature. They are plainly impossible to comprehensively review and test by upstream. This has been brought up a lot of times in lazy-trees and parallel-eval, by Nix contributors and Nix Team members alike. It is also hard to trust your internal code review and testing - you include a whole bunch of other patches that can make things harder to verify, and it is unreasonable to expect upstream to also follow your internal development, anyway.
This is not the case of the upstream being uncooperative - your development workflow just doesnât work for how a collaborative and open project is developed, at all. Break down your patches into small reviewable pieces, focusing on one small thing at a time - and Iâm sure youâll see so much more success in getting things actuall merged.
Actually, Lix already uses the âsmall reviewable piecesâ strategy with great success. It also doesnât have a bunch of issues that have plagued upstream for years (some of which directly caused by Eelco). But perhaps more importantly, AFAIK, Lix and Nix teams do try their best to cooperate on important matters - security issues, long-term flake plans, some features and bugfixes. Theseâs a lot of bad blood there - but both teams still try to cooperate and account for each otherâs cultures.
So far, your actions have been very unsuccessful in doing that. So far, things have been getting progressively worse every time you take action. Pethaps itâs time to reconsider how you go about those actions?
I am not sure how your âfameâ (from what timeframe, and amongst who?) is relevant here, to be honest
The problems in the community that youâve outlined are indeed very, very bad. They havenât appeared overnight, and they go to years of continuous stonewalling of valid concerns. Failure to address them, which repeats again is again, is why I stopped recommending Nix Project to individuals and organizations. I once held thought of doing some business based on Nix Project, and now this haunts me in nightmares.
There are ways to resolve it more gracefully than you do, though. There is political way in the Nix Project - that hasnât been particularly effective so far. Thereâs Lix way - a bunch of people, many of whom do Nix for a living, forked the project in hopes of building a better community and structure with less problems from the ground-up. It is too late to suggest leaving Nix completely - but you can still make your fork more of your own thing, independent from upstream. There are even precesents for legally protecting GPL code from âleakageâ, if you are concerned about that. Which I wouldnât, seeing that many patches you already include have gigantic size that is impossible to re-integrate into upstream in short time.
There actually is, for some things. Last I checked lazy-trees - it basically came down âthis is impossible for us to review, break it downâ. Same for parallel-eval. Issues concerning flakes stagnate, sure - but there is a truly vast amount of related issues that need solving, some of which were already mentioned in this thread.
This is exactly what Iâve already mentioned in my previous post and in this post regarding your priorities and development process being decidedly different from what upstream has.
This will sound hostile, but I do not currently know of a more neutral way to phrase this. Still, I want you to hear me out. I wear my opinion on my sleeve that the âhard decisionâ that I consider best is to exclude DetSys from the community. This will, of course, be unpleasant to you, but I still want to ask this question out of principle, to better see what common ground and disagreements are there. If Nix Project decides that the âhard decisionâ to be made is to exclude DetSys from the community, will you support it?
Actually, it can. And Lix people have, on many occasions, suggested renaming Nix to CppNix, to get rid of some terminology confusion and to emphasize the culture shift that happened. What Lix canât do is decide on Nixâs name, because it doesnât have the authority to do that.
Iâm not trying to one-up you: the difference here is crucial. Lix people havenât âorderedâ anyone - they gave feedback and made a request, and were refused. Nix community offered feedback and made a request to change DetNix branding. It is up to you to comply with the request - or dismiss it. Community is not being unreasonable here, at all.
And the whole reason there is even a conversation here is because NixOS Foundation hasnât registered a trademark in time. This is just a fact. Had there been a trademark, your âDeterminate Nixâ branding would be very dangerously close to breaking the law, and NixOS Foundation could choose to resolve the conflict in court, using their lawful rights. I havenât seen any symptoms of a controversy around trademarking in Nix community, and I have seen strong support for it, so I would assert that had NixOS Foundation had more time and resources, it would be able to register the trademark a while ago, which would objectively prevent you from taking up âDeterminate Nixâ branding to begin with - there would be no discussion here to begin with.
I donât do that to intimidate you or threaten legal action - I donât have the authority to do that, and thereâs no legal action to take when thereâs no trademark, anyway. I am merely explaining how we got to the point where we have this discussion. Please, do not exploit the fact that Nix is not trademarked due to the organizational issues for the sake of your project. This doesnât make you look any more trustworthy.
Sorry, I donât understand what you mean here. Please rephrase.
I think Eelco gave extremely conflicting signals on this one. He developed the feature - and then opened the RFC. He addressed some feedback - and not the other. He agreed in the RFC process that flakes arenât ready - and still pushed to merge flakes under a feature flag. He closed the RFC as ârejectedâ due to flakes not being enabled by default and ânot being readyâ - but also havenât followed up with other RFCs to solve this mess.
Frankly, due to this history of constantly going back and forth on the decision to be made, bouncing between steelmanning and compromising, and failure to address the consequences of that, which caused such a huge mess to begin with - I donât think Eelcoâs opinion on the matter has any value at all.
And besides, the flakes question isnât about Eelco to begin with - it is a question about the community at large. It is why the RFC was needed to begin with. Said community and RFC were severely damaged by Eelco acting very irresponsibly around it.
Iâm not trying to dig up skeletons from the closet to shame somebody - I am trying to demonstrate that none of the problems around flakes that we see to this day are accidental or made-up. All of them, to this day, go back to that hellish RFC. This is a community problem that you canât just ignore or dismiss. If you want to move forward without addressing those issues or helping the comminity figure this out - please commit to your fork, call it such, and then you are completely free to do so. But urging the community to ignore those unresolved issues for the sake of progress is very irresponsible, unless you successfully argue and convince the community that your approach at least does more good than harm, and preferrably - actually solves existing and very important issues.
Lix team has committed to their way of solving the problems, which is incompatible to how Nix community does things, by forking the project and doing their own thing. This is a very tall order, and I donât suggest everyone whoâs unhappy about anything to just âfork it, lolâ. But you do have to compromise somewhere - you either commit to tolerating the communityâs ups and downs, or you do your own thing. If you insist on doing things your way, without accounting for how community works at all - then I suggest fully committing to the fork instead of keeping up the appearance of cooperating with the upstream.
I think this is the right angle and one that I have been for a long time aware of. You are just missing one crucial piece: you are assuming that you are understanding the full picture of the last 10 years of history of âNix, the evaluatorâ development and all the social interactions with various generations of developers.
The reason for why certain spawn-off projects out of Nix exist is because everything âthat is possibleâ has been tried by some, and they decide to leave the space. CppNix as it is now, is the result of the management policies you explained (I donât really call that politics, but thereâs no real strategy-making IMHO in the current form.).
For my uses and my clientsâ needs, this is insufficient, the quality needs to be higher for my projects and my clientsâ projects.
Yeah, I agree. Unfortunately, given the skillsets at play, I do not foresee a hopeful outcome.
So this is why my only intervention (I try) was only to call out on the classical FUD played here about âoh no look they want to remove Flakes and break all the users out thereâ when actually the person who has been breaking the most the userspace for Nix users has been Eelco Dolstra. The sheer quantity of issues not acknowledged, the sheer quantity of regressions, the quantity of âoopsiesâ and yolo merges and yolo features is unbecoming of a mature project.
I know that the Nix team and even Eelco has the best intentions at heart. Even more: I know that Determinate Systems truly believe in their mission and their employees are probably great at many things, e.g. Lucâs work on Zero to Nix is a real gem of how to write good documentation.
This is the important thing here, everyone is doing their best and doing a lot of good work. So why is it not working out?
Thereâs nothing weird in a Lix contributor being a harsh critic of what Determinate Systems is doing. We are the best positioned to understand what you are exactly doing. I read all your branches, all your work, watched your videos, reviewed your work and more. I understand where youâre going and what is your strategy.
My intervention here is simply to move the debate from an emotionally-loaded conversation (understandable, like you said, you are deeply in love in Nix, so we are.) to a technical and factually-based conversation: âhow to fix Flakes without breaking users?â
What is troublesome or difficult is that contrary to Graham and Eelco, Iâm not the (co-)founder of a VC funded company with millions of dollars in bank and full-time employees working around the clock on products and things. Itâs not up to me to do the calls, neither to follow the RFCs that the Nix team painfully laid to get away from the Flakes debacle. That authority is in the hands of the management layer of Determinate Systems (and really any corporate company in the Nix space).
All the excuses about how upstream is blocking their work is a bit funny to me. They have the resources to unblock the work, but when, I asked Eelco in a Nix team call whether he was paid on behalf of Determinate Systems to work on Nix or not, he told me : no, heâs a volunteer in the Nix team. This is impossible to understand for me. Either Eelco (& DetSys) have been trying to send funded paid work to upstream and working with them, either this didnât happen and all that happened is what one of the Nix maintenance teamâs member described: blindfolds and sudden surprise work.
And let me tell you something for the record. Iâm sorry this is how you live it. We had an honest discussion few years ago about how things would look like in the next years. I tried to see what realistic exit there would be for you and your company. Unfortunately, I am only a volunteer in the larger FLOSS ecosystem and I feel like I was the only one carrying the project of trying to mend relationships with many corporate entities (and community members) that were broken. Nonetheless, I still apologize.
That being said, I am also disappointed to read you saying that. You are a mastodon as a company and all the reputation preceding you, in front of you, you have a myriad of confused (notably due to the tendency of people refusing to rename things to diminish confusion) contributors and users who have no option or retort except than present their frustration.
Someone said thereâs concerted efforts to do X or Y, thereâs mostly a shared common culture and people who are shocked over and over, some of them even discover the Determinate Systems drama and go sling mud, because this is what you do when you have no other power. As it was explained, writing C++ on the CppNix codebase is not for the faint of heart. Itâs hard. But many of my colleagues now believe in the mission of shipping something great for our users, something that is a common. Not a corporate-exploited resource.
If you believe in this mission, I recommend anyone who feels despaired over the state of things to think twice before slinging further mud to the Determinate Systems team, join Lix and ask what you can do. I donât promise we will solve everything instantly, but I can say that we will use your energy to ensure that everything that users deserve, including what Determinate Systems think it should be in a daemon to bypass LGPL requirements, will be considered and developed in Lix.
I think what needs to be said has been said in this thread (regarding Flakes, how to fix them, the rhetoric used, the baitânâswitch, etc.).
Maybe what should be done is next time Determinate Systems post their new release just before any event, community members just write a press release to call it out and merge it on the homepage, or I donât know, just hold a press release community area and only one message of disappointment gets sent. Iâm sure given how we are redoing all the same talking points all the time that this message only needs to be written once. This way, it will be less mud slinging and more grown-up communication and less repetition of what is the actual truth on various topics.
Now, I hope this is my last message on the topic, I tend to stay away from these discussions because I am profoundly disappointed by many of the ex-colleagues and leaders that I worked with in this project. I believe they have let down the original culture and identity of the Nix project, e.g. high quality work, empathy towards each other on trying to find the optimal outcome for everyfew involved, etc.
Uhhh, no, not at all? How have you reached this conclusion? There are reasons why me and pie contribute to Lix and not Nix - and those reasons are 100% cultural and political. Forking Nix to Lix also wasnât trivial at all - there is an untold amount of organizational and infra work that was put into it. I can only applaud this effort. And it is very hard to replicate.
A large part of the Lix team has signed the open letter against Eelco. A large part of other Lix contributors have done so, too. There are people who have never contributed to Nix, but tried contributing to Lix. All of this suggests that all those people were pushed out of committing to Nix, in significant part due to Eelco. Was it worth it to preserve one man and discard tens of people, many of whom are not any less capable? I think those were exactly the people we could bring to contributing to Nix, but utterly failed to do so in hopes of preserving Eelco. This is a terrible result.
Because nothing else works! There have been years of constructive talk about that - which led nowhere, because Eelco, who was BDFL in all possible regards then, dismissed and ignored it. It got more heated - he still did exactly nothing. We had an open letter - to which he wrote a horrid response which led many people to ragequit. He then did the bare minimum, resigning from Foundation, and talk around the town is that even getting to that point has been pure torture. Then, a temporary governance body, which⌠Hasnât addressed the problem at all, and kicked the can down the road to the SC which will be elected in then-future.
Well, we had our elections, and we have SC now. Guess what it has done to address this issue? Exactly the same as before - exactly nothing. The only thing that got us any results so far (Eelco resignation from Foundation, temporary governance body, and then SC) is the public outrage. So why do you insist that the community is in the wrong - when we have had people all along the way who couldâve solved the issue very effectively in short time, but havenât, and still donât?
But we do - as mentioned, this is the only thing that works.
Yes, because other strategies have been tried in the past, repeatedly, and they have achieved far less success than what âweâ do now - even with the miniscule amount that was achieved with this strategy!
No, it is not, lol. We have a governance body who can make this decision overnight. It has been voted for. We do not need consensus - we have SC precisely to act when thereâs no consensus.
You should maybe consider for a second why this came to be, instead of dismissing people outright.
We all started there, and got exactly nowhere. This. Does. Not. Work.
It seems to me that you experience a large amount of discomfort because people donât act nicely, and fail to account for why things ended up that way. This does not resolve any conflicts, whatsoever. It just preserves the status quo, calls the people expressing dissent to voice their opinions in ways that can be safely and calmly ignored, and absolves people in position of power of responsibility and accountability. This is shit. Please reconsider.
The Nix project has long intended to release version 3.0 when flakes are stable. With Determinate Nix 3.0, weâve fulfilled that promise by offering a formal stability guarantee for flakes, making them production-ready today.
(Emphasis my own.)
You are sending mixed signals by stating you âwill not describe [Determinate Nix 3.0] as something [upstream Nix] isnâtâ. In practice, by using the 3.0 version number, you have done just the contrary. You have declared that Nix 3.0 is ready, that the roadmap has been fulfilled, and it is available in the fork from Determinate Systems.
Even though I do read your words stating that Determinate Systems is just some services around a totally still Open Source, and Free Software component (Nix), and on a pure technicality still is, it is not what matters here.
And this comes back to an answer I did not have the energy or time to write to @rhendric, too: the issue is not that Determinate Systems has Embraced Nix. The issue not even that anyone Extends Nix. If weâre thinking about the infamous three Es, the insidiousness of them is that the first two are good, and without the third E, there is nothing wrong.
The issue is that when the third E comes, itâs not necessarily making itself obvious with a bang, it is a component of a long-term strategy, and is insidious. This is why people can become hyper-aware and defensive around situations that could result in an EEE situation. Like a VC-funded company doing bold moves Embracing and Extending an Open Source or Free Software project.
Though here, Graham, your move might have been too on-the-nose. Building alternative facts that Determinate Nix 3.0[sic] is not a fork, and not an attempt to describe Nix 3.0 as something it isnât, is, like the kids say, a mood. It feels like you are testing the grounds. Seeing how far you can push your narrative before it is too much.
This is what I was writing about in my previous messages. Having extensions around Nix is not an issue per se. What is, is the hostile move taking away the self-determination of the Nix project, by taking the roadmap toward Nix 3.0 from the teamâs hands, and scream loudly: I DECLARE WE ARE NOW HERE, wherever yâall really are.
The issue is 100% about messaging.
You could have made the exact same thing you were already doing, and continued doing it, and just pushed an update stating that Determinate Nix [1.0] continues to be the place where you can find the already existing guarantee of stability around Flakes-as-they-are, there wouldnât have been much notice around this. Even with mentioning the plan that you were going to extend this work toward for other experiments around Nix, wouldnât have made this much of a splash.
Except that the messaging, even if it was apparently not the intent, makes it sound like you are deciding that Nix 3.0 is ready, and forcing the hand of the upstream project through declaring loudly it is.
If, like you said, you are âdeliberately and sometimes painfully straightforward and honestâ, and that this really is a genuinely honest attempt, from an over-enthusiastic team. Then it is misguided. You have been running with blinders on, not realizing the privileged place Determinate Systems has and the power it holds over the project, and not realizing how small moves that are targeting the upstream project like this one needs to be done really carefully.
And now to discredit all of my points, a personal attack: Considering you said after that you are ârather famously easy to talk to, and [are] really quite happy to engage with hard conversations directly, with honesty and curiosityâ, Iâm not sure how straightforward and honest you are. Before I became an overt opponent to Determinate Systemâs moves against the ecosystem, you had spent a long time ghosting me. Iâm talking about discussions pretty much like here, where reaching out to you to get more information about those moves was met by silence. So Iâll continue having my doubts about the veracity of your communications.
