Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No, Guix does not refuse to support macos and not for ideological reasons either. Where do you get your info?

There is no way to build the package graph on macos. There is no glibc port for macos, and there's no free toolchain we could legally use.

There is little value in building Guix when we are forced to use a different proprietary toolchain, a different C library, and throw away the from-source bootstrap in exchange for Gigabytes of proprietary blobs. You might as well use Guix System in a virtual machine on macos.



The value of Guix on macOS is that your users can use the same project definitions on macOS and Linux. I don't personally care about the "from-source bootstrap" all that much, I want tooling that I can use to express my system's configuration as code and nix does this just fine on macOS.

As far as the ideological reasons goes, last time I looked for this, someone on a mailing list asked how you'd go about porting guix to macOS and some core team member answered they had no interest in supporting a non-FOSS system.


Guix has recently landed support for building Guix System containers on top of WSL2. Emacs (another GNU package) also runs just fine on Windows.

This is not about supporting a non-free system; I bet some nuance was left behind on the way from writing that mailing list post to the comment I'm responding to. Building packages for macOS would require an entirely different underpinning --- or cheating but cutting the package graph and grafting it on top of the huge proprietary blob that is the macOS development environment. It would also require that we buy macOS licenses and operate macOS build farm nodes to build binaries.

And for what? The resulting packages would in no way be equivalent to their GNU+Linux counterparts. The "same project definitions" would not describe the same thing at all.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: