
GNU Guix and GuixSD 0.15.0 released - severus_snape
https://www.gnu.org/software/guix/blog/2018/gnu-guix-and-guixsd-0.15.0-released/
======
tombert
I ask this with no passive aggression; what are the advantages of Guix over
Nix? I've used Nix a few times and thought it was pretty neat...

~~~
rekado
Here's something I wrote about this four months ago (with minor corrections).
I hope this helps.

\-------------------

As one of the co-maintainers of GNU Guix I'm obviously biased, but here's what
I consider some important unique features of Guix:

\- Guix is all written in Guile Scheme (with the exception of parts of the
inherited daemon, which hasn't yet been completely implemented in Guile); this
extends to development tools like importers, updaters, to user tools like
"guix environment", and even bleeds into other projects that are used by
GuixSD (the GNU system distribution built around Guix), such as the shepherd
init system. There is a lot of code reuse across the stack, which makes
hacking on Guix really fun and smooth.

\- Packages are first class citizens in Guix. In Nix the idea of functional
package management is very obvious in the way that packages are defined,
namely as functions. These functions take their concrete inputs from an
enormous mapping. In Guix you define first-class package values as Scheme
variables. These package values reference other package values, which leads to
a lazily constructed graph of packages. This emergent graph can be used as a
library to trivially build other tools like "guix graph" (for visualising the
graph in various ways) or "guix web" (for a web interface to installing and
searching packages), "guix refresh" (for updating package definitions), a
lovely feature-rich Emacs interface etc.

\- Embedded DSL. Since Guix is written in Scheme---a language for writing
languages---it was an obvious choice to embed the package DSL in the host
language Scheme instead of implementing a separate language that needs a
custom interpreter. This is great for hacking on Guix, because you can use all
the tools you'd use for Scheme hacking. There's a REPL, great Emacs support, a
debugger, etc. With its support for hygienic macros, Scheme is also a perfect
vehicle to implement features like monads (we use a monadic interface for
talking to the daemon) and to implement other convenient abstractions.

\- Graph rewriting. Having everything defined as regular Scheme values means
that you can almost trivially go through the package graph and rewrite things,
e.g. to replace one variant of a package with a different one. Your software
environment is just a Scheme value and can be inspected or precisely modified
with a simple Scheme API.

\- Code staging. Thanks to different ways of quoting code (plain S-expressions
and package-aware G-expressions), we use Scheme at all stages: on the "host
side" as well as on the "build side". Instead of gluing together shell
snippets to be run by the daemon we work with the AST of Scheme code at all
stages. If you're interested in code staging I recommend reading this paper:
[https://hal.inria.fr/hal-01580582/en](https://hal.inria.fr/hal-01580582/en)

\- Bootstrapping. Some of us are very active in the "bootstrappable builds"
community (see [http://bootstrappable.org](http://bootstrappable.org)) and are
working towards full bootstrap paths for self-hosting compilers and build
systems. One result is a working bootstrap path of the JDK from C (using
jikes, GNU classpath, jamvm, icedtea, etc). In Guix we take bootstrapping
problems serious and prefer to take the longer way to build things fully from
source instead of just adding more binary blobs. This means that we cannot
always package as many things as quickly as others (e.g. Java libraries are
hard to build recursively from source). I'm currently working on bootstrapping
GHC without GHC and without the generated C code, but via interpreting a
variant of GHC with Hugs. Others are working on bootstrapping GCC via Scheme.

\- GuixSD, the GNU system distribution built around Guix. GuixSD has many
features that are very different from NixOS. The declarative configuration in
Scheme includes system facilities, which also form a graph that can be
inspected and extended; this allows for the definition of complex system
facilities that abstract over co-dependent services and service
configurations. GuixSD provides more Scheme APIs that apply to the whole
system, turning your operating system into a Scheme library.

\- I like the UI of Guix a lot more than that of Nix. With Nix 2.0 many
perceived problems with the UI have been addressed, of course, but hey, I
still prefer the Guix way. I also really like the Emacs interface, which is
absolutely gorgeous. (What can I say, I live in Emacs and prefer rich 2D
buffers over 1D command line strings.)

\- It's GNU. I'm a GNU hacker and to me Guix is a representative of a modern
and innovative GNU. It's great to see more GNU projects acting as one within
the context of Guix and GuixSD to provide an experience that is greater than
the sum of its parts. Work on Guix affected other GNU packages such as the
Hurd, Guile, cool Guile libraries, and led to a bunch of new GNU packages such
as a workflow language for scientific computing.

On the other hand, although Guix has a lot of regular contributors and is very
active, Nix currently has more contributors than Guix. Guix is a younger
project. The tendency to take bootstrapping problems very seriously means that
sometimes difficult packages require more work. Oddly, Guix seems to attract
more Lispers than Haskellers (I'm a recovering Haskeller who fell in love with
Scheme after watching the SICP lecture videos); it seems to be the other way
around with Nix.

Having said all that: Nix and Guix are both implementations of functional
package management. Both projects solve similar problems and both are active
in the reproducible builds efforts. Solutions that were found by Nix devs
sometimes make their way into Guix and vice versa. The projects are not
competing with one another (there are orders of magnitudes more people out
there who use neither Guix nor Nix than there are users of functional package
managers, so there's no point in trying to get people who use Nix to switch to
Guix). At our recent Guix fringe event before FOSDEM Eelco Dolstra (who
invented functional package management and Nix) gave a talk on the future of
Nix surrounded by Guix hackers --- there is no rivalry between these two
projects.

~~~
EuAndreh
Great explanation.

Other than daemon implementation and design ideas that migrated from/to
Nix/Guix, is there a way to write a package in Nix and use that derivation in
Guix or vice-versa?

I ask thinking if it would be possible to somehow leverage the work on
packages from on project to the other.

~~~
rekado
I think that derivations are at a level that is too low to be useful for
interoperability. The format for derivations has not changed in Guix (yet?),
but you wouldn't work on derivations directly most of the time. Most of the
fun happens at a much higher level where an abstraction for packages and build
systems exists.

The needs of the two projects have diverged over time and the daemon in Guix
is slowly being rewritten in Scheme (this has been the subject of a GSoC
project and most parts already exist on the Scheme side for other purposes). I
would not count on continued compatibility, nor do I think it is particularly
important simply because the contents of the derivations is different, so that
there would be little difference between running both Nix and Guix on the same
system and feeding Nix derivations to the Guix daemon (if that even works).

------
gkya
I love Guix and GuixSD and would like to move to it as my main OS, but I
dislike that they actively censor information on how to run a custom kernel
and get set up on a machine where some drivers linux-libre removes are
required. I understand that they don't want to distribute those stuff and
that's fine, but not everybody can buy new hardware and especially _any_
hardware easily. This is extremism for me (banning official information, not
the offending drivers), it's distasteful and discourages me.

~~~
rekado
This is not censorship. We just don't want the #guix IRC channel or the
project's mailing lists to recommend ways to use proprietary software. People
are welcome to use non-project channels to discuss proprietary software.

~~~
michaelmrose
So you have scatter information about how to actually make guix useful to a
large number of users who over 13 different platforms that people use and hope
users can use google search to reassemble said info.

This is inefficient and poorly considered. When my family got their first
modern computer in my teens it ran windows. When we bought a better one so I
could explore computer animation it ran windows. My first computer I paid for
dual booted linux/windows. My computers now exclusively run linux.

I switched to free software because it was better ideologically but more
importantly because I can presently use it to accomplish my goals.

Dual booting is surely inferior to just running free software from a software
freedom standpoint but if I couldn't dual boot I might not have bothered at
all.

Making nonfree sofware require an affirmative act beyond apt-install foo is a
good step deleting all info from the official platform is unreasonable.

~~~
mikegerwitz
For more information, see the GNU Coding Standards:

[https://www.gnu.org/prep/standards/standards.html#References](https://www.gnu.org/prep/standards/standards.html#References)

In particular:

> A GNU program should not recommend, promote, or grant legitimacy to the use
> of any non-free program. Proprietary software is a social and ethical
> problem, and our aim is to put an end to that problem. We can’t stop some
> people from writing proprietary programs, or stop other people from using
> them, but we can and should refuse to advertise them to new potential
> customers, or to give the public the idea that their existence is ethical.

Excluding material isn't censorship---GNU stands by its principles. You
wouldn't expect a vegan organization to advertise means of obtaining meat, for
example.

~~~
rekado
I'd like to add that _using_ proprietary software is not an act that deserves
condemnation, it's not a moral failing or something like that. The GNU project
opposes _proprietary software_ as it is considered a social and ethical
problem. Although I advise against it, you are free to use proprietary
software for whatever reason (including possibly ethical or financial reasons)
--- there are no mechanisms in place to prevent you from doing that in Guix
(and the fact that Linux libre cannot load certain user-supplied firmware is a
bug).

 _As a project_ , however, we do not recommend the use of proprietary software
and don't provide a platform for advice on how to replace free parts of Guix
with non-free software.

The _use_ of proprietary software becomes an ethical problem when network
effects are in place. Otherwise, it is the mechanisms of proprietary software
itself that we object to, for example the barriers it poses to helping friends
or neighbours and the way it gives developers control over the users.

------
jancsika
Let's say I want to have the last five versions of my application installed as
a mortal user, for testing purposes.

Let's say that my application's build system pulls in a big GUI toolkit binary
because reasons.

Let's say I don't want to create "official" packages for it, just something
quick and dirty that will get me these versions installed.

Can I do this with GNU Guix?

~~~
nextos
With Nix you can, and Guix is a Nix reimplementation, so you can too.

In Nix, some details are still a bit clunky. Like pinning particular package
versions. But Nix / Guix are, in my opinion, already more useful and robust
that other distros.

For edge cases, I still use some ad hoc Dockers.

------
Y_Y
> Bootloader definitions are available for many boards—Novena, A20 OLinuXino,
> BeagleBone, and even NES.

I'd love to see somebody try to run GuixSD on a NES.

~~~
opencl
By "NES" they actually mean "NES Classic Edition" which is just a fairly
normal modern ARM board in a neat looking box.

------
agumonkey
very very happy to see the project lively and kicking :)

------
georgewsinger
The big problem that Nix/NixOS has is failure to integrate well with graphics
libraries (OpenGL drivers, etc).

Does Guix solve this problem?

~~~
danieldk
I have been using NixOS for a week now. I am curious, could you give more
details? I haven't tried any games, but Plasma is accelerated.

~~~
AnIdiotOnTheNet
Probably referring to the proprietary drivers, not the open ones that I assume
were included in the distro.

~~~
danieldk
But the proprietary drivers are too, just add

    
    
        services.xserver.videoDrivers = [ "nvidia" ];
    

or

    
    
        services.xserver.videoDrivers = [ "ati_unfree" ];
    

to the system configuration and do a _sudo nixos-build switch_ to switch into
the new system with NVIDIA drivers.

(NixOS is pretty fantastic in this respect, in the installation live
environment I just added

    
    
         boot.supportedFilesystems = [ "zfs" ];
    

to the configuration and switched to the new configuration. I could then do a
root on ZFS install without any extra effort.)

[https://nixos.org/nixos/manual/#idm140737316292128](https://nixos.org/nixos/manual/#idm140737316292128)

