Why GNU Guix Matters
ambrevar.xyz
Why GNU Guix Matters
1–8 of 8 posts
Re: Why GNU Guix Matters
#2Re: Why GNU Guix Matters
#3Guix is a hacky clone that is mostly unusable due to the FSF's extremely stupid definition of free on the firmware level. Check out Nix instead, but I'm guessing that anyone reading this already knows about Nix
Guix is not tied to any kernel version. Hurd and Linux-libre are officially supported. But it is trivial for users to incorporate non-free firmwares.
Re: Why GNU Guix Matters
#4Guix is a hacky clone that is mostly unusable due to the FSF's extremely stupid definition of free on the firmware level. Check out Nix instead, but I'm guessing that anyone reading this already knows about Nix
Check out Guix via Nix package definitions. Nix looks far more hacky (embedded shell scripts are standard). Guix package defs are declarative and readable (even for those with little Lisp exposure). Guix is not tied to any kernel version. Hurd and Linux-libre are officially supported. But it is trivial for users to incorporate non-free firmwares.
In fact I just spend 5 minutes to search for the source of a few Guix packages and I couldn't find it. I found this: https://guix.gnu.org/en/packages/ which is a meager list without any link to the packaging source. Huge red flag for a distro.
Re: Why GNU Guix Matters
#5Guix is a hacky clone that is mostly unusable due to the FSF's extremely stupid definition of free on the firmware level. Check out Nix instead, but I'm guessing that anyone reading this already knows about Nix
Re: Why GNU Guix Matters
#6Re: Why GNU Guix Matters
#7Earlier quoted context omitted.
Check out Guix via Nix package definitions. Nix looks far more hacky (embedded shell scripts are standard). Guix package defs are declarative and readable (even for those with little Lisp exposure). Guix is not tied to any kernel version. Hurd and Linux-libre are officially supported. But it is trivial for users to incorporate non-free firmwares.
Isn't embedded shell scripts exactly what you want though? I can't imagine having the flexibility of configuring entire unix systems without beeing able to ever touch a shell script. Unless you are writing shell scripts in some kind of meta language, but that's just writing shell scripts in another form. In fact I just spend 5 minutes to search for the source of a few Guix packages and I couldn't find it. I found thi…
I clicked the first
https://guix.gnu.org/en/packages/python-pyxel-1.4.3/
It says "Package source: game-development.scm" linking to https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...
It's a lisp code that does what a shell script might do, but declaratively. Indeed it isn't much different from an Arch Linux PKGBUILD.
Re: Why GNU Guix Matters
#8Guix is a hacky clone that is mostly unusable due to the FSF's extremely stupid definition of free on the firmware level. Check out Nix instead, but I'm guessing that anyone reading this already knows about Nix
Isn't Nix and Guix definition the same? And you just have to include the non-free on both?
They start to look similar at the level of compiled derivations, but even the builder scripts are different: in Guix they are compiled Guile scripts whereas in Nix they are Bash scripts.