9 ms·

GNU Guix and GuixSD 0.12.0 released

94 points by rekado 10y ago

CJefferson 10y ago
What's the current position of Nix vs Guix? I tried NixPkgs for a while on a mac about a year ago, but it wasn't really functional (I submitted a half-dozen or so bug reports, several were fixed, but I could see there was a long way to go towards a usefully working system...)
- setra 10y ago
  Nix is used / usable in production. Guix is still pretty far away.
  - deleted 10y ago
    [deleted]
  - rekado 10y ago
    This is not correct. There are at least three big bioinformatics clusters where Guix is used quite successfully (I know of large-scale deployments in Germany, the Netherlands, Australia). One of the deployments with 250 cluster nodes and uncounted GNU+Linux workstations is managed by me. I'd say it is very much usable and in fact used in production.
  - aseipp 10y ago
    I dunno, honestly, if you're capable of using Nix in production, you're capable of using Guix in production almost certainly. I say this as a NixOS maintainer (though I'm relatively dormant these days). I see this as a thing of relative scale. Most people aren't going to run Nix, and in practice, using Nix requires a fair amount of work in practice (often including upstream work). If you're prepared to go through all that, you can probably use Guix in principle, too. (Barring some technicalities, of course, but in general I think this is still true.)
  - davexunit 10y ago
    I use Guix in production to handle a very complicated dependency tree for some private speech recognition software.
- deleted 10y ago
  [deleted]
- Ixiaus 10y ago
  NixOS and nixpkgs is very functional, we use it in production at the company I work for and I also use it as my full-time laptop OS (it's great as a laptop OS).
  - seagreen 10y ago
    Nixpkgs on a mac actually has a really bad reputation as being undersupported. I use NixOS as my main OS though and it works fine.
    - ris 10y ago
      Now that nixpkgs' CI has an osx build, this may well get better.
- vertex-four 10y ago
  nixpkgs for Mac has never really been a priority, what's there is mostly contributed by a handful of people. It's certainly not got the same level of testing and use as e.g. Homebrew. It works wonderfully on Linux - especially under its own distribution, NixOS, which I run on my laptop.
- cwp 10y ago
  Bad timing. Yosemite broke basically everything in nixpkgs-darwin, and it took a long time to get everything fixed. I think that was mainly due to the switch from GCC to Clang and the accompanying toolchain, library and runtime changes. The good news it that the darwin stdenv is now "pure" in the functional sense. It bootstraps using /usr/bin/curl, and symlinks libSystem into the nix store, but otherwise doesn't rely on macOS at all. That makes it much more resilient to changes in macOS and Xcode.
hkjgkjy 10y ago
So scheme is not a purely functional language - I take that to mean Guix will not be as well? It will be more like "Unix as emacs"? Saddens me, because NixOS does all I want - except having s-expressions...
- codemac 10y ago
  The packaging is functional, the scripting is not. Guix still uses a fork of the nix-daemon, and thus derivations. The "functional packages, no side effects" part is still guaranteed in the build & install part. I'd say it's largely what you want, minus probably some GNU-isms in their packaging choices.
- chriswarbo 10y ago
  To be fair, a huge part of the functionality in nixpkgs and NixOS is provided by a ton of bash code, both standalone files and big strings in .nix files. Replacing that with Scheme sounds like a long-term win to me; although in the short term I imagine it makes packaging the contents of a bash-dominated world more frustrating.
- ue_ 10y ago
  NixOS is missing some things for me personally, such as multilib support (I play a game that's only available using 32-bit libraries). Unfortunately I didn't read the documentation and arrived at a situation where I couldn't install my game. I ended up re-installing Debian. It sounds trivial, but unfortunately it was a deal-breaker for me. I really liked the centralised configuration and package management offered by NixOS.
  - ambrop7 10y ago
    It is most definitely possible to plan 32-bit games (at least via Steam) on NixOS. The only things not to forget is to enable "hardware.opengl.driSupport32Bit" and "hardware.pulseaudio.support32Bit". Other than that, just installing the Steam package usually should work.
  - rnhmjoj 10y ago
    It's possible to build FHS environments with multilib [1]. In fact it's what I use to run games and other binary only software: It works perfectly for me. I will share my setup. The expression `games.nix` [2] I use for my games builds a chroot environment with both 32bit and 64bit /lib and a command `start-game` to launch games from the environment. I store them in ~/game/$gamename, with a `$gamename/start.sh`, which is a slightly tweaked or cleaned up version of what it's usually found in gogs and humble bundle games. To use it you do `nix-env -if games.nix` to install it the first time and the just `start-game $gamename` to play. To fiddle around uncomment the trailing `#.env`, run `nix-shell games.nix` and you will land in the chroot environment with everything you need. Most of Nix features like this one are not really documented but fortunately there's github search and folks in #nixos are always available. [1]: https://nixos.org/wiki/FHS_environments https://nixos.org/wiki/FHS_environments [2]: https://hastebin.com/fopelaseyo.nix https://hastebin.com/fopelaseyo.nix
alxmdev 10y ago
> In addition to standard package management features, Guix supports ... unprivileged package management, per-user profiles, ... That sounds really cool. I wish I could install DEB packages just for my local user, without needing root access. I wanted this back at my university's computer lab, and I still want this on my own systems today. These days a lot of people use personal single-user machines, so having it mandatory that packages be installed to the root file system is very restrictive. For example, I have a lot of DEB-packaged games from HumbleBundle, and it feels weird to need admin privileges to install them all across /usr/games, /usr/local/share and all that instead of just a place of my choosing under /home/me.
- agumonkey 10y ago
  Can't say for Guix, but nix can be installed standalone IIRC.
- rekado 10y ago
  You can use Guix as a standalone package manager on pretty much any GNU+Linux distribution. It only affects /gnu, /var/guix, and /etc/guix/acl. It won't touch any global state (e.g. libraries in /usr, or binaries in /bin) and won't use any global state when building packages.
- viraptor 10y ago
  So from a security standpoint, it's actually a good idea to do it like this. I mean, provided the games contact the internet in any way - for purely offline games it doesn't matter. By separating the owner and the account running the game, you can ensure that local write bugs cannot affect the executed code. Not a huge issue, but if you can prevent that at close to no cost, then why not? (ideally we should have simple user-accessible sandboxing instead, but that's not always easy at the moment)
rekado 10y ago
Hi there, I'm the person who made the release announcement and I happen to be one of the two co-maintainers of GNU Guix. I'm using Guix in production at a bioinformatics institute. If you have specific questions about Guix or functional package management feel free to ask me. To try to answer one common question: we aren't on bad terms with the Nix people or compete with them. We are working towards very similar goals, and the underlying paradigm of functional package management (pioneered by Nix) is the same. Members of both projects are involved in efforts towards reproducibility. We have different sensibilities when it comes to the actual implementation and that leads to different design choices.
- Klasiaster 10y ago
  Concerning the HURD support: Is there an image with GNU Hurd instead of the Linux kernel?
  - rekado 10y ago
    There is not (yet). In functional package management we build everything from source until we hit a small set of common bootstrap binaries. In the case of the Hurd it is now possible to bootstrap all of the Hurd system in this manner. This means that we can use Guix as a package manager on top of a Hurd system (e.g. Debian GNU/Hurd), but GuixSD using the Hurd is not yet available. I think it's close, though.
- agumonkey 10y ago
  What about the reproducible build project. Is there some regular communication channel with them ? or just friendly acknowledgement ?
  - davexunit 10y ago
    Guix developers attend the Reproducible Build Summits, among other collaborative efforts.
  - rekado 10y ago
    Both Guix maintainers attended this years reproducible builds summit in Berlin. We're involved with them since before the summit in Athens. At the most recent summit we start a new cross-distro project that I hope we can announce soon.

94 points by rekado 10y ago

What's the current position of Nix vs Guix? I tried NixPkgs for a while on a mac about a year ago, but it wasn't really functional (I submitted a half-dozen or so bug reports, several were fixed, but I could see there was a long way to go towards a usefully working system...)

setra 10y ago
Nix is used / usable in production. Guix is still pretty far away.
- deleted 10y ago
  [deleted]
- rekado 10y ago
  This is not correct. There are at least three big bioinformatics clusters where Guix is used quite successfully (I know of large-scale deployments in Germany, the Netherlands, Australia). One of the deployments with 250 cluster nodes and uncounted GNU+Linux workstations is managed by me. I'd say it is very much usable and in fact used in production.
- aseipp 10y ago
  I dunno, honestly, if you're capable of using Nix in production, you're capable of using Guix in production almost certainly. I say this as a NixOS maintainer (though I'm relatively dormant these days). I see this as a thing of relative scale. Most people aren't going to run Nix, and in practice, using Nix requires a fair amount of work in practice (often including upstream work). If you're prepared to go through all that, you can probably use Guix in principle, too. (Barring some technicalities, of course, but in general I think this is still true.)
- davexunit 10y ago
  I use Guix in production to handle a very complicated dependency tree for some private speech recognition software.
deleted 10y ago
[deleted]
Ixiaus 10y ago
NixOS and nixpkgs is very functional, we use it in production at the company I work for and I also use it as my full-time laptop OS (it's great as a laptop OS).
- seagreen 10y ago
  Nixpkgs on a mac actually has a really bad reputation as being undersupported. I use NixOS as my main OS though and it works fine.
  - ris 10y ago
    Now that nixpkgs' CI has an osx build, this may well get better.
vertex-four 10y ago
nixpkgs for Mac has never really been a priority, what's there is mostly contributed by a handful of people. It's certainly not got the same level of testing and use as e.g. Homebrew. It works wonderfully on Linux - especially under its own distribution, NixOS, which I run on my laptop.
cwp 10y ago
Bad timing. Yosemite broke basically everything in nixpkgs-darwin, and it took a long time to get everything fixed. I think that was mainly due to the switch from GCC to Clang and the accompanying toolchain, library and runtime changes. The good news it that the darwin stdenv is now "pure" in the functional sense. It bootstraps using /usr/bin/curl, and symlinks libSystem into the nix store, but otherwise doesn't rely on macOS at all. That makes it much more resilient to changes in macOS and Xcode.

hkjgkjy 10y ago

So scheme is not a purely functional language - I take that to mean Guix will not be as well? It will be more like "Unix as emacs"? Saddens me, because NixOS does all I want - except having s-expressions...

codemac 10y ago
The packaging is functional, the scripting is not. Guix still uses a fork of the nix-daemon, and thus derivations. The "functional packages, no side effects" part is still guaranteed in the build & install part. I'd say it's largely what you want, minus probably some GNU-isms in their packaging choices.
chriswarbo 10y ago
To be fair, a huge part of the functionality in nixpkgs and NixOS is provided by a ton of bash code, both standalone files and big strings in .nix files. Replacing that with Scheme sounds like a long-term win to me; although in the short term I imagine it makes packaging the contents of a bash-dominated world more frustrating.
ue_ 10y ago
NixOS is missing some things for me personally, such as multilib support (I play a game that's only available using 32-bit libraries). Unfortunately I didn't read the documentation and arrived at a situation where I couldn't install my game. I ended up re-installing Debian. It sounds trivial, but unfortunately it was a deal-breaker for me. I really liked the centralised configuration and package management offered by NixOS.
- ambrop7 10y ago
  It is most definitely possible to plan 32-bit games (at least via Steam) on NixOS. The only things not to forget is to enable "hardware.opengl.driSupport32Bit" and "hardware.pulseaudio.support32Bit". Other than that, just installing the Steam package usually should work.
- rnhmjoj 10y ago
  It's possible to build FHS environments with multilib [1]. In fact it's what I use to run games and other binary only software: It works perfectly for me. I will share my setup. The expression `games.nix` [2] I use for my games builds a chroot environment with both 32bit and 64bit /lib and a command `start-game` to launch games from the environment. I store them in ~/game/$gamename, with a `$gamename/start.sh`, which is a slightly tweaked or cleaned up version of what it's usually found in gogs and humble bundle games. To use it you do `nix-env -if games.nix` to install it the first time and the just `start-game $gamename` to play. To fiddle around uncomment the trailing `#.env`, run `nix-shell games.nix` and you will land in the chroot environment with everything you need. Most of Nix features like this one are not really documented but fortunately there's github search and folks in #nixos are always available. [1]: https://nixos.org/wiki/FHS_environments https://nixos.org/wiki/FHS_environments [2]: https://hastebin.com/fopelaseyo.nix https://hastebin.com/fopelaseyo.nix

alxmdev 10y ago

> In addition to standard package management features, Guix supports ... unprivileged package management, per-user profiles, ... That sounds really cool. I wish I could install DEB packages just for my local user, without needing root access. I wanted this back at my university's computer lab, and I still want this on my own systems today. These days a lot of people use personal single-user machines, so having it mandatory that packages be installed to the root file system is very restrictive. For example, I have a lot of DEB-packaged games from HumbleBundle, and it feels weird to need admin privileges to install them all across /usr/games, /usr/local/share and all that instead of just a place of my choosing under /home/me.

agumonkey 10y ago
Can't say for Guix, but nix can be installed standalone IIRC.
rekado 10y ago
You can use Guix as a standalone package manager on pretty much any GNU+Linux distribution. It only affects /gnu, /var/guix, and /etc/guix/acl. It won't touch any global state (e.g. libraries in /usr, or binaries in /bin) and won't use any global state when building packages.
viraptor 10y ago
So from a security standpoint, it's actually a good idea to do it like this. I mean, provided the games contact the internet in any way - for purely offline games it doesn't matter. By separating the owner and the account running the game, you can ensure that local write bugs cannot affect the executed code. Not a huge issue, but if you can prevent that at close to no cost, then why not? (ideally we should have simple user-accessible sandboxing instead, but that's not always easy at the moment)

rekado 10y ago

Hi there, I'm the person who made the release announcement and I happen to be one of the two co-maintainers of GNU Guix. I'm using Guix in production at a bioinformatics institute. If you have specific questions about Guix or functional package management feel free to ask me. To try to answer one common question: we aren't on bad terms with the Nix people or compete with them. We are working towards very similar goals, and the underlying paradigm of functional package management (pioneered by Nix) is the same. Members of both projects are involved in efforts towards reproducibility. We have different sensibilities when it comes to the actual implementation and that leads to different design choices.

Klasiaster 10y ago
Concerning the HURD support: Is there an image with GNU Hurd instead of the Linux kernel?
- rekado 10y ago
  There is not (yet). In functional package management we build everything from source until we hit a small set of common bootstrap binaries. In the case of the Hurd it is now possible to bootstrap all of the Hurd system in this manner. This means that we can use Guix as a package manager on top of a Hurd system (e.g. Debian GNU/Hurd), but GuixSD using the Hurd is not yet available. I think it's close, though.
agumonkey 10y ago
What about the reproducible build project. Is there some regular communication channel with them ? or just friendly acknowledgement ?
- davexunit 10y ago
  Guix developers attend the Reproducible Build Summits, among other collaborative efforts.
- rekado 10y ago
  Both Guix maintainers attended this years reproducible builds summit in Berlin. We're involved with them since before the summit in Athens. At the most recent summit we start a new cross-distro project that I hope we can announce soon.