[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hacks to install Guix packages without root
From: |
Dave Love |
Subject: |
Re: Hacks to install Guix packages without root |
Date: |
Mon, 06 Nov 2017 15:03:30 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Pjotr Prins <address@hidden> writes:
> On Tue, Oct 31, 2017 at 02:19:55PM +0000, Dave Love wrote:
>> Pjotr Prins <address@hidden> writes:
>>
>> > 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
>>
>> 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.
This may be a bit off-topic, but perhaps it helps in packaging: I don't
know whether that refers to using PRoot or fakechroot, but anyway,
what specifically is the problem in bioinformatics?
By the way, I measured compressed tar/untar under PRoot on CentOS 6 of
the CentOS root image. It's around a factor of two slower than native
on untar and about 40% slower on tar.
>> 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
> is overkill for just deploying software. Guix proves that.
Oh, sure, and there are longer standing solutions anyhow, if OS packages
are out.
> Conda
> proves that too though it is less robust than Guix and less well at
> handling dependencies. Both have support for containers thrown in.
[I didn't realize conda had containers built in, but it seems
Python-centric anyway.]
> In other words, in my area, quite a few people started preferring Conda over
> 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 ;)
Does that mean containers or images? (The way the terminology has gone
is rather unhelpful...) Docker is a nightmare for use with HPC-type
resource managers, but you can run from OCI-type images more sanely, of
course.
I probably basically agree!