7 ms·

GNU Guix 0.8 released

163 points by davexunit 12y ago

taylanub 12y 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/ http://www.gnu.org/software/guix/
Hz8NSD 12y ago
Why are they saying 'Linux-Libre' kernel? It looks like some kind of masturbation.
sergiosgc 12y 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 12y 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.
  - sergiosgc 12y 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).
    - _delirium 12y ago
      Having multiple system package managers coexisting is pretty thorny. If very carefully delineated so they manage completely independent bits of software installed in their own prefixes, I could see it working (with some careful path management). But if you're actually installing/upgrading system software with it, having some mix of apt, rpm, and guix managing your packages sounds like a recipe for pain.
    - davexunit 12y ago
      Much like how many of us use pip, gem, npm, composer, etc. on our Debian/Red Hat/etc. machines, you can also use Guix in the same way. For example, you are deploying a production web application and Guix had newer versions of some dependencies than your stable host system. You could use Guix to create a profile (a collection of installed packages, a bundle in Ruby terminology) that includes those dependencies for your web application to use. It's possible to use pip and friends on a Guix system, too. I personally do all of my Guix hacking on a Debian machine. They play very nicely together.
- akerl_ 12y 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.
gtirloni 12y ago
So it's a Scheme layer on top of Nix?
- taylanub 12y ago
  On top of the Nix daemon certainly, though not Nix as a whole, which has its own package recipe language etc.
- davexunit 12y 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 12y ago
Thank goodness, I was concerned that we didn't have enough package management options!
sly010 12y 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).
- taylanub 12y 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.)
norswap 12y 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.
- davexunit 12y 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.
  - norswap 12y 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?
  - SwellJoe 12y 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.
darklajid 12y 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.
- taylanub 12y 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/ http://www.libreboot.org/
  - darklajid 12y 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.
erkose 12y ago
Boot to Guile FTW!

163 points by davexunit 12y 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/ http://www.gnu.org/software/guix/

Hz8NSD 12y ago

Why are they saying 'Linux-Libre' kernel? It looks like some kind of masturbation.

sergiosgc 12y 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 12y 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.
- sergiosgc 12y 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).
  - _delirium 12y ago
    Having multiple system package managers coexisting is pretty thorny. If very carefully delineated so they manage completely independent bits of software installed in their own prefixes, I could see it working (with some careful path management). But if you're actually installing/upgrading system software with it, having some mix of apt, rpm, and guix managing your packages sounds like a recipe for pain.
  - davexunit 12y ago
    Much like how many of us use pip, gem, npm, composer, etc. on our Debian/Red Hat/etc. machines, you can also use Guix in the same way. For example, you are deploying a production web application and Guix had newer versions of some dependencies than your stable host system. You could use Guix to create a profile (a collection of installed packages, a bundle in Ruby terminology) that includes those dependencies for your web application to use. It's possible to use pip and friends on a Guix system, too. I personally do all of my Guix hacking on a Debian machine. They play very nicely together.
akerl_ 12y 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.

gtirloni 12y ago

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

taylanub 12y ago
On top of the Nix daemon certainly, though not Nix as a whole, which has its own package recipe language etc.
davexunit 12y 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 12y ago

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

sly010 12y 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).

taylanub 12y 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.)

norswap 12y 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.

davexunit 12y 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.
- norswap 12y 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?
- SwellJoe 12y 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.

darklajid 12y 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.

taylanub 12y 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/ http://www.libreboot.org/
- darklajid 12y 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.

erkose 12y ago

Boot to Guile FTW!