GNU Guix 0.8 released

https://lists.gnu.org/archive/html/guix-devel/2014-11/msg00379.html

by davexunit • 12 years ago

163 72 12 years ago

lists.gnu.org

taylanub11• 12 years ago

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/

sergiosgc7• 12 years ago

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.

lucian1900• 12 years ago

Nix (and by extension Guix) are meant to be this solution you're looking for. The problem, as with most unified solutions, is adoption.

sergiosgc7• 12 years ago

Then that is the very first thing they must state. Instead, the opening line is: "GNU Guix is the functional package manager for the GNU system and a distribution thereof."

In addition, this problem can only be solved by luring established platforms, and this can only be achieved by providing a transition path. It should be able to coexist with other package managers (composer, or pip, or npm or, if shooting for the moon, rpm and deb).

akerl_• 12 years ago

I'm always confused to see this point brought up. Whenever there are lots of options, folks talk about the harms of fragmentation and wasted effort and focus. Whenever there aren't a lot of options, it seems like the same crowd demands disruption and competing choices.

sergiosgc7• 12 years ago

Different people, probably. I'm all for consolidation whenever the problem space is very well defined, and divergence whenever the problem space is ill defined. This is a case of the former.

abenga• 12 years ago

This is a pretty common point of view, but I wonder, how would this be enforced in a free-and-open software development ecosystem? Who would go around stopping people from launching their own take on a solution to the same problem apart from the "blessed" solution? In a world where everyone is free to choose which problem they'd like to solve and how to go about it, and it is impossible for everyone to agree about even the most trivial of options, you cannot ever have only one text editor, package manager, init system, etc.

Seeing how well most developers welcome change in their favorite OSes, editors, etc, I imagine a world where every developer bends their efforts towards the one true chosen solution, and are not allowed or able to choose to "waste" their efforts on another solution wouldn't yield as vibrant a software ecosystem as we have now.

sergiosgc7• 12 years ago

This is a pretty common point of view, but I wonder, how would this be enforced in a free-and-open software development ecosystem?

It wouldn't be enforced. The beauty of OSS is that there is no enforcing of solutions. Even when you touch something as core as the init system or the graphics system, the solution must prevail by technical merits. There is marketing, but thankfully this is a world of technical evaluation first, selling second and never one of enforcement.

Change is more difficult, but so are mandated blunders.

unterstrom• 12 years ago

Mandatory XKCD comic: http://xkcd.com/927/

taylanub11• 12 years ago

You beat me to it. :-)

bryanlarsen2• 12 years ago

I would argue that it's far from a well defined problem. deb/rpm have very fundamental differences from gem/pip/npm etc. CoreOS takes a very different approach to packaging, and so does Nix/guix.

If it truly was a well defined problem, everybody would be using RPM. All the package managers you mentioned were created because somebody perceived a problem or limitation with previous formats.

sergiosgc7• 12 years ago

I would argue that it's far from a well defined problem. deb/rpm have very fundamental differences from gem/pip/npm etc.

I know the internals of pear, pip, rpm and deb. I don't recognize fundamental differences between them, although this evaluation depends on the definition of fundamental.

At the very core, all of them catalog files on the filesystem, script configuration of files once written and trigger reactions from other packages to the appearance of a new package.

The key difference is one of domain. Development platform specific package managers do their operations from inside the development language, with the niceties that come about from that (better APIs to change the development environment). This is not fundamental.

As for being well defined, I state the problem as: If you lock in a room, for a couple of hours, the lead developers of deb and pip, would they be able to come up with a unified package manager? It's, for me, clear that they would. Rinse and repeat, and you get a full unified spec.

1ris2• 12 years ago

I hope this solves the fad that every new programming language writes its own package manager.

davidw• 12 years ago

Adopting a GPL'ed tool written in Guile to install packages for their own languages? I don't see it as likely.

cpa• 12 years ago

It's well defined, but there's no good solution to this problem yet! See: http://www.well-typed.com/blog/2014/09/how-we-might-abolish-... It's true for every language out there, not just Haskell.

taylanub11• 12 years ago

Guix is not late in that there aren't many purely functional package managers out there. It's the second after Nix if I'm not mistaken, and it doesn't reinvent the purely functional wheel either; it builds on top of existing core parts of Nix. Why not use Nix? Most importantly because it's not GNU; NIH is sadly a real problem for GNU. But Nix also uses C++/Perl and a stand-alone package recipe language; Guix uses Scheme as much as possible. ISTR Guix also has some features that Nix lacks, such as unprivileged package management. Don't quote me on it though; mayhaps it's trivial to add to Nix or has already been done.

Cooperating with existing infrastructure is, I imagine, very difficult for a purely functional package manager, given the whole "purely functional" aspect. :-)

It's also extremely unlikely that Debian will just give up apt, and RedHad will just give up rpm.

And every programming language platform seems to have its own package manager precisely because of that reason: there is no one package manager on all systems, but a proglang platform wants to offer package management on all systems, so each bake their own implemented in and special-made for the language.

It's a sad state, but that's the world of software for you.

http://xkcd.com/927/

seagreen• 12 years ago

Nix does have unprivileged package management via a CLI tool, though the absolutely fantastic describe-the-whole-system-in-one-file wonder that's configuration.nix[1] takes elevated privileges.

[1] E.g: https://github.com/Fuuzetsu/nix-project-defaults/blob/master...

Dylan168072• 12 years ago

Guix is not late in that there aren't many purely functional package managers out there.

Why does almost anyone not involved in writing it care what language the package manager is written in?

Cooperating with existing infrastructure is, I imagine, very difficult for a purely functional package manager, given the whole "purely functional" aspect. :-)

I don't follow. Why is that difficult?

http://xkcd.com/927/

You can have different implementations of the same standard. To make your own standard is a step beyond.

taylanub11• 12 years ago

Late clarification because I wasn't careful and forgot that "NIH" has very negative connotations:

When I say "NIH is sadly a real problem for GNU," what I mean is that NIH can be an actual valid reason for GNU to fork or reinvent something, not that they're guilty for doing so. As in, it's unfortunate that they'd have to do it, but sometimes they have to. (Often it's not "reinvent" at all though, instead merely maintain an upstream compatible fork such as IceCat or Linux-libre.)

The reason is that if a non-GNU project is heavily relied on by GNU, the project might one day decide that they don't exactly agree with GNU anymore, so it's best to have a fork under GNU which can be fully trusted. Sometimes I find this non-trusting stance sad, but it seems to be necessary; just see Mozilla adding DRM to Firefox. :-(

agumonkey2• 12 years ago

Package management may be defined but maybe not well named. More and more when I see package I see language stack, lexical scope and such...

Maybe the Systems vs Languages split is detrimental to the solution here.

dragonwriter• 12 years ago

Package management is probably, today, a very well defined problem.

I don't think it is. I think "package management" is a name for a general class of solutions that addresses a range of problems (varying, at a minimum, along a continuum between "I want a way to pull a set of implementations of particular capabilities on any of a variety of different systems for which the appropriate implementations of those capabilities may be different" to "I want be able to reproduce from a list the same set of implementations across different machines".)

There's also a range of priorities about certainty of results versus freedom to mix and match and ease of contributing to the globally accessible repository.

I very much don't think the problem addressed by package management is "well-defined", and I'm not even sure it is coherent in the sense that were the problems different people look to package management to solve all collected, there would be a single workable solution that would address all of them optimally.

stinkytaco2• 12 years ago

The imperfect analogy I've used is the comparison between paints and pencils. They perform similar general functions (placing something on a media) and even use a similar set of tools (a long stick held in the hand). But the end result and even the goal could be totally different (I may want to hang a painting on a wall in a frame and I may want my pencil drawings to be reproduced a book).

It's not perfect, but it helps non-users (i.e. managers) understand that one tool does not fit all.

Doji3• 12 years ago

Nix is attempting to be the solution you're looking for. Look at the nixpkgs repository: 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/

SSLy• 12 years ago

Just one question: how much it takes to run Bumblebee, zsh and Steam on that?

foobarqux2• 12 years ago

How easy is it to build your own packages from, say, the tip of the master branch of github repository? How automated is building the dependencies?

Building packages on Debian like systems is a huge pain. Arch is much better but I need Debian/Ubuntu-like reliability.

paroneayea• 12 years ago

Guix is based on / inspired by Nix, but using Scheme instead of a custom DSL.

VieElm• 12 years ago

curl 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.

kachnuv_ocasek• 12 years ago

are we forever doomed to have multiple package managers for the dot product of [operating system]X[development platform]?

Did you, by any chance, mean Cartesian or direct product?

VLM3• 12 years ago

Don't forget the classic non package maintainer mistake of thinking policy = package file type/format.

Its pretty trivial to "force" a rpm to install on a Debian box. That doesn't mean that magically any of it will follow Debian policy, any of the paths will be correct, any of the dependencies will be correct. But technically files can be thrown onto the filesystem, even if they can't actually be used where they land. And vice versa, if you shove a deb onto a Redhat box.

My biggest "NIH" surprise is GNU has this and the emacs package system and at first glance they have nothing in common. The idea of installing a local copy of Rails or Leiningen off Emacs MELPA is kinda weird. I wonder if emacs twenty...something will use a user level version of this system. That would be interestingly consistent.

taylanub11• 12 years ago

Guix is a big effort at making a purely functional package manager with a large recipe database and all kinds of bells and whistles you want in a full operating system.

Emacs's minimal package manager is to install Elisp libraries (and nothing else) on every platform where Emacs runs, including MS Windows, and you can be happy it does dependency tracking.

The two can't really be compared. Maybe in 10 years Guix will run on all platforms and have its components separated in such a way that it's sensible for Emacs to ship a version of Guix with it for Elisp package management, but don't hold your breath.

So I don't think NIH applies there.

rythie• 12 years ago

I'm not sure it really matters that rpm and deb solve the same problem unless you use different distros.

However npm, gem, pip, composer mostly solve the same problem, but a different one to rpm, in that we want per-project dependancies rather than per-system and want them to be commitable. Also many project combine languages so it would be good if these were combined.

gtirloni• 12 years ago

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

taylanub11• 12 years ago

On top of the Nix daemon certainly, though not Nix as a whole, which has its own package recipe language etc.

davexunit5• 12 years ago

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• 12 years ago

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

sly010• 12 years ago

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).

taylanub11• 12 years ago

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.)

norswap2• 12 years ago

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.

davexunit5• 12 years ago

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.

norswap2• 12 years ago

Thanks! Would it be possible to have a declarative (mostly, I'm interested about multi-versioning and rollbacks) using the .deb / .rpm binaries instead of the sources?

SwellJoe2• 12 years ago

"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.

wtetzner• 12 years ago

Yeah, I think there is metadata missing from those repositories. Nix uniquely identifies a package by hashing all of the inputs that went into building it.

Doji3• 12 years ago

Can you clarify what's wrong with nixpkgs? https://github.com/NixOS/nixpkgs

Granted, it's not yet perfect, but my experience with it so far has left me very impressed.

darklajid2• 12 years ago

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.

taylanub11• 12 years ago

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/

darklajid2• 12 years ago

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.

wtracy• 12 years ago

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.

It's a GNU project. GNU is run by the FSF. The stated goal of the FSF is the eventual elimination of all proprietary software. None of this should come as a surprise.

erkose• 12 years ago

Boot to Guile FTW!

GNU Guix 0.8 released

Related Stories