
GNU Guix 0.9.0 released – Functional package manager and distribution - rekado
http://savannah.gnu.org/forum/forum.php?forum_id=8398
======
mbrock
I'm intrigued by Guix but right now I'm invested in NixOS.  Finally I've
learned most of the Nix language, which is elegant and quite clever, but it
was a little bit of a hurdle.  Scheme is more familiar and easy to learn, I
think, and I can easily see macros as being extremely useful for system
configuration.  I'm fully convinced that the Nix/Guix style of package
management and system configuration is Teh Future.  Anyone who isn't drinking
koolaid on that bandwagon yet should hop on and check it out. 

~~~
nextos
I also love Nix/Guix, but I have the feeling the future will sadly be giving
us container-ized apps systemd-style.  Much worse security and sysadmin-wise. 

~~~
mbrock
I launch containers from systemd in NixOS.  My future is a mixed bag. 

~~~
nextos
Containers are cool for big things.  But imagine every single program stuck
inside a container without proper management tools to track dependencies.  Now
imagine a heartbleed-like scenario where you need to patch a big security hole
ASAP.  With containers you'd have a hard time. 

~~~
kefka
Depends how those "containers" interact with the system at large. 

In the Windows world, it's common to have the libraries you need stored in
~/Program Files/Program_name/ .  Now, each program dumps in its program home
the library, only because it cannot guarantee the library would be in the
system. 

In Linux, we deal with having different major versions of said library.  nd
minor versions are clobbered by major.  So when someone who wrote stuff using
python 2.7.2 and 2.7.3(bugfixes) comes out, there is invariably something that
is broken. 

A container that encompasses "Python", and holds all the versions would be a
great deal.  Same with other programs.  They could interact, but their install
and environment would be encompassed as a complete "Python", regardless of
version or bugfix. 

~~~
JupiterMoon
You are describing NixOS/Guix rather than containers. 

------
ilurk
I'm just trying to get all of this "package management" sorted out.  So could
anyone please comment. 

Guix is a package manager that is currently limited at 2619 packages [1]

NixOS is a GNU/Linux distro which uses the Nix package manager (makes package
management reliable and reproducible.  It provides atomic upgrades and
rollbacks, side-by-side installation of multiple versions of a package, multi-
user package management and easy setup of build environments) and currently
provides 11630 packages [2]

Ansible/Chef/Puppet is a package manager oriented at deployment at multiple
nodes, which works with multiple GNU/Linux distros. 

Vagrant is a package manager.  A wrapper around Ansible/Chef/Puppet. 

My understanding is that I can fix all problems with NixOS, with the caveat
that I'm limited to NixOS, so I can't Nix on a Debian or Ubuntu or Redhat. 

Assuming the adoption of NixOS isn't a constraint, why should I bother to
learn Ansible/Chef/Puppet and Vagrant? 

And if Ansible/Chef/Puppet are still worth learning (and please comment why)
besides NixOS, is there any reason to learn Vagrant as well? 

[1]
[http://www.gnu.org/software/guix/packages/](http://www.gnu.org/software/guix/packages/)

[2]
[https://nixos.org/nixos/packages.html](https://nixos.org/nixos/packages.html)

~~~
fineIllregister
You can run Nix on Arch.  I think you can run it on other operating systems. 

[https://aur.archlinux.org/packages/nix/](https://aur.archlinux.org/packages/nix/)

~~~
codemac
You can run Guix on Arch as well (it's what I do)

------
matthewbauer
Does anyone else feel like they're just duplicating all the work done by Nix? 
I guess there's nothing wrong with multiple functional package managers.  It
just seems wrong to reject Nix just because it allows unfree software. 

~~~
civodul
Guix indeed has a strong commitment to user freedom, which makes it a
different project. 

Technically, I don't see it as "duplicating" Nix: Guix uses low-level parts of
Nix that are awesome, and replaces higher-level layers with a more integrated
and unified system.  See
[https://arxiv.org/abs/1305.4584](https://arxiv.org/abs/1305.4584) for the
technical rationale or the video on the home page on the concrete impact of
those differences.  Hacking GuixSD is a very different experience, I think! 

(Disclaimer: I maintain Guix and I'm a former NixOS hacker.) 

~~~
mbrock
Random lazy question: do you know about running GuixSD on AWS EC2?  We're very
happy with NixOS's AMI images, since they let us provision AWS instances
extremely easily. 

~~~
civodul
As far as I know nobody has tried so far, but that would be cool. 

------
rkuska
Looking at the package list I can see:

python-sphinx and python2-sphinx

From this I conclude that python-sphinx is python3 version of sphinx right?  Do
you think that's sane (from user experience point of view) assuming that
/usr/bin/python should point to python2? 
[https://www.python.org/dev/peps/pep-0394/](https://www.python.org/dev/peps/pep-0394/)

~~~
davexunit
Yes, python-sphinx is the Python 3 version of Sphinx.  Note that Guix does not
conform to the FHS, and thus has no /usr directory. 

~~~
rkuska
Yet anyway as a python user I would expect to receive python2 version when
installing python-sphinx. 

In Fedora we have (most recent change in packaging guidelines):

Source rpm: python-foo which generates binary rpms: python2-foo and
python3-foo where python2-foo has virtual provides for python-foo, once
Python3 will become THE default python by the upstream merits we will change
python-foo provides to python3-foo package. 

------
weavie
I'm not sure I fully understand what Guix is.  Is it a replacement for pacman /
apt-get etc..? 

~~~
mbrock
Here's an evocative screenshot:

[http://www.gnu.org/software/guix/screenshots/0.8.3/guix-
syst...](http://www.gnu.org/software/guix/screenshots/0.8.3/guix-system-
vm.png)

It's a distribution of Linux that uses the Scheme language both for defining
packages and for configuring the user's system. 

In that picture, someone is generating a QEMU image from a certain system
configuration.  The Guix tools will read the configuration file, and then
create a VM that matches its parameters. 

You might be reminded of Ansible, Vagrant, and similar tools for "declarative"
configuration. 

Note how the configuration specifies a list of user accounts.  Later, inside
the VM, you could modify that list -- say, change Bob's name, add Alice, and
also create a common user group for them -- and then tell Guix to update the
system.  It would then look at its current configuration and figure out what to
change. 

The same applies for things like defining system services.  So you will have a
Scheme file that defines, say, that nginx should be running on port 80 with
these three different vhost configurations.  The distribution will then know
how to generate an nginx configuration file, how to setup the init system, and
how to reload these things on changes. 

(I don't know if Guix has a predefined thing for generating Nginx
configurations; if not, you can certainly build one easily with some Scheme
expressions.) 

I use NixOS, which is an earlier implementation of the same idea.  Me and my
brother, with whom I work, share a basic system configuration file.  That means
I can define a new web service, along with whatever package dependencies it
may have, even including creating a new user account -- and push that to our
repository, so he will pick it up, and then I can say "hey, check out
localhost:8050" and it'll just work. 

We also use NixOS on our cloud servers.  We have one configuration file that
declares all of our services (redis, etc) along with our app vhosts (mostly in
the form of systemd units that launch Docker containers, using some custom Nix
functions).  This means that our services are always running the same way on
our laptops as on the server, just on different domains (the server's internet
domain vs our localhost domains). 

~~~
emj
Guile actually looks good when used declarative! 

------
listic
What does "GNU" icon in the packages list [1] stand for? 

[1]
[http://www.gnu.org/software/guix/packages/](http://www.gnu.org/software/guix/packages/)

~~~
sepeth
They are part of the GNU system. 

[http://www.gnu.org/help/evaluation.html](http://www.gnu.org/help/evaluation.html)

Btw, some projects are hosted on nongnu.org domain, those are not part of the
GNU system. 

~~~
mikegerwitz
And we'd love to see more!  Information and instructions for submitting your
project are in the link above. 

(I'm part of the GNU evaluation team.) 

------
yepguy
Does Guix have (the equivalent of) package signing?  Last I checked Nix wasn't
very concerned about this. 

~~~
sparkie
Package signing is relatively useless.  All it tells you is that a given person
signed a binary, but it does nothing to tell you whether the contents of that
binary match the source code (and currently, no such tooling exists to perform
this verification.) 

Nix and Guix on the other hand, are primarily source code based.  Packages are
given an identity which is a secure hash of their source code and complete
build instructions.  This makes it infeasible to make any modifications to the
source code, as intentionally malicious modifications would result in a
different hash, and source code changes are detectable in commit logs. 

While binary versions of these packages are available via Hydra, one can
always use the source code versions if they're worried about security.  Long
term goals for Nix and Guix are to have completely reproducible binary
packages, whereby we can assert that given a package definition, the resulting
binaries will be bit identical when compiled from different machines.  Instead
of relying on a hash of the source code, we'll have a hash of binaries
matching a package definition. 

And when we get to this stage, we can completely stop worrying about _who_
packaged a piece of software, because the result should be the same
regardless.  Instead, we can start looking at an alternative model of
distribution where several independant parties, chosen by the user, reach a
consensus on the binary hash which corresponds to a given package definition,
and have that package retreivable through a distributed network (a DHT). 

~~~
vfclists
Does this also include the compiler and versions of the compiler used,
assuming that build and compiler options are identical?