guix.texi

@code{--ad-hoc} flag is positional.  Packages appearing before
@code{--ad-hoc} are interpreted as packages whose dependencies will be
added to the environment.  Packages appearing after are interpreted as
packages that will be added to the environment directly.  For example,
the following command creates a Guix development environment that
additionally includes Git and strace:

@example
guix environment guix --ad-hoc git strace
@end example

Sometimes it is desirable to isolate the environment as much as
possible, for maximal purity and reproducibility.  In particular, when
using Guix on a host distro that is not GuixSD, it is desirable to
prevent access to @file{/usr/bin} and other system-wide resources from
the development environment.  For example, the following command spawns
a Guile REPL in a ``container'' where only the store and the current
working directory are mounted:

@example
guix environment --ad-hoc --container guile -- guile
@end example

@quotation Note
The @code{--container} option requires Linux-libre 3.19 or newer.
@end quotation

The available options are summarized below.

@table @code
@item --expression=@var{expr}
@itemx -e @var{expr}
Create an environment for the package or list of packages that
@var{expr} evaluates to.

For example, running:

@example
guix environment -e '(@@ (gnu packages maths) petsc-openmpi)'
@end example

starts a shell with the environment for this specific variant of the
PETSc package.

Running:

@example
guix environment --ad-hoc -e '(@@ (gnu) %base-packages)'
@end example

starts a shell with all the GuixSD base packages available.

@item --load=@var{file}
@itemx -l @var{file}
Create an environment for the package or list of packages that the code
within @var{file} evaluates to.

As an example, @var{file} might contain a definition like this
(@pxref{Defining Packages}):

@example
@verbatiminclude environment-gdb.scm
@end example

@item --ad-hoc
Include all specified packages in the resulting environment, as if an
@i{ad hoc} package were defined with them as inputs.  This option is
useful for quickly creating an environment without having to write a
package expression to contain the desired inputs.

For instance, the command:

@example
guix environment --ad-hoc guile guile-sdl -- guile
@end example

runs @command{guile} in an environment where Guile and Guile-SDL are
available.

Note that this example implicitly asks for the default output of
@code{guile} and @code{guile-sdl} but it is possible to ask for a
specific output---e.g., @code{glib:bin} asks for the @code{bin} output
of @code{glib} (@pxref{Packages with Multiple Outputs}).

This option may be composed with the default behavior of @command{guix
environment}.  Packages appearing before @code{--ad-hoc} are interpreted
as packages whose dependencies will be added to the environment, the
default behavior.  Packages appearing after are interpreted as packages
that will be added to the environment directly.

@item --pure
Unset existing environment variables when building the new environment.
This has the effect of creating an environment in which search paths
only contain package inputs.

@item --search-paths
Display the environment variable definitions that make up the
environment.

@item --system=@var{system}
@itemx -s @var{system}
Attempt to build for @var{system}---e.g., @code{i686-linux}.

@item --container
@itemx -C
@cindex container
Run @var{command} within an isolated container.  The current working
directory outside the container is mapped inside the
container.  Additionally, the spawned process runs as the current user
outside the container, but has root privileges in the context of the
container.

@item --network
@itemx -N
For containers, share the network namespace with the host system.
Containers created without this flag only have access to the loopback
device.

@item --expose=@var{source}[=@var{target}]
For containers, expose the file system @var{source} from the host system
as the read-only file system @var{target} within the container.  If
@var{target} is not specified, @var{source} is used as the target mount
point in the container.

The example below spawns a Guile REPL in a container in which the user's
home directory is accessible read-only via the @file{/exchange}
directory:

@example
guix environment --container --expose=$HOME=/exchange guile -- guile
@end example

@item --share=@var{source}[=@var{target}]
For containers, share the file system @var{source} from the host system
as the writable file system @var{target} within the container.  If
@var{target} is not specified, @var{source} is used as the target mount
point in the container.

The example below spawns a Guile REPL in a container in which the user's
home directory is accessible for both reading and writing via the
@file{/exchange} directory:

@example
guix environment --container --share=$HOME=/exchange guile -- guile
@end example
@end table

It also supports all of the common build options that @command{guix
build} supports (@pxref{Common Build Options}).

@node Invoking guix publish
@section Invoking @command{guix publish}

The purpose of @command{guix publish} is to enable users to easily share
their store with others, which can then use it as a substitute server
(@pxref{Substitutes}).

When @command{guix publish} runs, it spawns an HTTP server which allows
anyone with network access to obtain substitutes from it.  This means
that any machine running Guix can also act as if it were a build farm,
since the HTTP interface is compatible with Hydra, the software behind
the @code{hydra.gnu.org} build farm.

For security, each substitute is signed, allowing recipients to check
their authenticity and integrity (@pxref{Substitutes}).  Because
@command{guix publish} uses the system's signing key, which is only
readable by the system administrator, it must be started as root; the
@code{--user} option makes it drop root privileges early on.

The signing key pair must be generated before @command{guix publish} is
launched, using @command{guix archive --generate-key} (@pxref{Invoking
guix archive}).

The general syntax is:

@example
guix publish @var{options}@dots{}
@end example

Running @command{guix publish} without any additional arguments will
spawn an HTTP server on port 8080:

@example
guix publish
@end example

Once a publishing server has been authorized (@pxref{Invoking guix
archive}), the daemon may download substitutes from it:

@example
guix-daemon --substitute-urls=http://example.org:8080
@end example

The following options are available:

@table @code
@item --port=@var{port}
@itemx -p @var{port}
Listen for HTTP requests on @var{port}.

@item --listen=@var{host}
Listen on the network interface for @var{host}.  The default is to
accept connections from any interface.

@item --user=@var{user}
@itemx -u @var{user}
Change privileges to @var{user} as soon as possible---i.e., once the
server socket is open and the signing key has been read.

@item --repl[=@var{port}]
@itemx -r [@var{port}]
Spawn a Guile REPL server (@pxref{REPL Servers,,, guile, GNU Guile
Reference Manual}) on @var{port} (37146 by default).  This is used
primarily for debugging a running @command{guix publish} server.
@end table

Enabling @command{guix publish} on a GuixSD system is a one-liner: just
add a call to @code{guix-publish-service} in the @code{services} field
of the @code{operating-system} declaration (@pxref{guix-publish-service,
@code{guix-publish-service}}).


@node Invoking guix challenge
@section Invoking @command{guix challenge}

@cindex reproducible builds
@cindex verifiable builds

Do the binaries provided by this server really correspond to the source
code it claims to build?  Is this package's build process deterministic?
These are the questions the @command{guix challenge} command attempts to
answer.

The former is obviously an important question: Before using a substitute
server (@pxref{Substitutes}), you'd rather @emph{verify} that it
provides the right binaries, and thus @emph{challenge} it.  The latter
is what enables the former: If package builds are deterministic, then
independent builds of the package should yield the exact same result,
bit for bit; if a server provides a binary different from the one
obtained locally, it may be either corrupt or malicious.

We know that the hash that shows up in @file{/gnu/store} file names is
the hash of all the inputs of the process that built the file or
directory---compilers, libraries, build scripts,
etc. (@pxref{Introduction}).  Assuming deterministic build processes,
one store file name should map to exactly one build output.
@command{guix challenge} checks whether there is, indeed, a single
mapping by comparing the build outputs of several independent builds of
any given store item.

The command's output looks like this:

@smallexample
$ guix challenge --substitute-urls="http://hydra.gnu.org http://guix.example.org"
updating list of substitutes from 'http://hydra.gnu.org'... 100.0%
updating list of substitutes from 'http://guix.example.org'... 100.0%
/gnu/store/@dots{}-openssl-1.0.2d contents differ:
  local hash: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
  http://hydra.gnu.org/nar/@dots{}-openssl-1.0.2d: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
  http://guix.example.org/nar/@dots{}-openssl-1.0.2d: 1zy4fmaaqcnjrzzajkdn3f5gmjk754b43qkq47llbyak9z0qjyim
/gnu/store/@dots{}-git-2.5.0 contents differ:
  local hash: 00p3bmryhjxrhpn2gxs2fy0a15lnip05l97205pgbk5ra395hyha
  http://hydra.gnu.org/nar/@dots{}-git-2.5.0: 069nb85bv4d4a6slrwjdy8v1cn4cwspm3kdbmyb81d6zckj3nq9f
  http://guix.example.org/nar/@dots{}-git-2.5.0: 0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73
/gnu/store/@dots{}-pius-2.1.1 contents differ:
  local hash: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
  http://hydra.gnu.org/nar/@dots{}-pius-2.1.1: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
  http://guix.example.org/nar/@dots{}-pius-2.1.1: 1cy25x1a4fzq5rk0pmvc8xhwyffnqz95h2bpvqsz2mpvlbccy0gs
@end smallexample

@noindent
In this example, @command{guix challenge} first scans the store to
determine the set of locally-built derivations---as opposed to store
items that were downloaded from a substitute server---and then queries
all the substitute servers.  It then reports those store items for which
the servers obtained a result different from the local build.

@cindex non-determinism, in package builds
As an example, @code{guix.example.org} always gets a different answer.
Conversely, @code{hydra.gnu.org} agrees with local builds, except in the
case of Git.  This might indicate that the build process of Git is
non-deterministic, meaning that its output varies as a function of
various things that Guix does not fully control, in spite of building
packages in isolated environments (@pxref{Features}).  Most common
sources of non-determinism include the addition of timestamps in build
results, the inclusion of random numbers, and directory listings sorted
by inode number.  See @uref{http://reproducible.debian.net/howto/}, for
more information.

To find out what's wrong with this Git binary, we can do something along
these lines (@pxref{Invoking guix archive}):

@example
$ wget -q -O - http://hydra.gnu.org/nar/@dots{}-git-2.5.0 \
   | guix archive -x /tmp/git
$ diff -ur --no-dereference /gnu/store/@dots{}-git.2.5.0 /tmp/git
@end example

This command shows the difference between the files resulting from the
local build, and the files resulting from the build on
@code{hydra.gnu.org} (@pxref{Overview, Comparing and Merging Files,,
diffutils, Comparing and Merging Files}).  The @command{diff} command
works great for text files.  When binary files differ, a better option
is @uref{http://diffoscope.org/, Diffoscope}, a tool that helps
visualize differences for all kinds of files.

Once you've done that work, you can tell whether the differences are due
to a non-deterministic build process or to a malicious server.  We try
hard to remove sources of non-determinism in packages to make it easier
to verify substitutes, but of course, this is a process, one that
involves not just Guix but a large part of the free software community.
In the meantime, @command{guix challenge} is one tool to help address
the problem.

If you are writing packages for Guix, you are encouraged to check
whether @code{hydra.gnu.org} and other substitute servers obtain the
same build result as you did with:

@example
$ guix challenge @var{package}
@end example

@noindent
... where @var{package} is a package specification such as
@code{guile-2.0} or @code{glibc:debug}.

The general syntax is:

@example
guix challenge @var{options} [@var{packages}@dots{}]
@end example

The one option that matters is:

@table @code

@item --substitute-urls=@var{urls}
Consider @var{urls} the whitespace-separated list of substitute source
URLs to compare to.

@end table


@node Invoking guix container
@section Invoking @command{guix container}
@cindex container

@quotation Note
As of version @value{VERSION}, this tool is experimental.  The interface
is subject to radical change in the future.
@end quotation

The purpose of @command{guix container} is to manipulate processes
running within an isolated environment, commonly known as a
``container'', typically created by the @command{guix environment}
(@pxref{Invoking guix environment}) and @command{guix system container}
(@pxref{Invoking guix system}) commands.

The general syntax is:

@example
guix container @var{action} @var{options}@dots{}
@end example

@var{action} specifies the operation to perform with a container, and
@var{options} specifies the context-specific arguments for the action.

The following actions are available:

@table @code
@item exec
Execute a command within the context of a running container.

The syntax is:

@example
guix container exec @var{pid} @var{program} @var{arguments}@dots{}
@end example

@var{pid} specifies the process ID of the running container.
@var{program} specifies an executable file name within the container's
root file system.  @var{arguments} are the additional options that will
be passed to @var{program}.

The following command launches an interactive login shell inside a
GuixSD container, started by @command{guix system container}, and whose
process ID is 9001:

@example
guix container exec 9001 /run/current-system/profile/bin/bash --login
@end example

Note that the @var{pid} cannot be the parent process of a container.  It
must be the container's PID 1 or one of its child processes.

@end table

@c *********************************************************************
@node GNU Distribution
@chapter GNU Distribution

@cindex Guix System Distribution
@cindex GuixSD
Guix comes with a distribution of the GNU system consisting entirely of
free software@footnote{The term ``free'' here refers to the
@url{http://www.gnu.org/philosophy/free-sw.html,freedom provided to
users of that software}.}.  The
distribution can be installed on its own (@pxref{System Installation}),
but it is also possible to install Guix as a package manager on top of
an installed GNU/Linux system (@pxref{Installation}).  To distinguish
between the two, we refer to the standalone distribution as the Guix
System Distribution, or GuixSD.

The distribution provides core GNU packages such as GNU libc, GCC, and
Binutils, as well as many GNU and non-GNU applications.  The complete
list of available packages can be browsed
@url{http://www.gnu.org/software/guix/packages,on-line} or by
running @command{guix package} (@pxref{Invoking guix package}):

@example
guix package --list-available
@end example

Our goal has been to provide a practical 100% free software distribution of
Linux-based and other variants of GNU, with a focus on the promotion and
tight integration of GNU components, and an emphasis on programs and
tools that help users exert that freedom.

Packages are currently available on the following platforms:

@table @code

@item x86_64-linux
Intel/AMD @code{x86_64} architecture, Linux-Libre kernel;

@item i686-linux
Intel 32-bit architecture (IA32), Linux-Libre kernel;

@item armhf-linux
ARMv7-A architecture with hard float, Thumb-2 and NEON,
using the EABI hard-float ABI, and Linux-Libre kernel.

@item mips64el-linux
little-endian 64-bit MIPS processors, specifically the Loongson series,
n32 application binary interface (ABI), and Linux-Libre kernel.

@end table

GuixSD itself is currently only available on @code{i686} and @code{x86_64}.

@noindent
For information on porting to other architectures or kernels,
@xref{Porting}.

@menu
* System Installation::         Installing the whole operating system.
* System Configuration::        Configuring the operating system.
* Installing Debugging Files::  Feeding the debugger.
* Security Updates::            Deploying security fixes quickly.
* Package Modules::             Packages from the programmer's viewpoint.
* Packaging Guidelines::        Growing the distribution.
* Bootstrapping::               GNU/Linux built from scratch.
* Porting::                     Targeting another platform or kernel.
@end menu

Building this distribution is a cooperative effort, and you are invited
to join!  @xref{Contributing}, for information about how you can help.

@node System Installation
@section System Installation

@cindex Guix System Distribution
This section explains how to install the Guix System Distribution
on a machine.  The Guix package manager can
also be installed on top of a running GNU/Linux system,
@pxref{Installation}.

@ifinfo
@c This paragraph is for people reading this from tty2 of the
@c installation image.
You're reading this documentation with an Info reader.  For details on
how to use it, hit the @key{RET} key (``return'' or ``enter'') on the
link that follows: @pxref{Help,,, info, Info: An Introduction}.  Hit
@kbd{l} afterwards to come back here.
@end ifinfo

@subsection Limitations

As of version @value{VERSION}, the Guix System Distribution (GuixSD) is
not production-ready.  It may contain bugs and lack important
features.  Thus, if you are looking for a stable production system that
respects your freedom as a computer user, a good solution at this point
is to consider @url{http://www.gnu.org/distros/free-distros.html, one of
more established GNU/Linux distributions}.  We hope you can soon switch
to the GuixSD without fear, of course.  In the meantime, you can
also keep using your distribution and try out the package manager on top
of it (@pxref{Installation}).

Before you proceed with the installation, be aware of the following
noteworthy limitations applicable to version @value{VERSION}:

@itemize
@item
The installation process does not include a graphical user interface and
requires familiarity with GNU/Linux (see the following subsections to
get a feel of what that means.)

@item
The system does not yet provide full GNOME and KDE desktops.  Xfce and
Enlightenment are available though, if graphical desktop environments
are your thing, as well as a number of X11 window managers.

@item
Support for the Logical Volume Manager (LVM) is missing.

@item
Few system services are currently supported out-of-the-box
(@pxref{Services}).

@item
More than 2,000 packages are available, but you may
occasionally find that a useful package is missing.
@end itemize

You've been warned.  But more than a disclaimer, this is an invitation
to report issues (and success stories!), and join us in improving it.
@xref{Contributing}, for more info.

@subsection USB Stick Installation

An installation image for USB sticks can be downloaded from
@indicateurl{ftp://alpha.gnu.org/gnu/guix/guixsd-usb-install-@value{VERSION}.@var{system}.xz},
where @var{system} is one of:

@table @code
@item x86_64-linux
for a GNU/Linux system on Intel/AMD-compatible 64-bit CPUs;

@item i686-linux
for a 32-bit GNU/Linux system on Intel-compatible CPUs.
@end table

This image contains a single partition with the tools necessary for an
installation.  It is meant to be copied @emph{as is} to a large-enough
USB stick.

To copy the image to a USB stick, follow these steps:

@enumerate
@item
Decompress the image using the @command{xz} command:

@example
xz -d guixsd-usb-install-@value{VERSION}.@var{system}.xz
@end example

@item
Insert a USB stick of 1@tie{}GiB or more in your machine, and determine
its device name.  Assuming that USB stick is known as @file{/dev/sdX},
copy the image with:

@example
dd if=guixsd-usb-install-@value{VERSION}.x86_64 of=/dev/sdX
@end example

Access to @file{/dev/sdX} usually requires root privileges.
@end enumerate

Once this is done, you should be able to reboot the system and boot from
the USB stick.  The latter usually requires you to get in the BIOS' boot
menu, where you can choose to boot from the USB stick.

@subsection Preparing for Installation

Once you have successfully booted the image on the USB stick, you should
end up with a root prompt.  Several console TTYs are configured and can
be used to run commands as root.  TTY2 shows this documentation,
browsable using the Info reader commands (@pxref{Help,,, info, Info: An
Introduction}).  The installation system runs the GPM mouse daemon,
which allows you to select text with the left mouse button and to paste
it with the middle button.

To install the system, you would:

@enumerate

@item
Configure the network, by running:

@example
ifconfig eno1 up && dhclient eno1
@end example

to get an automatically assigned IP address from the wired
network interface controller@footnote{
@c http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20
The name @code{eno1} is for the first on-board Ethernet controller.  The
interface name for an Ethernet controller that is in the first slot of
the first PCI bus, for instance, would be @code{enp1s0}.  Use
@command{ifconfig -a} to list all the available network interfaces.},
or using the @command{ifconfig} command.

The system automatically loads drivers for your network interface
controllers.

Setting up network access is almost always a requirement because the
image does not contain all the software and tools that may be needed.

@item
Unless this has already been done, you must partition, and then format
the target partition.

Preferably, assign partitions a label so that you can easily and
reliably refer to them in @code{file-system} declarations (@pxref{File
Systems}).  This is typically done using the @code{-L} option of
@command{mkfs.ext4} and related commands.

Be sure that your partition labels match the value of their respective
@code{device} fields in your @code{file-system} configuration, if your
@code{file-system} configuration sets the value of @code{title} to
@code{'label}, as do the example configurations found on the USB
installation image under @file{/etc/configuration} (@pxref{Using the
Configuration System}).

@c FIXME: Uncomment this once GRUB fully supports encrypted roots.
@c A typical command sequence may be:
@c
@c @example
@c # fdisk /dev/sdX
@c @dots{} Create partitions etc.@dots{}
@c # cryptsetup luksFormat /dev/sdX1
@c # cryptsetup open --type luks /dev/sdX1 my-partition
@c # mkfs.ext4 -L my-root /dev/mapper/my-partition
@c @end example

The installation image includes Parted (@pxref{Overview,,, parted, GNU
Parted User Manual}), @command{fdisk}, Cryptsetup/LUKS for disk
encryption, and e2fsprogs, the suite of tools to manipulate
ext2/ext3/ext4 file systems.

@item
Once that is done, mount the target root partition under @file{/mnt}.

@item
Lastly, run @code{herd start cow-store /mnt}.

This will make @file{/gnu/store} copy-on-write, such that packages added
to it during the installation phase will be written to the target disk
rather than kept in memory.

@end enumerate


@subsection Proceeding with the Installation

With the target partitions ready, you now have to edit a file and
provide the declaration of the operating system to be installed.  To
that end, the installation system comes with two text editors: GNU nano
(@pxref{Top,,, nano, GNU nano Manual}), and GNU Zile, an Emacs clone.
It is better to store that file on the target root file system, say, as
@file{/mnt/etc/config.scm}.

@xref{Using the Configuration System}, for examples of operating system
configurations.  These examples are available under
@file{/etc/configuration} in the installation image, so you can copy
them and use them as a starting point for your own configuration.

Once you are done preparing the configuration file, the new system must
be initialized (remember that the target root file system is mounted
under @file{/mnt}):

@example
guix system init /mnt/etc/config.scm /mnt
@end example

@noindent
This will copy all the necessary files, and install GRUB on
@file{/dev/sdX}, unless you pass the @option{--no-grub} option.  For
more information, @pxref{Invoking guix system}.  This command may trigger
downloads or builds of missing packages, which can take some time.

Once that command has completed---and hopefully succeeded!---you can run
@command{reboot} and boot into the new system.  The @code{root} password
in the new system is initially empty; other users' passwords need to be
initialized by running the @command{passwd} command as @code{root},
unless your configuration specifies otherwise
(@pxref{user-account-password, user account passwords}).

Join us on @code{#guix} on the Freenode IRC network or on
@file{guix-devel@@gnu.org} to share your experience---good or not so
good.

@subsection Building the Installation Image

The installation image described above was built using the @command{guix
system} command, specifically:

@example
guix system disk-image --image-size=850MiB gnu/system/install.scm
@end example

@xref{Invoking guix system}, for more information.  See
@file{gnu/system/install.scm} in the source tree for more information
about the installation image.

@node System Configuration
@section System Configuration

@cindex system configuration
The Guix System Distribution supports a consistent whole-system configuration
mechanism.  By that we mean that all aspects of the global system
configuration---such as the available system services, timezone and
locale settings, user accounts---are declared in a single place.  Such
a @dfn{system configuration} can be @dfn{instantiated}---i.e., effected.

One of the advantages of putting all the system configuration under the
control of Guix is that it supports transactional system upgrades, and
makes it possible to roll-back to a previous system instantiation,
should something go wrong with the new one (@pxref{Features}).  Another
one is that it makes it easy to replicate the exact same configuration
across different machines, or at different points in time, without
having to resort to additional administration tools layered on top of
the system's own tools.
@c Yes, we're talking of Puppet, Chef, & co. here.  ↑

This section describes this mechanism.  First we focus on the system
administrator's viewpoint---explaining how the system is configured and
instantiated.  Then we show how this mechanism can be extended, for
instance to support new system services.

@menu
* Using the Configuration System::  Customizing your GNU system.
* operating-system Reference::  Detail of operating-system declarations.
* File Systems::                Configuring file system mounts.
* Mapped Devices::              Block device extra processing.
* User Accounts::               Specifying user accounts.
* Locales::                     Language and cultural convention settings.
* Services::                    Specifying system services.
* Setuid Programs::             Programs running with root privileges.
* X.509 Certificates::          Authenticating HTTPS servers.
* Name Service Switch::         Configuring libc's name service switch.
* Initial RAM Disk::            Linux-Libre bootstrapping.
* GRUB Configuration::          Configuring the boot loader.
* Invoking guix system::        Instantiating a system configuration.
* Running GuixSD in a VM::      How to run GuixSD in a virtual machine.
* Defining Services::           Adding new service definitions.
@end menu

@node Using the Configuration System
@subsection Using the Configuration System

The operating system is configured by providing an
@code{operating-system} declaration in a file that can then be passed to
the @command{guix system} command (@pxref{Invoking guix system}).  A
simple setup, with the default system services, the default Linux-Libre
kernel, initial RAM disk, and boot loader looks like this:

@findex operating-system
@lisp
@include os-config-bare-bones.texi
@end lisp

This example should be self-describing.  Some of the fields defined
above, such as @code{host-name} and @code{bootloader}, are mandatory.
Others, such as @code{packages} and @code{services}, can be omitted, in
which case they get a default value.

Below we discuss the effect of some of the most important fields
(@pxref{operating-system Reference}, for details about all the available
fields), and how to @dfn{instantiate} the operating system using
@command{guix system}.

@unnumberedsubsubsec Globally-Visible Packages

@vindex %base-packages
The @code{packages} field lists packages that will be globally visible
on the system, for all user accounts---i.e., in every user's @code{PATH}
environment variable---in addition to the per-user profiles
(@pxref{Invoking guix package}).  The @var{%base-packages} variable
provides all the tools one would expect for basic user and administrator
tasks---including the GNU Core Utilities, the GNU Networking Utilities,
the GNU Zile lightweight text editor, @command{find}, @command{grep},
etc.  The example above adds tcpdump to those, taken from the @code{(gnu
packages admin)} module (@pxref{Package Modules}).

@findex specification->package
Referring to packages by variable name, like @var{tcpdump} above, has
the advantage of being unambiguous; it also allows typos and such to be
diagnosed right away as ``unbound variables''.  The downside is that one
needs to know which module defines which package, and to augment the
@code{use-package-modules} line accordingly.  To avoid that, one can use
the @code{specification->package} procedure of the @code{(gnu packages)}
module, which returns the best package for a given name or name and
version:

@lisp
(use-modules (gnu packages))

(operating-system
  ;; ...
  (packages (append (map specification->package
                         '("tcpdump" "htop" "gnupg-2.0"))
                    %base-packages)))
@end lisp

@unnumberedsubsubsec System Services

@vindex %base-services
The @code{services} field lists @dfn{system services} to be made
available when the system starts (@pxref{Services}).
The @code{operating-system} declaration above specifies that, in
addition to the basic services, we want the @command{lshd} secure shell
daemon listening on port 2222 (@pxref{Networking Services,
@code{lsh-service}}).  Under the hood,
@code{lsh-service} arranges so that @code{lshd} is started with the
right command-line options, possibly with supporting configuration files
generated as needed (@pxref{Defining Services}).

@cindex customization, of services
@findex modify-services
Occasionally, instead of using the base services as is, you will want to
customize them.  For instance, to change the configuration of
@code{guix-daemon} and Mingetty (the console log-in), you may write the
following instead of @var{%base-services}:

@lisp
(modify-services %base-services
  (guix-service-type config =>
                     (guix-configuration
                      (inherit config)
                      (use-substitutes? #f)
                      (extra-options '("--gc-keep-outputs"))))
  (mingetty-service-type config =>
                         (mingetty-configuration
                          (inherit config)
                          (motd (plain-file "motd" "Hi there!")))))
@end lisp

@noindent
The effect here is to change the options passed to @command{guix-daemon}
when it is started, as well as the ``message of the day'' that appears
when logging in at the console.  @xref{Service Reference,
@code{modify-services}}, for more on that.

The configuration for a typical ``desktop'' usage, with the X11 display
server, a desktop environment, network management, power management, and
more, would look like this:

@lisp
@include os-config-desktop.texi
@end lisp

@xref{Desktop Services}, for the exact list of services provided by
@var{%desktop-services}.  @xref{X.509 Certificates}, for background
information about the @code{nss-certs} package that is used here.

Again, @var{%desktop-services} is just a list of service objects.  If
you want to remove services from there, you can do so using the
procedures for list filtering (@pxref{SRFI-1 Filtering and
Partitioning,,, guile, GNU Guile Reference Manual}).  For instance, the
following expression returns a list that contains all the services in
@var{%desktop-services} minus the Avahi service:

@example
(remove (lambda (service)
          (eq? (service-kind service) avahi-service-type))
        %desktop-services)
@end example

@unnumberedsubsubsec Instantiating the System

Assuming the @code{operating-system} declaration
is stored in the @file{my-system-config.scm}
file, the @command{guix system reconfigure my-system-config.scm} command
instantiates that configuration, and makes it the default GRUB boot
entry (@pxref{Invoking guix system}).

The normal way to change the system's configuration is by updating this
file and re-running @command{guix system reconfigure}.  One should never
have to touch files in @command{/etc} or to run commands that modify the
system state such as @command{useradd} or @command{grub-install}.  In
fact, you must avoid that since that would not only void your warranty
but also prevent you from rolling back to previous versions of your
system, should you ever need to.

@cindex roll-back, of the operating system
Speaking of roll-back, each time you run @command{guix system
reconfigure}, a new @dfn{generation} of the system is created---without
modifying or deleting previous generations.  Old system generations get
an entry in the GRUB boot menu, allowing you to boot them in case
something went wrong with the latest generation.  Reassuring, no?  The
@command{guix system list-generations} command lists the system
generations available on disk.

@unnumberedsubsubsec The Programming Interface

At the Scheme level, the bulk of an @code{operating-system} declaration
is instantiated with the following monadic procedure (@pxref{The Store
Monad}):

@deffn {Monadic Procedure} operating-system-derivation os
Return a derivation that builds @var{os}, an @code{operating-system}
object (@pxref{Derivations}).

The output of the derivation is a single directory that refers to all
the packages, configuration files, and other supporting files needed to
instantiate @var{os}.
@end deffn

This procedure is provided by the @code{(gnu system)} module.  Along
with @code{(gnu services)} (@pxref{Services}), this module contains the
guts of GuixSD.  Make sure to visit it!


@node operating-system Reference
@subsection @code{operating-system} Reference

This section summarizes all the options available in
@code{operating-system} declarations (@pxref{Using the Configuration
System}).

@deftp {Data Type} operating-system
This is the data type representing an operating system configuration.
By that, we mean all the global system configuration, not per-user
configuration (@pxref{Using the Configuration System}).

@table @asis
@item @code{kernel} (default: @var{linux-libre})
The package object of the operating system kernel to use@footnote{Currently
only the Linux-libre kernel is supported.  In the future, it will be
possible to use the GNU@tie{}Hurd.}.

@item @code{kernel-arguments} (default: @code{'()})
List of strings or gexps representing additional arguments to pass on
the kernel's command-line---e.g., @code{("console=ttyS0")}.

@item @code{bootloader}
The system bootloader configuration object.  @xref{GRUB Configuration}.

@item @code{initrd} (default: @code{base-initrd})
A two-argument monadic procedure that returns an initial RAM disk for
the Linux kernel.  @xref{Initial RAM Disk}.

@item @code{firmware} (default: @var{%base-firmware})
@cindex firmware
List of firmware packages loadable by the operating system kernel.

The default includes firmware needed for Atheros-based WiFi devices
(Linux-libre module @code{ath9k}.)

@item @code{host-name}
The host name.

@item @code{hosts-file}
@cindex hosts file
A file-like object (@pxref{G-Expressions, file-like objects}) for use as
@file{/etc/hosts} (@pxref{Host Names,,, libc, The GNU C Library
Reference Manual}).  The default is a file with entries for
@code{localhost} and @var{host-name}.

@item @code{mapped-devices} (default: @code{'()})
A list of mapped devices.  @xref{Mapped Devices}.

@item @code{file-systems}
A list of file systems.  @xref{File Systems}.

@item @code{swap-devices} (default: @code{'()})
@cindex swap devices
A list of strings identifying devices to be used for ``swap space''
(@pxref{Memory Concepts,,, libc, The GNU C Library Reference Manual}).
For example, @code{'("/dev/sda3")}.

@item @code{users} (default: @code{%base-user-accounts})
@itemx @code{groups} (default: @var{%base-groups})
List of user accounts and groups.  @xref{User Accounts}.

@item @code{skeletons} (default: @code{(default-skeletons)})
A monadic list of pairs of target file name and files.  These are the
files that will be used as skeletons as new accounts are created.

For instance, a valid value may look like this:

@example
(mlet %store-monad ((bashrc (text-file "bashrc" "\
     export PATH=$HOME/.guix-profile/bin")))
  (return `((".bashrc" ,bashrc))))
@end example

@item @code{issue} (default: @var{%default-issue})
A string denoting the contents of the @file{/etc/issue} file, which is
what displayed when users log in on a text console.

@item @code{packages} (default: @var{%base-packages})
The set of packages installed in the global profile, which is accessible
at @file{/run/current-system/profile}.

The default set includes core utilities, but it is good practice to
install non-core utilities in user profiles (@pxref{Invoking guix
package}).