From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Guix on macOS Date: Thu, 12 Oct 2017 23:33:08 +0200 Message-ID: <8760bkgigb.fsf@elephly.net> References: <87bmldavre.fsf@gmail.com> <87efq8pwrf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2lpa-0002eV-Rc for guix-devel@gnu.org; Thu, 12 Oct 2017 18:19:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2lpY-0006kY-Ep for guix-devel@gnu.org; Thu, 12 Oct 2017 18:19:54 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21017) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e2lpY-0006kM-7g for guix-devel@gnu.org; Thu, 12 Oct 2017 18:19:52 -0400 In-reply-to: <87efq8pwrf.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org Ludovic Courtès 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