Not completely related but I decided on my latest GNU/Linux distro install that I much prefer the macOS model with slow updates for the major stuff with optional use of Homebrew and other updating mechanisms for the add-ons. One of the things that I got tired of was having to run updates on Fedora, Ubuntu, etc. So I decided to install Debian Stable with the Nix package manager as a sort of Homebrew replacement. This way I don't have to worry about my distro breaking, while I can get new stuff that is atomic and easy to remove when I want. I am curious if any Guix users do something similar.

I like Gentoo for this reason. I can leave core elements and stuff I don't care about on "stable" while selectively choosing "unstable" for things I use every day. Unstable is pretty stable for the most part. The nice thing is the stable core is still rolling so no major updates.

Gentoo was too hard for me to install (command-line partitioning is just too risky) so I ended up using Redcore, which has a nice GUI installer, and is Gentoo-based.

command-line partitioning is just too risky

So partitioning a device is less risky with a GUI? That doesn't make sense.

EDIT: I should be more constructive:

I know that the command line scares some people, but that's just like computers in general scare most people, it's just something you have to get over with.

Another "scary" thing is the choice that exists between multiple available partitioning tools, I know it took me some time before I decided that the good old fdisk was my choice, but really, it probably doesn't matter, any should be OK. You probably won't actually do it directly from the command line anyway, e.g. fdisk is dialog driven instead.

Lastly, I doubt that it isn't possible to fire up Xorg from the Gentoo install media and then partition from a GUI tool, if that's what you want.

I personally find it easier to see the gui layout of my disk before I press play. Gparted can queue and execute a lot of changes to get to your desired state. Very intuitive for people like myself who doesn't deal with partition layouts and filesystems on a daily basis.

To reiterate the point you are replying to:

Using a command-line partitioning utility like parted or fdisk is more risky to interface with, at least for the layman.

Am I using GPT tables? How many blocks for this partition again? What partition type am I marking this? Am I using a capital G to denote gigabyte? A plus sign before or after the number? What is the current state? What is the planned state?

These aren't particularly difficult questions, but they are more easily answered when using a GUI tool like GParted than they are when using fdisk or parted.

GParted is an excellent GUI. I personally haven't seen a more reliable and usable partition utility. It's my first and last recommendation, no matter what the user's background, and it will likely continue to be for a very long time.

Cfdisk. Much better and still terminal based.

You can always boot any Linux rescue system (Knoppix) and use gparted to figure out the partitioning, then continue their cli install. I do agree that partitioning by commandline is scary biz. A good TUI (think weechat, htop, tmux quality) would do great for this purpose. That is, if the machine is a pet and not cattle.

I used Gentoo exclusively for 5+ years (around 2002-2007) and after the umpteenth update which broke printing, I switched to Debian stable, and will probably use it for the rest of my life. Being able to get stuff done without having to worry about random stuff breaking was a very positive life change. Back then most Gentoo ebuild authors updated versions of all dependencies of a package, as well as the package itself, which

I have several machines running NixOS and one running Guix.

In Nix you have several channels that push package updates. The stable one moves very slowly, and because Hydra tests packages, it's really rare to experience broken things.

You can also mix them and e.g. install some packages from unstable, and keep others from stable.

Additionally Nix and Guix provide easy total and partial rollbacks, so you should not be afraid of breaking anything.

Have you preferred Nix or Guix (specifically in writing the configuration/managing the system)?

Might as well try out NixOS.

I've been using it on all my personal devices for ~6 months and also for some bare metal sever deployments.

A (mostly) immutable system configured with a single config file is an absolute killer feature.

The ability to roll back to a previous config in the bootloader or the terminal is brilliant.

And home-manager [1] provides the same experience for your user environment.

I also looked into Guix, but the community and package repository seem much smaller.

They also don't accept proprietary software in the official package repo. Which is a respectable ideological choice, but really reduces usability a lot compared to nixpkgs.

[1] https://github.com/nix-community/home-manager

I tried to install NIX, but the graphical installer wouldn't boot. I'd have the option to choose it in GRUB, but it went to a command-line.

Then when I tried the text-based install, it couldn't see my NVME disk.

Weird, i stumbled through NixOS, a dual boot grub setup, and backed by NVME with no issues and very little Linux information to start with.

Currently on NixOS btw, been a great experience from it so far.

My SSD is an Intel 660P, if that helps debugging in any way. Installing using nixos-gnome-20.09.1889.58f9c4c7d3a-x86_64-linux.iso.

Like the other replier, I also found NixOS very difficult to install and my hardware wasn't supported as well as Debian was.

I really agree with this in concept. It's frustrating to me that in practice, Homebrew wants to own /usr/local: https://docs.brew.sh/FAQ#why-does-homebrew-prefer-i-install-...

I know the "cool thing" these days is homebrew, but there's also MacPorts [1] which I would say it and aligns better with the "use a stable base + compile the latest things" approach.

MacPorts does not use the base system to compile the latest things on top. Instead, it creates a "parallel system" where everything is installed from MacPorts (and hence you all dependencies are continuously updated) for the "latest stuff" you install through MacPorts, while not touching the system stuff at all.

[1] https://www.macports.org/

What do you think of using pkgsrc on the MacIntosh?

https://www.pkgsrc.org

I'm running Guix on Void, but I think Guix on Debian (experimental) is better supported [1] and what I plan to switch to eventually.

[1] https://lists.gnu.org/archive/html/guix-devel/2020-11/msg002...

I was complaining how weird the Nix language is, until I saw Scheme.

What would be less weird (and why)?

The release song slaps. Love the beat.

I tried installing GUIX on my 2013 MacBook Air 11" on Sunday night.

The installer insists on erasing the entire disk, not sharing with other partitions.

I removed the SSD for safety, and plugged in a second USB stick.

The installer took from 21:20 to 7:30 am the next day. It needed to be connected to wired Thunderbolt Ethernet, which in my case means in the laundry.

Downloading packages took a long time (about 2 hours). "grafting" took longer. Finally it failed to set up the bootloader. No big deal, try GRUB or rEFIt, right? But they didn't detect it.

There is an "EFI Boot" option in the startup menu (holding option). That just boots to a black screen.

I'm sorry, but issues like this mean that I think GUIX is not desktop-ready for bare metal. It'll be relegated to a virtual machine (along with OpenIndiana, PureOS, Haiku, Hello, etc).

You are aware that you are trying GUIX out on hardware which has been tightly locked away from being interoperable with anything besides MacOS, right?

Are you aware that Apple hardware pre-2015 was much more open than it is today? I agree with your sentiment for modern Macs, and that's why I'm trying to find a suitable OS for switching.

When there's a limited scope of what drivers are required, it should be easier, not harder, to support certain hardware. Being unable to read NVME drives (which have been around since 2011) is no longer acceptable for an OS in 2020.

What made you pick guix over nixos?

I tried both.

Choosing NIX - Installer from GRUB just boots live, not actually an installation process.

I tried copying the USB stick to a partition using cp -Lr. Still not booting. I tried manually specifying that partition using GRUB. The errors were:

Timed out waiting for device /dev/root, trying to mount anyway.

mounting /dev/root on /iso...

mount: mounting /dev/root on /mnt-root/iso failed: No such file or directory

At that point I gave up.

I love Guix in theory, but I have a lot of issues with performance. Literally orders of magnitude slower other package managers. Downloading is slow, even if the total download size is small. Recently, it took two hours to upgrade Julia because, I guess, it wasn't available on the substitute server.

When you think of Guix as a source distribution first and a binary distribution second this makes sense. The build farm is just another user that builds everything from source. If it didn't catch up with the builds because someone just changed a package definition then you might be requesting a binary that hasn't yet been built.

Slow download appears to depend a lot on location to an extent that we suspect peering problems. The main build farm's head node is connected to the internet from a well-connected research campus with dual 10G. Multiple tests have concluded that the configuration from server-side software, to network hardware of the server, down to networking in the data centre is sane.

Maybe we'll have to bite the bullet and (again) use a CDN to better serve users that inexplicably experience slow connections.

What about integrating (and encouraging users to opt into) peer-to-peer distribution? If I understand correctly, this would work for Guix and Nix.

I'm not using Guix, but if I was I would be happy to do this. I have no data cap on my home internet, and my PC is usually on.

What are the security implications of this?

The implementation requires that you have at least one authorized substitute server advertising the same hash.

In simplified terms, if ci.guix.gnu.org advertises a substitute for /gnu/store/abc123-foo, with the checksum "xyz789" (and the cryptographic signature of that advertisement checks out), your daemon can safely download that file over P2P.

Ah, I think I'm misunderstanding the intent here. Clearly P2P distribution of checksummed binaries can be safe, I was just wondering if there were a solution to the build farm being behind. It seems like you can't really trust the first build of any artifact unless it comes from a central source.

There have been discussions of an "N of P" distribution, i.e. if 80% of available peers (or substitute servers) advertise the same build result, then treat it as safe.

I expect that both will be implemented, and the choice left up to the user.

I firmly believe that Nix (and/or Guix) are the future. I am going to use Nix as the keyword below, but Guix and Nix are so very similar that everything is also true for Guix.

Snap, Flatpak, Docker, AppImage, etc are all very complex solutions that are actually quite painful to interact with. Nix on the other hand solves the problem extremely well. You can have different complex applications running side by side with very different dependencies trees and they will not cross paths.

Every time I see a package being distributed as a Snap, I wonder why. These containered solutions are very complex, trying very hard to emulate FHS with mount namespaces, binding mounting tons of sockets around, and almost always end up mounting all of /home in the container. The don't provide much security, and quite difficult to deal with, and require a daemon.

Nix on the other hand has zero containerization requirements. It simply works by ensuring the programs are looking in the right place for the libraries they need. It would be great if more vendors just shipped a Nix derivation (or store path) that was their application stack. It would end version incompatibilities for ever, in a way that isn't a burden for the user.

Nix + bubblewrap add all the benefits of snap and flatpak as well. But again, there is no benefit to bubblewrap is if you are just going to blanket allow read-write everywhere anyway. At least with raw bubblewrap you can make these policies actually protect something.

Similarly, Nix is easily installed on any existing system. So you can use nix packages on Debian, Ubuntu, Centos, Fedora, DSL, or any other linux distribution because it runs entirely out of /nix. I use nix packages on Archlinux at home, and Debian systems as work.

Cross distro development works 100% of the time because Nix doesn't use anything from the distro.

Nix (and Guix) are really what the Linux community should be moving towards IMHO. I personally prefer Nix's syntax, but the underlying technologies are so similar I consider them the same. Guix started as a fork of Nix, and one day I hope they decide to end up becoming compatible with each other again.

Guix started as a fork of Nix

This is repeated often but it is an unfortunate misunderstanding. One self-contained component of Nix was used unaltered in Guix: the nix-daemon. Everything else but the daemon (and that's a lot) is a completely independent implementation of the same principles that were first demonstrated in Nix: functional package management.

Why reuse the daemon? Because it could be done. The daemon takes very low level build instructions ("derivations") and arranges for them to be executed in an isolated environment. In Guix derivations are generated through compilation of higher level concepts that as such have no correspondence in Nix.

The common ground is the format of the derivation, which has only been modified occasionally to better suit our differing needs.

My point was more than guix and nix could both write to the same store using a single daemon compatible with both in the future. Ensuring some cooperation between the two going forward.

That currently isn't possible, but would be nice.

I imagine it could only work for packages, not for system configuration. But that still would be a huge win.

System configuration is also just another store item, really. The current development, however, is to move away from the old nix-daemon and to (slowly) finish its replacement that reuses all of the other existing Guix features for process isolation and building.

This is desirable as there are minor annoying differences between the build environment spawned by the C++ daemon and the environment one would get using "guix environment --container". Unifying this by simply using Guile on both sides of the divide (build side vs host side) would allow for more code reuse within Guix and unlock a few features.

It's not a high priority because the modified nix-daemon works fine for now, but a CS student is moving forward with the Guile daemon as a university project now.

So the dream of sharing the same daemon may not be realistic. I think that this is not a big deal, because the daemon really should serve the project and as the needs of the two projects diverge so do their respective daemons.

One thing that flatpak has over nix is the set of common bases. If I was going to distribute something shifted from nix, I'd essentially need to move every single dependency (which needs to be compiled/configured right). It's not a huge problem for a cli tool in golang, but something that requires qt, GL, input method support, etc.? I'm glad there's a flatpak base for those that not only "just works", and it's going to be maintained/distributed even of the app isn't.

I'm not sure I understand this argument. The main difference when compiling is that you use --prefix=$output instead of --prefix=/usr (which is nicely abstracted away by build systems).

You can 'guix pack -RR ibus qutebrowser', copy the resulting binaries to any GNU/Linux system, and still expect them to work.

Yes you can, but you have to compile and distribute them all. And again distribute every single update for them. You end up with "nothing changed in my app, but there's the whole package again with a fixed deep dependency of foo". (Or more likely, no update)

Right. Referring to exact versions of dependencies is a feature of the functional package management model. How else can you guarantee that the program will behave exactly the same every time you run it?

Guix (unlike Nix) supports "grafts", so you can change something deep in the graph without having to compile every dependent package again. But grafts also produce different store items of course, so no big difference for "guix pack".

You can also do this in nix.

https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...

And it depends on your use case - whether you want to guarantee exactly the same behaviour and ship all the dependency updates yourself; or do you want to have less maintenance burden and trust the base layer to not change behaviour.

In a tightly controlled environment inside a company where the update mechanisms are preconfigured / enforced, I'd go with nix model. When distributing an app to people on the internet, I'd choose flatpak model.

Nixpkgs already packages all of the things you've mentioned (qt, GL, input method support). So to package your own software with Nix, all you have to do is specify them as dependencies. There's no need to "move every single dependency" at all.

Nix and Guix have too steep of a learning curve. Maybe someday I'll be willing to invest the time to understand what's going on, but the CLI and docs just aren't good enough to go from "I know nothing" to "ah, I can install the latest <firefox,inkscape,chromium,etc.>". It really isn't clear to me how to switch a running system's package manager to either or even if either is fit to be the system's main package manager.

I watched a video of a seasoned linux user trying to install nix and abandoning the procedure because of the lack of docs. I even downloaded a virtualbox image of NixOS and tried to update everything to the latest version: 30 minutes later only firefox was installed but it wasn't in PATH thus couldn't be executed. Never found out how to install the KDE desktop.

Guix was another beast that I tried installing as a non-root user (insisted on using `curl | bash`, which I loathe). It was never up to date and I couldn't find the package I wanted to install (so fancy new chromium wrapper.. next-browser or something).

Maybe now things are better, but back then (1-2 years ago), neither were anywhere close to modern GUI distros. Until they make it easy to use, it's going to stay niche.

I found the documentation to be plentiful compared to other projects, though it's not as comprehensive as the Arch Wiki. The docs definitely mention how to install KDE [1] and firefox [2].

To learn more about Nix, I'd recommend grepping the nixpkgs [3] repository once you grasp the basics of the Nix language (Nix Pills [4] would be a good start for that). Since everything in the Nix official repository belongs in nixpkgs, it's easy to search for the information I want. I just wish CentOS and Debian had a way of searching across the entire codebase this easily when I couldn't figure out something from the docs.

[1]: https://nixos.org/manual/nixos/stable/#sec-x11 [2]: https://nixos.org/manual/nix/stable/#idm140737322634320 [3]: https://github.com/NixOS/nixpkgs [4]: https://nixos.org/guides/nix-pills/

I filed a PR in the nix pills repo like eight months ago that never got touched; they're effectively abandoned and contain hard errors. One more snare trap in the mine field that is nix documentation.

To anyone that wanders by this, if you value your time at all, don't bother with nix unless you have someone you can corner and directly get answers from.

I just wish CentOS and Debian had a way of searching across the entire codebase this easily when I couldn't figure out something from the docs.

You can use https://sources.debian.org/ website to search in the Debian packages and their source code.

Snap, Flatpak, Docker, AppImage, etc are all very complex solutions that are actually quite painful to interact with.

Uh... what? You're comparing these things against Guix and Nix, which require you to learn a new language to use. Not to mention that AppImage, at least, is only complex because it kinda has to be in order to be portable, single-file, directly-executable application. Which is to say, it is only complex in its implementation so that it can be much less painful to interact with [0].

Nix on the other hand solves the problem extremely well. You can have different complex applications running side by side with very different dependencies trees and they will not cross paths.

Which AppImage can do without you having to learn a new language, and as a bonus will even let you store those applications on entirely different media without recompilation or anything.

Similarly, Nix is easily installed on any existing system.

AppImages work on most Linux systems, which is about as well as anyone can do with something that requires no pre-installed runtime.

[0] and it actually isn't that complex really.

Guix and Nix [...] require you to learn a new language

Not true.

`guix install foo`, done.

Oh, you want to define an operating system declaratively in a file? Yeah, learn the DSL that was designed to let you do just that.

So the thing that is the primary value proposition of the system, yeah?

I think the package managers themselves, with unprivileged operation, immutable profiles, atomic upgrades and rollbacks, "guix pack", etc are the main value propositions.

The OS thing is mostly a side effect.

Maybe I'm misunderstanding, but isn't part of the point that the packages themselves are declarative and you're not beholden to some maintainer to get stuff? Wouldn't that mean writing your own... whatever it is your write to get software installed?

Not sure about guix but the unprivileged part isn’t true of nix as you do need root to install initially.

The problem with nix is that it defeats the purpose of shared libraries. Normally, when you upgrade a shared library, all consumers of it get fixed for free.

With nix every package is siloed into its own separate dependency graph and so you can have many versions of a shared library coexisting on the system but each version may be used only by one consumer. That means upgrading one will not affect all the others.

So then the only way to get consumers of a shared library to upgrade is to upgrade the consumers as well. Well then why not switch to static linking and be done with it? It would be much simpler that way.

nix/guix = academia and like conceptualism

others = industry and leverage existing subsystems

that's why

I don't know what you think is needed for nix/guix that has not existed the past 20 years.

All the other technologies I mentioned require fairly recent kernels to work, namely for all the namespace shenanigans they employ. Nix can run on perfectly fine on at least Linux 3.2 (stock wheezy), so far as I tested.

I think this is about right.

Nix feels pretty close to "right thing to do", but if the other solutions are more successful, it's a case of "worse is better".

I think the important part is usability compared to what's already there. It's much easier to write a Dockerfile than to write something with Nix. You can get much stronger benefits from Nix than from a Dockerfile.. but, most of which you don't really need all the time.

My impression is the other solutions are quick-ish hacks to solve problems that come from (and building upon) the complexities of systems built using quick-ish hacks. Nix feels like a more elegant solution, but it's also different enough that it's got a steep learning curve for anything harder than "install foo".

I think users may find it easier to create a Docker image with `guix pack -f docker app1 app2` than to write a Dockerfile.

As a bonus, the resulting Docker image is bit-reproducible and recipients of the image can "map it back" to the original Guix revision.

https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack....

I don't understand some details about Nix when people talk about it. Forgive me for being ignorant.

* Do packages need to be 'ported' to Nix or its build / install system? If so, how much effort will it take and on what factors the effort required to port may vary substantially? (eg: Programming Language).

* How is disk space usage? Is there any kind of deduplication?

* How are security updates to shared libraries handled?

* Transactional upgrades look great. But how is the user experience around Transactional upgrades of running GUI applications?

* Other performance characteristics - bandwidth (delta upgrades possible?), startup time (I hope this will be good)..

Note: these points concern Nix, the situation may be different on Guix

* Do packages need to be 'ported' to Nix or its build / install system? If so, how much effort will it take and on what factors the effort required to port may vary substantially? (eg: Programming Language).

Yes. To make Nix really work it has to be pervasive and this sometimes means porting packages again, however there's a lot of automation around this, see[0] for ones that leverage existing build systems in other languages. Autoconf and cmake packages are already accounted for by the default builder, and usually only the dependencies have to be specified.

* How is disk space usage? Is there any kind of deduplication?

The Nix store can be intensive on memory, as once a dependency such as glibc is updated, all the reverse dependencies (i.e. the set X such that X depends on glibc directly or transitively) have to be rebuilt as well. There is an option to optimise the store, but I don't know how much it helps in practice, see[1]. Garbage collection can be invoked manually or automatically to free up unused store entries.

* Other performance characteristics - bandwidth (delta upgrades possible?), startup time (I hope this will be good)..

By startup time you might be referring to NixOS. It's very good on my Late 2013 13-inch MacBook Pro, around 20 seconds to go from cold boot to login screen.

[0] https://github.com/svanderburg/node2nix https://github.com/NixOS/cabal2nix https://github.com/cargo2nix/cargo2nix https://github.com/nix-community/poetry2nix https://github.com/kamilchm/go2nix https://github.com/nix-community/pip2nix

[1] https://nixos.wiki/wiki/Storage_optimization

By startup time you might be referring to NixOS

I was referring to application startup which is an issue for snap & flatpak. I'd like to know how it (Nix + sandboxing solution like bubblewrap) compares to flatpak.

Yes they need to be ported, in the optimal case it's just specifing the build dependencies and the build command.

It's deprecation addressed so you only store any given dependency & version once, but if you need multiple versions you store each.

It's easy for the storage size to balloon, but also easy to garage collect away stuff you aren't using without worrying about it

You update the library and every thing it depends on

You need to restart the gui application after the upgrade

The download size can be big, I haven't found it much more inconvenient than other distros

Start up time is unremarkable

And it is easy to install software that's not packaged by distribution, ungoogled chromium [1]:

    $ nix-env -iA nixpkgs.ungoogled-chromium
    $ which chromium
    /home/sergeykish/.nix-profile/bin/chromium

[1] https://search.nixos.org/packages?channel=20.09&show=ungoogl...

Or:

    guix install ungoogled-chromium

This CLI difference is in part due to the underlying design, which is not just about syntax (parens vs. braces) but more about abstractions and composition.

For example, the Nix language doesn't have the ability to define new data types, and it doesn't have a "package" or an "operating system" data type. That means that all the entries in Nixpkgs look alike, which in turn prevents building a "package-aware" or "OS-aware" user interface.

The Guix CLI "knows" about packages and versions, and package transformation options are an example of how the CLI can take advantage of that abstraction.

Likewise, the "guix system" command knows about services, which gives it convenient introspection capabilities such as "guix system extension-graph" and "guix system shepherd-graph".

It really isn't about parentheses vs. braces. :-)

This is what annoys me about Nix the most - the missing abstraction of those, resulting in an often cumbersome UX and a very steep learning curve.

Guix on the other hand provides those, but is far from what nixpkgs offers in terms of number and actuality of pkgs.

I think it's somewhat unfair to use number of packages vs Nix as an argument against Guix.

Nixpkgs has the biggest package repository of all the distributions, and a much larger community.

If you compare Guix against Arch for example, Guix comes out more favorably (15k packages) vs Arch's 12k.

Guix packages tend to be very well integrated too, usually running upstream test suites, leading to fewer run-time problems. I think only Debian and Fedora matches Guix on this practice.

Armchair package user litmus test:

1. Is there a LTS Firefox package in Guix?

2. Is there a LTS Chromium package in Guix?

3. Is there an escape hatch if I'd rather just download an Electron binary for my package dependency rather than properly package Electron?

As a user of both Nix and Guix, Guix really needs to do a thousand papercuts campaign because there's so much low-hanging fruit here.

The Nix shell script installer is a one-time that you can rerun without it reinstalling Nix (it will just skip if it detects an already existent Nix). Guix reinstalls (and take forever doing it). The Nix installer is much faster. You also need to make sure you import keys when installing Guix because security.

Doing any package related thing will tell you about a failure to install locale. This is straight out of the box Guix if you've installed it on, say, Ubuntu. This is not a good out of the box experience. It blows. If you Google this error you are told to install glibc-utf 8-locales but on my Ubuntu base system this doesn't actually solve the error.

If you the user can clamber over these two landmines well it's an awesome Emacs package repository. This is actually where Guix wins over its cousin and as an ardent Emacs user its fantastic to have all the most esoteric packages and weird builds of Emacs like emacs-pgtk-native-comp I source from a Guix user channel and install declaratively from a manifest.scm file.

Guix should lean into this one major strength and put out an Emacs-centered heavily opinionated installer image that uses EXWM for its window manager.

The Nix shell script installer is a one-time that you can rerun without it reinstalling Nix (it will just skip if it detects an already existent Nix). Guix reinstalls (and take forever doing it).

Wait, what? The Guix installer script also stops if it detects an existing installation, and has done so since the initial commit:

https://git.savannah.gnu.org/cgit/guix.git/tree/etc/guix-ins...

You also need to make sure you import keys when installing Guix because security.

If you are complaining that the installer verifies the GPG signature of a file it downloaded from the internet, I don't know what to say. :-)

Doing any package related thing will tell you about a failure to install locale.

This can happen when your installed locales are from a different glibc than what the guix-daemon was built with. Upgrading and restarting the daemon will solve it.

That said, I think the daemon recently got smarter about it.

Guix should lean into this one major strength and put out an Emacs-centered heavily opinionated installer image that uses EXWM for its window manager.

The system installer disk image does give you an option to create an EXWM system (as well as GNOME, Xfce, etc).

Wait, what? The Guix installer script also stops if it detects an existing installation, and has done so since the initial commit:

You're right about this, apologies. What I intended to convey was that Guix hard bails on an install so can't be scripted as part of a "dotfiles up" on a new system. Nix gracefully bails and can therefore be scripted.

This can happen when your installed locales are from a different glibc than what the guix-daemon was built with. Upgrading and restarting the daemon will solve it.

This is from 5 minutes ago. I have both glibc-locales and glibc-utf8-locales installed:

/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)

If you are complaining that the installer verifies the GPG signature of a file it downloaded from the internet, I don't know what to say. :-)

Speaking strictly from the perspective of a desktop end-user, this should probably be rolled into the one-liner.

And, as I'm testing, I also notice that even for operations which require no changes, a guix pull takes 5 or more minutes over the equivalent nix operation. Why am I building guix-system for 5 minutes with nothing to be done?

I urge you to take all of this as friendly advice from someone who fits into the market category of Guix's next million users. How you capture them is by removing the barriers to entry, streamlining the package management process, and massaging over papercuts that a brand-new user won't have the patience for.

The system installer disk image does give you an option to create an EXWM system (as well as GNOME, Xfce, etc).

This is awesome. :-D