I really like the idea and architecture of GUIX and I find it like a better design overall than Nix... but unfortunately, being under the GNU, support for proprietary firmware and Operating Systems (i.e. Mac and Windows) makes it really hard for most of us who are using those systems and don't really feel like running a VM just to use whatever software.
I wish they had a separate spinoff that just made sure their software can run on Windows and MacOS, something like exists for emacs, but I think that the challenges are pretty big as they appear to rely on Linux-only APIs?
The challenges are more political than technological. They prefer not to compromise their choice to use only Free Software, which is their right, of course.
However, I've run into a GUIX person or two who frame it as a technical issue because something like macOS lacks a completely verifiable build chain (i.e., needing to use XCode to bootstrap). This is a factual statement, but not the real reason why support for macos/windows is absent.
What is the real reason then? Please enlighten me, because I have been blocked by these technical issues in my past attempts to bring Guix to macOS. Guix is built around glibc and there is no glibc port for macOS. Using XCode for everything is like replacing a bicycle drive train with a steam engine; I guess it's still a vehicle of some sort, but Theseus is still unhappy with his new ship.
Unwillingness to compromise, as you might recall from our last conversation on the topic. This is your right, but framing it as a technical problem is incorrect.
You don't have to use it for everything, that's a straw man. If Guix-darwin was willing to accept some impurity, you could probably use XCode just enough to bootstrap a glibc and compiler chain, and then dispense with it.
Having a completely verifiable toolchain is a laudable political goal, not a technical requirement.
nix-darwin's existence clearly shows there are no technical obstacles to an equivalent guix-darwin.
Believe me, I wanted to like Guix. I'd prefer a Lisp over the nix language, easily. But I'm losing respect for the project based on its messengers.
Humans already have ways to build software on macos, so why bother doing it with something called "Guix" if the thing that we would necessarily --- and for technical reasons --- end up with bears little resemblance to Guix? If someone sees value in that, enough to warrant converting resources to realize this value, they are welcome to do just that.
Note that we also have a way of using Guix as it is on macos via virtualization of Guix System. It also sits atop a large binary blob (the size of the native bits of the qemu closure), just like a macos-native bootstrap of the roots of the Guix graph does.
We're going around in circles now. I believe the Guix equivalent to something like nix-darwin would still be sufficiently guix-like (like a new language impl) to be worthwhile. You believe it wouldn't be guix, and iiuc, nothing short of your vision of guix would be guix, and since that can't be done from top-to-bottom on macOS, guix can't be done. I take it you don't view nix-darwin as nix?
And yet, the nature of identity is always in flux. You are not made up of the same atoms as when you were an infant. Many lines of code in a software project change, and yet it remains the same, ship-of-Theseus style.
Guix's identity could encompass a guix-darwin side project and still remain guix. You think of it as a technical issue, but it's only your choice of what guix means that entails that view. Which comes right back around to my assertion that no macOS support is fundamentally a political choice of guix's devs, not a technical problem.
> end up with bears little resemblance to Guix
Based on my experience with nix-darwin, this seems like exaggeration, and I think most others would agree.
> Note that we also have a way of using Guix as it is on macos via virtualization of Guix System. It also sits atop a large binary blob (the size of the native bits of the qemu closure), just like a macos-native bootstrap of the roots of the Guix graph does.
You are possibly the only person who is using "binary-blob-at-root" as equivalency criteria. Are you genuinely confused why macOS users aren't just using the Qemu Guix? Part of the appeal of nix/guix on mac is not having to pay the virtualization cost.
Guix has the nonguix channel, which provides the vanilla Linux kernel and other packages that contain blobs or nonfree parts: https://gitlab.com/nonguix/nonguix/
I wish they had a separate spinoff that just made sure their software can run on Windows and MacOS, something like exists for emacs, but I think that the challenges are pretty big as they appear to rely on Linux-only APIs?