From 95d53c5c9a14de412216a1bdf2e0dd739d17564e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christina=20S=C3=B8rensen?= Date: Thu, 5 Sep 2024 09:44:01 +0200 Subject: [PATCH] docs: move usage before how it works MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Christina Sørensen --- README.md | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index ef2a9fa..c8da98d 100644 --- a/README.md +++ b/README.md @@ -21,20 +21,6 @@ weather`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-weather.html). -## How It Works - -The basic idea is that we construct a set of all requisites to build the -top-level of a NixOS configuration, and then query Nix cache(s) for the narinfo. -By doing this in a high concurrency, parallel task runner (i.e. tokio async -runtime), and only querying the headers for status codes, we can reach -impressive speeds, typically around 45~ network time. - -One of the biggest limiting factors regarding speed is building the -`config.system.toplevel`, and finding the necessary requisites with `nix-store`. -Caching the requisites is a future goal, so that we only have to build the -`toplevel`, and then match against its derivation in cache, which should cut -down the nix part of the runtime by ~80%. - ## Usage > **Note** @@ -49,3 +35,16 @@ nix-weather --name myhost --config ~/git/my-nixos-config Here, we specify the name of the host, as specified at the flake output `nixosConfiguration`, and a path to the NixOS configuration flake. +## How It Works + +The basic idea is that we construct a set of all requisites to build the +top-level of a NixOS configuration, and then query Nix cache(s) for the narinfo. +By doing this in a high concurrency, parallel task runner (i.e. tokio async +runtime), and only querying the headers for status codes, we can reach +impressive speeds, typically around 45~ network time. + +One of the biggest limiting factors regarding speed is building the +`config.system.toplevel`, and finding the necessary requisites with `nix-store`. +Caching the requisites is a future goal, so that we only have to build the +`toplevel`, and then match against its derivation in cache, which should cut +down the nix part of the runtime by ~80%.