You’ve figured it out 
4 Likes
My bad. I’ve said elsewhere that the ideal set of patches in Determinate Nix is zero, because maintaining a divergent set is no fun.
13 Likes
I’d like to try to summarize why this thread, and other products by Determinate Systems (like Flakehub) make people upset, while maintaining a good defense for Determinate Systems (DS).
It seems like the business model of DS is to take Nix, which has started as a PHD project, and is widely used by the community, and ship it to costumers along with business-class stability, along with also features not yet merged in github.com/nixos/nix, and with business-class support.
A good example of a GNU/Linux distribution that uses such a model is SUSE (and openSUSE), and I personally think it is a perfectly legitimate business model and I think many people would have liked to use a GNU/Linux distribution that is developed and maintained by paid programmers, and that the company of it is making profit which ensures the build servers etc will stay active in the far future.
However, with Nix and with DS, it is not clear exactly what is the business model and how is this aligned with the community model. For example: Who is paying the people with merge permissions to github.com/NixOS/nix? And in the companies that employs them, how is their role with regards to github.com/NixOS/nix is defined? And on the more developmental side: What are the procedures for a new feature and or a bug fix to get into github.com/NixOS/nix? Who decides what new features to stabilize and not? How is this decision making influenced by the business models of the employers of the github.com/NixOS/nix committers?
I think it is very unfaithful to be so avoidant of determining (no pun intended) which Nix features are in which stage of stabilization, and how does DS expects the development of their product to contribute back to github.com/NixOS/nix and hence the rest of the community.1
1: There could be more companies that are shipping Nix based products, and that their developers and founders intersect with committers to github.com/NixOS/nix, but I don’t know any.
33 Likes
we got det nix 3 before nix 3
11 Likes
I know arguing with determinate systems is impossible, because they unironically gaslight you, as others have pointed out before…
So I’d just like to say that I think this sucks. You can’t argue with that.
I. Think. This. Sucks.
I really can’t wait to jump ship to whatever comes next after this distro sinks itself. Hopefully we won’t repeat the mistakes we made here.
28 Likes
At least we have lix now: https://lix.systems
22 Likes
Every time Determinate make an announcement and re-ignites this discussion, I keep wondering: what is the future of orig Nix? And how can we resolve this conflict in a way that won’t make it flame up again three times a year?
Currently, the original Nix project is being torn apart between two forks—one hostile, one angry. More specifically, the issue I see is that it has unhealthy overlap with Determinate Nix, causing conflicts of interest in development resources and project direction. The solutions I see are either for one to be subsumed in the other to become a coherent whole again, or a clean cut separation of both projects, allowing orig Nix to go truly independent ways again.
When I say unhealthy overlap with Determinate Nix, one key aspect of that is that Eelco is still orig Nix team member while also working on Determinate Nix. This is an intolerable conflict of interest to me. Making a clear cut between both projects means to pick a side, to pick a project. Given that asking someone to leave their employer is unreasonable, I therefore ask that Eelco leaves the orig Nix team instead.
On the Determinate side, I kindly ask you to stop taking us for fools, to stop the silly “distro” gaslighting pretense, and to fully commit to a true fork (even if it’s a soft fork synced with orig Nix). The ideal number of patches is only zero when both projects are fully aligned, which they clearly aren’t anymore at this point. Please stop trying to shove your vision of Nix down everyone’s throat through the backdoor.
65 Likes
Uhh, so lazy trees and multi eval in NixOS/nix when?? Maybe a stupid question but it sounds weird that as of now these are features that only enterprise customers get…
10 Likes
There’s an interesting parallel in the Drupal CMS community.
Dries Buytaert (I salute you dear compatriot!), Drupal’s original author, founded a US company (Acquia) that sells services around Drupal. However, every single improvement developed by Acquia is integrated directly the official Drupal project, rather than maintaining a separate internal fork (and bragging about it). Acquia employees contribute exclusively upstream, eliminating the burden of maintaining their own version.
As far as I’m aware, this model has effectively prevented friction from arising in the Drupal community, and this situation is profitable for both parties. It might be worth exploring whether a similar approach could resolve our conflict here in a durable way.
[…] As a constructive alternative to the current tension, I’d suggest clearly committing either to a full fork or, preferably, to ensuring all improvements and developments are consistently contributed directly upstream into the official NixOS/nix codebase.
31 Likes
we build it ourselves from source in our secure, SLSA build level 3, controlled infrastructure
I’m happy to see more focus on provenance in Nix. Provenance is currently completely lacking in hydra.nixos.org and cache.nixos.org and we could do much better here.
Also it’s correct to say that a build artifact is SLSA build level 3, but it’s kind of meaningless to call infrastructure SLSA build level 3. SLSA unfortunately does little in asserting the correctness of build infrastructure except for some self-attestation saying that you should check that your build infrastructure is “Secure” but no standardised way into proving it is secure/(SLSA • Verifying build platforms).
There’s a build environment track that concerns with build infrastructure though which wants to assure things like build environment attestation but it’s still draft SLSA • Build Environment track
I think Nix can have an interesting role in these kind of things though but there’s a lot of room for improvement.
https://www.youtube.com/watch?v=UlJUpUQc9Lc was an excellent talk at NixCon about how we could empower Nix to not only prove Build provenance but also builder provenance**.
** Today even build provenance in nix is basically not existent. As our binary cache doesn’t sign over the deriver we don’t have any non-forgeable information on how an output path was produced. Which makes it kind of hard to reach any SLSA level with just plain Nix. What guarantees do signatures by binary caches give? - #13 by arianvp
Edit:
There’s a PR from Eelco to add (at this point unsigned) provenance info of store paths in the sqlite database. That’s useful Store path provenance tracking by edolstra · Pull Request #11749 · NixOS/nix · GitHub
23 Likes
As a Nix team member, I do feel betrayed.
Eelco doesn’t talk about these things, ever.
Two weeks ago I asked about his Planet Nix talk
iirc you’ll be presenting about configurable flakes at Planet Nix. Could we have a peek and give feedback?
Said he would, never heard back. Massive topic, huge impact on UX. Nothing.
Whatever Eelco says and does, you have to assume it is merely his own opinion.
We’ve tried to fix that with the Nix team, and we were “on track”, accepting more contributions, working with Eelco in a respectful manner, but he has still managed to cause division and fragmentation.
Today I find myself on the demonized end of an unnecessary divide. Those who took a different approach, I used to blame more for failing to collaborate, but now I blame them equally.
I guess that’s progress.
I didn’t sign up for this (just tried to help), but here I am talking about blame. It’s sad, but nonetheless I’m still hopeful that we can keep working together as a community.
101 Likes
Maybe Eelco should resign from the Nix team as well, seeing as he has a massive conflict of interest and has shown time and time again he can’t overcome the biases that come with it.
9 Likes
There is a major point of confusion for me: in the community version of Nix, lazy tree or lazy path, as almost the last step of flake stabilization, are considered extremely unstable, and they are not even included as testing features. However, Determinate Nix, as a commercially supported product, pushes them to consumers. How is this possible?
31 Likes
Automatic certificate handling for ZScaler … and other security platforms.
That’s welcomed news since work forces ZScaler on us.
We provide full MDM integration, including partnerships with leading MDM providers like jamf, and ensure seamless macOS upgrades across your Apple ecosystem.
2 Likes
Look at how many big PRs that Eelco has in draft status in perpetually it seems, and now this blog post is saying that they’re going to be stabilized in their fork of Nix (let’s call a spade a spade here).
https://github.com/NixOS/nix/pulls/edolstra
Now look at the active branches in DetSys fork of Nix:
There are flake-schemas, configurable-flakes, and more. DetSys in my opinion, is trying to commercialize Nix and make these features exclusive to their distribution of Nix or at least make the full version of these features exclusive to their version of Nix. It also appears, to me, that Eelco is making all of these PRs and leaving them in an unfinished state. Not bringing them to completion so they can promise to stabilize them in their DetSys version of Nix and make it a more attractive option to companies.
How is this not a conflict of interest?
EDIT: Regarding naming, I have seen people confused thinking this was Nix 3.0 when it’s not.
EDIT 2: Also upstream tracking for the “not a fork” version of Nix: Upstream tracking by edolstra · Pull Request #4 · DeterminateSystems/nix-src · GitHub
18 Likes
I decided to look into whether this would be a violation of the Nix trademark policy. Instead I found Agree on a trademark policy · Issue #36 · NixOS/foundation · GitHub which suggests that there isn’t one. Perhaps this is something that the new Foundation board should be looking into?
Companies and commercial projects should not use Nix or NixOS in their names or branding.
Interesting that this was predicted two years ago.
16 Likes
I wonder who was the chair of the foundation at the time.
6 Likes
It is perhaps the most significant step, although I would consider Reuse input lock files · Issue #7730 · NixOS/nix · GitHub to be essential, and the legacy flat lock to be undesirable to keep support around in perpetuity.
Other desirable changes can probably be done in an incremental way, but forgive me if I overlook something.
We do need to distinguish between two kinds of stability. This is somewhat unique to Nix.
- Design stability: which behaviors can we commit to? Nix should keep producing the same derivation hashes and output hashes over time, as part of its reproducibility promise. This makes “stabilized” behaviors rather permanent, which is a huge risk for an underfunded(??) project.
- Operational stability: does it crash? bugs?
We have problems in both areas. They are orthogonal but correlated problems, as fixes to operational stability may expose problems in the design.
As a brief example, we’ve had a case recently where users were using flake inputs to fetch submodules. This is completely unnecessary since 2.26, and it only worked for them because their working directory happened to coincide with the flake root. Sensitivity to the working directory instead of base directory is bug, so here you see an interaction between the two kinds of stability that we discussed.
If we had committed to the 2.25 behavior of flakes by blessing it as stable, we would have to implement a completely unnecessary feature which would even require some architectural changes, removing the separation between fetchTree and the base directory concept, forever making call-flake.nix and the native code that interacts with it more complicated.
Indeed if Determinate were to keep compatible with such a misfeature, we should not accept it upstream.
We have reached contradiction. Q.e.d. I guess. Determinate Nix will have to diverge.
Furthermore they’ve painted themselves into a corner, because they’ve just made part of the community disagree with their approach to stabilization.
41 Likes
These were created without community input, without complying with the roadmap we had at the time (prioritizing the CLI), and they’ve seen little community engagement because of that.
If anyone wishes to contribute a large feature to any collaborative project, they would be wise to talk to the team. Eelco had every opportunity to do so, but decided to operate alone.
32 Likes
Imagine you are on the Nix team and you believe flakes are ready for prime time. You want them to be stabilized, but you know that not the entire community agrees on this. You believe your Nix-driven business would benefit from being able to recommend flakes to your customers. You have three options:
- Wait ∞ years for the community to agree, and too bad for your customers (and therefore your revenue). You are then the target of internet outrage—terrible leadership! Nothing ever gets finished! Nix stagnates while forks thrive! Let’s all jump ship because Nix is ‘cooked’!
- Use your power as a member of the Nix team to stabilize flakes. You are then the target of internet outrage—how dare you! This is a community project! Your profits don’t override the interests of the community! Conflict of interest!
- Leave decisions about what to do in Nix to the community, but ship flakes for your customers in a fork. You are then the target of internet outrage—how dare you! Why do your customers get stable flakes but the community doesn’t? You can’t be on the maintenance teams of two distinct flavors of Nix—resign at once!
This part of the argument is just so silly. DNix is open source! If you want stable flakes, what stops you from using DNix? If you don’t, you still have Nix! If there are PRs you want merged, add them as patches and distribute the resulting binary however you please! The LGPL permits it! Compiling Nix takes a few minutes! Why is this so outrageous?
From where I sit (as someone who thinks flakes are not ready for prime time and would be quite happy to see all the flake evangelists leave Nix free to redesign them in breaking ways), everyone in this conversation should be trying to have a conversation about control. DetSys wants the ability to self-determine what capabilities they give to their customers, without the fear of the new Steering Council somehow coming in and pulling the rug out from under them. The natural response to that sort of fear is an independent fork—though of course it’s to their advantage to keep that fork as soft as possible, to maximize the benefits from network effects. The community is reacting to their own fears that control of Nix has been or will be stolen from them by a commercial entity, and is responding with all of this 
.
I think an optimal outcome here would look like the SC stepping in and filling the leadership vacuum. Work with the Foundation to make a trademark policy and enforce it—of course DetSys is not incentivized to rename their fork of their own free will, and demonizing them for being a business and responding to incentives like a business does is all just so much hot air; if you want change, change the incentives. Fix the RFC process or come up with an alternative procedure for deciding questions on which the community has been divided for a long time. Anything else, from anyone else, is a waste of our time and attention.
44 Likes