I really can’t stand the way Graham acts in this. He’s acting as though he’s being truly honest and opening, but is only responding to comments that allow him to market their products. There are many great replies to him asking real questions that he refuses to answer.
Two examples that he really should respond to; https://discourse.nixos.org/t/determinate-nix-3-0/61202/122 https://discourse.nixos.org/t/determinate-nix-3-0/61202/125
Edit: This reply is a good summary of the issues and actions that have occurred for anyone who doesnt want to read the whole thread https://discourse.nixos.org/t/determinate-nix-3-0/61202/224
The Nix project has long intended to release version 3.0 when flakes 4 are stable. With Determinate Nix 3.0, we’ve fulfilled that promise
i noticed this language recently as well. i’m glad Nix upstream is defending themselves, but honestly, the place where Nix “3rd party” tooling shines is in documentation. i swear to god the #1 things holding back Nix adoption is piss poor documentation. and i love the idea of Nix to be clear, but if the official docs are years out of date for installing popular user space software like CUDA and the Rust toolchain, for which the docs are either far out of date or using solutions that are not standard or otherwise clunky, then it’s silly to recommend for my work. and also to be clear, i could pull string and make this happen at my company—we’ve done it for Rust—, but i will not stick my neck out for this kind of tribalism.
on one hand tho, Determinate Systems provided clear install instructions for flakes (which is an important feature, for a lot of maintainers for sure) and did make it clear what the differences were (some of which were clearly better defaults), even if the verbiage is a bit aggressive. i honestly don’t know what it will take. i’m slowly but surely becoming competent in the ecosystem, but i get the vibe from forum posts (which i’m forced to read in lieu of docs) that there’s this “why don’t you already get this” from the already established community. and maintainers act like there’s no reason for these “soft forks” to exist. Nix is not straightforward, and, no, the language isn’t simple enough to learn in an hour. adoption requires good docs
#1 things holding back Nix adoption is piss poor documentation
The docs are bad because there is this massive split between flakes and nonflakes , where flakes are considered “unstable” and “experimental” but a ton of people use them. The official docs, due to flakes being experimental, can’t really touch on that topic at all, and the unofficial docs will mostly be flakes only. And some things can only be done via flakes or only via channels, so that furthers the issue.
There was another discourse post about it, and it was agreed that the nix team just needs to choose something, as the problem is the split and indecisivice, rather than flakss or channels (old way) being uniquely bad.
where Nix “3rd party” tooling shines is in documentation
Determinate systems nix ships with flakes enabled by default. Official nix does not. This means thay determinate nix has a much easier time documenting their product as they exclusively use flakes.
The problem and potential conflict of interest documented in that thread, is that many of the determinate systems employees are big nix contributors with much power over nix official — including Eelco Dostra, the inventor of nix and the creator of flakes. Despite clearly doing recent work with flakes, and clearly contributing to making flakes the “default” in determinate nix, very little effort has been put into making flakes official by these same contributors.
The fear is that nix official is being intentionally kept bad, in order to push the product of determinate systems nix.
The fear is that nix official is being intentionally kept bad, in order to push the product of determinate systems nix.
Part of the reason why a lot of people are moving to projects like Lix, including increasing use amongst core contributors
i worked in Android development for years. i used Kotlin and Jetpack Compose in alpha. their docs weren’t perfect but they existed. in my experience good documentation evolves with the project and isn’t tacked on as an afterthought.
otherwise i get you point and really don’t know enough about the drama to pick a side. i just want my software to work 🤷♂️
ETA: honestly documentation as a first class primitive in Nix is a selling point. if only that consistency could be applied to high level docs
but honestly, the place where Nix “3rd party” tooling shines is in documentation.
totally amazing what can be done with millions of dollars in VC money, huh?
Flakes aren’t documented well because they aren’t stable. The actions of Detsys to push flakes as stable are hurting the feature in the long run. It shouldn’t be a problem to break an experimental feature. Now many people and organizations are depending on Flakes, and flaws they have are much harder to fix.
Dunno how much more drama nixos will need to have a substantial amount of people just move to a fork. Aux exists, but I think it’s dead. It could be revived if more people joined though.
I’m hoping NixOS figures out these inevitable growing pains. The problem they’re having has a ton to do with flakes and Eelco not wanting to accept the community’s pushback on this feature. So, he implemented the feature in his “upstream” project.
I use it all the time but I’m told it is unstable.