9 ms·

GNU Guix 0.9.0 released – Functional package manager and distribution

171 points by rekado 11y ago

mbrock 11y ago
I'm intrigued by Guix but right now I'm invested in NixOS. Finally I've learned most of the Nix language, which is elegant and quite clever, but it was a little bit of a hurdle. Scheme is more familiar and easy to learn, I think, and I can easily see macros as being extremely useful for system configuration. I'm fully convinced that the Nix/Guix style of package management and system configuration is Teh Future. Anyone who isn't drinking koolaid on that bandwagon yet should hop on and check it out.
- nextos 11y ago
  I also love Nix/Guix, but I have the feeling the future will sadly be giving us container-ized apps systemd-style. Much worse security and sysadmin-wise.
  - civodul 11y ago
    The future is what we make it. :-)
    - a3n 11y ago
      Or is the future what we made it?
  - mbrock 11y ago
    I launch containers from systemd in NixOS. My future is a mixed bag.
    - nextos 11y ago
      Containers are cool for big things. But imagine every single program stuck inside a container without proper management tools to track dependencies. Now imagine a heartbleed-like scenario where you need to patch a big security hole ASAP. With containers you'd have a hard time.
      - tolle 11y ago
        Depends on how stuff is implemented no? You change a library, you do a rebuild of all packages that uses that library, the user downloads package deltas and the filesystem does deduplication so the same file is used in all the containers. Would only cause a problem with packages from third party sources. But thats a possible problem now already?
      - kefka 11y ago
        Depends how those "containers" interact with the system at large. In the Windows world, it's common to have the libraries you need stored in ~/Program Files/Program_name/ . Now, each program dumps in its program home the library, only because it cannot guarantee the library would be in the system. In Linux, we deal with having different major versions of said library. nd minor versions are clobbered by major. So when someone who wrote stuff using python 2.7.2 and 2.7.3(bugfixes) comes out, there is invariably something that is broken. A container that encompasses "Python", and holds all the versions would be a great deal. Same with other programs. They could interact, but their install and environment would be encompassed as a complete "Python", regardless of version or bugfix.
        JupiterMoon 11y ago
        You are describing NixOS/Guix rather than containers.
      - mbrock 11y ago
        Yeah, I don't want to run every single program in a container... and I don't plan to. That said, containers have their advantages even in that security scenario. For example, once I was running into obscure segfaults that seemed related to some interaction between Sidekiq a particular Ruby version. Once I figured out the fix, I just changed the top line of a couple of Dockerfiles to change their Ruby versions. Generally also containers are built on existing Linux distributions and use their packages. I still haven't figured out exactly what I want to do but my vague future plan involves containers bootstrapped from Nix expressions. That's just to get a level of indirection to abstract away NixOS so I can run app services on whatever distribution.
      - 11y ago
- zeckalpha 11y ago
  You can combine the two: https://wingolog.org/archives/2015/08/04/developing-v8-with-guix https://wingolog.org/archives/2015/08/04/developing-v8-with-...
- Ankaios 11y ago
  I'm intrigued, too, but I'm planning on drinking the Kool-Aid only after someone figures out how to sanely include support for late binding of dependencies. If that happens—allowing security updates without explicit action for every package—I think I'll be in.
matthewbauer 11y ago
Does anyone else feel like they're just duplicating all the work done by Nix? I guess there's nothing wrong with multiple functional package managers. It just seems wrong to reject Nix just because it allows unfree software.
- mbrock 11y ago
  I feel like all the Linux distributions are duplicating work. And all the language-specific package managers. If everyone could just get along and work on the same thing... Well, they're not going to. Guix has a different language, different core values, different allegiances, probably different long-term plans. If I were to start thinking more seriously about the wasted effort in duplicated definitions of packages, I would probably end up thinking about using RDF linked data to define software dependencies and capabilities. Then you could generate Nix expressions, Guix things, RPMs, Docker containers, or what have you. The declarative model of Nix/Guix should work well with something like that.
  - digi_owl 11y ago
    It may help to look at it akin to evolution.
    - emj 11y ago
      If only more people mutated thei package managers..
  - sparkie 11y ago
    I hope you're not thinking of using Turtle or XML for defining packages in this system, as I would need to fork your project and define my packages in JSON-LD. I would also need to submit a proposal to the w3c to include 'rdf:SchemeLiteral' into the standard for compatiblity with existing infrastructure.
    - mbrock 11y ago
      Luckily the W3C people have been very careful to make sure that Turtle, XML, and JSON-LD are all interoperable, so I don't mind your fork, if the JSON syntax is more appropriate for your needs.
weavie 11y ago
I'm not sure I fully understand what Guix is. Is it a replacement for pacman / apt-get etc..?
- rekado 11y ago
  From the announcement: > GNU Guix is a functional package manager for the GNU system. The Guix System Distribution or GuixSD is an advanced distribution of the GNU system that relies on GNU Guix and respects the user's freedom. > In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. Guix uses low-level mechanisms from the Nix package manager, except that packages are defined as native Guile modules, using extensions to the Scheme language. GuixSD offers a declarative approach to operating system configuration management, and is highly customizable and hackable. You might also find this little poster helpful: http://elephly.net/downies/poster-v3.pdf http://elephly.net/downies/poster-v3.pdf
- agumonkey 11y ago
  A different approach at package management. Inspire by functional programming. Installing a package defines a new system generation shadowing the previous one. The older generation aren't removed. You can thus have multiple version of a package on disk and jump back and forth between generations.
  - michaelsbradley 11y ago
    Is there a recommended approach for using Guix along with VMs or containers (in the most general sense)? My day-to-day machine is a mac laptop; but for my software development work, I have been using docker-machine, docker-compose and docker server/client to configure, spin up, wire together, and tear down repeatable Linux environments, which run inside VirtualBox on my mac. I'm interested in what a comparable (in a broad sense) workflow might look like with Guix, but I'm not quite sure where/how to start.
    - rekado 11y ago
listic 11y ago
What does "GNU" icon in the packages list [1] stand for? [1] http://www.gnu.org/software/guix/packages/ http://www.gnu.org/software/guix/packages/
- sepeth 11y ago
  They are part of the GNU system. http://www.gnu.org/help/evaluation.html http://www.gnu.org/help/evaluation.html Btw, some projects are hosted on nongnu.org domain, those are not part of the GNU system.
  - mikegerwitz 11y ago
    And we'd love to see more! Information and instructions for submitting your project are in the link above. (I'm part of the GNU evaluation team.)
- vacri 11y ago
  Mouseover says "Part of GNU" - part of the GNU project, so managed by GNU.
- deleted 11y ago
  [deleted]
rkuska 11y ago
Looking at the package list I can see: python-sphinx and python2-sphinx From this I conclude that python-sphinx is python3 version of sphinx right? Do you think that's sane (from user experience point of view) assuming that /usr/bin/python should point to python2? https://www.python.org/dev/peps/pep-0394/ https://www.python.org/dev/peps/pep-0394/
- davexunit 11y ago
  Yes, python-sphinx is the Python 3 version of Sphinx. Note that Guix does not conform to the FHS, and thus has no /usr directory.
  - rkuska 11y ago
    Yet anyway as a python user I would expect to receive python2 version when installing python-sphinx. In Fedora we have (most recent change in packaging guidelines): Source rpm: python-foo which generates binary rpms: python2-foo and python3-foo where python2-foo has virtual provides for python-foo, once Python3 will become THE default python by the upstream merits we will change python-foo provides to python3-foo package.
yepguy 11y ago
Does Guix have (the equivalent of) package signing? Last I checked Nix wasn't very concerned about this.
- sparkie 11y ago
  Package signing is relatively useless. All it tells you is that a given person signed a binary, but it does nothing to tell you whether the contents of that binary match the source code (and currently, no such tooling exists to perform this verification.) Nix and Guix on the other hand, are primarily source code based. Packages are given an identity which is a secure hash of their source code and complete build instructions. This makes it infeasible to make any modifications to the source code, as intentionally malicious modifications would result in a different hash, and source code changes are detectable in commit logs. While binary versions of these packages are available via Hydra, one can always use the source code versions if they're worried about security. Long term goals for Nix and Guix are to have completely reproducible binary packages, whereby we can assert that given a package definition, the resulting binaries will be bit identical when compiled from different machines. Instead of relying on a hash of the source code, we'll have a hash of binaries matching a package definition. And when we get to this stage, we can completely stop worrying about who packaged a piece of software, because the result should be the same regardless. Instead, we can start looking at an alternative model of distribution where several independant parties, chosen by the user, reach a consensus on the binary hash which corresponds to a given package definition, and have that package retreivable through a distributed network (a DHT).
  - vfclists 11y ago
    Does this also include the compiler and versions of the compiler used, assuming that build and compiler options are identical?
- civodul 11y ago
  The "substitutes" (pre-built binaries) are signed: http://www.gnu.org/software/guix/manual/html_node/Substitutes.html http://www.gnu.org/software/guix/manual/html_node/Substitute... . We use a SPKI-style PKI: http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-archive.html http://www.gnu.org/software/guix/manual/html_node/Invoking-g... . The package recipes themselves are in a Git repo, which has signed release tags (but not signed commits.) Lastly, the new 'guix challenge' command helps users check whether binaries provided by a server genuinely come from the source it claims to have built. See http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-challenge.html http://www.gnu.org/software/guix/manual/html_node/Invoking-g... .
ilurk 11y ago
I'm just trying to get all of this "package management" sorted out. So could anyone please comment. Guix is a package manager that is currently limited at 2619 packages [1] NixOS is a GNU/Linux distro which uses the Nix package manager (makes package management reliable and reproducible. It provides atomic upgrades and rollbacks, side-by-side installation of multiple versions of a package, multi-user package management and easy setup of build environments) and currently provides 11630 packages [2] Ansible/Chef/Puppet is a package manager oriented at deployment at multiple nodes, which works with multiple GNU/Linux distros. Vagrant is a package manager. A wrapper around Ansible/Chef/Puppet. My understanding is that I can fix all problems with NixOS, with the caveat that I'm limited to NixOS, so I can't Nix on a Debian or Ubuntu or Redhat. Assuming the adoption of NixOS isn't a constraint, why should I bother to learn Ansible/Chef/Puppet and Vagrant? And if Ansible/Chef/Puppet are still worth learning (and please comment why) besides NixOS, is there any reason to learn Vagrant as well? [1] http://www.gnu.org/software/guix/packages/ http://www.gnu.org/software/guix/packages/ [2] https://nixos.org/nixos/packages.html https://nixos.org/nixos/packages.html
- fineIllregister 11y ago
  You can run Nix on Arch. I think you can run it on other operating systems. https://aur.archlinux.org/packages/nix/ https://aur.archlinux.org/packages/nix/
  - codemac 11y ago
    You can run Guix on Arch as well (it's what I do)
- ris 11y ago
  "why should I bother to learn Ansible/Chef/Puppet and Vagrant" Nix-y people would argue that you shouldn't. And I'd fully agree with them. They're horribly overblown glorified shell scripts.
- narrowrail 11y ago
  It seems like you need to do some more reading for full comprehension (and I am a novice), but real quick: Ansible/Chef/Puppet are for configuration management and Vagrant is for managing VMs (normally on a local machine, for development). These tools may provide some overlap from a 'solutions' perspective, but they achieve the result via a different approach. ETA: Apparently, Guix is for both package management and config, which is really interesting. This might be the excuse I needed to learn Scheme.
Snesker 11y ago
call me when it's production ready. (around version 5)

171 points by rekado 11y ago

I'm intrigued by Guix but right now I'm invested in NixOS. Finally I've learned most of the Nix language, which is elegant and quite clever, but it was a little bit of a hurdle. Scheme is more familiar and easy to learn, I think, and I can easily see macros as being extremely useful for system configuration. I'm fully convinced that the Nix/Guix style of package management and system configuration is Teh Future. Anyone who isn't drinking koolaid on that bandwagon yet should hop on and check it out.

nextos 11y ago
I also love Nix/Guix, but I have the feeling the future will sadly be giving us container-ized apps systemd-style. Much worse security and sysadmin-wise.
- civodul 11y ago
  The future is what we make it. :-)
  - a3n 11y ago
    Or is the future what we made it?
- mbrock 11y ago
  I launch containers from systemd in NixOS. My future is a mixed bag.
  - nextos 11y ago
    Containers are cool for big things. But imagine every single program stuck inside a container without proper management tools to track dependencies. Now imagine a heartbleed-like scenario where you need to patch a big security hole ASAP. With containers you'd have a hard time.
    - tolle 11y ago
      Depends on how stuff is implemented no? You change a library, you do a rebuild of all packages that uses that library, the user downloads package deltas and the filesystem does deduplication so the same file is used in all the containers. Would only cause a problem with packages from third party sources. But thats a possible problem now already?
    - kefka 11y ago
      Depends how those "containers" interact with the system at large. In the Windows world, it's common to have the libraries you need stored in ~/Program Files/Program_name/ . Now, each program dumps in its program home the library, only because it cannot guarantee the library would be in the system. In Linux, we deal with having different major versions of said library. nd minor versions are clobbered by major. So when someone who wrote stuff using python 2.7.2 and 2.7.3(bugfixes) comes out, there is invariably something that is broken. A container that encompasses "Python", and holds all the versions would be a great deal. Same with other programs. They could interact, but their install and environment would be encompassed as a complete "Python", regardless of version or bugfix.
      - JupiterMoon 11y ago
        You are describing NixOS/Guix rather than containers.
    - mbrock 11y ago
      Yeah, I don't want to run every single program in a container... and I don't plan to. That said, containers have their advantages even in that security scenario. For example, once I was running into obscure segfaults that seemed related to some interaction between Sidekiq a particular Ruby version. Once I figured out the fix, I just changed the top line of a couple of Dockerfiles to change their Ruby versions. Generally also containers are built on existing Linux distributions and use their packages. I still haven't figured out exactly what I want to do but my vague future plan involves containers bootstrapped from Nix expressions. That's just to get a level of indirection to abstract away NixOS so I can run app services on whatever distribution.
    - 11y ago
zeckalpha 11y ago
You can combine the two: https://wingolog.org/archives/2015/08/04/developing-v8-with-guix https://wingolog.org/archives/2015/08/04/developing-v8-with-...
Ankaios 11y ago
I'm intrigued, too, but I'm planning on drinking the Kool-Aid only after someone figures out how to sanely include support for late binding of dependencies. If that happens—allowing security updates without explicit action for every package—I think I'll be in.

matthewbauer 11y ago

Does anyone else feel like they're just duplicating all the work done by Nix? I guess there's nothing wrong with multiple functional package managers. It just seems wrong to reject Nix just because it allows unfree software.

mbrock 11y ago
I feel like all the Linux distributions are duplicating work. And all the language-specific package managers. If everyone could just get along and work on the same thing... Well, they're not going to. Guix has a different language, different core values, different allegiances, probably different long-term plans. If I were to start thinking more seriously about the wasted effort in duplicated definitions of packages, I would probably end up thinking about using RDF linked data to define software dependencies and capabilities. Then you could generate Nix expressions, Guix things, RPMs, Docker containers, or what have you. The declarative model of Nix/Guix should work well with something like that.
- digi_owl 11y ago
  It may help to look at it akin to evolution.
  - emj 11y ago
    If only more people mutated thei package managers..
- sparkie 11y ago
  I hope you're not thinking of using Turtle or XML for defining packages in this system, as I would need to fork your project and define my packages in JSON-LD. I would also need to submit a proposal to the w3c to include 'rdf:SchemeLiteral' into the standard for compatiblity with existing infrastructure.
  - mbrock 11y ago
    Luckily the W3C people have been very careful to make sure that Turtle, XML, and JSON-LD are all interoperable, so I don't mind your fork, if the JSON syntax is more appropriate for your needs.

weavie 11y ago

I'm not sure I fully understand what Guix is. Is it a replacement for pacman / apt-get etc..?

rekado 11y ago
From the announcement: > GNU Guix is a functional package manager for the GNU system. The Guix System Distribution or GuixSD is an advanced distribution of the GNU system that relies on GNU Guix and respects the user's freedom. > In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. Guix uses low-level mechanisms from the Nix package manager, except that packages are defined as native Guile modules, using extensions to the Scheme language. GuixSD offers a declarative approach to operating system configuration management, and is highly customizable and hackable. You might also find this little poster helpful: http://elephly.net/downies/poster-v3.pdf http://elephly.net/downies/poster-v3.pdf
agumonkey 11y ago
A different approach at package management. Inspire by functional programming. Installing a package defines a new system generation shadowing the previous one. The older generation aren't removed. You can thus have multiple version of a package on disk and jump back and forth between generations.
- michaelsbradley 11y ago
  Is there a recommended approach for using Guix along with VMs or containers (in the most general sense)? My day-to-day machine is a mac laptop; but for my software development work, I have been using docker-machine, docker-compose and docker server/client to configure, spin up, wire together, and tear down repeatable Linux environments, which run inside VirtualBox on my mac. I'm interested in what a comparable (in a broad sense) workflow might look like with Guix, but I'm not quite sure where/how to start.
  - rekado 11y ago

listic 11y ago

What does "GNU" icon in the packages list [1] stand for? [1] http://www.gnu.org/software/guix/packages/ http://www.gnu.org/software/guix/packages/

sepeth 11y ago
They are part of the GNU system. http://www.gnu.org/help/evaluation.html http://www.gnu.org/help/evaluation.html Btw, some projects are hosted on nongnu.org domain, those are not part of the GNU system.
- mikegerwitz 11y ago
  And we'd love to see more! Information and instructions for submitting your project are in the link above. (I'm part of the GNU evaluation team.)
vacri 11y ago
Mouseover says "Part of GNU" - part of the GNU project, so managed by GNU.
deleted 11y ago
[deleted]

rkuska 11y ago

Looking at the package list I can see: python-sphinx and python2-sphinx From this I conclude that python-sphinx is python3 version of sphinx right? Do you think that's sane (from user experience point of view) assuming that /usr/bin/python should point to python2? https://www.python.org/dev/peps/pep-0394/ https://www.python.org/dev/peps/pep-0394/

davexunit 11y ago
Yes, python-sphinx is the Python 3 version of Sphinx. Note that Guix does not conform to the FHS, and thus has no /usr directory.
- rkuska 11y ago
  Yet anyway as a python user I would expect to receive python2 version when installing python-sphinx. In Fedora we have (most recent change in packaging guidelines): Source rpm: python-foo which generates binary rpms: python2-foo and python3-foo where python2-foo has virtual provides for python-foo, once Python3 will become THE default python by the upstream merits we will change python-foo provides to python3-foo package.

yepguy 11y ago

Does Guix have (the equivalent of) package signing? Last I checked Nix wasn't very concerned about this.

sparkie 11y ago
Package signing is relatively useless. All it tells you is that a given person signed a binary, but it does nothing to tell you whether the contents of that binary match the source code (and currently, no such tooling exists to perform this verification.) Nix and Guix on the other hand, are primarily source code based. Packages are given an identity which is a secure hash of their source code and complete build instructions. This makes it infeasible to make any modifications to the source code, as intentionally malicious modifications would result in a different hash, and source code changes are detectable in commit logs. While binary versions of these packages are available via Hydra, one can always use the source code versions if they're worried about security. Long term goals for Nix and Guix are to have completely reproducible binary packages, whereby we can assert that given a package definition, the resulting binaries will be bit identical when compiled from different machines. Instead of relying on a hash of the source code, we'll have a hash of binaries matching a package definition. And when we get to this stage, we can completely stop worrying about who packaged a piece of software, because the result should be the same regardless. Instead, we can start looking at an alternative model of distribution where several independant parties, chosen by the user, reach a consensus on the binary hash which corresponds to a given package definition, and have that package retreivable through a distributed network (a DHT).
- vfclists 11y ago
  Does this also include the compiler and versions of the compiler used, assuming that build and compiler options are identical?
civodul 11y ago
The "substitutes" (pre-built binaries) are signed: http://www.gnu.org/software/guix/manual/html_node/Substitutes.html http://www.gnu.org/software/guix/manual/html_node/Substitute... . We use a SPKI-style PKI: http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-archive.html http://www.gnu.org/software/guix/manual/html_node/Invoking-g... . The package recipes themselves are in a Git repo, which has signed release tags (but not signed commits.) Lastly, the new 'guix challenge' command helps users check whether binaries provided by a server genuinely come from the source it claims to have built. See http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-challenge.html http://www.gnu.org/software/guix/manual/html_node/Invoking-g... .

ilurk 11y ago

I'm just trying to get all of this "package management" sorted out. So could anyone please comment. Guix is a package manager that is currently limited at 2619 packages [1] NixOS is a GNU/Linux distro which uses the Nix package manager (makes package management reliable and reproducible. It provides atomic upgrades and rollbacks, side-by-side installation of multiple versions of a package, multi-user package management and easy setup of build environments) and currently provides 11630 packages [2] Ansible/Chef/Puppet is a package manager oriented at deployment at multiple nodes, which works with multiple GNU/Linux distros. Vagrant is a package manager. A wrapper around Ansible/Chef/Puppet. My understanding is that I can fix all problems with NixOS, with the caveat that I'm limited to NixOS, so I can't Nix on a Debian or Ubuntu or Redhat. Assuming the adoption of NixOS isn't a constraint, why should I bother to learn Ansible/Chef/Puppet and Vagrant? And if Ansible/Chef/Puppet are still worth learning (and please comment why) besides NixOS, is there any reason to learn Vagrant as well? [1] http://www.gnu.org/software/guix/packages/ http://www.gnu.org/software/guix/packages/ [2] https://nixos.org/nixos/packages.html https://nixos.org/nixos/packages.html

fineIllregister 11y ago
You can run Nix on Arch. I think you can run it on other operating systems. https://aur.archlinux.org/packages/nix/ https://aur.archlinux.org/packages/nix/
- codemac 11y ago
  You can run Guix on Arch as well (it's what I do)
ris 11y ago
"why should I bother to learn Ansible/Chef/Puppet and Vagrant" Nix-y people would argue that you shouldn't. And I'd fully agree with them. They're horribly overblown glorified shell scripts.
narrowrail 11y ago
It seems like you need to do some more reading for full comprehension (and I am a novice), but real quick: Ansible/Chef/Puppet are for configuration management and Vagrant is for managing VMs (normally on a local machine, for development). These tools may provide some overlap from a 'solutions' perspective, but they achieve the result via a different approach. ETA: Apparently, Guix is for both package management and config, which is really interesting. This might be the excuse I needed to learn Scheme.

Snesker 11y ago

call me when it's production ready. (around version 5)