chore: rebrand Nix to Lix when it makes sense

Here's my guide so far:

$ rg '((?!(recursive).*) Nix
(?!(daemon|store|expression|Rocks!|Packages|language|derivation|archive|account|user|sandbox|flake).*))'
-g '!doc/' --pcre2

All items from this query have been tackled. For the documentation side:
that's for https://git.lix.systems/lix-project/lix/issues/162.

Additionally, all remaining references to github.com/NixOS/nix which
were not relevant were also replaced.

Fixes: https://git.lix.systems/lix-project/lix/issues/148.
Fixes: https://git.lix.systems/lix-project/lix/issues/162.
Change-Id: Ib3451fae5cb8ab8cd9ac9e4e4551284ee6794545
Signed-off-by: Raito Bezarius <raito@lix.systems>

1 files changed, 2 insertions, 2 deletions

diff --git a/src/libstore/globals.cc b/src/libstore/globals.cc
index 993a8cfa5..763dc9158 100644
--- a/src/libstore/globals.cc
+++ b/src/libstore/globals.cc
@@ -87,7 +87,7 @@ Settings::Settings()
 
     /* Set the build hook location
 
-       For builds we perform a self-invocation, so Nix has to be self-aware.
+       For builds we perform a self-invocation, so Lix has to be self-aware.
        That is, it has to know where it is installed. We don't think it's sentient.
 
        Normally, nix is installed according to `nixBinDir`, which is set at compile time,
@@ -101,7 +101,7 @@ Settings::Settings()
        current executable, using `getSelfExe()`.
 
        As a last resort, we resort to `PATH`. Hopefully we find a `nix` there that's compatible.
-       If you're porting Nix to a new platform, that might be good enough for a while, but
+       If you're porting Lix to a new platform, that might be good enough for a while, but
        you'll want to improve `getSelfExe()` to work on your platform.
      */
     std::string nixExePath = nixBinDir + "/nix";