+FIXME(meson): this section is wrong for meson and commented out accordingly. See "Running Tests" above, and ask the Lix team if you need further clarification.
+
+
+
+
### Debugging failing functional tests
When a functional test fails, it usually does so somewhere in the middle of the script.
@@ -170,6 +184,10 @@ edit it like so:
bar
```
+
+FIXME(meson): this is incorrect for meson. `_NIX_TEST_ACCEPT=1` is still valid but the test invocation needs to change.
+
+
It is frequently useful to regenerate the expected output.
To do that, rerun the failed test(s) with `_NIX_TEST_ACCEPT=1`.
For example:
@@ -214,14 +236,21 @@ To ensure that characterization testing doesn't make it harder to intentionally
## Integration tests
The integration tests are defined in the Nix flake under the `hydraJobs.tests` attribute.
-These tests include everything that needs to interact with external services or run Nix in a non-trivial distributed setup.
+These tests include everything that needs to interact with external services or run Lix in a non-trivial distributed setup.
Because these tests are expensive and require more than what the standard github-actions setup provides, they only run on the master branch (on ).
You can run them manually with `nix build .#hydraJobs.tests.{testName}` or `nix-build -A hydraJobs.tests.{testName}`
+
+
+Installer tests section is outdated and commented out, see https://git.lix.systems/lix-project/lix/issues/33
+
+
+
+
diff --git a/doc/manual/src/glossary.md b/doc/manual/src/glossary.md
index b7c340d36..caf740724 100644
--- a/doc/manual/src/glossary.md
+++ b/doc/manual/src/glossary.md
@@ -57,12 +57,12 @@
The location in the file system where store objects live. Typically
`/nix/store`.
- From the perspective of the location where Nix is
+ From the perspective of the location where Lix is
invoked, the Nix store can be referred to
as a "_local_" or a "_remote_" one:
+ A [local store]{#gloss-local-store} exists on the filesystem of
- the machine where Nix is invoked. You can use other
+ the machine where Lix is invoked. You can use other
local stores by passing the `--store` flag to the
`nix` command. Local stores can be used for building derivations.
@@ -133,7 +133,7 @@
- [substituter]{#gloss-substituter}
- An additional [store]{#gloss-store} from which Nix can obtain store objects instead of building them.
+ An additional [store]{#gloss-store} from which Lix can obtain store objects instead of building them.
Often the substituter is a [binary cache](#gloss-binary-cache), but any store can serve as substituter.
See the [`substituters` configuration option](./command-ref/conf-file.md#conf-substituters) for details.
@@ -159,7 +159,7 @@
- [Nix expression]{#gloss-nix-expression}
A high-level description of software packages and compositions
- thereof. Deploying software using Nix entails writing Nix
+ thereof. Deploying software using Lix entails writing Nix
expressions for your packages. Nix expressions are translated to
derivations that are stored in the Nix store. These derivations can
then be built.
diff --git a/doc/manual/src/installation/building-source.md b/doc/manual/src/installation/building-source.md
index d57f42c5a..83c645ae7 100644
--- a/doc/manual/src/installation/building-source.md
+++ b/doc/manual/src/installation/building-source.md
@@ -1,6 +1,13 @@
-# Building Nix from Source
+# Building Lix from Source
-After cloning Nix's Git repository, issue the following commands:
+
+
+FIXME(meson): This section is outdated for meson and has been commented out. See https://git.lix.systems/lix-project/lix/issues/258
+
+
+
+
diff --git a/doc/manual/src/installation/env-variables.md b/doc/manual/src/installation/env-variables.md
index db98f52ff..fb6f02e41 100644
--- a/doc/manual/src/installation/env-variables.md
+++ b/doc/manual/src/installation/env-variables.md
@@ -1,6 +1,6 @@
# Environment Variables
-To use Nix, some environment variables should be set. In particular,
+To use Lix, some environment variables should be set. In particular,
`PATH` should contain the directories `prefix/bin` and
`~/.nix-profile/bin`. The first directory contains the Nix tools
themselves, while `~/.nix-profile` is a symbolic link to the current
@@ -16,20 +16,30 @@ source prefix/etc/profile.d/nix.sh
# `NIX_SSL_CERT_FILE`
+
+
+FIXME(Lix): This section is undoubtedly wrong due to the Lix installer being replaced. The definitely-wrong install section has been commented out.
+
+
+
If you need to specify a custom certificate bundle to account for an
HTTPS-intercepting man in the middle proxy, you must specify the path to
the certificate bundle in the environment variable `NIX_SSL_CERT_FILE`.
-If you don't specify a `NIX_SSL_CERT_FILE` manually, Nix will install
+If you don't specify a `NIX_SSL_CERT_FILE` manually, Lix will install
and use its own certificate bundle.
-Set the environment variable and install Nix
+
+
In the shell profile and rc files (for example, `/etc/bashrc`,
`/etc/zshrc`), add the following line:
@@ -39,10 +49,10 @@ export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt
> **Note**
>
-> You must not add the export and then do the install, as the Nix
+> You must not add the export and then do the install, as the Lix
> installer will detect the presence of Nix configuration, and abort.
-If you use the Nix daemon, you should also add the following to
+If you use the Lix daemon, you should also add the following to
`/etc/nix/nix.conf`:
```
@@ -51,11 +61,11 @@ ssl-cert-file = /etc/ssl/my-certificate-bundle.crt
## Proxy Environment Variables
-The Nix installer has special handling for these proxy-related
+The Lix installer has special handling for these proxy-related
environment variables: `http_proxy`, `https_proxy`, `ftp_proxy`,
`no_proxy`, `HTTP_PROXY`, `HTTPS_PROXY`, `FTP_PROXY`, `NO_PROXY`.
-If any of these variables are set when running the Nix installer, then
+If any of these variables are set when running the Lix installer, then
the installer will create an override file at
`/etc/systemd/system/nix-daemon.service.d/override.conf` so `nix-daemon`
will use them.
diff --git a/doc/manual/src/installation/installation.md b/doc/manual/src/installation/installation.md
index dafdeb667..d05445eab 100644
--- a/doc/manual/src/installation/installation.md
+++ b/doc/manual/src/installation/installation.md
@@ -1,38 +1,15 @@
# Installation
-This section describes how to install and configure Nix for first-time use.
+See https://lix.systems/install/ for more details.
-The current recommended option on Linux and MacOS is [multi-user](#multi-user).
+
diff --git a/doc/manual/src/installation/installing-binary.md b/doc/manual/src/installation/installing-binary.md
index ffabb250a..c2edc0dc2 100644
--- a/doc/manual/src/installation/installing-binary.md
+++ b/doc/manual/src/installation/installing-binary.md
@@ -1,5 +1,11 @@
# Installing a Binary Distribution
+See https://lix.systems/install/ for more details.
+
+
+
We believe we have ironed out how to cleanly support the read-only root
on modern macOS. New installs will do this automatically.
@@ -101,7 +107,7 @@ this to run the installer, but it may help if you run into trouble:
- `nobrowse`: prevent the Nix Store volume from showing up on your
desktop; also keeps Spotlight from spending resources to index
this volume
-
+ ~~>
- if you have FileVault enabled
- generate an encryption password
- put it in your system Keychain
@@ -156,3 +162,5 @@ $ ./install
If you need to edit the multi-user installation script to use different
group ID or a different user ID range, modify the variables set in the
file named `install-multi-user`.
+
+-->
diff --git a/doc/manual/src/installation/installing-docker.md b/doc/manual/src/installation/installing-docker.md
index 9d6d8f2d9..2d7701024 100644
--- a/doc/manual/src/installation/installing-docker.md
+++ b/doc/manual/src/installation/installing-docker.md
@@ -1,6 +1,10 @@
-# Using Nix within Docker
+# Using Lix within Docker
-To run the latest stable release of Nix with Docker run the following command:
+Currently the Lix project doesn't ship docker images. However, we have the infrastructure to do it, it's just not yet been done. See https://git.lix.systems/lix-project/lix/issues/252
+
+
diff --git a/doc/manual/src/installation/installing-source.md b/doc/manual/src/installation/installing-source.md
index 09b4e4887..06d070610 100644
--- a/doc/manual/src/installation/installing-source.md
+++ b/doc/manual/src/installation/installing-source.md
@@ -1,4 +1,4 @@
-# Installing Nix from Source
+# Installing Lix from Source
-If no binary package is available or if you want to hack on Nix, you
-can build Nix from its Git repository.
+If no binary package is available or if you want to hack on Lix, you
+can build Lix from its Git repository.
diff --git a/doc/manual/src/installation/nix-security.md b/doc/manual/src/installation/nix-security.md
index 1e9036b68..d5ae7535d 100644
--- a/doc/manual/src/installation/nix-security.md
+++ b/doc/manual/src/installation/nix-security.md
@@ -1,15 +1,15 @@
# Security
-Nix has two basic security models. First, it can be used in “single-user
+Lix has two basic security models. First, it can be used in “single-user
mode”, which is similar to what most other package management tools do:
there is a single user (typically root) who performs all package
management operations. All other users can then use the installed
packages, but they cannot perform package management operations
themselves.
-Alternatively, you can configure Nix in “multi-user mode”. In this
+Alternatively, you can configure Lix in “multi-user mode”. In this
model, all users can perform package management operations — for
instance, every user can install software without requiring root
-privileges. Nix ensures that this is secure. For instance, it’s not
+privileges. Lix ensures that this is secure. For instance, it’s not
possible for one user to overwrite a package used by another user with a
Trojan horse.
diff --git a/doc/manual/src/installation/prerequisites-source.md b/doc/manual/src/installation/prerequisites-source.md
index d4babf1ea..8584f295a 100644
--- a/doc/manual/src/installation/prerequisites-source.md
+++ b/doc/manual/src/installation/prerequisites-source.md
@@ -1,5 +1,15 @@
# Prerequisites
+
+
+FIXME(meson): This section is very wrong with respect to meson and we have commented it out.
+We are sorry.
+The most current alternative to this section is to read `package.nix` and see which things are being depended on.
+
+
+
+
diff --git a/doc/manual/src/installation/supported-platforms.md b/doc/manual/src/installation/supported-platforms.md
index 8ca3ce8d4..3b07ce48a 100644
--- a/doc/manual/src/installation/supported-platforms.md
+++ b/doc/manual/src/installation/supported-platforms.md
@@ -1,7 +1,11 @@
# Supported Platforms
-Nix is currently supported on the following platforms:
+Lix is currently supported on the following platforms:
- - Linux (i686, x86\_64, aarch64).
+ - Linux (i686 (tier 2), x86\_64 (tier 1), aarch64 (tier 1)).
- - macOS (x86\_64, aarch64).
+ - macOS (x86\_64 (tier 2 [(issue to make tier 1)](https://git.lix.systems/lix-project/lix/issues/269)), aarch64 (tier 1)).
+
+
+Tier 2 platforms aren't checked in CI, so may break without notice; such breakage *is* however considered a bug.
+We would like for them to work but they are a secondary priority.
diff --git a/doc/manual/src/installation/uninstall.md b/doc/manual/src/installation/uninstall.md
index 06dab6cdb..5fb8b56e4 100644
--- a/doc/manual/src/installation/uninstall.md
+++ b/doc/manual/src/installation/uninstall.md
@@ -1,8 +1,18 @@
-# Uninstalling Nix
+# Uninstalling Lix
+
+
+
+FIXME(Lix): This section is outdated and commented out due to the Lix installer being replaced such that it has an actual uninstaller.
+
+See https://git.lix.systems/lix-project/lix-installer#uninstalling for up-to-date uninstallation instructions using the installer.
+
+
+
+
diff --git a/doc/manual/src/installation/upgrading.md b/doc/manual/src/installation/upgrading.md
index 6d09f54d8..2cdbf9683 100644
--- a/doc/manual/src/installation/upgrading.md
+++ b/doc/manual/src/installation/upgrading.md
@@ -1,14 +1,23 @@
-# Upgrading Nix
+# Upgrading Lix
-Multi-user Nix users on macOS can upgrade Nix by running: `sudo -i sh -c
-'nix-channel --update &&
-nix-env --install --attr nixpkgs.nix &&
-launchctl remove org.nixos.nix-daemon &&
-launchctl load /Library/LaunchDaemons/org.nixos.nix-daemon.plist'`
+
-Single-user installations of Nix should run this: `nix-channel --update;
-nix-env --install --attr nixpkgs.nix nixpkgs.cacert`
+FIXME(Lix): does Lix forward to the installer for `nix upgrade-nix`? Should it, if present? Lix *should* restart the daemon for you [but currently doesn't (issue)](https://git.lix.systems/lix-project/lix/issues/267).
-Multi-user Nix users on Linux should run this with sudo: `nix-channel
---update; nix-env --install --attr nixpkgs.nix nixpkgs.cacert; systemctl
-daemon-reload; systemctl restart nix-daemon`
+
+
+**For instructions to switch to Lix**, see .
+
+Lix may be upgraded by running `nix upgrade-nix` and then restarting the Nix daemon.
+
+## Restarting daemon on Linux
+
+`sudo systemctl daemon-reload && sudo systemctl restart nix-daemon`
+
+## Restarting daemon on macOS
+
+
+
+FIXME(Lix): Write instructions that, according to the [beta installation guide](https://wiki.lix.systems/link/1) do not sometimes crash macOS (?!)
+
+
diff --git a/doc/manual/src/introduction.md b/doc/manual/src/introduction.md
index 76489bc1b..9fbc429f8 100644
--- a/doc/manual/src/introduction.md
+++ b/doc/manual/src/introduction.md
@@ -1,12 +1,8 @@
# Introduction
-Nix is a _purely functional package manager_. This means that it
-treats packages like values in purely functional programming languages
-such as Haskell — they are built by functions that don’t have
-side-effects, and they never change after they have been built. Nix
-stores packages in the _Nix store_, usually the directory
-`/nix/store`, where each package has its own unique subdirectory such
-as
+Lix is an implementation of Nix, a powerful, _purely functional_ package management system.
+This means that it treats packages like values in purely functional programming languages such as Haskell — they are built by functions that don’t have side-effects, and they never change after they have been built.
+Lix stores packages in the _Nix store_, usually the directory `/nix/store`, where each package has its own unique subdirectory such as
/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/
@@ -31,7 +27,7 @@ used by other packages.
## Complete dependencies
-Nix helps you make sure that package dependency specifications are
+Lix helps you make sure that package dependency specifications are
complete. In general, when you’re making a package for a package
management system like RPM, you have to specify for each package what
its dependencies are, but there are no guarantees that this
@@ -40,7 +36,7 @@ package will build and work correctly on _your_ machine if you have
the dependency installed, but not on the end user's machine if it's
not there.
-Since Nix on the other hand doesn’t install packages in “global”
+Since Lix on the other hand doesn’t install packages in “global”
locations like `/usr/bin` but in package-specific directories, the
risk of incomplete dependencies is greatly reduced. This is because
tools such as compilers don’t search in per-packages directories such
@@ -54,13 +50,11 @@ This sounds risky, but it works extremely well.
## Multi-user support
-Nix has multi-user support. This means that non-privileged users can
-securely install software. Each user can have a different _profile_,
-a set of packages in the Nix store that appear in the user’s `PATH`.
-If a user installs a package that another user has already installed
-previously, the package won’t be built or downloaded a second time.
-At the same time, it is not possible for one user to inject a Trojan
-horse into a package that might be used by another user.
+Lix has multi-user support.
+This means that non-privileged users can securely install software, and it is considered a bug if users can trample on each other.
+Each user can have a different _profile_, a set of packages in the Nix store that appear in the user’s `PATH`.
+If a user installs a package that another user has already installed previously, the package won’t be built or downloaded a second time.
+At the same time, it is not possible for one user to inject a Trojan horse into a package that might be used by another user.
## Atomic upgrades and rollbacks
@@ -106,7 +100,7 @@ Packages are built from _Nix expressions_, which is a simple
functional language. A Nix expression describes everything that goes
into a package build task (a “derivation”): other packages, sources,
the build script, environment variables for the build script, etc.
-Nix tries very hard to ensure that Nix expressions are
+Lix tries very hard to ensure that Nix expressions are
_deterministic_: building a Nix expression twice should yield the same
result.
@@ -130,22 +124,21 @@ also all its dependencies (all the way up to the C library and the
compiler) would have to be built, at least if they are not already in the
Nix store. This is a _source deployment model_. For most users,
building from source is not very pleasant as it takes far too long.
-However, Nix can automatically skip building from source and instead
+However, Lix can automatically skip building from source and instead
use a _binary cache_, a web server that provides pre-built
binaries. For instance, when asked to build
-`/nix/store/b6gvzjyb2pg0…-firefox-33.1` from source, Nix would first
+`/nix/store/b6gvzjyb2pg0…-firefox-33.1` from source, Lix would first
check if the file `https://cache.nixos.org/b6gvzjyb2pg0….narinfo`
exists, and if so, fetch the pre-built binary referenced from there;
otherwise, it would fall back to building from source.
## Nix Packages collection
-We provide a large set of Nix expressions containing hundreds of
-existing Unix packages, the _Nix Packages collection_ (Nixpkgs).
+We provide a large set of Nix expressions containing tens of thousands of existing Unix packages, the _Nix Packages collection_ (Nixpkgs).
## Managing build environments
-Nix is extremely useful for developers as it makes it easy to
+Lix is extremely useful for developers as it makes it easy to
automatically set up the build environment for a package. Given a Nix
expression that describes the dependencies of your package, the
command `nix-shell` will build or download those dependencies if
@@ -174,11 +167,11 @@ the package:
## Portability
-Nix runs on Linux and macOS.
+Lix runs on Linux and macOS.
## NixOS
-NixOS is a Linux distribution based on Nix. It uses Nix not just for
+NixOS is a Linux distribution based on Nix technology. It uses Nix not just for
package management but also to manage the system configuration (e.g.,
to build configuration files in `/etc`). This means, among other
things, that it is easy to roll back the entire configuration of the
@@ -188,6 +181,6 @@ homepage](https://nixos.org/).
## License
-Nix is released under the terms of the [GNU LGPLv2.1 or (at your
+Lix is released under the terms of the [GNU LGPLv2.1 or (at your
option) any later
version](http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html).
diff --git a/doc/manual/src/language/advanced-attributes.md b/doc/manual/src/language/advanced-attributes.md
index a5ad47a93..ec21b9990 100644
--- a/doc/manual/src/language/advanced-attributes.md
+++ b/doc/manual/src/language/advanced-attributes.md
@@ -116,7 +116,7 @@ Derivations can declare some infrequently used optional attributes.
These attributes declare that the derivation is a so-called
*fixed-output derivation*, which means that a cryptographic hash of
the output is already known in advance. When the build of a
- fixed-output derivation finishes, Nix computes the cryptographic
+ fixed-output derivation finishes, Lix computes the cryptographic
hash of the output and compares it to the hash declared with these
attributes. If there is a mismatch, the build fails.
@@ -241,7 +241,7 @@ Derivations can declare some infrequently used optional attributes.
then when the builder runs, the environment variable `bigPath`
will contain the absolute path to a temporary file containing `a
very long string`. That is, for any attribute *x* listed in
- `passAsFile`, Nix will pass an environment variable `xPath`
+ `passAsFile`, Lix will pass an environment variable `xPath`
holding the path of the file containing the value of attribute
*x*. This is useful when you need to pass large strings to a
builder, since most operating systems impose a limit on the size
@@ -256,13 +256,13 @@ Derivations can declare some infrequently used optional attributes.
the cost of building locally.
- [`allowSubstitutes`]{#adv-attr-allowSubstitutes}\
- If this attribute is set to `false`, then Nix will always build this
+ If this attribute is set to `false`, then Lix will always build this
derivation; it will not try to substitute its outputs. This is
useful for very trivial derivations (such as `writeText` in Nixpkgs)
that are cheaper to build than to substitute from a binary cache.
You may disable the effects of this attibute by enabling the
- `always-allow-substitutes` configuration option in Nix.
+ `always-allow-substitutes` configuration option in Lix.
> **Note**
>
@@ -284,7 +284,7 @@ Derivations can declare some infrequently used optional attributes.
[`outputChecks`](#adv-attr-outputChecks) for example.
As a convenience to Bash builders,
- Nix writes a script that initialises shell variables
+ Lix writes a script that initialises shell variables
corresponding to all attributes that are representable in Bash. The
environment variable `NIX_ATTRS_SH_FILE` points to the exact
location of the script, both in a build and a
diff --git a/doc/manual/src/language/derivations.md b/doc/manual/src/language/derivations.md
index 1dceacab7..c10e8149d 100644
--- a/doc/manual/src/language/derivations.md
+++ b/doc/manual/src/language/derivations.md
@@ -61,7 +61,7 @@ the attributes of which specify the inputs of the build.
outputs = [ "lib" "headers" "doc" ];
```
- This will cause Nix to pass environment variables `lib`, `headers`
+ This will cause Lix to pass environment variables `lib`, `headers`
and `doc` to the builder containing the intended store paths of each
output. The builder would typically do something like
@@ -137,7 +137,7 @@ The builder is executed as follows:
it’s `out`.)
- If an output path already exists, it is removed. Also, locks are
- acquired to prevent multiple Nix instances from performing the same
+ acquired to prevent multiple Lix instances from performing the same
build at the same time.
- A log of the combined standard output and error is written to
@@ -150,17 +150,17 @@ The builder is executed as follows:
- The temporary directory is removed (unless the `-K` option was
specified).
- - If the build was successful, Nix scans each output path for
+ - If the build was successful, Lix scans each output path for
references to input paths by looking for the hash parts of the input
- paths. Since these are potential runtime dependencies, Nix registers
+ paths. Since these are potential runtime dependencies, Lix registers
them as dependencies of the output paths.
- - After the build, Nix sets the last-modified timestamp on all files
+ - After the build, Lix sets the last-modified timestamp on all files
in the build result to 1 (00:00:01 1/1/1970 UTC), sets the group to
the default group, and sets the mode of the file to 0444 or 0555
(i.e., read-only, with execute permission enabled if the file was
originally executable). Note that possible `setuid` and `setgid`
bits are cleared. Setuid and setgid programs are not currently
- supported by Nix. This is because the Nix archives used in
+ supported by Lix. This is because the Lix archives used in
deployment have no concept of ownership information, and because it
makes the build result dependent on the user performing the build.
diff --git a/doc/manual/src/package-management/basic-package-mgmt.md b/doc/manual/src/package-management/basic-package-mgmt.md
index e86ef7396..0d94ea231 100644
--- a/doc/manual/src/package-management/basic-package-mgmt.md
+++ b/doc/manual/src/package-management/basic-package-mgmt.md
@@ -1,11 +1,20 @@
# Basic Package Management
+
+
+FIXME(Lix): This section does not document the most common modern practices in terms of avoiding channels, pinning, declarative software installation (see flakey-profile or home-manager or NixOS), or using flakes, etc.
+It is, however, likely correct at a technical level.
+
+For more information on modern practices, see the [resources](https://lix.systems/resources) page on the Lix site.
+
+
+
The main command for package management is
[`nix-env`](../command-ref/nix-env.md). You can use it to install,
upgrade, and erase packages, and to query what packages are installed
or are available for installation.
-In Nix, different users can have different “views” on the set of
+In Nix systems, different users can have different “views” on the set of
installed applications. That is, there might be lots of applications
present on the system (possibly in many different versions), but users
can have a specific selection of those active — where “active” just
@@ -14,12 +23,12 @@ on the set of installed applications is called a *user environment*,
which is just a directory tree consisting of symlinks to the files of
the active applications.
-Components are installed from a set of *Nix expressions* that tell Nix
+Components are installed from a set of *Nix expressions* that tell Lix
how to build those packages, including, if necessary, their
-dependencies. There is a collection of Nix expressions called the
+dependencies. There is a very large collection of Nix expressions called the
Nixpkgs package collection that contains packages ranging from basic
development stuff such as GCC and Glibc, to end-user applications like
-Mozilla Firefox. (Nix is however not tied to the Nixpkgs package
+Mozilla Firefox. (Lix is however not tied to the Nixpkgs package
collection; you could write your own Nix expressions based on Nixpkgs,
or completely new ones.)
@@ -28,7 +37,7 @@ You can manually download the latest version of Nixpkgs from
convenient to use the Nixpkgs [*channel*](../command-ref/nix-channel.md), since it makes
it easy to stay up to date with new versions of Nixpkgs. Nixpkgs is
automatically added to your list of “subscribed” channels when you
-install Nix. If this is not the case for some reason, you can add it
+install Lix. If this is not the case for some reason, you can add it
as follows:
```console
@@ -107,7 +116,7 @@ present on your system (in which case installing it into your user
environment would be a very quick operation). The last one (`S`)
indicates whether there is a so-called *substitute* for the package,
which is Nix’s mechanism for doing binary deployment. It just means that
-Nix knows that it can fetch a pre-built package from somewhere
+Lix knows that it can fetch a pre-built package from somewhere
(typically a network server) instead of building it locally.
You can install a package using `nix-env --install --attr `. For instance,
@@ -121,12 +130,12 @@ will install the package called `subversion` from `nixpkgs` channel (which is, o
> **Note**
>
-> When you ask Nix to install a package, it will first try to get it in
-> pre-compiled form from a *binary cache*. By default, Nix will use the
+> When you ask Lix to install a package, it will first try to get it in
+> pre-compiled form from a *binary cache*. By default, Lix will use the
> binary cache ; it contains binaries for most
> packages in Nixpkgs. Only if no binary is available in the binary
-> cache, Nix will build the package from source. So if `nix-env
-> -iA nixpkgs.subversion` results in Nix building stuff from source, then either
+> cache, Lix will build the package from source. So if `nix-env
+> -iA nixpkgs.subversion` results in Lix building stuff from source, then either
> the package is not built for your platform by the Nixpkgs build
> servers, or your version of Nixpkgs is too old or too new. For
> instance, if you have a very recent checkout of Nixpkgs, then the
@@ -147,7 +156,7 @@ $ nix-env --uninstall subversion
```
Upgrading to a new version is just as easy. If you have a new release of
-Nix Packages, you can do:
+nixpkgs, you can do:
```console
$ nix-env --upgrade --attr nixpkgs.subversion
diff --git a/doc/manual/src/package-management/binary-cache-substituter.md b/doc/manual/src/package-management/binary-cache-substituter.md
index 855eaf470..4dcf2ca3f 100644
--- a/doc/manual/src/package-management/binary-cache-substituter.md
+++ b/doc/manual/src/package-management/binary-cache-substituter.md
@@ -1,8 +1,21 @@
# Serving a Nix store via HTTP
+
+
+FIXME(Lix): This section documents outdated practices.
+
+In particular, the Lix developers would *not* recommend using `nix-serve` as it is relatively-unmaintained Perl.
+The Lix developers would recommend instead using an s3 based cache (which is what https://cache.nixos.org is), and if it is desired to self-host it, use something like [garage](https://garagehq.deuxfleurs.fr/).
+
+See the following projects:
+- [attic](https://github.com/zhaofengli/attic) - multi-tenant cache for larger deployments, using s3 as a backend.
+- [harmonia](https://github.com/nix-community/harmonia) - closer to a drop in replacement for use cases served by nix-serve
+
+
+
You can easily share the Nix store of a machine via HTTP. This allows
other machines to fetch store paths from that machine to speed up
-installations. It uses the same *binary cache* mechanism that Nix
+installations. It uses the same *binary cache* mechanism that Lix
usually uses to fetch pre-built binaries from .
The daemon that handles binary cache requests via HTTP, `nix-serve`, is
@@ -31,20 +44,19 @@ which should print something like:
WantMassQuery: 1
Priority: 30
-On the client side, you can tell Nix to use your binary cache using
-`--substituters`, e.g.:
+On the client side, you can tell Lix to use your binary cache using `--substituters` (assuming you are a trusted user, see `trusted-users` in nix.conf), e.g.:
```console
$ nix-env --install --attr nixpkgs.firefox --substituters http://avalon:8080/
```
-The option `substituters` tells Nix to use this binary cache in
+The option `substituters` tells Lix to use this binary cache in
addition to your default caches, such as .
-Thus, for any path in the closure of Firefox, Nix will first check if
+Thus, for any path in the closure of Firefox, Lix will first check if
the path is available on the server `avalon` or another binary caches.
If not, it will fall back to building from source.
-You can also tell Nix to always use your binary cache by adding a line
+You can also tell Lix to always use your binary cache by adding a line
to the `nix.conf` configuration file like this:
substituters = http://avalon:8080/ https://cache.nixos.org/
diff --git a/doc/manual/src/package-management/garbage-collection.md b/doc/manual/src/package-management/garbage-collection.md
index 29a3b3101..07ca29365 100644
--- a/doc/manual/src/package-management/garbage-collection.md
+++ b/doc/manual/src/package-management/garbage-collection.md
@@ -6,7 +6,7 @@ is to create a new user environment that no longer contains symlinks to
the “deleted” packages.
Of course, since disk space is not infinite, unused packages should be
-removed at some point. You can do this by running the Nix garbage
+removed at some point. You can do this by running the Lix garbage
collector. It will remove from the Nix store any package not used
(directly or indirectly) by any generation of any profile.
diff --git a/doc/manual/src/package-management/package-management.md b/doc/manual/src/package-management/package-management.md
index d528112e2..274986663 100644
--- a/doc/manual/src/package-management/package-management.md
+++ b/doc/manual/src/package-management/package-management.md
@@ -1,4 +1,4 @@
-This chapter discusses how to do package management with Nix, i.e.,
+This chapter discusses how to do package management with Lix, i.e.,
how to obtain, install, upgrade, and erase packages. This is the
“user’s” perspective of the Nix system — people who want to *create*
packages should consult the chapter on the [Nix language](../language/index.md).
diff --git a/doc/manual/src/package-management/s3-substituter.md b/doc/manual/src/package-management/s3-substituter.md
index d8a1d9105..55182128b 100644
--- a/doc/manual/src/package-management/s3-substituter.md
+++ b/doc/manual/src/package-management/s3-substituter.md
@@ -1,17 +1,28 @@
# Serving a Nix store via S3
-Nix has [built-in support](@docroot@/command-ref/new-cli/nix3-help-stores.md#s3-binary-cache-store)
-for storing and fetching store paths from
-Amazon S3 and S3-compatible services. This uses the same *binary*
-cache mechanism that Nix usually uses to fetch prebuilt binaries from
+Lix has [built-in support](@docroot@/command-ref/new-cli/nix3-help-stores.md#s3-binary-cache-store)
+for storing and fetching store paths from Amazon S3 and S3-compatible services.
+
+
+
+FIXME(Lix): document the correct setup to fetch from a s3 cache via HTTP rather than just through `s3://` (which works, but forces you to remain s3-like on the client side)
+
+
+
+
In this example we will use the bucket named `example-nix-cache`.
## Anonymous Reads to your S3-compatible binary cache
If your binary cache is publicly accessible and does not require
-authentication, the simplest and easiest way to use Nix with your S3
+authentication, the simplest and easiest way to use Lix with your S3
compatible binary cache is to use the HTTP URL for that cache.
For AWS S3 the binary cache URL for example bucket will be exactly
@@ -48,11 +59,11 @@ Your bucket will need the following bucket policy:
For AWS S3 the binary cache URL for example bucket will be exactly
.
-Nix will use the [default credential provider
+Lix will use the [default credential provider
chain](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/credentials.html)
for authenticating requests to Amazon S3.
-Nix supports authenticated reads from Amazon S3 and S3 compatible binary
+Lix supports authenticated reads from Amazon S3 and S3 compatible binary
caches.
Your bucket will need a bucket policy allowing the desired users to
@@ -63,11 +74,11 @@ updated to have a restricted `Principal` to support this.
## Authenticated Writes to your S3-compatible binary cache
-Nix support fully supports writing to Amazon S3 and S3 compatible
+Lix support fully supports writing to Amazon S3 and S3 compatible
buckets. The binary cache URL for our example bucket will be
.
-Nix will use the [default credential provider
+Lix will use the [default credential provider
chain](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/credentials.html)
for authenticating requests to Amazon S3.
diff --git a/doc/manual/src/package-management/ssh-substituter.md b/doc/manual/src/package-management/ssh-substituter.md
index bd07b97cc..44dc3ef84 100644
--- a/doc/manual/src/package-management/ssh-substituter.md
+++ b/doc/manual/src/package-management/ssh-substituter.md
@@ -1,6 +1,6 @@
# Serving a Nix store via SSH
-You can tell Nix to automatically fetch needed binaries from a remote
+You can tell Lix to automatically fetch needed binaries from a remote
Nix store via SSH. For example, the following installs Firefox,
automatically fetching any store paths in Firefox’s closure if they are
available on the server `avalon`:
@@ -9,8 +9,8 @@ available on the server `avalon`:
$ nix-env --install --attr nixpkgs.firefox --substituters ssh://alice@avalon
```
-This works similar to the binary cache substituter that Nix usually
-uses, only using SSH instead of HTTP: if a store path `P` is needed, Nix
+This works similar to the binary cache substituter that Lix usually
+uses, only using SSH instead of HTTP: if a store path `P` is needed, Lix
will first check if it’s available in the Nix store on `avalon`. If not,
it will fall back to using the binary cache substituter, and then to
building from source.
diff --git a/doc/manual/src/protocols/protocols.md b/doc/manual/src/protocols/protocols.md
index d6bf1d809..1f77f98a2 100644
--- a/doc/manual/src/protocols/protocols.md
+++ b/doc/manual/src/protocols/protocols.md
@@ -1,4 +1,4 @@
# Protocols
This chapter documents various developer-facing interfaces provided by
-Nix.
+Lix.
diff --git a/doc/manual/src/protocols/tarball-fetcher.md b/doc/manual/src/protocols/tarball-fetcher.md
index 274fa6d63..3527333f2 100644
--- a/doc/manual/src/protocols/tarball-fetcher.md
+++ b/doc/manual/src/protocols/tarball-fetcher.md
@@ -23,11 +23,11 @@ Link: ; rel="immutable"
*flakeref* must be a tarball flakeref. It can contain the tarball flake attributes
`narHash`, `rev`, `revCount` and `lastModified`. If `narHash` is included, its
value must be the NAR hash of the unpacked tarball (as computed via
-`nix hash path`). Nix checks the contents of the returned tarball
+`nix hash path`). Lix checks the contents of the returned tarball
against the `narHash` attribute. The `rev` and `revCount` attributes
are useful when the tarball flake is a mirror of a fetcher type that
has those attributes, such as Git or GitHub. They are not checked by
-Nix.
+Lix.
```
Link:
+
+FIXME(Lix): This chapter is quite outdated with respect to recommended practices in 2024 and needs updating.
+The commands in here will work, however, and the installation section is up to date.
+
+For more updated guidance, see the links on
+
+
+
This chapter is for impatient people who don't like reading
documentation. For more in-depth information you are kindly referred
to subsequent chapters.
-1. Install Nix by running the following:
+1. Install Lix:
+
+ On Linux and macOS the easiest way to install Lix is to run the following shell command
+ (as a user other than root):
```console
- $ curl -L https://nixos.org/nix/install | sh
+ $ curl -sSf -L https://install.lix.systems/lix | sh -s -- install
```
+ For systems that **already have Nix installed**, such as NixOS systems, read our [install page](https://lix.systems/install)
+
The install script will use `sudo`, so make sure you have sufficient rights.
- On Linux, `--daemon` can be omitted for a single-user install.
For other installation methods, see [here](installation/installation.md).
@@ -90,10 +103,12 @@ to subsequent chapters.
$ nix-env --rollback
```
-1. You should periodically run the Nix garbage collector to get rid of
+1. You should periodically run the Lix garbage collector to get rid of
unused packages, since uninstalls or upgrades don't actually delete
them:
```console
$ nix-collect-garbage --delete-old
```
+
+ N.B. on NixOS there is an option [`nix.gc.automatic`](https://nixos.org/manual/nixos/stable/options#opt-nix.gc.automatic) to enable a systemd timer to automate this task.
diff --git a/doc/manual/src/release-notes/release-notes.md b/doc/manual/src/release-notes/release-notes.md
index b05d5ee0a..cdac464ca 100644
--- a/doc/manual/src/release-notes/release-notes.md
+++ b/doc/manual/src/release-notes/release-notes.md
@@ -1 +1 @@
-# Nix Release Notes
+# Lix Release Notes
diff --git a/src/nix/upgrade-nix.md b/src/nix/upgrade-nix.md
index cce88c397..b327727dd 100644
--- a/src/nix/upgrade-nix.md
+++ b/src/nix/upgrade-nix.md
@@ -16,8 +16,8 @@ R""(
# Description
-This command upgrades Nix to the stable version declared in Nixpkgs.
-This stable version is defined in [nix-fallback-paths.nix](https://github.com/NixOS/nixpkgs/raw/master/nixos/modules/installer/tools/nix-fallback-paths.nix)
+This command upgrades Lix to the latest stable version.
+This stable version is defined in [the Lix manifest](https://releases.lix.systems/manifest.nix)
and updated manually. It may not always be the latest tagged release.
By default, it locates the directory containing the `nix` binary in the `$PATH`