Re: Feedback from JRES in Dijon

[Konrad Hinsen]

Hi Ludo,

>> I am working on an article (ultimately for "Computing in Science and
>> Engineering") that takes up some of those subjects and illustrates them
>> using Guix. It would be nice to get feedback from the Guix community
>> early, to make sure I don't do something stupid. So I could do a first
>> version for the Guix blog, and thus propose it here for review,
>> and then make it a bit less technical for a wider audience.
>
> That would be great!  Also, a “how to do reproducible science with Guix”
> hands-on would be nice (we could also have a section in the cookbook.)

Since I am working for something quite similar for the Reproducible
Research MOOC, I can also make a variant for the cookbook. I just need
to find the time to make progress on all that!

Cheers,
  Konrad.

Re: Feedback from JRES in Dijon

[Ludovic Courtès]

Hi Julien,

Julien Lepiller  skribis:

> I presented the project at JRES yesterday and had lots of questions
> and reactions.

Thanks for the nice talk and for sharing feedback!  It’s really great to
see how each one of us approaches it from a different angle, and I think
you chose the right one for this audience (mostly sysadmins).

(The install/remove example on the first slide is of course
questionable, but the rest is great.  ;-))

> One person was wondering whether Guix would be a good idea for there
> cluster. I said yes then I redirected them to guix hpc.

Neat, I hope we’ll hear from them.  :-)

> 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 guess a single Git commit ID or, better, a Software Heritage intrinsic
ID could fit the bill.

> Another was asking about the possibility ofusing Guix to have multiple
> kernels and boot a debian with guix's kernel (so as to choose a
> compatible kernel at boot iiuc).

Uh, an unusual use case.

> 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
> ^^".

Ah well, there’s a learning curve.  Now, my hope is that people who
manage to do “conda install” would also manage to get started with “guix
install”.  But that’s more and more of a social issue (spreading the
word) than a technical one, I think.

Anyway, nice work!  If you want we can have the PDF of your talk (and
the article you wrote at
!)
on the web site, perhaps with a tiny blog post giving some context.

Thanks,
Ludo’.

PS: I also got positive feedback from a colleague who attended your
talk.  :-)

Re: Feedback from JRES in Dijon

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen  skribis:

>> If I might, one the best presentation [1] -- that I am aware of -- on
>> this. Sorry in French.
>
> Thanks for the marketing :-)
>
>> [1] 
>> https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
>> https://aramis.resinfo.org/wiki/lib/exe/fetch.php?media=pleniaires:aramis_keynote_enjeux-et-defis-recherche-reproductible_konrad_hinsen.pdf
>>
>> Maybe we could convert it to an entry for the HPC blog. What do you think?
>
> I am working on an article (ultimately for "Computing in Science and
> Engineering") that takes up some of those subjects and illustrates them
> using Guix. It would be nice to get feedback from the Guix community
> early, to make sure I don't do something stupid. So I could do a first
> version for the Guix blog, and thus propose it here for review,
> and then make it a bit less technical for a wider audience.

That would be great!  Also, a “how to do reproducible science with Guix”
hands-on would be nice (we could also have a section in the cookbook.)

Thanks,
Ludo’.

Re: Feedback from JRES in Dijon

[Konrad Hinsen]

Hi Bengt,

> BTW3, Konrad,
> That was a nice presentation -- are the tools you used to prepare it and 
> present it
> available as libre packages? (I'm not insisting you answer ;-)

That's LaTeX with the Beamer package, plus Inkscape for the graphics.
It's all in Guix.

A bit of history: for many years I used Apple's Keynote software for my
presentations. Until I discovered one day that I couldn't open my old
presentations any more. Apple had changed the format a few times, and
then quietly dropped support for the older formats. And the older
software versions that could read the old presentations were no longer
available.

So now it's LibreOffice for short quick-and-dirty slide hacking, and
LaTeX with Beamer for everything else.

Cheers,
  Konrad.

Re: Feedback from JRES in Dijon

[Bengt Richter]

Hi Tim, Konrad,

On +2019-12-07 23:11:19 -0500, Timothy Sample wrote:
> Hi Bengt,
> 
> I omitted a lot of your message, but I hope I have the easy explanation
> you’re looking for.  :)
> 
> Bengt Richter  writes:
> 
> > On +2019-12-07 11:35:02 -0500, Timothy Sample wrote:
> >> 
> >> [...]
> >> 
> >> Unfortunately, I got certificate errors, but VLC lets you temporarily
> >> ignore those.
> >
> > [...]
> >
> > Anyone see an easy explanation?
> 
> After a little more digging, it seems that the certificate sent for
> “ccwebcast.in2p3.fr” is signed with an intermediate certificate from
> “TERENA”.  This is in turn signed with a DigiCert root certificate.
> Unfortunately it looks like “ccwebcast.in2p3.fr” doesn’t send the whole
> certificate chain, and the TERENA cert is not part of our “nss-certs”
> package, so tools using certs from that package (basically everything on
> a normal Guix install) will be unwilling to trust “ccwebcast.in2p3.fr”.
> IceCat is okay with it, but it uses its own certificates (it must know
> about the TERENA cert, so it doesn’t need the whole chain).
> 
> Fortunately, for exceptional situations like this, you can tell most
> tools to skip certificate validation (like I mentioned with VLC).  For
> youtube-dl, you can use the “--no-check-certificate” option.  Note
> however that this is rather dangerous in general, since you are telling
> youtube-dl allow anyone to pretend to be anyone else!  In this case,
> since it’s just a video and IceCat is okay with the certificate it’s
> probably fine.  Just be careful.  :)
> 
> 
> -- Tim

Thank you very much for digging and providing the dangerous solution :)
(I suppressed my paranoia this once, and it did work BTW :)

BTW2, I have icecat installed, so I wonder if, given that it "uses its own 
certificates"
(and knows about TEREMA) is there a cert-PATH that could be extended so other
apps see icecat's cert info in addition to their own?

BTW3, Konrad,
That was a nice presentation -- are the tools you used to prepare it and 
present it
available as libre packages? (I'm not insisting you answer ;-)

-- 
Regards,
Bengt Richter

Re: Feedback from JRES in Dijon

[Timothy Sample]

Hi Bengt,

I omitted a lot of your message, but I hope I have the easy explanation
you’re looking for.  :)

Bengt Richter  writes:

> On +2019-12-07 11:35:02 -0500, Timothy Sample wrote:
>> 
>> [...]
>> 
>> Unfortunately, I got certificate errors, but VLC lets you temporarily
>> ignore those.
>
> [...]
>
> Anyone see an easy explanation?

After a little more digging, it seems that the certificate sent for
“ccwebcast.in2p3.fr” is signed with an intermediate certificate from
“TERENA”.  This is in turn signed with a DigiCert root certificate.
Unfortunately it looks like “ccwebcast.in2p3.fr” doesn’t send the whole
certificate chain, and the TERENA cert is not part of our “nss-certs”
package, so tools using certs from that package (basically everything on
a normal Guix install) will be unwilling to trust “ccwebcast.in2p3.fr”.
IceCat is okay with it, but it uses its own certificates (it must know
about the TERENA cert, so it doesn’t need the whole chain).

Fortunately, for exceptional situations like this, you can tell most
tools to skip certificate validation (like I mentioned with VLC).  For
youtube-dl, you can use the “--no-check-certificate” option.  Note
however that this is rather dangerous in general, since you are telling
youtube-dl allow anyone to pretend to be anyone else!  In this case,
since it’s just a video and IceCat is okay with the certificate it’s
probably fine.  Just be careful.  :)


-- Tim

Re: Feedback from JRES in Dijon

[Bengt Richter]

Hi Timothy,

On +2019-12-07 11:35:02 -0500, Timothy Sample wrote:
> Hello,
> 
> Konrad Hinsen  writes:
> 
> > Hi Bengt,
> >
> >>> [1]
> >>> https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
> >>> https://aramis.resinfo.org/wiki/lib/exe/fetch.php?media=pleniaires:aramis_keynote_enjeux-et-defis-recherche-reproductible_konrad_hinsen.pdf
> >>>
> >>
> >> Is [1] available as a libre video download?
> >
> > No idea. I can answer most questions about the content since I am the
> > speaker, but I was not involved with recording and publishing.
> 
> I was able to play it on Guix System with VLC.  The following URL uses
> “MPEG-DASH” for streaming, and VLC understands that.
> 
> 
> https://ccwebcast.in2p3.fr/vod/_definst_/mp4:media/5c/e6/5ce6537209640/5ce6537209640.mp4/manifest.mpd
> 
> Unfortunately, I got certificate errors, but VLC lets you temporarily
> ignore those.
> 
> HTH!
> 
> (Thanks Konrad!  I’m looking forward to watching it later.)
> 
> 
> -- Tim

Thanks Tim, but unfortunately I don't have VLC loaded (I'll look into it)
.
I have a little scriptlet that takes an executable name and
extracts urls from piped-in whatever and gives me a choice
which url to be returned to call the executable with, so I tried wget to
see if I could see what the .mpd was:

--8<---cut here---start->8---
Choose from the following urls to be returned:
1) 
https://aramis.resinfo.org/wiki/lib/exe/fetch.php?media=pleniaires:aramis_keynote_enjeux-et-defis-recherche-reproductible_konrad_hinsen.pdf
2) 
https://ccwebcast.in2p3.fr/vod/_definst_/mp4:media/5c/e6/5ce6537209640/5ce6537209640.mp4/manifest.mpd
3) 
https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
#? 2
--2019-12-07 16:58:15--  
https://ccwebcast.in2p3.fr/vod/_definst_/mp4:media/5c/e6/5ce6537209640/5ce6537209640.mp4/manifest.mpd
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving ccwebcast.in2p3.fr (ccwebcast.in2p3.fr)... 134.158.69.183
Connecting to ccwebcast.in2p3.fr (ccwebcast.in2p3.fr)|134.158.69.183|:443... 
connected.
ERROR: The certificate of ?ccwebcast.in2p3.fr? is not trusted.
ERROR: The certificate of ?ccwebcast.in2p3.fr? doesn't have a known issuer.
Press any key to continue...
--8<---cut here---end--->8---

Then, to see if youtube-dl could handle it:

--8<---cut here---start->8---
Choose from the following urls to be returned:
1) 
https://aramis.resinfo.org/wiki/lib/exe/fetch.php?media=pleniaires:aramis_keynote_enjeux-et-defis-recherche-reproductible_konrad_hinsen.pdf
2) 
https://ccwebcast.in2p3.fr/vod/_definst_/mp4:media/5c/e6/5ce6537209640/5ce6537209640.mp4/manifest.mpd
3) 
https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
#? 2
[generic] manifest: Requesting header
WARNING: Could not send HEAD request to 
https://ccwebcast.in2p3.fr/vod/_definst_/mp4:media/5c/e6/5ce6537209640/5ce6537209640.mp4/manifest.mpd:
 
[generic] manifest: Downloading webpage
ERROR: Unable to download webpage:  (caused by URLError(SSLCertVerificationError(1, '[SSL: 
CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local 
issuer certificate (_ssl.c:
1108)')))
Press any key to continue...
--8<---cut here---end--->8---

I have not yet configured dnsmasq -- do you think the above is a DNSSEC problem
that would be solved by dnsmasq? (does someone have a QND quick-and-dirty how-to
for configuring dnsmasq, spelling out any gotchas -- or should RTFM suffice?)

Or do you think ccwebcast.in2p3.fr might have the same/similar subdomain issues 
as savannah?

I can ping both domain and subdomain though:

--8<---cut here---start->8---
$ ping ccwebcast.in2p3.fr
PING ccpntc08c.in2p3.fr (134.158.69.183) 56(84) bytes of data.
64 bytes from ccpntc08c.in2p3.fr (134.158.69.183): icmp_seq=1 ttl=41 time=182 ms
64 bytes from ccpntc08c.in2p3.fr (134.158.69.183): icmp_seq=2 ttl=41 time=179 ms
64 bytes from ccpntc08c.in2p3.fr (134.158.69.183): icmp_seq=3 ttl=41 time=178 ms
^C
--- ccpntc08c.in2p3.fr ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 3606ms
rtt min/avg/max/mdev = 177.732/179.508/181.948/1.783 ms
$ ping in2p3.fr
PING in2p3.fr (134.158.69.48) 56(84) bytes of data.
64 bytes from ccwbvip13.in2p3.fr (134.158.69.48): icmp_seq=1 ttl=41 time=176 ms
64 bytes from ccwbvip13.in2p3.fr (134.158.69.48): icmp_seq=2 ttl=41 time=178 ms
^C
--- in2p3.fr ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 176.318/176.911/177.505/0.593 ms
$
--8<---cut here---end--->8---

... so idk -- maybe I can bypass DNSSEC problemss with /etc/hosts ...
Will try that, just to add a data point :)

Nope, doesn't seem to change anything ;-/

--8<---cut here---start->8---
$ wget $(stack)

Re: Feedback from JRES in Dijon

[Timothy Sample]

Hello,

Konrad Hinsen  writes:

> Hi Bengt,
>
>>> [1]
>>> https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
>>> https://aramis.resinfo.org/wiki/lib/exe/fetch.php?media=pleniaires:aramis_keynote_enjeux-et-defis-recherche-reproductible_konrad_hinsen.pdf
>>>
>>
>> Is [1] available as a libre video download?
>
> No idea. I can answer most questions about the content since I am the
> speaker, but I was not involved with recording and publishing.

I was able to play it on Guix System with VLC.  The following URL uses
“MPEG-DASH” for streaming, and VLC understands that.


https://ccwebcast.in2p3.fr/vod/_definst_/mp4:media/5c/e6/5ce6537209640/5ce6537209640.mp4/manifest.mpd

Unfortunately, I got certificate errors, but VLC lets you temporarily
ignore those.

HTH!

(Thanks Konrad!  I’m looking forward to watching it later.)


-- Tim

Re: Feedback from JRES in Dijon

[Konrad Hinsen]

Hi Bengt,

>> [1] 
>> https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
>> https://aramis.resinfo.org/wiki/lib/exe/fetch.php?media=pleniaires:aramis_keynote_enjeux-et-defis-recherche-reproductible_konrad_hinsen.pdf
>>
>
> Is [1] available as a libre video download?

No idea. I can answer most questions about the content since I am the
speaker, but I was not involved with recording and publishing.

> IMO if you can't reproduce bit-identical results, you should find out 
> _exactly_ why.
> And if you do get exactly the same result, you should also know exactly why 
> ;-)

That's a nice way to put it!

> The video touches on IEEE 754 (and I do believe the lecturer
> understands these issues, but he says (IIU.fr :) no programming
> language gives control over the FPU -- is that true?? I mean,
> including on-the-metal x86_64 assembly language??

I wouldn't count that as a programming language, but that is of course
debatable. For me, a programming language is a platform-neutral medium
that can be run on any type of computer. And yes, you can argue that
the subset of x86 assembly that doesn't manipulate hardware other than
registers fits that definition, but you have to draw the line somewhere.

More interestingly (definitions aren't really interesting), I am of
course not certain that there is no programming language that gives
access to the full IEEE754 programming model. I am not aware of any,
but if there is, I'd like to find out!

> BTW, if you are interested in floating point, links from here should be fun:
>
> --8<---cut here---start->8---
> https://en.wikipedia.org/wiki/William_Kahan
> --8<---cut here---end--->8---

Indeed. For those unfamiliar with that name, Kahan designed the 8087
floating-point processor for Intel and was the main driver behind the
IEEE 754 standardization effort.

Cheers,
  Konrad.

Re: Feedback from JRES in Dijon

[Konrad Hinsen]

Hi Simon,

> If I might, one the best presentation [1] -- that I am aware of -- on
> this. Sorry in French.

Thanks for the marketing :-)

> [1] 
> https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
> https://aramis.resinfo.org/wiki/lib/exe/fetch.php?media=pleniaires:aramis_keynote_enjeux-et-defis-recherche-reproductible_konrad_hinsen.pdf
>
> Maybe we could convert it to an entry for the HPC blog. What do you think?

I am working on an article (ultimately for "Computing in Science and
Engineering") that takes up some of those subjects and illustrates them
using Guix. It would be nice to get feedback from the Guix community
early, to make sure I don't do something stupid. So I could do a first
version for the Guix blog, and thus propose it here for review,
and then make it a bit less technical for a wider audience.

Cheers,
  Konrad.

Re: Feedback from JRES in Dijon

[Bengt Richter]

Hi zimoun,

On +2019-12-05 16:52:47 +0100, zimoun wrote:
> Hi,
> 
> On Thu, 5 Dec 2019 at 16:45, Konrad Hinsen  wrote:
> 
> > > So they are doing physical simulation (fluid dynamics), so they don't
> > > (can't) get the same result when running the same experiment
> > > twice. They wart replicability, that is, even if the results are
> > > different, they are close enough to each other that you have to draw
> > > the same scientific conclusion, independent of your compiler or other
> > > package inputs.
> >
> > That's a common point of view in the numerical simulation community.
> > What the people defending it don't realize is that both reproducibility
> > and replicability matter, but in different situations and for different
> > reasons. Reproducibility matters for verification ("was the computation
> > done correctly?"), replicability matters for validation ("was the
> > computation the right one for the scientific question?").
> 
> If I might, one the best presentation [1] -- that I am aware of -- on
> this. Sorry in French.
> 
> [1] 
> https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
> https://aramis.resinfo.org/wiki/lib/exe/fetch.php?media=pleniaires:aramis_keynote_enjeux-et-defis-recherche-reproductible_konrad_hinsen.pdf
>

Is [1] available as a libre video download?
My current youtube-dl could not find the video of [1], though I watched it with 
firefox.
I think it would be good for my French, such as it is, to watch that a few 
times ;-)

IMO if you can't reproduce bit-identical results, you should find out _exactly_ 
why.
And if you do get exactly the same result, you should also know exactly why ;-)

IME, in the process of figuring out the explanations you will always learn 
something.

You may be reproducing perfectly a biased result which could be improved as
a numerical result by counter-intuitively adding noise to the inputs
(to spread roundoff across the lsb roundoff boundary so that a mean will show
where in the interval the best estimate fell).

And if you are on the hairy edge of having a non-singular matrix to invert,
results can change because your thread got interrupted at a point where fp regs
got stored as 64 bits and thus restored with different precision than if the
interrupt didn't happen. Just because someone logged in remotely for unrelated 
reasons.

Such an infinitesimal value change can change the search order for pivot point 
in a matrix
and change the order of computation, or even make zero elements that otherwise 
differed
enough to make the inversion possible. And maybe you shouldn't actually store 
an inverse
from a library routine and then multiply, but rewrite your algorith to avoid 
truncations-
Of course your results may still be unusably sensitive ;-)

OTOH, you may notice that your algorithm would do much better if you 
pre-translated your
inputs to a better coordinate system orgin (e.g. to make lots of off-diagonal 
exact zeroes).

You may want to analyze how roundoff errors propagate through a Kalman filter 
vs a direct MLE version,
to see at what bit region in your numerical results input effects turn to 
computational artifacts,
to judge how to express your idea of the scientific significance of your 
results.

The video touches on IEEE 754 (and I do believe the lecturer understands these 
issues, but
he says (IIU.fr :) no programming language gives control over the FPU -- is 
that true?? I mean,
including on-the-metal x86_64 assembly language?? I thought you could set all 
those bits
that the firmware pays attention to, no?)

BTW, if you are interested in floating point, links from here should be fun:

--8<---cut here---start->8---
https://en.wikipedia.org/wiki/William_Kahan
--8<---cut here---end--->8---

Hey, in the '60s we wrote floating point in assembler, (after having written 
the assembler
for the custom system :) and were happy to get division timed under a 
millisecond ;-) Time flies :)

> Maybe we could convert it to an entry for the HPC blog. What do you think?
> 
> 
> Cheers,
> simon
> 

-- 
Regards,
Bengt Richter

Re: Feedback from JRES in Dijon

[zimoun]

Hi,

On Thu, 5 Dec 2019 at 16:45, Konrad Hinsen  wrote:

> > So they are doing physical simulation (fluid dynamics), so they don't
> > (can't) get the same result when running the same experiment
> > twice. They wart replicability, that is, even if the results are
> > different, they are close enough to each other that you have to draw
> > the same scientific conclusion, independent of your compiler or other
> > package inputs.
>
> That's a common point of view in the numerical simulation community.
> What the people defending it don't realize is that both reproducibility
> and replicability matter, but in different situations and for different
> reasons. Reproducibility matters for verification ("was the computation
> done correctly?"), replicability matters for validation ("was the
> computation the right one for the scientific question?").

If I might, one the best presentation [1] -- that I am aware of -- on
this. Sorry in French.

[1] 
https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
https://aramis.resinfo.org/wiki/lib/exe/fetch.php?media=pleniaires:aramis_keynote_enjeux-et-defis-recherche-reproductible_konrad_hinsen.pdf

Maybe we could convert it to an entry for the HPC blog. What do you think?


Cheers,
simon

Re: Feedback from JRES in Dijon

[zimoun]

On Thu, 5 Dec 2019 at 15:43, Julien Lepiller  wrote:

> So they are doing physical simulation (fluid dynamics), so they don't (can't) 
> get the same result when running the same experiment twice. They wart 
> replicability, that is, even if the results are different, they are close 
> enough to each other that you have to draw the same scientific conclusion, 
> independent of your compiler or other package inputs.

It is question for the Philosophy of Science. What is the status of error? ;-)

In the area of controlling the error, Interval Arithmetic [1] gives
interesting results.

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


All the best,
simon

Re: Feedback from JRES in Dijon

[Konrad Hinsen]

Hi Julien and Pierre,

> So they are doing physical simulation (fluid dynamics), so they don't
> (can't) get the same result when running the same experiment
> twice. They wart replicability, that is, even if the results are
> different, they are close enough to each other that you have to draw
> the same scientific conclusion, independent of your compiler or other
> package inputs.

That's a common point of view in the numerical simulation community.
What the people defending it don't realize is that both reproducibility
and replicability matter, but in different situations and for different
reasons. Reproducibility matters for verification ("was the computation
done correctly?"), replicability matters for validation ("was the
computation the right one for the scientific question?").

Moreover, there is a practical use for reproducibility when checking for
replicability. Suppose you have a program and a result, then you run the
program with a different compiler and get a different result, too
different to be scientifically equivalent. No replicability. Then what?
How do you figure out what went wrong? The very first thing you want to
check is reproducibility: can you get the same result by using the same
compiler? If yes, fine, you can then look at intermediate results in
both versions of the computation to figure out where the differences
come from. If not, there is no point in wasting time on that: there is
something wrong with the code or the data you got, and you have to check
your sources first.

Giving up on reproducibility thus means giving up a valuable debugging
technique.

Cheers,
  Konrad

Re: Feedback from JRES in Dijon

[zimoun]

Hi Julien,

Thank you for this report.

On Thu, 5 Dec 2019 at 15:25, Julien Lepiller  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

Re: Feedback from JRES in Dijon

[Julien Lepiller]

So they are doing physical simulation (fluid dynamics), so they don't (can't) 
get the same result when running the same experiment twice. They wart 
replicability, that is, even if the results are different, they are close 
enough to each other that you have to draw the same scientific conclusion, 
independent of your compiler or other package inputs.

Le 5 décembre 2019 15:34:15 GMT+01:00, Pierre Neidhardt  a 
écrit :
>Thanks for the feedback!
>
>> 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.
>
>What's replicability?
>
>-- 
>Pierre Neidhardt
>https://ambrevar.xyz/

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: Feedback from JRES in Dijon

[Julien Lepiller]

I forgot to give you a link to the presentation. It's in French: 
https://replay.jres.org/videos/watch/c77b3a44-b75f-4c10-9f39-8fb55ae096d7

Also, Marc talked about jdev, another French conference where we could present 
Guix too: http://devlog.cnrs.fr/jdev2020

Le 5 décembre 2019 15:16:23 GMT+01:00, Julien Lepiller  a 
écrit :
>Hi Guix!
>
>I presented the project at JRES yesterday and had lots of questions and
>reactions.
>
>One person was wondering whether Guix would be a good idea for there
>cluster. I said yes then I redirected them to guix hpc.
>
>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).
>
>Another was asking about the possibility ofusing Guix to have multiple
>kernels and boot a debian with guix's kernel (so as to choose a
>compatible kernel at boot iiuc).
>
>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
>^^".
>
>That's only a few conversations that really marked me, but I had more,
>and I'll hopefully have more this afternoon and tomorrow.
>
>Marc, who organised the guile and guix days in Strasbourg last summer
>is here too and said he will write a tutorial on using vin to program
>in scheme. I'm lookinq forward to reading it!

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.