A quick one. NixOS recently got a trademark. Awesome. Now what.

As a governance insider, I’ll give you a general gist of what this likely means:

• Using the word “NixOs” for products generally wont be permitted.
• “Nix” can be used in some cases, albeit only when there is no confusion or product conflict with official NixOS foundation projects.
• Using the NixOS logo may also get a similar treatment, so I’d avoid using it for your NixOS++ AI rewrite.

Of course, this is NOT legal advice, just a best guess about enforcement.

Right, not very intersting. The thing is what we call stuff now. I’ve been thinking about this a lot, and here are my suggestions:

Why bother with acronyms? As much as having cool sounding words is an underrated part of our quest of getting rid of ansible for good, it can feel a bit much. But hear me out.

Not just does this help us actually create usable categories for talking about these, as I’ll demonstrate later, but it also let’s us clearly disamgibuate e.g. the classic “Nix, no not Nix Nix, no not nixpkgs, nix as in nixos” things. Insert beloved Nix isn’t NixOs isn’t Nixpkgs graphic here.

Functional Package Managers (FPMs)

A functional package manager is anything like Nix, Lix, Determinate, Guix, Twix, Snix, or similar. It’s not for instance pacman, or apt, as those aren’t based on turning functionally defined packages into build products.

What it actually does: evaluate the package definitions, build stuff, put the results in a store. Lix is an FPM. Guix is an FPM. If you fork “Nix the program,” you’re usually making a new FPM — that does not automatically mean you made a new package collection or a new OS. People keep saying “NixOS fork” for all of those. Stop. Its a fork of Nix. It’s a new functional package manager.

Functional System Distributions (FSDs)

These are systems such as e.g. NixOS, Guix System, Axolotl, EkaOS. It’s not for instance Arch, debian or windows.

The FSD is the actual system you ship: package manager + package collection + store convention, usually with a module system, something you can boot or call “the distro”. You can make a new FSD without rewriting the FPM. You can also write a new FPM that still runs someone else’s FSD, if enough of the rest matches. This is also why the trademark hurts: people used to just say “a NixOS” for this whole category. Well, they didn’t because they didn’t even have a word for this. Anyways.

Functional Package Collections (FPCs)

These are package sets such as Nixpkgs, Guix packages, Ekala, Auxolotl packages, or even smaller subsets. It’s not for instance Aur, brew, winget, or similar.

The FPC is the pile of package definitions. Not the CLI, that’s the package manager. Not the distro. nixpkgs is a functional package collection. A smaller tree can be an FPC too. When Auxolotl or Ekala fork “the packages,” that’s an FPC move. AUR, brew, winget — different beast; they’re more “catalog of things to install” than this functional collection setup.

Functional Store Conventions (FSCs)

These are the specific store systems used. E.g. Ekala, Auxolotil, Lix, Nix, Determinate all use the Nix Store system, even if Determinate is making their own Daemon for it?

Guix has its own fork of this. Nice Guix, real innovation.

I say convention because it’s the shared layout and hashing and “where do the built things live” rules — not one fancy network protocol. Nix, Lix, Determinate and friends mostly share one FSC, so paths and caches still mean something to each other. Guix has a store too, just not that same convention… mostly, yes there is overlap, I’ll treat this later. And a binary cache? That’s just a thing for an FSC. We’ll also treat that later.

How these fit together

Obviously, a FSD uses a FPM and a FPC with a FSC to build the FSDs. Then the FPM just targets a FSC and evaluates the FPC. Duh duh duh. It’s obvious.

But like, okay perhaps we can explain that better.

Lix is an functional package manager (FPM). Same functional store convention (FSC) as Nix, can evaluate the same functional package collections (FPCs, nixpkgs and friends). It’s not an functional system distribution (FSD) and not a functional package set (FPC).

Auxolotl-ish work is mostly an functional package set, maybe an functional system distribution, often still on the same functional store convention with a compatible functional package manager.

And you may now say… okay that is heavy. Fair. If you must, you can omit the F.

Said in other words: Auxolotl-ish work is mostly an package set, maybe a system distribution, often still on the same store convention with a compatible package manager.

That’s nice right? Yea, you won’t know that this is actually Functional, but if context establishes it, that’s perhaps fine. One more example just in case.

Guix is an FPM with its own FSC, its own FPC, and its own FSD. Same paradigm, not just a drop-in for Nix FPM, NixOS FSD, and Nixpkgs FPC.

Phew. But at least we can talk about it now in a succint way.

Compatible vs sibling FPMs

Quick distinction, because otherwise Guix and Lix get shoved in the same bucket and then everyone is confused again. And I get enough hatemail as it is (I do however appreciate the fan mail)

An FPM is just a functional package manager. That’s it. Pure-ish package functions, immutable store stuff, closures, that whole deal. Guix is an FPM even if Nix never existed. You could invent a FPM in a cave with no Nix ancestry and it’d still be an FPM. Compatible with Nix is not the entrance requirement to the club.

Compatible is the other thing: can these FPMs actually share an FSC and evaluate the same FPCs. Nix, Lix, Determinate — same store convention, same kind of collection surface. Drop-in-ish. If you wonder “does my nixpkgs still evaluate” with this FPM, the answer is yes if it is compatible.

Sibling mean the FPM is same ancestry, i.e. invented in the same cave. Guix and Nix are sibling FPMs, with Guix forking of from Nix specifically, making it a child of Nix. However, they’re no longer on speaking terms, even if multiple people are trying to get them to talk together again. Even when they talk together through our various weird ways of bridging them, they’re not directly compatible.

Guix is still an FPM, with its own FSC, own FPC, own FSD. Family, but not a binary you swap in and just works.

So: both Lix and Guix are FPMs. Only one of those is “compatible FPM for the Nix FSC / nixpkgs FPC” in the usual sense.

What about module systems cafkafk why didn’t you talk about module systems >:(

I couldn’t find a cool acronym. But yes. Still matters.

A lot of what people mean by “NixOS-like” is not the FPM and not the FPC. It’s the module system — you know, options composing into a system or a user environment. FSDs usually ship one. That’s a big chunk of the product surface.

And different projects can ship different ones. Auxolotl for instance had ambitions of a new module system. Fine. Then you get the fun part: a module system might line up with some FSDs and FPCs and not others, and two module systems might refuse to talk to each other even when they’re both sitting on the same FPM or FSC.

So if someone says they forked “how you configure the system,” maybe ask which noun they mean. FSD? FPC? Modules? Those are different PRs in real life.

And yes, a FSD might have multiple module systems. And heck, different FSDs might even have the same module system. It’s 2026, get over it.

Why not more terms

I know, I know. What about caches. What about flakes. What about an FPM that speaks two stores. What about one without a store (the endgame for impermanence freaks). Where’s the acronym for those!

I’d contend that you mostly don’t need one.

A binary cache is a thing for an FSC. It serves store paths under that convention. It’s not special. Flakes, channels, pins — that’s how you fetch or lock an FPC. Also not a special thing. An FPM that can do two FSCs or two FPCs is still an FPM. Having two of something is just… having two of something.

If you can already say what was forked with FPM, FSD, FPC, and FSC, minting another genus is how every word becomes “Nix” again and we’re back to the graphic.