Pjotr Prins <pjotr.publi...@thebird.nl> writes: > On Tue, Oct 31, 2017 at 02:19:55PM +0000, Dave Love wrote: >> Pjotr Prins <pjotr.publi...@thebird.nl> 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!