Re: Guix on macOS

[Ricardo Wurmus]

Ludovic Courtès <address@hidden> writes:

> First of all, it’s never been a goal of Guix to run on non-GNU systems.
> Now, I have nothing against it in principle, as long as (1) this can be
> achieved in a maintainable way, and (2) the targeted user-land software
> is free and buildable from source.
>
> I suspect macOS fails criterion #2.  Back in the day (not sure if that’s
> still the case), Nix would bootstrap using the system’s compiler and C
> library (which meant that things were likely to break in subtle ways on
> macOS upgrades.)
>
> As for criterion #1, to me, that pretty much means sticking to the GNU
> libc.  From my experience on Nixpkgs, having to deal with different C
> libraries is a real burden.  It also leads to a situation where you have
> second-class systems because they use an alternate libc and it’s not
> uncommon for packages to fail to build against that libc.  To put it
> differently: it’s already difficult enough to have *one* OS working.

I’m quoting all of what Ludo wrote here, because I absolutely agree.

I investigated this in 2014 and once again in 2015 as I had access to
some Macs at the office, but the very fact that there is no legal way to
build the software in freedom makes this whole business very
unattractive.  I also looked at PureDarwin and the defunct OpenDarwin,
as well as inofficial ports of the GNU C library to macOS — none of
these roads looked promising as the software is hardly even buildable.

The only way I could see this working is to support a mechanism for
package graph sections, i.e. a way for a user to cheat and “graft” a
section of a package graph onto a binary blob that the user says is
equivalent.  Obviously, that’s crude and we would sanction a hack as an
official misfeature.  We’d lose all guarantees that we’re working hard
to provide.  It would be regrettable to “support” Guix on macOS if that
thing running on macOS hasn’t really much in common with Guix on GNU.

Christopher wrote this:

> Is there a way to maybe run Guix in some sort of namespaced or some
> variant of "virtualized" or "contained" way that we could recommend for
> OSX users, without having to bend over backwards to accomodate a
> different libc and etc?

In order to use the Hypervisor framework that macOS 10.10 and higher
provide we would need to use Xcode, so we couldn’t even build a tool
like that without relying on proprietary software.  But we don’t have to
build a tool like that, because it already exists in the form of virtual
machine applications (or even Docker for Mac).

The best we could do on macOS is to run applications in a GNU virtual
machine and try hard to make them blend in.  That’s not really
appealing, neither technically nor practically, in my opinion.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net