
GNU Guix 0.5 released - Tsiolkovsky
https://lists.gnu.org/archive/html/guix-devel/2013-12/msg00061.html
======
tikhonj
For reference: GNU Guix is a version of Nix[1] with some additional features
like a Guile API. While I'm sure it makes sense in the greater context of a
GNU system where everything is happy and Guile-powered, I personally do not
really see a reason to use Guix over normal Nix which seems to have a greater
mind share and user base.

If you like this approach to package management, you might want to consider
trying NixOS[2], which is a distro that uses Nix as its primary package
manager. NixOS has a disproportionately high uptake in the Haskell community,
so it has a very good selection of Haskell packages--if you're playing around
with or actively using Haskell, that could be another bonus for NixOS.

Personally, I think the idea is very cool. I will probably at least try using
NixOS for my next laptop--I generally switch distros every time I get a new
computer.

[1]: [http://nixos.org/nix/](http://nixos.org/nix/) [2]:
[http://nixos.org/](http://nixos.org/)

~~~
xiaomai
I'm a huge fan of the nix/guix projects (initially I was super excited to see
a guix because I prefer scheme, but actually the Nix language is wonderful).
I'm really surprised the Nix package manager doesn't have a bigger following
with Mac OS X people (it's a lot more capable than homebrew, and you get
binary distribution for free).

One problem I ran into as a ruby guy was building gems that needed to link
against a C lib. Part of the beauty of the Nix approach is that it isolates
everything. The "proper" solution I guess would be to package gems as Nix
packages, but it seems like there probably should be some way to let a utility
know the proper build flags for a given lib.

~~~
zimbatm
Same here, Nix is exciting. The story with ruby still has some way to go
before it is seamless.

For each language they have an adapter that exports the language-specific
package manager to nix expressions. cabal, perl, python and ruby are all
supported (maybe more). In the case of ruby there is `nix` ruby gem that you
can use to generate a .nix expression. Ideally you could amend it to say that
nokogiri depends on libxml2 and such. Then your project could have a deps.nix
file that you can install. `nix-env -f deps.nix -i`

I'm also exploring different ways to work with my projects. For example
creating a custom profile per project that's derived from a project-specific
derivation.

~~~
sparkie
I'm not particularly a fan of the idea of static converters to nix
expressions, ala cabal2nix. They require someone to run them in the first
place, so you don't pick up updates to packages dynamically.

I'd rather we collectively agree on a protocol for installing, updating,
querying packages etc, such that each language-specific package manager can
talk to others through a daemon and install foreign packages that are required
for the projects. It would require a fair amount of work to update each
package manager to talk it (optionally), and agree on the semantics and
policies of the protocol, but I think the benefits could be huge.

Using Nix/Guix as the basis for such protocol would probably be ideal due to
the immutable nature of packages and ability to install side-by-side versions,
and that you can specify an identity of a dependency, rather than rely on
fuzzy matching of name and version.

------
davexunit
Congratulations to ludovic and the other contributors! I wrote a few of the
new packages in this release. The prospect of having not only an official GNU
distribution but one built on such a solid package management platform is very
exciting.

I recommend checking out some of the package definitions in the gnu/packages
directory to see how elegant the DSL is. Here's a module that I wrote:
[http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/...](http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/sdl.scm)

If you happen to be interested in monads in Scheme, be sure to check out
guix/monads.scm. It's a good read:
[http://git.savannah.gnu.org/cgit/guix.git/tree/guix/monads.s...](http://git.savannah.gnu.org/cgit/guix.git/tree/guix/monads.scm)

Please try out the QEMU image for an early look at Guix's GNU system. If you
like what you see, we could use some help packaging popular free software
programs. Oh, and join the mailing list and come lurk in #guix on freenode.

~~~
Sanddancer
I see some interesting parts in the dsl, but at the same time, I see some
warts that would rather be shaved off. For example, requiring (sha256 (base32
"hash")) just adds cruft in my opinion. I'd say exposing a function that
handles all that for you, like what nix does, would be better -- something
like (hash-sha256 "hash").

Though personally, the licensing section leads a real sour taste in my mouth.
Nix's licensing system is much simpler, much less politicized. Simply link to
the license directly, leave the commentary elsewhere. Linking to the FSF's
reasonings for every license just makes me much less inclined to experiment
with it.

------
hansjorg
For any one else wondering:

>The result of package build functions is cached in the file system, in a
special directory called the store (see The Store). Each package is installed
in a directory of its own, in the store—by default under /nix/store. The
directory name contains a hash of all the inputs used to build that package;
thus, changing an input yields a different directory name.

>This approach is the foundation of Guix’s salient features: support for
transactional package upgrade and rollback, per-user installation, and garbage
collection of packages (see Features).

[http://www.gnu.org/software/guix/manual/guix.html#Features](http://www.gnu.org/software/guix/manual/guix.html#Features)

------
javert
How is this concept different from the concept of "deterministic builds"?

To break that down, first: Can you get a determinisitc build from using a
functional package manager?

Second, is a functional package manager a better way to get deterministic
builds than whatever else is used (and what that is, I have no clue)?

~~~
xiaomai
Read the paper from the Nix people, it's fantastic:
[http://nixos.org/~eelco/pubs/nixos-jfp-
final.pdf](http://nixos.org/~eelco/pubs/nixos-jfp-final.pdf)

------
josteink
While I'll probably not be using this myself, tokhonj's explanation of what
this is does make me a bit tickly. _Nix_ as a whole sounds neat. Having that
work with LISP/Scheme sounds even neater.

But the name is horrible. Guix makes this sound like something GUI-related. A
GNU implementation of X? I don't know. The name is wildly misleading.

They really should consider doing something about that, because naming
conventions tend to matter more than you think they do.

~~~
sparkie
I dislike the name too. It's meant to be pronounced "geeks", but I imagine
most people will expect to pronounce it "gwicks" or "GUI x" on first look. I'd
prefer something like "Gnix", or GNU Nix, which maintains it's origin and
makes it clear it's a GNU project. Or just call it "Geeks" if you want it
pronounced that way.

------
nfoz
Sounds similar to Nix/NixOS [http://nixos.org/](http://nixos.org/)

~~~
andrewflnr
That's because guix is a fork of Nix.

------
616c
Is anyone using NixOS on a laptop or desktop they use frequently? This is the
third time I read about it here, and I generally curious.

~~~
ocharles
I have been using NixOS as my primary OS for the best part of half a year now
(maybe more). I haven't looked back since :) I do warn people though - it's
not as featureful as other distributions, so you have to be willing to help
out. I'm approaching my 100th commit on the project, I believe.

------
yaiu
> New port to the Loongson MIPS64 processors, n32 ABI (‘mips64el-linux’)

Time to fire up my yeeloong

------
616c
Want your head to explore: the future of package management: an Emacs plugin
when Emacs goes Guile! (Personally, I think that would be pretty cool.)

~~~
sparkie
Perhaps we could have something like EDE mode (but one that people would
actually use), which uses a Guile DSL to describe projects and which hooks
nicely into Guix to automatically handle the dependencies of the project, and
build projects in an isolated environment. With any luck we could say bye-bye
to make, m4 and pkg-config too.

------
peterwwillis
I just looked up the page on Nix, and, yuck.

First of all, requiring the directory you install shit to to include a full
cryptographic hash in its name? Do you even comprehend how completely useless
the file path is now to a human? Sure you can have a directory of symlinks to
make it readable again, but as we should know by now, plenty of applications
bork on trees of symlinks (and you can't hardlink a directory). Plus your
garbage collector depends on hardlinks (or a whole lot of tree indexing). This
could have been managed in so many ways to make it a lot more user friendly.

"Complete dependencies"? You mean MANDATORY dependencies? This is so fucking
annoying. Now I can't install an entire OS because one package with a specific
SHA is gone. So even though I could rebuild it from scratch and it could be
functionally identical, with 1 bit different the SHA is hosed and now
everything is useless. Not to mention even if I had it, I have to ship every
single dependency to anyone any time I want to give them that package/app/etc.
Fantastic. And 'scanning binaries for hashes of directories'? This has got to
be the laziest, dumbest solution to a complex problem i've seen supported by
GNU since...... Wait, nevermind. They've probably supported dumber things.

MULTI-USERS?!? YOU MEAN A NORMAL USER CAN INSTALL A PACKAGE? GET OUT. NO
PACKAGE MANAGER CAN DO THAT EXCEPT.... All of them?

Atomic rollbacks/upgrades sounds nice, until you realize a program might be
running other programs, which might trigger your runtime dependency checking,
which might screw everything up.

"Garbage collector" ? Oh. If it has hardlinks, you don't delete it. Gotcha.

As far as "functional" operations go, it's been pretty well proven in
production environments that you don't actually have to completely recreate a
binary exactly; just approximately. Functional operations management gives
techies a hard-on, but means diddly in terms of real-world problem solving. We
have managed away the implicated problems years ago.

WHY ARE WE STILL INSTALLING FROM SOURCE?! Did Gentoo teach you all nothing!?!

Service deployment? You mean service configuration management and deployment?
Sigh, here we go again. Let's combine three different things into one and
pretend it's a viable solution for general operational challenges.

Everything else seems handy.

~~~
weland
Why are you even using a computer?

~~~
peterwwillis
.....Why are you?

