Update README for the demise of config

1 files changed, 13 insertions, 30 deletions

diff --git a/README b/README
index 44dd2a2fc6b5..bc0c4caad83d 100644
--- a/README
+++ b/README
@@ -22,22 +22,6 @@ Nix expressions used to build a given system can always be recovered
 from the Nix store, since they will be a dependency of the system
 derivation.
 
-Another important difference is how programs are configured.  Typically,
-programs are configured on NixOS using modules, but this approach can
-only support a single, system-level configuration for a program.  It is
-desirable to be able to be able to configure a program on a per-user
-basis, or even to allow a user to instantiate multiple versions of the
-same program, with different configurations.  Rather than the module
-approach, these expressions use utility functions to create small
-wrapper programs that apply the desired configuration by setting the
-appropriate command line flag or environment variable, then exec into
-the program itself.  Creating multiple instances of the same program is
-then trivial, by using two different invocations of the helper function.
-The configured programs are defined in the config directory, and the
-aforementioned utility functions are available in config/tools.nix.  The
-configured packages are added to Nixpkgs under the pkgsConfigured
-attribute; defined in nixpkgs-overlays/zzzzzz-config/default.nix.
-
 Whereas NixOS configurations are typically made up of configuration
 files along with seperate repositories or channels for Nixpkgs (and
 possibly some overlays), here a single tree is used.  This means that
@@ -56,20 +40,19 @@ structures would be possible, but only this one has this feature, and so
 it made sense to choose it.
 
 In constrast to NixOS, an attempt is made here to assist with per-user
-application state management through the `home' module.  This module
-allows activation scripts to be defined on a per-directory basis inside
-a user's home.  For programs like gpg, which require configuration files
-to be in the same directory as mutable program state, this approach
-allows configuration to be stored read-only in the Nix store, and then
-symlinked into the state directory, allowing this type of program to
-still realise some of the benefits of Nix-based configuration.  However,
-unlike other forms of program configuration as described above, this
-can't simply be done by wrapping a program (at least, without increasing
-the startup time of a program too much), and so a module has to be used.
-These modules are, by convention, stored in the appropriate subdirectory
-of the config directory, rather than in the modules directory, so that
-all program-specific configuration for a particular program lives in one
-place.
+application state management through the `home' and `xdg' modules.  The
+`xdg' module allows creating an immutable XDG_CONFIG_HOME in
+/run/current-system, which allows environment.etc-like management of
+per-user configuration files, without introducing a new, seperate build
+command à la home-manager.  The disadvantage to this approach is that,
+unlike home-manager, it assumes that the user has permission to rebuild
+the entire NixOS system.  The `home' module allows activation scripts to
+be defined on a per-directory basis inside a user's home.  For programs
+like gpg, which require configuration files to be in the same directory
+as mutable program state, this approach allows configuration to be
+stored read-only in the Nix store, and then symlinked into the state
+directory, allowing this type of program to still realise some of the
+benefits of Nix-based configuration.
 
 Note: MIT license does not apply to the packages built by Nixpkgs,
 merely to the package descriptions (Nix expressions, build scripts, and