Technology

FOSDEM 2025

Publié le 04/03/2025
12 mins de lecture

FOSDEM 2025

Le Fosdem a eu lieu pendant le samedi 1 et dimanche 2 février 2025 sur le plateau du Solbosch. Pour cette occasion, l’ULB Université libre de Bruxelles accueille plus de 1000 présentations et des milliers de visiteurs

Les quelques thématiques majeures :

Conférences dédiées aux languages informatiques: Java, Python, Ada, Rust, Go, Ruby, Javascript, Swift
Conférences dédiées aux bases de données: PostgreSQL, MySQL, Cloud Native Databases
Logiciels et fondations libres: LibreOffice, Mozilla, GCC, LLVM, Kernel, eBPF, Android Open Source Project, Linux distributions
Data: Data Analytics, HPC, Big Data & Data Science,
Divers: Monitoring and Observability, Robotics and Simulation, Quantum Computing, Containers, Radio, Railways and Open Transport, Legal and Policy, etc

Programme

Echantillon des conférences qui nous ont intéressées:

Java Valhalla Stage 2 - Nullness Emotion

Dans cette présentation, Remi Forax a introduit l’étape 2 du projet tant attendu Valhalla, vieux de plus de 10 ans. Il a expliqué que l’étape 1, qui introduit les « value objects », est prête à être livrée. Pouvoir éliminer le null permet entre autres que les objets soient « flattened » en mémoire et stockés sur la stack, améliorant performances et utilisation mémoire.

Remi a détaillé les défis liés aux champs de type value objects, notamment l’élimination de la possibilité de null pour des optimisations poussées. La syntaxe proposée pour les classes value-type ressemblerait à :

String! pour indiquer un String non-nullable.
String? pour un String nullable (comme les références classiques).

La question des valeurs par défaut se pose si null n’est pas autorisé. Notons que l’objectif n’est pas la null-safety, mais l’optimisation des value types et de leur memory layout.

Vous pouvez trouver la présentation ici.

Advancing Java Profiling

Johannes Bechberger et Jaroslav Bachorik ont fait le tour des outils de profiling Java (non commerciaux) disponibles, en expliquant les avantages et inconvénients de chacun : le JFR, l’async-profiler et l’eBPF Profiler d’OTel, dont j’ai découvert l’existence lors de cette présentation.

Parmi les points clés à retenir :

Lors de l’utilisation de JFR, il faut toujours utiliser `-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints` pour réduire le safepoint bias.
JFR est sûr et stable, mais n’est pas un véritable CPU sampler en raison de son fonctionnement et n’affiche pas les native frames.
L‘async-profiler (Linux et Mac) est un CPU sampler plus précis et affiche les native frames, mais est légèrement moins stable que JFR et dépend des internes de la JVM (vmstructs).
L’eBPF Profiler d’OTel est également un meilleur CPU sampler que JFR, utilisant eBPF comme son nom l’indique. Il est très stable, mais repose aussi sur les internes de la JVM.

Les speakers parient sur l’avenir de JFR pour combler ses lacunes, comme un meilleur CPU sampling, l’affichage des native frames et les « profiling labels » (des étiquettes aux échantillons collectés, comme une API REST ou une base de données liée à un utilisateur). Cela simplifierait la visualisation des résultats.

Vous pouvez trouver la présentation ici.

ClickHouse - How we built a new powerful JSON data type for ClickHouse

By Pavel Kruglov & Robert Schulze ClickHouse est une base de données relationnelle, orientée colonne conçue pour être scalable pour les traitements d’agrégation OLAP. Json est devenu un format incontournable pour représenter des données structurées mais aussi non structurées. Mais cette flexibilité ne facilite pas le stockage dans les bases de données orientées colonne. Robert nous explique comment ClickHouse a créé un nouveau type puissant pour représenter les données Json qui repose sur 2 nouveautés:

Variant Data Type
Dynamic Data Type Le type JSON est disponible en version béta, n’est pas encore prêt pour une utilisation en production, mais montre des performances prometteuses.

Python - Understanding programming peculiarities

By Katie McLaughlin

Katie a exposé quelques curiosirés de languages, notamment concernant le comportement des opérateurs arithmétiques. Javascript, Bash et Python 2 révèlent quelques uns de leurs secrets de spécification qui permettent d’expliquer ces comportements étranges à première vue. Javascript:

> [] + []
« »
> [] + {}
« [object Object] »
> {} + []
0
> {} + {}
NaN

Katie demande fréquemment la participation du public pour voter sur le résultat d’une expression et s’intéresse enfin au cas de Python 3.

Anatomy of a Python OpenTelemetry instrumentation

By Riccardo Magliocchetti/

Le principe d‘OpenTelemetry est de recueillir les logs, métriques et traces, pour tout langage et notamment pour le langage Python. Pour commencer, opentelemetry-bootstrap est un outil en ligne de commande qui permet de lister et installer les bibliothèques d’instrumentation disponibles pour les dépendances de nos projets (ex: opentelemetry-instrumentation-asyncio, opentelemetry-instrumentation-flask)

Riccardo nous montre qu’OpenTelemetry se base sur des composants Python souvent méconnus pour fonctionner et instrumenter le langage Python. OpenTelemetry a recours au module python sitecustomize.py et utilise les entry points pour charger la configuration et découvrir les plugins. Riccardo nous apprend que opentelemetry-instrumentation permet l’instrumentation automatique et utilise le monkey patching (via la bibiliothèque wrapt) pour instrumenter le code.

PostreSQL

Anatomy of Table-Level Locks in PostgreSQL by Gulcin Yildirim Jelinek

Cette présentation commence par évoquer les mécanismes de verrous implémentés dans postgresql et donne plusieurs recommandations pour diminuer les impacts des verrous sur une table, par exemple lorsqu’elle reçoit des longs SELECT et un changement de schéma. Parmi les possibilités, on peut utiliser des requêtes CONCURRENTLY (qui ne sont pas transactionnelles) ou découper les opérations en plusieurs requêtes. Gulcin recommande enfin l’utilisation de pgroll pour opérer des migrations de schémas sans interruption de service.

https://pgroll.com/blog/anatomy-of-table-level-locks-reducing-locking-impact

Don't stand there and gawk, extend it!

By Efraim Flashner Présentation des fonctionnalités de awk à partir d’exemples concrets. J’ai appris qu’il est également possible de créer une sorte de bibliothèque de scripts en les déposant dans un répertoire et d’y faire référence via la variable d‘env AWKPATH et de l’option -i:

export AWKPATH= »$PWD/lib »
awk -i util.awk ‘BEGIN{print myfunction($1)}’

Mozilla - Lumigator: evaluating LLMs made simple

By Davide Eynard

Lumigator est une application Python conçue pour évaluer et comparer les performances de grands modèles de langage (LLM). Indépendant de l’infrastructure, il peut être exécuté sur un ordinateur local, sur un cluster local ou dans le cloud. Il s’appuie sur des standards d’interopérabilité tels que l’API Openai. Il offre une API, un SDK et une interface utilisateur web simple. Le premier cas d’utilisation choisi par l’équipe pour évaluer les modèles est le résumé de texte.

Lumigator est construit sur une stack open source: FastAPI pour le server web, Ray pour le cluster; il utilise une base de données SQL (SQLite on local) pour stocker les datasets, les expériences, métadonnées, et enfin un stockage objet S3 (MinIO on local).

Zero-Code Distributed Traces for any programming language

By Fabian Stäber, Rafael Roquetto

Fabian et Rafael, ingénieurs à Grafana Labs, présentent Grafana Beyla, une instrumentation zero-code qui s’appuie sur eBPF et qui est proposée en donation à OpenTelemetry (CNCF) : sous le nom opentelemetry-ebpf-instrumentation.

Les métriques de réseaux (HTTP, SQL, gRPC, Redis, Kafka, etc) sont facilement collectées par eBPF pour n’importe quel langage ou framework; mais les traces distribuées sont plus difficiles à collecter et à suivre : la difficulté réside dans la propagation du contexte de la trace. Les traces sont identifiées par :

SpanId: identifie chaque requête individuelle,
TraceId: relie ensemble les spanId et est commune pour toutes les spans d’une trace.

Rafael présente plusieurs approches pour propager le TraceId qui peut être décodé par eBPF dans l’en-tête HTTP ou l’en-tête IP des paquets réseau.

CERN EOS Open Storage and CTA Service

Deux présentations ont été faites par des employés du CERN à propos de leur gestion de la grande quantité de données générées par le Large Hadron Collider (LHC).

Dans la première présentation, From Particle Collisions to Physics Results: EOS Open Storage at CERN, Abhishek Lekshmanan et Guilherme Amadio nous ont présenté EOS, leur service open source de stockage et d’analyse de leurs données. Le volume de données s’élève aujourd’hui à 1030 Petabytes (PB). La présentation explique l’architecture de données qui implique des metadata server (MGM), QuarkDB et des file storage server (FST), ainsi qu’une interface web. Après une expérience sur le LHC, les données sont transférées pour être prise en charge par EOS à un débit de transfert qui varie entre 16 et 155 Gigabytes par secondes (GB/s) dépendant du site du LHC d’où elles proviennent. Les données sont ensuite transférées par EOS vers les cartouches de données qui servent d’archives à un débit entre 15 et 60 GB/s. EOS transfert aussi les données vers le cloud à un débit moyen de 450 GB/s pour un pic de 1.3 terabytes par secondes (TB/s).

Dans la deuxième présentation, CERN CTA Service: writing LHC data to tape with opensource software on commodity hardware, Julien Leduc nous explique en détails comment le service CERN Tape Archive (CTA) gère plus de 900 PB de données à travers 50 000 cartouches de données. Plusieurs types de cartouches sont utilisées comme les cartouches 3592JD, 3592JE, 3592JF, LTO-7M, LTO-8, et LTO-9, et avec des capacités de stockage allant de 59 à 551 PB par cartouche. Quand des données doivent être transférées de EOS aux cartouches, EOS les transfert d’abord vers les SSD de CTA qui servent de buffer avant qu’elles soient transférées vers les cartouches. Il n’y a aucune redondance pour les données archivées, et les données sont supprimées des SSD une fois le transfert vers les cartouches fini. Un repack des données est parfois nécessaire dû à des cartouches défectueuses, des cartouches seulement partiellement utilisées, ou des types de cartouches trop anciens. Le repack est fait en passant les données des cartouches vers les SSD, puis des SSD vers les nouvelles cartouches.

Quantum type system in H-hat quantum programming language

Dans la présentation Quantum type system in H-hat quantum programming language, Eduardo Maschio nous parle d’une nouvelle approche à l’adaptation de la programmation “classique” aux propriétés et comportements des machines quantiques. Le langage Ĥ (ou H-Hat) introduit des types et des variables quantiques distingués par l’utilisation du caractère ‘@’. Il a notamment donné les exemples du type “@bool” et d’une variable “@q:@bool = @redim(@false)”. Quand on y assigne quelque chose, les variables quantiques en Ĥ accumulent des instructions classiques dans une pile plutôt que de les exécuter immédiatement. Pour lire la valeur de la variable, il faut ensuite la caster en un type classique comme dans l’exemple « cast(u32 @redim(@3<@u2>))« , et c’est à ce moment que les instructions sont exécutées. Cette approche innovante vise à intégrer de manière plus intuitive les paradigmes de l’informatique quantique dans le développement de logiciels, permettant ainsi aux développeurs de tirer parti des capacités quantiques de manière plus efficace.

En pratique

Le tramway dessert l’arrêt « ULB » (Tram 8/25 Bus 71/72). https://www.stib-mivb.be/accueil/acheter Ticket digital smartphone: 2.70€. Paiement par carte bancaire sans contact: 2.30€

Il y a 2 parkings, mais ils sont de petites tailles, il est possible de se garer dans les rues aux alentours https://fosdem.org/2025/practical/transportation/

Attention Bruxelles est une ZFE, il est nécessaire d’enregistrer son véhicule auparavant sur https://lez.brussels/mytax/fr/

Plusieurs bâtiments de l’université accueillent les présentations, notamment:

le vieux bâtiment en forme de U qui abrite plusieurs grands amphis, grinçants et pas très confortables
le bâtiment moderne K qui abritent des petites salles de TD
le bâtiment H qui contient des amphis sombres de taille moyenne.

Dans les couloirs, on peut retrouver des stands de sociétés ou de projets open source (PostgreSQL, Jenkins, Gitlab, etc); on peut également y acheter le T-shirt Fosdem. Attention, certaines salles, relativement petites dans le batiment K sont prises d’assaut et il est difficile d’y obtenir une place au milieu de la demi-journée. Si vous avez comme objectif une présentation à ne pas rater, mieux vaut prévoir de vous rendre dans la salle 1h avant pour les présentations précédentes. Sinon, il est également possible de suivre le live de toutes les salles sur le site du Fosdem avec une bonne connection internet.