NixOS/nix-pills
NixOS/nix-pills
1
0
Fork 0
mirror of https://github.com/NixOS/nix-pills synced 2024-09-19 04:00:13 -04:00
Code Activity

Nix pill 1: address feedback

Browse source
This commit is contained in:
Michael Peyton Jones 2017-11-18 11:32:07 +00:00
parent 81bd79d369
commit 4d0c1d27a5
1 changed files with 7 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
pills/01-why-you-should-give-it-try.xml
View file

@ -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