Tiny Guix (and containers)

[Pjotr Prins]

I have been playing around with containers to create something for a
book:

  https://gitlab.com/pjotrp/guix-notes/blob/master/CONTAINERS.org

these are (Docker) images that can be run by anyone - which is great!

Only (minor) issue is the containers are 1.4GB in size. These are the
biggies in this image:

  address@hidden /gnu/store [env]# du -sh *|grep -e "[[:digit:]][[:digit:]]M"
  36M     0s5manjvfa0gmsv2r71rchky7ab70g1d-icu4c-58.2
  36M     15plffwjdv8ii6vbsnvrvy6irbfsz4x4-gfortran-5.4.0-lib
  22M     3x53yv4v144c9xp02rs64z7j597kkqax-gcc-5.4.0-lib
  16M     42d5rjrdkln6nwvzwdc8dyd4w6iy3n5j-coreutils-8.27
  13M     5c9qygcdircjg1dkaw6rnw59c6v4akca-python-cython-0.27
  90M     5sv5zy2kgg6iaqyv8zw49w4243j0xkd0-gcc-5.4.0
  19M     5vjvxngriskrsrg5lv162i927crciy9x-bioperl-minimal-1.7.0
  40M     
9c5ip78j3cr6ywx9vjicn545pmq24802-book-evolutionary-genomics-0.2.1-53a7aef
  92M     9shcsn90rpzacysklhfiidc9qkcn3f1l-ruby-2.4.2
  16M     azbfh3i72lbaqvhgg5m7p6ymmqq0ii6q-glib-2.52.3
  59M     bzn4wyrbdmfc1bd7lq05db5psfl5f8x8-perl-5.26.0
  28M     d4hwf3w2ca9lmf7nrgk2jsr9mhxcmb40-vim-8.0.1207
  15M     d5khpb89l7w65qvwry6ikx57sknnnl9p-python-biopython-1.70
  46M     d8gkn84yqacjr80pzicz1ka3y2s1f2x0-guile-2.2.2
  63M     f7j1vq0ncc1znrn0cyy07gps3r0h1iaa-openblas-0.2.19
  10M     fqxyqlpkbm4fc9x91yyqs7zbhm495b2s-ruby-ffi-1.9.18
  65M     ks27x0mf95gir0cdgb9h573xbava6v1k-python-3.5.3
  11M     kwzs8k97qy7avxxldnzavlii9zphh3d6-libxml2-2.9.4
  13M     l95wcgysigi5mkmzgrr9k0irrszzd2m8-profile
  41M     n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25
  34M     nnykzgwfy8mwh2gmxm715sjxykg8qjwn-binutils-2.28
  11M     nyd19c9ccykji2lg9jhxfzv6zd67ar55-lapack-3.7.1
  423M    p4h18j5dnn7sgajni9pfas0jm4dgdnv6-emboss-6.5.7
  22M     pc96dryzfghnih9lqrjfa24n205ds7ir-python-numpy-1.12.0
  31M     sq8yhawx0x3pyvvqrxx8hmw4rnp4mz03-bioruby-1.5.1
  45M     y8g28w9icanll84llw6xvdyjrw0qvnp9-r-minimal-3.4.2
  15M     zb662xs7i06l079n2wr5mn56862v6wfm-r-biostrings-2.44.2
  14M     zbywrj6klakskj0sppq56viqh9l56jl0-util-linux-2.30.1

It is obvious emboss could be trimmed down ;). But I think none of
these packages when trimmed down ought to be larger than 15M. Not
even gcc.

Separately I have been using Travis-Ci for (integration) testing of a
C++ project (soon to adding D) which we are working on

  https://travis-ci.org/genetics-statistics/GEMMA

Now it takes forever to set up the image - a tiny Guix Docker
container would be great here and probably get attention (most Travis
testing time goes up in downloading stuff!). To users it makes a huge
difference if they have to wait 10 minutes or 10 seconds.

Then there is my idea of creating (mail) servers using Guix. It would
be great to go tiny there too. And in the embedded world they may
consider Guix when it is tiny.

My question is, who else would be interested and how to best to go
about this in Guix. It makes no sense to write separate packages (I
think) because the maintenance effort would go up hugely.  But tiny is
also not exactly a subset of existing packages. I mean 

  guix package -i glibc:tiny

could be a target. Splitting packages in bioruby:doc, bioruby:dev and
bioruby:lib would serve that purpose too. We know Debian struggled
with this and we also know that OpenWRT/LEDE went the NIH way. What
lessons are there?

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.

Pj.