Interesting things I saw at FOSDEM 2024 -- Day 1

Has the FOSDEM logo always been a coronavirus ?

It's not my plan to talk much about opensource/tech stuff much on this capsule. Those things are more part of my work than of my hobbies. And plenty of other capsule have interesting things to say about those subject. But I am at FOSDEM this year so here are quick notes of the presentation I found interesting and what I liked about them.

Reproducibility is always hard to do to deal with, but nowerr near as hard as having to redo an experiment 6 month later.

Philippe Swartvagher had a really interesting presentation on how to make experiments more reproducible. Guix got to shine in the spotlight again thanks to its ability to provide reproducibility for code, patching, builds, and environment all in one convenient description.

On the post-processing and ploting side of things, the tow advice from Philippe hit close to home:

• Separate post-processing from plotting. You only want to do the former once, but you'll be doing a lot of the second one.
• Do not factorize code used for plotting as much as you would other code. More likely thant not you will want different graph to have different adjustment.

All in all that talk was very reminisent of my experience in research. I still haven't tried Guix but I'm now more interested.

Notebooks are no inherently reproducible, but this can help.

Antoni Ivanov presented the Versatile Data Kit (VDK) a plugin for JupyterLab, that is designed to help turn notebooks into production computation drivers. The problems this tool tries to solves are also for the most part the things that make notebooks unreproducible. So this might be a tool to look into if your are using Jupyter and want to make sure you'll be able to rerun the notebook perfectly.

Reproducible builds

In ten years debian has gone from thinking it would be impossible for people to reproduce their exact binary distribution from source, to having 95% of their packages be reproducible. Impressive work, but the biggest challenge are are yet to come since neither the kernel nor the grub are reproducible.

TPM

Saw an interesting presentation by James Bottomley about wanting to use the Trusted Platform Module for they cryptography needs. The global take away seemed to be that integration has been somewhat slow due to low standardisation in the modules space. But it did raise a few interesting ideas.

• Most GPG key outlive le laptop they are used on, so keys generated on a TPM are not very good for this use case. Generating a key outside of the module and importing it is a bit more involved but should work with suffciently recent versions of gpg (>= 2.3).
• Form that standpoint storing ssh keys on the module seems to be a good idea. You should have one ssh key per machine anyways. But it seems getting ssh-agent to use the TPM requires patching.
• Modern TPM use key derivation from a seed to generate key-pairs for different cryptosystems in a deterministic fashion. Creating what is essentially a cross-cryptosystem key set. Boggles my mind.