Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GNU Guix 0.8.1

savannah.gnu.org

Post reply on HN
Print view View original

31–40 of 41 posts

Re: GNU Guix 0.8.1

#31

Post by knome »

taylanub wrote: post #23
drdaeman wrote: post #13

Everyone talks about advantages. Would love to hear about disadvantages. Not obvious ones (like having to learn configuration language semantics or package missing stuff myself), but things that don't lie down in a plain sight right away and only discovered after a few days, weeks or months of usage. Anyone to share their experiences? (Migrating from Arch to NixOS at the moment, but thought maybe I'd detour a bit and…

From my understanding, the biggest disadvantage to purely functional package management is that you can't just swap out a package in isolation when many others depend on it. If I upgrade a package, I have to upgrade its whole DAG of dependent packages if I want them to use the new version (I could however delay that; they would simply continue to use the old version which hasn't been garbage-collected yet because the…

To save compilation time and bandwidth the authors might be able to make their package dependencies sort of inside out, using a smaller program simply to perform the needed library loading and dependency injection on the core of the software.

Then if you're going between versions, you can avoid having to update the lion's share of code just because the dependencies change.

    jabberwork-1.2
      jabberwock.core-1.6
      jabberwock.apache.interface-0.3
    
    jabberwock-1.3
      jabberwock.core-1.6
      jabberwock.apache-interface-0.4
Instead of having to update all the hefty ".core" modules, you could get away with only updating the hopefully lighter launchers / library loaders and the specific interface code being updated.

Re: GNU Guix 0.8.1

#32

Post by espadrine »

drdaeman wrote: post #13

Everyone talks about advantages. Would love to hear about disadvantages. Not obvious ones (like having to learn configuration language semantics or package missing stuff myself), but things that don't lie down in a plain sight right away and only discovered after a few days, weeks or months of usage. Anyone to share their experiences? (Migrating from Arch to NixOS at the moment, but thought maybe I'd detour a bit and…

1. There are few packages, compared to dpkg.

2. It creates guix-specific users for building purposes.

There really isn't much bad to say about guix. You can even switch to it without giving up on your old package manager. That way, even point 1. isn't an issue. Of course, 2. isn't really an issue in itself; `cat /etc/passwd` already contains a lot of users whose purpose I know little about.

Re: GNU Guix 0.8.1

#33

Post by ape4 »

chriswarbo wrote: post #8
Zardoz84 wrote: post #3

Could someone explain in a simple way, why this is better that using, for example, apt-get ?

Guix is based on Nix, so the following applies to both. apt-get allows at most one version of a package to be installed at a time; if you want two versions, you need to ask the maintainers to split the package into two. Guix doesn't suffer this problem; packages are given an ID based on a hash of their contents and dependencies, so two versions will happily sit side-by-side. An "update" is treated more like installin…

Some nice ideas there. Of course, in the real world we have our distro's package manager as a given. So I wonder how an additional package manager would work with it.

Re: GNU Guix 0.8.1

#34

Post by agumonkey »

loevborg wrote: post #29

I tried out nixos (the complete distro based on nix) on the weekend -- it's not saying too much that it's a revelation. I can see myself completely switching for my development machines and possibly for servers as well. The amazing thing is that the whole set up of your linux machine is encaptulated in one declarative text file (that you can put in version control). Give it a try by installing it using VirtualBox: ht…

Reminds me of archlinux early days when one of their main arguments was that configuration was done in a single file (as BSDs). Nix is like a typechecked version of that.

Re: GNU Guix 0.8.1

#35

Post by pmahoney »

chriswarbo wrote: post #8
Zardoz84 wrote: post #3

Could someone explain in a simple way, why this is better that using, for example, apt-get ?

Guix is based on Nix, so the following applies to both. apt-get allows at most one version of a package to be installed at a time; if you want two versions, you need to ask the maintainers to split the package into two. Guix doesn't suffer this problem; packages are given an ID based on a hash of their contents and dependencies, so two versions will happily sit side-by-side. An "update" is treated more like installin…

> if you want two versions, you need to ask the maintainers to split the package into two

This is still true in Nix (and Guix I assume), although there are facilities for overriding, say, just the source tarball (to a different version) without needing to create a whole new Nix package (and worst case, creating a whole new Nix package is an order of magnitude easier than creating a Debian package in my experience).

In the "nixpkgs" set of packages, a few packages come in multiple versions (gcc, autotools come to mind), but most are only available in a single version.

Of course, once you've managed to install package-version-1, even as nixpkgs moves to version 2, 3, and so on, your version 1 can remain installed forever if you wish, and nothing can swap out the libpng, or libc or whatever it may depend on, since as you say all these can live side-by-side with other versions of themselves.

Re: GNU Guix 0.8.1

#36

Post by agumonkey »

Nix and Guix begin to have some momentum, it's a joy to see. I'm now wondering if that momentum will revive.. Hurd development. That's right, I said it.

Re: GNU Guix 0.8.1

#37

Post by housel »

To try the downloaded USB image in VirtualBox, first decompress the .xz file and then run

    vboxmanage convertfromraw ~/Downloads/gsd-usb-install-0.8.1.i686-linux gsd-install.vdi --format vdi
The resulting VDI file can then be attached to a VirtualBox machine as a primary IDE disk. Be sure to enable PAE/NX in the System settings.

Re: GNU Guix 0.8.1

#38

Post by elementai »

Zardoz84 wrote: post #3

Could someone explain in a simple way, why this is better that using, for example, apt-get ?

It's better because given the same input you always get the same output. For example, in Gentoo when one builds a package the final result depends on what's been built before. Or (killer feature for configuration management):

Suppose one has a resource for file in Puppet

file "blah" do source "yada" end

if you erase that resource, the file still stays there. With Nix/Guix anything not defined in configuration isn't present at all on system.

Another feature : one can install, for example, different versions of Python/PyPy/etc locally using the same package manager. Local and system-wide package share the same underlying files and don't interfere.

Rollbacks, very easy way to restore system packages/configs to previous working state.

Re: GNU Guix 0.8.1

#39

Post by aidenn0 »

ArneBab wrote: post #25
dangirsh wrote: post #4

Awesome to see this here! I've been using Nix/Nixos (which Guix is heavily based on) on my personal laptop for several months now. I'll never look back from the purely declarative system configuration - I finally feel like I have full control of my machine's state. It looks like Guix provides a significantly more expressive interface with Scheme than Nixos does with Nix expressions. IIRC, there's also better integrat…

I ran Guix as user-specific overlay on my Gentoo box for some time. It was pretty neat and I thought about using it for cross-distro deployment of libraries I need for development. About half a year ago I ran into problems with updating and did not have the time to fix it (stuff simply did not build - I did not try the --with-source trick). I hope that a reinstall with the new version fixes that. What sold it to me w…

Do you have a specific guide you followed for trying that? I've been using gentoo for a while, and this sounds like a good way to try guix or nix.

Re: GNU Guix 0.8.1

#40

Post by taylanub »

knome wrote: post #31
taylanub wrote: post #23

Earlier quoted context omitted.

From my understanding, the biggest disadvantage to purely functional package management is that you can't just swap out a package in isolation when many others depend on it. If I upgrade a package, I have to upgrade its whole DAG of dependent packages if I want them to use the new version (I could however delay that; they would simply continue to use the old version which hasn't been garbage-collected yet because the…

To save compilation time and bandwidth the authors might be able to make their package dependencies sort of inside out, using a smaller program simply to perform the needed library loading and dependency injection on the core of the software. Then if you're going between versions, you can avoid having to update the lion's share of code just because the dependencies change. jabberwork-1.2 jabberwock.core-1.6 jabberwoc…

I also started thinking things along the lines of that when I first looked into how Guix does things, but after annoying the developers a little (many thanks to Ludovic's patience) I've come to understand that things like that beat the whole purpose of having pure packages not only in binary content but also in run-time behavior.

Basically, reproducible builds are a red herring here. A package's identity is not only the hash of its byte-by-byte contents, it also includes ("closes over") the identities of all packages it "references" (depends on), meaning it will always have the exact same run-time behavior everywhere because even all its dependencies count as part of its identity.

Post reply on HN