I think nix on non NixOS is succinct enough, but maybe I’m not the right person to judge brevity
I think having too many terms makes it harder for newcomers to understand what’s going on. Especially with things like this, that a newcomer will likely need to understand quite early on.
If we do have one, it should be very obvious. “Guix foreign” is reasonably easy to connect the dots on, but even that might be confusing to a non-native speaker, or someone who works with multiple architectures a lot.
I have a strong and possibly controversial opinion on this. We should set up the entire value proposition and subsequent narrative as follows:
Nix is a program to run on Linux and Darwin.
NixOS is a special (advanced) use case of Nix.
There has already been much debate around this, and it would be great if someone writes down the facts, pro’s and con’s so we have an overview.
Briefly, off the top of my head:
easing people into Nix on their customary systems provides a much more fluent onboarding experience
running a new operating system is a barrier to entry, as it involves many additional steps
our current target audience of software developers is highly resource constrained if they want to get things done, and we should enable them to leverage a large part of Nix’s value in the least amount of time.
dealing with NixOS on top of Nix is a tax on their valuable time
obscuring what confused newcomers need to know with (for them, at that moment irrelevant) details about NixOS makes that job harder
@garbas argues the “simple” use cases are where we have most potential for increasing mind-share (i.e., market adoption)
@mat, @garbas, @polygon, and others, report that NixOS is simply not an option for many business use cases
2022 Nix community survey (~1900 responses) tells us NixOS is a very important, but not the primary use case
caveat: the numbers only tell us about our core audience of active community members
only ~50% use NixOS regularly
~ 20% use Nix on non-Linux
Yes, many of us care to set up their systems like well-oiled machines that are reproducible with a single press of a button. Yet, we have to assume this is not the majority of people who would greatly benefit from learning and using Nix standalone.
Edit:
Using a term such as “non-NixOS” (which I have seen many times) is problematic in its own right.
It contains a negation. What is the actual thing you are talking about then, if it’s not NixOS?
It hints at the unfounded assumption that NixOS is the only thing of relevance. It is not, see above.
I can only imagine where that notion comes from historically, but I think we should move away from that.
I’m fine advertising Nix first and NixOS being a side effect of nix. But when writing guides for doing things with nix, I often have to differentiate how to do something when on NixOS and when not. This adds too many “nix” and “nixos” words in sentences, I suppose this is really confusing
Hm, that’s just for differentiation in context of this discussion. I would not actually use that anywhere.
We still have to figure out terminology. See that thread for details and please let us continue the naming discussion on the related pull request directly.
Also I agree with @fricklerhandwerk. Our “recruitment stories” should be this:
“Power users” using Home Manager on any platform
Developers using Nix on any platform
Sysadmins using NixOS
Arguably the last one is the post polished, I know @Gabriel439 thinks we should emphasize it further. But unfortunately it seems to me that half of sysadmin-land is very conservative, and the other is high as a kite on proprietary cloud stuff which is actively deskilling it. This makes it hard to do as a recruitment channel.
The other "recruitment stories don’t rely on NixOS at all, and indeed that is their entire point — making trying out our ecosystem a much more low friction thing focusing on some existing needs (dot files, don’t just build on my machine) before they fully drink the kool-aid.
Yes! We do not need to disambiguate between nix on nixos or not, as the way you enable flakes is essentially the same for both: add a line to /etc/nix/nix.conf, the difference is how exactly the line ends up there, though that is not nix’ concern. If we disambiguate this, then we would also need to disambiguate for about anything that has a module on NixOS.
But indeed, we need a way to better disambiguate between these:
“nix” the framework/buildtool for reproducible builds
“nix” the language that is used by the tool mentioned in 1
Well if Nickle replaces what we have today completely, we sidestep the problem, but so long as the language was have today continues to exist it needs a name.
Call it “Nickle–” if you want, lol, but it’s no the same thing.
It avoids coming up with a completely new name, which would make it hard for existing users to actually use it, but it’s different enough to that it would actually matter in eg google searches.
One possible downside is that people still end up using both Nix and Nixlang, like it happens for Go/golang.
One possible downside is that people still end up using both Nix and Nixlang, like it happens for Go/golang.
I think it will be exactly that. IMO in “lang”, the “lang” has no meaning than modifying a word to make it search-engine friendly. In speech and thought, it doesn’t disambiguate, and so we are back where we started.