
GNU Guix – The Emacs of Distros [video] - davexunit
http://audio-video.gnu.org/video/misc/2015-01__GNU_Guix__The_Emacs_of_Distros.webm
======
JasonFruit
If it were the Emacs of distros, this wouldn't be a video. Give me text that I
can read. (And get off my lawn.)

~~~
dmix
Here you go:

[https://www.gnu.org/software/guix/manual/guix.html#Introduct...](https://www.gnu.org/software/guix/manual/guix.html#Introduction)

~~~
theophrastus
This useful reference says "GNU Guix1 is a functional package management tool
for the GNU system", so it's _not_ a "Distro" as the title here declares? but
rather, it's an aptitude replacement via guile? It's always nice to get from
protracted video, and odd headline, to: "ok, but what is it? what's its
function?"

~~~
pseudonom-
From the linked page:

> Last but not least, Guix is used to build a distribution of the GNU system,
> with many GNU and non-GNU free software packages. The Guix System
> Distribution, or GNU GSD, takes advantage of the core properties of Guix at
> the system level. With GNU GSD, users declare all aspects of the operating
> system configuration, and Guix takes care of instantiating that
> configuration in a reproducible, stateless fashion. See GNU Distribution[0].

[0]: [https://www.gnu.org/software/guix/manual/guix.html#GNU-
Distr...](https://www.gnu.org/software/guix/manual/guix.html#GNU-Distribution)

------
pseudonom-
How does Guix compare to NixOS? Now that both have been around a little while,
what are the relative merits of Guile and the Nix expression language, in
practice? How big is each community? The Guix package list is much smaller
than the NixOS list?

~~~
davexunit
I'm a Guix core developer, so my answers below will of course be biased
towards Guix.

>what are the relative merits of Guile and the Nix expression language, in
practice?

Nix is a DSL, whereas Guile is a general-purpose programming language. In
practice, I find it better to use a general-purpose language, because you have
access to all of the features of that language and its libraries for free.

>How big is each community?

I don't have any stats, but the Nix community is definitely bigger. Both
communities are very active. The guix-devel mailing list and the #guix IRC
channel are busy places.

[https://lists.gnu.org/archive/html/guix-
devel/2015-02/thread...](https://lists.gnu.org/archive/html/guix-
devel/2015-02/threads.html)

>The Guix package list is much smaller than the NixOS list?

Yes. The Guix package list is rapidly growing, though. Patches for new
packages come in every day. Our last release had 164 new packages.

Hope this helps!

------
Sanddancer
Unfortunately, guix seems to fall into the problem so many source distribution
systems fall into. Looking through the documentation, they make it entirely
too difficult to customize compilation options. For example, FreeBSD's
packaging system has make.conf, which allows one to set environment flags for
the package build system, its ports tree lets you make custom builds of
software for things like additional library support, and generally supports
options that let you make your systems your own.

Guix, while it claims to support repeatable builds, keeps you in the same
restrictive build process as other package managers. It's hard to configure
how your packages are built, hard to maintain your custom options between
updates, and from the scant documentation, and hard to maintain a server for
private packages. Add in its poor capabilities as a package manager, such as
the bizarre requirement to upgrade the distribution to upgrade your package
list, and you just have a poor mess of an operating system.

~~~
davexunit
Seems to me that you've written some harsh things about a project that you
don't understand. I will humor you:

>Guix, while it claims to support repeatable builds, keeps you in the same
restrictive build process as other package managers.

This sentence makes no sense to me. Do you know what "reproducible builds"
means in this context? See:
[https://wiki.debian.org/ReproducibleBuilds/About](https://wiki.debian.org/ReproducibleBuilds/About)

>It's hard to configure how your packages are built

In Guix, packages are Scheme objects, giving you maximum flexibility. You can
easily customize configure/make flags, along with many other things, to make
custom package builds. It's also easy to maintain your own separate package
recipes. Guix makes packaging easy. That said, there are folks that are
interested in a global configuration system, so maybe we'll see that some day.
Guix is alpha software, it doesn't have every bell and whistle that you might
like.

>and hard to maintain a server for private packages

First of all, you don't need a server for any packages. There is no single
point of trust in Guix. You can build every single package on your own
computer. Now, you could run your own Hydra instance like
[https://hydra.gnu.org](https://hydra.gnu.org), and soon you'll be able to run
'guix publish' from any guix machine to spawn a server that exposes a Hydra-
compatible web service for serving binaries.

>Add in its poor capabilities as a package manager

Transactional upgrades, rollbacks, and per-user package installation are poor
capabilities?

>the bizarre requirement to upgrade the distribution to upgrade your package
list

The package recipes ship with Guix, so upgrading Guix via 'guix pull' gets you
the new package recipes, too. This does _not_ upgrade the system, only the
version of Guix for the user who ran 'guix pull'. The "package list" isn't a
package list, it's a collection of Scheme modules.

~~~
Sanddancer
Yes, I know what reproducible builds are. Debian, and FreeBSD have them for
default configurations, and OpenBSD is working towards that direction.
However, FreeBSD and OpenBSD also make it easy for a user to customize their
builds through well-documented commands. The two goals are not mutually
exclusive, but the decisions made by your software make that hard.

Your argument about packages being Scheme objects completely misses the point.
How are the configuration options maintained between versions? With systems
like FreeBSD, the package build configurations are saved elsewhere. This means
that when I do update, my configuration options are saved, without me needing
to patch the build recipe every time a new version's released.

Yes, I know I don't need a package server if I'm just pulling packages other
people wrote, and all that software plays nicely together. There are a lot of
cases, though, that require that different machines have mutually incompatible
configurations. For example, your webservers could all be nginx, except for
the two servers in the corner that are serving up an old mod_perl app. Having
a server that can serve packages and dependency chains for these two cases can
be invaluable. For that, I'm going to need a server that my machines can poll
to figure out what packages are indeed available. From everything you've
stated, guix doesn't have that capability.

Transactional maintenance is definitely interesting, and something I'd love to
see other OSes do. Per-user package installation, on the other hand, is
something a lot of other packaging systems have. NetBSD's pkgsrc, Gentoo's
build system, etc, all support it without any problem. Your system, requires
what should be metadata -- package build instructions -- to be intermingled
with code -- the package manager program. Additionally, its querying
capabilities seem lacking; there doesn't seem, for example, to be any option
to figure out what package installed a particular file. Additionally, there is
no way for a systems administrator to easily audit those packages installed by
users; if a user is running an insecure, out of date program because they
haven't done an update in six months, this could lead to some pretty big
problems.

I know that the package list is a collection of scheme modules. At the same
time, those modules almost certainly are not interwoven into the base guix
system. Additionally, there are many packages, like daemons, suid software,
etc, that will need to be updated by the root user. Furthermore, as
vulnerabilities like heartbleed and shellshock have shown, there are times
when one can't wait for scheduled releases to push patch updates. Intermeshing
the software from the data is just going to lead to problems.

~~~
davexunit
>Your system, requires what should be metadata -- package build instructions
-- to be intermingled with code -- the package manager program.

Package build instructions _are_ code. C Packages builds in Guix are a pure
function of their dependencies and the version of Guix being used, so it makes
perfect sense to ship the package recipes with Guix itself.

>Intermeshing the software from the data is just going to lead to problems.

So far it's lead to a lot of solutions. As Lispers often say, code is data,
and data is code. I think you have a disagreement with this notion, so it's
obvious why you would not like Guix or Nix.

------
SSLy
I've drank the systemd kool-aid. I'd consider Guix, but I want systemd (if
only just for nspawn).

~~~
davexunit
Systemd just doesn't integrate well into our system. The big advantage of
using dmd is that it is also written in Scheme, giving us access to all of the
features and libraries that Guile has. Our initrd is also written in Scheme,
giving us the same advantages.

There is a GSoC proposal out there to add support for some of systemd's file
formats to dmd, for interoperability (and being able to run GNOME, notably).
If any student reads this and wants to hack on an init system this summer,
subscribe to our mailing list or hop on #guix on freenode and let us know.

~~~
digi_owl
>and being able to run GNOME, notably

Should make people stand up and pay attention...

------
zyla666
Looks like Nix rewritten in Guile. We need more fragmentation!

~~~
vertex-four
Specifically, it uses Nix as the underlying system, but implements a new
syntax and maintains a separate package tree written in this new syntax. I'm
not entirely certain why.

~~~
59nadir
It's told very clearly on both the project's website and in the linked video
that they consider the Scheme language to provide a more hackable interface
for package specification and management. It's also demonstrated that it all
integrates very nicely into Emacs.

On top of that it's also stated in the comments here, by a Guix developer,
that while having a DSL for package specification is nice, they think having a
whole general purpose language for it is better.

