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
3 Likes
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.
4 Likes
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
4 Likes
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.
3 Likes
There’s no installer shown on the homepage, and Download | Nix & NixOS shows the official installer, not the detsys one. And new users generally use the official installer, they do not come to know about the detsys installer until someone else mentions it.
I said something like this a year ago, but I am disappointed to hear that we are still in the situation where Eelco could push to the nix project (which he owns and founded) or to the detsys project (which he owns and cofounded) and he chooses to push to the detsys project rather than enabling detsys employees to contribute to nix. This isn’t a question of if contributions can be accepted - they can, if that was the intention. Yes, Eelco stepped down from the NixOS foundation but that’s more to do with administrative/funding tasks and isn’t relevant here (which is why that’s in a separate topic).
7 Likes
You just argued that the generous interpretation of this is that DetSys will be able to change DetSys NixCpp quicker for their customers, and then just upstream the changes. But since there’s no guarantee going forward that their changes will be accepted (unless DetSys is controlling upstream CppNix), that means that their Nix-distribution will diverge from upstream CppNix.
Eelco announced Flakes at NixCon in 2018, I think. Don’t tell me that the group of people now employed at DetSys couldn’t possible have worked to stabilise flakes in upstream nix sometime between then and now.
4 Likes
Yep, that’s about the long and short of it! We make lots of patches to Nix, they’re all PR’d directly to the upstream project. Since Eelco isn’t a BDFL or fundamentally in charge of the project, a number of them haven’t landed yet for a variety of good and valid reasons. Hopefully this helps provide more background on this (careful) phrase: “Determinate Nix will include patches that have not yet been released by the upstream project.” We’ve PR’d them, they’re just not released.
At the same time, we’re afforded certain flexibility on our release cadence and how we ship to our users. For example, our ability to do phased rollouts to users over time. This means we can ship more aggressively and react more quickly. This is how we concluded that flakes are stable as they are today and guarantee their stability into the future: using the data we’ve seen from our users and general Nix adoption.
At the end of the day, we’re not looking to diverge in ways that break compatibility. I believe the project is better with us all working together. That’s why it isn’t a fork, but a downstream distribution. Hopefully, having real-world usage and stability data about the patches we’ve PR’d upstream will make it easier to land in upstream Nix.
11 Likes
DetSys was clear pretty early on in the process (by Spring 2023, at least) that they didn’t feel like it was their place to “push” the Nix project to adopt their installer (i.e., people on the Nix side would need to evaluate/decide/pull and build the muscles to maintain differences). The Nix team representatives present were also clear that they didn’t have the bandwidth to do the pulling.
Lest it get stuck at that impasse, the pulling has fallen to Matthew and I (and Domen did a smidge from a hackathon). This has been slow because we are few and (at least I personally) have very little bandwidth to dedicate to it.
At least one person from DetSys shows up to each of the bi-weekly installer WG calls where they communicate what they’re up to, answer codebase/process questions, provide advice if we’re PRing something upstream, etc. They’re also receptive to any feedback we have on changes that could minimize the friction we encounter trying to follow them.
There’ve also been a few multimonth periods where it’s just made more sense to sit around and wait:
- For much of 2023 it didn’t make sense to do much until a large refactor was baked.
- As of late this Spring we mostly just needed to figure out an initial release process and then nudge more official teams to finally get it ~hosted under nixos.org, but the macOS Sequoia update breaking existing Nix installs consumed the focus of installer WG meetings from June through September–and it again didn’t make much sense to put effort into syncing up until it was clear that our Sequoia mitigations were going well. (I woke up early to take a look at the conflicts before work this morning, but I’ve burned that time on this message.)
The Nix team was clear that it didn’t want some of the opinionated features of the installer, so Matthew has had to work on replacing some of those parts with implementations that are equivalent to the official installer. (Since we intend to follow the DetSys upstream, this also means we have meaningful diffs to maintain during sync-up.)
16 Likes
That’s correct. Sorry for misinformation, should’ve double checked.
Out of curiosity: what are those opinionated features? We removed some too, but it wasn’t a large churn. But CppNix approach towards what’s “opinionated” and what’s not is likely different.
1 Like
Isn’t DetSys in essentially the same position as Flox? Neither company is or ever has been ‘the maker of Nix’, and both companies are offering open core products targeting enterprises where Nix itself comprises much of that ‘open core’. Each of them has an employee on the Nix team.
DetSys does not to me seem positioned to unilaterally ‘take Nix open-core’ by blocking the merging of certain kinds of features into Nix. A Nix team comprised of too many members of companies with substantial overlap in their products and strategies might risk that kind of problem, though.
It would be smart and helpful for DetSys to declare that they don’t have veto power over what goes into Nix.
It’d probably also be good for the Nix team to declare that no company does.
Similarly, it’d probably be helpful for a Steering Committee to eventually do something in conjunction with the Nix team to help show that they intend to do their best to ensure the Nix team is and will be composed such that it’s unlikely that many members will share an interest in such gatekeeping. I imagine this is an issue of which any member of such a committee is likely to be well aware. Hopefully community leaders and the Nix team can work out a good plan to help grow the Nix team as a hedge against domination by companies (or groups of companies) whose material interests in Nix improvements are narrower than those of the wider community of users and developers.
Seems doable, and basically one of the aims of a lot of recent and ongoing community work. Efforts to keep Nix free are only bolstered by friendly forks like Lix and Nixpkgs-targeting reimplementations like Tvix, too. As long as there’s a Nixpkgs/NixOS-compatible Nixlang implementation willing to accept whatever features, there’s kind of a cap on how much a company can benefit from keeping those features out of CppNix, even if they could.
There’s plenty of other places for a company like DetSys to add value or compete if Nix gets better builtins for authenticating to private repos or whatever. I think these concerns are valid and important— we’ve all seen open-core projects reject PRs to sustain their commercial developers’ respective ‘moats’. But I don’t think the overall picture here looks that much like pre-fork Terraform or GitLab or whatever, and it seems like we’re finally growing a governance structure that can work to ensure things stay that way.
7 Likes
Setting aside obvious stuff like diagnostics/telemetry, IIRC it all fell under the list in GitHub - DeterminateSystems/nix-installer: Install Nix and flakes with the fast and reliable Determinate Nix Installer, with over 7 million installs. (Lix’s copy of the list is at lix-project/lix-installer: A fork of the Determinate Nix installer. - Lix Systems).
1 Like
It’s at least consistent that a distribution of (not exclusively) glue code to a proprietary code hosting and distribution site (FlakeHub) is proprietary on its own. So I’m not surprised about this, though it makes me a bit sad and tired.
I honestly believe the community folks involved in things like Flox and DetSys that they really do think that their work on fully-fledged enterprise development would not just be a benefit to their products and platforms, but also to a significant extent to the open community. Unfortunately, there are so many (former) FLOSS-adjacent examples of venture capital funded tech products that didn’t work out that way but took vastly opposite routes. Personally, I see this as the wrong way.
There is a strong value in Free and Open Source Software insisting on being based on FLOSS tools itself. Thus for the time being I hope that I never need to touch such tooling myself. This won’t work by itself, so I am already grateful to everyone who works on improving the core and wider ecosystem in a FLOSS-first fashion, no matter whether upstream or in a friendly fork.
The needs obviously targeted in the proprietary extensions can though serve as an inspiration of what might be needed.
PS: The flake.nix and the way it serves architecture-specific blobs is at least a fascinating read 
10 Likes
Even if we did want to break Nix in this way, does this strike you as a change that the other core team members would approve?
2 Likes
Due to Eelco basically owning nixos/nix and also owning DetSys, I do not believe in the rest of the core team. There still seems to lie a lot of power in a single persons actions.
He might have stepped down from the board, but he is in fact still able to do what he wants with nixos/nix. I still see some conflict of interest in this regard.
Trust has to be regained.
And with DetSys only introducing ever new services based on nix, while flakes remainig in a “stable experimental” state doesn’t improve my trust.
The fact that it sometimes appears that DetSys “owns” the nix project doesn’t help either.
And the fact that this perceived ownership might move on to the next company that Eelco decides to start working for, does help even less, as before DetSys “ownership” often appeared to be at tweag.
And at this point I do not really know whom I do not trust… Eelco, DetSys, the nix core team or the foundation…
For sure, I will not ask Eelco to stop earning money, nor will I try to forbid DetSys trying to be profitable. Its just the overall situation that makes it appear shady currently. And looking back, many of the DetSys news and products have been somewhat controversial within the active community. The official parts and the not so official parts.
So again, its all about (the lack of) trust…
14 Likes
Also crummy communication. The original announcement didn’t mention source availability or license at all. As a result (and from examining the flake) we all assumed closed/proprietary, and that this was intentional. Now @grahamc has just said on lobste.rs that there’s intent to open source it when possible. If that had been stated up front it might have allayed a lot of anxiety!
3 Likes
This post was flagged by the community and is temporarily hidden.
8 Likes
Speaking as a fellow community member who’s also not a mod, I personally flagged it for “responding to a post’s tone instead of its actual content” (which is explicitly proscribed against in the community guidelines) and because I see an “apology” for others’ behaviour (which doesn’t make sense anyway) as bad-faith engagement that doesn’t add to the conversation (it provokes/escalates). Considering the posts from detsys employees appear to not be flagged (despite the hotly contested nature of the topic) while your post was, I suggest that merits reconsidering your approach.
Anyway, returning to the topic… I saw one aspect mentioned earlier that mentioned confusion between the detsys and official nix. I find that interesting because normally if any project took the nix name in such a way, they would be asked to distinguish their project clearly and avoid use of the trademark. (see for example New Discord To Discuss Nix/NixOS and the Wider Ecosystem - #5 by fricklerhandwerk and Searchix: web-based option/package search including nix-darwin and home-manager - #15 by fricklerhandwerk )
But such action hasn’t been done in this case - detsys intentionally called the thing “nix”, played up Eelco’s association, and no one has objected from the NixOS Foundation. Why? And this to me speaks to the special treatment detsys gets compared to any other company, again due to Eelco’s involvement. He’s “off the board” but is he really?
12 Likes
As pointed out by a post that unfortunately got branched off into a separate thread - Eelco is not off the board despite the board statement back in May.
Lix ran into code that breaks HTTP protocol conventions, presumably for FlakeHub reasons. And as pointed out in another DetSys thread - despite all the claims, DetSys doesn’t actually help “flake stabilization” efforts. And reading Eelco’s “I don’t want to make version resolution” to announce that as a paid feature on his enterprise product is very questionable. And yes, I know that he said something a little different, but it really reads like a hard “no” consider Eelco popped up, made a concern, and disappeared completely, not bothering to comment when valid counter-arguments are brought up.
Hard doubt on any meaningful open-source contribution from DetSys, basically.
8 Likes
This post was flagged by the community and is temporarily hidden.
1 Like