IRC channel logs
2023-09-19.log
back to list of logs
<rekado>I just gave a talk in front of system administrators of various German research institutes <rekado>next week I’ll conduct a 3 hour workshop for those in the audience who want to learn how to set up Guix and build packages <civodul>then again, who wouldn’t be beguiled by one of your talks? :-) <rekado>(I find it very hard to gauge audience engagement when giving online talks) <civodul>like was it among a bunch of k8s conda binderhub whatever talks? <rekado>no, there’s some kind of regular seminar series <rekado>so I guess this means that those in attendance were actually interested to learn about it <civodul>let’s see if there’s a spike of Guix usage in .de :-) <zimoun>Do you plan to push your “slides“ somewhere? maintenance.git maybe? <rekado>spent a little over a third of the talk to motivate reproducibility and put the different deployment traditions into perspective <rekado>zimoun: yes, I’ll push the sources to maintenance.git some time later <civodul>i find that spending time on the motivation rather than the solution is fruitful <rekado>zimoun: I pushed the slides to maintenance.git <zimoun>rekado: nice slides! Now, the audience is convinced that Guix rocks, for sure! :-) <zimoun>civodul, rekado: at work, we are discussing to install 3 different OS on 3 different hardware (revamp an old cluster) for testing reproducibility and friends. The question is: which OS do you use in your lab? CentOS? Else? <civodul>by ‘3 different OSes’, you mean 3 different GNU/Linux distros, right? :-) <zimoun>Yes. For one, yeah maybe. There is question about proprietary drivers though. It is an old cluster and I cannot put an USB dongle as workaround. :-) <civodul>you don’t have to, plus i doubt the server requires non-free firmware/drivers <zimoun>And so, I guess your lab is running Guix System on the cluster, isn’t it? <civodul>it’s not, but the cluster predates Guix System <civodul>i mean, i’ve installed servers in our build farms etc. and have not encountered hardware requiring proprietary firmware/drivers <zimoun>Well, it appears to me already hard to convince HPC folks to install Guix on the top of any distro, so I will not try to convince them to install Guix System. Especially, when I am not personally convinced Guix System fits the constraints of cluster world. Anyway, we are drifting. :-) <zimoun>civodul: Which OS (distro) is running on the cluster of your lab? <zimoun>Thanks. Which one? And which linux kernel version? <civodul>without unpriviliged user namespaces, etc. <PurpleSym>civodul, rekado: I added webhooks for guix-cran, guix-science and guix-science-nonfree. <rekado>on our cluster it’s also CentOS 7 with what they call Linux 3.10. <rekado>I think they are committed to using a RHEL variant because they decided on proprietary storage(!) <rekado>proprietary firmware and drivers is not an obstacle to using Guix System; you’d just use a different kernel <rekado>*third-party* proprietary stuff is a bigger obstacle <rekado>but when your cluster depends on third-party proprietary modules you’ve already lost control over the design of your cluster anyway. <rekado>I’m looking for inspiration for the upcoming workshop. It’s supposed to prepare participants to contribute to Guix, so we’ll go through parts of the contribution workflow and play with channels. <rekado>for your past workshops do you have any materials (e.g. exercises or steps) you could share?