nixos-facter is the spiritual successor to hardware-configuration.nix, which is generated by nixos-generate-config. Unlike its predecessor, nixos-facter generates a JSON file containing information about all connected hardware, rather than Nix code. This JSON output can be interpreted more flexibly using a set of NixOS modules.
We have tested nixos-facter extensively over several months in Clan and nixos-anywhere. Based on its stability and performance, we are now confident enough to remove its beta label and officially move it to nix-community.
Our next step will be to gradually migrate NixOS modules to nixpkgs.
Curious about nixos-facter? You can set it up in two simple steps.
Big thanks to @brianmcgee for all the bug fixing!
How would I pare down the resulting JSON file to only the things needed by NixOS? For comparison, nixos-generate-config generates 24 lines of Nix code, while nixos-facter generates 5692 lines of JSON, including things like which keyboard is connected.
This is not supported and also not planned. Nix uses a fast JSON parser so that the overhead of keeping all data shouldn’t have a big impact. On the upside it allows to evolve modules without having to regenerate the hardware report.
Ok actually one can disable modules when running nixos-facter but at the moment we assume all of them are enabled. So it would be best effort if it works with less
Seems like a nice idea, I’m already using a pattern of defining host hardware capabilities etc in the configuration and then having bunch of custom modules that then are toggled and configured based on those capabilities. This seems like a good step towards not having to define those manually for each host.
For me, it created a 257k JSON file with 10892 of lines, including attached USB devices…
That would be more than 5 MB of JSON files for my currently 20 hosts in my nixcfg repository just on the first commit.
Not sure if that’s your concern, but I’m pretty sure git stores compressed objects, so it wouldn’t mean 5MB of additional data transferred when cloning your repo.
We do networking a bit differently i.e. use the networkd backend. But it would be useful if you could open an issue for that and also point us how wsl normally does networking (i.e. if it uses dhcp)
How does nixos-facter interact with and compare to nixos-hardware? Currently I use nixos-hardware with my laptop model. Of course nixos-facter is automated, while nixos-hardware contains “hand-picked” configurations, but aside from that, I’d be interested if there’s any diverging goals or something like that.
It’s with nixos-hardware compatible. We hope we can remove the amount of manually written code in nixos-hardware with nixos-facter, but that would require the community to switch. Some quirks will always be present and cannot be auto-detected
We also see the opportunity to suggest nixos-hardware modules based on sku names, but we haven’t figured out how yet.
I might be misunderstanding you. Are you saying that there is no way to inspect the list of modifications that nixos-facter-modules is going to apply to your system? If so, this seems like it would be a serious dealbreaker for most NixOS users.
The JSON files produced by nixos-facter aren’t human-readable / interpretable. The configuration changes applied by nixos-facter-modules are not exposed to the user. Should the users just blindly run nixos-facter + nixos-facter-modules and then hope/pray that the resulting configuration changes work / make sense / are optimal for their system?
I understand your concern, and we’re trying to figure out the best way to provide a config diff.
For example, I had an initial prototype which would traverse options and introspect definitionsWithLocations to provide a facter.debug config entry you could use to see what was being set by nixos-facter. It worked in a simple VM but quickly led to infinite recursion errors. You can see it here
There’s also some discussion about using nix-diffhere.
A robust solution for this is most definitely something we need.
I meant to pick @roberth’s brain some more on this over the weekend at FOSDEM. We’re open to suggestions.
I completely agree with ruro. With how much pain I went through setting up nvidia on my previous system, I would not use a tool that modifies kernel modules without showing changes.
While I have no idea if this is at all technically relevant, I have greatly enjoyed the UX of nvd to see package differences.
But please don’t take it to heart, I am keen to see this succeed!
Woah talk about turnaround times! that NVD output looks awesome, and it’s exactly what I was thinking of. It gives new users a clear output of what it does (and by extension what they didn’t even know they were missing out on).