From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: Hacks to install Guix packages without root Date: Fri, 3 Nov 2017 12:54:03 +0100 Message-ID: <20171103115403.GA10810@thebird.nl> References: <874lqlmvjn.fsf@elephly.net> <87a80dbeln.fsf@gnu.org> <20171027082726.GB8646@thebird.nl> <877evb762c.fsf@albion.it.manchester.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34469) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAaaB-0005gk-8U for guix-devel@gnu.org; Fri, 03 Nov 2017 07:56:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAaa7-00035v-0h for guix-devel@gnu.org; Fri, 03 Nov 2017 07:56:19 -0400 Content-Disposition: inline In-Reply-To: <877evb762c.fsf@albion.it.manchester.ac.uk> 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: Dave Love Cc: guix-devel@gnu.org On Tue, Oct 31, 2017 at 02:19:55PM +0000, Dave Love wrote: > Pjotr Prins writes: >=20 > > PRoot is too slow for most HPC purposes but can be used to build > > non-proot binaries, as I do here: > > > > https://gitlab.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org >=20 > I've never tried to measure it, but how does it affect most HPC > purposes? It's not as if they're going to be using a lot of syscalls. > (However, it's not clear to me how PRoot wins over fakeroot+fakechroot.= ) Best to try for the specific use case. For bioinformatics it won't work. > >> The tarballs could include proot-static and another statically-linke= d > >> program that essentially tries to call unshare(2). Would that make > >> sense? > > > > proot is a no-go for actual use involving IO. >=20 > Presumably that depends on the i/o (amount and type, which might just b= e > in userspace). yes > >> > With that we would be one step closer to the user experience of Do= cker > >> > =E2=80=94 without having a runtime dependency on Docker. > >>=20 > >> It=E2=80=99s also fine to use Docker when it=E2=80=99s available, I = think. > > > > Docker is a no-go on 90% HPC's out there (that number may go down > > slowly). >=20 > [Perhaps not as many as it should be no go...] >=20 > > Also Docker is a royal pain to deal with: every time I have > > to install it somewhere it gives me some grief. I don't think it is > > that useful for distributing software. > > > > I think if we have a proper replacement for Docker - like Conda does = - > > the need for Docker will actually go away. >=20 > What would a proper replacement do that existing solutions don't? Also= , > what does Conda provide? I don't remember seeing anything like that > with it. I was not clear. Conda essentially is a light replacement for Docker if you just think of Docker as a deployment option *only*. Docker=20 is overkill for just deploying software. Guix proves that. Conda proves that too though it is less robust than Guix and less well at handling dependencies. Both have support for containers thrown in. In other words, in my area, quite a few people started preferring Conda o= ver Docker and replacing it in practise. That is what I meant to say. Docker is not going away, mind. We may end up putting Conda and Guix in Docker containers ;) Pj. --=20