Although Aux doesn’t have excellent searchability right now, I do think that it’s the kind of name that can be very memorable and recognizable once established.
As far as aesthetic and effective branding goes, I’m more concerned with the .computer TLD personally. Understandably there probably aren’t many aux domains available as it’s a 3 character word, but I think grabbing a .org with “auxos” like nixos.org or even something like “auxgroup” would be better. It’s mostly a personal nitpick though.
Did you check those though? Like the OS thats already called A/UX?
I think this won’t work well and we will reget it later. Sometimes I just want to search something about the nix language but the stack overflow post didnt include “nix lang” it just said “nix” and then google just never finds it. And I don’t mean nix cli or nix package or nix os, I mean nix lang but it just doesn’t show up.
Its the whole reason I have to search the discourse instead of google, because google doesnt find much.
I’ve resorted to just always calling it “nixpkgs” even when I mean nix lang or nix os because “nix os” conflates with Unix OS. And same with Aux and A/UX even though its dead.
One extra x could completely and permanently solve this problem.
It just feels like “Aux” is motivated by intangible preference, while Auxx (or other) is motivated by a very real and tangible problem that nix still suffers from.
Also, taking a step back and looking at this thread from a meta perspective; this could be a good starting point for establishing how the Aux discourse can handle disagreement in a healthy way.
Present ideas until people’s opinion isn’t changing (Let’s say wait ~1 week to make sure people get a chance to look at it)
Then someone can say “call to vote, because no changed opinions”
Vote and choose when/if this topic should be revoted on in the future, tie broken by online coin toss
Vote on the choice itself
Accept the outcome
If people bring up issue again, tell them it was either decided permanently or tell them the date for when its allowed to be reconsidered
This issue is a bit unique because it is fundamental to the project and our governance structures do not fully exist yet. Reasonably, a project name change isn’t something that would happen. However, a new project’s name may be decided in the future. I believe for that some community input may be useful, but the steering committee should be the place where that decision is made. As well, we really don’t need to spend a bunch of time on names for the most part. Aux isn’t exactly assessable in today’s world because none of our projects exist yet and no documentation or community resources exist to be linked to. Much the same way that searching “rust atomics” would yield different results before and after the programming language rust came into being.
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?).
