3 ms·

I have heard of Guix, and I am quite excited about it. I am just waiting for it to catch up for me. In this regard, Nix and NixOS are also fascinating. Maybe

by 616c 13y ago

I have heard of Guix, and I am quite excited about it. I am just waiting for it to catch up for me. In this regard, Nix and NixOS are also fascinating. Maybe I am the last of the Linux kids using Stow, and I like it because it makes me worry less about source installations on my computer. It would be great to see Guix build on this idea. As much as I would love to transition to a new Linux distro, I would love even more having a ~/guix or ~/.guix path with different builds. If I really mess up my computer, I can delete this folder and all those binaries and the appropriate symlinks go away. This is what worries me about NixOS. Eventually with Stow NixOS, and other declarative package management you hit a little where you cannot outhink your dependenices. If your root is nixos and everything else is symlinked, that sounds hard for a mere mortal like me to debug. http://nixos.org/nixos/screenshots/nixos-terminals.png http://nixos.org/nixos/screenshots/nixos-terminals.png

sparkie 13y ago
You can already do that with guix and nix - they can run atop your distro and simply create new application directories where you want them. The actual builds are in /nix/store (or /guix/store), and symlinked from whatever profile you want (you can have several). It's also gonna be pretty hard to screw up your computer too, since multiple versions of software can be installed without problems, and you can perform safe rollbacks. The store is read-only and shouldn't be hard deleted by mortals anyway, but you should perform all the deletions through nix/guix. The advantage of building an OS out of nix/guix is that you generally don't want to perform any kind of change to a system which is not reproducible (ie, no "hidden knowledge" that went into configuring a system) - so that if your system does ever break due to some unforeseen circumstances, you have a declarative configuration of the system in its entirety before it broke, and you can rebuild the system in a few commands. It's probably worth abandoning the idea that applications (or symlinks) should go into /usr/bin or anywhere else - the need for symlinks exists mostly for compatibility, but from the POV of a package or configuration, you should only refer to a specific identity of a derivation in the store. For example, if I wanted a shortcut of say, emacs on my desktop - I could have a "desktop_icons.scm" package in which I define them - and rather than pointing to some /usr/bin/emacs, I would point to some "emacs" variable (referring to a specific version) imported from the emacs package, and append the relative bin path. Then if I change the version "emacs" points to, the desktop icon will be updated too.
- davexunit 13y ago
  Nitpick: Guix uses /gnu/store now. :)

by 616c 13y ago

sparkie 13y ago

You can already do that with guix and nix - they can run atop your distro and simply create new application directories where you want them. The actual builds are in /nix/store (or /guix/store), and symlinked from whatever profile you want (you can have several). It's also gonna be pretty hard to screw up your computer too, since multiple versions of software can be installed without problems, and you can perform safe rollbacks. The store is read-only and shouldn't be hard deleted by mortals anyway, but you should perform all the deletions through nix/guix. The advantage of building an OS out of nix/guix is that you generally don't want to perform any kind of change to a system which is not reproducible (ie, no "hidden knowledge" that went into configuring a system) - so that if your system does ever break due to some unforeseen circumstances, you have a declarative configuration of the system in its entirety before it broke, and you can rebuild the system in a few commands. It's probably worth abandoning the idea that applications (or symlinks) should go into /usr/bin or anywhere else - the need for symlinks exists mostly for compatibility, but from the POV of a package or configuration, you should only refer to a specific identity of a derivation in the store. For example, if I wanted a shortcut of say, emacs on my desktop - I could have a "desktop_icons.scm" package in which I define them - and rather than pointing to some /usr/bin/emacs, I would point to some "emacs" variable (referring to a specific version) imported from the emacs package, and append the relative bin path. Then if I change the version "emacs" points to, the desktop icon will be updated too.

davexunit 13y ago
Nitpick: Guix uses /gnu/store now. :)