Un an de financement pour le développement de FreeBSD
(daemonology.net)- Développement de l’ingénierie de publication de FreeBSD et de FreeBSD/EC2 pendant un an avec le soutien d’Amazon
- Travail mené en parallèle sur la gestion des releases et les améliorations liées à EC2, avec une moyenne d’environ 50 heures par mois
- Résolution de problèmes fonctionnels majeurs et amélioration de la qualité, notamment pour la gestion de l’alimentation des instances Graviton, la prise en charge du hotplug et les performances de démarrage
- Extension des types d’AMI et automatisation des builds afin d’améliorer la diversité et l’efficacité de la distribution des AMI FreeBSD
- Après la fin du financement, un ralentissement du rythme de développement et une stagnation partielle de certaines fonctionnalités sont attendus
Retour sur un an de financement du développement de FreeBSD
# Contexte de départ et processus de financement
- Je gère la plateforme FreeBSD/EC2 depuis 2010 et j’assure aussi le rôle de responsable de l’ingénierie de publication de FreeBSD depuis novembre 2023
- Je recevais déjà de petits financements via Antithesis, Patreon et d’autres canaux, mais le travail lié aux releases empiétait fortement sur le temps consacré au développement de FreeBSD/EC2
- Des discussions avec Amazon au sujet d’un sponsoring des travaux sur EC2 se poursuivaient depuis plusieurs années, et en avril 2024 j’ai été mis en relation avec la personne chargée du budget, ce qui a débouché sur un financement d’un an
- Le financement a été versé via GitHub Sponsors, et la période visée par Amazon ne coïncide pas forcément avec les dates effectives de versement
# Répartition du financement et du temps de travail
- À la demande d’Amazon, je me suis engagé à fournir 40 heures par mois de travail sur l’ingénierie de publication de FreeBSD et le développement EC2
- En pratique, j’ai consacré environ 50 heures par mois, réparties entre 20 heures sur les problèmes EC2, 20 heures sur les releases et 10 heures sur d’autres tâches d’ingénierie
- Le volume horaire variait fortement d’un mois à l’autre
# Gestion des releases FreeBSD
- En mettant en place et en pilotant un calendrier de releases trimestrielles pour FreeBSD, quatre releases ont été réalisées en un an : FreeBSD 13.4 (2024.9), 14.2 (2024.12), 13.5 (2025.3), 14.3 (prévu pour 2025.6)
- Chaque release comprenait l’incitation des développeurs à respecter la date limite de soumission du code, l’approbation et la coordination des demandes de merge, la construction et les tests des images, la rédaction des annonces et la correction de diverses erreurs de build liées aux releases
- Le temps consacré à l’ingénierie de publication variait entre 33,5 et 79 heures par trimestre, avec une charge qui diminuait progressivement au fil du temps grâce à la stabilisation
# Principales améliorations de fonctionnalités EC2 et progrès de qualité
Pilote d’alimentation pour instances Graviton et prise en charge du hotplug
-
Résolution d’un problème qui empêchait FreeBSD de détecter le signal d’arrêt propre envoyé par l’API EC2 sur les instances Graviton
- Utilisation de l’objet ACPI _AEI pour relier le signal de type "power button" basé sur GPIO à la logique du pilote
- Le problème de désactivation du périphérique causé par une incohérence du réglage du drapeau Pull Up dans les tables ACPI fournies par EC2 a été contourné par l’ajout du paramètre ACPI_Q_AEI_NOPULL dans les AMI FreeBSD/EC2
-
Diagnostic et correction d’un ensemble de problèmes de hotplug des périphériques (en particulier le hot unplug) sur les instances EC2 Graviton et x86
- Traitement de plusieurs catégories de bugs, dont des fuites d’IRQ, des incohérences entre l’état d’alimentation PCI et les signaux de l’OS, ainsi que des périphériques PCI « fantômes »
- Application de quirks ACPI comme solution temporaire (par exemple ACPI_Q_CLEAR_PME_ON_DETACH, ACPI_Q_DELAY_BEFORE_EJECT_RESCAN), en attendant la correction des bugs côté EC2
Automatisation des tests de hotplug et amélioration de la qualité
- Développement d’un script attachant et détachant de manière répétée des volumes EBS dans l’environnement EC2, avec validation de la stabilité sur 300 tests consécutifs
- Amélioration de la qualité en réglant à 0 seconde, sur EC2, le délai inutile de 5 secondes du hotplug PCIe qui n’a de sens que sur des systèmes physiques
Amélioration des performances de démarrage
- Amélioration méthodique des problèmes de vitesse de démarrage de FreeBSD/EC2 grâce à la collecte et à l’analyse de données
- Résolution successive de plusieurs problèmes : triplement du temps de démarrage début 2024 après augmentation de la taille du disque racine, retard d’initialisation de l’entropie du noyau sur les instances Graviton2, allongement du temps de démarrage avec ZFS, et problèmes de prise en charge d’IPv6 liés à IMDSv2
- Des optimisations ont été réalisées sur plusieurs axes, notamment l’écart de performance de démarrage selon le système de fichiers, l’inefficacité de l’approvisionnement en entropie et les retards d’initialisation réseau
# Élargissement de la gamme des AMI FreeBSD et automatisation du build/de la distribution
- En plus des AMI existantes base et cloud-init, ajout d’une small AMI (suppression du code et des outils inutiles de débogage et de test, taille de 1 Go) et d’une builder AMI (constructeur personnalisable par l’utilisateur)
- Avec 4 types d’AMI * 2 systèmes de fichiers (UFS/ZFS) * 2 architectures (amd64/arm64) * 3 versions (13, 14, 15), le nombre de combinaisons d’images a fortement augmenté ; cela a conduit à l’automatisation de la suppression des anciennes images et à la mise en script du processus, avec nettoyage de 336 To de snapshots EBS
# Améliorations générales d’ingénierie
- La parallélisation des builds d’AMI/releases FreeBSD a réduit le temps total de build d’environ 22 heures à 13 heures, laissant davantage de marge pour ajouter plus de types d’AMI
- Des tests automatisés basés sur des instances EC2 et des comparaisons avec diffoscope ont permis d’identifier et de corriger des problèmes de reproductibilité des builds
- En parallèle, diverses petites tâches ont aussi été menées : revue de patchs du pilote ENA, build de conteneurs OCI et envoi au registre, amélioration d’outils liés à AWS, rapports sur des problèmes de sécurité, etc.
# Perspectives et limites
- Le rôle de maintien de l’ingénierie de publication de FreeBSD et de la plateforme EC2 reste assuré, mais le temps que je pourrai y consacrer devrait diminuer par rapport à avant
- Les releases FreeBSD 15.0 (décembre 2024), 14.4/15.1/14.5/15.2 (2026) sont prévues comme annoncé, mais le rythme des ajouts de fonctionnalités et des corrections de bugs devrait ralentir
- Des chantiers inachevés, comme l’extension automatique du système de fichiers, l’automatisation du multi-NIC et du hotplug, la distribution d’AMI pré-corrigées, un outil web pour les utilisateurs EC2 ou la prise en charge de FreeBSD/Firecracker, risquent de stagner à long terme
# Mot de la fin
- Ce financement d’Amazon représente une opportunité extrêmement rare pour un développeur open source, et l’auteur exprime sa fierté pour le travail accompli ainsi que sa gratitude
1 commentaires
Commentaires sur Hacker News
Partage de la nouvelle que FreeBSD a été ajouté aujourd’hui à la page de téléchargement de ziglang.org ; les utilisateurs de FreeBSD peuvent désormais récupérer facilement des builds de la branche master compilés automatiquement par la CI
FreeBSD est maintenant officiellement entièrement pris en charge comme cible de cross-compilation ; il est possible de compiler vers FreeBSD de façon similaire à Linux, par exemple avec
zig cc -o hello hello.c -target riscv64-freebsdS’il y a des dépendances C/C++, elles peuvent être importées et compilées facilement avec le système de build de Zig, ce qui permet de cross-compiler sans difficulté des projets assez complexes vers FreeBSD
L’espoir est que cela pousse davantage de projets à ajouter le support et les tests FreeBSD dans leur CI
Il y avait beaucoup de passages amusants à lire
Un cas où, dès la première semaine de 2024, le processus de démarrage de FreeBSD est soudainement devenu trois fois plus lent ; après avoir longuement suivi les commits, la cause s’est révélée être l’augmentation de la taille du disque racine de 5 Go à 6 Go
Après avoir demandé à un contact chez Amazon, la réponse avait presque quelque chose de magique : « on ne sait pas exactement, mais il vaut peut-être mieux ne pas le savoir »
Fait important, en augmentant la taille du disque racine à 8 Go, les performances sont revenues à leur niveau précédent
En entendant ça, j’ai maintenant vraiment envie de savoir pourquoi
Je me demande combien de temps le bisect des commits a réellement pris pour trouver ce problème
J’imagine qu’il fallait recréer l’image et redémarrer la VM à chaque fois
Mention d’un billet de blog personnel de 2006 indiquant que la limite de taille d’objet originale de S3 était de 5 Go
https://aws.amazon.com/blogs/aws/amazon_s3/
Impossible de dire si cela a un lien direct avec la baisse de performances de FreeBSD
Beaucoup de choses avancent aussi sur le support des ordinateurs portables
Lecture d’une information selon laquelle la BSD Foundation investit 750 000 $ pour se concentrer sur diverses fonctionnalités, dont l’implémentation de l’état de veille S0ix
Le projet associé peut être consulté sur https://github.com/FreeBSDFoundation/proj-laptop
J’aurais aimé qu’Amazon soutienne et contribue davantage, mais en réalité cela semble se limiter au minimum pour FreeBSD
Amazon n’apparaît même pas dans la liste des sponsors de FreeBSD ; Google n’a donné que 9 k$ l’an dernier, et Apple comme Meta/Facebook sont absents
À l’inverse, il faut saluer la présence de Microsoft sur la liste
Il est surprenant que ces grandes entreprises, qui tirent pourtant beaucoup de bénéfices de FreeBSD et d’OpenBSD, ne fassent pas automatiquement des dons chaque année
Les informations sur les sponsors sont disponibles sur https://freebsdfoundation.org/our-donors/donors/?donationYear=2024
Je suis d’accord sur le fait qu’Amazon devrait soutenir davantage FreeBSD
Mais l’absence dans la liste des donateurs de la FreeBSD Foundation ne signifie pas qu’il n’y a aucun soutien
Le financement de développement que j’ai reçu ne passait pas non plus par la fondation, et en pratique, le développement financé par la fondation ne représente qu’environ 10 % du soutien total des entreprises
Le développement soutenu par la fondation reste important car il permet de se concentrer sur des travaux bénéfiques à FreeBSD lui-même, mais à l’échelle globale cela reste minoritaire
Remarque selon laquelle on ne peut pas voir l’ensemble de la situation à partir de ce seul commentaire
Cela ne montre qu’un instantané des dons faits à la fondation par année, tandis que les contributions de développement elles-mêmes sont résumées dans les notes de version de chaque release
https://www.freebsd.org/releases/
Je me demande pourquoi Microsoft soutient FreeBSD
Les extensions Hyper-V ne sont pas aussi complètes que sur Linux, il n’existe pas de port officiel de .NET, et Microsoft ne semble pas non plus exploiter de services basés sur FreeBSD
Avis selon lequel Amazon est l’entreprise du FAANG qui contribue le moins au FOSS
Beaucoup de respect pour cperciva
Je me demande comment il parvient à gérer à la fois Tarsnap et FreeBSD
Pour une réparation simple, on peut soit la faire soi-même, soit appeler un professionnel
Seule une partie du temps consacré à ce travail sur FreeBSD venait du temps dégagé par Tarsnap, et c’était moins important qu’on pourrait le croire
J’ai déjà utilisé FreeBSD comme station de travail par le passé, et c’était impressionnant
Je voulais utiliser FreeBSD comme passerelle/pare-feu/serveur DNS/DHCP à la maison, mais faute de support pour les pilotes de carte réseau 10GbE, j’ai finalement choisi Nix
C’est agréable de voir que FreeBSD reste bien maintenu
Je me demande qui sont les plus gros utilisateurs de FreeBSD/EC2
Moi non plus, je ne le sais pas vraiment
En pratique, les utilisateurs qui me contactent représentent probablement moins de 0,1 % de l’ensemble des utilisateurs de FreeBSD/EC2
J’aimerais vraiment savoir qui utilise FreeBSD sur EC2
Je me demande si Netflix n’utilise FreeBSD que sur ses edge boxes
Je me demande quelle niche FreeBSD occupe dans l’univers Unix
Question sur la raison d’utiliser FreeBSD, plus complexe, plutôt qu’OpenBSD ou NetBSD, et si, quand on a besoin de ZFS, de Nvidia ou d’ELF, Linux ne serait pas simplement un meilleur choix
Je connais les problèmes liés à GNU, mais il existe aussi des alternatives comme Musl Void ; j’ai donc une curiosité sincère sur la « personnalité » propre à FreeBSD
Expérience d’utilisation de FreeBSD dans la finance, à la fois sur EC2 et sur des serveurs bare metal en datacenter
Usage intensif de zfs et des jails
Tous les services tournaient de manière isolée dans chaque jail, ce qui était très rentable
Quand une partie a été migrée vers le cloud pour opérer un hybride Linux(k8s)+FreeBSD, les coûts ont fortement augmenté
Gérer directement le datacenter a ses inconvénients, comme le remplacement des disques ou la gestion des incendies, mais AWS offre de nombreuses fonctionnalités comme le multi-région, avec le coût qui va avec
zfs a été d’une grande aide lorsqu’une table de base de données en production a été supprimée par erreur ; grâce à un snapshot, il a été possible de revenir en arrière immédiatement, et zfs servait aussi pour les sauvegardes
Expérience également de troubleshooting en production avec dtrace
Quand seuls des serveurs FreeBSD étaient exploités, l’administration était simple car il n’y avait qu’une seule famille d’OS ; avec l’introduction de Linux, chaque équipe utilisait sa propre distribution, ce qui créait de la confusion
J’apprécie FreeBSD comme structure intégrée noyau + OS
De mon point de vue, FreeBSD donne l’impression de mélanger assez bien les qualités d’OpenBSD et de NetBSD
Autrefois, FreeBSD se distinguait par son optimisation pour les CPU Intel et sa sécurité solide, avec surtout le support de ZFS comme facteur décisif
Le support natif des pilotes Nvidia pour FreeBSD n’est arrivé que récemment
Au final, FreeBSD combine bien les atouts des autres BSD et une bonne stabilité matérielle
FreeBSD a une base d’utilisateurs bien plus large qu’OpenBSD ou NetBSD
Son catalogue logiciel est lui aussi bien plus vaste, au point de permettre un usage quotidien sur desktop
Si je n’utilise pas Linux, c’est parce qu’il est trop lié aux intérêts des entreprises
Avis selon lequel FreeBSD surpasse Linux sur le support de ZFS
Grâce aux questions de licence, FreeBSD offre un meilleur environnement
FreeBSD est plus performant qu’OpenBSD en matière de débit réseau
En général, les BSD évoluent moins vite, ce qui en fait de bonnes plateformes intégrées
Avis selon lequel cet article ne donne pas une image très favorable de l’environnement de développement de FreeBSD
Étant donné la complexité d’un OS de cette ampleur, il semble regrettable qu’il n’y ait pas au moins une personne à plein temps comme release manager, et que la réalité se limite à un travail à temps partiel pendant un an
Malgré cela, l’existence de FreeBSD reste importante, car Linux n’est pas la seule alternative possible