all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Julien Lepiller <julien@lepiller.eu>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Feedback from JRES in Dijon
Date: Thu, 5 Dec 2019 16:42:24 +0100	[thread overview]
Message-ID: <CAJ3okZ3M9qSgM6cXEmPx8GO_n+thj09ZR=zJUcWzuuc484PeFQ@mail.gmail.com> (raw)
In-Reply-To: <8D474474-AF4C-4B03-9D38-3BB089BEE4EB@lepiller.eu>

Hi Julien,

Thank you for this report.

On Thu, 5 Dec 2019 at 15:25, Julien Lepiller <julien@lepiller.eu> wrote:

> Another wanted to have some kind of doi for guix describe + manifest (a better UI and easier thing to cite in a paper I suppose).

I agree that something is lacking. I was not thinking about DOI but I
was thinking a better UI similar to "git tag" to improve the current
situation. It is not exactly the question that you had but it seems
related, AFAIU. For example, it is hard to know which commit I need to
"guix pull" to have Python 3.6, if we have. I tried to start a
discussion in this topic there [1]. Another concrete example had been
asked here [2].

[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html
[2] https://lists.gnu.org/archive/html/help-guix/2019-06/msg00098.html


> The person I talked to at lunch was a bit skeptical about Guix. They have it and Nix, with module on their cluster. They told me they were more concerned about replicability than reproducibility. Also, their users are lost between the options, they have trouble getting help on guix from their admins and they end up using conda, yet another tool ^^".

Bit-to-bit reproducibility is the first step to go to Replicability, IMHO.
For sure, Conda is a no-go for this goal, again IMHO. :-)
Modulefiles is loosing their time by re-doing what packagers are
doing; it is the dependency hell because they spend their time on
compiling libraries -- the code of interest depends on one lib which
depends on other lib which depends on... So it requires a lot of
manpower. Guix solves that elegantly IMO; considering channels.

And the big issue of replicability is floating point. The same binary
with the same inputs does not compute the same output. For example,
see page 13 of [3].

[3] https://jcad2019.sciencesconf.org/data/2019_JCAD_Repro_Hill_vf.pdf

Well I am not sure that a general solution can solve replicability...
and it is software by software.


Cheers,
simon

  parent reply	other threads:[~2019-12-05 15:42 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-05 14:16 Feedback from JRES in Dijon Julien Lepiller
2019-12-05 14:34 ` Pierre Neidhardt
2019-12-05 14:42   ` Julien Lepiller
2019-12-05 15:44     ` Konrad Hinsen
2019-12-05 15:52       ` zimoun
2019-12-06  7:07         ` Bengt Richter
2019-12-06 12:24           ` Konrad Hinsen
2019-12-07 16:35             ` Timothy Sample
2019-12-08  2:48               ` Bengt Richter
2019-12-08  4:11                 ` Timothy Sample
2019-12-08 23:09                   ` Bengt Richter
2019-12-09  5:23                     ` Konrad Hinsen
2019-12-06 12:57         ` Konrad Hinsen
2019-12-10 16:57           ` Ludovic Courtès
2019-12-11 20:48             ` Konrad Hinsen
2020-01-07 16:05           ` Proposal for a blog contribution on reproducible computations Konrad Hinsen
2020-01-09 20:40             ` zimoun
2020-01-10 16:59             ` Ludovic Courtès
2020-01-10 17:19               ` zimoun
2020-01-10 18:53               ` Giovanni Biscuolo
2020-01-11  9:31               ` Konrad Hinsen
2020-01-11 14:05                 ` Giovanni Biscuolo
2020-01-13  8:37                 ` Ludovic Courtès
2020-01-14  9:06               ` Konrad Hinsen
2020-01-14 15:38                 ` Ludovic Courtès
2020-01-14 16:18                   ` Konrad Hinsen
2020-01-14 16:40                     ` Ludovic Courtès
2020-01-10 17:03             ` Ludovic Courtès
2020-01-11  9:39               ` Konrad Hinsen
2020-01-15 22:20                 ` Ludovic Courtès
2019-12-05 15:47     ` Feedback from JRES in Dijon zimoun
2019-12-05 14:39 ` Julien Lepiller
2019-12-05 15:42 ` zimoun [this message]
2019-12-10 17:06 ` Ludovic Courtès

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

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

  git send-email \
    --in-reply-to='CAJ3okZ3M9qSgM6cXEmPx8GO_n+thj09ZR=zJUcWzuuc484PeFQ@mail.gmail.com' \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=julien@lepiller.eu \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.