URL: https://linuxfr.org/news/entretien-avec-francois-tigeot-developpeur-dragonfly-bsd Title: Entretien avec François Tigeot, développeur DragonFly BSD Authors: antistress François Tigeot, Benoît Sibaud, Xavier Teyssier et palm123 Date: 2013年10月25日T00:33:33+02:00 License: CC By-SA Tags: entretien, ftigeot, dragonflybsd, pkgng, freebsd, coulisses et scientific_linux Score: 55 Nous avons la chance d'avoir quelques développeurs qui fréquentent LinuxFR.org (_what else?_), dont François Tigeot (lecteur silencieux, dorénavant inscrit sous le pseudo [ftigeot](https://linuxfr.org/users/ftigeot)) qui contribue au système d'exploitation libre [[DragonFly BSD]], un cousin de FreeBSD au sujet duquel nous avions interrogé tantôt Jean-Sébastien Pédron (quant au [portage du Kernel-based mode-setting – KMS – pour les GPU Radeon](//linuxfr.org/news/entretien-avec-jean-sebastien-pedron-a-pied-d-oeuvre-pour-porter-kms-pour-radeon-dans-freebsd)) puis Baptiste Daroussin (au sujet de [« pkgng », le nouveau système de packages binaires](//linuxfr.org/news/baptiste-daroussin-revient-sur-pkgng-le-nouveau-systeme-de-packages-binaires-de-freebsd) qui a été justement repris par DragonFly (les fourbes !) : hasard ou coïncidence ? Autrement dit : y aurait-il une mafia française du logiciel libre ? Pour répondre à cette lancinante question, rappelons : - ce que Jean-Sébastien Pédron avait fini par avouer, sous la torture, lorsque je lui avais posé la question suivante : « _Échanges‐tu avec les développeurs des autres *BSD sur ta partie ?_ » : « _Je suis également en contact avec François Tigeot, de DragonFly, qui s'est occupé du pilote Intel chez eux. Je pense qu'on va travailler de plus en plus ensemble, parce qu'on a sans doute moyen de se répartir le boulot._ ». - ce que Baptiste Daroussin avait fini par avouer, avec les mêmes moyens, lorsque je lui avais posé la même question : « _Les échanges sont assez nombreux, essentiellement avec DragonFly. En effet sous l'impulsion de John Marino, aidé maintenant par François Tigeot, pkgng et les ports FreeBSD ont été porté sous DragonFly avec des résultats plus que convaincants. La dernière version de DragonFly dispose du support au choix entre pkgsrc ou pkgng + ports, je suis convaincu que la prochaine version de DragonFly sortira avec uniquement pkgng_ ». Il semble qu'il y ait définitivement une piste à creuser... Du coup j'ai bien envie de passer François à la question relativement à la pile graphique de DragonFly ou au port de pkgng, mais on m'indique dans l'oreillette que ces sujets ne sont en réalité qu'une partie de l'activité déployée par François dans DragonFly. Nous allons donc de ce pas interroger ce personnage – qui semble central dans la communauté DragonFly – afin de tenter d'y voir plus clair. Quoi qu'il en soit, nous remercions chaleureusement François Tigeot d'avoir accepté de répondre à quelques questions pour LinuxFR.org et aussi pour son implication dans DragonFly ! À noter que les hyperliens ont été ajoutés après coup par les contributeurs à cette dépêche pour en faciliter la lecture. ---- [Site officiel de DragonFly](http://www.dragonflybsd.org/) [DragonFly sur Wikipédia](https://fr.wikipedia.org/wiki/DragonFly_BSD) [Dépêche sur la sortie de la dernière version (3.4) de DragonFly ](http://linuxfr.org/news/sortie-de-la-version-dragonfly-3-4) ---- **_Pourrais-tu te présenter en quelques mots ?_** J'ai 36 ans, un DUT informatique systèmes et réseaux, suis gérant de SARL. Je travaille principalement comme consultant (sysadmin, maitrise d'ouvrage). Ma société vend du matériel serveur, ce qui me permet parfois de faire des benchmarks intéressants. **_Pourrais-tu te présenter en plus de mots, finalement ? ;)_** Le fait de travailler dans une petite boite permet de voir plein de problématiques intéressantes. Voici en vrac mes tâches les plus courantes : - vente de solutions complètes (matériel+conseil+services). J'ai mis en place des infrastructures de stockage ou des clusters de calcul dans des labos de recherche par exemple ; - sysadmin : infogérance de serveurs, travail en régie sur des missions plus ou moins longues pour différentes sociétés ; - maîtrise d'ouvrage : conception et mise en place d'une infrastructure IT complète depuis zéro, en commençant par l'accès Internet si besoin ; - pompier : diagnostic et mise en place de mesures correctives pour résoudre des problèmes de performance en urgence. Le matériel serveur installé par ma société n'est jamais mis en production du jour au lendemain. Les machines tournent en atelier pendant une période de rodage qui permet de détecter les problèmes immédiats (disques durs KO dès la livraison, etc.) et me laisse parfois le temps de faire tourner des benchmarks. J'ai ainsi pu mesurer les performances de plusieurs systèmes d'exploitation avec des charges de travail orientées stockage comme ([Blogbench](http://www.pureftpd.org/project/blogbench)) ou bases de données ([Postgres](http://fr.wikipedia.org/wiki/PostgreSQL)). Ceci a permis d'améliorer de façon significative les performances et la tenue en charge de DragonFly dans plusieurs domaines. **_Comment définirais‐tu ton rapport au logiciel libre, et comment es‐tu entré en contact avec lui ?_** Je dirais que, pour moi, les logiciels libres font maintenant partie du paysage et sont tellement pratiques que je n'envisage pas d'utiliser autre chose. Dans les années 80-90, la plupart des ordinateurs qu'un particulier pouvait acheter étaient livrés avec des outils de développement, même si ce n'était qu'un [[BASIC]] en ROM. Avec la domination de Windows depuis 1995, il était devenu impossible de programmer à partir d'un PC de base, à moins de payer des sommes extrêmement importantes dans des logiciels supplémentaires. C'est un cherchant un compilateur C abordable que j'ai entendu parler de [GCC](http://fr.wikipedia.org/wiki/GNU_Compiler_Collection) et que j'ai découvert petit à petit Unix et le monde des logiciels libres. **_Comment t'es-tu retrouvé à utiliser DragonFly ?_** J'utilisais FreeBSD comme routeur+parefeu ; lors du passage des versions 5.x à la 6.x (en 2006 je crois), le système s'est mis à planter de façon récurrente tous les 2-3 jours. C'était un bug connu et qu'il n'était manifestement pas possible de corriger rapidement. Je me suis alors souvenu de l'existence de DragonFly, qui avait été forké de FreeBSD quelques années auparavant, l'ai installé sur mon routeur, et n'ai plus eu de problèmes. Sa stabilité digne de FreeBSD 4.x (des uptimes de plus d'un an n'avaient rien d'exceptionnel) a fait en sorte que je l'ai progressivement installé sur la plupart des machines de ma société par la suite. **_Comment es-tu devenu développeur ?_** J'étais très enthousiaste à la suite de la création du système de fichier [[HAMMER]], et j'ai donc naturellement voulu l'utiliser dans un contexte entreprise. J'ai très vite déchanté quand j'ai voulu obtenir une information aussi simple que la liste des cartes RAID supportées, qui n'existait tout simplement pas. Je me suis donc retrouvé à établir cette liste moi-même, en testant du matériel gracieusement prêté par un grossiste de la région parisienne. C'était en avril 2011. Petit à petit, j'ai ensuite contribué à faire fonctionner des applications, corriger des bugs, etc... jusqu'à me retrouver développeur DragonFly sans vraiment m'en rendre compte. **_Apparemment tu es un vrai touche-à-tout, intervenant au niveau applicatif, benchmarking, développement noyau... Quelles sont, selon toi, tes contributions les plus utiles et importantes ?_** Dans l'ordre d'importance, je dirais : 1. Portage de [drm2](http://fr.wikipedia.org/wiki/Direct_rendering_infrastructure)/[gem](http://fr.wikipedia.org/wiki/Graphics_Execution_Manager)/[kms](http://fr.wikipedia.org/wiki/Kernel-based_mode-setting) et des pilotes [i915](http://fr.wikipedia.org/wiki/Pile_graphique_Linux#Intel_GMA_et_HD_Graphics) puis [radeon](http://fr.wikipedia.org/wiki/Radeon_%28logiciel%29) (voir respectivement [ici](http://www.dragonflybsd.org/docs/developer/GEMdrmKMS/), [ici](http://lists.dragonflybsd.org/pipermail/users/2013-July/053643.html) et [là](http://lists.dragonflybsd.org/pipermail/commits/2013-October/198282.html)). En fait ce n'est que récemment, à l'été 2012, que j'ai commencé sérieusement à m'intéresser à la pile graphique drm utilisée par les nouveaux pilotes [[X.org]] et à porter les fonctions et sous-systèmes nécessaires depuis FreeBSD. C'était devenu une urgence car sans ça il est maintenant impossible d'afficher des graphiques sur une grande partie des machines récentes. 2. [Dports](https://www.dragonflybsd.org/docs/howtos/HowToDPorts/) (adaptation des ports FreeBSD et des paquets binaires pkgng à DragonFly). J'ai aidé John Marino à rendre le système utilisable et je m'occupe encore de créer de nouveaux paquets binaires quand j'ai le temps. C'est essentiel pour rendre le système d'exploitation plus pratique à utiliser. 3. [Portage de LibreOffice](http://leaf.dragonflybsd.org/mailarchive/users/2011-05/msg00089.html). Devoir mettre les mains profondément dans le cambouis m'a permis aussi d'identifier des problèmes non-spécifiques à DragonFly et qui m'ont permis d'améliorer le logiciel pour tout le monde. J'ai ainsi contribué à éliminer du code OS/2 et HP-UX que personne n'utilisait, supprimé des fonctions de gestion de quotas disque qui n'avaient rien à faire dans une suite bureautique, etc. C'était une tâche importante car, sans applications, un système d'exploitation n'a qu'un intérêt limité. 4. [Portage depuis FreeBSD](http://leaf.dragonflybsd.org/mailarchive/commits/2012-06/msg00156.html) du pilote [ixgbe(4)](http://leaf.dragonflybsd.org/cgi/web-man?command=ixgbe§ion=ANY) pour cartes Ethernet Intel 10 Gb/s. Cela n'a encore qu'un intérêt très limité pour la plupart des gens et c'est pour cela que je le mets en dernier, mais c'est cependant quelque chose d'essentiel pour créer des serveurs de stockage haute performance, domaine dans lequel DragonFly a la possibilité d'exceller. **_Et quelles seraient pour toi tes contributions les plus difficiles, et pourquoi ?_** La plus difficile est sans conteste la pile graphique drm moderne avec ses gestionnaires mémoire associés. Je n'aurais jamais pu faire marcher cela tout seul d'ailleurs, Johannes Hofmann et Matt Dillon ont permis que le pilote i915/kms fonctionne en implémentant des fonctionnalités essentielles dans le noyau alors que j'avais laissé le projet de côté pour me consacrer à Dports. Le gestionnaire de mémoire GEM et le pilote i915 ont besoin de gérer le matériel à un niveau auquel on n'était pas habitué jusqu'à présent. Les GPU Intel utilisent des ressources mémoire partagées avec le processeur, mais les caches de ces deux composants ne sont pas [cohérents](http://fr.wikipedia.org/wiki/Coh%C3%A9rence_%28donn%C3%A9es%29) entre eux. Il a été nécessaire de modifier le noyau afin que le contenu de certaines pages mémoire ne soient par exemple _jamais_ mises en cache par le processeur ou que les caches soient complètement vidés pour certaines zones mémoire lorsque le pilote le demande. Maintenant que le plus gros est fait, je m'efforce de garder le code plus ou moins synchronisé avec FreeBSD et de réduire petit à petit les différences historiques du sous-système drm pour le rapprocher de l'implémentation Linux moderne. **_Quelle a été exactement ta contribution sur pkgng dont Baptiste Daroussin nous a rebattu les oreilles récemment ? ;)_** J'avais contribué à fournir des machines puissantes à John Marino pour la mise au point de Dports, grâce à l'aide de Dell et du CNRS - plus précisèment le Centre de Mathématique Laurent Schwartz (Ecole Polytechnique/Institut National des Sciences Mathématiques et de leurs Interactions) et l'Institut d'Astrophysique Spatiale (Paris-Sud/Institut National des Sciences de l'Univers) que je remercie chaleureusement au passage. J'ai aussi contribué à faire fonctionner plusieurs logiciels importants, et surtout passé beaucoup de temps à faire tourner Poudriere, et remonter tous les bugs que j'ai trouvés. Poudriere, l'outil de création de paquets en parallèle, stresse tellement le système d'exploitation et le matériel qu'on avait presque des _kernel panics_ toutes les cinq minutes au début. Quand c'est devenu assez stable, j'ai cherché d'où venaient certains problèmes de performance pour les éliminer, ce qui a été fait par des développeurs noyau ayant de la bouteille. Matt Dillon a corrigé à lui seul la majorité des bugs et des problèmes de performance les plus critiques si je me souviens bien. C'est moi qui ait fait les benchmarks et les graphiques qui sont repris dans [la dépêche sur DragonFly 3.4](https://linuxfr.org/news/sortie-de-la-version-dragonfly-3-4). Ils proviennent de deux posts sur la liste de discussion kernel@ : [celui-ci](http://lists.dragonflybsd.org/pipermail/kernel/2013-April/047011.html) et [celui-là](http://lists.dragonflybsd.org/pipermail/kernel/2013-April/062806.html). Maintenant, je continue d'utiliser Poudriere pour produire les paquets binaires officiels avec John. **_Tes autres contributions, en vrac ?_** Au niveau applicatif : - Portage de Java : j'ai fait fonctionner le jdk 1.5 en utilisant une technique de bootstrapping mise au point par OpenBSD, puis je me suis occupé du jdk 1.6. J'ai également participé à faire fonctionner le openjdk 1.7 (le travail a principalement été fait par Chris Turner pour celui-là). Au niveau benchmarking : - Juillet 2011 : benchmarks Blogbench/RAID. Cela a fait apparaître un problème : avec un système disque trop chargé, Hammer avait tendance à trop privilégier les requêtes en lecture, au détriment de celles en écriture. Problème corrigé au bout de quelques jours (parcourir [la liste de diffusion](http://lists.dragonflybsd.org/pipermail/kernel/2011-July/062229.html) pour plus de précisions). - Septembre 2011 : benchmarks Blogbench/RAID. Confirme qu'il n'y a plus de problème de montée en charge. Le sous-système disque peut traiter de plus en plus de transactions au fur et à mesure qu'on ajoute des disques. - Novembre 2011 : benchmarks Postgres (pgbench) : DragonFly 2.10 vs 2.13 vs FreeBSD 9.1-RC1. Les résultats ont montré des problèmes de stabilité sous fortes charges, corrigés en quelques jours. - Aout 2012 : benchmarks Postgres (pgbench) : DragonFly 3.0 vs 3.1 vs FreeBSD 9.1-RC1 vs Scientific Linux 6.2. Pas de problème majeur avec DragonFly 3.1, mais Linux est loin devant d'un point de vue performances. - Octobre 2012 : benchmarks Postgres (pgbench). Collaboration continue ce mois-ci entre Matt Dillon et moi-même pour améliorer les performances de DragonFly et mieux monter à l'échelle en fonction des ressources processeur disponibles. Voir [le résultat](http://lists.dragonflybsd.org/pipermail/users/2012-October/071003.html). - Avril 2013 : Poudriere et Sysbench file/io sur tmpfs : DragonFly 3.2 vs DragonFly 3.4. Mesure des améliorations de performance réalisées dans le cadre de l'intégration de Poudriere. Au niveau du développement noyau : Mon idée est toujours de rendre DragonFly plus utilisable dans un contexte professionnel. Pour cela, j'ai essayé de corriger des manques flagrants au niveau du système d'exploitation : - Août 2011-Avril 2012 : implémentation de quotas VFS suivant une ancienne idée de projet [[GSoC]]. HAMMER est capable de rivaliser avec ZFS sur bien des points, mais personne n'avait tout simplement pensé à y inclure un système de quotas. Les quotas VFS permettent d'ajouter des limites d'utilisation à chaque point de montage, quel que soit le système de fichiers sous-jacent. On peut ainsi limiter les quantités de données pouvant être écrites dans un /tmp monté depuis un ramdisk par exemple. - Mars-avril 2012 : élimination d'une ancienne limite de 64 ko maximum pour les entrées-sorties sur les périphériques de stockage (disques, clés USB, etc.). - Mai 2012 : portage des pilotes ichwd et amdsbwd(4) depuis FreeBSD. Il s'agit de pilotes de watchdog permettant un reboot matériel d'une machine en cas de plantage du système d'exploitation. DragonFly avait des problèmes de stabilité à cette époque suite à l'élimination des derniers verrous qui empêchaient le noyau de fonctionner en parallèle sur tous les processeurs par défaut. **_Collabores-tu avec les développeurs des autres *BSD sur tes parties ?_** Oui, j'ai par exemple discuté de problématiques communes et poussé des patchs pour Robert Nagy d'OpenBSD et Baptiste Daroussin de FreeBSD du temps où j'étais développeur LibreOffice. J'ai bien sûr continué à échanger avec Baptiste sur tout ce qui concerne pkgng et Poudriere. Aujourd'hui, je suis principalement le travail fait par Jean-Sébastien Pédron et l'équipe qui s'occupe des pilotes graphiques FreeBSD. Je m'efforce de synchroniser le code autant que possible et récupère périodiquement leurs contributions. La pile graphique drm2 de DragonFly a été portée depuis FreeBSD et non directement depuis Linux au départ. Dans l'autre sens, FreeBSD récupère aussi certains des changements introduits par DragonFly. Ceci dit, les implémentations drm2 de DragonFly et FreeBSD ne sont pas identiques : j'ai également récupéré des fonctions importantes depuis OpenBSD et nous avons des implémentations locales de certaines APIs Linux qui nous permettent d'être plus proches du code drm Linux. Notre but commun avec Jean-Sébastien est de réduire au maximum les différences historiques entre les piles drm et de se rapprocher le plus possible de l'implémentation Linux afin de faciliter la maintenance du code sur le long terme. **_Qu'est ce qu tu aimerais (voir) changer/améliorer dans DragonFly, quels sont les prochains sujets et même les futurs enjeux pour DragonFly ?_** À mon sens, le projet souffre d'un gros manque de marketing et n'est par conséquent pas assez connu. J'aimerais également qu'il soit plus facilement utilisable en entreprise en pouvant l'intégrer dans un annuaire ldap dès l'installation par exemple. Pour des considérations plus long terme, le chantier le plus important est le développement du système de fichier Hammer 2 qui est prévu pour fonctionner à terme en multi-maître sur un cluster de machines. **_Quels distribution et environnement graphique utilises‐tu ?_** J'utilise principalement DragonFly, les serveurs de ma société et mon poste de travail tournent avec. Je gère aussi des FreeBSD et des distributions Linux diverses chez les clients. Mon environnement graphique préféré est Windowmaker que j'ai utilisé aussi longtemps que possible avec des composants de kde3. Kpdf était pour moi le meilleur lecteur PDF existant sous Unix; maintenant qu'il a été abandonné, je cherche toujours un remplaçant capable de _bien_ imprimer. **_Quel est ton avis sur les évolutions en cours de la pile graphique ?_** Je n'ai pas grand-chose à redire sur le fond. C'est assez logique que le noyau gère le matériel et que X.org se contente d'être une application classique et cesse d'essayer d'être un système d'exploitation à lui tout seul. **_Et sur Systemd ?_** J'ai l'impression que ces dernières années, pas mal de développeurs qui tournent autour des distributions Linux sont devenus fous et rendent leurs produits inutilisables. Mais c'est très bien : qu'ils continuent dans cette voie. Systemd est aujourd'hui l'une des meilleures raisons qui existe pour migrer vers un système d'exploitation *BSD.

AltStyle によって変換されたページ (->オリジナル) /