This isn’t exactly true; he is still quite active in the RFC process, many of which involve NixOS and Nixpkgs.
4 Likes
Never said that, nixos/nix here refers to the repo name on GH.
And my concerns are specifically about that one repo. This thread is about nixos/nix and DetSys’ fork(?) of it, not nixos/nixpkgs.
4 Likes
nixos/nix here refers to the repo name on GH.
Ah, ok, that makes sense now.
I totally see where the confusion comes from, though I have problems using the name “CppNix” to refer to the nix project, to avoid confusion with CppNix…
3 Likes
FYI that project was created exclusively and blatantly to cause confusion with the term CppNix because the CppNix team dislikes the practice that tvix first adopted at least two years ago of calling “the nix implementation written in c++” CppNix, which was then adopted by the Lix style guide. Both such uses preceded roberth’s deliberate name collision by months to years, and I do not believe anyone actually intends to use that name collision project in practice; it exists purely either because it’s funny (which it is) or as an argument that the nix implementation written in c++ should not be called CppNix.
Until there’s an unambiguous name for the CppNix project (the nix implementation) chosen by its maintainers, everyone who cares about ambiguity (chiefly people who would like the Holy Trinity of “CppNix is not nixpkgs is not NixOS is not nix language, but is nix” to stop confusing everyone and implying that there will only ever be one Nix implementation) will keep using the most popular term to refer to it.
16 Likes
Let me enumerate the claims you’re making here, setting aside your invective against DetSys.
- DetSys tweeted something that could be considered inconvenient disclosure of a vuln.
- DetSys…
a. …not doing semver for flakes the way you wanted.
b. …selling a product/service for working with/hosting flakes. - DetSys allegedly sabotaging documentation efforts.
- DetSys not disclosing business ties with Anduril with Eelco was head of board (there, filled in the blanks for you, correct me if wrong.)
- DetSys not taking a public position on many cultural issues in the community.
Taking these in turn:
Re: 1, I’d note that there are open efforts to improve the security story in the Nix ecosystem. There is also precedent–the whole debacle with puck–for sloppy disclosure. It’s useful to say “hey, we all need to do better” and it isn’t useful to act like this is a problem for only one actor.
Re: 2, I understand your frustration given your work on Rime for something like a year now. That said, nothing is preventing your solution–or any other similar solution–from winning out in the marketplace. If your issue is simply that they’re charging money, well, unfortunately that ship has sailed in open source for decades now; it turns out that sometimes people need to make rent.
Re: 3, there are plenty of folks that were or are working on “competing” documentation solutions for Nix. Again, calling out DetSys ignores other people (in that very thread you linked) that were similarly acting (under the best of intentions) in ways that caused fragmentation. And again, as before, if there is a better docs solution out there it will win out.
Re: 4, DetSys likely has NDAs with their some portion of their customers. Even without NDAs, many companies are cagey about who they work with. They do not owe you or me or anybody their rolodex. As Nix gets more commercial adoption and we see more industry involvement–which has already happened, is going to keep happening, and I believe for the sake of Nix should not cease happening–we’re going to run into this more and more frequently and as a community we’ll need to navigate that new state of affairs with an open mind and with grace.
Re: 5, DetSys is a business and frankly they probably have better uses for their time than getting involved in internet culture war arguments (for example, shipping a flake service). Further, considering their position, the investment of time to handle these things with the proper care and delicacy–assuming that everybody at the table is acting in good faith, which the various heated discussions in the project spaces, unofficial spaces, and fediverse suggest may not be the case–has a very unclear payoff to them as a business and runs the risk of prolonging drama in the community. Better to leave the arguments to people who have nothing better to do than call each other nazis and marxists.
Everything you mentioned, in short, is some combination of unfortunate or inevitable, and while I see your annoyance it seems to me to boil down mostly to “These people I don’t like for whatever reason did things I don’t agree with in ways I don’t approve of and aren’t functioning with the same logic and exact moral calculus that I do.”
Since you’re somebody running for the steering committee, I think it’d be helpful to recognize that there are other value systems and contributors outside of your natural grouping and preferences, and to realize that you’re going to have to serve the whole community, not just the subset you like most.
10 Likes
Hey look, you found one. (The Nix implementation.)
2 Likes
Not really? There’s at least 4 “nix implementations” I know of prior to detsys’s thing, now it’s 5…
and regarding @crertel you did strawman a bit, their point was that it appeared to be active sabotage, not simply creating a competing product. (I am not personally making that point as I know nothing about the doc team governance.) The other points have been overdone, I won’t even address those…
8 Likes
Only one is named Nix, though. The stated objection was to the ambiguity between the Nix language and the Nix implementation, which is a non-issue because the words ‘language’ and ‘implementation’ are easy to append and resolve the ambiguity entirely, as the problem statement itself demonstrates. Other implementations of the Nix language have all to my knowledge taken new names for themselves, like Determinate Nix (if that even counts as a new implementation).
3 Likes
Nope, there’s now two. And this will continue to cause confusion if the foundation lets the trademark clarity slip. If you don’t see how putting nix in the name of something that isn’t nix causes confusion for people who aren’t embedded in the community yet, I have no idea how to make that clearer.
Also no one calls cppnix “the nix implementation”, that’s far too mouthful and even detsys just calls it nix.
9 Likes
Sure, but disclosing a security issue publicly rather than reporting it to the people who would fix it and giving them time to do so, is a major mistake at best. Especially since to my understanding, this is common cybersecurity practice.
The issue is less that they’re making money and more that they’re intentionally keeping functionality proprietary to reduce competition with the entirely free, open-source version of Nix. There are also still ways for companies to make money off of open-source projects, such as providing commercial support like Canonical does with Ubuntu.
According to the post @cafkafk linked regarding this, the leader of the documentation team deleted the starter templates and not long after, Detsys launched their own documentation site. It is at the very least suspicious. Also could you point out specific examples of people acting “in ways that caused fragmentation” in that thread?
Does that exempt them from disclosing conflicts of interest? I would say DetSys’s ties with Anduril were especially relevant during the sponsorship fiasco, for example.
Correct me if I am wrong, but I think @cafkak was referring to things like sealioning in discussions of diversity measures rather than a “culture war.” Considering how DetSys placed themselves squarely in the center of the Nix community, I think it is a reasonable concern that they remained silent rather than making a statement.
In my humble opinion, denying that there is a problem and blaming the person bringing it up for having a problem with it is not a particularly compelling or productive argument.
10 Likes
That’s a separate issue, and not something I was intending to argue for or against.
Yeah, that’s how language works! You use the long form when disambiguation is needed. In addition to the Nix language and the Nix implementation, there’s the Nix store, the Nix daemon, the Nix REPL, the Nix derivation format, the Nix archive format, and probably a dozen other things that are ‘the Nix _’—we don’t need to give them all unique names, and it’s fine to say ‘Nix’ to refer to any of them if the meaning is clear in context.
3 Likes
Fair, I misunderstood that.
If the discussion is the DSL vs impl, then I think it will continue to be confusing along that axis until nix the language and nix the impl themselves change names to disambiguate. AFAIK all official material calls both “nix” without qualifier, so those intending to disambiguate must choose an arbitrary/imperfect term for the canonical impl.
If it was that clear then we wouldn’t need a term to disambiguate in the first place. AFAICT this comes down to your personal preference against “cppnix” as a term. I think that topic’s also been overwrought, elsewhere.
(And I think this is pretty far offtopic now, yeah?)
4 Likes
Since I happen to have been doing the pointing-out in the past: The reason why I didn’t get to that yet is that I’m trying to get a few days offline at the moment, and I also only learn about such things as they get published.
While the foundation board did not yet manage to register a trademark or establish a policy, there’s a draft that I think is good enough as a stopgap. Even without legal leverage, collectively we should be able to clearly sanction inappropriate use of the name and visual identity.
In this case, in my humble opinion, calling something “Determinate Nix” is not enough of a distinction from the original project. What I find especially problematic is that, in the latest article on the website at the time of writing, some links labeled with just “Nix” point to the “Determinate Nix” page, and that it’s not clear whether the “Determinate Nix Installer” installs the original Nix or “Determinate Nix”. The heading says “Install Nix” but the command line example sets the --determinate flag. This to me clearly violates the requirement to avoid misleading the audience.
A more distinctive name, at the very least one that does not contain “Nix” as a standalone word, unambiguous communication what the installer installs, and not conflating the Determinate Systems distribution with upstream Nix in the wording and link labels would fix the issue. (By the way, I appreciate that you eventually adapted the wording where you recommended using flakes and the experimental CLI.)
I can’t observe any sort of special treatment, to be honest. Of what sort would that be, and by whom?
As noted by @ron in the other thread, Eelco is still making payments on behalf of the foundation, which is crucial for operating things such as Summer of Nix. Transition of responsibilities is happening, however slowly, and I didn’t notice any other involvement.
But all that is off topic. Because apart from the issues with branding, I think it’s actually great news that there’s yet another product that fills the needs of people who strike different trade-offs than many of us here. I’m confident this has the potential for a win-win situation, as long as we don’t confuse or mislead our audiences and make sure upstream is healthy.
I discussed this with @grahamc at the past two NixCons.
I’ve been advocating for a clear split between what’s libre and what’s proprietary, because the needs and abilities of the different groups of producers and consumers of software are so different.
Proprietary additions do not need to take away from upstream, to the contrary: They can provide a source of income for authors, and absorb a chunk of feature requests that wouldn’t fit upstream anyway; independent groups can also move more quickly and explore the solution space to common problems. Conversely, upstream can focus on stability and standardisation; it’s a very different kind of work that also needs to be done, and it can mesh nicely if we’re deliberate about it.
More special-purpose products downstream and less ambitious expectations to what upstream can (or should) provide would be a relief for maintainers and allow us to focus on substance rather than presentation.
I’d love to see Nix become more of a “library” (minimal, composable building blocks that aim for maximal control), and downstream distributors providing “frameworks” (battries-included scaffolds for gluing together domain-specific solutions that aim for maximal velocity). I’m fine with Nix being “boring” in the sense that it’s a tool for creators rather than an application for users (who may actually care about something else entirely). I’d even go as far as saying that if Determinate Systems buys into flakes so much that they’re willing to guarantee stability, and they and their users are fine with the trade-offs involved, it may as well be a downstream-only feature.
All we need for a more than just peaceful coexistence of different actors in the ecosystem are strong lines of communication. So I think it’s just right that we all keep talking to each other, here or wherever.
21 Likes
Sure, they don’t necessarily need to, but in practice, how could you ensure that? It seems like it opens an opportunity for perverse incentives. If a feature’s enticing enough, it will draw people in and if it’s proprietary, then it would be easy for DetSys to lock people into their version, intentionally or not.
Regarding authors making a source of income, there are other ways companies have used open source to accomplish it, such as providing professional support, to name an example.
If you want to experiment with additions to Nix without upstreaming it, would the resulting fork strictly have to be proprietary? Why not maintain a fork while keeping it open source and just not make an upstream PR? I doubt Lix and Tvix necessarily plan on upstreaming their changes, for instance.
That sounds like a somewhat okay idea on its surface. However, I can’t help but suspect that Determinate Nix would suddenly be declared the reference implementation for such a tool if that were to pass. Could you (or someone else) perhaps alleviate these suspicions?
I would say stripping a very popular and useful feature from Nix and privatizing it is already a huge trade-off. What would the benefits of such a move even be? For people other than DetSys, specifically.
I think I am missing something. What problem is this solving? You mentioned it would make it clear to Nix’s users about the status of flakes, but I do not see how breaking tons of downstream users by removing a widely-used feature and giving control of its further development to a for-profit company is a good way to do that.
3 Likes
The problem is all of the would-be Nix users who don’t try it. So many are not trying it because they want to use the hugely popular feature of flakes. But they’re so spooked by the status of flakes they don’t want to risk it. And It is hard to blame them, when a literal Nix Team member occasionally suggests Nix should remove flakes altogether, breaking tons of downstream users, and cause ecosystem fragmentation by putting them in a downstream-only version of Nix.
Like I said before, I don’t want that! I think Nix should remove the experimental flag! But the status quo is also really bad.
@grahamc You haven’t reacted to the problem of the naming collision between nix and determinate nix. What are your plans to solve this?
11 Likes
Hey Graham,
Since this is a declaration of terror against the community version of Nix, I think some words need to be said.
Determinate Nix is not a fork of Nix—it is a downstream Nix distribution.
We will continue to add new features to Determinate Nix to make the Nix user experience ever smoother for teams. These include better authentication support for flakes and binary caches, flake schemas, parallel evaluation, and much more.
This is classic gaslighthing - a manipulation technique meant to confuse readers and prevent them from fully understanding what’s happening.
Let me rephrase it for you:
We, DetSys, are going to develop things in our fork and if the upstream OSS doesn’t accept these changes, we’re going to diverge from this fork and claim ours is better.
Since Eelco Dolstra is complicit in this and we have tried to convince him to rather work for the NixOS Foundation, I must say I’m disappointed, but not surprised.
I have seen this coming ever since you sponsored your installer over the official installer using ads in Feb 2023:
In recent years we got Lix and Tvix due to a lack of leadership and people from Nix Core team have resigned from working on Nix.
Splitting the community over who develops Nix and pushing for stabilization of flakes without addressing the downsides is not leadership; it’s divisive. We have usually normalized banning people which such behavior.
Finally, this not only fails to create a safe environment for community members but also affects companies like Cachix, which I founded long before Eelco became involved in moving this into the commercial space.
I won’t be contributing to Nix anymore and will put my efforts into Tvix, where I have confidence this kind of behavior won’t be tolerated.
All the best, Domen
34 Likes
I’ve looked at some trademark policies I know in the opensource software world and came across Sublicense the Linux Mark | Linux Foundation
If we imagine that we would follow that, Determinate Nix Package Manager would be an acceptable name.