Easy authentication to FlakeHub on Amazon Web Services using IAM roles.
Determinate Nix is part of a more all-encompassing experience of using Nix that we call Determinate. You’ll hear much more about Determinate, FlakeHub features like private flakes and FlakeHub Cache, and more in the upcoming days.
Feel free to reach out to us on Discord with any questions or requests!
Thanks, @mschwaig! I hope so, too! We’ve been happy to see the progress on our installer being adopted upstream, and we’ll – as we always have – continue to work with the upstream project.
It feels notable, and disappointing, that all this work appears to be closed-source. Problems like “Nix doesn’t enable garbage collection by default” would be more usefully solved by changing the defaults in upstream Nix, no?
Hmm, I think the wording is not great there on our part. Garbage collection in Nix is currently manual. We have added something (inside the daemon that we provide) that automatically runs garbage collection for you in the background. This is not something that can be enabled in Nix.
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?
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.
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.
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?
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.
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?
