diff --git a/pills/01-why-you-should-give-it-try.xml b/pills/01-why-you-should-give-it-try.xml
index 0e9e91c..c0da93b 100644
--- a/pills/01-why-you-should-give-it-try.xml
+++ b/pills/01-why-you-should-give-it-try.xml
@@ -33,7 +33,6 @@
       The <link xlink:href="https://nixos.org/nix/manual/">Nix</link>,
       <link xlink:href="https://nixos.org/nixpkgs/manual/">Nixpkgs</link>, and
       <link xlink:href="https://nixos.org/nixos/manual/">NixOS</link> manuals;
-      <link xlink:href="http://www.infoq.com/articles/configuration-management-with-nix">articles</link>;
       and wiki are excellent resources for explaining how Nix/NixOS works, how
       you can use it, and the number of cool things being done with it.
       However, at the beginning you may feel that some of the magic
@@ -60,7 +59,7 @@
        xlink:href="http://www.rpm.org/">rpm</link>, ...) mutate the
        global state of the system. If a package
        <literal>foo-1.0</literal> installs a program to
-       <literal>/usr/bin/foo</literal>, you cannot install
+       <filename>/usr/bin/foo</filename>, you cannot install
        <literal>foo-1.1</literal> as well, unless you change the
        installation paths or the binary name.
        But changing the binary names means breaking users of
@@ -126,25 +125,25 @@
        Nix makes no assumptions about the global state of the system.
        This has many advantages, but also some drawbacks of course.
        The core of a Nix system is the Nix store, usually
-       installed under <literal>/nix/store</literal>, and some tools to manipulate the
+       installed under <filename>/nix/store</filename>, and some tools to manipulate the
        store. In Nix there is the notion of a <emphasis>derivation</emphasis> rather than a
        package. The difference can be subtle at the beginning, so I
        will often use the words interchangeably.
      </para>
      <para>
        Derivations/packages are stored in the Nix store as follows:
-       <literal>/nix/store/<replaceable>hash-name</replaceable></literal>,
+       <filename>/nix/store/<replaceable>hash-name</replaceable></filename>,
        where the hash uniquely identifies the derivation (this isn't quite true,
        it's a little more complex), and the name is the name of
        the derivation.
      </para>
      <para>
        Let's take a bash derivation as an example:
-       <literal>/nix/store/s4zia7hhqkin1di0f187b79sa2srhv6k-bash-4.2-p45/</literal>.
-       This picks out a directory that contains <literal>bin/bash</literal>.
+       <filename>/nix/store/s4zia7hhqkin1di0f187b79sa2srhv6k-bash-4.2-p45/</filename>.
+       This is a directory in the Nix store which contains <filename>bin/bash</filename>.
      </para>
      <para>
-       What that means is that there's no <literal>/bin/bash</literal>, there's only that
+       What that means is that there's no <filename>/bin/bash</filename>, there's only that
        self-contained build output in the store. The same goes for
        coreutils and everything else. To make them convenient
        to use from the shell, Nix will arrange for binaries to appear in
@@ -197,7 +196,7 @@
        When upgrading a library, most package managers replace it in-place.
        All new applications run afterwards with the new library
        without being recompiled. After all, they all refer dynamically
-       to <literal>libc6.so</literal>.
+       to <filename>libc6.so</filename>.
      </para>
      <para>
        Since Nix derivations are immutable, upgrading a library like glibc