From: zimoun <zimon.toutoune@gmail.com>
To: Taylan Kammer <taylan.kammer@gmail.com>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Advantages over Nix?
Date: Mon, 26 Oct 2020 11:41:52 +0100 [thread overview]
Message-ID: <CAJ3okZ1=4KeDUCg0EX_VCRvWhH7pb4Y=3ucBcY8sW68vrfxr5w@mail.gmail.com> (raw)
In-Reply-To: <87blgpl9g5.fsf@gmail.com>
Hi Taylan.
On Mon, 26 Oct 2020 at 08:42, Taylan Kammer <taylan.kammer@gmail.com> wrote:
> However, currently at my workplace I'm trying to pitch Nix/Guix as a
> better way of generating Docker container images, opposed to the impure
> Dockerfile way of doing it.
The pitch really depends on the background of your workplace.
Providing scientific C applications running on HPC clusters is not the
same as running Python/JS/SQL web services.
> (I've never really worked with Docker yet so my understanding is very
> shallow; I hope what I'm saying makes sense. My understanding is that
> via Dockerfiles you generate images imperatively, and the results are
> dependent on the state of the universe. Yuck!)
The main pitfall is not the Dockerfile per se but the classical
distribution it often implies. Well, this video is explaining better
than my words. :-)
https://archive.fosdem.org/2019/schedule/event/gnu_guix_new_approach_to_software_distribution/
> So now the question is: given that Nix is older and thus probably more
> mature, are there any non-subjective, non-ideological reasons to pick
> Guix over Nix?
I do not know Nix. The killer features I cannot work without now are:
- time-machine
- environment (alone, with --pure or --container)
- pack -f docker
- repl
> TL;DR: sell Guix (over Nix) to someone who doesn't care about GNU or
> Scheme?
For reference, Pierre started this [1] and I do not remember the end
of the story. IMHO, the nice move is to write down typical use
cases/scenarii that Guix solves and then the audience can pick the one
they are interested in or the one that talks to them as an entry
point. Therefore, to convince my co-workers, I pick our typical
workflow, show how it works (or would work) with Guix, pointing out
what are the current drawbacks of the current workflow and how Guix
improves the situation or sometimes only one specific part of the
workflow. (My co-workers are biologists so they do not care much
about the computational tools since the one who is doing. ;-))
1: https://lists.gnu.org/archive/html/help-guix/2020-01/msg00002.html
All the best,
simon
next prev parent reply other threads:[~2020-10-26 10:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 7:42 Advantages over Nix? Taylan Kammer
2020-10-26 9:29 ` Jan Nieuwenhuizen
2020-10-26 11:36 ` Taylan Kammer
2020-10-26 23:39 ` Ludovic Courtès
2020-10-27 10:35 ` Pjotr Prins
2020-10-27 13:14 ` zimoun
2020-10-28 5:58 ` Pjotr Prins
2020-10-26 10:41 ` zimoun [this message]
2020-10-26 11:44 ` Pierre Neidhardt
2020-10-26 12:46 ` Taylan Kammer
2020-10-26 12:42 ` Taylan Kammer
2020-10-26 16:14 ` zimoun
2020-10-26 20:29 ` Yasuaki Kudo
2020-10-26 22:32 ` Ricardo Wurmus
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='CAJ3okZ1=4KeDUCg0EX_VCRvWhH7pb4Y=3ucBcY8sW68vrfxr5w@mail.gmail.com' \
--to=zimon.toutoune@gmail.com \
--cc=guix-devel@gnu.org \
--cc=taylan.kammer@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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
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).