This is okay, but given how many people are using and recommending DetSys installer and especially! GitHub action, there should be a huge warning about it posted somewhere in the official channels, as no one really reads GitHub Actions warnings and a lot of people aren’t reading discourse/DetSys blog
Great point. We have about 3 months to migrate to an alternative action to continue to use nix, or switch to lix.
I‘ll use this opportunity to shamelessly plug my own GitHub action that I think is superior to any other Nix action: GitHub - ners/simply-nix
It builds on top of nixbuild‘s fabulous fast nix install action and adds aggressive space reclaim (which I‘ve hacked together with inspiration from several other actions).
I believe most GitHub projects should be able to drop in either this or the nixbuild action instead of the incumbent ones, and save valuable time and space on CI runs. ![]()
This is very disappointing and not a good move for the community. It was clear the writing was on the wall though when you introduced the fork, then started pushing it into the installer. I hope you’re getting paid well for the moves you’re making, because they’re bad for the community and the ecosystem, regardless of how you market and spin them.
TBH it’s not reasonable to hold DetSys to the double standard of “we don’t want you in the community” and “why aren’t you doing things with the community in mind”. A better position here is that if you’re Anti-DetSys, just don’t use DetSys and improve what you are capable of improving and promote that in your circle. I don’t really feel that at this point, the way the community has treated everyone involved with DetSys (in particular Eelco and Graham), that they owe “the community” anything. It’s surprising to me how positive and supportive they’ve continued to be, despite that, and are continuing to do things that have made an impact (at least for me). That isn’t to say I think everything they touch is gold, mind you
The community wanted them to have less involvement, and this is the outcome, such is the nature of open source.
I don’t personally think it’s a double-standard. They aren’t wanted in the community not because they’re DetSys, but because they don’t play nice, and continue to not play nice. And the sentiment won’t shift if they continue on the same path.
Sure, the sentiment may also be driving them away from engaging with the community, on top of the community not being a source of income, but by and large it’s not as you outlined „we don’t want you in the community” and „why aren’t you doing things with the community in mind”. Quite the opposite — „we don’t want you in the community because you aren’t doing things with the community in mind”
Hm, from where I’m sitting it would seem they’ve only added value to the ecosystem and been supportive, and have made attempts at getting things merged upstream. I get that they haven’t done things the way some people in the community would like and that there are requested changes, but there is really nothing stopping anyone in the community from taking up the mantle of the pull requests they have opened and completing the tasks with their changes in mind. The fact that such pull requests remain open imo is the responsibility of the community, not just the contributor. With such a large organization such as nix/nixos, it’s common that changes can take a long time to land. If we really wanted those changes to land sooner rather than later we could do the work to get them into a state that they are ready. The fact that pull requests were opened at all speaks volumes to me of the effort to continue improving the upstream distribution and remain in good faith, despite the immense amount of work and pressure it is to run a business. The argument that the ecosystem is disrupted because DetSys makes money for trying to improve nix for companies that need it does not ring true for me. It’s a win for everyone when nix gains adoption, improvements and new ideas/implementations. There are many other instances of this, such as Tvix or Lix, and companies which use funding to chart their own vision for nix, such as Flox.
I feel like my comments have come off as overly defensive on DetSys’ behalf, but my hope is that we can move on from assuming bad faith (for all parties, not just DetSys) and get back to enjoying the magic of using nix and building great software.
Also @lucperkins, I wonder if a potential solution could be to fork the installer repo and add it to the nix-community org so that the uninstaller will continue to be available for upstream nix?
I’m gonna go touch some grass now
Wishing you all a very pleasant evening.
As noted in the blog post, that has already been done:
“Determinate Nix” exists because they cannot get their features merged in nixos/nix in time for their customers. Almost every feature that Determinate Nix has, which nixos/nix doesn’t, there exists a PR for it in nixos/nix. I think this is very much uncalled for. Read the following quote, which isn’t unreasonable for me to agree with, and shouldn’t be for you either, unless you can back it up.
Now are the PRs in the state for merging? I’ll leave that to the maintainers of Nix. But then again, Determinate Nix isn’t closed source and the PRs for nixos/nix has the same code that they’re shipping.
I would argue that using nixos/nix gives me better code quality, than using Determinate Nix. ![]()
I’m only tangentially aware of Determinate Nix. How is it different from other derivatives/forks like Lix?
I see Lix is in nixpkgs. Is it intended that Determinate Nix will live in nixpkgs too?
I don’t see profit as a problem in general. Many other nix* contributors do profit from it, I believe that is a good thing.
I’m still a bit worried that over long term the differences between these two Nix implementations will keep growing.
I’ve observed something similar in another project. The commercial actor had specific demands/environment. So they implemented features for those demands, but only for their demands, i.e. the changes weren’t in a good shape for wider use targeted by the original project.
So over time we got into a limbo where no one was interested in adapting these changes to satisfy both of the groups, so it became a permanent fork. (and then they closed-sourced most of it piece by piece over time, I think, but I don’t expect that would happen in case of DetSys)
Is my understanding correct, that Determinate Nix requires Determinate Nixd and that Determinate Nixd still is proprietary software, i.e. it’s not licensed freely and not even “source available”, unless I am mistaken?
If so, I think that’s worth highlighting. I guess that means that users of e.g. the GitHub action would just be “upgraded” to non-free software unless they switch away from it.
Adding non-optional, proprietary components also makes it quite a bit harder to argue, in good faith, that this is merely a “downstream distribution” and not just a fork IMO.
We just need a Forgejo action now ;p, or if anyone else didn’t know their is tangled.sh which CI uses Nix :3.
This really throws the trustworthiness of Determinate Systems and its employees into question. The company exists to serve the Nix community. Dropping support for the main implementation of Nix in favor of a fork that isn’t even fully FOSS is very unsettling.
Wrong! We do not serve “the Nix community.” In fact, I’m not really sure what it would mean to serve “the Nix community” any more than I know what it would mean to serve, say, my country or humanity.
We are a small group of people (9 employees now) who have strong ideas about what we think Nix could and should be, and we got some funding and we’re working hard to make that vision a reality. We don’t wait around for any kind of community consensus—and I’m not sure how one would even go about discerning such a consensus—before we build and do things; we just do them. That said, there are certainly limits to our action. We’re a for-profit company but we’re careful to respect licenses and copyright law and general open source norms and we certainly don’t act with ill intent toward the community, which has given us a lot (and we seek to benefit the community in return, as evinced by contributions that I needn’t belabor here). But beyond that, we actively eschew any kind of modus operandi according to which we ask “the Nix community” what they want—again, not sure what that would mean amongst people who disagree about just about everything—and then provide that. To us, that sounds like a recipe for stagnation and “a faster horse.” Instead, we put forth ideas and tools and platforms and we see how it goes and we gauge the response, and we do so alongside others with different ideas. Smush it all together and see what comes out on top. It’s a lot of fun and, we think, more productive than finding a prior consensus and acting on that. Some people in the Nix community love what we do, others don’t, and I don’t know how any company could build and act with anything resembling boldness while ruffling no feathers whatsoever.
So no, we don’t “exist to serve the Nix community.” To me abstractions like that essentially amount to “you exist to do what I want you to do and you’re not doing it.”
I’m fine with you about doing your own non-community thing. But I’m tired about you advertising releases an changes on the community channels and people with determinate nix specific problems ending up here.