
GNU Guix 0.8 released - davexunit
https://lists.gnu.org/archive/html/guix-devel/2014-11/msg00379.html
======
taylanub
Cross-post from Reddit to clarify what exactly Guix is:

GNU Guix is a Guile-using Nix-derivative purely functional package manager and
at the same time package recipe database. (Shipped in one so the recipe
language doesn't need to be frozen for compatibility.) Development of the
Guile-based init system DMD is closely tied with it.

Its last few releases include stuff to install a stand-alone GNU/Linux-libre
system which might be sanctioned as the GNU Operating System if RMS approves.
Since it builds heavily on GNU software like Guile (GNU's official
scripting/extension language) for its init system and package manager /
deployment tool, prioritizes GNU packages in its database, and remains
ostensibly kernel-agnostic with the hopes of running on the Hurd in the
future, it can be seen literally as the GNU OS. (GRUB, GCC, Autotools, Glibc,
Bash, coreutils, etc. all go without saying.)

(Until approval of the name GNU, the OS simply has the same name as the
package manager: Guix.)

And homepage:
[http://www.gnu.org/software/guix/](http://www.gnu.org/software/guix/)

------
sergiosgc
Package management is probably, today, a very well defined problem. Isn't it
time to solve this once and for all? Or are we forever doomed to have multiple
package managers for the dot product of [operating system]X[development
platform]?

It itches me that php has pear and composer, node has npm, ruby has gems and
python has pip. It itches that deb and rpm solve the exact same problem, not
to mention all the other smaller package formats/managers like pacman, yaourt
or portage. It looks as pretty obvious that it is the same problem, albeit
attacked via some different angles (source build versus binary distribution
notably).

It even looks like it could be cross-platform, solving in one simple swoop at
least unix systems (namely linux along with the BSDs) and, in a dream world,
non-unix systems (windows, notably).

Daydreaming, yes. The status quo is too well established. But it justifies my
jaded look regarding Guix: Late comer to a party that is already stale and
over.

~~~
Doji
Nix is attempting to be the solution you're looking for. Look at the nixpkgs
repository:
[https://github.com/NixOS/nixpkgs](https://github.com/NixOS/nixpkgs)

You will see packages for tons of stuff, including:

    
    
        * Python packages from PyPi: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/python-packages.nix
        * Haskell packages from Hackage: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/haskell-packages.nix
        * Perl packages from CPAN: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix
        * NodeJS packages: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/node-packages.nix
        * Lua Packages https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/lua-packages.nix
    

All these packages in one place, all installed through the same system and
automatically built and tested on the Hydra build farm. Nix users have
developed tools which automate (as much as possible) the creation of these
packages.

I really believe NixOS is the future of the Linux distro, and it's tragic that
it's still relatively obscure. It revolutionizes the OS in a myriad of ways,
getting everything into the same package repository is just the beginning. For
instance, it's fully configuration managed out of the box, using the Nix
package manager as its configuration mangement system. Puppet, ansible,
saltstack, chef, etc. are all made obsolete. Sure, it still has some rough
edges, but it's a great community to contribute to and is improving at a
impressive clip. If you're interested in the other ways NixOS is better than
whatever you're currently using, I refer you to the website:
[https://nixos.org/](https://nixos.org/)

~~~
VieElm
> curl [https://nixos.org/nix/install](https://nixos.org/nix/install) | sh

Installation instructions for nix. Although I'm not sure that arbitrarily
running shell scripts from the internet is a good thing. When I install an OS
X app from the internet, at least it's signed.

~~~
VLM
That script does a lot of work that boils down to "go to
[https://nixos.org/releases/nix/nix-1.7](https://nixos.org/releases/nix/nix-1.7)
and do the obvious"

Of course if thats not signed you still have a problem. Eternal chicken and
egg issues. How do you install gpg to verify a gpg signature while verifying
the gpg signature of gpg

------
sly010
Interestingly enough, the adoption of a new technology standard is very
similar problem to that of the adoption of a new product. There is a
learning/switching cost involved, and for someone to make the move the pain
has to be absolutely unbearable, the new solution has to be 10x better, and
the cost has to be as low as possible. We often end up in local minimums and
paradoxically the only way to overcome those is to run competing searches
(aka, multiple products/standards) or simply to restart the search. Then there
is also the problem of existing solutions being already "good enough" (think
python27, IE8, IPV4, dpkg, cars that run on oil, and electricity that comes
from coal).

~~~
taylanub
Purely functional package management (PFPM) gives us reproducible builds;
other package management systems don't. 1/0 = ∞. Therefore PFPM is infinitely
better than non-PF PM. ;-P

And my reasons for choosing Guix over Nix would be: fully-free GNU system,
doesn't use systemd (no hate, just a preference), uses Scheme/Guile for
everything from init system to PM.

(Add possible future Guile/Emacs integration to the mix, and that Guile might
enter even more GNU software (e.g. it's in GCC, GDB, and Make already), and we
get an interesting picture of a pseudo-Lisp Machine... I'm thrilled,
personally.)

------
darklajid
As someone that ran nixos for a time I wonder if this might allow me to
proceed further - with nix(os) I had some issues grasping the recipes/the
language. Scheme looks much more accessible to me.

Offputting is the strong focus on libre in the announcement. While I actually
like that I often find that projects that emphasize their relation to
free/libre software are .. failing in the real world. Need to figure out if I
could actually install useful media codecs, flash if needed, heck - maybe
decss or whatever I deem necessary.

~~~
taylanub
Adobe Flash is an outright offense if you ask me. A distro providing a
separate repo for non-free software is one thing, forcing me to run
uninspectable code, which is known to have a horrible security record, under
my user's privileges, is another thing. As OpenBSD people say, it's a feature
that it's missing. :-P

I don't know what problem with media codecs there are. FFmpeg, as free
software, implements H.264 just fine, even though it's a patented format. I
don't know how exactly the legal aspects of that work, but I'm happy it
somehow works, because otherwise I couldn't watch all my [spoiler]Chinese
cartoons[/spoiler].

Now WiFi cards are a problem from what I know. You can buy a WiFi dongle with
free software drivers though to get around that issue, or replace your
laptop's WiFi card with one that has free drivers. I suspect that will be the
one major issue with the GNU OS, and the only thing we can do is ask
manufacturers of WiFi hardware to be more cooperative.

The other big problem tends to be the BIOS, but GRUB/Linux-libre at least boot
just fine on proprietary BIOS, so it's no issue for those who don't care.
Those who want to take the further step for software freedom may want to look
into LibreBoot: [http://www.libreboot.org/](http://www.libreboot.org/)

~~~
darklajid
Well, let's put flash aside. I'm not a fan and Shumway works for most stuff
that I need.

Dropbox? BTSync? (I .. don't care about the latter, and try to replace the
former with SyncThing atm, but I'm trying to make a point: It's more than just
a single binary blob to watch cat movies or porn in a browser)

What I really like to install is Steam.

What I'm trying to say here is: If there's no middle ground, no way to fulfill
my needs, the system just isn't for me. I might support the idealistic idea,
but I cannot (or, more precise: I don't want to) work with a number of
limitations.

I didn't even think about wifi or anything hardware related. If that doesn't
"just work" it's again impossible for me to use the project and I need to bury
the idea of trying Guix right next to my failed attempt to run nixos as my
host system.

------
norswap
I like the idea a lot. However what's lacking is good package repositories to
go with it. Nix has exactly the same issue.

A question I have is why don't they use the Debian / Fedora repositories? Is
there some crucial meta-data missing? Are the build script for .deb / .rpm
made in such a way that it is not possible to add multi-version support on
top?

To clarify, I'm not asking them to interoperate with apt-get/yum, just to use
the package repositories as a source.

~~~
davexunit
>why don't they use the Debian / Fedora repositories?

They are fundamentally incompatible.

Among other reasons, Debian and Fedora package builds are not reproducible.
That is, given the corresponding source code to the package, you're not likely
to get the same binary if you build it yourself. Sometimes maintainer uploaded
packages may not build at all for someone else, because the binary built on
the maintainer's machine relied on some extra software not specified in the
build recipe.

Nix/Guix are source-based distributions. They build packages in an isolated
chroot, in which only the explicit dependencies of a package are available.
This means that no user must rely on a server to give them binaries. Any user
can opt to build any package on their own system instead, and the result will
be nearly bit-identical to what's on the build farm.

Hope this helps.

~~~
SwellJoe
_" Nix/Guix are source-based distributions. They build packages in an isolated
chroot, in which only the explicit dependencies of a package are available.
This means that no user must rely on a server to give them binaries. Any user
can opt to build any package on their own system instead, and the result will
be nearly bit-identical to what's on the build farm."_

While the package format RPM lacks insurance of this process, the culture of
Fedora/RHEL is that packages are built using mock (as part of the koji build
system), which _does_ build everything in a chroot. And, if a package would
build differently (such as pulling in different libraries, for instance) for
someone using the same tools it is considered a bug and will be fixed by the
maintainer.

I don't know how specific guix/nix get in this regard: Do they specify the
build dependencies down to some sort of file-based checksum level? Or will
they build against any compatible version of a library? If the latter, how is
that different from RPM when using mock? One could just as readily end up with
a very different build of a package, based on which library version is
available in the repo against which the package is being built.

One could lock down the remote repository to create predictable builds (i.e.
only use the Fedora version 20 repo, with no updates; or the Guix version
whatever repo with no updates), and presumably either would produce very
predictable builds (I know the Fedora case would).

So, what do you mean when you say "reproducible"? Is it really specific and
unforgiving of new versions of things? Or, does it allow for newer versions
easily? RPM allows one to specify things with extreme specificity (down to the
exact version and package revision), but one rarely does that if the package
will build successfully with a range of versions.

I'm not sure I'm convinced this is a unique feature of Guix/Nix, is what I'm
trying to say.

~~~
davexunit
>Do they specify the build dependencies down to some sort of file-based
checksum level?

Yes, Emacs 24.4 built with X support has a different hash than Emacs 24.4
built without X support. They are completey different in the eyes on Nix/Guix.

>So, what do you mean when you say "reproducible"? Is it really specific and
unforgiving of new versions of things? Or, does it allow for newer versions
easily?

In Nix/Guix, you _have to_ specify the _exact_ dependencies, nothing is
implicit. Packages are built as a pure function. A package's identity is the
hash of all its build inputs: source code, build system, and other
dependencies. Bumping the version of a dependency triggers rebuilds of
packages that depend on it.

I know of no other package management systems that treat package builds in
this manner.

~~~
SwellJoe
This doesn't really sound like a feature. Or, at least, not a feature I've
ever wished I had.

From a purely pragmatic perspective, it means huge swaths of software have to
be rebuilt any time anything gets updated. And, it's become clear now to me
that every user is building all their own software (as with ports or Gentoo
ebuild, both of which I consider unacceptable package managers for servers for
that very reason)...given that, and given that rebuilds now must often span
huge piles of software, occasionally with exploding dependency chains, I'm
feeling a little queasy imagining trying to administer such a system.

I understand the appeal, from a security perspective (and particularly in a
world in which the NSA and other highly capable attackers are willing to exert
resources to compromise software at the vendor level), of being able to
duplicate a package from source. That's cool. But, why force every user to do
so every time they update their software? Am I missing something? Are there
also binary packages and being able to verify package builds is optional?

~~~
davexunit
Users do not need to build everything for themselves. They can download
binaries from the build farm, just as if they were using a binary-based
distro. The system is transparent: If a binary is available from an authorized
remote machine, Guix will pull from it. If not, Guix will build it locally.

To respond to security updates to core packages a lot faster, we are using a
technique called 'grafting' that doesn't involve full rebuilds.

------
erkose
Boot to Guile FTW!

------
gtirloni
So it's a Scheme layer on top of Nix?

~~~
davexunit
To some degree, yes. Guix is compatible with the low-level Nix package format,
and it currently uses the upstream Nix daemon. Everything else has been
replaced. Guix uses its own client-side and build-side code. The Nix language
is replaced entirely with Guile Scheme, build scripts are Guile programs
instead of shell scripts, the UI is different, etc.

------
Spooky23
Thank goodness, I was concerned that we didn't have enough package management
options!

