Yeah pretty much, the best example I have found for showcasing a solution to this issue is this[1] example, where you can see we start from the most basic of "compilers" (quite literally the equivalent to a `sed` command) and work our way up to Linux 4.9 if I remember correct. Biggest issue is circular dependencies (a lot of lower level build tools depend on themselves nowadays, so we end up needing to build like 4-5 older versions to work our way to a modern toolchain) and different architectures. Since x86 has always been a given, having a completely bootstrappable toolchain on something like arm or even risc-v is a more complex problem, where older versions of programs needed may not necessarily compile or be able to compile further programs on these architectures.
So the store itself is still located in '/', it's in '/gnu/store'. However, the location can be changed when building guix (you would need to compile it yourself) with the ./configure options --with-store-dir={PATH}. (The /var/guix path you referred to is the state path, where guix stores accounting databases and stuff for it to actually track the store)
EDIT: I forgot to mention, do not do this. If you want the store in a different location, set up a bind mount. Guix makes assumptions that would make it so you no longer could use substitutes (binary downloads of packages), so keep that in mind.[1]
I've been using Guix for about the last year and a half at this point (and is coincidentally most of what I post about on this site) and Guix certainly has its ups and downs. Most notably, for me, Guix is leagues slower than Nix it seems, since I use both on my system with Guix as the main distro. Also, just generally less packages and the ones that are present are out of date. However, the architecture of Guix means it can be extremely easy to bump versions of packages as long as dependencies or build options haven't changed too drastically. You will inevitably need to run your own channel on top of your system to actually house these version bumps (before you upstream them!) and packages that you package yourself (again, try to upstream if applicable!). I'd say that about 30-40% of my packages have been modified by me in some way or another, whether it be a complete rewrite of the definition, build option modifications, or just a simple version bump while we wait for it to appear in the upstream repo (more "core" packages, like bluez and those type, get updated less often since that triggers a rebuild of all packages that may depend on it). It definitely isn't for the faint of heart, but I find it rewarding.
Some exciting changes are upcoming too, like the addition of being able to boot from UKIs rather than being stuck with GRUB, which probably won't happen for a bit still, however I think this ties into the broader "issue" with Guix.
The community is small, which is definitely a result of it (just like Nix) being more complex than the average distro that people do not want to deal with, compounded by the fact that it uses even less standard utilities to build the system (like not using systemd as a service manager in lieu of shepherd). I feel a lot of the pain points that Guix has can be addressed just by having more eyes and hands on the project. If anyone has more specific questions on using Guix I'd be more than happy to give my view.
I believe so! I did some messing around with the whole "bootstrappable" suite of repos a few months ago and I remember there was a repo [1] that automated the chain of bootstrapping from a project known as hex0 to Linux 4.9 (iirc) inside qemu using fiwix as an intermediary. I didn't have the time to experiment past running it and verifying it works (it did, took my poor laptop around 10 or so hours to run from start to finish), but I presume I would have been able to compile the latest versions of GCC and Linux from the final state of the VM it made. I may still have the image it made lying around somewhere.
I will admit, I was hesitant as well, but so far it's been fine. The #guix community on libera.chat is very active and has been nothing short of amazing in helping me understand the ins and outs of Guix. For any non-free software I use, #nonguix in libera.chat exists. It's less active but still pretty active (plus I pop in occasionally).
No, feel free to use the official guide, it's still very, very, very helpful. Yes, you do need to use an unofficial image, but that's just if you have hardware that requires non-free drivers (or blobbed drivers, Guix uses Linux-Libre by default).
Not the best of circumstances, I know, but it works (plus if you really wanted to, they give the derivation details in the release notes so you could just spin up a Guix VM which runs fine with the default image and generate the image yourself).
I've been using Guix for a bit over 2 months at this point and honestly the whole 'non-free' software thing has not been an issue in the slightest. Use the System Crafters installation iso [1] to get around driver issues on install, and then the only time I've ever had the system complain to me was it warning me one of my hardware components wouldn't work (which it did, since the System Crafters ISO uses the standard Linux kernel). Afterwards, just add nonguix (and I even added Nix as well, so I get the best of both worlds!) If a package isn't in Guix and I don't want to make a package definition, I simply pull it using Nix home-manager. May not be the best or 'proper' setup, but I find it works well enough. [2]
Made an account just to say this: anyone who hasnt heard of the SIGBOVIK conferences should look up the minutes from this year and read through some of the papers submitted, maybe even go through a few years.
[1]: https://github.com/fosslinux/live-bootstrap