1. 29

  2. 15

    I’ve become more and more disillusioned with NixOS over the past couple of months. Packaging things that aren’t available, or even updating existing packages, has so many little undocumented gotchas that (I guess) they assume you’ll figure out reading from reading gh issues or random blog posts. It has actually stopped me working on a few different projects because it’s not worth figuring out how to package something.

    However, I don’t think I can go back to a traditional distro after tasting the stability and convenience of something like NixOS. Has anyone here tried both NixOS and GuixSD. or perhaps switched from one to the other?

    Guix seems so much better documented from the brief read though I’ve given it after seeing this. The docs just have so much detail.

    Also, I’d much rather learn a real language like scheme for making packages than the rather incomprehensible (at least to me) language that Nix invented.

    What are the downsides of Guix that I just haven’t seen yet?

    1. 9

      Guix has fewer packages, because they have a smaller community. Being a GNU project, they attempt to limit the amount of non-free, or license-incompatible, software as much as possible: using linux-libre, nearly no potential ZFS support, no Intel microcode, etc. If your hardware depends on a binary blob, you might have to jump through several hoops to get it working. As of 2018-07-06, they don’t have LVM support.

      That said, guix seems far better thought out than nix. It does not rely on a particular init ecosystem (cough, systemd, cough). It has more features available without installing additional packages, for example: guix import instead of the myriad of pypi2nix, nix-generate-from-cpan, etc packages that are separately written; guix environment makes creating an isolated container as easy as its normal environment isolation; etc. And guix is most certainly better documented.

      If you’re comfortable packaging software yourself (and don’t mind doing so), some of these problems could be fixable. You can keep (or contribute to) a non-free guix repository (such as these, but these do not seem to be well maintained, nor will the be approved of, probably). One could also use guix import to import from a local copy of nixpkgs (though such an import is imperfect, and might require manual maintenance), or run guix atop NixOS.

      Unfortunately, I needed a system that works with nearly-minimal hassle on my hardware, with my software, and that is what NixOS gave me. The nix language is quaint, and the reliance on bash and systemd rather annoying, but personally I can ignore that and use a working computer with a relatively nice environment management system.

      1. 2

        It does not rely on a particular init ecosystem You are referring to Guix, the package manager here, right? Because, as far as I understand, GuixSD, the Linux distribution does depend on https://www.gnu.org/software/shepherd/?

        1. 3

          I was referring to the fact that neither Guix nor GuixSD rely on systemd. But you are correct, as best as I can tell GuixSD seems to rely on Shepherd.

          Though maybe not all services seem to rely on it? Some of them don’t seem to mention shepherd at all, but I can’t tell whether or not that means anything because I’m not well versed in Guix scheme.

          1. 1


            Here’s one example that clearly refers to shepherd. Is there any reason to believe that shepherd is better than systemd?

            1. 6

              Three things, maybe:

              • Shepherd doesn’t try to be more than an init system. Contrast to Logind, which GNOME depends on, which is tied to systemd. elogind had to be forked and extracted from systemd, because otherwise GNOME would not work without it. I don’t know of any end user applications that require shepherd to be the init system in any way that doesn’t resemble init system / daemon management usage.
              • shepherd is also written in scheme, which means that Guix expressions can easily generate code per the user’s configuration for the shepherd file since you’re just going from scheme to scheme.
              • I can’t remember if systemd can do this or not, but you can also run shepherd as a user to manage your user’s daemons (rather than the system-wide daemons). Convenient!
              1. 1

                I can’t remember if systemd can do this or not, but you can also run shepherd as a user to manage your user’s daemons

                Yes, systemd can do that.

                1. 1

                  I can’t remember if systemd can do this or not, but you can also run shepherd as a user to manage your user’s daemons

                  Systemd does have support for user services, without needing to start another daemon as your user.

                  1. 1

                    I should clarify that I meant being able to run one or more shepherd as a user being a feature :)

                2. 5

                  Shepherd isn’t an ecosystem of things that come bundled together? It isn’t Linux specific? It doesn’t (yet) slowly overtake various other components of your system, such as udev? There are definitely reasons that I still believe that Shepherd is better than systemd.

                  However, nothing’s perfect. Upon a further examining of the documentation, it does seem that you are correct regarding Guix’s dependence on Shepherd: namely, all services do currently depend on it.

            2. 2

              Thanks for that Guix on NixOS link. I actually installed GuixSD in a VM at work today and noticed there were quite a few packages missing that I would like to have, so that seems like a good way to get started making son new packages before I go all in on the OS.

              1. 1

                What is the status of Java especially maven dependencies of a project? (which doesn’t seem to be fixed in Nix yet)?

            3. 8

              My latest install has been Guix on top of Arch.
              I’ve been running it as my daily driver for a couple months.


              • Guix is easy to hack on, you can get in there and do whatever you want with minimal fuss, especially compared to other package managers.
              • Emacs integration is robust, including a powerful REPL.
              • Scheme is a full language, I can realistically see Guix subsuming all other language-specific dependency and package managers. Especially attractive for polyglot projects that are juggling multiple build tools and environments.
              • Can build lots of packages from source, with their build dependencies, which makes it great when patching those projects.
              • Easy to apply your own patches or specify your own remotes.
              • Runs package test suites on the host system.


              • Packages are still few and frequently out-of-date compared to Pacman.
              • Still fairly unstable, stuff breaks, updates break.
              • Slow… Building so much from source is slow… Even with fast mirrors get ready for a slow time.

              Overall, I like having it on my system, it’s especially nice for managing Emacs packages! I fall back onto Pacman frequently to work around the cons. I couldn’t run GuixSD as my daily driver.

              1. 1

                The last time, I tried nix, everything in the store had to be world-readable, which made it rather questionable to manage things like private keys for TLS certificates and so on through nix expressions. Is this an issue with guix too?

              2. 7

                Nice to see Guix is still alive and in good shape. I really want to give it a try soon (probably next fall) ; I wish all contributors and maintainers good luck until then!

                1. 3

                  Is the only difference between Guix and Nix the language? I know Nix is more mature and has a bigger community with more packages, but I don’t see any user-facing changes between the two.

                  1. 4

                    I guess there are many differences? One important one is the license. The FSF prefers Guix and GuixSD over Nix and NixOS.

                    1. 1

                      that’s…not really…a difference in the technology

                      1. 3

                        Oh, you wanted only technological differences? Sorry about that. :)

                    2. 3

                      Guix is or was based on the Nix daemon and essentially just a fork, substituting the Nix language for scheme, plus the requirements for packaging. This was several years ago now, it may have diverged further.