NixOS · Oct 4, 2019 · Oct 4, 2019 · Oct 4, 2019 · Oct 4, 2019 · Oct 8, 2019
diff --git a/nixos/doc/manual/administration/boot-problems.xml b/nixos/doc/manual/administration/boot-problems.xml
@@ -6,15 +6,22 @@
  <title>Boot Problems</title>
 
  <para>
-  If NixOS fails to boot, there are a number of kernel command line parameters that may help you to identify or fix the issue. You can add these parameters in the GRUB boot menu by pressing “e” to modify the selected boot entry and editing the line starting with <literal>linux</literal>. The following are some useful kernel command line parameters that are recognised by the NixOS boot scripts or by systemd:
+  If NixOS fails to boot, there are a number of kernel command line parameters
+  that may help you to identify or fix the issue. You can add these parameters
+  in the GRUB boot menu by pressing “e” to modify the selected boot entry
+  and editing the line starting with <literal>linux</literal>. The following
+  are some useful kernel command line parameters that are recognised by the
+  NixOS boot scripts or by systemd:
   <variablelist>
    <varlistentry>
     <term>
      <literal>boot.shell_on_fail</literal>
     </term>
     <listitem>
      <para>
-      Start a root shell if something goes wrong in stage 1 of the boot process (the initial ramdisk). This is disabled by default because there is no authentication for the root shell.
+      Start a root shell if something goes wrong in stage 1 of the boot process
+      (the initial ramdisk). This is disabled by default because there is no
+      authentication for the root shell.
      </para>
     </listitem>
    </varlistentry>
@@ -24,7 +31,10 @@
     </term>
     <listitem>
      <para>
-      Start an interactive shell in stage 1 before anything useful has been done. That is, no modules have been loaded and no file systems have been mounted, except for <filename>/proc</filename> and <filename>/sys</filename>.
+      Start an interactive shell in stage 1 before anything useful has been
+      done. That is, no modules have been loaded and no file systems have been
+      mounted, except for <filename>/proc</filename> and
+      <filename>/sys</filename>.
      </para>
     </listitem>
    </varlistentry>
@@ -44,7 +54,11 @@
     </term>
     <listitem>
      <para>
-      Boot into rescue mode (a.k.a. single user mode). This will cause systemd to start nothing but the unit <literal>rescue.target</literal>, which runs <command>sulogin</command> to prompt for the root password and start a root login shell. Exiting the shell causes the system to continue with the normal boot process.
+      Boot into rescue mode (a.k.a. single user mode). This will cause systemd
+      to start nothing but the unit <literal>rescue.target</literal>, which
+      runs <command>sulogin</command> to prompt for the root password and start
+      a root login shell. Exiting the shell causes the system to continue with
+      the normal boot process.
      </para>
     </listitem>
    </varlistentry>
@@ -54,7 +68,8 @@
     </term>
     <listitem>
      <para>
-      Make systemd very verbose and send log messages to the console instead of the journal.
+      Make systemd very verbose and send log messages to the console instead of
+      the journal.
      </para>
     </listitem>
    </varlistentry>
@@ -65,6 +80,11 @@
  </para>
 
  <para>
-  If no login prompts or X11 login screens appear (e.g. due to hanging dependencies), you can press Alt+ArrowUp. If you’re lucky, this will start rescue mode (described above). (Also note that since most units have a 90-second timeout before systemd gives up on them, the <command>agetty</command> login prompts should appear eventually unless something is very wrong.)
+  If no login prompts or X11 login screens appear (e.g. due to hanging
+  dependencies), you can press Alt+ArrowUp. If you’re lucky, this will start
+  rescue mode (described above). (Also note that since most units have a
+  90-second timeout before systemd gives up on them, the
+  <command>agetty</command> login prompts should appear eventually unless
+  something is very wrong.)
  </para>
 </section>
diff --git a/nixos/doc/manual/administration/cleaning-store.xml b/nixos/doc/manual/administration/cleaning-store.xml
@@ -5,43 +5,59 @@
         xml:id="sec-nix-gc">
  <title>Cleaning the Nix Store</title>
  <para>
-  Nix has a purely functional model, meaning that packages are never upgraded in place. Instead new versions of packages end up in a different location in the Nix store (<filename>/nix/store</filename>). You should periodically run Nix’s <emphasis>garbage collector</emphasis> to remove old, unreferenced packages. This is easy:
+  Nix has a purely functional model, meaning that packages are never upgraded
+  in place. Instead new versions of packages end up in a different location in
+  the Nix store (<filename>/nix/store</filename>). You should periodically run
+  Nix’s <emphasis>garbage collector</emphasis> to remove old, unreferenced
+  packages. This is easy:
 <screen>
 <prompt>$ </prompt>nix-collect-garbage
 </screen>
-  Alternatively, you can use a systemd unit that does the same in the background:
+  Alternatively, you can use a systemd unit that does the same in the
+  background:
 <screen>
 <prompt># </prompt>systemctl start nix-gc.service
 </screen>
-  You can tell NixOS in <filename>configuration.nix</filename> to run this unit automatically at certain points in time, for instance, every night at 03:15:
+  You can tell NixOS in <filename>configuration.nix</filename> to run this unit
+  automatically at certain points in time, for instance, every night at 03:15:
 <programlisting>
 <xref linkend="opt-nix.gc.automatic"/> = true;
 <xref linkend="opt-nix.gc.dates"/> = "03:15";
 </programlisting>
  </para>
  <para>
-  The commands above do not remove garbage collector roots, such as old system configurations. Thus they do not remove the ability to roll back to previous configurations. The following command deletes old roots, removing the ability to roll back to them:
+  The commands above do not remove garbage collector roots, such as old system
+  configurations. Thus they do not remove the ability to roll back to previous
+  configurations. The following command deletes old roots, removing the ability
+  to roll back to them:
 <screen>
 <prompt>$ </prompt>nix-collect-garbage -d
 </screen>
   You can also do this for specific profiles, e.g.
 <screen>
 <prompt>$ </prompt>nix-env -p /nix/var/nix/profiles/per-user/eelco/profile --delete-generations old
 </screen>
-  Note that NixOS system configurations are stored in the profile <filename>/nix/var/nix/profiles/system</filename>.
+  Note that NixOS system configurations are stored in the profile
+  <filename>/nix/var/nix/profiles/system</filename>.
  </para>
  <para>
-  Another way to reclaim disk space (often as much as 40% of the size of the Nix store) is to run Nix’s store optimiser, which seeks out identical files in the store and replaces them with hard links to a single copy.
+  Another way to reclaim disk space (often as much as 40% of the size of the
+  Nix store) is to run Nix’s store optimiser, which seeks out identical files
+  in the store and replaces them with hard links to a single copy.
 <screen>
 <prompt>$ </prompt>nix-store --optimise
 </screen>
-  Since this command needs to read the entire Nix store, it can take quite a while to finish.
+  Since this command needs to read the entire Nix store, it can take quite a
+  while to finish.
  </para>
  <section xml:id="sect-nixos-gc-boot-entries">
   <title>NixOS Boot Entries</title>
 
   <para>
-   If your <filename>/boot</filename> partition runs out of space, after clearing old profiles you must rebuild your system with <literal>nixos-rebuild</literal> to update the <filename>/boot</filename> partition and clear space.
+   If your <filename>/boot</filename> partition runs out of space, after
+   clearing old profiles you must rebuild your system with
+   <literal>nixos-rebuild</literal> to update the <filename>/boot</filename>
+   partition and clear space.
   </para>
  </section>
 </chapter>
diff --git a/nixos/doc/manual/administration/container-networking.xml b/nixos/doc/manual/administration/container-networking.xml
@@ -6,7 +6,10 @@
  <title>Container Networking</title>
 
  <para>
-  When you create a container using <literal>nixos-container create</literal>, it gets it own private IPv4 address in the range <literal>10.233.0.0/16</literal>. You can get the container’s IPv4 address as follows:
+  When you create a container using <literal>nixos-container create</literal>,
+  it gets it own private IPv4 address in the range
+  <literal>10.233.0.0/16</literal>. You can get the container’s IPv4 address
+  as follows:
 <screen>
 <prompt># </prompt>nixos-container show-ip foo
 10.233.4.2
@@ -17,21 +20,34 @@
  </para>
 
  <para>
-  Networking is implemented using a pair of virtual Ethernet devices. The network interface in the container is called <literal>eth0</literal>, while the matching interface in the host is called <literal>ve-<replaceable>container-name</replaceable></literal> (e.g., <literal>ve-foo</literal>). The container has its own network namespace and the <literal>CAP_NET_ADMIN</literal> capability, so it can perform arbitrary network configuration such as setting up firewall rules, without affecting or having access to the host’s network.
+  Networking is implemented using a pair of virtual Ethernet devices. The
+  network interface in the container is called <literal>eth0</literal>, while
+  the matching interface in the host is called
+  <literal>ve-<replaceable>container-name</replaceable></literal> (e.g.,
+  <literal>ve-foo</literal>). The container has its own network namespace and
+  the <literal>CAP_NET_ADMIN</literal> capability, so it can perform arbitrary
+  network configuration such as setting up firewall rules, without affecting or
+  having access to the host’s network.
  </para>
 
  <para>
-  By default, containers cannot talk to the outside network. If you want that, you should set up Network Address Translation (NAT) rules on the host to rewrite container traffic to use your external IP address. This can be accomplished using the following configuration on the host:
+  By default, containers cannot talk to the outside network. If you want that,
+  you should set up Network Address Translation (NAT) rules on the host to
+  rewrite container traffic to use your external IP address. This can be
+  accomplished using the following configuration on the host:
 <programlisting>
 <xref linkend="opt-networking.nat.enable"/> = true;
 <xref linkend="opt-networking.nat.internalInterfaces"/> = ["ve-+"];
 <xref linkend="opt-networking.nat.externalInterface"/> = "eth0";
 </programlisting>
-  where <literal>eth0</literal> should be replaced with the desired external interface. Note that <literal>ve-+</literal> is a wildcard that matches all container interfaces.
+  where <literal>eth0</literal> should be replaced with the desired external
+  interface. Note that <literal>ve-+</literal> is a wildcard that matches all
+  container interfaces.
  </para>
 
  <para>
-  If you are using Network Manager, you need to explicitly prevent it from managing container interfaces:
+  If you are using Network Manager, you need to explicitly prevent it from
+  managing container interfaces:
 <programlisting>
 networking.networkmanager.unmanaged = [ "interface-name:ve-*" ];
 </programlisting>

diff --git a/nixos/doc/manual/administration/containers.xml b/nixos/doc/manual/administration/containers.xml
@@ -5,15 +5,28 @@
         xml:id="ch-containers">
  <title>Container Management</title>
  <para>
-  NixOS allows you to easily run other NixOS instances as <emphasis>containers</emphasis>. Containers are a light-weight approach to virtualisation that runs software in the container at the same speed as in the host system. NixOS containers share the Nix store of the host, making container creation very efficient.
+  NixOS allows you to easily run other NixOS instances as
+  <emphasis>containers</emphasis>. Containers are a light-weight approach to
+  virtualisation that runs software in the container at the same speed as in
+  the host system. NixOS containers share the Nix store of the host, making
+  container creation very efficient.
  </para>
  <warning>
   <para>
-   Currently, NixOS containers are not perfectly isolated from the host system. This means that a user with root access to the container can do things that affect the host. So you should not give container root access to untrusted users.
+   Currently, NixOS containers are not perfectly isolated from the host system.
+   This means that a user with root access to the container can do things that
+   affect the host. So you should not give container root access to untrusted
+   users.
   </para>
  </warning>
  <para>
-  NixOS containers can be created in two ways: imperatively, using the command <command>nixos-container</command>, and declaratively, by specifying them in your <filename>configuration.nix</filename>. The declarative approach implies that containers get upgraded along with your host system when you run <command>nixos-rebuild</command>, which is often not what you want. By contrast, in the imperative approach, containers are configured and updated independently from the host system.
+  NixOS containers can be created in two ways: imperatively, using the command
+  <command>nixos-container</command>, and declaratively, by specifying them in
+  your <filename>configuration.nix</filename>. The declarative approach implies
+  that containers get upgraded along with your host system when you run
+  <command>nixos-rebuild</command>, which is often not what you want. By
+  contrast, in the imperative approach, containers are configured and updated
+  independently from the host system.
  </para>
  <xi:include href="imperative-containers.xml" />
  <xi:include href="declarative-containers.xml" />

diff --git a/nixos/doc/manual/administration/control-groups.xml b/nixos/doc/manual/administration/control-groups.xml
@@ -5,10 +5,16 @@
         xml:id="sec-cgroups">
  <title>Control Groups</title>
  <para>
-  To keep track of the processes in a running system, systemd uses <emphasis>control groups</emphasis> (cgroups). A control group is a set of processes used to allocate resources such as CPU, memory or I/O bandwidth. There can be multiple control group hierarchies, allowing each kind of resource to be managed independently.
+  To keep track of the processes in a running system, systemd uses
+  <emphasis>control groups</emphasis> (cgroups). A control group is a set of
+  processes used to allocate resources such as CPU, memory or I/O bandwidth.
+  There can be multiple control group hierarchies, allowing each kind of
+  resource to be managed independently.
  </para>
  <para>
-  The command <command>systemd-cgls</command> lists all control groups in the <literal>systemd</literal> hierarchy, which is what systemd uses to keep track of the processes belonging to each service or user session:
+  The command <command>systemd-cgls</command> lists all control groups in the
+  <literal>systemd</literal> hierarchy, which is what systemd uses to keep
+  track of the processes belonging to each service or user session:
 <screen>
 <prompt>$ </prompt>systemd-cgls
 ├─user
@@ -26,19 +32,34 @@
   │ └─2376 dhcpcd --config /nix/store/f8dif8dsi2yaa70n03xir8r653776ka6-dhcpcd.conf
   └─ <replaceable>...</replaceable>
 </screen>
-  Similarly, <command>systemd-cgls cpu</command> shows the cgroups in the CPU hierarchy, which allows per-cgroup CPU scheduling priorities. By default, every systemd service gets its own CPU cgroup, while all user sessions are in the top-level CPU cgroup. This ensures, for instance, that a thousand run-away processes in the <literal>httpd.service</literal> cgroup cannot starve the CPU for one process in the <literal>postgresql.service</literal> cgroup. (By contrast, it they were in the same cgroup, then the PostgreSQL process would get 1/1001 of the cgroup’s CPU time.) You can limit a service’s CPU share in <filename>configuration.nix</filename>:
+  Similarly, <command>systemd-cgls cpu</command> shows the cgroups in the CPU
+  hierarchy, which allows per-cgroup CPU scheduling priorities. By default,
+  every systemd service gets its own CPU cgroup, while all user sessions are in
+  the top-level CPU cgroup. This ensures, for instance, that a thousand
+  run-away processes in the <literal>httpd.service</literal> cgroup cannot
+  starve the CPU for one process in the <literal>postgresql.service</literal>
+  cgroup. (By contrast, it they were in the same cgroup, then the PostgreSQL
+  process would get 1/1001 of the cgroup’s CPU time.) You can limit a
+  service’s CPU share in <filename>configuration.nix</filename>:
 <programlisting>
 <link linkend="opt-systemd.services._name_.serviceConfig">systemd.services.httpd.serviceConfig</link>.CPUShares = 512;
 </programlisting>
-  By default, every cgroup has 1024 CPU shares, so this will halve the CPU allocation of the <literal>httpd.service</literal> cgroup.
+  By default, every cgroup has 1024 CPU shares, so this will halve the CPU
+  allocation of the <literal>httpd.service</literal> cgroup.
  </para>
  <para>
-  There also is a <literal>memory</literal> hierarchy that controls memory allocation limits; by default, all processes are in the top-level cgroup, so any service or session can exhaust all available memory. Per-cgroup memory limits can be specified in <filename>configuration.nix</filename>; for instance, to limit <literal>httpd.service</literal> to 512 MiB of RAM (excluding swap):
+  There also is a <literal>memory</literal> hierarchy that controls memory
+  allocation limits; by default, all processes are in the top-level cgroup, so
+  any service or session can exhaust all available memory. Per-cgroup memory
+  limits can be specified in <filename>configuration.nix</filename>; for
+  instance, to limit <literal>httpd.service</literal> to 512 MiB of RAM
+  (excluding swap):
 <programlisting>
 <link linkend="opt-systemd.services._name_.serviceConfig">systemd.services.httpd.serviceConfig</link>.MemoryLimit = "512M";
 </programlisting>
  </para>
  <para>
-  The command <command>systemd-cgtop</command> shows a continuously updated list of all cgroups with their CPU and memory usage.
+  The command <command>systemd-cgtop</command> shows a continuously updated
+  list of all cgroups with their CPU and memory usage.
  </para>
 </chapter>
diff --git a/nixos/doc/manual/administration/declarative-containers.xml b/nixos/doc/manual/administration/declarative-containers.xml
@@ -6,7 +6,10 @@
  <title>Declarative Container Specification</title>
 
  <para>
-  You can also specify containers and their configuration in the host’s <filename>configuration.nix</filename>. For example, the following specifies that there shall be a container named <literal>database</literal> running PostgreSQL:
+  You can also specify containers and their configuration in the host’s
+  <filename>configuration.nix</filename>. For example, the following specifies
+  that there shall be a container named <literal>database</literal> running
+  PostgreSQL:
 <programlisting>
 containers.database =
   { config =
@@ -16,26 +19,42 @@ containers.database =
       };
   };
 </programlisting>
-  If you run <literal>nixos-rebuild switch</literal>, the container will be built. If the container was already running, it will be updated in place, without rebooting. The container can be configured to start automatically by setting <literal>containers.database.autoStart = true</literal> in its configuration.
+  If you run <literal>nixos-rebuild switch</literal>, the container will be
+  built. If the container was already running, it will be updated in place,
+  without rebooting. The container can be configured to start automatically by
+  setting <literal>containers.database.autoStart = true</literal> in its
+  configuration.
  </para>
 
  <para>
-  By default, declarative containers share the network namespace of the host, meaning that they can listen on (privileged) ports. However, they cannot change the network configuration. You can give a container its own network as follows:
+  By default, declarative containers share the network namespace of the host,
+  meaning that they can listen on (privileged) ports. However, they cannot
+  change the network configuration. You can give a container its own network as
+  follows:
 <programlisting>
 containers.database = {
   <link linkend="opt-containers._name_.privateNetwork">privateNetwork</link> = true;
   <link linkend="opt-containers._name_.hostAddress">hostAddress</link> = "192.168.100.10";
   <link linkend="opt-containers._name_.localAddress">localAddress</link> = "192.168.100.11";
 };
 </programlisting>
-  This gives the container a private virtual Ethernet interface with IP address <literal>192.168.100.11</literal>, which is hooked up to a virtual Ethernet interface on the host with IP address <literal>192.168.100.10</literal>. (See the next section for details on container networking.)
+  This gives the container a private virtual Ethernet interface with IP address
+  <literal>192.168.100.11</literal>, which is hooked up to a virtual Ethernet
+  interface on the host with IP address <literal>192.168.100.10</literal>. (See
+  the next section for details on container networking.)
  </para>
 
  <para>
-  To disable the container, just remove it from <filename>configuration.nix</filename> and run <literal>nixos-rebuild switch</literal>. Note that this will not delete the root directory of the container in <literal>/var/lib/containers</literal>. Containers can be destroyed using the imperative method: <literal>nixos-container destroy foo</literal>.
+  To disable the container, just remove it from
+  <filename>configuration.nix</filename> and run <literal>nixos-rebuild
+  switch</literal>. Note that this will not delete the root directory of the
+  container in <literal>/var/lib/containers</literal>. Containers can be
+  destroyed using the imperative method: <literal>nixos-container destroy
+  foo</literal>.
  </para>
 
  <para>
-  Declarative containers can be started and stopped using the corresponding systemd service, e.g. <literal>systemctl start container@database</literal>.
+  Declarative containers can be started and stopped using the corresponding
+  systemd service, e.g. <literal>systemctl start container@database</literal>.
  </para>
 </section>
diff --git a/nixos/doc/manual/administration/imperative-containers.xml b/nixos/doc/manual/administration/imperative-containers.xml
@@ -6,22 +6,33 @@
  <title>Imperative Container Management</title>
 
  <para>
-  We’ll cover imperative container management using <command>nixos-container</command> first. Be aware that container management is currently only possible as <literal>root</literal>.
+  We’ll cover imperative container management using
+  <command>nixos-container</command> first. Be aware that container management
+  is currently only possible as <literal>root</literal>.
  </para>
 
  <para>
   You create a container with identifier <literal>foo</literal> as follows:
 <screen>
 # nixos-container create foo
 </screen>
-  This creates the container’s root directory in <filename>/var/lib/containers/foo</filename> and a small configuration file in <filename>/etc/containers/foo.conf</filename>. It also builds the container’s initial system configuration and stores it in <filename>/nix/var/nix/profiles/per-container/foo/system</filename>. You can modify the initial configuration of the container on the command line. For instance, to create a container that has <command>sshd</command> running, with the given public key for <literal>root</literal>:
+  This creates the container’s root directory in
+  <filename>/var/lib/containers/foo</filename> and a small configuration file
+  in <filename>/etc/containers/foo.conf</filename>. It also builds the
+  container’s initial system configuration and stores it in
+  <filename>/nix/var/nix/profiles/per-container/foo/system</filename>. You can
+  modify the initial configuration of the container on the command line. For
+  instance, to create a container that has <command>sshd</command> running,
+  with the given public key for <literal>root</literal>:
 <screen>
 # nixos-container create foo --config '
   <xref linkend="opt-services.openssh.enable"/> = true;
   <link linkend="opt-users.users._name__.openssh.authorizedKeys.keys">users.users.root.openssh.authorizedKeys.keys</link> = ["ssh-dss AAAAB3N…"];
 '
 </screen>
-  By default the next free address in the <literal>10.233.0.0/16</literal> subnet will be chosen as container IP. This behavior can be altered by setting <literal>--host-address</literal> and <literal>--local-address</literal>:
+  By default the next free address in the <literal>10.233.0.0/16</literal> subnet will be chosen
+  as container IP. This behavior can be altered by setting <literal>--host-address</literal> and
+  <literal>--local-address</literal>:
 <screen>
 # nixos-container create test --config-file test-container.nix \
     --local-address 10.235.1.2 --host-address 10.235.1.1
@@ -33,37 +44,51 @@
 <screen>
 # nixos-container start foo
 </screen>
-  This command will return as soon as the container has booted and has reached <literal>multi-user.target</literal>. On the host, the container runs within a systemd unit called <literal>container@<replaceable>container-name</replaceable>.service</literal>. Thus, if something went wrong, you can get status info using <command>systemctl</command>:
+  This command will return as soon as the container has booted and has reached
+  <literal>multi-user.target</literal>. On the host, the container runs within
+  a systemd unit called
+  <literal>container@<replaceable>container-name</replaceable>.service</literal>.
+  Thus, if something went wrong, you can get status info using
+  <command>systemctl</command>:
 <screen>
 # systemctl status container@foo
 </screen>
  </para>
 
  <para>
-  If the container has started successfully, you can log in as root using the <command>root-login</command> operation:
+  If the container has started successfully, you can log in as root using the
+  <command>root-login</command> operation:
 <screen>
 # nixos-container root-login foo
 [root@foo:~]#
 </screen>
-  Note that only root on the host can do this (since there is no authentication). You can also get a regular login prompt using the <command>login</command> operation, which is available to all users on the host:
+  Note that only root on the host can do this (since there is no
+  authentication). You can also get a regular login prompt using the
+  <command>login</command> operation, which is available to all users on the
+  host:
 <screen>
 # nixos-container login foo
 foo login: alice
 Password: ***
 </screen>
-  With <command>nixos-container run</command>, you can execute arbitrary commands in the container:
+  With <command>nixos-container run</command>, you can execute arbitrary
+  commands in the container:
 <screen>
 # nixos-container run foo -- uname -a
 Linux foo 3.4.82 #1-NixOS SMP Thu Mar 20 14:44:05 UTC 2014 x86_64 GNU/Linux
 </screen>
  </para>
 
  <para>
-  There are several ways to change the configuration of the container. First, on the host, you can edit <literal>/var/lib/container/<replaceable>name</replaceable>/etc/nixos/configuration.nix</literal>, and run
+  There are several ways to change the configuration of the container. First,
+  on the host, you can edit
+  <literal>/var/lib/container/<replaceable>name</replaceable>/etc/nixos/configuration.nix</literal>,
+  and run
 <screen>
 # nixos-container update foo
 </screen>
-  This will build and activate the new configuration. You can also specify a new configuration on the command line:
+  This will build and activate the new configuration. You can also specify a
+  new configuration on the command line:
 <screen>
 # nixos-container update foo --config '
   <xref linkend="opt-services.httpd.enable"/> = true;
@@ -74,15 +99,23 @@ Linux foo 3.4.82 #1-NixOS SMP Thu Mar 20 14:44:05 UTC 2014 x86_64 GNU/Linux
 # curl http://$(nixos-container show-ip foo)/
 &lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">…
 </screen>
-  However, note that this will overwrite the container’s <filename>/etc/nixos/configuration.nix</filename>.
+  However, note that this will overwrite the container’s
+  <filename>/etc/nixos/configuration.nix</filename>.
  </para>
 
  <para>
-  Alternatively, you can change the configuration from within the container itself by running <command>nixos-rebuild switch</command> inside the container. Note that the container by default does not have a copy of the NixOS channel, so you should run <command>nix-channel --update</command> first.
+  Alternatively, you can change the configuration from within the container
+  itself by running <command>nixos-rebuild switch</command> inside the
+  container. Note that the container by default does not have a copy of the
+  NixOS channel, so you should run <command>nix-channel --update</command>
+  first.
  </para>
 
  <para>
-  Containers can be stopped and started using <literal>nixos-container stop</literal> and <literal>nixos-container start</literal>, respectively, or by using <command>systemctl</command> on the container’s service unit. To destroy a container, including its file system, do
+  Containers can be stopped and started using <literal>nixos-container
+  stop</literal> and <literal>nixos-container start</literal>, respectively, or
+  by using <command>systemctl</command> on the container’s service unit. To
+  destroy a container, including its file system, do
 <screen>
 # nixos-container destroy foo
 </screen>

diff --git a/nixos/doc/manual/administration/logging.xml b/nixos/doc/manual/administration/logging.xml
@@ -5,11 +5,18 @@
         xml:id="sec-logging">
  <title>Logging</title>
  <para>
-  System-wide logging is provided by systemd’s <emphasis>journal</emphasis>, which subsumes traditional logging daemons such as syslogd and klogd. Log entries are kept in binary files in <filename>/var/log/journal/</filename>. The command <literal>journalctl</literal> allows you to see the contents of the journal. For example,
+  System-wide logging is provided by systemd’s <emphasis>journal</emphasis>,
+  which subsumes traditional logging daemons such as syslogd and klogd. Log
+  entries are kept in binary files in <filename>/var/log/journal/</filename>.
+  The command <literal>journalctl</literal> allows you to see the contents of
+  the journal. For example,
 <screen>
 <prompt>$ </prompt>journalctl -b
 </screen>
-  shows all journal entries since the last reboot. (The output of <command>journalctl</command> is piped into <command>less</command> by default.) You can use various options and match operators to restrict output to messages of interest. For instance, to get all messages from PostgreSQL:
+  shows all journal entries since the last reboot. (The output of
+  <command>journalctl</command> is piped into <command>less</command> by
+  default.) You can use various options and match operators to restrict output
+  to messages of interest. For instance, to get all messages from PostgreSQL:
 <screen>
 <prompt>$ </prompt>journalctl -u postgresql.service
 -- Logs begin at Mon, 2013-01-07 13:28:01 CET, end at Tue, 2013-01-08 01:09:57 CET. --
@@ -19,14 +26,18 @@ Jan 07 15:44:14 hagbard postgres[2681]: [2-1] LOG:  database system is shut down
 Jan 07 15:45:10 hagbard postgres[2532]: [1-1] LOG:  database system was shut down at 2013-01-07 15:44:14 CET
 Jan 07 15:45:13 hagbard postgres[2500]: [1-1] LOG:  database system is ready to accept connections
 </screen>
-  Or to get all messages since the last reboot that have at least a “critical” severity level:
+  Or to get all messages since the last reboot that have at least a
+  “critical” severity level:
 <screen>
 <prompt>$ </prompt>journalctl -b -p crit
 Dec 17 21:08:06 mandark sudo[3673]: pam_unix(sudo:auth): auth could not identify password for [alice]
 Dec 29 01:30:22 mandark kernel[6131]: [1053513.909444] CPU6: Core temperature above threshold, cpu clock throttled (total events = 1)
 </screen>
  </para>
  <para>
-  The system journal is readable by root and by users in the <literal>wheel</literal> and <literal>systemd-journal</literal> groups. All users have a private journal that can be read using <command>journalctl</command>.
+  The system journal is readable by root and by users in the
+  <literal>wheel</literal> and <literal>systemd-journal</literal> groups. All
+  users have a private journal that can be read using
+  <command>journalctl</command>.
  </para>
 </chapter>
diff --git a/nixos/doc/manual/administration/maintenance-mode.xml b/nixos/doc/manual/administration/maintenance-mode.xml
@@ -9,6 +9,8 @@
   You can enter rescue mode by running:
 <screen>
 # systemctl rescue</screen>
-  This will eventually give you a single-user root shell. Systemd will stop (almost) all system services. To get out of maintenance mode, just exit from the rescue shell.
+  This will eventually give you a single-user root shell. Systemd will stop
+  (almost) all system services. To get out of maintenance mode, just exit from
+  the rescue shell.
  </para>
 </section>
diff --git a/nixos/doc/manual/administration/network-problems.xml b/nixos/doc/manual/administration/network-problems.xml
@@ -6,11 +6,20 @@
  <title>Network Problems</title>
 
  <para>
-  Nix uses a so-called <emphasis>binary cache</emphasis> to optimise building a package from source into downloading it as a pre-built binary. That is, whenever a command like <command>nixos-rebuild</command> needs a path in the Nix store, Nix will try to download that path from the Internet rather than build it from source. The default binary cache is <uri>https://cache.nixos.org/</uri>. If this cache is unreachable, Nix operations may take a long time due to HTTP connection timeouts. You can disable the use of the binary cache by adding <option>--option use-binary-caches false</option>, e.g.
+  Nix uses a so-called <emphasis>binary cache</emphasis> to optimise building a
+  package from source into downloading it as a pre-built binary. That is,
+  whenever a command like <command>nixos-rebuild</command> needs a path in the
+  Nix store, Nix will try to download that path from the Internet rather than
+  build it from source. The default binary cache is
+  <uri>https://cache.nixos.org/</uri>. If this cache is unreachable, Nix
+  operations may take a long time due to HTTP connection timeouts. You can
+  disable the use of the binary cache by adding <option>--option
+  use-binary-caches false</option>, e.g.
 <screen>
 # nixos-rebuild switch --option use-binary-caches false
 </screen>
-  If you have an alternative binary cache at your disposal, you can use it instead:
+  If you have an alternative binary cache at your disposal, you can use it
+  instead:
 <screen>
 # nixos-rebuild switch --option binary-caches http://my-cache.example.org/
 </screen>

diff --git a/nixos/doc/manual/administration/rebooting.xml b/nixos/doc/manual/administration/rebooting.xml
@@ -16,15 +16,20 @@
 <screen>
 # reboot
 </screen>
-  which is equivalent to <command>systemctl reboot</command>. Alternatively, you can quickly reboot the system using <literal>kexec</literal>, which bypasses the BIOS by directly loading the new kernel into memory:
+  which is equivalent to <command>systemctl reboot</command>. Alternatively,
+  you can quickly reboot the system using <literal>kexec</literal>, which
+  bypasses the BIOS by directly loading the new kernel into memory:
 <screen>
 # systemctl kexec
 </screen>
  </para>
  <para>
-  The machine can be suspended to RAM (if supported) using <command>systemctl suspend</command>, and suspended to disk using <command>systemctl hibernate</command>.
+  The machine can be suspended to RAM (if supported) using <command>systemctl
+  suspend</command>, and suspended to disk using <command>systemctl
+  hibernate</command>.
  </para>
  <para>
-  These commands can be run by any user who is logged in locally, i.e. on a virtual console or in X11; otherwise, the user is asked for authentication.
+  These commands can be run by any user who is logged in locally, i.e. on a
+  virtual console or in X11; otherwise, the user is asked for authentication.
  </para>
 </chapter>
diff --git a/nixos/doc/manual/administration/rollback.xml b/nixos/doc/manual/administration/rollback.xml
@@ -6,11 +6,19 @@
  <title>Rolling Back Configuration Changes</title>
 
  <para>
-  After running <command>nixos-rebuild</command> to switch to a new configuration, you may find that the new configuration doesn’t work very well. In that case, there are several ways to return to a previous configuration.
+  After running <command>nixos-rebuild</command> to switch to a new
+  configuration, you may find that the new configuration doesn’t work very
+  well. In that case, there are several ways to return to a previous
+  configuration.
  </para>
 
  <para>
-  First, the GRUB boot manager allows you to boot into any previous configuration that hasn’t been garbage-collected. These configurations can be found under the GRUB submenu “NixOS - All configurations”. This is especially useful if the new configuration fails to boot. After the system has booted, you can make the selected configuration the default for subsequent boots:
+  First, the GRUB boot manager allows you to boot into any previous
+  configuration that hasn’t been garbage-collected. These configurations can
+  be found under the GRUB submenu “NixOS - All configurations”. This is
+  especially useful if the new configuration fails to boot. After the system
+  has booted, you can make the selected configuration the default for
+  subsequent boots:
 <screen>
 # /run/current-system/bin/switch-to-configuration boot</screen>
  </para>
@@ -22,7 +30,8 @@
   This is equivalent to running:
 <screen>
 # /nix/var/nix/profiles/system-<replaceable>N</replaceable>-link/bin/switch-to-configuration switch</screen>
-  where <replaceable>N</replaceable> is the number of the NixOS system configuration. To get a list of the available configurations, do:
+  where <replaceable>N</replaceable> is the number of the NixOS system
+  configuration. To get a list of the available configurations, do:
 <screen>
 <prompt>$ </prompt>ls -l /nix/var/nix/profiles/system-*-link
 <replaceable>...</replaceable>

diff --git a/nixos/doc/manual/administration/running.xml b/nixos/doc/manual/administration/running.xml
@@ -6,7 +6,8 @@
  <title>Administration</title>
  <partintro xml:id="ch-running-intro">
   <para>
-   This chapter describes various aspects of managing a running NixOS system, such as how to use the <command>systemd</command> service manager.
+   This chapter describes various aspects of managing a running NixOS system,
+   such as how to use the <command>systemd</command> service manager.
   </para>
  </partintro>
  <xi:include href="service-mgmt.xml" />

diff --git a/nixos/doc/manual/administration/service-mgmt.xml b/nixos/doc/manual/administration/service-mgmt.xml
@@ -5,10 +5,21 @@
          xml:id="sec-systemctl">
  <title>Service Management</title>
  <para>
-  In NixOS, all system services are started and monitored using the systemd program. Systemd is the “init” process of the system (i.e. PID 1), the parent of all other processes. It manages a set of so-called “units”, which can be things like system services (programs), but also mount points, swap files, devices, targets (groups of units) and more. Units can have complex dependencies; for instance, one unit can require that another unit must be successfully started before the first unit can be started. When the system boots, it starts a unit named <literal>default.target</literal>; the dependencies of this unit cause all system services to be started, file systems to be mounted, swap files to be activated, and so on.
+  In NixOS, all system services are started and monitored using the systemd
+  program. Systemd is the “init” process of the system (i.e. PID 1), the
+  parent of all other processes. It manages a set of so-called “units”,
+  which can be things like system services (programs), but also mount points,
+  swap files, devices, targets (groups of units) and more. Units can have
+  complex dependencies; for instance, one unit can require that another unit
+  must be successfully started before the first unit can be started. When the
+  system boots, it starts a unit named <literal>default.target</literal>; the
+  dependencies of this unit cause all system services to be started, file
+  systems to be mounted, swap files to be activated, and so on.
  </para>
  <para>
-  The command <command>systemctl</command> is the main way to interact with <command>systemd</command>. Without any arguments, it shows the status of active units:
+  The command <command>systemctl</command> is the main way to interact with
+  <command>systemd</command>. Without any arguments, it shows the status of
+  active units:
 <screen>
 <prompt>$ </prompt>systemctl
 -.mount          loaded active mounted   /
@@ -19,7 +30,8 @@ graphical.target loaded active active    Graphical Interface
 </screen>
  </para>
  <para>
-  You can ask for detailed status information about a unit, for instance, the PostgreSQL database service:
+  You can ask for detailed status information about a unit, for instance, the
+  PostgreSQL database service:
 <screen>
 <prompt>$ </prompt>systemctl status postgresql.service
 postgresql.service - PostgreSQL Server
@@ -39,7 +51,9 @@ Jan 07 15:55:57 hagbard postgres[2390]: [1-1] LOG:  database system is ready to
 Jan 07 15:55:57 hagbard postgres[2420]: [1-1] LOG:  autovacuum launcher started
 Jan 07 15:55:57 hagbard systemd[1]: Started PostgreSQL Server.
 </screen>
-  Note that this shows the status of the unit (active and running), all the processes belonging to the service, as well as the most recent log messages from the service.
+  Note that this shows the status of the unit (active and running), all the
+  processes belonging to the service, as well as the most recent log messages
+  from the service.
  </para>
  <para>
   Units can be stopped, started or restarted:
@@ -48,7 +62,9 @@ Jan 07 15:55:57 hagbard systemd[1]: Started PostgreSQL Server.
 # systemctl start postgresql.service
 # systemctl restart postgresql.service
 </screen>
-  These operations are synchronous: they wait until the service has finished starting or stopping (or has failed). Starting a unit will cause the dependencies of that unit to be started as well (if necessary).
+  These operations are synchronous: they wait until the service has finished
+  starting or stopping (or has failed). Starting a unit will cause the
+  dependencies of that unit to be started as well (if necessary).
  </para>
 <!-- - cgroups: each service and user session is a cgroup
 

diff --git a/nixos/doc/manual/administration/store-corruption.xml b/nixos/doc/manual/administration/store-corruption.xml
@@ -6,22 +6,31 @@
  <title>Nix Store Corruption</title>
 
  <para>
-  After a system crash, it’s possible for files in the Nix store to become corrupted. (For instance, the Ext4 file system has the tendency to replace un-synced files with zero bytes.) NixOS tries hard to prevent this from happening: it performs a <command>sync</command> before switching to a new configuration, and Nix’s database is fully transactional. If corruption still occurs, you may be able to fix it automatically.
+  After a system crash, it’s possible for files in the Nix store to become
+  corrupted. (For instance, the Ext4 file system has the tendency to replace
+  un-synced files with zero bytes.) NixOS tries hard to prevent this from
+  happening: it performs a <command>sync</command> before switching to a new
+  configuration, and Nix’s database is fully transactional. If corruption
+  still occurs, you may be able to fix it automatically.
  </para>
 
  <para>
-  If the corruption is in a path in the closure of the NixOS system configuration, you can fix it by doing
+  If the corruption is in a path in the closure of the NixOS system
+  configuration, you can fix it by doing
 <screen>
 <prompt># </prompt>nixos-rebuild switch --repair
 </screen>
-  This will cause Nix to check every path in the closure, and if its cryptographic hash differs from the hash recorded in Nix’s database, the path is rebuilt or redownloaded.
+  This will cause Nix to check every path in the closure, and if its
+  cryptographic hash differs from the hash recorded in Nix’s database, the
+  path is rebuilt or redownloaded.
  </para>
 
  <para>
   You can also scan the entire Nix store for corrupt paths:
 <screen>
 <prompt># </prompt>nix-store --verify --check-contents --repair
 </screen>
-  Any corrupt paths will be redownloaded if they’re available in a binary cache; otherwise, they cannot be repaired.
+  Any corrupt paths will be redownloaded if they’re available in a binary
+  cache; otherwise, they cannot be repaired.
  </para>
 </section>
diff --git a/nixos/doc/manual/administration/troubleshooting.xml b/nixos/doc/manual/administration/troubleshooting.xml
@@ -5,7 +5,8 @@
         xml:id="ch-troubleshooting">
  <title>Troubleshooting</title>
  <para>
-  This chapter describes solutions to common problems you might encounter when you manage your NixOS system.
+  This chapter describes solutions to common problems you might encounter when
+  you manage your NixOS system.
  </para>
  <xi:include href="boot-problems.xml" />
  <xi:include href="maintenance-mode.xml" />

diff --git a/nixos/doc/manual/administration/user-sessions.xml b/nixos/doc/manual/administration/user-sessions.xml
@@ -5,15 +5,21 @@
         xml:id="sec-user-sessions">
  <title>User Sessions</title>
  <para>
-  Systemd keeps track of all users who are logged into the system (e.g. on a virtual console or remotely via SSH). The command <command>loginctl</command> allows querying and manipulating user sessions. For instance, to list all user sessions:
+  Systemd keeps track of all users who are logged into the system (e.g. on a
+  virtual console or remotely via SSH). The command <command>loginctl</command>
+  allows querying and manipulating user sessions. For instance, to list all
+  user sessions:
 <screen>
 <prompt>$ </prompt>loginctl
    SESSION        UID USER             SEAT
         c1        500 eelco            seat0
         c3          0 root             seat0
         c4        500 alice
 </screen>
-  This shows that two users are logged in locally, while another is logged in remotely. (“Seats” are essentially the combinations of displays and input devices attached to the system; usually, there is only one seat.) To get information about a session:
+  This shows that two users are logged in locally, while another is logged in
+  remotely. (“Seats” are essentially the combinations of displays and input
+  devices attached to the system; usually, there is only one seat.) To get
+  information about a session:
 <screen>
 <prompt>$ </prompt>loginctl session-status c3
 c3 - root (0)
@@ -28,7 +34,10 @@ c3 - root (0)
                   ├─10339 -bash
                   └─10355 w3m nixos.org
 </screen>
-  This shows that the user is logged in on virtual console 3. It also lists the processes belonging to this session. Since systemd keeps track of this, you can terminate a session in a way that ensures that all the session’s processes are gone:
+  This shows that the user is logged in on virtual console 3. It also lists the
+  processes belonging to this session. Since systemd keeps track of this, you
+  can terminate a session in a way that ensures that all the session’s
+  processes are gone:
 <screen>
 # loginctl terminate-session c3
 </screen>

diff --git a/nixos/doc/manual/configuration/abstractions.xml b/nixos/doc/manual/configuration/abstractions.xml
@@ -6,7 +6,8 @@
  <title>Abstractions</title>
 
  <para>
-  If you find yourself repeating yourself over and over, it’s time to abstract. Take, for instance, this Apache HTTP Server configuration:
+  If you find yourself repeating yourself over and over, it’s time to
+  abstract. Take, for instance, this Apache HTTP Server configuration:
 <programlisting>
 {
   <xref linkend="opt-services.httpd.virtualHosts"/> =
@@ -26,7 +27,9 @@
     ];
 }
 </programlisting>
-  It defines two virtual hosts with nearly identical configuration; the only difference is that the second one has SSL enabled. To prevent this duplication, we can use a <literal>let</literal>:
+  It defines two virtual hosts with nearly identical configuration; the only
+  difference is that the second one has SSL enabled. To prevent this
+  duplication, we can use a <literal>let</literal>:
 <programlisting>
 let
   exampleOrgCommon =
@@ -47,11 +50,16 @@ in
     ];
 }
 </programlisting>
-  The <literal>let exampleOrgCommon = <replaceable>...</replaceable></literal> defines a variable named <literal>exampleOrgCommon</literal>. The <literal>//</literal> operator merges two attribute sets, so the configuration of the second virtual host is the set <literal>exampleOrgCommon</literal> extended with the SSL options.
+  The <literal>let exampleOrgCommon = <replaceable>...</replaceable></literal>
+  defines a variable named <literal>exampleOrgCommon</literal>. The
+  <literal>//</literal> operator merges two attribute sets, so the
+  configuration of the second virtual host is the set
+  <literal>exampleOrgCommon</literal> extended with the SSL options.
  </para>
 
  <para>
-  You can write a <literal>let</literal> wherever an expression is allowed. Thus, you also could have written:
+  You can write a <literal>let</literal> wherever an expression is allowed.
+  Thus, you also could have written:
 <programlisting>
 {
   <xref linkend="opt-services.httpd.virtualHosts"/> =
@@ -61,11 +69,16 @@ in
     ];
 }
 </programlisting>
-  but not <literal>{ let exampleOrgCommon = <replaceable>...</replaceable>; in <replaceable>...</replaceable>; }</literal> since attributes (as opposed to attribute values) are not expressions.
+  but not <literal>{ let exampleOrgCommon = <replaceable>...</replaceable>; in
+  <replaceable>...</replaceable>; }</literal> since attributes (as opposed to
+  attribute values) are not expressions.
  </para>
 
  <para>
-  <emphasis>Functions</emphasis> provide another method of abstraction. For instance, suppose that we want to generate lots of different virtual hosts, all with identical configuration except for the host name. This can be done as follows:
+  <emphasis>Functions</emphasis> provide another method of abstraction. For
+  instance, suppose that we want to generate lots of different virtual hosts,
+  all with identical configuration except for the host name. This can be done
+  as follows:
 <programlisting>
 {
   <xref linkend="opt-services.httpd.virtualHosts"/> =
@@ -83,11 +96,15 @@ in
       ];
 }
 </programlisting>
-  Here, <varname>makeVirtualHost</varname> is a function that takes a single argument <literal>name</literal> and returns the configuration for a virtual host. That function is then called for several names to produce the list of virtual host configurations.
+  Here, <varname>makeVirtualHost</varname> is a function that takes a single
+  argument <literal>name</literal> and returns the configuration for a virtual
+  host. That function is then called for several names to produce the list of
+  virtual host configurations.
  </para>
 
  <para>
-  We can further improve on this by using the function <varname>map</varname>, which applies another function to every element in a list:
+  We can further improve on this by using the function <varname>map</varname>,
+  which applies another function to every element in a list:
 <programlisting>
 {
   <xref linkend="opt-services.httpd.virtualHosts"/> =
@@ -97,11 +114,15 @@ in
       [ "example.org" "example.com" "example.gov" "example.nl" ];
 }
 </programlisting>
-  (The function <literal>map</literal> is called a <emphasis>higher-order function</emphasis> because it takes another function as an argument.)
+  (The function <literal>map</literal> is called a <emphasis>higher-order
+  function</emphasis> because it takes another function as an argument.)
  </para>
 
  <para>
-  What if you need more than one argument, for instance, if we want to use a different <literal>documentRoot</literal> for each virtual host? Then we can make <varname>makeVirtualHost</varname> a function that takes a <emphasis>set</emphasis> as its argument, like this:
+  What if you need more than one argument, for instance, if we want to use a
+  different <literal>documentRoot</literal> for each virtual host? Then we can
+  make <varname>makeVirtualHost</varname> a function that takes a
+  <emphasis>set</emphasis> as its argument, like this:
 <programlisting>
 {
   <xref linkend="opt-services.httpd.virtualHosts"/> =
@@ -119,14 +140,17 @@ in
       ];
 }
 </programlisting>
-  But in this case (where every root is a subdirectory of <filename>/sites</filename> named after the virtual host), it would have been shorter to define <varname>makeVirtualHost</varname> as
+  But in this case (where every root is a subdirectory of
+  <filename>/sites</filename> named after the virtual host), it would have been
+  shorter to define <varname>makeVirtualHost</varname> as
 <programlisting>
 makeVirtualHost = name:
   { hostName = name;
     documentRoot = "/sites/${name}";
     adminAddr = "alice@example.org";
   };
 </programlisting>
-  Here, the construct <literal>${<replaceable>...</replaceable>}</literal> allows the result of an expression to be spliced into a string.
+  Here, the construct <literal>${<replaceable>...</replaceable>}</literal>
+  allows the result of an expression to be spliced into a string.
  </para>
 </section>
diff --git a/nixos/doc/manual/configuration/ad-hoc-network-config.xml b/nixos/doc/manual/configuration/ad-hoc-network-config.xml
@@ -6,7 +6,10 @@
  <title>Ad-Hoc Configuration</title>
 
  <para>
-  You can use <xref linkend="opt-networking.localCommands"/> to specify shell commands to be run at the end of <literal>network-setup.service</literal>. This is useful for doing network configuration not covered by the existing NixOS modules. For instance, to statically configure an IPv6 address:
+  You can use <xref linkend="opt-networking.localCommands"/> to specify shell
+  commands to be run at the end of <literal>network-setup.service</literal>.
+  This is useful for doing network configuration not covered by the existing
+  NixOS modules. For instance, to statically configure an IPv6 address:
 <programlisting>
 <xref linkend="opt-networking.localCommands"/> =
   ''

diff --git a/nixos/doc/manual/configuration/ad-hoc-packages.xml b/nixos/doc/manual/configuration/ad-hoc-packages.xml
@@ -6,18 +6,33 @@
  <title>Ad-Hoc Package Management</title>
 
  <para>
-  With the command <command>nix-env</command>, you can install and uninstall packages from the command line. For instance, to install Mozilla Thunderbird:
+  With the command <command>nix-env</command>, you can install and uninstall
+  packages from the command line. For instance, to install Mozilla Thunderbird:
 <screen>
 <prompt>$ </prompt>nix-env -iA nixos.thunderbird</screen>
-  If you invoke this as root, the package is installed in the Nix profile <filename>/nix/var/nix/profiles/default</filename> and visible to all users of the system; otherwise, the package ends up in <filename>/nix/var/nix/profiles/per-user/<replaceable>username</replaceable>/profile</filename> and is not visible to other users. The <option>-A</option> flag specifies the package by its attribute name; without it, the package is installed by matching against its package name (e.g. <literal>thunderbird</literal>). The latter is slower because it requires matching against all available Nix packages, and is ambiguous if there are multiple matching packages.
+  If you invoke this as root, the package is installed in the Nix profile
+  <filename>/nix/var/nix/profiles/default</filename> and visible to all users
+  of the system; otherwise, the package ends up in
+  <filename>/nix/var/nix/profiles/per-user/<replaceable>username</replaceable>/profile</filename>
+  and is not visible to other users. The <option>-A</option> flag specifies the
+  package by its attribute name; without it, the package is installed by
+  matching against its package name (e.g. <literal>thunderbird</literal>). The
+  latter is slower because it requires matching against all available Nix
+  packages, and is ambiguous if there are multiple matching packages.
  </para>
 
  <para>
-  Packages come from the NixOS channel. You typically upgrade a package by updating to the latest version of the NixOS channel:
+  Packages come from the NixOS channel. You typically upgrade a package by
+  updating to the latest version of the NixOS channel:
 <screen>
 <prompt>$ </prompt>nix-channel --update nixos
 </screen>
-  and then running <literal>nix-env -i</literal> again. Other packages in the profile are <emphasis>not</emphasis> affected; this is the crucial difference with the declarative style of package management, where running <command>nixos-rebuild switch</command> causes all packages to be updated to their current versions in the NixOS channel. You can however upgrade all packages for which there is a newer version by doing:
+  and then running <literal>nix-env -i</literal> again. Other packages in the
+  profile are <emphasis>not</emphasis> affected; this is the crucial difference
+  with the declarative style of package management, where running
+  <command>nixos-rebuild switch</command> causes all packages to be updated to
+  their current versions in the NixOS channel. You can however upgrade all
+  packages for which there is a newer version by doing:
 <screen>
 <prompt>$ </prompt>nix-env -u '*'
 </screen>
@@ -38,7 +53,8 @@
  </para>
 
  <para>
-  <command>nix-env</command> has many more flags. For details, see the <citerefentry>
+  <command>nix-env</command> has many more flags. For details, see the
+  <citerefentry>
   <refentrytitle>nix-env</refentrytitle>
   <manvolnum>1</manvolnum></citerefentry> manpage or the Nix manual.
  </para>

diff --git a/nixos/doc/manual/configuration/adding-custom-packages.xml b/nixos/doc/manual/configuration/adding-custom-packages.xml
@@ -6,23 +6,33 @@
  <title>Adding Custom Packages</title>
 
  <para>
-  It’s possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the <link
-xlink:href="http://nixos.org/nixpkgs/manual">Nixpkgs manual</link>. In short, you clone Nixpkgs:
+  It’s possible that a package you need is not available in NixOS. In that
+  case, you can do two things. First, you can clone the Nixpkgs repository, add
+  the package to your clone, and (optionally) submit a patch or pull request to
+  have it accepted into the main Nixpkgs repository. This is described in
+  detail in the <link
+xlink:href="http://nixos.org/nixpkgs/manual">Nixpkgs
+  manual</link>. In short, you clone Nixpkgs:
 <screen>
 <prompt>$ </prompt>git clone https://github.com/NixOS/nixpkgs
 <prompt>$ </prompt>cd nixpkgs
 </screen>
-  Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to <literal>environment.systemPackages</literal>, e.g.
+  Then you write and test the package as described in the Nixpkgs manual.
+  Finally, you add it to <literal>environment.systemPackages</literal>, e.g.
 <programlisting>
 <xref linkend="opt-environment.systemPackages"/> = [ pkgs.my-package ];
 </programlisting>
-  and you run <command>nixos-rebuild</command>, specifying your own Nixpkgs tree:
+  and you run <command>nixos-rebuild</command>, specifying your own Nixpkgs
+  tree:
 <screen>
 # nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs</screen>
  </para>
 
  <para>
-  The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the <link xlink:href="https://www.gnu.org/software/hello/">GNU Hello</link> package directly in <filename>configuration.nix</filename>:
+  The second possibility is to add the package outside of the Nixpkgs tree. For
+  instance, here is how you specify a build of the
+  <link xlink:href="https://www.gnu.org/software/hello/">GNU Hello</link>
+  package directly in <filename>configuration.nix</filename>:
 <programlisting>
 <xref linkend="opt-environment.systemPackages"/> =
   let
@@ -36,7 +46,8 @@ xlink:href="http://nixos.org/nixpkgs/manual">Nixpkgs manual</link>. In short, yo
   in
   [ my-hello ];
 </programlisting>
-  Of course, you can also move the definition of <literal>my-hello</literal> into a separate Nix expression, e.g.
+  Of course, you can also move the definition of <literal>my-hello</literal>
+  into a separate Nix expression, e.g.
 <programlisting>
 <xref linkend="opt-environment.systemPackages"/> = [ (import ./my-hello.nix) ];
 </programlisting>

diff --git a/nixos/doc/manual/configuration/config-file.xml b/nixos/doc/manual/configuration/config-file.xml
@@ -13,7 +13,15 @@
 { <replaceable>option definitions</replaceable>
 }
 </programlisting>
-  The first line (<literal>{ config, pkgs, ... }:</literal>) denotes that this is actually a function that takes at least the two arguments <varname>config</varname> and <varname>pkgs</varname>. (These are explained later.) The function returns a <emphasis>set</emphasis> of option definitions (<literal>{ <replaceable>...</replaceable> }</literal>). These definitions have the form <literal><replaceable>name</replaceable> = <replaceable>value</replaceable></literal>, where <replaceable>name</replaceable> is the name of an option and <replaceable>value</replaceable> is its value. For example,
+  The first line (<literal>{ config, pkgs, ... }:</literal>) denotes that this
+  is actually a function that takes at least the two arguments
+  <varname>config</varname> and <varname>pkgs</varname>. (These are explained
+  later.) The function returns a <emphasis>set</emphasis> of option definitions
+  (<literal>{ <replaceable>...</replaceable> }</literal>). These definitions
+  have the form <literal><replaceable>name</replaceable> =
+  <replaceable>value</replaceable></literal>, where
+  <replaceable>name</replaceable> is the name of an option and
+  <replaceable>value</replaceable> is its value. For example,
 <programlisting>
 { config, pkgs, ... }:
 
@@ -22,11 +30,19 @@
   <xref linkend="opt-services.httpd.documentRoot"/> = "/webroot";
 }
 </programlisting>
-  defines a configuration with three option definitions that together enable the Apache HTTP Server with <filename>/webroot</filename> as the document root.
+  defines a configuration with three option definitions that together enable
+  the Apache HTTP Server with <filename>/webroot</filename> as the document
+  root.
  </para>
 
  <para>
-  Sets can be nested, and in fact dots in option names are shorthand for defining a set containing another set. For instance, <xref linkend="opt-services.httpd.enable"/> defines a set named <varname>services</varname> that contains a set named <varname>httpd</varname>, which in turn contains an option definition named <varname>enable</varname> with value <literal>true</literal>. This means that the example above can also be written as:
+  Sets can be nested, and in fact dots in option names are shorthand for
+  defining a set containing another set. For instance,
+  <xref linkend="opt-services.httpd.enable"/> defines a set named
+  <varname>services</varname> that contains a set named
+  <varname>httpd</varname>, which in turn contains an option definition named
+  <varname>enable</varname> with value <literal>true</literal>. This means that
+  the example above can also be written as:
 <programlisting>
 { config, pkgs, ... }:
 
@@ -39,15 +55,22 @@
   };
 }
 </programlisting>
-  which may be more convenient if you have lots of option definitions that share the same prefix (such as <literal>services.httpd</literal>).
+  which may be more convenient if you have lots of option definitions that
+  share the same prefix (such as <literal>services.httpd</literal>).
  </para>
 
  <para>
-  NixOS checks your option definitions for correctness. For instance, if you try to define an option that doesn’t exist (that is, doesn’t have a corresponding <emphasis>option declaration</emphasis>), <command>nixos-rebuild</command> will give an error like:
+  NixOS checks your option definitions for correctness. For instance, if you
+  try to define an option that doesn’t exist (that is, doesn’t have a
+  corresponding <emphasis>option declaration</emphasis>),
+  <command>nixos-rebuild</command> will give an error like:
 <screen>
 The option `services.httpd.enable' defined in `/etc/nixos/configuration.nix' does not exist.
 </screen>
-  Likewise, values in option definitions must have a correct type. For instance, <option>services.httpd.enable</option> must be a Boolean (<literal>true</literal> or <literal>false</literal>). Trying to give it a value of another type, such as a string, will cause an error:
+  Likewise, values in option definitions must have a correct type. For
+  instance, <option>services.httpd.enable</option> must be a Boolean
+  (<literal>true</literal> or <literal>false</literal>). Trying to give it a
+  value of another type, such as a string, will cause an error:
 <screen>
 The option value `services.httpd.enable' in `/etc/nixos/configuration.nix' is not a boolean.
 </screen>
@@ -66,18 +89,26 @@ The option value `services.httpd.enable' in `/etc/nixos/configuration.nix' is no
 <programlisting>
 <xref linkend="opt-networking.hostName"/> = "dexter";
 </programlisting>
-      Special characters can be escaped by prefixing them with a backslash (e.g. <literal>\"</literal>).
+      Special characters can be escaped by prefixing them with a backslash
+      (e.g. <literal>\"</literal>).
      </para>
      <para>
-      Multi-line strings can be enclosed in <emphasis>double single quotes</emphasis>, e.g.
+      Multi-line strings can be enclosed in <emphasis>double single
+      quotes</emphasis>, e.g.
 <programlisting>
 <xref linkend="opt-networking.extraHosts"/> =
   ''
     127.0.0.2 other-localhost
     10.0.0.1 server
   '';
 </programlisting>
-      The main difference is that it strips from each line a number of spaces equal to the minimal indentation of the string as a whole (disregarding the indentation of empty lines), and that characters like <literal>"</literal> and <literal>\</literal> are not special (making it more convenient for including things like shell code). See more info about this in the Nix manual <link
+      The main difference is that it strips from each line a number of spaces
+      equal to the minimal indentation of the string as a whole (disregarding
+      the indentation of empty lines), and that characters like
+      <literal>"</literal> and <literal>\</literal> are not special (making it
+      more convenient for including things like shell code). See more info
+      about this in the Nix manual
+      <link
       xlink:href="https://nixos.org/nix/manual/#ssec-values">here</link>.
      </para>
     </listitem>
@@ -106,7 +137,12 @@ The option value `services.httpd.enable' in `/etc/nixos/configuration.nix' is no
 <programlisting>
 <xref linkend="opt-boot.kernel.sysctl"/>."net.ipv4.tcp_keepalive_time" = 60;
 </programlisting>
-      (Note that here the attribute name <literal>net.ipv4.tcp_keepalive_time</literal> is enclosed in quotes to prevent it from being interpreted as a set named <literal>net</literal> containing a set named <literal>ipv4</literal>, and so on. This is because it’s not a NixOS option but the literal name of a Linux kernel setting.)
+      (Note that here the attribute name
+      <literal>net.ipv4.tcp_keepalive_time</literal> is enclosed in quotes to
+      prevent it from being interpreted as a set named <literal>net</literal>
+      containing a set named <literal>ipv4</literal>, and so on. This is
+      because it’s not a NixOS option but the literal name of a Linux kernel
+      setting.)
      </para>
     </listitem>
    </varlistentry>
@@ -116,7 +152,8 @@ The option value `services.httpd.enable' in `/etc/nixos/configuration.nix' is no
     </term>
     <listitem>
      <para>
-      Sets were introduced above. They are name/value pairs enclosed in braces, as in the option definition
+      Sets were introduced above. They are name/value pairs enclosed in braces,
+      as in the option definition
 <programlisting>
 <xref linkend="opt-fileSystems"/>."/boot" =
   { device = "/dev/sda1";
@@ -133,7 +170,8 @@ The option value `services.httpd.enable' in `/etc/nixos/configuration.nix' is no
     </term>
     <listitem>
      <para>
-      The important thing to note about lists is that list elements are separated by whitespace, like this:
+      The important thing to note about lists is that list elements are
+      separated by whitespace, like this:
 <programlisting>
 <xref linkend="opt-boot.kernelModules"/> = [ "fuse" "kvm-intel" "coretemp" ];
 </programlisting>
@@ -150,7 +188,9 @@ swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
     </term>
     <listitem>
      <para>
-      Usually, the packages you need are already part of the Nix Packages collection, which is a set that can be accessed through the function argument <varname>pkgs</varname>. Typical uses:
+      Usually, the packages you need are already part of the Nix Packages
+      collection, which is a set that can be accessed through the function
+      argument <varname>pkgs</varname>. Typical uses:
 <programlisting>
 <xref linkend="opt-environment.systemPackages"/> =
   [ pkgs.thunderbird
@@ -159,7 +199,10 @@ swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
 
 <xref linkend="opt-services.postgresql.package"/> = pkgs.postgresql_10;
 </programlisting>
-      The latter option definition changes the default PostgreSQL package used by NixOS’s PostgreSQL service to 10.x. For more information on packages, including how to add new ones, see <xref linkend="sec-custom-packages"/>.
+      The latter option definition changes the default PostgreSQL package used
+      by NixOS’s PostgreSQL service to 10.x. For more information on
+      packages, including how to add new ones, see
+      <xref linkend="sec-custom-packages"/>.
      </para>
     </listitem>
    </varlistentry>

diff --git a/nixos/doc/manual/configuration/config-syntax.xml b/nixos/doc/manual/configuration/config-syntax.xml
@@ -5,8 +5,18 @@
          xml:id="sec-configuration-syntax">
  <title>Configuration Syntax</title>
  <para>
-  The NixOS configuration file <filename>/etc/nixos/configuration.nix</filename> is actually a <emphasis>Nix expression</emphasis>, which is the Nix package manager’s purely functional language for describing how to build packages and configurations. This means you have all the expressive power of that language at your disposal, including the ability to abstract over common patterns, which is very useful when managing complex systems. The syntax and semantics of the Nix language are fully described in the <link
-xlink:href="http://nixos.org/nix/manual/#chap-writing-nix-expressions">Nix manual</link>, but here we give a short overview of the most important constructs useful in NixOS configuration files.
+  The NixOS configuration file
+  <filename>/etc/nixos/configuration.nix</filename> is actually a <emphasis>Nix
+  expression</emphasis>, which is the Nix package manager’s purely functional
+  language for describing how to build packages and configurations. This means
+  you have all the expressive power of that language at your disposal,
+  including the ability to abstract over common patterns, which is very useful
+  when managing complex systems. The syntax and semantics of the Nix language
+  are fully described in the
+  <link
+xlink:href="http://nixos.org/nix/manual/#chap-writing-nix-expressions">Nix
+  manual</link>, but here we give a short overview of the most important
+  constructs useful in NixOS configuration files.
  </para>
  <xi:include href="config-file.xml" />
  <xi:include href="abstractions.xml" />

diff --git a/nixos/doc/manual/configuration/configuration.xml b/nixos/doc/manual/configuration/configuration.xml
@@ -6,7 +6,11 @@
  <title>Configuration</title>
  <partintro xml:id="ch-configuration-intro">
   <para>
-   This chapter describes how to configure various aspects of a NixOS machine through the configuration file <filename>/etc/nixos/configuration.nix</filename>. As described in <xref linkend="sec-changing-config" />, changes to this file only take effect after you run <command>nixos-rebuild</command>.
+   This chapter describes how to configure various aspects of a NixOS machine
+   through the configuration file
+   <filename>/etc/nixos/configuration.nix</filename>. As described in
+   <xref linkend="sec-changing-config" />, changes to this file only take
+   effect after you run <command>nixos-rebuild</command>.
   </para>
  </partintro>
  <xi:include href="config-syntax.xml" />

diff --git a/nixos/doc/manual/configuration/customizing-packages.xml b/nixos/doc/manual/configuration/customizing-packages.xml
@@ -6,25 +6,47 @@
  <title>Customising Packages</title>
 
  <para>
-  Some packages in Nixpkgs have options to enable or disable optional functionality or change other aspects of the package. For instance, the Firefox wrapper package (which provides Firefox with a set of plugins such as the Adobe Flash player) has an option to enable the Google Talk plugin. It can be set in <filename>configuration.nix</filename> as follows: <filename> nixpkgs.config.firefox.enableGoogleTalkPlugin = true; </filename>
+  Some packages in Nixpkgs have options to enable or disable optional
+  functionality or change other aspects of the package. For instance, the
+  Firefox wrapper package (which provides Firefox with a set of plugins such as
+  the Adobe Flash player) has an option to enable the Google Talk plugin. It
+  can be set in <filename>configuration.nix</filename> as follows: <filename>
+  nixpkgs.config.firefox.enableGoogleTalkPlugin = true; </filename>
  </para>
 
  <warning>
   <para>
-   Unfortunately, Nixpkgs currently lacks a way to query available configuration options.
+   Unfortunately, Nixpkgs currently lacks a way to query available
+   configuration options.
   </para>
  </warning>
 
  <para>
-  Apart from high-level options, it’s possible to tweak a package in almost arbitrary ways, such as changing or disabling dependencies of a package. For instance, the Emacs package in Nixpkgs by default has a dependency on GTK 2. If you want to build it against GTK 3, you can specify that as follows:
+  Apart from high-level options, it’s possible to tweak a package in almost
+  arbitrary ways, such as changing or disabling dependencies of a package. For
+  instance, the Emacs package in Nixpkgs by default has a dependency on GTK 2.
+  If you want to build it against GTK 3, you can specify that as follows:
 <programlisting>
 <xref linkend="opt-environment.systemPackages"/> = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ];
 </programlisting>
-  The function <varname>override</varname> performs the call to the Nix function that produces Emacs, with the original arguments amended by the set of arguments specified by you. So here the function argument <varname>gtk</varname> gets the value <literal>pkgs.gtk3</literal>, causing Emacs to depend on GTK 3. (The parentheses are necessary because in Nix, function application binds more weakly than list construction, so without them, <xref linkend="opt-environment.systemPackages"/> would be a list with two elements.)
+  The function <varname>override</varname> performs the call to the Nix
+  function that produces Emacs, with the original arguments amended by the set
+  of arguments specified by you. So here the function argument
+  <varname>gtk</varname> gets the value <literal>pkgs.gtk3</literal>, causing
+  Emacs to depend on GTK 3. (The parentheses are necessary because in Nix,
+  function application binds more weakly than list construction, so without
+  them, <xref linkend="opt-environment.systemPackages"/> would be a list with
+  two elements.)
  </para>
 
  <para>
-  Even greater customisation is possible using the function <varname>overrideAttrs</varname>. While the <varname>override</varname> mechanism above overrides the arguments of a package function, <varname>overrideAttrs</varname> allows changing the <emphasis>attributes</emphasis> passed to <literal>mkDerivation</literal>. This permits changing any aspect of the package, such as the source code. For instance, if you want to override the source code of Emacs, you can say:
+  Even greater customisation is possible using the function
+  <varname>overrideAttrs</varname>. While the <varname>override</varname>
+  mechanism above overrides the arguments of a package function,
+  <varname>overrideAttrs</varname> allows changing the
+  <emphasis>attributes</emphasis> passed to <literal>mkDerivation</literal>.
+  This permits changing any aspect of the package, such as the source code. For
+  instance, if you want to override the source code of Emacs, you can say:
 <programlisting>
 <xref linkend="opt-environment.systemPackages"/> = [
   (pkgs.emacs.overrideAttrs (oldAttrs: {
@@ -33,16 +55,32 @@
   }))
 ];
 </programlisting>
-  Here, <varname>overrideAttrs</varname> takes the Nix derivation specified by <varname>pkgs.emacs</varname> and produces a new derivation in which the original’s <literal>name</literal> and <literal>src</literal> attribute have been replaced by the given values by re-calling <literal>stdenv.mkDerivation</literal>. The original attributes are accessible via the function argument, which is conventionally named <varname>oldAttrs</varname>.
+  Here, <varname>overrideAttrs</varname> takes the Nix derivation specified by
+  <varname>pkgs.emacs</varname> and produces a new derivation in which the
+  original’s <literal>name</literal> and <literal>src</literal> attribute
+  have been replaced by the given values by re-calling
+  <literal>stdenv.mkDerivation</literal>. The original attributes are
+  accessible via the function argument, which is conventionally named
+  <varname>oldAttrs</varname>.
  </para>
 
  <para>
-  The overrides shown above are not global. They do not affect the original package; other packages in Nixpkgs continue to depend on the original rather than the customised package. This means that if another package in your system depends on the original package, you end up with two instances of the package. If you want to have everything depend on your customised instance, you can apply a <emphasis>global</emphasis> override as follows:
+  The overrides shown above are not global. They do not affect the original
+  package; other packages in Nixpkgs continue to depend on the original rather
+  than the customised package. This means that if another package in your
+  system depends on the original package, you end up with two instances of the
+  package. If you want to have everything depend on your customised instance,
+  you can apply a <emphasis>global</emphasis> override as follows:
 <screen>
 nixpkgs.config.packageOverrides = pkgs:
   { emacs = pkgs.emacs.override { gtk = pkgs.gtk3; };
   };
 </screen>
-  The effect of this definition is essentially equivalent to modifying the <literal>emacs</literal> attribute in the Nixpkgs source tree. Any package in Nixpkgs that depends on <literal>emacs</literal> will be passed your customised instance. (However, the value <literal>pkgs.emacs</literal> in <varname>nixpkgs.config.packageOverrides</varname> refers to the original rather than overridden instance, to prevent an infinite recursion.)
+  The effect of this definition is essentially equivalent to modifying the
+  <literal>emacs</literal> attribute in the Nixpkgs source tree. Any package in
+  Nixpkgs that depends on <literal>emacs</literal> will be passed your
+  customised instance. (However, the value <literal>pkgs.emacs</literal> in
+  <varname>nixpkgs.config.packageOverrides</varname> refers to the original
+  rather than overridden instance, to prevent an infinite recursion.)
  </para>
 </section>
diff --git a/nixos/doc/manual/configuration/declarative-packages.xml b/nixos/doc/manual/configuration/declarative-packages.xml
@@ -6,11 +6,17 @@
  <title>Declarative Package Management</title>
 
  <para>
-  With declarative package management, you specify which packages you want on your system by setting the option <xref linkend="opt-environment.systemPackages"/>. For instance, adding the following line to <filename>configuration.nix</filename> enables the Mozilla Thunderbird email application:
+  With declarative package management, you specify which packages you want on
+  your system by setting the option
+  <xref linkend="opt-environment.systemPackages"/>. For instance, adding the
+  following line to <filename>configuration.nix</filename> enables the Mozilla
+  Thunderbird email application:
 <programlisting>
 <xref linkend="opt-environment.systemPackages"/> = [ pkgs.thunderbird ];
 </programlisting>
-  The effect of this specification is that the Thunderbird package from Nixpkgs will be built or downloaded as part of the system when you run <command>nixos-rebuild switch</command>.
+  The effect of this specification is that the Thunderbird package from Nixpkgs
+  will be built or downloaded as part of the system when you run
+  <command>nixos-rebuild switch</command>.
  </para>
 
  <para>
@@ -20,15 +26,20 @@
 nixos.firefox   firefox-23.0   Mozilla Firefox - the browser, reloaded
 <replaceable>...</replaceable>
 </screen>
-  The first column in the output is the <emphasis>attribute name</emphasis>, such as <literal>nixos.thunderbird</literal>.
+  The first column in the output is the <emphasis>attribute name</emphasis>,
+  such as <literal>nixos.thunderbird</literal>.
  </para>
-
  <para>
-  Note: the <literal>nixos</literal> prefix tells us that we want to get the package from the <literal>nixos</literal> channel and works only in CLI tools. In declarative configuration use <literal>pkgs</literal> prefix (variable).
+  Note: the <literal>nixos</literal> prefix tells us that we want to get the
+  package from the <literal>nixos</literal> channel and works only in CLI tools.
+
+  In declarative configuration use <literal>pkgs</literal> prefix (variable).
  </para>
 
  <para>
-  To “uninstall” a package, simply remove it from <xref linkend="opt-environment.systemPackages"/> and run <command>nixos-rebuild switch</command>.
+  To “uninstall” a package, simply remove it from
+  <xref linkend="opt-environment.systemPackages"/> and run
+  <command>nixos-rebuild switch</command>.
  </para>
 
  <xi:include href="customizing-packages.xml" />

diff --git a/nixos/doc/manual/configuration/file-systems.xml b/nixos/doc/manual/configuration/file-systems.xml
@@ -5,21 +5,41 @@
          xml:id="ch-file-systems">
  <title>File Systems</title>
  <para>
-  You can define file systems using the <option>fileSystems</option> configuration option. For instance, the following definition causes NixOS to mount the Ext4 file system on device <filename>/dev/disk/by-label/data</filename> onto the mount point <filename>/data</filename>:
+  You can define file systems using the <option>fileSystems</option>
+  configuration option. For instance, the following definition causes NixOS to
+  mount the Ext4 file system on device
+  <filename>/dev/disk/by-label/data</filename> onto the mount point
+  <filename>/data</filename>:
 <programlisting>
 <xref linkend="opt-fileSystems"/>."/data" =
   { device = "/dev/disk/by-label/data";
     fsType = "ext4";
   };
 </programlisting>
-  Mount points are created automatically if they don’t already exist. For <option><link linkend="opt-fileSystems._name__.device">device</link></option>, it’s best to use the topology-independent device aliases in <filename>/dev/disk/by-label</filename> and <filename>/dev/disk/by-uuid</filename>, as these don’t change if the topology changes (e.g. if a disk is moved to another IDE controller).
+  Mount points are created automatically if they don’t already exist. For
+  <option><link linkend="opt-fileSystems._name__.device">device</link></option>,
+  it’s best to use the topology-independent device aliases in
+  <filename>/dev/disk/by-label</filename> and
+  <filename>/dev/disk/by-uuid</filename>, as these don’t change if the
+  topology changes (e.g. if a disk is moved to another IDE controller).
  </para>
  <para>
-  You can usually omit the file system type (<option><link linkend="opt-fileSystems._name__.fsType">fsType</link></option>), since <command>mount</command> can usually detect the type and load the necessary kernel module automatically. However, if the file system is needed at early boot (in the initial ramdisk) and is not <literal>ext2</literal>, <literal>ext3</literal> or <literal>ext4</literal>, then it’s best to specify <option>fsType</option> to ensure that the kernel module is available.
+  You can usually omit the file system type
+  (<option><link linkend="opt-fileSystems._name__.fsType">fsType</link></option>),
+  since <command>mount</command> can usually detect the type and load the
+  necessary kernel module automatically. However, if the file system is needed
+  at early boot (in the initial ramdisk) and is not <literal>ext2</literal>,
+  <literal>ext3</literal> or <literal>ext4</literal>, then it’s best to
+  specify <option>fsType</option> to ensure that the kernel module is
+  available.
  </para>
  <note>
   <para>
-   System startup will fail if any of the filesystems fails to mount, dropping you to the emergency shell. You can make a mount asynchronous and non-critical by adding <literal><link linkend="opt-fileSystems._name__.options">options</link> = [ "nofail" ];</literal>.
+   System startup will fail if any of the filesystems fails to mount, dropping
+   you to the emergency shell. You can make a mount asynchronous and
+   non-critical by adding
+   <literal><link linkend="opt-fileSystems._name__.options">options</link> = [
+   "nofail" ];</literal>.
   </para>
  </note>
  <xi:include href="luks-file-systems.xml" />

diff --git a/nixos/doc/manual/configuration/firewall.xml b/nixos/doc/manual/configuration/firewall.xml
@@ -6,15 +6,21 @@
  <title>Firewall</title>
 
  <para>
-  NixOS has a simple stateful firewall that blocks incoming connections and other unexpected packets. The firewall applies to both IPv4 and IPv6 traffic. It is enabled by default. It can be disabled as follows:
+  NixOS has a simple stateful firewall that blocks incoming connections and
+  other unexpected packets. The firewall applies to both IPv4 and IPv6 traffic.
+  It is enabled by default. It can be disabled as follows:
 <programlisting>
 <xref linkend="opt-networking.firewall.enable"/> = false;
 </programlisting>
-  If the firewall is enabled, you can open specific TCP ports to the outside world:
+  If the firewall is enabled, you can open specific TCP ports to the outside
+  world:
 <programlisting>
 <xref linkend="opt-networking.firewall.allowedTCPPorts"/> = [ 80 443 ];
 </programlisting>
-  Note that TCP port 22 (ssh) is opened automatically if the SSH daemon is enabled (<option><xref linkend="opt-services.openssh.enable"/> = true</option>). UDP ports can be opened through <xref linkend="opt-networking.firewall.allowedUDPPorts"/>.
+  Note that TCP port 22 (ssh) is opened automatically if the SSH daemon is
+  enabled (<option><xref linkend="opt-services.openssh.enable"/> =
+  true</option>). UDP ports can be opened through
+  <xref linkend="opt-networking.firewall.allowedUDPPorts"/>.
  </para>
 
  <para>
@@ -25,6 +31,7 @@
   { from = 8000; to = 8010; }
 ];
 </programlisting>
-  Similarly, UDP port ranges can be opened through <xref linkend="opt-networking.firewall.allowedUDPPortRanges"/>.
+  Similarly, UDP port ranges can be opened through
+  <xref linkend="opt-networking.firewall.allowedUDPPortRanges"/>.
  </para>
 </section>
diff --git a/nixos/doc/manual/configuration/ipv4-config.xml b/nixos/doc/manual/configuration/ipv4-config.xml
@@ -6,14 +6,17 @@
  <title>IPv4 Configuration</title>
 
  <para>
-  By default, NixOS uses DHCP (specifically, <command>dhcpcd</command>) to automatically configure network interfaces. However, you can configure an interface manually as follows:
+  By default, NixOS uses DHCP (specifically, <command>dhcpcd</command>) to
+  automatically configure network interfaces. However, you can configure an
+  interface manually as follows:
 <programlisting>
 <link linkend="opt-networking.interfaces._name__.ipv4.addresses">networking.interfaces.eth0.ipv4.addresses</link> = [ {
   address = "192.168.1.2";
   prefixLength = 24;
 } ];
 </programlisting>
-  Typically you’ll also want to set a default gateway and set of name servers:
+  Typically you’ll also want to set a default gateway and set of name
+  servers:
 <programlisting>
 <xref linkend="opt-networking.defaultGateway"/> = "192.168.1.1";
 <xref linkend="opt-networking.nameservers"/> = [ "8.8.8.8" ];
@@ -22,7 +25,10 @@
 
  <note>
   <para>
-   Statically configured interfaces are set up by the systemd service <replaceable>interface-name</replaceable><literal>-cfg.service</literal>. The default gateway and name server configuration is performed by <literal>network-setup.service</literal>.
+   Statically configured interfaces are set up by the systemd service
+   <replaceable>interface-name</replaceable><literal>-cfg.service</literal>.
+   The default gateway and name server configuration is performed by
+   <literal>network-setup.service</literal>.
   </para>
  </note>
 
@@ -31,6 +37,7 @@
 <programlisting>
 <xref linkend="opt-networking.hostName"/> = "cartman";
 </programlisting>
-  The default host name is <literal>nixos</literal>. Set it to the empty string (<literal>""</literal>) to allow the DHCP server to provide the host name.
+  The default host name is <literal>nixos</literal>. Set it to the empty string
+  (<literal>""</literal>) to allow the DHCP server to provide the host name.
  </para>
 </section>
diff --git a/nixos/doc/manual/configuration/ipv6-config.xml b/nixos/doc/manual/configuration/ipv6-config.xml
@@ -6,21 +6,25 @@
  <title>IPv6 Configuration</title>
 
  <para>
-  IPv6 is enabled by default. Stateless address autoconfiguration is used to automatically assign IPv6 addresses to all interfaces. You can disable IPv6 support globally by setting:
+  IPv6 is enabled by default. Stateless address autoconfiguration is used to
+  automatically assign IPv6 addresses to all interfaces. You can disable IPv6
+  support globally by setting:
 <programlisting>
 <xref linkend="opt-networking.enableIPv6"/> = false;
 </programlisting>
  </para>
 
  <para>
-  You can disable IPv6 on a single interface using a normal sysctl (in this example, we use interface <varname>eth0</varname>):
+  You can disable IPv6 on a single interface using a normal sysctl (in this
+  example, we use interface <varname>eth0</varname>):
 <programlisting>
 <xref linkend="opt-boot.kernel.sysctl"/>."net.ipv6.conf.eth0.disable_ipv6" = true;
 </programlisting>
  </para>
 
  <para>
-  As with IPv4 networking interfaces are automatically configured via DHCPv6. You can configure an interface manually:
+  As with IPv4 networking interfaces are automatically configured via DHCPv6.
+  You can configure an interface manually:
 <programlisting>
 <link linkend="opt-networking.interfaces._name__.ipv6.addresses">networking.interfaces.eth0.ipv6.addresses</link> = [ {
   address = "fe00:aa:bb:cc::2";
@@ -40,6 +44,7 @@
  </para>
 
  <para>
-  See <xref linkend='sec-ipv4' /> for similar examples and additional information.
+  See <xref linkend='sec-ipv4' /> for similar examples and additional
+  information.
  </para>
 </section>
diff --git a/nixos/doc/manual/configuration/kubernetes.xml b/nixos/doc/manual/configuration/kubernetes.xml
@@ -5,10 +5,12 @@
          xml:id="sec-kubernetes">
  <title>Kubernetes</title>
  <para>
-  The NixOS Kubernetes module is a collective term for a handful of individual submodules implementing the Kubernetes cluster components.
+  The NixOS Kubernetes module is a collective term for a handful of individual
+  submodules implementing the Kubernetes cluster components.
  </para>
  <para>
-  There are generally two ways of enabling Kubernetes on NixOS. One way is to enable and configure cluster components appropriately by hand:
+  There are generally two ways of enabling Kubernetes on NixOS. One way is to
+  enable and configure cluster components appropriately by hand:
 <programlisting>
 services.kubernetes = {
   apiserver.enable = true;
@@ -19,44 +21,92 @@ services.kubernetes = {
   flannel.enable = true;
 };
 </programlisting>
-  Another way is to assign cluster roles ("master" and/or "node") to the host. This enables apiserver, controllerManager, scheduler, addonManager, kube-proxy and etcd:
+  Another way is to assign cluster roles ("master" and/or "node") to the host.
+  This enables apiserver, controllerManager, scheduler, addonManager,
+  kube-proxy and etcd:
 <programlisting>
 <xref linkend="opt-services.kubernetes.roles"/> = [ "master" ];
 </programlisting>
   While this will enable the kubelet and kube-proxy only:
 <programlisting>
 <xref linkend="opt-services.kubernetes.roles"/> = [ "node" ];
 </programlisting>
-  Assigning both the master and node roles is usable if you want a single node Kubernetes cluster for dev or testing purposes:
+  Assigning both the master and node roles is usable if you want a single node
+  Kubernetes cluster for dev or testing purposes:
 <programlisting>
 <xref linkend="opt-services.kubernetes.roles"/> = [ "master" "node" ];
 </programlisting>
-  Note: Assigning either role will also default both <xref linkend="opt-services.kubernetes.flannel.enable"/> and <xref linkend="opt-services.kubernetes.easyCerts"/> to true. This sets up flannel as CNI and activates automatic PKI bootstrapping.
+  Note: Assigning either role will also default both
+  <xref linkend="opt-services.kubernetes.flannel.enable"/> and
+  <xref linkend="opt-services.kubernetes.easyCerts"/> to true. This sets up
+  flannel as CNI and activates automatic PKI bootstrapping.
  </para>
  <para>
-  As of kubernetes 1.10.X it has been deprecated to open non-tls-enabled ports on kubernetes components. Thus, from NixOS 19.03 all plain HTTP ports have been disabled by default. While opening insecure ports is still possible, it is recommended not to bind these to other interfaces than loopback. To re-enable the insecure port on the apiserver, see options: <xref linkend="opt-services.kubernetes.apiserver.insecurePort"/> and <xref linkend="opt-services.kubernetes.apiserver.insecureBindAddress"/>
+  As of kubernetes 1.10.X it has been deprecated to open non-tls-enabled ports
+  on kubernetes components. Thus, from NixOS 19.03 all plain HTTP ports have
+  been disabled by default. While opening insecure ports is still possible, it
+  is recommended not to bind these to other interfaces than loopback. To
+  re-enable the insecure port on the apiserver, see options:
+  <xref linkend="opt-services.kubernetes.apiserver.insecurePort"/> and
+  <xref linkend="opt-services.kubernetes.apiserver.insecureBindAddress"/>
  </para>
  <note>
   <para>
-   As of NixOS 19.03, it is mandatory to configure: <xref linkend="opt-services.kubernetes.masterAddress"/>. The masterAddress must be resolveable and routeable by all cluster nodes. In single node clusters, this can be set to <literal>localhost</literal>.
+   As of NixOS 19.03, it is mandatory to configure:
+   <xref linkend="opt-services.kubernetes.masterAddress"/>. The masterAddress
+   must be resolveable and routeable by all cluster nodes. In single node
+   clusters, this can be set to <literal>localhost</literal>.
   </para>
  </note>
  <para>
-  Role-based access control (RBAC) authorization mode is enabled by default. This means that anonymous requests to the apiserver secure port will expectedly cause a permission denied error. All cluster components must therefore be configured with x509 certificates for two-way tls communication. The x509 certificate subject section determines the roles and permissions granted by the apiserver to perform clusterwide or namespaced operations. See also: <link
-     xlink:href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/"> Using RBAC Authorization</link>.
+  Role-based access control (RBAC) authorization mode is enabled by default.
+  This means that anonymous requests to the apiserver secure port will
+  expectedly cause a permission denied error. All cluster components must
+  therefore be configured with x509 certificates for two-way tls communication.
+  The x509 certificate subject section determines the roles and permissions
+  granted by the apiserver to perform clusterwide or namespaced operations. See
+  also:
+  <link
+     xlink:href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/">
+  Using RBAC Authorization</link>.
  </para>
  <para>
-  The NixOS kubernetes module provides an option for automatic certificate bootstrapping and configuration, <xref linkend="opt-services.kubernetes.easyCerts"/>. The PKI bootstrapping process involves setting up a certificate authority (CA) daemon (cfssl) on the kubernetes master node. cfssl generates a CA-cert for the cluster, and uses the CA-cert for signing subordinate certs issued to each of the cluster components. Subsequently, the certmgr daemon monitors active certificates and renews them when needed. For single node Kubernetes clusters, setting <xref linkend="opt-services.kubernetes.easyCerts"/> = true is sufficient and no further action is required. For joining extra node machines to an existing cluster on the other hand, establishing initial trust is mandatory.
+  The NixOS kubernetes module provides an option for automatic certificate
+  bootstrapping and configuration,
+  <xref linkend="opt-services.kubernetes.easyCerts"/>. The PKI bootstrapping
+  process involves setting up a certificate authority (CA) daemon (cfssl) on
+  the kubernetes master node. cfssl generates a CA-cert for the cluster, and
+  uses the CA-cert for signing subordinate certs issued to each of the cluster
+  components. Subsequently, the certmgr daemon monitors active certificates and
+  renews them when needed. For single node Kubernetes clusters, setting
+  <xref linkend="opt-services.kubernetes.easyCerts"/> = true is sufficient and
+  no further action is required. For joining extra node machines to an existing
+  cluster on the other hand, establishing initial trust is mandatory.
  </para>
  <para>
-  To add new nodes to the cluster: On any (non-master) cluster node where <xref linkend="opt-services.kubernetes.easyCerts"/> is enabled, the helper script <literal>nixos-kubernetes-node-join</literal> is available on PATH. Given a token on stdin, it will copy the token to the kubernetes secrets directory and restart the certmgr service. As requested certificates are issued, the script will restart kubernetes cluster components as needed for them to pick up new keypairs.
+  To add new nodes to the cluster: On any (non-master) cluster node where
+  <xref linkend="opt-services.kubernetes.easyCerts"/> is enabled, the helper
+  script <literal>nixos-kubernetes-node-join</literal> is available on PATH.
+  Given a token on stdin, it will copy the token to the kubernetes secrets
+  directory and restart the certmgr service. As requested certificates are
+  issued, the script will restart kubernetes cluster components as needed for
+  them to pick up new keypairs.
  </para>
  <note>
   <para>
    Multi-master (HA) clusters are not supported by the easyCerts module.
   </para>
  </note>
  <para>
-  In order to interact with an RBAC-enabled cluster as an administrator, one needs to have cluster-admin privileges. By default, when easyCerts is enabled, a cluster-admin kubeconfig file is generated and linked into <literal>/etc/kubernetes/cluster-admin.kubeconfig</literal> as determined by <xref linkend="opt-services.kubernetes.pki.etcClusterAdminKubeconfig"/>. <literal>export KUBECONFIG=/etc/kubernetes/cluster-admin.kubeconfig</literal> will make kubectl use this kubeconfig to access and authenticate the cluster. The cluster-admin kubeconfig references an auto-generated keypair owned by root. Thus, only root on the kubernetes master may obtain cluster-admin rights by means of this file.
+  In order to interact with an RBAC-enabled cluster as an administrator, one
+  needs to have cluster-admin privileges. By default, when easyCerts is
+  enabled, a cluster-admin kubeconfig file is generated and linked into
+  <literal>/etc/kubernetes/cluster-admin.kubeconfig</literal> as determined by
+  <xref linkend="opt-services.kubernetes.pki.etcClusterAdminKubeconfig"/>.
+  <literal>export KUBECONFIG=/etc/kubernetes/cluster-admin.kubeconfig</literal>
+  will make kubectl use this kubeconfig to access and authenticate the cluster.
+  The cluster-admin kubeconfig references an auto-generated keypair owned by
+  root. Thus, only root on the kubernetes master may obtain cluster-admin
+  rights by means of this file.
  </para>
 </chapter>
diff --git a/nixos/doc/manual/configuration/linux-kernel.xml b/nixos/doc/manual/configuration/linux-kernel.xml
@@ -5,19 +5,27 @@
          xml:id="sec-kernel-config">
  <title>Linux Kernel</title>
  <para>
-  You can override the Linux kernel and associated packages using the option <option>boot.kernelPackages</option>. For instance, this selects the Linux 3.10 kernel:
+  You can override the Linux kernel and associated packages using the option
+  <option>boot.kernelPackages</option>. For instance, this selects the Linux
+  3.10 kernel:
 <programlisting>
 <xref linkend="opt-boot.kernelPackages"/> = pkgs.linuxPackages_3_10;
 </programlisting>
-  Note that this not only replaces the kernel, but also packages that are specific to the kernel version, such as the NVIDIA video drivers. This ensures that driver packages are consistent with the kernel.
+  Note that this not only replaces the kernel, but also packages that are
+  specific to the kernel version, such as the NVIDIA video drivers. This
+  ensures that driver packages are consistent with the kernel.
  </para>
  <para>
-  The default Linux kernel configuration should be fine for most users. You can see the configuration of your current kernel with the following command:
+  The default Linux kernel configuration should be fine for most users. You can
+  see the configuration of your current kernel with the following command:
 <programlisting>
 zcat /proc/config.gz
 </programlisting>
-  If you want to change the kernel configuration, you can use the <option>packageOverrides</option> feature (see <xref
-linkend="sec-customising-packages" />). For instance, to enable support for the kernel debugger KGDB:
+  If you want to change the kernel configuration, you can use the
+  <option>packageOverrides</option> feature (see
+  <xref
+linkend="sec-customising-packages" />). For instance, to enable support
+  for the kernel debugger KGDB:
 <programlisting>
 nixpkgs.config.packageOverrides = pkgs:
   { linux_3_4 = pkgs.linux_3_4.override {
@@ -28,31 +36,44 @@ nixpkgs.config.packageOverrides = pkgs:
     };
   };
 </programlisting>
-  <varname>extraConfig</varname> takes a list of Linux kernel configuration options, one per line. The name of the option should not include the prefix <literal>CONFIG_</literal>. The option value is typically <literal>y</literal>, <literal>n</literal> or <literal>m</literal> (to build something as a kernel module).
+  <varname>extraConfig</varname> takes a list of Linux kernel configuration
+  options, one per line. The name of the option should not include the prefix
+  <literal>CONFIG_</literal>. The option value is typically
+  <literal>y</literal>, <literal>n</literal> or <literal>m</literal> (to build
+  something as a kernel module).
  </para>
  <para>
-  Kernel modules for hardware devices are generally loaded automatically by <command>udev</command>. You can force a module to be loaded via <xref linkend="opt-boot.kernelModules"/>, e.g.
+  Kernel modules for hardware devices are generally loaded automatically by
+  <command>udev</command>. You can force a module to be loaded via
+  <xref linkend="opt-boot.kernelModules"/>, e.g.
 <programlisting>
 <xref linkend="opt-boot.kernelModules"/> = [ "fuse" "kvm-intel" "coretemp" ];
 </programlisting>
-  If the module is required early during the boot (e.g. to mount the root file system), you can use <xref linkend="opt-boot.initrd.kernelModules"/>:
+  If the module is required early during the boot (e.g. to mount the root file
+  system), you can use <xref linkend="opt-boot.initrd.kernelModules"/>:
 <programlisting>
 <xref linkend="opt-boot.initrd.kernelModules"/> = [ "cifs" ];
 </programlisting>
-  This causes the specified modules and their dependencies to be added to the initial ramdisk.
+  This causes the specified modules and their dependencies to be added to the
+  initial ramdisk.
  </para>
  <para>
-  Kernel runtime parameters can be set through <xref linkend="opt-boot.kernel.sysctl"/>, e.g.
+  Kernel runtime parameters can be set through
+  <xref linkend="opt-boot.kernel.sysctl"/>, e.g.
 <programlisting>
 <xref linkend="opt-boot.kernel.sysctl"/>."net.ipv4.tcp_keepalive_time" = 120;
 </programlisting>
-  sets the kernel’s TCP keepalive time to 120 seconds. To see the available parameters, run <command>sysctl -a</command>.
+  sets the kernel’s TCP keepalive time to 120 seconds. To see the available
+  parameters, run <command>sysctl -a</command>.
  </para>
  <section xml:id="sec-linux-config-customizing">
   <title>Customize your kernel</title>
 
   <para>
-   The first step before compiling the kernel is to generate an appropriate <literal>.config</literal> configuration. Either you pass your own config via the <literal>configfile</literal> setting of <literal>linuxManualConfig</literal>:
+   The first step before compiling the kernel is to generate an appropriate
+   <literal>.config</literal> configuration. Either you pass your own config
+   via the <literal>configfile</literal> setting of
+   <literal>linuxManualConfig</literal>:
 <screen><![CDATA[
   custom-kernel = super.linuxManualConfig {
     inherit (super) stdenv hostPlatform;
@@ -63,11 +84,17 @@ nixpkgs.config.packageOverrides = pkgs:
     allowImportFromDerivation = true;
   };
   ]]></screen>
-   You can edit the config with this snippet (by default <command>make menuconfig</command> won't work out of the box on nixos):
+   You can edit the config with this snippet (by default <command>make
+   menuconfig</command> won't work out of the box on nixos):
 <screen><![CDATA[
       nix-shell -E 'with import <nixpkgs> {}; kernelToOverride.overrideAttrs (o: {nativeBuildInputs=o.nativeBuildInputs ++ [ pkgconfig ncurses ];})'
   ]]></screen>
-   or you can let nixpkgs generate the configuration. Nixpkgs generates it via answering the interactive kernel utility <command>make config</command>. The answers depend on parameters passed to <filename>pkgs/os-specific/linux/kernel/generic.nix</filename> (which you can influence by overriding <literal>extraConfig, autoModules, modDirVersion, preferBuiltin, extraConfig</literal>).
+   or you can let nixpkgs generate the configuration. Nixpkgs generates it via
+   answering the interactive kernel utility <command>make config</command>. The
+   answers depend on parameters passed to
+   <filename>pkgs/os-specific/linux/kernel/generic.nix</filename> (which you
+   can influence by overriding <literal>extraConfig, autoModules,
+   modDirVersion, preferBuiltin, extraConfig</literal>).
 <screen><![CDATA[
 
   mptcp93.override ({
@@ -94,7 +121,9 @@ nixpkgs.config.packageOverrides = pkgs:
   <title>Developing kernel modules</title>
 
   <para>
-   When developing kernel modules it's often convenient to run edit-compile-run loop as quickly as possible. See below snippet as an example of developing <literal>mellanox</literal> drivers.
+   When developing kernel modules it's often convenient to run edit-compile-run
+   loop as quickly as possible. See below snippet as an example of developing
+   <literal>mellanox</literal> drivers.
   </para>
 
 <screen><![CDATA[

diff --git a/nixos/doc/manual/configuration/luks-file-systems.xml b/nixos/doc/manual/configuration/luks-file-systems.xml
@@ -6,7 +6,10 @@
  <title>LUKS-Encrypted File Systems</title>
 
  <para>
-  NixOS supports file systems that are encrypted using <emphasis>LUKS</emphasis> (Linux Unified Key Setup). For example, here is how you create an encrypted Ext4 file system on the device <filename>/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d</filename>:
+  NixOS supports file systems that are encrypted using
+  <emphasis>LUKS</emphasis> (Linux Unified Key Setup). For example, here is how
+  you create an encrypted Ext4 file system on the device
+  <filename>/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d</filename>:
 <screen>
 # cryptsetup luksFormat /dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d
 
@@ -23,12 +26,15 @@ Enter passphrase for /dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d: ***
 
 # mkfs.ext4 /dev/mapper/crypted
 </screen>
-  To ensure that this file system is automatically mounted at boot time as <filename>/</filename>, add the following to <filename>configuration.nix</filename>:
+  To ensure that this file system is automatically mounted at boot time as
+  <filename>/</filename>, add the following to
+  <filename>configuration.nix</filename>:
 <programlisting>
 <link linkend="opt-boot.initrd.luks.devices._name__.device">boot.initrd.luks.devices.crypted.device</link> = "/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d";
 <xref linkend="opt-fileSystems"/>."/".device = "/dev/mapper/crypted";
 </programlisting>
-  Should grub be used as bootloader, and <filename>/boot</filename> is located on an encrypted partition, it is necessary to add the following grub option:
+  Should grub be used as bootloader, and <filename>/boot</filename> is located
+  on an encrypted partition, it is necessary to add the following grub option:
 <programlisting><xref linkend="opt-boot.loader.grub.enableCryptodisk"/> = true;</programlisting>
  </para>
 </section>
diff --git a/nixos/doc/manual/configuration/matrix.xml b/nixos/doc/manual/configuration/matrix.xml
@@ -5,16 +5,33 @@
          xml:id="module-services-matrix">
  <title>Matrix</title>
  <para>
-  <link xlink:href="https://matrix.org/">Matrix</link> is an open standard for interoperable, decentralised, real-time communication over IP. It can be used to power Instant Messaging, VoIP/WebRTC signalling, Internet of Things communication - or anywhere you need a standard HTTP API for publishing and subscribing to data whilst tracking the conversation history.
+  <link xlink:href="https://matrix.org/">Matrix</link> is an open standard for
+  interoperable, decentralised, real-time communication over IP. It can be used
+  to power Instant Messaging, VoIP/WebRTC signalling, Internet of Things
+  communication - or anywhere you need a standard HTTP API for publishing and
+  subscribing to data whilst tracking the conversation history.
  </para>
  <para>
-  This chapter will show you how to set up your own, self-hosted Matrix homeserver using the Synapse reference homeserver, and how to serve your own copy of the Riot web client. See the <link xlink:href="https://matrix.org/docs/projects/try-matrix-now.html">Try Matrix Now!</link> overview page for links to Riot Apps for Android and iOS, desktop clients, as well as bridges to other networks and other projects around Matrix.
+  This chapter will show you how to set up your own, self-hosted Matrix
+  homeserver using the Synapse reference homeserver, and how to serve your own
+  copy of the Riot web client. See the
+  <link xlink:href="https://matrix.org/docs/projects/try-matrix-now.html">Try
+  Matrix Now!</link> overview page for links to Riot Apps for Android and iOS,
+  desktop clients, as well as bridges to other networks and other projects
+  around Matrix.
  </para>
  <section xml:id="module-services-matrix-synapse">
   <title>Synapse Homeserver</title>
 
   <para>
-   <link xlink:href="https://github.com/matrix-org/synapse">Synapse</link> is the reference homeserver implementation of Matrix from the core development team at matrix.org. The following configuration example will set up a synapse server for the <literal>example.org</literal> domain, served from the host <literal>myhostname.example.org</literal>. For more information, please refer to the <link xlink:href="https://github.com/matrix-org/synapse#synapse-installation"> installation instructions of Synapse </link>.
+   <link xlink:href="https://github.com/matrix-org/synapse">Synapse</link> is
+   the reference homeserver implementation of Matrix from the core development
+   team at matrix.org. The following configuration example will set up a
+   synapse server for the <literal>example.org</literal> domain, served from
+   the host <literal>myhostname.example.org</literal>. For more information,
+   please refer to the
+   <link xlink:href="https://github.com/matrix-org/synapse#synapse-installation">
+   installation instructions of Synapse </link>.
 <programlisting>
 let
   fqdn =
@@ -104,11 +121,26 @@ in {
   </para>
 
   <para>
-   If the <code>A</code> and <code>AAAA</code> DNS records on <literal>example.org</literal> do not point on the same host as the records for <code>myhostname.example.org</code>, you can easily move the <code>/.well-known</code> virtualHost section of the code to the host that is serving <literal>example.org</literal>, while the rest stays on <literal>myhostname.example.org</literal> with no other changes required. This pattern also allows to seamlessly move the homeserver from <literal>myhostname.example.org</literal> to <literal>myotherhost.example.org</literal> by only changing the <code>/.well-known</code> redirection target.
+   If the <code>A</code> and <code>AAAA</code> DNS records on
+   <literal>example.org</literal> do not point on the same host as the records
+   for <code>myhostname.example.org</code>, you can easily move the
+   <code>/.well-known</code> virtualHost section of the code to the host that
+   is serving <literal>example.org</literal>, while the rest stays on
+   <literal>myhostname.example.org</literal> with no other changes required.
+   This pattern also allows to seamlessly move the homeserver from
+   <literal>myhostname.example.org</literal> to
+   <literal>myotherhost.example.org</literal> by only changing the
+   <code>/.well-known</code> redirection target.
   </para>
 
   <para>
-   If you want to run a server with public registration by anybody, you can then enable <option>services.matrix-synapse.enable_registration = true;</option>. Otherwise, or you can generate a registration secret with <command>pwgen -s 64 1</command> and set it with <option>services.matrix-synapse.registration_shared_secret</option>. To create a new user or admin, run the following after you have set the secret and have rebuilt NixOS:
+   If you want to run a server with public registration by anybody, you can
+   then enable <option>services.matrix-synapse.enable_registration =
+   true;</option>. Otherwise, or you can generate a registration secret with
+   <command>pwgen -s 64 1</command> and set it with
+   <option>services.matrix-synapse.registration_shared_secret</option>. To
+   create a new user or admin, run the following after you have set the secret
+   and have rebuilt NixOS:
 <screen>
 <prompt>$ </prompt>nix run nixpkgs.matrix-synapse
 <prompt>$ </prompt>register_new_matrix_user -k <replaceable>your-registration-shared-secret</replaceable> http://localhost:8008
@@ -118,14 +150,32 @@ in {
 <prompt>Make admin [no]:</prompt>
 Success!
 </screen>
-   In the example, this would create a user with the Matrix Identifier <literal>@your-username:example.org</literal>. Note that the registration secret ends up in the nix store and therefore is world-readable by any user on your machine, so it makes sense to only temporarily activate the <option>registration_shared_secret</option> option until a better solution for NixOS is in place.
+   In the example, this would create a user with the Matrix Identifier
+   <literal>@your-username:example.org</literal>. Note that the registration
+   secret ends up in the nix store and therefore is world-readable by any user
+   on your machine, so it makes sense to only temporarily activate the
+   <option>registration_shared_secret</option> option until a better solution
+   for NixOS is in place.
   </para>
  </section>
  <section xml:id="module-services-matrix-riot-web">
   <title>Riot Web Client</title>
 
   <para>
-   <link xlink:href="https://github.com/vector-im/riot-web/">Riot Web</link> is the reference web client for Matrix and developed by the core team at matrix.org. The following snippet can be optionally added to the code before to complete the synapse installation with a web client served at <code>https://riot.myhostname.example.org</code> and <code>https://riot.example.org</code>. Alternatively, you can use the hosted copy at <link xlink:href="https://riot.im/app">https://riot.im/app</link>, or use other web clients or native client applications. Due to the <literal>/.well-known</literal> urls set up done above, many clients should fill in the required connection details automatically when you enter your Matrix Identifier. See <link xlink:href="https://matrix.org/docs/projects/try-matrix-now.html">Try Matrix Now!</link> for a list of existing clients and their supported featureset.
+   <link xlink:href="https://github.com/vector-im/riot-web/">Riot Web</link> is
+   the reference web client for Matrix and developed by the core team at
+   matrix.org. The following snippet can be optionally added to the code before
+   to complete the synapse installation with a web client served at
+   <code>https://riot.myhostname.example.org</code> and
+   <code>https://riot.example.org</code>. Alternatively, you can use the hosted
+   copy at <link xlink:href="https://riot.im/app">https://riot.im/app</link>,
+   or use other web clients or native client applications. Due to the
+   <literal>/.well-known</literal> urls set up done above, many clients should
+   fill in the required connection details automatically when you enter your
+   Matrix Identifier. See
+   <link xlink:href="https://matrix.org/docs/projects/try-matrix-now.html">Try
+   Matrix Now!</link> for a list of existing clients and their supported
+   featureset.
 <programlisting>
 services.nginx.virtualHosts."riot.${fqdn}" = {
   enableACME = true;
@@ -140,7 +190,14 @@ services.nginx.virtualHosts."riot.${fqdn}" = {
   </para>
 
   <para>
-   Note that the Riot developers do not recommend running Riot and your Matrix homeserver on the same fully-qualified domain name for security reasons. In the example, this means that you should not reuse the <literal>myhostname.example.org</literal> virtualHost to also serve Riot, but instead serve it on a different subdomain, like <literal>riot.example.org</literal> in the example. See the <link xlink:href="https://github.com/vector-im/riot-web#important-security-note">Riot Important Security Notes</link> for more information on this subject.
+   Note that the Riot developers do not recommend running Riot and your Matrix
+   homeserver on the same fully-qualified domain name for security reasons. In
+   the example, this means that you should not reuse the
+   <literal>myhostname.example.org</literal> virtualHost to also serve Riot,
+   but instead serve it on a different subdomain, like
+   <literal>riot.example.org</literal> in the example. See the
+   <link xlink:href="https://github.com/vector-im/riot-web#important-security-note">Riot
+   Important Security Notes</link> for more information on this subject.
   </para>
  </section>
 </chapter>