The word Nix refers to two things: a language and a package manager.
These are deeply interlinked together with the language being how the package manager is able to do its job.
Nix grew out of a [PhD by Eelco Dolstra][nix_paper] wherein he proposes a slightly different way to manage dependencies on a system.
For most Linux systems programs make use of other software installed on the computer, for the most part this works fine.
Where issue may arise is if one program needs to update one of these dependencies, specially a minor or major patch where backwards compatibility is not guaranteed.
If another program is using this (system wide) dependency then it may run into interface issues when using it.
In a sense updating one program can break another on the system.
The route the Nix package manager takes is it treats each program as a function.
Using teh Nix language a function for that package is created which states what inputs are required, what is needed to turn those inputs into teh program as well as the name for the output.
The output is then saved in a read only location in the format of ``/nix/store/$hash-program-name-version``.
The programming language used by teh Nix package manager is called Nix, not Nixlang (as like Erlang) but rather the same name as primary tool that uses it.
Nix is an old enough project now, and as such has accumulated crust over the years.
This is a combination of technical and societal/governance.
On the technical side nix is built using c++ and a max of build systems that make it hard to expand it.
For a good long time the nix binary used in the package manager was locked at v2.18 due to issues.
It took most of a year for a higher version to be used on an official basis.
Regarding governance there has been several attempts to make it better for folks to contribute and to decouple everything from requiring Eelco to have an input.
Those attempts did not succeed.
The final straw for some of the more technical core contributors was Eelco's forming a company, hiding it from the community and trying to get military sponsorship.
This did not vibe well with folks.
Due to all of this many core maintainers forked Nix at 2.18 and started working to apply fixes for both code and organisational.
The result of their efforts is [Lix][nix_lix].
For a full explanation of its key features I would like to point you to the [Lix About page][nix_lix_about].
We use Lix instead of CppNix as the goals of Lix align with the viewpoints and ideologies that our members hold and what we want to represent as a (computer) society.
Back in [January 2023 we got disconnected from teh internet][skynet_disconnect].
For the purposes of this document the root cause is not of importance.
What *is* the mad Indian Jones ~~treasure~~ config hunt that it triggered.
![Brendan delving for configs][skynet_disconnect_reenactment]
Additionally ITD require us to update our systems regularly (as they should be).
Technically this config delving is an ongoing effort, the old hard drives are occasionally connected up and raided.
As you would imagine this is not ideal, a exasperating factor was that many programs had changed both the location and format of their configuration over the decades that Skynet has been using them.
This is where teh strengths of NixOS lie.
The config for the entire cluster is located in a singular location.
Using modules which work as a translation layer if the requirements for the programs change this dont impact us.
Not to mention we can fearlessly (and regularly) update our systems it is a match made is heaven.
Currently the Skynet cluster is comprised of 15 servers which have NixOS on them.
A combination of LXC's (Linux Containers) and physical bare metal servers.
Since these systems share a base config (with tehir individual applications layered on top) we are able to efficiently build them, building a package for one will also built it for other servers.
Combine that with teh ability to deploy them via our own selfhosted CI/CD we have a strong foundation to work off of.
