Re: Tiny Guix (and containers)

[Pjotr Prins <pjotr.public12@thebird.nl>]

On Tue, Oct 31, 2017 at 02:11:36PM +0000, Dave Love wrote:
> Pjotr Prins <pjotr.public12@thebird.nl> writes:
> 
> > But, really, I think when talking embedded systems and containers we
> > all want tiny. Even HPC can benefit. Tiny containers may be an
> > attractive proposition.
> 
> Yes, containers aside, dependencies in Guix are one of the reasons I'm
> currently unconvinced by its trades-off for HPC use; the closure a
> single package can be comparable with the whole compute node image I
> used to maintain with rpm.  Even then, you don't generally have
> debugging info available.

For most software we just need the binary executable and its shared
libs. That is exactly what I package with my tool:

For gemma the binary closure is only 18Mb. See
https://github.com/genetics-statistics/GEMMA/issues/90

That is small. And it runs on HPC. Maybe this is the way forward for
HPC. For many HPC tools we can create such very small tarballs. You
don't even need my relocatable installer if you have permission for
/gnu/store (but then NFS would be a better idea). Great thing
about Guix packages is that we can figure out what the dependencies
are and strip it down to those. There is no interference. When it
works, it works always!

Once you have a Guix package and closure it is quite easy to compile
it into something small and relocatable. That is what I have been
experimenting with and I like the result. I am going to deploy GEMMA
on a KNL supercomputer this month.

> I suppose the general point is that Guix seems to have rejected
> experience from other distributions, and it's not clear to me why.  (I
> don't mean it should necessarily follow them, of course.)  Is there any
> summary of the rationale for different decisions like not splitting
> packages into development and runtime and other components, packaging
> static libraries, and discarding debugging information, for instance?

In my opinion Guix is both young and mature at the same time.
Splitting packages is hard work and I think if enough people want to
do it it will happen (eventually). Like Ludo suggests, we could start
with the low hanging fruit.

In the first E-mail I wrote this would be of great interest to
embedded systems and HPC. I may try my stripping method on ARM and
MIPS coming year. Just for the heck of it.

Pj.



--