I don’t know how you can call this “not a fork of Nix”. Even if it is a soft fork that keeps tracking upstream changes like Forgejo was back in the day, call it what it is at least.
Are these just written to maximally flame the community at large now?
I mean seriously, come on…
The Nix project has long intended to release version 3.0 when flakes are stable. With Determinate Nix 3.0, we’ve fulfilled that promise
…
Not a fork, a future-proof foundation
Uh… why not build in foundation into Nix itself?
Building a better Nix
… than the nix team themselves (of whom you employ several?)
By maintaining our distribution, we can innovate at the pace our customers need without being constrained by upstream development cycles
Right. Upstream is the problem here
While flakes remain experimental in upstream Nix, we provide a formal stability guarantee to ensure your workflows remain functional.
I mean… really?
Yikes, I mean… yikes.
Most of the 371/340 you see there are because we’re based on top of 2.26, instead of upstream master. If you check out the 2.26-maintenance branch on upstream, you’ll see a similar difference: GitHub - NixOS/nix at 2.26-maintenance
We’ve also opened a draft tracking PR, which makes it easier to see the set of changes we have: Upstream tracking by edolstra · Pull Request #4 · DeterminateSystems/nix-src · GitHub
how else will you convince companies to pay for nixcpp without crippling upstream?
Great to see that you consider lazy trees and parallel eval as stable. Does it mean these could land in upstream soon?
We’re not quite ready to say stable, but we will be making them available to users in the very near future! Then after a period of customer exposure, marking them as stable.
They’ve been sitting as PRs for a long time upstream. I’m optimistic that by putting them in front of more users, we’ll get more feedback and operational experience faster.
I’ve been putting in some work towards making nix adoption practical in the robotics/ros ecosystem recently. This update diminishes my confidence that nix (the lgpl licensed project) with flakes will remain stable and actively developed for the next decade+. Specifically, I am concerned that the differing processes of stabilization and adding features between cppnix and determinant systems’ fork will lead to a split ecosystem, especially since the downstream fork seems to be adding features that aren’t in the upstream. I don’t want to tell an entire developer community to depend on an open core technology, or one that has a hazy future.
Hi Graham,
I love NixOS, and I manage my three home systems—my laptop, desktop, and a small home lab/NAS—with my flake.
Does Determinate Nix add anything relevant to my straightforward setup, or is it, as the article explains, tailored for companies with specific needs?
FWIW, having a vendor say “here’s our snapshot of the technology, you can pay us and we’ll give you stability, also we have some nice-to-haves that for whatever reason aren’t feasible in upstream” is a time-honored way of helping industry adoption.
I think that’s the wrong idea. You market Determinate Nix as a preferred build of Nix. You don’t market it as a beta test field. So creating features in your distribution that are not acceptable upstream is disingenuous. It shows that Determinate Nix is your product, not what the rest of us want it to be. I’m really worried about you folks.
Sure! Determinate Nix’s upcoming parallel evaluation, and the managed garbage collection for example. Other aspects may be less interesting / less motivating, especially when it comes to FlakeHub, like private/personal binary caches automatically integrated with GitHub actions workflows, pull based deployments, etc.
I’d totally blame the nix project lead for that!
Can you explain what this actually is? All I’ve seen so far is that it sounds a lot like something upstream Nix is already capable of.
Nix can do that. Determinate Nix does do it.
It can cynically be seen as keeping a cron job to run the GC on macOS (and non NixOS in general) as an enterprise feature by virtue of the stock packaging not shipping such a thing. That’s my understanding of it at least, a cron job with nice management.
Personally I would love if more energy would be put into the default UX of nix but at the moment the shell script installer reigns supreme in a way that looks exceptionally bad for the project, when the better packaging is developed by the employer of the project lead and sold as an enterprise feature.
These things do cost a lot of money to develop, and suck to test (and indeed it’s not like the Lix installer isn’t undermaintained either!), so I’m not saying it’s not reasonable to sell some packaging, just, it looks bad for the project lead to be employed doing so while the default packaging is as poor as it is.
I really want to assume good faith here, but I’m struggling with the obvious conflict of interests the Determinate Systems team has. How can I trust that your team, which also helps set priorities for Nix, is not holding back on features for Nix in favor of shipping them in your fork? I get that it’s easier to avoid dealing with “upstream” but when it’s literally some of the same people, don’t you think it sends a bad signal to blame upstream? I also note you didn’t say “it’ll help us gain evidence for eventually upstreaming” but instead you only say it’ll help you with operational experience.
If you want to move on and do your own thing, then I encourage you to do so. While I share concerns about fragmentation in the ecosystem, unfortunately between your fork and Lix that’s already a reality. I suspect that many people here wouldn’t necessarily be interested in a version of Nix marketed towards enterprises, but what really bothers them is the ethical concerns raised by the current status quo.
Very explicitly assuming as much good faith here as possible, I note that a commercial distribution with paid support can potentially try out some of those features sooner, precisely because there is paid support to deal with all the late loose ends that are required for stabilisation.
If detsys want to use their customers as paying beta-testers, that’s their prerogative, and their problem if customer expectations from marketing are different.
I absolutely agree that companies being able to pay for vendor support for nix is good for adoption, and that this is overall good for the nix ecosystem. My main concern is that determinate systems isn’t offering nix support to companies, they’re offering support for their own downstream fork of nix. Since top down decisions are being made around this fork, it seems like it has potential to split the ecosystem between the nix version corporations use and the foss nix that the community uses, which I believe would be a very bad thing.
I wouldn’t have any problem with this announcement if determinant systems was acting like redhat and providing corporate support for free software, rather than competing with its own community upstream.
Edit: adding some more context I feel is important
The robotics ecosystem consists of a mix of corporations, hobbyists, and researchers. Nix adoption wouldn’t be practical if one group used determinant nix while the others used lix or cppnix, especially if they diverge in approaches to flakes/version pinning, or language syntax. I believe a fork between enterprise and personal/research usage here would be very detrimental to any ecosystems trying to/considering adopting nix.
Wow, I wonder who employs them… oh, wait.