11 ms·

Hacking anything with GNU Guix

307 points by podiki 4y ago

genpfault 4y ago
...except KDE[1]: > GNOME, Xfce, LXDE, and Enlightenment are available (see Desktop Services), as well as a number of X11 window managers. However, KDE is currently missing. [1]: https://guix.gnu.org/manual/en/html_node/Limitations.html https://guix.gnu.org/manual/en/html_node/Limitations.html
rank0 4y ago
Can anyone explain to me the appeal of guix over nix? Is the learning curve any easier? I really badly wanted to like nix...but its just so strange and unconventional. Whenever I need a disposable environment I reach for lxc/lxd.
- nitsky 4y ago
  What in particular did you find strange and unconventional?
  - im3w1l 4y ago
    For me it was the core premise that is both the blessing and the curse. That it is only possible to install software by first packaging it.
    - amelius 4y ago
      That's because the basic idea is immutability and that doesn't go well with OSes designed around mutability. Nix/Guix are basically the "glue" that connects two worlds.
- jolmg 4y ago
  Haven't tried guix yet, and haven't used nix in years, but if what you struggled with is the language, guix might be less strange and more conventional since it uses Scheme as the language. It uses strict evaluation like most languages and there's probably more documentation about it.
- amelius 4y ago
  I think the main difference is that Guix will only support open software officially, whereas Nix will also happily allow proprietary stuff, like nVidia drivers. See e.g.: https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix > Guix channel for packages that can't be included upstream. Please do NOT promote or refer to this repository on any official Guix communication channels.
  - medstrom 4y ago
    Far from the 'main difference' -- if there was a project that just forked Nix and made that change, you could say that about it, but not about Guix, which has tons of work-hours invested and pretty much none of those work hours have to do with that.
    - amelius 4y ago
      True but that's from mostly a technical perspective. It is also (more?) important to know how a community thinks.
  - 0x457 4y ago
    I think the main difference is that Guix uses an actual language and writing things for it seems pretty reasonable, while Nix language is frustrating to work with and look at. There are probably hundreds of functions in nixpkgs that would make your life easy, but only 3.5 people know about them or how to use them.
- pxc 4y ago
  Guix is strange and unconventional in the same fundamental way as Nix, namely that each package is installed to its own, immutable, quasi-content-addressed prefix. This is because that design decision is what gives both package managers their superpowers. If you are already a Scheme user, you may find Guix more accessible for you. If you are not a C++ programmer, you may find hacking on the package manager itself easier with Guix. In terms of the CLI interface, Guix really shines here. Guix also has a more centralized approach to documentation, which you may find helpful. Beyond the surface-level language differences, Guix has gone with different abstractions than Nix in some key areas, and has some features that Nix lacks. One big one is that GuixSD uses a different model for defining the options that can be used to configure the system. Guix's approach¹ is more explicit, and features some provenance tracking for configured options— it can draw a graph for you showing where each setting on your system came from. Guix also takes a different approach to pinning package versions and defining repositories of source packages, and its conventions for doing those things are more settled than their equivalents and alternatives in the Nix world. Guix also supports a feature called 'grafts'² that allows you to avoid rebuilding the world in case of things like mission-critical security updates to glibc. This is a really cool and useful feature! I'm sure there are other things that more serious Guix users can better highlight than this dilettante. :) The Guix blog is really excellent! I strongly recommend it for getting a sense of what problems Guix tries to solve and how it sometimes approaches them differently than Nix does. -- 1: https://guix.gnu.org/manual/en/html_node/Defining-Services.html https://guix.gnu.org/manual/en/html_node/Defining-Services.h... 2: https://guix.gnu.org/blog/2020/grafts-continued/ https://guix.gnu.org/blog/2020/grafts-continued/
  - Macha 4y ago
    I tried and bounced off Nix on other systems, and I'm now running nixOS on my personal laptop (which is a secondary device). I think there's absolutely room to solve the same set of problems better than Nix does: 1. The number 1 problem for me has been documentation of nixpkgs. Nix lang is a bit funky but even if I was writing python the problem is that you're writing code to assign magic objects to magic variables and the only way to find the right ones is to read the nixpkgs source (and given the size of all-packages.nix and the limit of github's web viewer, maintain a local checkout). 2. Second place goes to the flake/non-flake divide where the nix community generally implies flakes are better but apart from the nix cli detailed docs, most things refuse to acknowledge its existence in the official docs. 3. Portability between macOS and Linux, where flakes actually make the situation worse as the root config is now system specific. 4. Tools like flakes, niv, the suggested way to write a shell.nix all want you to handle full commit hashes directly which is kinda unergonomic. None of these are inherent to the problem space. If I was to keep writing the list, maybe around 9 and 10 are the things around nixlang being a funky language or /nix directory that the "you just need to understand functional languages/content addressable stores" discussion seems to think are the top ones.
- turboponyy 4y ago
  From what I can tell (I've only used NixOS/Nix), Guix has considerably more thought put into the UX: Nix is currently undergoing a transition to a newer CLI; Nix's nomenclature is confusing; Guix has much better documentation; Guix has its equivalent of Nix's home-manager built-in. There is still some division in the Nix ecosystem between the pre-flake and the experimental post-flake way of doing things. Guix uses an established programming language for configuration, which some might find attractive (I actually quite like Nixlang after getting used to it). Guix makes installing non-free software a hassle (you have to include community sources). Nixpkgs doesn't impose this restriction, though you still have to explicitly allow the install of non-free packages when running Nix. Overall, Guix seems like the more polished product, though NixOS/Nix is similar in functionality and has a larger collection of packages and more traction in general.
  - retzkek 4y ago
    > Overall, Guix seems like the more polished product Possibly when comparing the Guix vs. Nix package managers, but for Linux distributions GuixSD ("Guix System" now) is very far behind NixOS in this regard. I've tried to install GuixSD on different hardware several times over the past couple years, and failed every time, between a lack of drivers and unpolished or buggy installer. Last time the installer wiped out my partition table without prompting when I went in to manually partition (to set up dual boot). NixOS on the other hand has always been flawless to install, and now there's even a modern GUI installer. I like Guix better in theory, but Nix wins in practicality.
    - tcmart14 4y ago
      Well the thing with the "Guix System" is that is uses the LinuxLibre kernel. So if the hardware you have requires proprietary bits or driver, it just isn't included. That isn't to defend Guix in anyway, but the problem doesn't seem to be Guix when you read the fine print of the distro, the problem is your hardware. So, do I agree necessarily agree with GNU's official distributions having this philosophy? Not really. Firmware and drivers is probably the one area I think the GNU people should finally throw in the towel. It keeps people out of running it, or doing so with relative ease. And the battle is for the most part lost on that end. But they do essentially tell you that it is likely it won't work across a lot of hardware out of the box. But here is the download page [0] https://guix.gnu.org/en/download/ https://guix.gnu.org/en/download/ That mentions the Libre kernel with link to information about the Libre kernel [1] https://www.fsfla.org/ikiwiki/selibre/linux-libre/ https://www.fsfla.org/ikiwiki/selibre/linux-libre/ With the following information: "Linux, the kernel developed and distributed by Linus Torvalds et al, contains non-Free Software, i.e., software that does not respect your essential freedoms, and it induces you to install additional non-Free Software that it doesn't contain. Even after allegedly moving all firmware to a separate project as of release 4.14, Linux so-called "sources" published by Mr Torvalds still contain non-Free firmware disguised as source code. Stux, a cute penguin. Few realize he's not Free GNU Linux-libre is a project to maintain and publish 100% Free distributions of Linux, suitable for use in Free System Distributions, removing software that is included without source code, with obfuscated or obscured source code, under non-Free Software licenses, that do not permit you to change the software so that it does what you wish, and that induces or requires you to install additional pieces of non-Free Software."
- throw10920 4y ago
  In addition to the other answers here: the Guix repositories only accept Free Software, even excluding things like Firefox, and intentionally make it somewhat difficult to install non-Free-Software (as opposed to Nix, where installing things like Firefox is relatively easy[1]). This may appeal to some people. [1] https://nixos.wiki/wiki/Firefox https://nixos.wiki/wiki/Firefox
  - amelius 4y ago
    Reminds me of the VHS vs Betamax war, where VHS won because Betamax (Sony) didn't allow adult videos (at least, so the legend goes).
  - yyyk2 4y ago
    Guix does not make non-free software "intentionally more difficult", it just excludes it from the main repository. There is a nonfree repo that you can add to your guix channels.
    - slim 4y ago
      the non free repo explicitly asks you not to talk about it https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix looks intentional to me
      - yyyk2 4y ago
        Well, all it says that you shouldn't promote it on the "official channels" (i.e. the mailing list and the #guix libera.chat channel). Guix, the package manager itself, does not make installing non-free packages any more difficult than free packages. I suppose it could be said that Guix (the project) makes finding non-free packages harder, although anecdotally I will say that nonguix is the first thing I've heard about guix, since it seems to be the most controversial part of it.
        throw10920 4y ago
        While it's technically correct to say that the software itself does not make it particularly difficult to install non-free packages, it also doesn't come with non-free repos when you set it up, and the documentation and official support channels intentionally lack information on non-free repos. As default settings and documentation are a critical part of a software project, it still has the end result of making it harder (much harder for non-technically-inclined users) to do so.
- forevernoob 4y ago
  One of my personal pet peeves are that Guix does not support Apple, while Nix does.
- hprotagonist 4y ago
  guix is written in basically scheme. Nix is some weird stringly typed DSL thing.
bogwog 4y ago
I had an idea recently to try out Fedora silverblue with Guix on top. Silverblue gives you an immutable root filesystem, which is great for building a reliable and reproducible system, but it makes installing software more complicated. Containers are the main solution, and stuff like flatpaks and toolbox. That (mostly) works, but it’s a bit heavy handed and not without annoyances. But with guix, your packages live in the guix store, and don’t touch your os packages. So that seems like a good way to manage software on top of an immutable OS. Unfortunately when I went to try it out, I learned that the only way to change the default location of the guix store (since /gnu/store won’t work in silverblue, and Guix isn’t available as a package for fedora) is to build it from source... and then I ran into some build issues when trying to do that and gave up. ...So maybe someone less lazy than I will pull it off and report back whether it’s actually a good idea or not!
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- Infernal 4y ago
  I'm downloading the silverblue iso right now to play with this in a VM. It is surprising to me that ostree does not let you do any sort of bind mount or symlink of a non-reserved location like /gnu to some other filesystem, so I'll have a whack at it.
  - bogwog 4y ago
    > It is surprising to me that ostree does not let you do any sort of bind mount or symlink of a non-reserved location like /gnu to some other filesystem, so I'll have a whack at it. ...Well, it might. I actually had zero experience with both ostree/silverblue and guix when I tried doing this, and may have made some hasty assumptions. EDIT: I do know however that guix doesn't work if the store is a symlink. I tried doing that a while back and it didn't work.
  - Infernal 4y ago
chubot 4y ago
I had a couple people attempt this for the dev environment of https://www.oilshell.org/ https://www.oilshell.org/ with Nix, and it wasn't entirely successful. (Not Guix, but my understanding is that Guix would have the same issues) As background, we've long had a set of evolving shell scripts that fetch and build dependencies at specific versions -- like bash/dash/zsh/mksh/busybox to test against, re2c to generate code, CommonMark, Python 3.10, MyPy with pip dependencies, and (bonus) R with CRAN dependencies. I wrote about 2 problems here: https://lobste.rs/s/s5co2f/where_contributors_have_problems_with#c_ndbezz https://lobste.rs/s/s5co2f/where_contributors_have_problems_... 1. OS X and libc, which is not really a problem since our existing scripts don't solve it either. It was just one motivation for Nix that didn't quite work out. 2. The file system layout becomes different, and Oil's shell tests rely on that. So containers ended up being easier. The whole build and test system runs in OCI containers under Docker and podman now, so it's pretty reproducible and automated. But I still think it would be nice if someone who actually knows Nix and Guix (unlike me) tries again. The dependencies are more stable now than 2 years ago. I think you have to write like 10 Nix or Guix expressions from scratch with the exact tarballs that we use. (Otherwise the tests will break even more, because Oil's tests are extremely detailed and find bugs in specific versions of specific shells.) Right now we have a 134 line shell.nix that tries to reuse Oil's scripts, but I think it doesn't gibe with the way that Nix and Guix are meant to be used. Probably the real solution would be more like 1000 lines from scratch? I remember that Nix Flakes was what I thought Nix was going to be, but at the time it wasn't ready. I thought Nix was supposed to solve the "it works on my machine" problem but it actually doesn't -- you still need a CI because it's possible to write .nix expressions in ways that break the sandboxing (unlike Bazel where you always get it). I had ran this by someone who knows Guix and my takeaway was that Guix is basically the same in that regard. A key problem is that, at least for awhile, I want it to work in parallel with our existing system ... not have a "big break".
- chubot 4y ago
  Also, reading back on that, I think the hardest part would be "PyPI dependencies" of MyPy, and "CRAN dependencies of R scripts like dplyr". These have what I call the "rewriting upstream" problem. Though maybe a hybrid approach can work? Or does that defeat the purpose? I think a problem with these kinds of systems is that they can be "all or nothing". If you're halfway in, and halfway out, you don't get any benefits.
pizza 4y ago
The article is about having the correct environment set up - attacking the problem from the environment level. When I think of "hacking code you didn't write" one of the biggest hurdles for me is "inserting my changes to the behavior of the code with minimal refactoring of the original" - attacking the problem from, perhaps, compiler instrumentation level. e.g. suppose when I use some library function f, there is a deeply nested function, g, that has access to some data x, which is cleaned up somewhere before the API returns its result. How do I tell my compiler "I want a new function h, which, when given the same arguments as f, returns x, by returning from within g" ?
- LanternLight83 4y ago
  This problem is trivial within emacs thanks to the advice system, and something I've always missed in literally any other programming environment. In Guile, I bet `(parameterize)` could be used to similar ends, but you don't get to choose the language of every project you hack on.
podiki 4y ago
Another great use of guix shell that I tend to do is for one off commands. I don't need OBS installed to use it occasionally, I can just do "guix shell obs -- obs" to run it once and not have it in my PATH, application launcher, etc. when I don't need it. Or better yet for running python or CL scripts, with something like 'guix shell python [python packages] -- python3 myscript.py "some argument"'. No need to carry around these libraries. This can be done with a manifest or guix.scm file as well, that guix shell will use automatically (once authorized, so you don't accidentally run something). This keeps things tidy in terms of just having packages I need all the time installed, while still being very quick after the first run. (There are some caveats about garbage collection, but I rarely do that.) And as the article mentioned there's also containers...lots of useful tools.
hedora 4y ago
Can anyone comment on how this compares to apt-get source? (Optionally run inside docker?)
- daptaq 4y ago
  AFAIK that won't install all the necessary dependencies, right? And even if it does, these are installed globally. Guix shell will only make the dependencies visible while the shell is active, and "hide" them again as soon as the process terminates.
- podiki 4y ago
  Not an apt user but my quick search suggests this just downloads the source of the package? The guix shell --development command in this article is for getting all the dependencies needed to build the package (but not the source itself, though you can do that through other guix commands I believe). In other words, with guix shell you can now run make or whatever you need to build the package in question, without needing to fetch the development tools, other libraries, set env variables, etc. Edit: for the source of a package guix build --source thepackage will return the path to the source (as stored in the store). This includes any patches or transformations (e.g. you can pass patches to be included or a git/branch/commit location to pull the source from instead of what is defined in the package definition)
- pxc 4y ago
  It's more like `apt build-dep`, but you don't install all the development libraries and headers to your system in a global, persistent way. Instead you just make them available for that shell session. It's likely a lot smaller than a Docker container that contains a whole Ubuntu runtime, and it'll automatically share a cache of deoendencies with any Guix packaged you may have installed locally. It also has normal/native access to your filesystem (and thus your dotfiles and your homedir), since it doesn't live in a container.
davexunit 4y ago
'guix shell' is killer. I use it for all my projects and one-off experiments. I also hook it up to Emacs 'M-x compile' so that compilation happens in the context of the guix shell. Beyond the simple command line package specification, you can add a guix.scm file to the root of your project repo and fill it with code that specifies all the packages needed for a development environment. Some of my guix.scm files are simple lists of existing packages, others are full of custom code to modify existing packages or define new ones. No matter how simple or complex it is behind the scenes, I just run 'guix shell' and get on with working on my project.
- _k9eq 4y ago
  You might be interested in buffer-env, it can automatically load an environment on a buffer-to-buffer basis and make it appear as though it were globally installed. No manual "guix shell ... -- ..." calls needed.
  - davexunit 4y ago
    Thanks, I've been meaning to check it out, so long as I can integrate guix shell with it.
  - dman 4y ago
    Could you elaborate a bit on how this works? Am a longtime emacs user and very motivated to get this working!
    - _k9eq 4y ago
      I wrote down my notes on how to use it here: https://amodernist.com/texts/emacs-guix.html https://amodernist.com/texts/emacs-guix.html.
      - dman 4y ago
        Thank you!!
- dman 4y ago
kqbx 4y ago
> PYTHONPATH, CPATH, etc are all set up and ready to go. Does that mean that Guix just exports the required environment variables in the shell rather than wrapping each executable with a bash script [1] like nix does? If yes, that's great, because the wrapper approach feels like an ugly hack. I found some executables on my nixos installation that are behind three layers of wrappers, and that's probably not the maximum. I guess nix could improve this situation by making `wrapProgram` smarter (if the executable to be wrapped is already a wrapper, merge the inner and outer wrapper), but even single-layer wrappers are annoying, and I imagine they have some performance impact. EDIT: I forgot about nix-shell, which does actually export the right environment variables directly to the shell. [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/make-wrapper.sh https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...
- pxc 4y ago
  Does nix-shell/`nix develop` use makeWrapper?
  - kqbx 4y ago
    Thank you, I totally forgot how nix-shell works. You're right, it should export the right env variables without makeWrapper. I haven't used nixos in a while and I got confused about this because to install python packages globally I used `python3.withPackages` and that does use the wrappers.
- yyyk2 4y ago
  Guix has a mechanism called search-paths which is defined for any package like Python that searches for things based on envars; it exports the relevant search paths into the environment. Though it also has shell wrappers, which are essentially a hack around non-propagating dependencies: it allows you to expose things that would normally be visible to everyone, like executables, to just the specific program.
retzkek 4y ago
It should be pointed out that "guix shell" is currently only available in the unstable "latest" version, not the stable "standard" release (v1.3.0). If you are running an older version, "guix environment" is similar. https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-shell.html https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix... https://guix.gnu.org/en/manual/en/html_node/Invoking-guix-environment.html#Invoking-guix-environment https://guix.gnu.org/en/manual/en/html_node/Invoking-guix-en...
- uncletaco 4y ago
  Running `guix pull` and restarting the daemon should update guix to the latest given it's a rolling release.
zelphirkalt 4y ago
Plus: You can make it all reproducible using `guix time-machine`.
yig 4y ago
xmake [1] gives you something like this via `xrepo env shell`. [1] https://xrepo.xmake.io/ https://xrepo.xmake.io/
jalino23 4y ago
thank you hn! this is a such a gem find
pmarreck 4y ago
It seems so obvious to me now that the fundamental design decision in Nix/Guix (to encapsulate dependencies via a content-addressed store, to make only those specific dependencies visible to the dependent app or library, to express all of this declaratively somehow, and to basically treat the entire build process and in fact the entire system configuration like a pure function with a deterministic result) is the way forward.
data_maan 4y ago
I'm not extremely competent in low-level SW engineering, so would anyone be willing to enlighten how all these shells and environment isolation techniques work? Even Python's virtual environment mechanisms are opaque to me and guix seems to be able to basically do that - but for anything you can think of (?).
- aaravchen 4y ago
  Simplified: In *nix environments primarily, many programs have similar building blocks. These building blocks are often separate projects and are managed as dependencies, which may in turn have their own dependencies. You end up with a tree or dependencies for each program, where parts in the tree may be the same for different programs. Only one copy of each part used in all trees is kept on the system so any program that needs it has it available. Usually all these libraries (dependencies) are kept in a few common locations on the system, and done global system settings list what those locations are. If you look you'll find a bunch of libraries all thrown into the same directory with one another as a result. But what happens when program A needs a library X version between 1.0 and 1.9, and program B needs library X version between 2.0 and 5.0? Both programs assume the system will have only one version on library X, and need it to meet their version requirements. Enter Guix (and it's cousin Nix). With Guix, instead of the single global setting listing a couple directories to find all libraries in, a unique environment is crafted for running program A where a large number of folders appear to be listed in the setting, each including exactly one version of one library. In parallel a different unique environment is crafted for program B in the same way. But in A's environment the folder for library X is the one with library X version 1.5, and in B's environment the folder for library X is the one for version 3.2, but they might both use the same folder for library Y version 0.6. This may seem obvious, but it's not as easy as this all sounds. There are actually a lot of global settings for where to find dependencies, some of them have to match each other, and which ones get used depends on what the programs being run are. Also there's more at play then just the version number of the library, what optional parts are included also plays a role. This gives a huge number of possible variations of packages, not all of which are easily summarized by something as simple as a version number. Therefore Guix had to have some way of consistently referring to a package that used a specific version of code, included specific options, and a while list of other factors that affect what results (called a "build closure"). How do you make sure you actually found everything that affects the build result though? You run it again under conditions that shouldn't change it and confirm it's the same output. Successfully doing this is called "deterministic builds", and allows you to conclusively state that a list of these inputs (the build closure) will always produce exactly these outputs. This may involve doing things like making the build of the package always think it's 1970-01-01 00:00:00 UTC+0 so builds that embed a timestamp always have the same timestamp, which is why Guix has had to create a large list of packages you need to pull from. One you have these deterministic builds, you can ask for a package via build closure, Guix can download (or locally build and populate) the package into your cache, and every subsequent request in a Guix-managed she'll used to run a program can point to the library folder in the cache. Making this even more difficult, building code has it's own dependencies added to the ones necessary for running it ("run time" vs "build time" dependencies). For compiled code this can be tools like the compiler used for example. When trying to figure out what's in the build closure, it can be very difficult. One way to make sure you really do control everything is to isolate it. That's what containers do.

307 points by podiki 4y ago

...except KDE[1]: > GNOME, Xfce, LXDE, and Enlightenment are available (see Desktop Services), as well as a number of X11 window managers. However, KDE is currently missing. [1]: https://guix.gnu.org/manual/en/html_node/Limitations.html https://guix.gnu.org/manual/en/html_node/Limitations.html

rank0 4y ago

Can anyone explain to me the appeal of guix over nix? Is the learning curve any easier? I really badly wanted to like nix...but its just so strange and unconventional. Whenever I need a disposable environment I reach for lxc/lxd.

nitsky 4y ago
What in particular did you find strange and unconventional?
- im3w1l 4y ago
  For me it was the core premise that is both the blessing and the curse. That it is only possible to install software by first packaging it.
  - amelius 4y ago
    That's because the basic idea is immutability and that doesn't go well with OSes designed around mutability. Nix/Guix are basically the "glue" that connects two worlds.
jolmg 4y ago
Haven't tried guix yet, and haven't used nix in years, but if what you struggled with is the language, guix might be less strange and more conventional since it uses Scheme as the language. It uses strict evaluation like most languages and there's probably more documentation about it.
amelius 4y ago
I think the main difference is that Guix will only support open software officially, whereas Nix will also happily allow proprietary stuff, like nVidia drivers. See e.g.: https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix > Guix channel for packages that can't be included upstream. Please do NOT promote or refer to this repository on any official Guix communication channels.
- medstrom 4y ago
  Far from the 'main difference' -- if there was a project that just forked Nix and made that change, you could say that about it, but not about Guix, which has tons of work-hours invested and pretty much none of those work hours have to do with that.
  - amelius 4y ago
    True but that's from mostly a technical perspective. It is also (more?) important to know how a community thinks.
- 0x457 4y ago
  I think the main difference is that Guix uses an actual language and writing things for it seems pretty reasonable, while Nix language is frustrating to work with and look at. There are probably hundreds of functions in nixpkgs that would make your life easy, but only 3.5 people know about them or how to use them.
pxc 4y ago
Guix is strange and unconventional in the same fundamental way as Nix, namely that each package is installed to its own, immutable, quasi-content-addressed prefix. This is because that design decision is what gives both package managers their superpowers. If you are already a Scheme user, you may find Guix more accessible for you. If you are not a C++ programmer, you may find hacking on the package manager itself easier with Guix. In terms of the CLI interface, Guix really shines here. Guix also has a more centralized approach to documentation, which you may find helpful. Beyond the surface-level language differences, Guix has gone with different abstractions than Nix in some key areas, and has some features that Nix lacks. One big one is that GuixSD uses a different model for defining the options that can be used to configure the system. Guix's approach¹ is more explicit, and features some provenance tracking for configured options— it can draw a graph for you showing where each setting on your system came from. Guix also takes a different approach to pinning package versions and defining repositories of source packages, and its conventions for doing those things are more settled than their equivalents and alternatives in the Nix world. Guix also supports a feature called 'grafts'² that allows you to avoid rebuilding the world in case of things like mission-critical security updates to glibc. This is a really cool and useful feature! I'm sure there are other things that more serious Guix users can better highlight than this dilettante. :) The Guix blog is really excellent! I strongly recommend it for getting a sense of what problems Guix tries to solve and how it sometimes approaches them differently than Nix does. -- 1: https://guix.gnu.org/manual/en/html_node/Defining-Services.html https://guix.gnu.org/manual/en/html_node/Defining-Services.h... 2: https://guix.gnu.org/blog/2020/grafts-continued/ https://guix.gnu.org/blog/2020/grafts-continued/
- Macha 4y ago
  I tried and bounced off Nix on other systems, and I'm now running nixOS on my personal laptop (which is a secondary device). I think there's absolutely room to solve the same set of problems better than Nix does: 1. The number 1 problem for me has been documentation of nixpkgs. Nix lang is a bit funky but even if I was writing python the problem is that you're writing code to assign magic objects to magic variables and the only way to find the right ones is to read the nixpkgs source (and given the size of all-packages.nix and the limit of github's web viewer, maintain a local checkout). 2. Second place goes to the flake/non-flake divide where the nix community generally implies flakes are better but apart from the nix cli detailed docs, most things refuse to acknowledge its existence in the official docs. 3. Portability between macOS and Linux, where flakes actually make the situation worse as the root config is now system specific. 4. Tools like flakes, niv, the suggested way to write a shell.nix all want you to handle full commit hashes directly which is kinda unergonomic. None of these are inherent to the problem space. If I was to keep writing the list, maybe around 9 and 10 are the things around nixlang being a funky language or /nix directory that the "you just need to understand functional languages/content addressable stores" discussion seems to think are the top ones.
turboponyy 4y ago
From what I can tell (I've only used NixOS/Nix), Guix has considerably more thought put into the UX: Nix is currently undergoing a transition to a newer CLI; Nix's nomenclature is confusing; Guix has much better documentation; Guix has its equivalent of Nix's home-manager built-in. There is still some division in the Nix ecosystem between the pre-flake and the experimental post-flake way of doing things. Guix uses an established programming language for configuration, which some might find attractive (I actually quite like Nixlang after getting used to it). Guix makes installing non-free software a hassle (you have to include community sources). Nixpkgs doesn't impose this restriction, though you still have to explicitly allow the install of non-free packages when running Nix. Overall, Guix seems like the more polished product, though NixOS/Nix is similar in functionality and has a larger collection of packages and more traction in general.
- retzkek 4y ago
  > Overall, Guix seems like the more polished product Possibly when comparing the Guix vs. Nix package managers, but for Linux distributions GuixSD ("Guix System" now) is very far behind NixOS in this regard. I've tried to install GuixSD on different hardware several times over the past couple years, and failed every time, between a lack of drivers and unpolished or buggy installer. Last time the installer wiped out my partition table without prompting when I went in to manually partition (to set up dual boot). NixOS on the other hand has always been flawless to install, and now there's even a modern GUI installer. I like Guix better in theory, but Nix wins in practicality.
  - tcmart14 4y ago
    Well the thing with the "Guix System" is that is uses the LinuxLibre kernel. So if the hardware you have requires proprietary bits or driver, it just isn't included. That isn't to defend Guix in anyway, but the problem doesn't seem to be Guix when you read the fine print of the distro, the problem is your hardware. So, do I agree necessarily agree with GNU's official distributions having this philosophy? Not really. Firmware and drivers is probably the one area I think the GNU people should finally throw in the towel. It keeps people out of running it, or doing so with relative ease. And the battle is for the most part lost on that end. But they do essentially tell you that it is likely it won't work across a lot of hardware out of the box. But here is the download page [0] https://guix.gnu.org/en/download/ https://guix.gnu.org/en/download/ That mentions the Libre kernel with link to information about the Libre kernel [1] https://www.fsfla.org/ikiwiki/selibre/linux-libre/ https://www.fsfla.org/ikiwiki/selibre/linux-libre/ With the following information: "Linux, the kernel developed and distributed by Linus Torvalds et al, contains non-Free Software, i.e., software that does not respect your essential freedoms, and it induces you to install additional non-Free Software that it doesn't contain. Even after allegedly moving all firmware to a separate project as of release 4.14, Linux so-called "sources" published by Mr Torvalds still contain non-Free firmware disguised as source code. Stux, a cute penguin. Few realize he's not Free GNU Linux-libre is a project to maintain and publish 100% Free distributions of Linux, suitable for use in Free System Distributions, removing software that is included without source code, with obfuscated or obscured source code, under non-Free Software licenses, that do not permit you to change the software so that it does what you wish, and that induces or requires you to install additional pieces of non-Free Software."
throw10920 4y ago
In addition to the other answers here: the Guix repositories only accept Free Software, even excluding things like Firefox, and intentionally make it somewhat difficult to install non-Free-Software (as opposed to Nix, where installing things like Firefox is relatively easy[1]). This may appeal to some people. [1] https://nixos.wiki/wiki/Firefox https://nixos.wiki/wiki/Firefox
- amelius 4y ago
  Reminds me of the VHS vs Betamax war, where VHS won because Betamax (Sony) didn't allow adult videos (at least, so the legend goes).
- yyyk2 4y ago
  Guix does not make non-free software "intentionally more difficult", it just excludes it from the main repository. There is a nonfree repo that you can add to your guix channels.
  - slim 4y ago
    the non free repo explicitly asks you not to talk about it https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix looks intentional to me
    - yyyk2 4y ago
      Well, all it says that you shouldn't promote it on the "official channels" (i.e. the mailing list and the #guix libera.chat channel). Guix, the package manager itself, does not make installing non-free packages any more difficult than free packages. I suppose it could be said that Guix (the project) makes finding non-free packages harder, although anecdotally I will say that nonguix is the first thing I've heard about guix, since it seems to be the most controversial part of it.
      - throw10920 4y ago
        While it's technically correct to say that the software itself does not make it particularly difficult to install non-free packages, it also doesn't come with non-free repos when you set it up, and the documentation and official support channels intentionally lack information on non-free repos. As default settings and documentation are a critical part of a software project, it still has the end result of making it harder (much harder for non-technically-inclined users) to do so.
forevernoob 4y ago
One of my personal pet peeves are that Guix does not support Apple, while Nix does.
hprotagonist 4y ago
guix is written in basically scheme. Nix is some weird stringly typed DSL thing.

bogwog 4y ago

I had an idea recently to try out Fedora silverblue with Guix on top. Silverblue gives you an immutable root filesystem, which is great for building a reliable and reproducible system, but it makes installing software more complicated. Containers are the main solution, and stuff like flatpaks and toolbox. That (mostly) works, but it’s a bit heavy handed and not without annoyances. But with guix, your packages live in the guix store, and don’t touch your os packages. So that seems like a good way to manage software on top of an immutable OS. Unfortunately when I went to try it out, I learned that the only way to change the default location of the guix store (since /gnu/store won’t work in silverblue, and Guix isn’t available as a package for fedora) is to build it from source... and then I ran into some build issues when trying to do that and gave up. ...So maybe someone less lazy than I will pull it off and report back whether it’s actually a good idea or not!

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
Infernal 4y ago
I'm downloading the silverblue iso right now to play with this in a VM. It is surprising to me that ostree does not let you do any sort of bind mount or symlink of a non-reserved location like /gnu to some other filesystem, so I'll have a whack at it.
- bogwog 4y ago
  > It is surprising to me that ostree does not let you do any sort of bind mount or symlink of a non-reserved location like /gnu to some other filesystem, so I'll have a whack at it. ...Well, it might. I actually had zero experience with both ostree/silverblue and guix when I tried doing this, and may have made some hasty assumptions. EDIT: I do know however that guix doesn't work if the store is a symlink. I tried doing that a while back and it didn't work.
- Infernal 4y ago

chubot 4y ago

I had a couple people attempt this for the dev environment of https://www.oilshell.org/ https://www.oilshell.org/ with Nix, and it wasn't entirely successful. (Not Guix, but my understanding is that Guix would have the same issues) As background, we've long had a set of evolving shell scripts that fetch and build dependencies at specific versions -- like bash/dash/zsh/mksh/busybox to test against, re2c to generate code, CommonMark, Python 3.10, MyPy with pip dependencies, and (bonus) R with CRAN dependencies. I wrote about 2 problems here: https://lobste.rs/s/s5co2f/where_contributors_have_problems_with#c_ndbezz https://lobste.rs/s/s5co2f/where_contributors_have_problems_... 1. OS X and libc, which is not really a problem since our existing scripts don't solve it either. It was just one motivation for Nix that didn't quite work out. 2. The file system layout becomes different, and Oil's shell tests rely on that. So containers ended up being easier. The whole build and test system runs in OCI containers under Docker and podman now, so it's pretty reproducible and automated. But I still think it would be nice if someone who actually knows Nix and Guix (unlike me) tries again. The dependencies are more stable now than 2 years ago. I think you have to write like 10 Nix or Guix expressions from scratch with the exact tarballs that we use. (Otherwise the tests will break even more, because Oil's tests are extremely detailed and find bugs in specific versions of specific shells.) Right now we have a 134 line shell.nix that tries to reuse Oil's scripts, but I think it doesn't gibe with the way that Nix and Guix are meant to be used. Probably the real solution would be more like 1000 lines from scratch? I remember that Nix Flakes was what I thought Nix was going to be, but at the time it wasn't ready. I thought Nix was supposed to solve the "it works on my machine" problem but it actually doesn't -- you still need a CI because it's possible to write .nix expressions in ways that break the sandboxing (unlike Bazel where you always get it). I had ran this by someone who knows Guix and my takeaway was that Guix is basically the same in that regard. A key problem is that, at least for awhile, I want it to work in parallel with our existing system ... not have a "big break".

chubot 4y ago
Also, reading back on that, I think the hardest part would be "PyPI dependencies" of MyPy, and "CRAN dependencies of R scripts like dplyr". These have what I call the "rewriting upstream" problem. Though maybe a hybrid approach can work? Or does that defeat the purpose? I think a problem with these kinds of systems is that they can be "all or nothing". If you're halfway in, and halfway out, you don't get any benefits.

pizza 4y ago

The article is about having the correct environment set up - attacking the problem from the environment level. When I think of "hacking code you didn't write" one of the biggest hurdles for me is "inserting my changes to the behavior of the code with minimal refactoring of the original" - attacking the problem from, perhaps, compiler instrumentation level. e.g. suppose when I use some library function f, there is a deeply nested function, g, that has access to some data x, which is cleaned up somewhere before the API returns its result. How do I tell my compiler "I want a new function h, which, when given the same arguments as f, returns x, by returning from within g" ?

LanternLight83 4y ago
This problem is trivial within emacs thanks to the advice system, and something I've always missed in literally any other programming environment. In Guile, I bet `(parameterize)` could be used to similar ends, but you don't get to choose the language of every project you hack on.

podiki 4y ago

Another great use of guix shell that I tend to do is for one off commands. I don't need OBS installed to use it occasionally, I can just do "guix shell obs -- obs" to run it once and not have it in my PATH, application launcher, etc. when I don't need it. Or better yet for running python or CL scripts, with something like 'guix shell python [python packages] -- python3 myscript.py "some argument"'. No need to carry around these libraries. This can be done with a manifest or guix.scm file as well, that guix shell will use automatically (once authorized, so you don't accidentally run something). This keeps things tidy in terms of just having packages I need all the time installed, while still being very quick after the first run. (There are some caveats about garbage collection, but I rarely do that.) And as the article mentioned there's also containers...lots of useful tools.

hedora 4y ago

Can anyone comment on how this compares to apt-get source? (Optionally run inside docker?)

daptaq 4y ago
AFAIK that won't install all the necessary dependencies, right? And even if it does, these are installed globally. Guix shell will only make the dependencies visible while the shell is active, and "hide" them again as soon as the process terminates.
podiki 4y ago
Not an apt user but my quick search suggests this just downloads the source of the package? The guix shell --development command in this article is for getting all the dependencies needed to build the package (but not the source itself, though you can do that through other guix commands I believe). In other words, with guix shell you can now run make or whatever you need to build the package in question, without needing to fetch the development tools, other libraries, set env variables, etc. Edit: for the source of a package guix build --source thepackage will return the path to the source (as stored in the store). This includes any patches or transformations (e.g. you can pass patches to be included or a git/branch/commit location to pull the source from instead of what is defined in the package definition)
pxc 4y ago
It's more like `apt build-dep`, but you don't install all the development libraries and headers to your system in a global, persistent way. Instead you just make them available for that shell session. It's likely a lot smaller than a Docker container that contains a whole Ubuntu runtime, and it'll automatically share a cache of deoendencies with any Guix packaged you may have installed locally. It also has normal/native access to your filesystem (and thus your dotfiles and your homedir), since it doesn't live in a container.

davexunit 4y ago

'guix shell' is killer. I use it for all my projects and one-off experiments. I also hook it up to Emacs 'M-x compile' so that compilation happens in the context of the guix shell. Beyond the simple command line package specification, you can add a guix.scm file to the root of your project repo and fill it with code that specifies all the packages needed for a development environment. Some of my guix.scm files are simple lists of existing packages, others are full of custom code to modify existing packages or define new ones. No matter how simple or complex it is behind the scenes, I just run 'guix shell' and get on with working on my project.

_k9eq 4y ago
You might be interested in buffer-env, it can automatically load an environment on a buffer-to-buffer basis and make it appear as though it were globally installed. No manual "guix shell ... -- ..." calls needed.
- davexunit 4y ago
  Thanks, I've been meaning to check it out, so long as I can integrate guix shell with it.
- dman 4y ago
  Could you elaborate a bit on how this works? Am a longtime emacs user and very motivated to get this working!
  - _k9eq 4y ago
    I wrote down my notes on how to use it here: https://amodernist.com/texts/emacs-guix.html https://amodernist.com/texts/emacs-guix.html.
    - dman 4y ago
      Thank you!!
dman 4y ago

kqbx 4y ago

> PYTHONPATH, CPATH, etc are all set up and ready to go. Does that mean that Guix just exports the required environment variables in the shell rather than wrapping each executable with a bash script [1] like nix does? If yes, that's great, because the wrapper approach feels like an ugly hack. I found some executables on my nixos installation that are behind three layers of wrappers, and that's probably not the maximum. I guess nix could improve this situation by making `wrapProgram` smarter (if the executable to be wrapped is already a wrapper, merge the inner and outer wrapper), but even single-layer wrappers are annoying, and I imagine they have some performance impact. EDIT: I forgot about nix-shell, which does actually export the right environment variables directly to the shell. [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/make-wrapper.sh https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...

pxc 4y ago
Does nix-shell/`nix develop` use makeWrapper?
- kqbx 4y ago
  Thank you, I totally forgot how nix-shell works. You're right, it should export the right env variables without makeWrapper. I haven't used nixos in a while and I got confused about this because to install python packages globally I used `python3.withPackages` and that does use the wrappers.
yyyk2 4y ago
Guix has a mechanism called search-paths which is defined for any package like Python that searches for things based on envars; it exports the relevant search paths into the environment. Though it also has shell wrappers, which are essentially a hack around non-propagating dependencies: it allows you to expose things that would normally be visible to everyone, like executables, to just the specific program.

retzkek 4y ago

It should be pointed out that "guix shell" is currently only available in the unstable "latest" version, not the stable "standard" release (v1.3.0). If you are running an older version, "guix environment" is similar. https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-shell.html https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix... https://guix.gnu.org/en/manual/en/html_node/Invoking-guix-environment.html#Invoking-guix-environment https://guix.gnu.org/en/manual/en/html_node/Invoking-guix-en...

uncletaco 4y ago
Running `guix pull` and restarting the daemon should update guix to the latest given it's a rolling release.

zelphirkalt 4y ago

Plus: You can make it all reproducible using `guix time-machine`.

yig 4y ago

xmake [1] gives you something like this via `xrepo env shell`. [1] https://xrepo.xmake.io/ https://xrepo.xmake.io/

jalino23 4y ago

thank you hn! this is a such a gem find

pmarreck 4y ago

It seems so obvious to me now that the fundamental design decision in Nix/Guix (to encapsulate dependencies via a content-addressed store, to make only those specific dependencies visible to the dependent app or library, to express all of this declaratively somehow, and to basically treat the entire build process and in fact the entire system configuration like a pure function with a deterministic result) is the way forward.

data_maan 4y ago

I'm not extremely competent in low-level SW engineering, so would anyone be willing to enlighten how all these shells and environment isolation techniques work? Even Python's virtual environment mechanisms are opaque to me and guix seems to be able to basically do that - but for anything you can think of (?).

aaravchen 4y ago
Simplified: In *nix environments primarily, many programs have similar building blocks. These building blocks are often separate projects and are managed as dependencies, which may in turn have their own dependencies. You end up with a tree or dependencies for each program, where parts in the tree may be the same for different programs. Only one copy of each part used in all trees is kept on the system so any program that needs it has it available. Usually all these libraries (dependencies) are kept in a few common locations on the system, and done global system settings list what those locations are. If you look you'll find a bunch of libraries all thrown into the same directory with one another as a result. But what happens when program A needs a library X version between 1.0 and 1.9, and program B needs library X version between 2.0 and 5.0? Both programs assume the system will have only one version on library X, and need it to meet their version requirements. Enter Guix (and it's cousin Nix). With Guix, instead of the single global setting listing a couple directories to find all libraries in, a unique environment is crafted for running program A where a large number of folders appear to be listed in the setting, each including exactly one version of one library. In parallel a different unique environment is crafted for program B in the same way. But in A's environment the folder for library X is the one with library X version 1.5, and in B's environment the folder for library X is the one for version 3.2, but they might both use the same folder for library Y version 0.6. This may seem obvious, but it's not as easy as this all sounds. There are actually a lot of global settings for where to find dependencies, some of them have to match each other, and which ones get used depends on what the programs being run are. Also there's more at play then just the version number of the library, what optional parts are included also plays a role. This gives a huge number of possible variations of packages, not all of which are easily summarized by something as simple as a version number. Therefore Guix had to have some way of consistently referring to a package that used a specific version of code, included specific options, and a while list of other factors that affect what results (called a "build closure"). How do you make sure you actually found everything that affects the build result though? You run it again under conditions that shouldn't change it and confirm it's the same output. Successfully doing this is called "deterministic builds", and allows you to conclusively state that a list of these inputs (the build closure) will always produce exactly these outputs. This may involve doing things like making the build of the package always think it's 1970-01-01 00:00:00 UTC+0 so builds that embed a timestamp always have the same timestamp, which is why Guix has had to create a large list of packages you need to pull from. One you have these deterministic builds, you can ask for a package via build closure, Guix can download (or locally build and populate) the package into your cache, and every subsequent request in a Guix-managed she'll used to run a program can point to the library folder in the cache. Making this even more difficult, building code has it's own dependencies added to the ones necessary for running it ("run time" vs "build time" dependencies). For compiled code this can be tools like the compiler used for example. When trying to figure out what's in the build closure, it can be very difficult. One way to make sure you really do control everything is to isolate it. That's what containers do.