I now see your point a bit better and I concede that there is a significant amount of that sort of zero-sum thinking going around.
3 Likes
I mean, I’d write a whole essay on it, and maybe I will. I think that Nix’s LGPL is good and the big question is whether DS is trying to work around it, or work with it, or some combination of the two options, and how much a lack of leadership has let the status quo unfold by default. What I will point out is that the LGPL is a license that means people’s work can’t be stolen and appropriated, so the source of perceived unfairness is coming from other locations likely related to expectations of how their contributions track with upstream.
Edit to add: in a matter of weeks, the community will be able to manage those expectations by talking with the stakeholders involved and doing the thankless work involved in getting a bunch of people with slightly differing motives to agree, so hopefully this cold war can end.
2 Likes
I don’t know that the LGPL comes into the picture given that detsys created an allegedly rust-based impl of the daemon. The main contention I saw was misleading marketing, for example:
1 Like
Right, this is the possible “working around it” I was referring to. Is it a full replacement for the daemon? I was under the impression it was some sort of orchestration process that serves a different purpose.
Edit: It’s this daemon, which handles logging into FlakeHub and scheduling GCs, and doesn’t replace nix-daemon. They also say:
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.
So, it’s more like another Nix distribution. This still brings me back to my initial question about the expectations about upstreaming patches for this sort of thing, and that the LGPL says anything that’s core Nix will remain open.
3 Likes
The LGPL doesn’t compel a fork to upstream its patches, but modified source code still has to be released if the modifications are released in binary form.
If Determinate Nix were to dynamically link to CppNix or just call its CLI directly, there’s no obligation to release source code. The dynamic linking exception is the main difference between the LGPL and the GPL.
2 Likes
Yeah, the “being nice” part is a social contract. Given history, I understand why people are hesitant to trust that they’ll uphold it. But, again, this is where clear expectation setting and boundaries help for the future. Especially around coordinating things like CVE releases which require a cohesive approach across projects, but it could be extended to “work with the team in general if something is to become an upstream standard.”
1 Like
There’s technically nothing stopping CppNix pulling patches from Determinate Nix without their approval. May not fall under “being nice”, but, that’s the license.
1 Like
Reciprocal licenses FTW! 
2 Likes
@grahamc are you (read: Graham and Determinate Systems, the company Graham represents) this unresponsive when it comes to feedback with your actual customers too? (Or I should rather say, negative feedback, as since the last time I posted you seemed too happy to reply when no one’s complaining (link, link))
This seems like something any current and potential customers (which may include me too, who knows!) lurking on this forum may want to know. If not, do we need to fund an entire new company just so we can make you answer a few simple questions?
I have brought this up twice. So, for the third time, what is up with post you linked referring to Determinate Nix as just “Nix”? Have you not noticed how this may mislead people?
And as @olaf has brought up before, how do you plan on solving this obvious name collision?
If this was an honest mistake you can just say so, fix the blog post, and all this discussion will be over.
7 Likes
To clarify the distinction further, we’ve updated the blog post link to point here instead. The now-linked page provides, I think, a “softer landing” than the official landing page and explicitly demarcates upstream Nix from Determinate Nix.
5 Likes
So you changed it from a link to your site to… a link to your site. Also, that page immediately starts with “We recommend starting with [a different page]” and then initially goes on to describe Nix as confusing.
We recommend starting with the Nix quick start and consulting concept docs primarily for clarification. Feel free to click x to the right to disable this notification on all concept docs.
Nix can be a somewhat confusing term because it refers to multiple things:
That’s not a good landing page for marketing purposes. It’s more of a technical overview. And it doesn’t resolve the problem of DetSys continually making efforts to brand Nix under their own domain.
4 Likes
It goes on to say:
- The pure and functional programming language
- The Nix CLI
- The overall Nix package management system
Is that not a common confusion?
Should it be?
1 Like
I think that page is a decent technical overview but a landing page it is not. And you’re right, it’s not supposed to be. That just makes it all the stranger that you’ve linked to it as the introductory link to the Nix ecosystem in the blog post.
2 Likes
Removed because it goes against my communication values.
It doesn’t say that Nix is confusing, it says that the term Nix is confusing because it can refer to three different things. This is a common complaint about Nix that, to me, feels worth tackling head-on.
4 Likes
Removed out of respect for the removal of its parent comment
1 Like
Our blog style is to heavily reference concept docs and similar sources. It’s an editorial style you’ll find throughout everything we write. Not to push people to a specific flow, but to generally provide deeper dive educational resources.
2 Likes
I suppose I’m still a tad bothered about linking community-wide words like Nix, nixpkgs, and NixOS to your own site, but I guess it’s hard to see that as a significant issue on your own blog site.
Regardless, in this particular instance, it seems like linking to the quick start makes more sense than that clarification page.
1 Like
Everything about Nix was a hugely rewarding puzzle. Every successful build was a huge dopamine hit, rewarding the challenges of navigating the Nix libraries and fixing build problems. Every pull request to Nixpkgs was quickly reviewed, merged, and celebrated by a relatively small group of dedicated folks who loved this tech as much as I did.
This really spoke to me, too. I got into NixOS around the same time as you, @grahamc— although I never made comparable contributions to Nixpkgs or communiry infrastructure. I remember the coziness (which is certainly gone) and the brilliance (which has not diminished at all) of the community at that time fondly. When I first tried NixOS, I knew I’d stumbled upon a secret treasure, and I wanted to show it to everyone.
Nixpkgs was smaller then, and so packaging something just to be able to play with it on NixOS was a given for basically all NixOS users at the time. And especially at that phase of my own discovery, there was joy in the puzzle-solving of it. There was joy, too, in encountering the incredible generosity of the Nix community, in how people worked to help newbies like me solve our own problems and improve our little contributions.
We had (and have) something really special here.
An aside regarding the link text for the word ‘Nix’ pointing somewhere internal: we do the same thing on my team on our docs site (which is aimed at external teams within the same company). We try not to redundantly document much that is covered upstream, and we do direct users to the actual Nix docs.
Nonetheless, we have a little Nix section in our docs that contains those links to upstream, some additional context, and various recommendations about how to approach Nix and its own documentation. I don’t think it’s that unusual a practice for blogs or docs sites. It’s the norm for wikis, too, of course.
4 Likes
It is, actually, but when there is a base large/consolidated enough that “most people” (casual users, enterprise users etc those who do not experiment much) could find an ACTIVE stable version, perhaps of a certain number of distros, and various experimental versions/branches of potential future evolution.
Even such “consumer only” userbases are useful, because they can contribute in casual posts, metrics, some patches here and there helping to understand how users reason and how to tech a different reasoning, because the primary goal of FLOSS is spreading knowledge, anything anyone learn could not being personal only but shared, so not wasted, because knowledge is the sole resource that grow with it’s usage instead of being depleted.
Freedom is a consequence because we need to be free to change anything, meaning creating new knowledge, and declarative systems who “document” de facto everything being themselves code are surely the future, but to been able to spread they do need a FLOSS large enough base. So far NixOS have a vast support for pretty anything and a stable version, so this needed phase is done, but recently many projects abort/derail making a big warning sign for the future. NixOps seems to be dead, and it was the needed step to a complete NixOS, the mean to orchestrate/mass deploy forgetting Ansible/Salt as we almost forget the older and much more complex/with much more overhead Puppet/Chef/Cacti etc. NixOS is still the way to easy develop and deploy complex and often complicated modern software, but instead of showing a mainline evolution and various branches, show a fragmentation: here the Flakes, here some forks too young and with a too little community to really go somewhere while the “mainline” seems to be just kept in maintenance mode with just little version bumps.
The sole current fully working fork of NixOS is Guix System, which is good, but I think the respective communities diverge too much to share different ideas the other side regularly pick improving through diversity.
So well… I’m not much optimist…