GNU Guix 1.4.0 released


The (transparent ?) support of long long-term reproducibility with the help of Software Heritage archive is particularly elegant, I wonder how to do this with Nix/Nixpkgs.


@lewo was/is? working on that for nixpkgs GitHub - nix-community/nixpkgs-swh: Send nixpkgs tarballs to Software Heritage [maintainer=@nlewo]

1 Like

Another guix shell innovation is optional emulation of the filesystem hierarchy standard (FHS) . The FHS specifies locations for different file categories— /bin for essential command binaries, /lib for libraries, and so on. Guix with its store does not adhere to the FHS, which prevents users from running programs that assume FHS adherence. The new --emulate-fhs (or -F ) flag of guix shell , combined with --container ( -C ), instructs it to create a container environment that follows the FHS. This is best illustrated with this example, where the ls command of the coreutils package appears right under /bin , as if we were on an FHS system like Debian:

This is so cool, having something like this as a first class feature of nix will remove a lot of beginner frustrations.


Wow, Guix has a ton more packages than when I last checked! Looks like the size of the Guix package collection has doubled in the past 3 years, much like Nixpkgs.

It’s great to see that project flourishing and pioneering new features. The package transformation CLI options look great! They remind me of some of the conveniences from Homebrew like --head, but better.

It is a bit sad to watch the Guix CLI so eclipse Nix’s, though. I like many of the improvements of the experimental, flakes-based CLI, but even that is not close to keeping pace with the excellent UX work happening on the Guix side!

I think I’ll have to give Guix System a serious try soon, especially since KDE support is starting to come in.


I agree, there’s something baffling about how Guix can advance so fast, even though it has way less contributors. Must be something about governance, but I don’t know much about theirs.

Also (and I’m repeating myself): their artwork!!

One thing I’m not sure about is whether using systemd instead of GNU Hurd is possible.


The fact that flakes have been “experimental” for so long is pretty bad for adoption. Let’s say you want to start using nix. You come across documentation for flakes and non-flakes. So you look into the difference. Flakes are the have been around for years, are the future, yet are still “experimental”. The “stable” way is considered legacy. What do you choose? It’s lose lose. For me the obvious choice is flakes but I could see how someone just getting into nix might not come to that conclusion and just give up on nix entirely.


Hurd is the kernel, the GNU Shepherd is the init system. A bit confusingly, perhaps, it’s systemctl equivalent is herd with an ‘e’. Guix System supports Linux as well as Hurd, but there’s no Systemd package in Guix yet, let alone Systemd support for Guix System.

What makes you interested in running Systemd with a Guix-based OS? Reusing upstream unit files?

Thanks for the clarification, I was indeed confusing Herd and Hurd :slight_smile:

Simply that I don’t want to learn another init system, and I’m quite happy with systemd.

Is there something about Guix SD that makes systemd less useful than on NixOS?

Just that packages can extend the whole init system in an Emacsy way, since the entire thing is also written in Guile Scheme

Emacsy? Just because Guile is a lisp dialect?

It would be really nice, if nixpkgs could be implemented in a Lisp/Scheme like language.

1 Like

The few guix packages I have seen so far had all one thing in common: they where extremely verbose. In nix specifying a hash is just assigning the hash to hash or in older code to sha256. In Guix you first specify I have a hash and then what type that is and then that there is a string for it.

Also easily and programmatically transforming code is built into scheme making such a command really easy.

If we would do the same for nix we could easily end up in a rabbit hole where building the automation took longer than just doing it by hand.

We have fhs envs as a first class feature in nixpkgs already. Adding a subcommand for that to nix is pretty easy but could easily fall into feature creep.
Also fhs’ are not always the solution to easily run something and could easily lead beginners into traps they can’t solve, yet.

Some challenges include:

  • there would need to be flags to add targetPkgs and multiPkgs to the env unless you want to end up early bloated like steam-run
  • then there needs to be an easier way to discover the location of files within in packages. Switching command-not-found to nix-index is a good step into that direction. A step after that would be to expose it in on
  • the fhs environment can be weird and confusing. For example up until recently vscode-fhs did not expose /etc/nixos.
  • programs started from within it behave differently then from outside. Most prominent xdg-open is often not working as expected.
  • fhs must be presented as a last resort to packaging when there is no source available or the package build system is so complicated/custom that it cannot be used without major work done

The grass seems always greener on the other side on a first high level view especially if you know nix with all of its good and bad parts.

Is Guix really not using systemd?!
In a perfect world with unlimited time (and maybe no sleep) … but we are not living in such a world. Also I like to use KDE where you have a really hard time without systemd and I personally like to spend my time not in a such an uphill battle.

Also in my social circles GNU Hurd is a joke with no audio system.

Good things take time and if they are not done yet, time isn’t up. I’d rather wait a few more years rather than having flakes 2.0.

Bummer and that’s a killer reason for me.

For example even if they are most of the time basic and need to be edited.
The bigger problem is support, knowledge, help and my time. I don’t expect to receive much or any support from upstream with shepherd. I am using software which is build on top of systemd features and would need to be ported. That all takes time which I don’t need to spend it I just stay with systemd. Sunken cost.

Without having any proof of this it immediately wakes fears in me of having to debug the init system itself. Frankly I feel much happier knowing that after boot stage1 most things cannot mess that much with the init system.

maybe at that point you could just build systemd on top of guix.

Hosted by Flying Circus.