fixup! blog: introducing nixos-facter

Emphasise that we can make more interesting config choices, not just replicate nixos-generate-config.

docs/site/blog/posts/nixos-facter.md

@@ -25,12 +25,14 @@ To account for this, you could always run `nixos-generate-config` again. But tha
 
 What if, instead of generating some Nix code, we first describe the current hardware in an intermediate format? This hardware report would be _'pure'_, devoid of any reference to NixOS, and intended as a stable, longer-term representation of the system.
 
-From here, we can create a series of NixOS modules designed to examine the report's contents and make the same kinds of decisions that `nixos-generate-config` does. The critical difference is that as NixOS evolves, so can these modules.
+From here, we can create a series of NixOS modules designed to examine the report's contents and make the same kinds of decisions that `nixos-generate-config` does. The critical difference is that as NixOS evolves, so can these modules, and with a full hardware report available we can make more interesting config choices about things such as GPUs and other devices. 
 
 In a perfect world, we should not need to regenerate the underlying report as long as there are no hardware changes. We can take this one step further.
 
 Provided that certain sensitive information, such as serial numbers and MAC addresses, is filtered out, there is no reason why these hardware reports could not be shared after they are generated for things like EC2 instance types, specific laptop models, and so on, much like [NixOS Hardware] currently shares Nix configs.
 
+
+
 ## Introducing NixOS Facter
 
 Still in its early stages, [Nixos Facter] is intended to do what I've described above.