unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Laura Lazzati <laura.lazzati.15@gmail.com>
Cc: Guix-devel <guix-devel@gnu.org>, help-guix <help-guix@gnu.org>
Subject: Re: Relationship between Docker and Guix
Date: Mon, 25 Nov 2019 16:52:59 +0100	[thread overview]
Message-ID: <CAJ3okZ0e-8LvfnNtqWXXcCyntqKjfRykPy-FH+5MFgwP19N8BQ@mail.gmail.com> (raw)
In-Reply-To: <CAPNLzUPiOXX+mz_bo2EcrB0E=f5ih4gy2RebGGP1TSgXTfbJTQ@mail.gmail.com>

Hi,

Thank you Ricardo for the detailed explanations.


I do not know if my analogy below is correct and/or useful.

The relationship between Docker and GNU Guix is container and the LXC
[1] technology. They use both but differently:

 - Docker is rooted in mutable/imperative and tries to go to more functional;
 - Guix is rooted in immutable/functional.


Everything starts with a configuration file: Dockerfile versus manifest.scm.

 - Dockerfile depends on the state of the distribution that one will
use -- say Debian -- and each time "RUN apt-get update" and/or "RUN
apt-get install" is called then no one can know in advance what the
resulting disk image will *exactly* contain;
 - the manifest.scm depends on the state of the channel trees, other
said, on commit hashes -- manifest.scm acts as a pure function: same
inputs, same outputs -- so one obtain exactly the same container.

We cannot guarantee that the manifest.scm file which one runs today
will generate the same bit-to-bit disk image in the future. Mainly
because it has not been tested yet on the long run. :-)

However, Guix provides the tools to detect that something is not as
expected. For example, we can imagine that today one says: this is the
manifest to build the disk image and the hashes of the store are that
(the same way one provides the MD5 of files when downloading); then in
the future, building again the disk image, we can compare. Currently,
it is impossible with Docker because all the distro are doomed
(mutable). ;-) So what people are currently doing is to store all the
Docker disk images.

Docker motto: build once and run anywhere.
Guix motto(*): build anytime and run everywhere.


To me the relationship(**) is:

   guix pack -f docker -m stuff.scm
   docker load < /gnu/store/<hash>-fancy-name.tar
   docker push



Hope that helps.

All the best,
simon



[1] https://en.wikipedia.org/wiki/LXC

(*) it is not official and my personal view ;-)
(**) again my personal view.

  reply	other threads:[~2019-11-25 15:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-23 10:17 Relationship between Docker and Guix Laura Lazzati
2019-11-23 15:48 ` Ricardo Wurmus
2019-11-25  9:20   ` Laura Lazzati
2019-11-25 15:52     ` zimoun [this message]
2019-11-26  9:57       ` Giovanni Biscuolo
2019-11-26 17:07         ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJ3okZ0e-8LvfnNtqWXXcCyntqKjfRykPy-FH+5MFgwP19N8BQ@mail.gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=help-guix@gnu.org \
    --cc=laura.lazzati.15@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).