https://search.nixos.org/options?query=nix.gc.automatic exists(there is a nix-darwin option as well), so I fail to see this as the case.
That performs garbage collection on a fixed schedule. Ours monitors your disk space over timr and responds to changes therein: Determinate documentation.
So it sounds like at the moment, 'Determinate Nixd` essentially does two things on non-NixOS, using macOS as an example:
- some nice Nix management stuff that I currently do with Nix-Darwin
- configures something to run the Nix garbage collector automatically with sensible defaults
- exports CAs from the macOS system Keychain and puts that in a CA bundle that Nix (and some packages from Nixpkgs?) will use
- probably mostly for helping unbreak the usual damage of (intercepting, ‘transparent’, whatever) SSL proxies that are common for large enterprises?
- (I did this manually, and it was a PITA to figure out)
- some session management stuff for integration with FlakeHub
So is this the general picture then? Upstreamable stuff like the upcoming parallel evaluator will, like the DetSys installer, ‘run ahead’ of mainline Nix but (generally? always?) aim to land in Nix eventually. On the other hand, stuff that doesn’t belong in Nix— whether because it’s not one of Nix’s core concerns, like one might argue about the extra service that runs the garbage collector or because it’s all about integrating with some DetSys service/platform— will live in supplemental, proprietary codebases like Determinate Nixd?
(I hope so! That approach makes sense to me.)
This is awesome! Especially for getting a NixOS-like experience of using Nix on Darwin and other Linux distributions. Thank you!
Maybe I’m reading too much into this, I haven’t had my morning coffee after all, but it sounds like Determinate Systems is basically announcing Nix (CppNix) going open core.
It’s baffling to read a statement by the maker of Nix, stating how many flaws Nix has, and how it will be fixed by their new proprietary offering.
I think Determinate Systems, and maybe mostly edolstra, owes the community an explanation as to how this is not basically announcing Nix (CppNix) going open core, or, if that’s the case, that people affiliated with Determinate steps down from relevant boards, committees, steering groups, etc., to make it crystral clear that Determinate Systems cannot act as a gatekeeper of features of Nix (CppNix).
Edit: Determinate Systems is of course more than welcome to make a living on Nix, but clear lines have to be drawn to make it clear that open source Nix (NixCpp) development is not limited by a corporate entity that has financial reasons to avoid certain features going into mainline Nix (CppNix).
I think it’s problematic that NixCpp is now essentially open core, I wish you had found more palatable ways to make money. It also scares me that DetSys twitter releasing security vulnerabilities in advance of proper channels isn’t just a major oopsie but one of many actions DetSys have been taking to deligitimize the open source Nix efforts.
This includes:
- sabotaging documentation efforts
- not implementing semver on flake inputs but turning it into a closed source platform
- not disclosing business ties with controversial sponsors when having employees as the head of the board
- staying silent on many cultural issues that people like graham would have previously championed, likely purely to avoid the potential for bad PR hurting profits
I put eza on flakehub soon after it was announced, I’ve given you plenty of good faith (I even made you aware that it was problematic that you didn’t have a way to dispatch the flakehub publish CI action).
To be blunt DetSys is an extremely bad and hostile open source citizen in our ecosystem, and I’ll be glad to see the day that you make your final departure from the project, any historical contributions aside. You can make money in tasteful ways, many other veteran contributors do so.
This post was flagged by the community and is temporarily hidden.
Congratulations on your new project, just in time for the NixCon! While it’s not something I plan to use personally or advertise around me, I genuinely hope it brings you success.
That said, I can’t help but feel that the direction you’re taking might be a mistake. I understand that the primary goal may most probably be financial, but by developing a closed-source solution to address gaps in the open-source Nix ecosystem, you could be undermining your own efforts in the long run. You are working with people who have been deeply involved in open source, and specifically with this project, for over 20 years. This makes the decision even more surprising… it feels like shooting yourself in the foot and ultimately counterproductive.
You’re promoting this product in a way that seems to overlook what’s already achievable in the open-source version, and it comes across as disingenuous.
Question: Is your next step to fork nixpkgs
and name it something else?
Will this not further bifurcate an already confusing eco-system?
I don’t think the name will do anyone any favors; is upstream Nix now indeterminate?
What is and is not in-scope? As your target is enterprise, what are your plans for isolated networks, if any?
How is this different from min-free
and max-free
? Will those get removed in the future? Are you going to break open source nix?
Does DetSys take Nix open core?
While I understand where the “open core” reading is coming from, I should also say that the Determinate documentation is saying this:
At the moment, the Nix in Determinate Nix matches the upstream version. In the future, however, Determinate Nix will include patches that have not yet been released by the upstream project.
I think you can read that in two ways. The charitable reading would be that DetSys will introduce things into Determinate Nix which will be up-streamed later. The uncharitable reading would be that DetSys will never up-stream these changes and they remain proprietary add-ons to their new product.
But unless you jump to the uncharitable reading immediately, it is not necessary to conclude that going “open core” with Nix is the aim here.
Did Eelco do a stepping back up in the shadows?
Did anyone ever ask themselves how the NixOS Foundation should, purely from a legal perspective, continue to operate as a legal entity with nobody on there? I mean it’s not just Eelco. We had a lot of stepping down lately. So it’s also all the others except Ron. And Ron is in the US. The foundation is a legal entity in the Netherlands.
Someone has to put a stamp on things to pay the bills. The stuff that Eelco appears to have done lately and that was posted here is just that.
Again, charitable reading would be: the whole thing will be decided / reorganized / updated officially once the elections are through and we have an actual governing body.
If we may take semantic versioning as an example of a feature offered by DetSys’s SaaS platform, have we seen efforts to upstream such functionality
I will not argue that the way flakes have been handled since their inception was great - many parties being involved here, though not me - nor will I argue that flakehub is the best solution under the sun.
But these are a bit different topics in my opinion. The new Determinate Nix is neither flakehub nor flakes. It’s a different product. And from what I can see, it’s based off of the Nix daemon. But it’s not announced as a fork, rather a distribution that will include some patches relevant for DetSys’s enterprise customers.
And, again, the most chartiable reading of all this is that DetSys is trying to provide an answer to a genuine problem: Make Nix more streamlined for the enterprise needs they are trying to serve as a company and be able to react fast if additional features require changes in the code base, all the while continuing to try and upstream at least the better part of these additions.
There’s also the empirical observation that neither was the detsys installer upstreamed nor flakehub opensourced so far. One could be inclined to interpret that as an indicator in which direction this journey goes.
Steps in that direction have been taken by the installer working group, including forking the repo into the NixOS org: GitHub - NixOS/experimental-nix-installer: An experimental fork of the Determinate Nix Installer to explore upstreaming.. Ultimately, it’s the decision of the community.
At least from the outside it looks like those steps were undertaken by people who are not known to me as detsys employees (except for grahams README update)? Maybe you could elaborate a bit on what forms of material support to these efforts detsys provides?
Also curious to read what “steps in that directions” are there regarding flakehub/semver, if any?
Cheers, and thanks for all your work
So, min-free
/max-free
, which is also configurable in nix itself?
https://nix.dev/manual/nix/2.18/command-ref/conf-file#conf-min-free
Thank for you replying.
If Determinate Systems could ensure a patch would go into NixCpp, they might as well just put it there in the first place. If they can’t, then they can’t guarantee that their patches to their NixCpp-distribution will ever make it into upstream NixCpp either.
This will most likely only cause more fragmentation.
Github provides a nice UI that allows to check the work done on the NixOS community fork of the installer. According to it, the only DetSys commit to the repo was a README fix by Graham. Maybe they helped make sense of the existing code - but it doesn’t look like DetSys put much effort into upstreaming the installer.
Not to mention the fact that there’s no need to do that to begin with. DetSys installer is already on the front page of nixos.org, it is the more known installer, and it supports both CppNix installation and DetSys Nix installation. There’s not much to actually fork and change - just changing the branding and removing DetSys Nix code paths, mostly.
For disclosure, the reason I know that is in the past few weeks, I ported and authored a bunch of patches to lix-installer, the Lix flavor of the installer. I haven’t reached out to anyone from DetSys to help me with this. I asked other Lix community members one or two questions about it, but otherwise my work was fully solo (aside from porting upstream PRs, where it’s not me who made the work to begin with). The project isn’t terribly complex: more overengineered and riddled with tech debt, if anything. It’s not too hard to fork and develop mostly- or entirely self-sufficiently. To clarify my role: I don’t hold any positions of authority or any formal roles in the Lix project, I’m just a random guy who contributes to it.
But once again, there’s no reason to do that aside from branding - DetSys installer already supports installing CppNix. Lix is a separate project that installs a separate daemon, so it explicitly cares about getting the branding right, and it also needs to have self-sustainable installer because Lix has already diverged quite a bit from CppNix, and will only grow farther. Those concerns don’t seem to apply to NixOS community at large, so shrug
Yes, you could argue that way. But I’d say this: DetSys were looking for official flake stabilization for a long time. Obviously because they were pushing flakes massively to their customer base, while they also got the Nix adoption they were looking for via flake’s popularity.
If you’re in that situation as a company, the whole flakes situation looks equally bad as it does to many contributors. But from a very different angle. From the perspective of a company like DetSys, one thing you might conclude is that it’s best to get things done on your own first, and then, maybe, upstream if it’s worth the time and energy you need to actually get them accepted.
Just judging from how this thread went, people might ask themselves if engaging in extensive communication with upstream is really worth the time value of your money.
This will most likely only cause more fragmentation.
I don’t know what that means. Centralization isn’t great either. I think independent entities and teams can pursue independent projects and develop products around Nix. I’d not say that is a bad thing, rather the contrary.