4 ms·

I agree on every single point. I'd love to make GuixSD my permanent home. But, Guix is not just Nix with better language. It comes with its own baggage elsewhe

I agree on every single point. I'd love to make GuixSD my permanent home. But, Guix is not just Nix with better language. It comes with its own baggage elsewhere. Guix repository has way wayy fewer packages. Some of the most common ones like the plasma-desktop are absent. Proprietary applications are a no-go. Even if I set up nonguix, I'm warned that that cuts off my support in official channels. As an Optimus laptop owner (because my Master's required running Cuda and pytorch) I'm simply left hanging on Guix. I understand and often appreciate Guix's stand on everything above. No. of packages is because of strong stance on bootstrapping, proprietary package unavailability is self a explanatory. But, that doesn't solve my problems, and creates few new ones. Even Debian allows using proprietary firmware blobs with some fiddling and doesn't turn people away for asking. These barriers are so much that I bit the bullet and (mostly) learned the weird Nix DSL. As much as I'd like to go for Guix, for my personal use case, it is a nonstarter.

_huayra_ 5y ago
Yes, if Guix were "Nix but with Scheme" I'd go for it in a second. Unfortunately, although both Nix and Guix make hard choices about things (e.g. the init system), at least the choices made by Nix are more livable day-to-day. As to why Nix wasn't some system written using Haskell (for actual language features that is also lazy) or Prolog (for its whole thing about solving constraint-based problems all over the place), I will never understand...
- GordonS 5y ago
  Would it be possible to write a CLI tool that translated Scheme into Nix-compatible config files? Presumably then you could alias Nix commands so they piped config 8n through the translator.
  - _huayra_ 5y ago
    It might be possible, but a better approach (and the one Guix used initially, iirc) is to just be compatible with the derivation format (kinda like object files in C/C++ compilation). The end result is basically a big dependency graph, so one may be able to write a different generator in front of it. Anyone who has done the basics in Prolog could "logically" pull this off (e.g. some rule requires another rule, or however Prolog works; it's been a long time since I looked at it), but all of the extra stuff in the library (e.g. all of the systemd tweaking, interface, etc) is a LOT of man hours. I heard about Spack [0] on a recent cppcast episode, which seems like a competitor to Nix (but from the supercomputing side of things), but I don't know if they do the OS-level stuff (vs. nix shell / conda / pip / gem replacement stuff). [0] https://spack.io/ https://spack.io/
- tgamblin 5y ago
  Guix and Nix don’t actually solve constraint problems, though. By design, they omit the dependency resolution that other package managers do, and humans manage the dependencies. If you want to change versions, you need to do some hacking to update things and propagate requirements through the package graph. You could think of Spack (github.com/spack/spack) as a nix/guix-like model, but with a solver. Spack uses ASP (which is prolog-like but reduces to SAT with optimization) but packages are written in an embedded python DSL.

_huayra_ 5y ago

Yes, if Guix were "Nix but with Scheme" I'd go for it in a second. Unfortunately, although both Nix and Guix make hard choices about things (e.g. the init system), at least the choices made by Nix are more livable day-to-day. As to why Nix wasn't some system written using Haskell (for actual language features that is also lazy) or Prolog (for its whole thing about solving constraint-based problems all over the place), I will never understand...

GordonS 5y ago
Would it be possible to write a CLI tool that translated Scheme into Nix-compatible config files? Presumably then you could alias Nix commands so they piped config 8n through the translator.
- _huayra_ 5y ago
  It might be possible, but a better approach (and the one Guix used initially, iirc) is to just be compatible with the derivation format (kinda like object files in C/C++ compilation). The end result is basically a big dependency graph, so one may be able to write a different generator in front of it. Anyone who has done the basics in Prolog could "logically" pull this off (e.g. some rule requires another rule, or however Prolog works; it's been a long time since I looked at it), but all of the extra stuff in the library (e.g. all of the systemd tweaking, interface, etc) is a LOT of man hours. I heard about Spack [0] on a recent cppcast episode, which seems like a competitor to Nix (but from the supercomputing side of things), but I don't know if they do the OS-level stuff (vs. nix shell / conda / pip / gem replacement stuff). [0] https://spack.io/ https://spack.io/
tgamblin 5y ago
Guix and Nix don’t actually solve constraint problems, though. By design, they omit the dependency resolution that other package managers do, and humans manage the dependencies. If you want to change versions, you need to do some hacking to update things and propagate requirements through the package graph. You could think of Spack (github.com/spack/spack) as a nix/guix-like model, but with a solver. Spack uses ASP (which is prolog-like but reduces to SAT with optimization) but packages are written in an embedded python DSL.