So what?
If DetSys actually comes out with a better installer, better than the community installer, and people use it instead, so what? If I search on Google for “linux installer” right now, I get Canonical’s Ubuntu. The next entry is linux.org. The next entry after DetSys is nixos.org.
The objective is to get people using Nix and growing the community–that’s what matters more than a nix measuring contest.
That’s a poor example. There is no “Linux installer” (I’m sure you’re aware that there’s also no ‘official’ Linux distribution either) but there is an official Nix installer for the official Nix distribution. Despite what DetSys advertising misleads people into believing, theirs is not the official installer nor the official Nix distribution.
I dont understand why everyone is so upset.
The Nix ecosystem needs better administration and that seems to be lacking in the community. If a company decides they can do it better, they can try. Just because its FOSS doesnt give the project a stamp of “immune to competition”. Its not even really competition, theyre upstreaming their code. They’re contributing a better installer that enables flakes by default, theyre contributiing a more up to date nix distribution. Quite frankly this is what nix as a whole needs is people who are actually making changes. Look at how long we’ve been waiting for NixOS to be ready for new release.
Nix is a far superior technology than docker, ansible, salt, etc. But it has nearly no adoption besides home labs and enthusiasts.
If companies wont touch nixos for the enterprise its because the ecosystem is not reliable enough.
I google “install nix” vs “nix installer” and get different top results, because detsys installer is refered to as “installer” everywhere, it comes up when searching for “nix installer”, surprise surprise.
And paying for seo is the standard practice. I don’t see any problems here which deserves to get a company banned, (not on this point at least)
As for the flake stabilisation issue, I think pushing for quick immediate stabilisation is stupid given the amount of instances people reported on how unpolished it is.
If Eelco Dostra is really blocking the flake stabilisation as people are alledging, I suggest to ignore the existing prs and rework them, so if not now, in the next few years flakes will be stable.
The idea of flakes being a plugin developed by Determinate Systems out of mainline nix suggested in one of these announcement threads, is great too. So I don’t see why people are getting so worked up and demanding to get this company banned. It just feels like hate without real substance.
Flakes aren’t enabled by default because of their still experimental status, despite that Detsys in my eyes, has continued to pushed them to try to be official despite their experimental status. This is one of the problems I have with Detsys. The lack of better administration will hopefully be solved by this upcoming SC we are going to have. Another of my concern regarding Detsys is that Detsys is seemingly trying to push the ecosystem towards an open core model and corporate controlled model. Rather than an open source and community controlled model via their proprietary offerings such as FlakeHub and now Determinate Nix.
I agree with this, it is a great resource and idea. Thank you for sharing. Somewhat similar, I posted something about how Apache projects work, which I also find inspiring: Nix deserves great governance.
This post was flagged by the community and is temporarily hidden.
You (and others) keep ignoring the actual problem, despite it having been pointed out a million times.
The problem is conflict of interest. You can’t hold actual power in organisation A (e.g. the NixOS foundation), while being financially invested in organisation B (e.g. Determinate Systems), when B is benefiting from A being held back.
Also, please go read Domen’s reply.
I don’t think B is benefitting of A being held back , that is at best an illusion, and I don’t think B (DetSys in this example) see it that way either. At the contrary.
Nix mindshare is currently a small, small fraction of what it could be, if adoption was increased as much as the technology deserves.
Do we not all want to see Nix becoming more mainstream, more popular, more successful? The way I see it, interests align much more than they conflict. And therefore it makes me surprised how often I see “conflict of interest” invoked as argument in this community.
detsys wants to make money while reducing the reach of the original project. I don’t see much alignment there. That’s also different from just about every other company I know that uses or builds on nix.
Besides, I am personally not a software religionist or evangelist, I care to see the software that I use get better, not just inflate numbers for venture capitalist investors or so on. I am sure various members of the community each have their own vision here. If there was a unified vision, I didn’t hear about it yet.
In the case of the installer, the DetSys installer is open source and the same license as the Nix install script, and it has already been noted that there is an effort to upstream it, if the community wants it. It’s hard to see how NixOS is being “held back” by being offered, free of charge or license encumberment, a better solution to a problem, that has already been field-tested with real users.
I don’t think this is accurate. Their business model presumably is aided by nix adoption.
Can you unpack this more?
The use of the subjunctive tense here seems premature to me! Devenv is already useful and pleasant to work with, plus easy to contribute to. As you mention, it’s also unencumbered by any unattractive attempts to lock users and contributors into proprietary tools. I don’t see any compelling reason why it can’t yet become the premier way to define and manage Nix-based, per-project development environments. Its universal availability might make it attractive even to customers of other Nix-centric platforms! (You don’t even need devenv-the-binary to use devenv-the-library. Devenv’s official docs make clear how you can use it with a flake.nix file and no special tooling, and presumably thus any Nixlang implementation you like, although devenv-the-binary does add nice functionality around garbage collection and speedups for direnv integration, etc.)
And I think this is a strategy that can pay off regardless of anything these other Nix startups do or don’t do. My team at work uses devenv for our own projects, and I know there is some interest in Nix adoption on other teams. Cachix will doubtless be the first option I push to evaluate when we come to need private binary caches, because our pleasant experiences working with Devenv have set our expectations for Cachix high.
That’s all. Just wanted to butt in to say that I remain optimistic about Devenv’s place in the ecosystem. 
This seems kind of circular reasoning to me. “I’m not happy that DetSys is trying to make flakes standard instead of being experimental because right now flakes are experimental.”
It’s like…okay, I guess? Sorry you don’t like them? There’s not a sound argument here that I can see for not doing flakes (I know some of those exist, but again, I haven’t seen any that seem to be true dealbreakers to me and which would preclude other people from using non-flake workflows).
(FWIW, the biggest coup Lix could’ve pulled off at launch would’ve been making flakes non-experimental in their fork, but alas…)
This is an oft-repeated talking point but I never really see any substantiation of it. Open-core means a particular thing, for example with Redis or Canonical or various other examples. Corporate-controlled means something else still, and with the licensing currently in place there’s nothing stopping a fork if it’s deemed needed.
If “worried about open-core” is being used as shorthand for “I don’t like the people involved and they made my friends angry so I don’t want them to make any money or benefit from the ecosystem” that’s a different thing altogether.
I’ll make the grim observation here: the community-controlled model has been bumpy, slow, and not particularly helpful, and has been set upon by various factions with grievances.
Open-source isn’t an aesthetic, it’s an organizational structure that gets picked to solve some set of needs–and if you fail to meet those needs, other structures exist. Open-source projects are not magically exempt from having to display competence and deliver on value, and similarly they are not magically morally better than a closed-source project that ships on time and solves real problems. Claiming otherwise is just fanboyism.
The other thing to note that gets glossed over: the ecosystem as it exists now requires lots of corporate handouts from companies that do not even pretend to otherwise care about it. The S3 bill, because reasons, is absurdly large.
There is no future in which we can both eschew corporate support and continue to be slow getting things done (say, slapfighting about governance and who is being othered by who instead of solving the technical problems that keep us existing on AWS’ largesse) and survive long-term. Pick 2.
It seems like you’re missing a lot of detail. Flakes are an annoyance in the community because:
Flake adoption is so vast that arguably whatever the current technical issues are, it seems most people arent bothered by them. Calling flakes experimental at this point is misleading.
Generally when you say experimental it means “going to change a lot and rapidly”.
Flakes have been stable for a long time now. It stopped being experimental when people stopped changing it and started using it.
This is just my opinion but RFCs are really only useful in so far as creating standards that many different groups need to agree on. Like TCP, UART, DNS, etc.
A single product with a feature being developed does not need an RFC, in fact thats probably why flakes became so widely adopted. It skipped the beaurocratic BS stage and went directly into problem solving stage.
An RFC gives people the structure, place, and time to discuss things and RFCs help build community consensus and buy in.
That’s fine for your opinion, but not what the community at large has agreed on.
That’s pure speculation.
And all the features that have gone thru the RFC process, been agreed upon, and have been successful are what, exactly?
I’d just like to quote @hraban from Nix team member suggests removing flakes; data suggest it isn't a good idea, please remove the experimental flag instead - #87 by hraban on this:
I’m in that dataset yet I dislike flakes. I agree with Infinisil’s objections (and more), I wish we would redesign them completely. Yet I add a flake.nix to all my new projects. Why? Because what alternative is there right now? Flakes have sucked all the oxygen out of the room for any alternatives.
This cuts to the heart of it right here.
I think useful follow-on questions from here that might help shed light are:
I think reflecting on those questions–and mods, maybe this would be a good forking point to a new discussion–might yield some interesting information.
It sounds like we’re arguing de jure vs. de facto standardization. De jure is when a standards body presents a standard; de facto is when the community adopts one technology over another.
It seems that flakes are a de facto standard in their current form, albeit with competing packages adding structure on top. It’s not unheard of for de facto choices to become a formal standard, just look at how many of the web standards came about. (Concurrent competing proposals and implementations happen all the time to get real-world experience before formalizing standards.)
Personally, I think a standards process that acknowledges flakes as they stand (at least from the DX perspective) and builds on that would benefit us all.