IRC channel logs

<civodul>"nice" regression that you found regarding swh

<zimoun>yeah, why is it not stable?

<zimoun>does it break ‘guix time-machine’?

<civodul>it's semi-breakage in the sense that one could always fetch the source with a new (guix swh) that works with today's API

<civodul>for users though, it looks broken, plain and simple

<zimoun>rekado_, civodul: yesterday, I had a meeting about a “new cluster” from scratch and they are installing Conda and Modules. In the same time, today I present Guix. Let see if people buy it ;-)

<dstolfa>zimoun: good luck!

<civodul>+1

<civodul>zimoun: "installing modules" really means compiling tons of packages by hand, and committing to keep them up-to-date and to grow the collection

<civodul>admins should be interested in *not* doing that

*dstolfa dislikes conda for an entirely different reason... one that has to do with anaconda the installer, not anaconda the conda thing

<dstolfa>makes it hard to search for anaconda documentation :(

<civodul>what's "anaconda the installer"?

<dstolfa>civodul: it's the installer that fedora, redhat and family use

<civodul>ah ok, i didn't know it was also called anaconda

<civodul>PurpleSym: i'm trying to see if we could get pytorch to use rocm

<civodul>it's looking for "HIP", does that ring a bell?

<PurpleSym>PurpleSym: Yeah, HIP is a part of rocm, which I did not package yet.

<PurpleSym>I had no use-case for it so far.

<civodul>ok, thanks

<civodul>i realized i could start with OpenCL support, which is more generic

<PurpleSym>It should be this one: https://github.com/ROCm-Developer-Tools/HIP

<civodul>i don't think i have the bandwidth for that right now, but i take note

<PurpleSym>It’s not too bad. Most of their code uses CMake, so it’s pretty straight-forward. I may take a look at it tomorrow.

<PurpleSym>(But then HIP seems to be only a thin layer above ROCm’s OpenCL support, so your gut feeling to go with OpenCL in the first place might be right.)

<civodul>hmm opencl-clhpp provides CL/cl2.hpp but i have code that looks for CL/cl.hpp

<zimoun>well, I will share the slides and maybe push them to maintenance/. WDYT?

<zimoun>civodul, yeah 200 modulefiles working on CentOS 7.

<zimoun>Ah, qestion about Guix working on Microsoft or Mac. Freedom cannot be used as answer. ;-)

<civodul>well, WSL on Windows

<civodul>zimoun: yes, we can definitely take the slides (Beamer?) in maintenance.git

<civodul>the question to ask re macOS IMO is "can we make reproducible research based on black bloxes?"

<zimoun>civodul, yeah beamer. Basically your template. :-)

<zimoun>arf, the research is already based on black boxes. Any instrument generating data is a black box. Most of the tools to clean the raw data are proprietary. Yes, Mac is not an acceptable platform for doing reproducible science and the result have to run on Linux machine. But 98% people around me are using Microsft or Mac. So they use Conda because it works there. Then, they asks Conda to the Linux cluster because they do not want to

<zimoun>learn another tool.

<zimoun>98% is a random number in the interval [70-99.9] ;-)

<zimoun>civodul: Guix on Mac is a “New Jersey style“ (worse is better)

<PurpleSym>civodul: You could try an old version of opencl-clhpp. They deprecated cl.hpp a while ago.

<civodul>PurpleSym: yes, i tried 2.0.11, which has cl.hpp, but now i get:

<civodul>error: ‘caffe2::Tensor’ is not a template

<civodul> CAFFE_KNOWN_TYPE(Tensor<OpenCLContext>);

<civodul>go figure

<civodul>i'd need some AI to find the right version

<civodul>zimoun: that's a sad situation!

<civodul>all i can say is that proprietary software is to computer science what magic potions are to chemistry

<zimoun>civodul, sad probably. But even computations using Guix also asks the question «can we make reproducible reproducible on black boxes?» because the hardware is black boxes as instrument is black boxes. :-)

<zimoun>so the question is more about the boundary, IMHO.

<dstolfa>zimoun: i find it easier to sell guix as: "you can choose versions of software and you can release your research in a way that anyone can run them on another linux box identically as you have when you released it"

<dstolfa>i don't think conda allows that?

<dstolfa>+ imo guix-jupyter is a big selling point. at least it was for me :)

<zimoun>dstolfa, yes. But people daily work on Mac or Microsoft. They will not change that. So they will use Conda because it works on Mac and Microsoft.

<civodul>zimoun: sure, but i think scientists should be pushing the boundaries in that respect

<civodul>black boxes should be intolerable

<dstolfa>zimoun: doesn't most of their work happen in a web browser anyway? i'd imagine they use jupyter notebooks?

*civodul has to go

<zimoun>civodul, imperfect world :-)

<efraim>I would think using guix in WSL would help at least the windows users

<zimoun>dstolfa, yes and no. For instance, the main dev behind Gmsh <https://gmsh.info/> uses Mac. They are a big of Free Software and so on. They use Emacs, developped a lot using Linux. Then, they switched to Mac because daily maintenance is easier. It just works: plug and play. An example among manyy others.

<zimoun>efraim, I agree. It had been my answer. There is more chance to have Guix on Windows than Guix on Mac. Because of WSL. :-)

*dstolfa fails to see how maintenance of a mac is easier than maintenance of something like RHEL, having used both...

<zimoun>dstolfa, I will not answer instead of people or try to convince that Mac is better. I use Linux and I am happy. :-) I am just pointing that a lot of people are using Mac and it will not change.

<dstolfa>zimoun: yeah, that's a sad reality unfortunately. we basically need a way to convince them to virtualize :P

<zimoun>Therefore, for most of scientific users, “we“ are trying to convince them for a double jump: switch from Mac to Linux *and* switch from Conda to Guix. The arguments must be really good. :-)

<zimoun>having a half-baked Mac port would reduce one jump, IMHO.

<dstolfa>zimoun: it would undoubtedly do so, it's just unclear to me how to do it

<zimoun>dstolfa: yeah. It is a lot of work. And if no one is paid to do so, I am doubtful that it will happen on spare time. Well, maybe we could try to change the message: from “no mac because black boxes” to “no mac because not enough resource and solution will be incomplete”. Somehow. :-)

<dstolfa>zimoun: well, i don't think i have much say in that, but i tend to agree that accessibility to free software on non-free systems is important for educating people and for adoption

<zimoun>dstolfa: I agree. :-)

<efraim>zimoun: have you looked at julia-documenter? it downloads a lot of javascript during run time

<efraim> https://github.com/JuliaDocs/Documenter.jl/blob/v0.27.6/src/Writers/HTMLWriter.jl

<rekado_>zimoun: if they are just ticking boxes you can say that Guix works on Mac because it can build Docker images, which will run just fine on a Mac.

<rekado_>whether this sleight of hand works depends on the audience, of course

<rekado_>I found that people fall for comparison tables all the time

<rekado_>you can make favorable comparison tables by listing a whole bunch of unimportant features that the competitors don’t implement and leave the impression that your tool is so much more comprehensive

<civodul>now we have a marketing strategy!

<rekado_>I’m not advocating for doing this, but the question whether it works on a Mac may be the attempt of a confused human brain to divide the problem into a list of features that can then be compared.

<rekado_>I’ve seen this dozens of times in IT purchasing discussions

<rekado_>it’s really frustating to observe

<civodul>yup

<rekado_>by mentioning Docker (which for many Mac users is a completely acceptable way of working) you could bypass the negative association of “missing” a feature.

<rekado_>ultimately what really matters is what their *actual* requirements look like. Often people want to keep all their options open, but it may lead to undesirable local maxima.

<civodul>true, saying "you can use it on macOS via Docker" is simple and probably good enough for many

<rekado_>when you install something with Conda on a Mac — that’s not even the same software that you get when you install the “same” thing on GNU+Linux.

<civodul>it seems quite common for devs on macOS to have a GNU/Linux VM or Docker image around

<civodul>rekado_: as in it has different dependencies?

<rekado_>yes.

<civodul>well, it necessarily does at some point in the graph, but maybe it's worse than that?

<rekado_>the application version and source may be superficially the same, but you have no way of quantifying equality.

<rekado_>you just get a mystery executable that claims to be the same application.

<rekado_>for some people that’s enough, of course.

<rekado_>but now it’s your turn to appeal to the desire to keep all options open — you can’t go beyond that limitation with a system that ignores equality/reproducibility.

<civodul>indeed

<rekado_>we know that R behaves differently when you swap out the BLAS implementation. Looking at a dependency graph you can imagine the potential contributions of each node to the behavior.

<rekado_>without accounting you can only trust that none of the many potential differences matter

<rekado_>we *can* do better than ignoring these differences, so I’d argue that we should not pick a system that *prevents* us from fine-grain reproducibility analysis.

<rekado_>seeing it from this perspective, using Guix-built things via Docker on a mac is actually *more desirable* than the alternative :)

<rekado_>anyway, that’s my elevator pitch — when the elevator is stuck and all mobile phones have run out of battery power, so conversation is the only alternative

<civodul>ah ah :-)

<civodul>but yeah, i think it should be easy to argue in a scientific context that we should aim for the maximum level of reproducibility

IRC channel logs

2021-09-09.log