Un an de financement pour le développement de FreeBSD

 (daemonology.net)
2 points par GN⁺ 2025-06-07 | 1 commentaires | Partager sur WhatsApp
  • Alors que la maintenance de FreeBSD/EC2 et l’ingénierie de release entraient en conflit dans le temps de bénévolat d’une seule personne, le financement d’un an par Amazon a permis d’avancer simultanément sur les opérations de release et les améliorations de la plateforme EC2
  • Le financement représentait nominalement 40 heures par mois via GitHub Sponsors, mais le travail réel a atteint en moyenne 50 heures par mois, réparties approximativement entre 20 h pour les problèmes EC2, 20 h pour l’avancement des releases et 10 h pour d’autres tâches d’ingénierie de release
  • En un an, la gestion des releases FreeBSD 13.4, 14.2, 13.5 et 14.3 s’est accompagnée de travaux prioritaires comme la gestion du signal d’arrêt sur AWS Graviton et le hot-plug de périphériques sur EC2
  • Pour identifier des régressions de performances au démarrage, des builds hebdomadaires d’AMI EC2 depuis 2018 ont été benchmarkés, ce qui a permis de repérer et corriger des causes de latence liées à la taille du disque racine, à l’initialisation d’entropie EFI, aux groupes de transactions ZFS et aux changements IPv6 d’IMDSv2
  • Le rôle se poursuit après la fin du financement, mais avec moins de temps disponible pour corriger directement les problèmes de dernière minute avant une release ou continuer à faire avancer la feuille de route des fonctionnalités EC2

Goulots d’étranglement avant le financement et répartition du temps

  • La maintenance de FreeBSD/EC2 se poursuit depuis le premier démarrage de FreeBSD sur Amazon EC2 en 2010, et en novembre 2023 s’y est ajouté le rôle de responsable de l’ingénierie de release de FreeBSD
  • Les petits financements d’Antithesis et du Patreon FreeBSD/EC2 ne suffisaient pas à assumer ces deux rôles
    • La liste des fonctionnalités à implémenter stagnait
    • Même lorsque des anomalies étaient repérées, il manquait du temps pour les enquêter, ce qui entraînait de plus en plus de reports
    • Début 2024, l’inquiétude grandissait quant à la capacité à être un “bon propriétaire” de la plateforme FreeBSD/EC2
  • En avril 2024, après avoir trouvé chez Amazon un interlocuteur disposant d’un budget, des discussions ont eu lieu sur le calendrier, le périmètre et la procédure, puis Amazon a décidé de financer le travail pendant un an via GitHub Sponsors
  • Le financement visait 40 heures par mois combinant l’ingénierie de release de FreeBSD et le développement de FreeBSD/EC2
    • Il a été expliqué qu’un financement ne couvrant qu’un seul des deux volets n’était pas réaliste, car ils dépendent l’un de l’autre
    • Dans les faits, l’investissement a atteint en moyenne environ 50 heures par mois
    • En moyenne, cela représentait 20 heures pour des sujets spécifiques à EC2, 20 heures pour l’avancement des releases FreeBSD et 10 heures pour d’autres tâches liées à l’ingénierie de release, avec de fortes variations selon les mois

Opérations de release trimestrielles et amélioration des builds

  • Conformément au calendrier de releases trimestrielles de FreeBSD annoncé en juillet 2024, 4 releases ont été gérées en un an
    • FreeBSD 13.4 : septembre 2024
    • FreeBSD 14.2 : décembre 2024
    • FreeBSD 13.5 : mars 2025
    • FreeBSD 14.3 : sortie prévue le 10 juin 2025
  • Chaque release comprenait l’incitation aux fusions de code, l’acceptation ou le refus des demandes de merge, la coordination avec d’autres équipes, la construction et les tests des images, la rédaction des annonces et la correction des problèmes dans les builds de release
    • En général, 3 Beta, 1 Release Candidate et la Release finale sont construits
    • L’essentiel du travail se concentre le mois précédant la release, c’est-à-dire le deuxième mois de chaque trimestre, le “Beta Month”
    • FreeBSD 13.5 a demandé 33,5 heures, FreeBSD 14.2 en a demandé 79
    • Plus une branche stable avance dans son cycle, moins il y a d’éléments cassés, ce qui tend à réduire la charge de travail liée aux releases
    • FreeBSD 14.1 n’a pas été suivie de cette façon, mais on estime que le temps d’ingénierie de release s’est approché des 100 heures, et FreeBSD 15.0 pourrait en demander bien davantage
  • Côté ingénierie de release générale, un travail de parallélisation des builds de release a également été mené
    • Avec l’augmentation du nombre d’AMI EC2, le temps passé à installer FreeBSD dans les images VM pesait plus lourd que le build lui-même
    • Le code de release a été parallélisé, mais des échecs de build sporadiques sont apparus, et comme un build de release complet durait environ 24 heures, il était difficile d’isoler la cause
    • La cause finale était une ligne manquante dans un Makefile pour créer un répertoire avant d’y installer des fichiers
    • Après correction, le temps de build de release est passé d’environ 22 heures à environ 13 heures, ce qui a aussi permis d’étendre des variantes d’AMI EC2 jusque-là repoussées à cause de la durée des builds
  • Les problèmes de reproductibilité des builds ont commencé à être vérifiés régulièrement avec EC2
    • Lors des tests d’images snapshot hebdomadaires, une instance EC2 est lancée pour construire sa propre AMI
    • L’image disque produite est comparée à l’image source avec diffoscope
    • Ces tests réguliers ont permis de découvrir plusieurs problèmes, dont certains ont été corrigés directement et d’autres transmis à d’autres développeurs

Gestion de l’alimentation sur Graviton et hot-plug dans FreeBSD/EC2

  • Les principales fonctionnalités demandées en priorité par Amazon pour FreeBSD/EC2 étaient un pilote d’alimentation pour les instances AWS Graviton et le hot-plug de périphériques
  • Le pilote d’alimentation Graviton gère le chemin par lequel l’API EC2 notifie au système d’exploitation un arrêt
    • Sans cette fonctionnalité, FreeBSD ignore le signal d’arrêt, puis EC2 coupe l’alimentation virtuelle après quelques minutes sur expiration du délai
    • Le “bouton d’alimentation” sur les systèmes Graviton est une broche GPIO, et les détails figurent dans l’objet ACPI _AEI
    • Du code a été ajouté pour retrouver ces informations dans ACPI et transmettre la configuration au pilote du contrôleur GPIO PL061
    • Lorsque la broche GPIO est assertée, le contrôleur génère une interruption, ce qui déclenche un événement ACPI “power button” menant à l’arrêt du système
  • Les tables ACPI fournies par EC2 indiquent que cette broche GPIO doit être configurée en “Pull Up”, mais le contrôleur PL061 ne dispose pas de résistances pull-up/pull-down
    • Linux ignore silencieusement l’échec de configuration du GPIO, ce qui masque le problème
    • FreeBSD, lui, désactivait le périphérique après l’échec de configuration
    • Le bug EC2 devrait être corrigé à terme sur les systèmes Graviton, mais pour l’instant l’AMI FreeBSD/EC2 intègre le quirk ACPI_Q_AEI_NOPULL pour ignorer le drapeau GPIO PullUp de l’objet _AEI
  • Le hot-plug, et surtout le hot-unplug, a demandé davantage de travail en raison de problèmes différents selon plusieurs types d’instances EC2
    • Certains systèmes Graviton fuyaient des réservations d’IRQ virtuelles pendant l’attachement PCI et, après 67 cycles d’attachement/détachement de volumes EBS, les IRQ étaient épuisées, provoquant un kernel panic FreeBSD
      • La cause était le code historique de routage des interruptions PCI, et un réglage du chargeur de démarrage a été ajouté pour désactiver ce code sur EC2
    • Certains systèmes Graviton utilisaient l’état d’alimentation du périphérique PCI comme signal pour déterminer si l’OS avait fini d’utiliser le périphérique et était prêt à l’éjecter
      • Cela est considéré comme un bug EC2, et pour l’instant le quirk ACPI_Q_CLEAR_PME_ON_DETACH modifie certains bits du registre de gestion d’alimentation PCI avant l’éjection
    • Sur les instances EC2 de dernière génération, en x86 comme en Graviton, le pilote FreeBSD nvme paniquait après un unplug PCIe
      • Le problème a été transmis au mainteneur du pilote nvme
    • Sur certaines instances EC2 x86 et Graviton, des périphériques “fantômes” restaient présents sur le bus PCI après une éjection, empêchant l’attachement de nouveaux périphériques
      • Le firmware Nitro gérait de façon asynchrone l’administration du bus PCI et celle des périphériques PCI, créant une fenêtre de quelques ms où le périphérique était débranché mais le bus PCI continuait à être signalé comme présent
      • Linux rescannant périodiquement le bus, il perd généralement cette course, tandis que FreeBSD rescannait immédiatement après le detach et voyait donc souvent ces périphériques fantômes
      • Pour l’instant, le quirk ACPI_Q_DELAY_BEFORE_EJECT_RESCAN ajoute un délai de 10 ms avant le rescan du bus PCI après le signal d’éjection
  • PCIe impose, pour une demande d’éjection de périphérique, un délai de 5 secondes après pression du bouton “attention”, et une seconde pression annule la demande
    • Sur EC2, personne n’appuie sur un bouton physique et il n’existe pas de mécanisme pour “appuyer” à nouveau sur un bouton virtuel, ce délai est donc inutile
    • Un paramètre tunable du chargeur de démarrage a été ajouté pour mettre ce délai à 0 sur EC2
  • Un script de test de hot-plug permet de lancer une instance EC2 puis de brancher/débrancher de façon répétée des volumes EBS via l’API EC2, afin de vérifier que FreeBSD supporte 300 cycles consécutifs d’attachement/détachement
    • Si un accès anticipé à de futurs types d’instances EC2 devient possible, il pourra servir à vérifier le bon fonctionnement du hot-plug

Suivi des régressions de performances au démarrage et extension des AMI

  • En dehors des deux priorités absolues d’Amazon, environ la moitié du temps consacré à EC2 a été absorbée par d’autres problèmes FreeBSD/EC2
  • Fin 2023 et début 2024, les instances FreeBSD/EC2 démarraient parfois plus lentement que prévu, au point qu’il a fallu augmenter le temps d’attente avant d’essayer une connexion SSH dans les tests de snapshots hebdomadaires
  • Pour traiter ces problèmes de performance, les temps de démarrage des builds hebdomadaires d’AMI EC2 depuis 2018 ont été benchmarkés
    • Plus de 10 000 instances EC2 ont été lancées dans ce cadre
    • Des graphiques de performance de boot FreeBSD ont commencé à être générés
    • La collecte des nouvelles données et l’actualisation des graphiques font désormais partie du processus de test des snapshots hebdomadaires
  • Plusieurs causes de lenteur au démarrage ont été identifiées et corrigées
    • À partir de la première semaine de 2024, le démarrage de FreeBSD est devenu environ 3 fois plus lent, et la cause a été retracée jusqu’à un commit augmentant la taille du disque racine de 5 Go à 6 Go
      • Après vérification côté Amazon, passer la taille du disque racine à 8 Go a permis de retrouver le niveau de performance antérieur
    • Sur la famille Graviton 2, un problème d’initialisation d’entropie du noyau allongeait le démarrage
      • Le noyau FreeBSD suspend le boot s’il manque d’entropie pour générer des nombres aléatoires sécurisés, jusqu’à en collecter davantage
      • Du code existait pour obtenir une seed sécurisée du firmware Nitro via le chargeur EFI, mais il ne s’exécutait pas sur EC2, et sur Graviton 2 une requête de 2048 octets était très lente
      • La requête présente dans le code Lua du menu de boot a été déplacée vers l’emplacement adéquat du Lua du chargeur afin qu’elle s’exécute que le menu soit activé ou non
      • En récupérant 64 octets d’entropie EFI puis en les étendant avec PBKDF2 pour satisfaire l’entrée API de 2048 octets, le temps de boot FreeBSD arm64/base/UFS est passé d’environ 25 secondes à environ 8 secondes
    • Les images ZFS démarraient plus lentement que celles en UFS, et l’ampleur de la latence dépendait non pas de la taille du disque mais de la quantité de données qu’il contenait
      • makefs plaçait tout dans un unique groupe de transactions, et au moment de l’attachement ZFS parcourait puis validait le groupe de transactions le plus récent, lisant et traitant ainsi toutes les métadonnées de fichiers du disque
      • Mark Johnston a résolu le problème en faisant écrire au système de fichiers un groupe de transactions plus élevé, de sorte que ce groupe unique ne soit plus considéré comme “récent”
      • Le temps de boot des images ZFS est passé d’environ 22 secondes à environ 11 secondes
    • En décembre 2024, un problème de boot a été détecté rapidement après l’ajout du support IPv6 au port net/aws-ec2-imdsv2-get
      • Ce port fournit une interface en ligne de commande au service EC2 Instance MetaData Service
      • Il essayait d’abord IPv6, alors que la configuration IMDS par défaut de l’instance ne supportait qu’IPv4, tout en conservant le délai TCP par défaut de 75 secondes
      • Après correction, il tente d’abord IPv4 et le délai a été ramené à 100 ms
  • Les variantes d’AMI FreeBSD ont également été étendues
    • Auparavant, seules base et cloud-init existaient
    • L’AMI small supprime les symboles de debug, LLDB, les bibliothèques 32 bits, les tests FreeBSD, l’agent Amazon SSM et l’AWS CLI, réduisant l’occupation disque d’environ 5 Go à environ 1 Go
    • L’AMI builder fournit des AMI Builder AMIs FreeBSD afin de permettre aux utilisateurs de créer facilement des AMI FreeBSD personnalisées
  • Avec l’augmentation des builds snapshot hebdomadaires due aux combinaisons de 4 variantes d’AMI, 2 systèmes de fichiers, 2 architectures et 3 versions de FreeBSD, un nettoyage des anciennes images et des snapshots EBS associés a été effectué
    • Le compte AWS utilisé pour l’ingénierie de release de FreeBSD est financé par Amazon, mais quelqu’un en supporte malgré tout le coût
    • Un script shell a permis de supprimer 336 To de snapshots EBS

Travail restant et contraintes après la fin du financement

  • En plus des grands projets, de nombreuses petites tâches se sont poursuivies
    • Correction de casses de build découvertes dans les builds snapshot hebdomadaires
    • Revue de patchs du pilote ENA
    • Aide à Dave Cottlehuber pour ajouter la possibilité de construire des conteneurs OCI et de les téléverser dans un dépôt
    • Amélioration de l’outil bsdec2-image-upload pour gérer plus proprement les erreurs internes AWS
    • Signalement d’un problème de sécurité AWS découvert par hasard
  • Après la fin du financement, les rôles de responsable de l’ingénierie de release de FreeBSD et de mainteneur de la plateforme FreeBSD/EC2 se poursuivent
    • FreeBSD 15.0 est attendu en décembre
    • En 2026 doivent suivre 14.4, 15.1, 14.5 et 15.2
  • Avec moins de temps disponible, il devient plus difficile de corriger directement les problèmes juste avant une release
    • Les fonctionnalités arrivant tard auront plus de chances d’être retirées que corrigées à temps pour la release
    • Si FreeBSD 14.2 a pu inclure des conteneurs OCI, c’est parce que le temps financé a permis de vérifier que toutes les pièces nécessaires étaient bien en place
  • Côté EC2, les tests de régression des performances de boot existent désormais et devraient permettre de détecter ce type de problèmes, mais la liste des fonctionnalités à développer pourrait stagner sans temps supplémentaire
    • Extension automatique du système de fichiers lors de l’agrandissement des volumes EBS
    • Amélioration de la configuration automatique de multiples interfaces réseau et du hot-plug d’interfaces réseau
    • AMI roulantes “pre-patched”
    • Un site web pour générer des fichiers EC2 user-data afin d’installer des paquets et lancer des démons
    • Reprise du travail sur FreeBSD/Firecracker et évolution vers une plateforme prise en charge
  • Le financement d’Amazon a représenté une opportunité bien plus importante que ce que reçoivent la plupart des développeurs open source, et sa fin laisse à la fois un regret et de la gratitude pour le travail accompli pendant cette période

À lire aussi

1 commentaires

 
GN⁺ 2025-06-07
Avis sur Hacker News

  • Super. À partir d’aujourd’hui, nous avons ajouté FreeBSD à la page de téléchargement de ziglang.org, ce qui permet aux utilisateurs de FreeBSD de récupérer des builds de la branche master générés automatiquement par la CI
    C’est désormais pris en charge comme cible de cross-compilation de premier ordre, y compris jusqu’à l’édition de liens avec libc, donc des choses comme zig cc -o hello hello.c -target riscv64-freebsd sont possibles
    Si vous avez des dépendances C/C++, vous pouvez les importer dans le système de build de Zig et les compiler, donc je pense qu’il sera facile de cross-compiler pour FreeBSD même des projets assez complexes. J’espère que cela aidera davantage de projets à ajouter la prise en charge de FreeBSD et des tests CI

    • La cross-compilation de Zig est excellente, et c’est une bonne nouvelle que FreeBSD fasse partie des cibles prises en charge
    • Zig a une licence compatible BSD, et FreeBSD inclut déjà LLVM dans son système de base ; je me demande donc si Zig finira un jour par y entrer lui aussi
      Ce serait bien d’avoir une alternative officiellement reconnue au C

  • Il y a ici quelques passages assez amusants
    « Dès la première semaine de 2024, le processus de démarrage de FreeBSD est soudain devenu environ 3 fois plus lent. En faisant une recherche dichotomique dans les commits, la cause s’est révélée être un commit qui faisait passer la taille du disque racine de 5 Go à 6 Go. Pourquoi ? J’ai demandé à des connaissances chez Amazon, et la réponse se situait quelque part entre “de la magie” et “vous ne voulez vraiment pas savoir” ; l’important, c’est qu’en passant le disque racine à 8 Go, les performances sont revenues à leur niveau précédent »

    • La limite de taille d’objet initiale de S3 était de 5 Go, et c’est aussi ce qui est indiqué dans un billet de 2006 : https://aws.amazon.com/blogs/aws/amazon_s3/
      Je ne sais pas si c’est lié au mur de performance observé
    • Maintenant, j’ai vraiment envie de savoir
    • Je me demande combien de temps il a fallu pour faire une recherche dichotomique sur un tel problème. Fallait-il reconstruire l’image et redémarrer la VM à chaque fois ?

  • Il y a aussi beaucoup de travail côté ordinateurs portables, et j’ai lu que la BSD Foundation y avait investi 750 000 dollars
    Cela inclut l’implémentation d’états de veille comme S0ix, et le projet est visible ici : https://github.com/FreeBSDFoundation/proj-laptop

    • Exact, beaucoup de travail est en cours. J’ai simplement écrit sur ce sur quoi je travaillais moi-même ;-)

  • J’ai énormément de respect pour cperciva
    Je ne sais pas comment il arrive à faire tout ça en plus de Tarsnap

    • À partir d’un certain point, on peut acheter du temps avec de l’argent. C’est le genre de choix entre réparer soi-même un robinet qui fuit ou appeler un plombier, ou refaire soi-même le placo du sous-sol après le passage des électriciens ou faire appel à un professionnel
      Pour être juste, une partie du temps que j’y ai consacré a bien été prise sur Tarsnap, mais beaucoup moins qu’on pourrait le penser

  • Je m’attendais à ce qu’Amazon dépense et contribue davantage, mais on dirait qu’ils veulent essentiellement payer uniquement pour une prise en charge minimale de FreeBSD
    Amazon n’apparaît même pas dans la liste des sponsors de FreeBSD [1], Google n’a donné que 9 000 dollars l’an dernier, et Apple n’y figure pas non plus. Microsoft, au moins, est dans la liste, ce qui mérite d’être reconnu. Meta/Facebook est aussi absent
    Ces entreprises utilisent FreeBSD et OpenBSD et continuent d’en bénéficier, donc je m’attendais à ce qu’elles fassent au minimum un don chaque année
    [1] https://freebsdfoundation.org/our-donors/donors/?donationYea...

    • Bien sûr, ce serait bien qu’Amazon contribue davantage, mais le fait de ne pas figurer dans la liste des donateurs de la FreeBSD Foundation ne signifie pas qu’ils ne soutiennent pas FreeBSD
      Par exemple, l’argent qui m’a été versé n’est pas passé par la Foundation. À vue de nez, dans le développement de FreeBSD financé par des entreprises, le développement soutenu par la Foundation représente probablement autour de 10 %
      Ces 10 % sont particulièrement importants, car ils peuvent se concentrer non pas sur “ce dont l’entreprise X a besoin”, mais sur “ce dont FreeBSD a besoin”, mais cela reste une petite part
    • Cela ne donne pas une vue d’ensemble
      Premièrement, cela ne montre qu’un instantané des dons à la Foundation pour une année donnée, donc l’historique des dons n’apparaît évidemment pas
      Deuxièmement, cela ne montre pas non plus les contributions au développement. On peut généralement en trouver un résumé dans les notes de version de chaque publication [1]
      [1] https://www.freebsd.org/releases/
    • Je me demande pourquoi Microsoft sponsorise. Les extensions Hyper-V ne sont pas aussi complètes que sous Linux, et il n’existe pas non plus de port .NET pris en charge par Microsoft
      Aucun service Microsoft, cloud ou non, qui tourne sur *BSD ne me vient à l’esprit
    • Parmi les FAANG, Amazon est l’un de ceux qui en font le moins pour le logiciel libre et open source

  • Je voulais utiliser FreeBSD comme passerelle domestique/pare-feu/serveur DNS/DHCP, mais il semble qu’il n’y ait pas de pilote pour ma carte réseau 10GbE, donc j’ai finalement choisi Nix
    Il y a longtemps, j’utilisais FreeBSD comme poste de travail, et c’était une expérience assez marquante. Ça fait plaisir de voir que le projet continue de tourner régulièrement

    • Mon entreprise et mon infrastructure personnelle utilisent toutes FreeBSD. Sous FreeBSD, les cartes réseau Intel sont fiables à 100 %, donc je n’utilise que ça
      Realtek semble partir en vrille sous charge, malgré les efforts soutenus des ingénieurs FreeBSD qui maintiennent le pilote. Je ne me plains pas, je respecte leur travail
      C’est un petit prix à payer, et cela m’évite d’avoir à installer un système d’exploitation moins stable

  • Je me souviens qu’à l’époque de FreeBSD 7 ou 8, les pilotes FreeBSD étaient meilleurs que ceux de Linux pour des choses comme les cartes Wi‑Fi Atheros
    J’ai préféré FreeBSD jusqu’aux environs de 2021, mais cela a changé quand les machines mélangeant différents cœurs CPU sont devenues courantes. Au début, j’ai acheté un RockPro64 avec 2 gros cœurs et 4 petits cœurs, puis ensuite un Intel Alder Lake
    Si j’ai bien compris, le scheduler de FreeBSD ne gère pas encore correctement ce genre de configuration, et semble ramener le système au plus petit dénominateur commun, celui des cœurs lents

  • Par curiosité, qui sont les principaux utilisateurs de FreeBSD/EC2 ?

    • Je n’en ai aucune idée. Sérieusement, les utilisateurs qui me contactent représentent probablement quelque chose comme 0,1 % de toute la base d’utilisateurs FreeBSD/EC2
      J’aimerais vraiment savoir qui utilise FreeBSD sur EC2
    • Netflix ne l’utilise-t-il que sur ses équipements edge ?

  • C’est un article qui montre très bien comment fonctionne le sponsoring open source par les entreprises

  • Quelqu’un qui utilise FreeBSD pourrait-il expliquer quelle niche FreeBSD occupe dans l’espace Unix ? Pourquoi FreeBSD plutôt qu’OpenBSD ou NetBSD, qui sont plus simples et plus cohérents ?
    Si la réponse est la prise en charge de ZFS, des pilotes Nvidia, d’ELF, etc., alors pourquoi pas Linux ? Je connais bien les problèmes de GNU, mais y a-t-il aussi des problèmes avec quelque chose comme Musl Void ?
    Je suis sincèrement curieux. FreeBSD existe pour moi comme une sorte de zone d’ombre : je n’ai jamais réussi à cerner précisément son identité centrale, celle qui le fait continuer à avancer, mais je sais qu’elle est quelque part

    • J’ai travaillé dans une société de services financiers qui utilisait FreeBSD à la fois sur EC2 et sur du bare metal dans des datacenters autogérés. Les deux fonctionnalités que nous utilisions tout le temps étaient ZFS et les jails
      Chaque service tournait dans son propre jail pour l’isolation, et un serveur même pas particulièrement puissant pouvait faire tourner tous les services, ce qui était extrêmement rentable
      À un moment donné, nous avons migré vers le cloud pour une configuration hybride, et le fait de mélanger Linux (k8s) et FreeBSD a fait exploser les coûts. Dans un datacenter, il faut acheter et remplacer les disques soi-même, gérer les situations comme les incendies, et on est limité à un seul pays ; mais AWS offre du multi-région et beaucoup de fonctionnalités intéressantes, avec le prix qui va avec
      Nous n’avons pas exploité ZFS de façon très poussée, mais quand une table a été supprimée par erreur dans la base de données de production, nous avons pu revenir immédiatement au snapshot ZFS juste précédent, ce qui nous a sauvé la mise une fois. Il y a eu une petite perte de données, mais pour cette application, le temps de disponibilité était plus important, donc ce n’était pas un gros problème. De mémoire, nous utilisions aussi ZFS pour les sauvegardes
      J’ai utilisé dtrace plusieurs fois pour diagnostiquer des problèmes en production, et quand Linux a été introduit dans notre parc de serveurs FreeBSD, chaque équipe a naturellement choisi une distribution différente, ce qui est devenu une sorte de zoo. Quand on utilise FreeBSD sur les serveurs, il n’y a qu’une seule variante
      J’utilise encore les deux et je les apprécie, mais j’aime vraiment le fait que FreeBSD soit un noyau et un système d’exploitation intégrés
    • D’après mon expérience, FreeBSD offre un bon équilibre entre les priorités respectives d’OpenBSD et de NetBSD
      Historiquement, FreeBSD a privilégié les CPU Intel, NetBSD était davantage axé sur la portabilité, et même si FreeBSD avait aussi une sécurité solide, OpenBSD s’est encore plus concentré sur cet aspect
      La prise en charge de ZFS par FreeBSD change vraiment la donne. Pour Nvidia, il me semble qu’ils ne fournissent des pilotes FreeBSD natifs que depuis récemment, et pendant longtemps il fallait utiliser la compatibilité avec le noyau Linux de FreeBSD
      Autrement dit, FreeBSD mélange bien les fonctionnalités proposées par les autres BSD, tout en étant extrêmement stable sur les plateformes matérielles que j’utilise principalement
    • FreeBSD est orienté débit d’une manière qu’OpenBSD ne l’est clairement pas, et je ne pense pas que NetBSD le soit non plus
      NetBSD joue sur la portabilité, et j’ai l’impression qu’ils ne passent pas énormément de temps à maintenir un débit réseau élevé
      Tous les BSD changent généralement beaucoup moins, ce qui a ses avantages et ses inconvénients, mais j’estime que ce sont de meilleures plateformes comme cibles d’intégration
    • FreeBSD a une meilleure prise en charge de ZFS que Linux, car il n’a pas de problème de licence
    • FreeBSD a une base d’utilisateurs bien plus importante qu’OpenBSD ou NetBSD. Il n’y a pas photo
      La liste des logiciels disponibles est aussi beaucoup plus vaste, et il peut servir de système d’exploitation moderne pour un usage quotidien sur desktop. C’est difficile à dire pour les deux autres
      Quant à pourquoi pas Linux : je ne veux pas de Linux. Il est trop écrasé par les intérêts des entreprises