
GNU Guix and GuixSD 0.13.0 released - rekado
https://www.gnu.org/software/guix/news/gnu-guix-and-guixsd-0.13.0-released.html
======
brendyn
I've had good fun learning to program with Guix lately. It's easy to start
packaging software and get contributions into a real project, But it's also a
large system, with complex internals that I'm gradually learning more about,
like G-Expressions[1]. I'm also studing SICP on the side, so it's nice that
they use essentially the same language.

I have high hopes for Guix. I conjecture that GuixSD can become the distro-
makers goto basis for creating new systems. Other distros have simpler sh-like
languages for building packages, which creates a system which is very much a
house of cards. Every time I look at debian package definitions for help, I
come out with one extra grey hair. I think Guix can build a much taller house
of cards than other packaging systems. For example, suppose you want to build
a Audio focused distro, and you'd like a PREEMPT_RT patched kernel, I haven't
bothered making this myself but it basically just requires `inherit'-ing the
linux-libre package definition, and then adding the PREEMPT_RT patch to the
list of patches to be applied. Whenever linux-libre is updated, your linux-
libre-lts will automatically include those changes too and be updated.
Naturally, incompatible updates can happen that break things, but that is
unavoidable. Then, you would create in your git repo all the package
definitions and customisations needed, and then finally a file containing the
system definition that is the actual distro. Other GuixSD users can try out
your distro by running sh $(guix system vm my-super-distro.scm --fallback) to
boot up a virtual machine running your system. Or guix system reconfigure my-
super-distro.scm will install it on the system in a non destructive way than
can be rolled back or reconfigured back to the previous system definition.
What's else? Scientific Guix? Educational Guix? One can share git repos
including .scm file that can easily be launched to show of their riced desktop
without borking other peoples systems? I admit I haven't looked at how debian
based distros are made, but I imagine it's not so simple to convert one dpkg
based distro into another one and then back again without any destructive
changes.

[1]
[https://www.gnu.org/software/guix/manual/html_node/G_002dExp...](https://www.gnu.org/software/guix/manual/html_node/G_002dExpressions.html)

------
arximboldi
Any experiences with using GuixSD as a main distribution for a standard laptop
working environment? I have been using Debian Sid for more than a decade but
the idea of having a system fully configured via reproducible pure Scheme
functions is tempting for sure...

~~~
mtm
I just installed GuixSD 0.12 last week on a Dell 13 7000. Went mostly smoothly
(had to use Grub BIOS instead of UEFI, that's been fixed in 0.13) after I
replaced the Intel WiFi card with an Atheros based one.

My needs are simple: emacs, Clojure (with Icedtea), Icecat and StumpWM. Plus
all the guile goodness!

Just realized I'm living in a system with four Lisps front and center (guile,
Common Lisp, elisp, and Clojure)

~~~
equalunique
That sounds pretty awesome. :)

I'm just here with two NixOS machines playing with ML languages.

Have you tried NixOS & do you have an opinion regarding it? Or was it just
straight to GuixSD?

------
CJefferson
What is the current position of guix Vs mix? Is one clearly more popular? Is
one "winning" or is this more of a Debian Vs redhat, where both can continue
to exist?

~~~
rekado
Disclaimer: I have been working on Guix since 2014 and use it in production.

Guix and Nix are both implementations of the functional package management
idea. Nix has been around for quite a few more years than Guix.

In Guix package expressions are first-class and the DSL is embedded in Guile,
a general purpose language, so packaging has a very different feel to it. It
also allows for fun tools like "guix graph".

Guix is used in scientific environments (e.g. where I work); I don't know if
there are deployments of Nix in HPC environments. I do think that there are
more bioinformatics tools packaged for Guix.

Another difference is in how the two projects approach certain problems, such
as bootstrapping from binaries. (Guix just got a new Java bootstrap from C.)

There is no rivalry between these projects and members of both projects
cooperate in the reproducible builds efforts.

~~~
dragandj
How easy (or even possible) is it to use proprietary libraries such as MKL or
CUDA or GPU drivers with Guix/GuixSD?

~~~
davexunit
It's all possible to do, but the Guix developers do not provide assistance.
From a purely technical perspective, software provided in binary form only
impedes one of the main goals of Guix, 100% reproducible builds, because there
is no source code.

~~~
nagvx
But would they provide resistance? As nice as the idea of a fully-free distro
is, I have the impression that free distros have a minuscule userbase compared
to their non-free counterparts. For an already niche distro, this sounds like
a significant handicap.

If someone came along and offered a hardware-compatibility repo or
redistribution, would the Guix community work with them, or would the
relationship be more distant, or even adversarial?

I'm personally very interested in the project, and have no desire to poison
the pure core of Guix, but I need my hardware to work.

~~~
rekado
We don't want to have discussions about non-free software on the project
channels, because they really are off-topic. We won't do anything to
_sabotage_ third-party repositories (no matter what they might contain); in
fact, we're working on implementing mechanisms to make it _easier_ to load
software from third-party channels.

But as a project following the Free System Distribution Guidelines (GNU FSDG)
we will not recommend third-party channels providing proprietory software, nor
would we want our project's communication channels (mailing list, IRC, etc) to
be used to steer users to channels that provide non-free software.

------
orangeshark
Congrats on the release. I use GNU Guix ontop of Fedora to use some extra
packages as well as commands like `guix environment` to set up a dev
environment to work on projects.

~~~
nerdponx
How easy/hard is it to manage? Does it conflict with Yum?

~~~
davexunit
It is completely isolated from other package managers. So you can use them in
harmony, and if you decide that you don't like Guix there's like 2 directories
to delete.

~~~
redtuesday
I assume unless you use software which installs it's cache/other stuff into
the user home directory, right? Then you would also need to delete these dirs
as well?

~~~
rekado
Software like that exists (e.g. ibus, which creates a database and cache in
the home directory), but generally I haven't had any problems with Guix on
other distributions.

~~~
redtuesday
Ah, good to know. Just tried sbt (build tool for scala) with Nix (have no
experience with Guix, but like that everything is in the same language) and it
indeed creates .ivy and .sbt caches in the home directory. Everything else
goes into the store like it should.

------
pjmlp
I don't have any use for Guix, but as language geek it is nice to see Guile
being used in production.

------
curiousreader
How does Guix relate to Flatpak?

~~~
rekado
Guix is a functional package manager, Flatpak is not. Flatpak is based on the
idea of runtimes (a collection of libraries and toolchains). There is no
dependency bundling with Guix and there are no "runtimes" against which
binaries are deployed.

Guix provides the tools for bit-reproducible builds, which is why it's used in
some HPC environments (including the institute where I work).

~~~
curiousreader
I read up a little on Guix, but I can't reconcile what I read with what you
wrote.

Guix clearly does track and even bundle dependencies.

The part I'm missing is how different packages can rely on different
dependencies without stepping on each others' toes. And if a certain package
relies on a dependency with known vulnerabilities, do I have to wait for the
package to change its dependency, or can I upgrade the dependency as soon as
it issues a fix?

~~~
rekado
> Guix clearly does track and even bundle dependencies.

No, it really does not. What part of the documentation made you come to this
conclusion?

Each package is installed into its very own prefix. The prefix is derived from
the hash of _all_ of the package's inputs. Inputs mean: the package
description itself (including configure flags and the like), the package
sources, and all packages it depends on, recursively. This means that every
package closes over the complete directed acyclic graph of its dependencies.

Change any of the inputs and the output prefix will change, i.e. the package
will end up in a different, separate directory.

Packages keep references to other packages. Instead of bundling all
dependencies under the package's prefix, packages can reference other packages
directly. We use the RUNPATH feature to embed absolute file names of e.g.
libraries.

A big part of Guix itself is a collection of package definitions. These
definitions are just Scheme values. Taken together, these Scheme values
describe a lazy graph of dependencies. Guix instantiates parts of this lazy
graph when installing packages.

As I wrote above, any change to a node in the graph affects all other nodes
upstream of it. If there's a security fix that needs to be applied to, say,
the glibc it will cause a rebuild of all packages that depend on it. (There is
an optimisation called grafts, which allows us to deliver security fixes
without actually rebuilding the world.) Packages that have been installed
already, however, will remain untouched. To benefit from a security fix these
packages have to be upgraded.

Guix makes it trivial to find the users of any given package in the store, so
it's easy for example to figure out if you have software that uses a
vulnerable library.

------
wcummings
Im gunna give guixsd a go (i run Ubuntu now). I do almost everything in emacs,
and I have all my configs/elsip (and plenty of scripts and other stuff) in a
big git repo. Setting up a new box is as simple as installing emacs and
checking out my repo. I look forward to rolling package installs and init
scripts etc into my repo (its init system is scheme based, no systemd).

Funny thing about guixsd, intel wifi chips wont work out of the box. Even if
you provide the firmware, the kernel wont load blobs. Im sure you could
install a new kernel... But it just feels dishonest. I bought a $10 usb
atheros card.

