I have first hand experience with trying to find a good alternative name for the oils project (previously oilshell) - which has been extremely badly named (type ‘shell oil’ into google…).
@jakehamilton I highly recommend you to really reconsider this. It’s not as bad as oilshell but atill somewhat ambiguous. NOW is the only time when it’s rather easy to change. I know, you got the dns and everything set up. But there would be much more to change once it takes off. The “annoyance” of a name change is fine NOW. Only a few months down the road it would annoy much more people.
Anyway I’m very thankful you took all your time to set things up. I’d understand if you were to keep aux. I can imagine you already spent a lot of time on this!
In the end it’s ‘just a name’ - which is currently a tiny bit better to google than nix. And nix “worked out”
I think the Nix/NixOS/Nixpkgs confusion is something we’re pretty uniquely positioned to tackle, as a fork - it’s definitely worth trying to address as I often hear from people new to the Nix ecosystem that understanding the divides between the 3 parts is not very intuitive.
Beginning from a complete copy of Nix, there’s a few distinct parts to the Aux ecosystem:
Language - the expression language that powers Aux tools
Build tool - the CLI application that consumes Aux language expressions, evaluates them and builds derivations
Package repository - a “standard library” of sorts for the Aux language, as well as a collection of expressions building commonly used software
Linux distribution - an operating system that uses the Aux build tool to build a full system, with associated configuration and software, all specified through the Aux language
I think it’s worth thinking about distinct and clear naming for each of these elements, with a focus on eliminating the confusion between the purpose of each component (ie. no more wondering if “it’s a part of Nix” means it’s in CppNix, Nixpkgs, or the Nix language).
Assuming we want to stick with Aux as a base, here’s some of my brainstorming:
Language: “The Aux Language” - the language is what underlies everything in Aux’s ecosystem, so I think it makes sense that the language itself should be named Aux - that’s what the ecosystem is around, after all.
Package repository: “Auxports”
Playing off of prior art for package repositories like FreeBSD Ports and Macports
Also a fun play on the common “auxilary port” terminology used in audio
Linux distribution:
“Linaux” is the first thing that comes to mind for me (obvious), but I’m not a fan of it - it’s not distinct enough from Linux for my liking
Going back to the audio thing though, that did start making me think about the concept of “line in/out” in audio gear - nothing really coming to mind on names there though
“AuxOS” feels obvious but is too similar to Apple’s A/UX operating system to be easily searchable, IMO
Build tool:
Audio has been the theme I’ve been playing on so far. Given this is a build tool, what names come to mind from “building sound”…
“Fourier”? Fourier analysis covers how sound waves are built out of basic, trigonometric function waves
“Synth”? Synthesizers are used to create sounds in electronic music production. Synth does have quite a few other meanings, though…
Instruments make sound. There’s plenty of those to pick from.
I would not change the name of the language unless we are making significant, backwards-incompatible changes to it. Since that would also mean that we could probably not use any third-party flakes in aux, I would caution against that.
Nix is a language, so it’s mainly a specification. No one would expect a C compiler called qbe to refer to the language it compiles as anything other that C. It would be counter-productive to do so.
We should definitely try to untangle the triangle of confusion, because that’s a real issue when trying to onboard people to Nix. I can’t tell you how often I had the conversation that start with “Hey, you should try Nix for your development tooling” “Yeah, it looks neat, but I’m happy with my Arch / Ubuntu / Debian”.
The term “nix” is to complected and hard to grasp for people outside the community.
We should try to avoid making the same mistake again.
Mmm. Good call. I don’t think we have any plans at current to break language compatibility. so maybe best for the lanuage to remain “the Nix language”. The other three though definitely need some reconsideration though (maybe less so the build tool? Maybe that can be Aux?).
What if we lean into the identity of Auxolotl? It is search engine friendly since it isn’t a word, the only real problem would be autocorrect being annoying until it learns the new dictionary entry. The name being different would help separate it from an aux cli and we can name other projects distinctly as well.
My biggest hang up with something like Auxx would be how clumsy it feels. Much like a hack I would use in css to increase specificity. Auxolotl feels much less clumsy, albeit not perfect.
+1
)