4 ms·

> Guix started as a fork of Nix This is repeated often but it is an unfortunate misunderstanding. One self-contained component of Nix was used unaltered in Gu

by rekado 6y ago

> Guix started as a fork of Nix This is repeated often but it is an unfortunate misunderstanding. One self-contained component of Nix was used unaltered in Guix: the nix-daemon. Everything else but the daemon (and that's a lot) is a completely independent implementation of the same principles that were first demonstrated in Nix: functional package management. Why reuse the daemon? Because it could be done. The daemon takes very low level build instructions ("derivations") and arranges for them to be executed in an isolated environment. In Guix derivations are generated through compilation of higher level concepts that as such have no correspondence in Nix. The common ground is the format of the derivation, which has only been modified occasionally to better suit our differing needs.

georgyo 6y ago
My point was more than guix and nix could both write to the same store using a single daemon compatible with both in the future. Ensuring some cooperation between the two going forward. That currently isn't possible, but would be nice. I imagine it could only work for packages, not for system configuration. But that still would be a huge win.
- rekado 6y ago
  System configuration is also just another store item, really. The current development, however, is to move away from the old nix-daemon and to (slowly) finish its replacement that reuses all of the other existing Guix features for process isolation and building. This is desirable as there are minor annoying differences between the build environment spawned by the C++ daemon and the environment one would get using "guix environment --container". Unifying this by simply using Guile on both sides of the divide (build side vs host side) would allow for more code reuse within Guix and unlock a few features. It's not a high priority because the modified nix-daemon works fine for now, but a CS student is moving forward with the Guile daemon as a university project now. So the dream of sharing the same daemon may not be realistic. I think that this is not a big deal, because the daemon really should serve the project and as the needs of the two projects diverge so do their respective daemons.
  - georgyo 6y ago
    System configuration is just another store item, but symlinked, copied, or referenced by other places outside the store as well. Such as systemd services. You're likely right though that compatibility between the two projects will continue diverge. My true dream was that vendors wouldn't have to build for Snap, Flatpak, Guix, and Nix. They could just use either Guix or Nix and have something usable by either user base. In the end the outputs are just writing stuff to the store. But the fact that the store paths are already different would make it a huge migration for that path to change in the future, and unlikely to ever happen. Still, I can dream.

by rekado 6y ago

georgyo 6y ago

My point was more than guix and nix could both write to the same store using a single daemon compatible with both in the future. Ensuring some cooperation between the two going forward. That currently isn't possible, but would be nice. I imagine it could only work for packages, not for system configuration. But that still would be a huge win.

rekado 6y ago
System configuration is also just another store item, really. The current development, however, is to move away from the old nix-daemon and to (slowly) finish its replacement that reuses all of the other existing Guix features for process isolation and building. This is desirable as there are minor annoying differences between the build environment spawned by the C++ daemon and the environment one would get using "guix environment --container". Unifying this by simply using Guile on both sides of the divide (build side vs host side) would allow for more code reuse within Guix and unlock a few features. It's not a high priority because the modified nix-daemon works fine for now, but a CS student is moving forward with the Guile daemon as a university project now. So the dream of sharing the same daemon may not be realistic. I think that this is not a big deal, because the daemon really should serve the project and as the needs of the two projects diverge so do their respective daemons.
- georgyo 6y ago
  System configuration is just another store item, but symlinked, copied, or referenced by other places outside the store as well. Such as systemd services. You're likely right though that compatibility between the two projects will continue diverge. My true dream was that vendors wouldn't have to build for Snap, Flatpak, Guix, and Nix. They could just use either Guix or Nix and have something usable by either user base. In the end the outputs are just writing stuff to the store. But the fact that the store paths are already different would make it a huge migration for that path to change in the future, and unlikely to ever happen. Still, I can dream.