all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Guix on macOS
Date: Thu, 12 Oct 2017 23:33:08 +0200	[thread overview]
Message-ID: <8760bkgigb.fsf@elephly.net> (raw)
In-Reply-To: <87efq8pwrf.fsf@gnu.org>


Ludovic Courtès <ludo@gnu.org> 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

  parent reply	other threads:[~2017-10-12 22:19 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-12  3:29 Guix on macOS Chris Marusich
2017-10-12  8:08 ` Konrad Hinsen
2017-10-12  8:59 ` Ludovic Courtès
2017-10-12 20:35   ` Christopher Allan Webber
2017-10-12 21:33   ` Ricardo Wurmus [this message]
2017-10-13 15:58     ` Christopher Allan Webber
2017-10-13  7:14   ` Chris Marusich
2017-10-13 11:47     ` Ricardo Wurmus
2017-10-13 12:55     ` Ludovic Courtès
2017-10-13 13:59       ` Konrad Hinsen
2017-10-13 13:59       ` Ricardo Wurmus
2017-10-13 15:59         ` Christopher Allan Webber
2017-10-13 14:08       ` Konrad Hinsen
2017-10-25 15:50         ` Adonay Felipe Nogueira
2017-10-27  4:11     ` Chris Marusich
2017-10-27  7:56       ` Hartmut Goebel
2017-10-28 20:27       ` Building Docker images of GuixSD Ludovic Courtès
2017-10-31  2:59         ` Chris Marusich
2017-11-05 15:45           ` Ludovic Courtès
2017-11-09  6:15             ` Chris Marusich
2017-11-09  6:43               ` Pjotr Prins
2017-11-09  8:23               ` Konrad Hinsen
2017-11-17 21:14               ` Ludovic Courtès
2017-11-27 22:13               ` Christopher Baines
2017-11-30  9:11                 ` Ludovic Courtès
2017-12-07  9:33                 ` Chris Marusich
2017-12-16  2:30                 ` Chris Marusich
2017-10-12 19:09 ` Guix on macOS Christopher Baines
2017-10-25 14:45 ` Adonay Felipe Nogueira
2017-10-27  1:06   ` Chris Marusich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8760bkgigb.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.