Any way I would suggest the “auxolotl” as mascot
Just a little spin off with this here. If we do go with the short name axl then i really like the idea of calling the auxolotl, Axel.
3 Likes
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.
8 Likes
patchbay
(This line consists of extra characters to make up the minimum length for a discourse post)
3 Likes
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.
3 Likes
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.
5 Likes
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?).
1 Like
Sounds like a mexican/ toltec/ mayan deity to me 
+1
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.
13 Likes
Auxolotl is very cute
9 Likes
I like it. I’ll see if I can take an axolotl-theme with this brainstorm round:
- Build tool: “Aux”
- We’ve already got this name. If we’re going to be “the Auxolotl Project” or something along those lines, may as well.
- Operating System:
- Where do axolotls live?
- Native to Mexico, although I am hesitant to just take the name of some place in Mexico
- (although i do admit, ChalcOS popped into my head while I was researching axolotl habitat)
- Salamanders generally live around freshwater lakes - Freshlake OS? Not awful.
- Package repository:
- This is largely a collection of derivations/libraries that Aux will consume - what do axolotls eat?
- Tends to be small bugs and fish
- Bugs and fish come from eggs? I think I’m getting too detached from the theme here…
- Axolotl prey is usually aquatic
- Water stored in a resevoir - the Aux Resevoir? I don’t mind that at all actually
- Bonus points for being thematic with Freshlake as well
(in case you can’t tell, I have a lot of fun coming up with names for things 
)
11 Likes
These are pretty good, thank you!
4 Likes
These are really nice! I think we want to avoid doing something similar to homebrew where some common things are renamed (pour from a cask) and it’s hard to understand what things are.
For example, let’s avoid calling our options “eggs” and all repositories “bodies of water” where we “swim eating fish”… however calling things “Freshwater OS” or the main repository the “Package Resivoir” is great, it’s thematic and still easily understandable
10 Likes
Agreed, we shouldn’t be attempting to reinvent common terminology like “packages”, “modules”, “options”, etc. - all that really achieves is newcomers that walk into the project, see “grommick the flurshbo by adding the pimblets to your Local Bowl”, and immediately walk away . It’s mostly the Nix/NixOS/Nixpkgs confusion that we should tackle here, and there’s not really any harm in having a little fun there.
5 Likes
“modules”, “options”
This is one of my biggest issues with nix I would like for a easy way to distinguish between the two. Or rather user made modules vs aux modules
1 Like
I think resevoir as the name of the package repository is growing on me, I really like it.
Giving Freshwater OS some more time to cycle around in my head, but I think that may be good to use as well.
9 Likes
i was thinking of a name like the group, like a murder for crows, but for axolotls its called a harem which feels wrong.
4 Likes
I disagree, it’s the pouring cask from brew problem again. I don’t think it’s unreasonable someone would want to pull from resovoir/nixpkgs, and now it’s a little more confusing because what does resevoir do again? I’m not saying to just follow what nix does, but nixpkgs tells you exactly what it is – it’s the packages for nix. What is nixos? The OS, with nix. The only hangup was nixlang vs nixcli vs nix the technology, which is what we should address.
1 Like
Thankfully we have plenty of time to think about this since project naming won’t be necessary until phase 2 (hard fork).
4 Likes
The transfer of anything should be called “passing the aux”.
(Credit to Shacomancer for this one 
)
5 Likes
Pointing out a minor typo just in case: reservoir.
I came up with a couple water based ideas for the OS name:
- HydrauOS, pronouncend “Hi-dr-ow-ess” (merge the 2 “o” sounds), pun on hydro while being unique
- HydreauxOS (“eaux” is French for waters, x is silent)
- Or just eauxOS (my fave), not set on a pronunciation but “oh-ess” would be funny: “I use oh-ess”
7 Likes