L'Open Source Initiative (OSI), fondation qui a défini et maintient la définition officielle de l'Open Source, et LinuxFr.org ont le même âge, à cinq mois près. Toutes deux sont nées en 1998, LinuxFr.org le 28 juin et l'OSI en février 1998. Nous avons fêté nos 20 ans ensemble à Paris Open Source Summit et depuis, nous nous retrouvons régulièrement autour de cupcakes, de bières ou toute autre occasion festive.

Mais il était temps d'aller un cran plus loin. LinuxFr.org (via l'association LinuxFr) devient membre de l'Open Source Initiative (OSI), comme organisation affiliée. Cela vient renforcer le lien avec les communautés du logiciel libre et de l'Open Source francophones et mettre en valeur les initiatives locales soutenant une collaboration ouverte dans le monde.

« Après d'innombrables célébrations d'anniversaire aux côtés de l'Open Source Initiative, LinuxFr.org est fier d'unir ses forces en tant qu'organisation affiliée. À une époque où l'Open Source est confrontée à des défis quotidiens, ce partenariat est essentiel pour mettre en avant des valeurs communes. Ce n'est qu'en rapprochant nos communautés que nous pourrons préserver et promouvoir les libertés que nous défendons tous deux. » – Florent Zara, membre du conseil d'administration de LinuxFr

L'OSI se réjouit « de collaborer avec [LinuxFr.org] pour soutenir notre engagement commun en faveur de l'Open Source. Leur participation renforce notre réseau international et souligne l’importance de nourrir les cultures Open Source dans toutes les langues et toutes les régions. »

Les cupcakes et la cuvée spéciale des 25 ans !

Je travaille depuis quelque temps sur Elpe, un projet qui vise à obtenir les bonnes propriétés de Nix/NixOS (les mises à jour atomiques, la reproductibilité), mais avec des paquets Ubuntu.

Le code : https://nest.pijul.com/pmeunier/elpe

L'idée est de définir des recettes de compilation en OCaml et de les envoyer à un backend Rust, qui se charge de les exécuter dans un conteneur sans réseau, en exposant uniquement le contexte nécessaire à la bonne exécution de la compilation. Les produits du build sont indexés par le contenu de la recette du build, et indexés une deuxième fois par le résultat : c'est ce deuxième hash qui est utilisé dans les dépendants du paquet, ce qui permet de construire un arbre de Merkle du système complet (et non seulement de ses sources), qui rend toute modification ultérieure facilement détectable.

De plus, le système de base provient des dépôts de paquet Debian ou Ubuntu. Cependant, tous les chemins sont hard-codés (comme dans Nix), ce qui permet de garantir la reproductibilité, au détriment toutefois du coût de mise à jour en termes d'espace et opérations disque.

Si le choix de Rust devient relativement consensuel par les temps qui courent, OCaml est plus surprenant. Après divers essais avec plusieurs langages, je l'ai choisi parce que c'est le seul langage avec à la fois :

• Une bonne approximation du système de types dont j'avais besoin: typage nominal et aussi structurel, entre autres.
• Un système de types relativement simple (pas de typeclasses ni de monades comme en Haskell, de borrow checkers comme en Rust ni de types dépendants comme en TypeScript).
• Du late binding, nécessaire pour exprimer des "overrides" et des "hooks", courants quand on veut compiler des choses (autoconf et make ont plein d'options de ce type, par exemple).
• Un compilateur ultra-rapide.
• Un bytecode, pour (dans le futur) contrôler aussi l'isolation du code de build de façon très légère.

La simplicité et l'expressivité d'OCaml sont bien adaptés à ce projet: les fonctions simples à concevoir y sont relativement claires à énoncer.

Pourquoi pas NixOS, me direz-vous ? En tant qu'utilisateur et contributeur depuis environ 10 ans, un certain nombre de problèmes plus ou moins récents m'ont motivé à explorer une alternative:

• En termes de gouvernance, la communauté a traversé dans la dernière année plusieurs crises de différentes tailles (Anduril, Devenv…). On pourrait y voir un signe de maturation ou au moins de croissance du projet, mais plusieurs éléments me permettent d'en douter, dont les réactions répétées de la fondation Nix, qui semble avoir beaucoup de mal à comprendre les messages pourtant clairs des contributeurs.

• Je vois aussi les choix de design imposés par les fondateurs du projet depuis quelques années comme un bien mauvais signe: les flakes (en 2020) étaient une première incarnation de cette tendance, et plus récemment la "distribution propriétaire" de Nix est clairement une mauvaise idée, alors que la qualité de code de Nix n'est pas au niveau où on l'attendrait et que le gros du projet repose depuis plusieurs années sur le travail pharaonique des contributeurs de Nixpkgs.

• On pourrait parler longtemps de la sécurité de Nix, qui me fait de plus en plus peur y compris pour mon usage personnel. Les process de gestion des rapports ne me conviennent pas, de même que l'opacité de certains choix techniques (les flags de compilation désactivés sur certaines plateformes, entre autres), souvent bien cachés dans les entrailles de Nixpkgs.

• Enfin, le langage trop complexe à utiliser (principalement par manque de typage statique et de messages d'erreurs pertinents) rend Nix difficile à utiliser au sein d'une organisation d'une taille importante, et encourage les comportements peu inclusifs (éviter d'écrire de la doc, inventer des casse-têtes pour faire des choses simples…). Je suis bien sûr conscient que des entreprises (comme Anduril) et des ONGs (comme Médecins Sans Frontières) l'utilisent, mais je ne pense pas que ce soit généralisable aux situations où j'aimerais voir ce genre de projet utilisé.