<nixpkgs/nixos> is an expert system database


#1

This isn’t a question, or answer, or announcement, just a public note that should actually be a blog post.

I’ve been always looking at NixOS modules codebase and it made me worry - “I see some pattern here, but I don’t understand which one”. But now I understand: NixOS modules is one of the largest world expert systems, with knowledge acquired from dozens of sysadmins and devops. How come?

Expert system

Expert system is a database of rules, made in IF…THEN… format. Then, given a set of “facts”, inference engine uses that database or rules to make some conclusions. What distinguish expert system from algorithm, is that rules are separated from each other, and rules are evaluated in a way to minimize infinite recursion problems.

In NixOS module system we specify facts by making option declarations in configuration.nix:

networking.hostname = "my-computer";

Now networking.hostname is a fact. configuration.nix is user-supplied fact database.

In NixOS module system, we have if and mkIf, which allow us to specify rules which operate on facts. In expert system the condition in mkIf is called LHS (left-hand side) and return value is called RHS (right-hand side). RHS in NixOS’s mkIf can add new facts:

systemd.services.my-service = mkIf config.services.my-service.enable {
   after = [ "network-setup.target" ];
};

Here systemd.services.my-service.after fact can be added to fact database after mkIf config.services.my-service.enable rule fired. Note that there are 1000+ mkIf calls in NixOS modules codebase, this corresponds to 1000+ rules defined.

On the differences with expert system, NixOS has conflict resolution strategy on fact level, not rule level. NixOS module system also have facts merge semantics. If two modules specify networking.nameservers = [ "8.8.8.8" ]; and networking.nameservers = [ "8.8.4.4" ];, this won’t make conflicts. Resolution would be combined list of strings. By using mkOrder, mkForce, mkDefault, mkOverride and other we set conflict strategy for facts. When all fact conflicts are resolved, module system fires all possible rules, to generate all possible facts. That is also an insight why it is impossible to remove facts in NixOS rule RHS.

So next time you do nixos-rebuild switch, recall that you’re evaluating expert system, one of the successful applications of AI to real-world domain.


Systemd backend or "using NixOps to manage Ubuntu"
Best resources for learning about the NixOS module system?
#2

Very interesting!

Now that we know that NixOS can be seen as an expert system, what can NixOS learn from other expert systems?


#3

Now that we know that NixOS can be seen as an expert system, what can NixOS learn from other expert systems?

Not that NixOS can learn, but existence of Module System, and it’s practical application (NixOS) should drive researchers. I’m quite surprised that Nix maternity company, given it’s background in Datalog, doesn’t sponsor research for NixOS (or doesn’t do it in public). Probably there still isn’t enough critical mass.

I see there are efforts to push Nix into HPC (and LHC) world. Also, I believe NixOS (or it’s variant) will get some certifications in future, which will allow it to become most wanted distribution for scientific machines (that would require lots of breaking refactors for NixOS though).