The official resources don’t mention Flakes because, as an experimental feature, we can’t just point users into using a feature that may change from time to time (realistically, it hasn’t, but there are new discussions about it). Being used by practically everyone (even me) does not change this fact.
Yeah my point was Determinate Nix is not the same as official Nix. They’re free direct people how they see fit through the Nix ecosystem. They choose to do that in a flake centric way so it doesn’t make sense to link to the official documentation. DetSys seems to think that flakes are “stable enough” to point people to their flake based documentation. If you disagree with that approach that’s fine but their motivations seem pretty clear and their line of reasoning is not irrational.
Aside, if you want to be pedantic, Flakes are documented in the Nix manual along all other experimental features, and Nix is for now still a part of the NixOS project.
Flakes are buried quite far into the documentation and I would never refer someone to the official documentation if I thought a flake centric view of Nix was the best approach.
I wish this Community could embrace that it is a vibrant growing ecosystem, and that an efflorescence in one part of the garden is not a cynical bid to cast shade on another part of the garden
I’d really like us to get beyond the cynical kind of zero-sum thinking that involves throwing shade. Nix is an incredible technology that is disruptive in a number of positive ways. The fact that it is open source and licensed under something like the LGPL means that the concept isn’t going anywhere, and the implementation certainly isn’t either. Of course, I’ve got opinions about the MIT License used for nixpkgs, and think that a better “living system” would be more likely with a dual LGPL/MIT, but that’s mostly beside the point here. The future is incredibly bright in multiple parts of the garden, and one party does not need to lose for another to win.
With no intention to be rude but… The future of distros it’s clearly declarative, so something to makes that possible on “upstream” side is needed. Nix{,OS} is the inventor (I think) but seen the actual fragmentation state I’m not so much optimistic about it’s future…
I wish people could remember the difference between trademark infringement and open source forks within a single thread. Forks are almost never permitted to use the upstream mark unconditionally, nor mislead others into believing they are getting the upstream software, the same would apply here.
And it probably hurts the nix community to pretend that the detsys community is the entirety of the nix community.
The issue isn’t zero-sum thinking, the issue is a company that has already demonstrated to be willing to use deception, sabotage, and predatory tactics like creating proprietary products like FlakeHub and Determinate Nix to lock in potential users to ensure profits. It’s not an “efflorescence in a part of the garden,” it’s kudzu crowding out everything else in the garden. Regardless if it’s zero-sum, there’s still plenty to lose.
Speaking of ways of thinking we need to get beyond, I really do not like when the focus of something is on how “disruptive” it is. To my understanding, that’s focusing purely on the potential for profit rather than actual usefulness or helpfulness. “Disruptive” seems to essentially be a marketing buzzword that boils down to “this is dramatically different from anything else out there and whoever is selling it is in the perfect opportunity to extract maximum profit from it and shape the market in their favor going forward.” That is the kind of thinking that drives companies like DetSys to come in and crowd out everything else in the garden, so to speak.
Edit: I should not have said the immediate above things. Whether I was aware at the time or not, I was taking my frustrations out on a stranger on a public forum. I have marked it as a spoiler to mark that I sincerely wish to retract what I have said.
FWIW, I do not think you are being rude.
I agree that the future of Linux distros is declarative configuration, but I think what you are referring to as “fragmentation” is a good thing. I think the proliferation of open-source forks and alternative implementations like Lix, Tvix, and the Aux community’s efforts to make an alternative to nixpkgs allows people outside of Nix’s dev team and DetSys to experiment with new ideas. If nothing else, it adds a potential check to prevent a single entity, non-profit or otherwise, from having complete dominance over the Nix ecosystem and the potential for stagnation that comes with it.
On second thought, I sincerely apologize. I should have thought a bit more before hitting “reply” and I should have realized how severely I was essentially accusing you.
I am sorry and I should know better than to behave in such a way, especially to a stranger and especially on a public forum.
I appreciate it. My actual stance on it is that there is a somewhat justified worry that DS isn’t being a good steward of the community. I’d go into how the LGPL in particular interacts with this and how I think all companies should push upstream when possible, but don’t love how these concerns turn into an opportunity to dunk on “the wrong people.” It has made interacting with the community frankly depressing, and is the kind of zero sum game I refer to.
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.
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:
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.
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.
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.”
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.
@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 uptwice. 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.
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.
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.
