Entretien avec des développeurs francophones d'OpenBSD - Partie 1

OpenBSD est un système d'exploitation libre sous licence ISC-BSD particulièrement réputé pour sa sécurité et qui est compatible avec de nombreuses architectures matérielles. On l'utilise en général comme routeur ou pare-feu mais il peut parfaitement être utilisé en tant que station de travail bureautique ou comme serveur généraliste.

Pour célébrer la sortie de la version 4.9, et aider à mieux faire connaître le projet, il a été décidé de proposer un entretien à plusieurs développeurs francophones d'OpenBSD.
J'ai donc envoyé une série de questions à huit d'entre eux en m'attendant à un certain pourcentage de refus. À ma grande surprise, tous ont répondu favorablement à cette demande, ce qui a conduit à la division en deux dépêches successives pour éviter un overflow de LinuxFr.org ;-)
Dans la seconde partie de la dépêche vous trouverez donc les réponses de:

• Marc Espie (espie@): responsable de l'infrastructure des ports et de la réécriture des pkgtools.
• Landry Breuil (landry@): mainteneur de Xfce et des logiciels Mozilla.
• Gilles Chehade (gilles@): auteur de smtpd.
• Miod Vallat (miod@): spécialiste des architectures « exotiques ».

Il y a une première section comprenant plusieurs questions générales et ensuite quelques questions plus spécialisées à destination de chacun d'entre eux en fonction de leur domaine de prédilection. Bien entendu, ils étaient libres de faire ce qu'ils voulaient de ces questions. Par exemple miod@ a ajouté à ses réponses des fortunes IRC (que je me suis bien gardé de traduire) et landry@ a choisi de répondre également aux questions spéciales destinées à l'origine à espie@.
Je tiens à tous les remercier une fois de plus pour leur disponibilité et pour leurs réponses.

N'oubliez pas qu'OpenBSD est entièrement développé par des volontaires et que, au moins via OpenSSH, vous bénéficiez sans doute de leur travail. Pous assurer la pérennité du projet surtout n'hésitez pas à commander les CD-ROM d'installation, des tshirts ou des posters. Ce sont, avec les dons de particuliers ou de sociétés, les seules sources de revenus du projet.

Sommaire

• Questions générales pour tous
• Questions spécifiques pour espie@
• Questions spécifiques pour landry@
• Questions spécifiques pour gilles@
• Questions spécifiques pour miod@

Questions générales pour tous

LinuxFr.org : Comment est-ce qu'on fait le choix de contribuer à OpenBSD par rapport aux autres projets libres qui existent ? Est-ce un hasard à la base ou bien est-ce un choix réfléchi ?

espie@ : J'avais Unix à l'école (SunOS) et j'ai eu un gros amiga chez moi, avec envie de jouer avec Unix là-aussi. OpenBSD s'est affirmé comme le seul choix possible (à l'époque): c'était le seul OS avec des instructions précises sur quoi installer. Plus tard, ce choix s'est amplement confirmé. Il y a un souci du travail bien fait qui n'existe tout simplement pas chez les autres. Entre autres, j'ai goûté à l'admin Linux et à l'admin OpenBSD. Je préfère amplement la 2e. Même s'il n'y a pas trois tonnes de gadgets kéké, au moins ça ne pète pas tous les six mois… passé un certain âge, quand on a fini d'apprendre, on aime bien les outils qui ne se mettent pas activement en travers de ta route pour t'empêcher de faire ton boulot.

landry@ : Au début, on utilise parce que certains points sont intéressants, et après la contribution vient naturellement parce que la doc est lisible et simple. Dans mon cas, j'ai commencé par porter grisbi (une bête appli de compta personnelle), car j'en ai eu besoin lorsque j'ai commencé à utiliser Open en desktop principal, après 2 ou 3 ans d'utilisation serveur. Puis lorsque Xfce 4.4 est sorti, je commençais à bien connaitre le code d'Xfce, je me suis aperçu que le port OpenBSD était plus ou moins à l'abandon, donc j'ai repris le flambeau.

gilles@ : Apres plusieurs années a utiliser principalement Linux, un « copain du net » m'a parle d'OpenBSD, un système « un peu lent et pas très connu » qui était clean et sécurisé. Apres l'avoir installé, je suis tombé sous le charme et ne l'ai plus jamais quitté (OpenBSD hein, pas le copain du net).
C'est donc naturellement que mes contributions se sont portées sur ce système, c'est celui sur lequel j'ai passé le plus de temps :-)

miod@ :

<dlg> its true that apple is using intel. i read it on slashdot
<alek> Yeah, and BSD is dead.
<alek> I read that there too...
<h> of course it is.
<h> why else would miod hack on it.

Tu parles d'une question ! Un choix, c'est personnel et pas forcément rationnel. Et il va de soi que l'on sera plus facilement amené à contribuer à un projet que l'on utilise au jour le jour, qu'à un projet que l'on apprécie sans forcément l'utiliser. J'ai contribué à OpenBSD parce que je l'utilisais. Et les raisons du choix de l'utiliser sont en partie dues au hasard, et en partie réfléchies…
La version officielle est que, lorsqu'il a fallu choisir entre NetBSD et OpenBSD, j'ai migré vers OpenBSD car les deux auteurs du code NIS de NetBSD (TdR et Mats O Jansson) étaient du côté OpenBSD.
Il y a une version officieuse, qui ne se raconte que d'oreille de druide à oreille de druide qu'autour d'une bonne bière.

---

LinuxFr.org : Est-ce que les hackathons OpenBSD sont importants pour faire avancer le travail ou bien est-ce principalement un évènement social ? Comment ça se passe vu de l'intérieur ?

espie@ : C'est un boost énorme pour le développement du projet. Déjà, il s'y passe des choses importantes en soit, puisqu'on peut faire rapidement avancer certaines choses, mais surtout ça fluidifie énormément les interactions entre développeurs pour le reste de l'année. C'est très différent de faire un chat avec quelqu'un qu'on connait physiquement et quelqu'un qu’on n’a jamais rencontré: il y a plein de nuances de langage qui, d'un coup, prennent tout leur sens.

landry@ : C'est autant important pour le coté social (ie les discussions dans les bars/restos) que pour le coté « on bosse une semaine d'affilée non-stop ». En plus, on est tous au même endroit donc les interactions/collaborations sont simplifiées. C'est aussi pas mal de moments de détente et de craquages…

gilles@ : Il est clair que cela fait avancer le travail considérablement, d'une part parce que nous sommes dans un environnement productif entourés de gens qui bossent, mais aussi parce que c'est fait dans une bonne ambiance, on peut échanger des idées et avoir un feedback immédiat. Les fuseaux horaires ne sont plus un problème et les contraintes moindres, chacun bosse à son rythme et sans pression.
Ça reste un événement social, chacun est libre de prendre un break quand il veut d'aller faire du tourisme, de la randonnée, d'aller boire des bières, c'est très sympa et ça permet a des gens qui ne travaillent pas forcément sur le même code d'échanger un peu.

miod@ :

<kjell> dammit. I LIVE in calgary and I'm still not adjusted to the local time after the hackathon. :)
<kjell> or rather, to civilian time.

Il y a un dicton officiel du parti qui dit : « un hackathon, ça sert soit à initier des choses, soit à les terminer ». La dimension sociale est bien évidemment une part importante (il est toujours agréable, à moins d'être un asocial endurci, de mettre un visage sur les noms de ses interlocuteurs), mais l'autre facteur important est la rapidité de communication: tous les développeurs réunis sont dans la même "timezone", donc actifs à peu près sur les mêmes plages horaires, et sont venus pour travailler ensemble, et font l'effort de ne pas se laisser distraire (voire accaparer) par le Monde-Réel-en-temps-normal.
De plus comme toute communauté, cela solidifie les liens entre personnes à coup de récits, d'anecdotes, de situations cocasses, etc.
Certains développeurs qui n'ont plus la possibilité d'être aussi actifs que par le passé se réservent pour les hackathons, et mettent tout en oeuvre pour ne pas les rater. Sans ce type d'événements, ces personnes ne contribueraient probablement plus du tout à l'avancement du projet.

---

LinuxFr.org : Est-ce qu'il existe selon toi une « culture » OpenBSD spécifique et reconnaissable ? Si oui comment est-ce que tu la définirait ?

espie@ : Oh que oui. Une culture d'artisan, envie de bien faire les choses, de prendre son temps, d'avoir à terme quelque chose qui soit nickel. Utilisable, simple.

landry@ : Beaucoup de private jokes entre dev…et « shut up and hack » est toujours d'actualité. Si quelqu'un veut quelque chose, il n'a qu'à le faire.

gilles@ : L'un des aspects reconnaissable et spécifique est l'absence de compromis sur les blobs. Le système ne dispose pas d'objet précompilés par un tiers, ne dispose pas de code contenant des defines opaques, de code signé sous NDA, etc… Quand vous téléchargez les sources d'OpenBSD, vous téléchargez les sources de TOUT OpenBSD.
D'autre part, il y a un réel souci de la qualité et de la simplicité. Les débats techniques tournent souvent autour de l'élégance d'une solution, le code ne sera pas commité juste parce qu'il marche. Il faut aussi qu'il soit élégant, cohérent et qu'il soit « la bonne solution ».
On pourrait débattre longuement de pourquoi cette intransigeance est un bienfait pour OpenBSD ET pour l'open-source en règle générale, mais ce genre de débat a bien vite fait de se transformer en troll :-)

miod@ :

<miod> are we not blowfishes?
<deraadt> You're saying we are DEVOlopers?

Il y a une culture propre aux développeurs du projet, c'est flagrant (et renforcé insidieusement par les hackathons), et plutôt normal car les développeurs adhèrent à la plupart des objectifs et techniques du projet. C'est une culture assez proche d'une culture d'artisans, avec l'amour du travail bien fait (quand on en a la possibilité), à force de « cent fois sur ${EDITOR} remettez votre ouvrage ».
Par ailleurs, comme les développeurs essuient souvent, en interne, des critiques sur leur code ou leurs idées assénées avec le moins de diplomatie possible, ils finissent par avoir le cuir bien tanné, et il s'agit là d'une vertu très appréciée (voire indispensable).
Le revers d'une telle attitude, c'est qu'elle encourage une certaine intolérance vis-à-vis du code considéré comme « pas à la hauteur », qui se manifeste parfois à la limite de l'arrogance. D'ailleurs, certains développeurs sont connus pour avoir des opinions péremptoires et pas toujours argumentées vis-à-vis du code d'autres projets (citons pêle-mèle OpenSSL, X.org, le noyau Linux), ce qui, reconnaissons-le, est franchement pénible. Et je ne fais sans doute pas exception à la règle !
En ce qui concerne les utilisateurs du système, je n'en sais rien. Une partie des utilisateurs, en tous cas les contributeurs réguliers aux listes de diffusion, ont un certain nombre d'atomes crochus avec les développeurs, sans avoir nécessairement le temps, les compétences ou tout simplement l'envie, de s'impliquer davantage dans la vie du système. Il serait difficile de dire quoi que ce soit sur les utilisateurs qui ne se manifestent pas…

---

LinuxFr.org : Theo est un leader à poigne alors que NetBSD et FreeBSD n'ont pas ce genre de "dictateur bienveillant". Qu'est-ce que tu penses de ce mode de fonctionnement ?

espie@ : Le principe dans OpenBSD, c'est que les décisions sont prises par les gens qui font avancer les choses. On ne peut pas vraiment s'assoir sur un bloc de code et dire « c'est à moi, vous n'y toucherez pas ». C'est un excellent principe. Pour ce qui est de Theo, c'est un type génial, qui a une excellente vision stratégique de ce qu'on veut faire. Il a rarement tort, et presque toujours raison. C'est une influence fondamentale pour la qualité d'OpenBSD. C'est aussi un gros avantage en cas de discorde entre développeurs: il y a quelqu'un pour trancher, on ne va pas remettre la décision 25 fois en question (ça change de mon vrai boulot…). Son plus gros défaut, c'est certainement d'être parfois peu diplomatique…

landry@ : Oh, regardez, un troll qui passe.
Plus sérieusement, c'est un mode de fonctionnement qui marche. En général il sait de quoi il parle, donc quand il tranche, c'est avec des raisons qui se tiennent. Après, le monde de l'OSS aime les potins et les ragots, donc il est facilement dépeint à tort comme un hystérique…

gilles@ : Disons que ce mode de fonctionnement ne me semble pas délirant.
Dans tout projet, il faut un chef de projet qui puisse prendre une décision sur les sujets qui peinent à mettre tout le monde d'accord. Theo est plutôt pas mal dans ce rôle, il sait gueuler quand il faut, il est perfectionniste et à priori il ne fera pas de compromis sur les points qui m'ont attirés chez OpenBSD.
Notre communauté reste tout de même basée sur la discussion, en ce sens Theo ne déroge pas a la règle et ses solutions et commits sont soumis au peer-review de la même manière que n'importe quel autre développeur. Il ne va pas committer du code qui est inferieur techniquement à celui d'un autre juste parce que c'est le sien.

miod@ : J'ai envie de répondre « Rien ».
Bon, en fait, l'intérêt d'avoir une personne qui gueule plus fort que les autres (ou qu'on laisse gueuler plus fort que les autres) est d'éviter de perdre du temps dans des discussions de type bikeshed. L'inconvénient étant que les arbitrages rendus ne sont pas toujours les meilleurs (car pas toujours faits selon des critères rationnels). Mais globalement, et de ce que je peux voir dans d'autre projets, on évite de perdre un temps énorme dans ces discussions sans intérêt (et on évite aussi d'avoir des gens qui ne s'expriment que dans ce type de discussion car ils estiment qu'ils ont leur mot à dire mais ne bougeront pas le petit doigt pour faire quoi que ce soit).
Ceci dit, le comportement abrasif de TdR a aussi découragé des personnes de talent de s'impliquer dans le développement d'OpenBSD. C'est à double tranchant.

---

LinuxFr.org : OpenBSD a pour habitude de lentement remplacer tous les logiciels sous licence GPL par des équivalents ISC-BSD. Quelle est la raison de cette politique de remplacement ?

espie@ : Ca fait partie des buts du projet OpenBSD. La GPLv2 est acceptable si on ne peut pas faire autrement. On n'aime vraiment pas la GPLv3, qui est effectivement illisible, peu testée en justice, et mise à l'écart de l'industrie. C'est pas un hasard si LLVM a décollé lorsque GCC est passé en GPLv3.
Et oui, la GPL est vraiment moins libre que la licence BSD, puisqu'on retire des droits à l'utilisateur pour "mieux le protéger du grand méchant capitaliste". Personnellement, je trouve ça infantilisant comme façon de voir les choses. Ça ne nous empêche pas d'être extrêmement bruyants lorsqu'un constructeur de matériel fait des choses fermées, on est beaucoup moins conciliant là-dessus qu'un Linux ou qu'un FreeBSD…

landry@ : L'éthique, ca compte ? Un jour ou l'autre, les changements de licence des projets utilisant la GPL font qu'on ne peut plus importer de nouvelles versions (ie pour l'instant pas de GPLv3, donc pas de gcc > 4.2.1, ni de gdb > 6.6). Avec un logiciel sous une licence différente, le problème ne se pose pas.

gilles@ : Ce genre de questions…on a déjà déclenché des guerres pour moins que ca :-)
Plus sérieusement, il ne s'agit pas d'une question d'idéologie bête et méchante mais plus d'une question pratique a mon sens.
OpenBSD distribue un système libre au sens BSD, la présence de code GPL dans la base fait que l'intégralité du système n'est pas soumis aux mêmes règles. Si des outils équivalents existent en licence ISC/BSD alors la question ne se pose pas et c'est plus simple.

miod@ : Essentiellement une raison politique due à la licence GPL, tout simplement.

---

LinuxFr.org : Sans troller quel est à tes yeux le principal défaut de la GPL ? Est-ce le côté idéologique de la FSF ? La complexité du texte par rapport à la ISC-BSD ? Le fait que la GPL ne permet pas d'intégrer le code dans un projet non GPL et donc est "moins libre" ?

landry@ : La licence est illisible pour un humain normal…et cette complexité donne lieu a des situations ubuesques, comme les incompatibilités entre différentes versions de LGPL/GPL.

gilles@ : À la base, pour moi qui venais de Linux et adhérais a la GPL, le premier frein a été la complexité et la taille de la licence. J'ai eu l'impression de devoir faire des études de droit pour la comprendre elle et ses implications, puis j' ai fini par la voir comme un gros pâté de règles.
En prenant un peu de recul, j'ai pris conscience que je voulais donner le code à la communauté sans rien demander en contrepartie. La licence BSD me convient mieux, après chacun fait le choix de ce qu'il veut donner et prendre en retour donc je ne conseille jamais de licence, c'est un choix euh…intime ?

miod@ : Il faut distinguer la GPL version 2 et la GPL version 3 ici. La GPL version 2 ne (nous) pose de problèmes que parce que, de notre point de vue, elle n'est pas aussi libre que nous le souhaiterions.
La licence GPL version 3 ajoute le problème de sa non-compréhensibilité pour un simple mortel. À moins d'avoir de solides bases juridiques, il n'est pas possible de trouver deux personnes qui en comprennent le texte de la même façon. Le texte de cette licence est tellement long et complexe qu'il inspire deux choses : d'une part, on se demande s'il ne s'agit pas d'un poisson d'avril qui aurait mal tourné, et d'autre part, on se demande où est la backdoor tellement il y a de texte et de clauses, alors que l'idée derrière la GPL peut s'exprimer, en langage non juridique, de façon beaucoup plus courte. Du coup nous n'avons aucune confiance en cette licence. La FSF prétend que « en substance, c'est comme la GPLv2, mais en mieux », et nous restons dubitatifs.

---

LinuxFr.org : Avec PC-BSD il y a une tentative sérieuse de proposer un desktop facile à utiliser et basé sur un BSD. Quel est ton avis sur ce projet ? Est-ce qu'un équivalent basé sur OpenBSD te semble souhaitable ?

espie@ : Il y a de gros efforts pour rendre nos ports plus simples d'installation et de configuration. Et il y a certains aspects de PC-BSD qui m'intéressent. Mais c'est un problème de ressources.

landry@ : C'est bien pour Mme michu… Après, OpenBSD est déjà facile à utiliser en desktop, pourvu qu'on sache lire de la doc, et qu'on connaisse un peu le fonctionnement d'un système (un peu a la Slackware disons). Je ne pense pas qu'un installeur graphique soit pertinent, si un utilisateur est rebuté par un installeur en ligne de commande, OpenBSD n'est pas fait pour lui…

gilles@ : Je connais très mal PC-BSD mais on m'en a dit beaucoup de bien.
Je ne sais pas si un équivalent basé sur OpenBSD serait souhaitable. En effet, ce qui fait le « charme » de PC-BSD est qu'il est très simple a utiliser et qu'il fait de BSD ce que Ubuntu a fait de Linux, un système que ma moman peut s'installer et utiliser.
OpenBSD n'acceptant pas de blobs et ne distribuant pas tous les firmwares, il va fatalement falloir mettre la main a la pâte dans certains cas la où PC-BSD ne nécessitera pas de faire cet effort. Ma moman ne sait pas utiliser un term et ne sait pas qui est root :-(

miod@ : Je n'ai aucun avis sur PC-BSD car je ne l'ai pas essayé et que je ne fais pas partie de la cible d'un tel projet.

---

LinuxFr.org : Plus généralement quelle est ta position sur la « démocratisation » d'OpenBSD ? Est-ce qu'il faut rechercher des nouveaux utilisateurs ou bien est-ce que tu penses qu'il faut qu'il y ait une sorte de barrière minimum à l'entrée pour que seuls les gens motivés utilisent ce système ?

espie@ : La barrière à l'entrée est très raisonnable: on veut des gens qui sachent lire, et qui utilisent leur cerveau. Je me fous un peu d'avoir des utilisateurs en plus. Des développeurs doués supplémentaires, ça oui, ça m'intéresse énormément. Il y a énormément de chantiers en cours dans OpenBSD. Quelqu'un de motivé peut à peu près toucher à tout dans le système. Par contre, OpenBSD comme système réservé aux serveurs et inutilisable par un utilisateur moyen, ce sont deux fausses idées qui sont franchement insultantes vis-à-vis du travail accompli. J'encourage les gens à ne pas bêtement colporter ce genre de niaiserie, mais à essayer OpenBSD avant de dire n'importe quoi.

landry@ : Il n'y a pas de service marketing@ (contrairement à certains, ils se reconnaîtront :). Ce n'est pas une question d'être motivé ou non, il suffit juste d'être curieux et de savoir lire et comprendre une doc. Les nouveaux utilisateurs viennent généralement par curiosité, on ne force personne à utiliser le système.

gilles@ : Je suis pour la démocratisation, je suis fier du travail qui est fait par nos hackers et je pense que beaucoup d'utilisateurs gagneraient à passer certains postes et serveurs sous OpenBSD.
Maintenant, je suis également pour une barrière à l'entrée. OpenBSD dispose de documentation d'une qualité que je n'ai jamais trouvée ailleurs et savoir lire fait partie des pré-requis si l'on ne veut pas se faire jeter des pierres. En ce qui me concerne, je passe pas mal de temps a répondre aux questions par mail, mais je m'attends à ce qu'il y ait eu un minimum d'effort préalable.

miod@ : En tant que vieux con élitiste et mangeur d'enfants, j'estime que le fait d'être devant un clavier et un écran ne dispense pas d'utiliser son cerveau et de faire preuve de bon sens. Je n'aime pas, à titre personnel, les interfaces qui me cachent leur fonctionnement et m'empêchent de comprendre ce qui se passe en cas de problème. Je préfère que les utilisateurs d'OpenBSD aient un certain niveau de connaissance de l'utilisation (et l'administration de base) d'un système de type Unix. Ce n'est pas une question de motivation, c'est une question de comprendre un minimum le fonctionnement du système.

---

LinuxFr.org : Est-ce que tu vois GCC comme un compilateur incontournable ou bien est-ce que tu penses que LLVM va le surpasser ?

espie@ : GCC est un mal nécessaire, ça fait pas mal d'années qu'il ne correspond plus vraiment aux objectifs d'OpenBSD :
- Le compilo est très gros, très lent, bouffe énormément de mémoire.
- La conception interne a été guidée par des principes politiques, aucune séparation propre du frontend et du backend, de peur que des sales entreprises propriétaires fabriquent leur propre compilo C++, ou leur propre backend pour leur processeur propriétaire.
Du coup, plein de choses sympathiques sont infaisables, comme d'utiliser gcc pour auditer du code.
- GCC est essentiellement développé par quelques gros vendeurs linux, Red Hat en tête. Ça se sent très fort côté architectures réellement supportées. C'est aussi extrêmement dur de participer à leur process de développement, vu que seuls sont acceptés les patchs pour la version courante, avec éventuel backport sur la version antérieure. Une grosse partie du temps, la version courante ne marche pas sous OpenBSD, ce qui rend difficile le fait d'adapter nos patchs à la version courante. C'est la raison pour laquelle certaines de nos innovations (les vérifs supplémentaires de taille de tampon développées par Otto Morboeck) ne sont pas dans la version officielle de GCC.
- Il y a aussi pas mal de pression pour faire du code qui tourne vite, quitte à interpréter la norme de manière dangereuse pour la sécurité. On n'a pas forcément d'énormes attentes du côté LLVM, mais on a bien l'intention de rester avec notre version de GCC le plus longtemps possible. On s'est arrêté à la dernière version sous GPLv2…

landry@ : Joker, je ne connais pas assez GCC pour en parler. Je sais juste que l'archi parait crade (la non-séparation des backends du core ou quelque chose comme ca, tout ca pour des raisons de licence), et que le support pour certaines architectures que supporte OpenBSD est progressivement droppé.

gilles@ : LLVM est très prometteur et plusieurs devs s'en servent pour le très très sympathique scan-build :-)
Après je n'ai pas trop de recul, j'utilise principalement GCC puisque c'est le compilateur qui sert a générer la release.

miod@ :

<art> Ok. I added a printf if s == NULL and now it's not NULL anymore.
<deraadt> Nice compiler you got there.
<art> compiled with -O2 what can you expect?
<deraadt> Correctness?

J'avais dit il y a plusieurs années déjà que GCC avait réussi à faire le vide autour de lui (voir ce commentaire). Cela commence enfin à changer. J'apprécie énormément l'activité de projets comme LLVM, mais je doute que LLVM ne taille réellement des croupières à GCC avant plusieurs années. On en reparle dans cinq ans ?

---

LinuxFr.org : Dans la plupart des OS libres on assiste à une floraison de nouveaux systèmes de fichiers (HAMMER, ZFS, Btrfs, etc). Est-ce que l'entrée de ZFS dans OpenBSD est prévue ou bien est-ce UFS2 qui va rester le standard ? Est-ce que tu penses que c'est un sujet important ou bien est-ce que UFS2 est suffisament bon et donc qu'il n'y a pas urgence ?

espie@ : C'est pas prévu, c'est pas urgent, et j'avoue que ça ne m'intéresse pas.

landry@ : ZFS a une licence inacceptable pour OpenBSD. De ce que j'ai suivi de quelques discussions, il y'a un certain intérêt pour HAMMER, mais pas de code. Un certain L.T. disait « Talk is cheap, just show me the code ». Pour l'instant, otto@ accomplit un travail certain sur FFS et fsck, et ce sont des fondations éprouvées qui sont faites pour rester longtemps.
Ah, et UFS2 c'est chez FreeBSD. FFS2, c'est « juste » l'antédiluvien FFS avec le support des partitions > 1To.

gilles@ : Humpf j'aimerai bien voir HAMMER porté sous OpenBSD, il m'envoie du rêve. Quelqu'un ? :-)

miod@ :

<art> Does anyone know the time complexity of fsck?
<deraadt> O(forever)

ZFS n'est pas prévu ne serait-ce que pour une simple question de licence. J'aimerai bien voir un système de fichiers plus moderne qu'UFS dans OpenBSD (Hammer, par exemple), mais je n'ai ni le temps ni très envie de m'en occuper, et c'est une partie du système qui nécessite beaucoup de temps, de compétence, et une bonne épaisseur de dos.

---

LinuxFr.org : À l'heure actuelle il me semble que les threads sont gérés en userland dans OpenBSD avec libpthread. Comment avance le projet rthreads ? Comment se compare ce nouveau système avec les implémentations qui existent dans les autres OS ?

espie@ : Ça avance trop lentement à mon goût, vu qu'une implémentation des threads totalement conforme est de plus en plus indispensable au fonctionnement de plein de logiciels tiers.

landry@ : rthreads c'est le holy grail de la plupart des porteurs, ça nous permettrait de virer plein de hacks crades partout dans le portstree. Mais ça avance très lentement.

miod@ : C'est exact. La libpthread d'OpenBSD est une implémentation au rabais, dérivée d'une très vieille implémentation. En gros c'est comme GNU Pth dans son mode le plus spartiate, mais en pire. Et pourtant ça tombe en marche la plupart du temps.
Le projet rthreads vise à fournir de vrais processus légers, gérés par le noyau comme composants d'un même processus lourd, et ordonnançables indépendamment les uns des autres (en configuration "1:1" : a un processus léger correspond une entité ordonnançable).
Mais ce projet avance très lentement car il n'y a réellement qu'une seule personne qui y travaille, et que c'est un travail particulièrement ingrat et casse-${GENITALS}…

---

LinuxFr.org : Est-ce que la scalabilité sur une machine multiprocesseur, qui nécessite un remplacement du Giant Lock par des verrous à grains fins, est un objectif vraiment compatible avec la simplicité/sécurité de l'OS ?

espie@ : Les choses ne sont pas si claires que ça ! Il n'est même pas évident que mettre plein de petits verrous partout soit une si bonne idée, côté performances. Combien de temps est-ce qu'un noyau à grains fins passe à acquérir des verrous et les rendre ? C'est non négligeable ! Sur une machine mono-coeur ou bi-coeur, le gain n'est pas du tout net, mais le fonctionnement à base de verrous fins est un consensus, peu de gens se posent vraiment la question de savoir si on y gagne réellement, ça commence à ressembler à la case à cocher pour manager.
Plutôt que de mettre des petits verrous partout, il faut sans doute identifier les sous-systèmes qui sont vraiment goulet d'étranglement, et permettre à plusieurs process de visiter ces sous-systèmes en même temps. Si on peut permettre à pf de bosser tout seul dans son coin, par exemple, et sans doute certains aspects du filesystem. Et garder le reste sous biglock. Il y a aussi plein d'autres améliorations orthogonales qui feront gagner plus de temps. Le boulot de gestion mémoire d'Ariane, par exemple. Ou toutes les histoires d'affinités de processus sur un coeur. Une gestion mémoire correcte est à mon avis un enjeu bien plus important que le biglock côté performances.
Pour revenir sur les verrous, en plus, évidemment, ça rajoute du bruit qui complique le travail si tu veux faire quelque chose de robuste et sûr.

miod@ : De mon point de vue, non. Ce qui n'empêche pas qu'il soit possible de le faire (encore heureux).
À mon avis, il est moins dangereux de réécrire un sous-système en le concevant avec des verrous à grain fin, que de modifier en ce sens un système existant : tous les postulats du code existant non explicitement documentés vont fatalement être cassés chacun à leur tour (voire plusieurs fois), lors de la mise en place des nouveaux verrous, et au final, dès lors que le système est assez complexe, la mise au point est très longue est laborieuse.
Mais d'un point de vue purement d'ingénierie, il est plus facile de converger vers le verrouillage à grains fins par cette méthode, quitte à ce que le processus dure très longtemps, que par le remplacement global du sous-système (dont la nouvelle version ne sera pas exempte d'erreurs et nécessitera un temps de stabilisation potentiellement long).
C'est d'ailleurs cette approche progressive qui a été adoptée par Linux et FreeBSD, pour ne citer qu'eux.

---

LinuxFr.org : Comment est-ce que tu considères les autres systèmes BSD ? Est-ce qu'il y a beaucoup de partage de code et de pollinisation croisée ou bien c'est plutôt « chacun dans son coin » ?

espie@ : Je m'intéresse surtout aux bouts sur lesquels je travaille. D'après mon expérience, il y a pas mal de partage: Net et Free ont repris tout mon boulot sur m4, par exemple. Le rythme est souvent lent, par contre, avec pas mal d'années de décalage entre ce qui se fait chez les uns et les autres.

landry@ : J'échange assez souvent avec mes homologues de FreeBSD/pkgsrc pour certains ports, on se pique régulièrement des patches, et on essaie de faire front commun pour contrer les codes qui se veulent linux-only.

miod@ :

<drahn> anyone how writes C code in 147+ column should be shot.
<brad> drahn: have anyone in mind ?
<drahn> darwin developers perhaps.

Comme inférieurs, bien sûr, ne serait-ce que parce qu'ils ne peuvent pas tourner sur bon nombre de mes machines (-:
Pique à part, il y a moins de partage de code que par le passé, car les différents BSD ont tous divergé fortement les uns par rapport aux autres, mais il y a beaucoup de suivi entre les BSD (i.e. une partie des développeurs de GremlinBSD suit le développement de PoltergeistBSD, et vice-versa). Par ailleurs, même si le code de FermatBSD n'est pas directement transposable à MersenneBSD, il peut servir de source d'inspiration (« comment ont-ils résolu ce problème ? ») ou de documentation (« tiens, l'auteur mentionne que la documentation officielle de tel registre est erronée »).

---

LinuxFr.org : Pourquoi est-ce qu'il n'y a pas de système « Role-Based Access Control » ou « Mandatory Access Control » à la SELinux dans OpenBSD ? Est-ce une question de complexité de configuration ?

espie@ : Parce que ça n'apporte rien en terme de sécurité réelle. Je sais que certains vont s'étrangler en lisant ça. Ce genre de trucs est essentiellement là pour les feignants, qui n'ont pas le temps de faire de la vraie sécurité, et qui vont coller des rustines à la place. Si tu as un système complexe, ce n'est pas en rajoutant de la complexité que tu vas le rendre plus sûr, bien au contraire. Les MAC et autres cochonneries sont là pour faire qu'un Unix ressemble plus à un Windows… ça permet juste d'implémenter des politiques de sécurité plus bancales, au lieu de se poser de vraies questions. Ça va permettre de faire du logiciel propriétaire plus portable, en portant le modèle de sécurité tout pourri de Windows.

miod@ : C'est une décision philosophique. OpenBSD essaie de fournir un système de type Unix, et considère qu'un système de type RSBAC n'est plus un Unix.
Il y a aussi, effectivement, le fait que configurer un tel système n'est pas à la portée du premier venu et que le risque d'erreur est grand.
Maintenant, ça, c'est l'opinion du projet en 2011. Il est possible que le discours sur ce sujet soit différent dans quelques années.

---

LinuxFr.org : Comment as-tu réagi à l'histoire de la backdoor qui aurait été implantée dans OpenBSD ? Es-ce que tu penses qu'il y a eu des dégats sur le plan médiatique ou bien que finalement cela aura eu des effets positifs en terme de revue de code ?

espie@ : J'ai réagi avec scepticisme. Peu surpris, mais déçu par la couverture médiatique extrêmement sensationnaliste qui en a été faite (il y avait une revue net macintosh qui a été particulièrement nulle, sur le coup, faudrait que je retrouve la référence). Les faits: un illustre inconnu (du point de vue des gens d'OpenBSD) affirme que Jason Wright aurait codé une backdoor dans IPSec. Il mélange des faits anodins et vérifiables, comme le fait que Jason était employé à tel endroit, avec des élucubrations étranges sur IPSec… bizarre autant qu'étrange. Au final, on a regardé à la loupe les bouts de code concernés, un peu d'audit ne faisant jamais de mal, pour enterrer définitivement cette rumeur. C'est du FUD. On ne sait juste pas trop à qui profite ce coup médiatique !

landry@ : Beaucoup de vent et de fud pour pas grand chose…les gens sérieux savent passer au dessus de ce genre de ragots douteux, et se faire une opinion par eux-mêmes.

gilles@ : Plutôt sereinement, ce n'est pas la première fois que quelqu'un balance sans preuve ce genre de commentaire sur une liste de diffusion.
Médiatiquement, OpenBSD a montré son sérieux en ré-auditant le code suspect malgré le fait qu'il n'y avait pas de preuve concernant la backdoor, le code en est sorti encore plus fiable.
Sans vouloir lancer de FUD, je serais plus inquiet de backdoors de la CIA dans un driver propriétaire d'une grosse boite américaine qui est distribué par de nombreux systèmes bien plus populaires. Après, très personnellement, je pense que la CIA a d'autres chats a fouetter que backdoorer des systèmes open-source et qu'ils peuvent obtenir les infos qui les intéressent de manière plus directes :-)

miod@ :

<art> Give 1000 monkeys with typewriters enough time and they'll write an old exploit.

J'ai tellement ri que j'ai eu une crampe du diaphragme. Le seul dégât est la réputation de Gregory Perry, et je doute que le gain en notoriété en valait la chandelle.
Je doute également que cela aie eu des effets positifs en revue de code. Certes, cela a été l'occasion de faire un audit du code incriminé, ce qui n'avait pas été fait depuis un certain temps; mais il y avait, et il y a toujours, des audits (ir)réguliers du code.
En revanche, il est possible que cela a servi à rendre les gens, à l'extérieur du projet, plus conscients du besoin d'audit régulier (et surtout, récurrent).

---

LinuxFr.org : J'avais posé une question à Brad Spengler (GRSecurity) au sujet de strlcpy et strlcat et de la perspective de leur intégration dans la glibc. Sa réponse a été : « Tous ceux qui veulent remplacer les dépassements de tampons exploitables par des troncations de chaînes exploitables sont libres d'ajouter leur propre copie de strlcpy et strlcat dans leur code source. Je ne vois aucune raison pour ajouter ces fonctions dans la glibc ». Qu'est-ce que tu penses de cette opinion ?

espie@ : La voix de son maitre. Il reprend verbatim l'avis d'Ulrich Drepper. Quand je dis que linux ressemble de plus en plus à une secte ! Je me demande si ces gens sont en contact avec de vrais développeurs, genre ceux qui pondent les centaines de logiciels qui sont dans les ports. La grosse majorité fait n'importe quoi avec strcpy. Et les patterns courants d'utilisation de strncpy ou strncat ne sont pas brillants…
Ce que refusent de voir Drepper et Spengler, c'est que le programmeur moyen ne sait pas utiliser strcpy, alors que strlcpy est infiniment plus neuneu-proof. La raison pour laquelle strlcpy est plus sûre, c'est qu'elle est bien plus simple à utiliser, et donc qu'on peut faire avec du code correct du premier coup. Ulrich et Spengler voient la situation avec des œillères. Il ne faut pas arrêter la discussion sur strcpy aux problèmes de sécurité que vont poser ces diverses fonctions aux Über-programmers, mais aller faire un tour dans les tranchées, regarder à quoi ressemble du code typique. Là, on constate que l'essentiel des problèmes posés par strcpy est résolu par strlcpy. Les soucis de troncation de chaîne sont infiniment moins graves.

Quitte à faire une analogie douteuse, ça me rappelle la position de l'Église Catholique concernant l'utilisation des moyens de contraception. Le discours officiel, c'est que ceux-ci sont une Mauvaise Idée puisqu'ils permettent des rapports charnels autres que dans le cadre du couple. Très certainement, mais ça n'est pas le problème le plus urgent, en particulier médicalement, où la non-utilisation de moyens de contraceptions tue des gens, en particulier en Afrique.

gilles@ : Il s'agit d'un commentaire absolument pas informé venant d'une personne qui ne sait de toute évidence pas lire une man page. strlcpy/strlcat permettent de détecter les troncatures et de gérer l'erreur…
Je pourrais montrer un petit exemple de code et le mettre au défi d'exploiter ma troncature exploitable mais je ne ferai que recopier l'exemple de la page de manuel qu'il a préféré ignorer.

miod@ : Que les valeurs de retour de ces deux fonctions ne sont pas faites pour les chiens.

---

LinuxFr.org : De manière générale les développeurs de GRSecurity/PaX semblent assez amers du manque de reconnaissance à leur égard (cf ce graphique) Est-ce que OpenBSD s'est inspiré d'eux pour W^X ou bien est-ce complètement indépendant ?

espie@ : Indépendant, pour autant que je sache. Après, le boulot de GRsecurity/PAX est tellement incomplet que c'est normal que quasi-personne ne leur rende hommage. L'essentiel du boulot dans OpenBSD, ce n'est pas de développer de nouvelles protections pour la sécurité comme W^X. Ça, c'est essentiellement trivial, ça ne représente même pas 5% du travail. Non, le vrai travail, c'est de les faire marcher. De pouvoir les déployer sur la totalité du système. Et ça, ça bouffe 95% du temps. Quelques exemples concrets: W^X a complètement cassé emacs, et nécessité de faire pas mal de choses pour le réparer… La randomisation des chargements mémoire a fortement compliqué W^X. Ça a aussi cassé tous les logiciels qui s'attendaient à pouvoir faire du mmap à une adresse fixe. Tous les interpréteurs lisp, par exemple. Les guard pages ont permis de détecter des buffer overflow et underflow en lecture. Trois bugs à corriger rien que de la compilation d'openoffice… Oh, et les canaris ont demandé quelques corrections dans le serveur X, qui comportait quelques buffers overflows. La liste est très longue… À comparer avec GRsecurity, où à peu près tout est débrayable, et généralement débrayé sur un système en production.

miod@ : Il s'agit d'un travail indépendant. Personnellement je n'ai appris l'existence de PaX que lorsqu'ils ont commencé à se manifester en hurlant au plagiat.
L'idée, côté OpenBSD, a germé chez un groupe de développeurs lors de l'événement "What The Hack" HAL 2001. Comme ils étaient fortement imbibés d'alcool, il est possible qu'il y ait eu discussion entre les gens de PaX et ces développeurs, et que ces derniers ne s'en souviennent pas parce qu'ils avaient trop bu. Ou vice-versa.
D'un autre côté, étant donné que le ou les auteurs de PaX s'évertuent à rester anonymes, et que l'attitude du projet OpenBSD est de considérer avec le plus grand mépris les personnes qui diffusent « leur » code de façon anonyme, cela n'aide pas à apaiser les relations.

---

LinuxFr.org : Le support d'une version d'OpenBSD est très court (1 an) par rapport aux distributions Linux qui visent le marché de l'entreprise. Est-ce que tu vois ça comme un vrai handicap ou bien est-ce que cela n'a pas vraiment d'importance ? Est-ce qu'il existe des solutions envisageables et réalistes pour améliorer cette situation ?

espie@ : C'est un mal nécessaire, on n'a pas les ressources pour assurer un niveau de support réaliste sur des durées plus longues. L'essentiel des efforts se concentre sur le fait de rendre les mises à jour encore plus fiables et sans douleur. Si des entreprises ont de vrais besoins à ce niveau-là, il suffirait qu'ils mettent quelques sous là-dedans…

landry@ : Une entreprise fournissant du support sur OpenBSD peut être capable de tenir ce rythme de mise à jour, donc c'est pour moi largement suffisant. À titre perso et comme la grande majorité des développeurs, j'utilise uniquement -current.

gilles@ : Cela n'a pas vraiment d'importance, OpenBSD se cale sur un délai permettant de faire des releases avec des évolutions fréquentes et qui ne nous mettent pas trop la pression sans pour autant nous laisser le temps de glandouiller.
Autant les changements qui risquent de casser un setup sont pris en compte et des fois une couche de compatibilité est conservée pendant une release pour laisser un délai de migration, autant c'est à l'entreprise qui décide qu'OpenBSD lui convient de gérer quand et comment elle fait ses updates.

miod@ : C'est un handicap, mais je suis sûr qu'il est possible de trouver une entreprise (SSLL…) pour fournir ce support si nécessaire.
Il n'y a pas volonté de changer cet état de fait. Nous préférons que les gens fassent tourner du code récent, cela nous évite de nous souvenir de tous les bugs corrigés dans les versions antérieures (-:

---

LinuxFr.org : Le sujet polémique du moment c'est la question de la compatibilité multi-OS des développements. Entre les protestations d'Xfce au sujet des technologies compatibles seulement avec Linux (udev) et les propositions de Lennart Poettering de rendre GNOME dépendant du noyau Linux (systemd) il semble que nous traversions une période de crise. Quel est ton sentiment à ce sujet ?

espie@ : C'est pas une vraie nouveauté (voir ma réponse concernant GCC), c'est juste plus sorti au grand jour. Je pense que tous ces projets n'ont pas bien réalisé le nombre d'innovations qui viennent du monde BSD et pas de Linux. Linux n'est pas viable écologiquement en tant que mono-culture.

landry@ : Si les choses sont bien faites, elles peuvent être ou portables, ou optionnelles. Sinon, il faut se battre contre des choix stupides.
Upower est un bon exemple de comment designer un code pour qu'il soit facilement possible d'écrire un backend pour un OS. Udev est l'exemple opposé. Les développeurs BSD veulent bien écrire le code pour qu'Udev marche sur autre chose que linux, mais il faudrait déjà que le code soit architecturé et documenté pour, et qu'il ne faille pas se battre contre des moulins à vent bornés dans le cas de systemd.

gilles@ : Je pense que les gens comme Poettering sont une véritable nuisance à la communauté open-source. Ils créent des conflits là où il n'y en a pas, provoquent des tensions dans des communautés qui échangent et coopèrent sans problème habituellement, et ce uniquement parce qu'ils sont persuadés que leur système est le seul qui soit valable. C'est de l'intégrisme à deux balles…
Je pense que son systemd est une mauvaise solution à un faux problème et qu'il va se prendre des coups de bambou de la part d'un paquet de monde. Remplacer sans vraie raison un outil destiné aux admins par une solution pensée pour les codeurs, ça m'a tout l'air d'être la recette d'une cata.
Mon sentiment au sujet des projets qui tendent à oublier la portabilité pour préférer Linux, c'est que tout cela chagrine landry@ et ajacoutot@, et quand ils sont tristes, je suis moi même triste :-(
Si OpenBSD décidait du jour au lendemain de ne plus distribuer OpenSSH en version portable parce que « notre code est supérieur » je pense que tout le monde crierait au scandale et serait bien embêté.

miod@ : Je n'ai pas l'impression d'une crise. J'ai juste l'impression que les logiciels « à la mode » sont écrits par des gens qui ont oublié la philosophie « ne faire qu'une chose, mais la faire bien » qui a fait le succès d'Unix. Il ne faut pas oublier que le libre, c'est vaste, et cela va bien au delà des systèmes de type Unix. Des systèmes comme Haiku ou Syllable sont des logiciels libres qui méritent tout autant notre considération.
Qu'un développeur souhaite ne pas faire l'effort de rendre son code portable, c'est son choix, et il faut le respecter. Mais dès lors que le logiciel est poussé comme indispensable, ne pas lui permettre de fonctionner sur d'autres systèmes libres est une marque de mépris.
Les différents systèmes libres se conforment à des interfaces de programmation destinées à faciliter le portage de code entre les systèmes, telles que POSIX. On peut regretter une certaine inertie dans l'évolution de ce genre de standard, mais d'un autre côté il est préférable de se donner la possibilité de prendre du recul sur les évolutions techniques proposées par les différents systèmes et savoir adopter les bonnes idées tout en évitant celles qui s'avèrent être mal conçues.
Il est également normal que les outils les plus proches du système puissent avoir besoin d'interfaces plus spécifiques que ce que peut proposer POSIX. Dans ce cas le travail de portage est plus délicat, mais cela peut être l'occasion de convaincre les autres systèmes d'adopter ces interfaces…

---

LinuxFr.org : Si tu pouvais changer quelque chose dans le mode de développement d'OpenBSD qu'est-ce que ce serait ?

espie@ : Rappeler aux utilisateurs que c'est des choses qu'on fait sur notre temps libre, et que s'ils apprécient le résultat, ils peuvent donner des sous. Ou fabriquer des structures d'entreprises qui vendent du OpenBSD. Ça permettrait d'avoir plus de moyens, et donc d'aller plus loin.

landry@ : CVS. De tous les SCM que j'ai du utiliser, c'est de loin le moins pratique/convivial… mais faut faire avec.

gilles@ : Plus de hackathons en Europe :-)

miod@ :

<t> i only sign NDA's
<smart> No Deal, Asshole?

Je n'en sais rien. Je suis trop impliqué et depuis trop longtemps pour pouvoir prendre assez de recul pour répondre à cette question. Le fonctionnement actuel est plutôt efficace à mes yeux…

---

Questions spécifiques pour espie@

LinuxFr.org : Est-ce que tu peux expliquer un peu cette séparation entre le basesystem et les ports ? C'est assez alien pour un utilisateur d'une distribution GNU/Linux classique.

espie@ : C'est une simplification nécessaire: ça permet d'avoir un système de base dont tu es sûr qu'il est cohérent. Il y a aussi un niveau de support beaucoup plus important pour le système de base. C'est également une simplification pour l'utilisateur: les outils de base sont là. On ne réalise pas, quinze jours après, qu'on a oublié d'installer finger et telnet et qu'on en aurait bien besoin. C'est encore plus net si on travaille sur un système administré par quelqu'un d'autre, on est bien moins dépendant des idiosyncrasies du root local. On a un vrai système Unix avec les outils de base présents sur tous les Unix depuis plus de 20 ans.

landry@ : Le basesystem permet de faire toutes les tâches de base, et est maintenu comme un ensemble. Les ports permettent d'installer des alternatives a ce qui est dans le basesys, ou quelque chose répondant a un besoin particulier.

---

LinuxFr.org : Quelle était la raison pour laquelle tu t'es lancé dans cette réécriture complète des outils `pkg*` ? Pourquoi le Perl ?_

espie@ : C'était juste la façon la plus rapide de répondre à nos besoins: les outils en C étaient remplis de buffer overflows potentiels, et totalement inadaptés à l'idée de faire des mises-à-jour. Perl était le seul langage présent dans le système de bases répondant à tous mes besoins: excellentes capacités de traitement de chaînes, orientation objet… et langage non compilé. pkg_add n'est que la partie émergée de l'iceberg, il y a tous les scripts du système de ports qui s'appuient sur la même infrastructure. J'ai « perdu » un peu de temps dans la réécriture, qui a été regagné une bonne dizaine de fois depuis (en fait, ce qui a pris le plus de temps, c'est la conception et pas la réécriture).

landry@ : Parce que perl était dans le basesystem, et qu'il permet de faire de l'OO "facilement" :)

---

LinuxFr.org : Est-ce que tu regardes les autres gestionnaires modernes de paquets chez les cousins BSD (pkgin, pkgng) ? Ces gestionnaires utilisent sqlite alors que ta réécriture des `pkg*` n'a pas opté pour cette solution. Pourquoi avoir fait ce choix ?_

espie@ : Oui, bien sûr, je suis ce que font les voisins depuis pas mal d'années. Avec un oeil amusé. On a débroussaillé le terrain avec pas mal d'années d'avance. Avec leurs nouveaux outils, ils vont se coltiner tous les problèmes qu'on a rencontrés, diagnostiqués et résolus depuis quatre ou cinq ans. Bonne chance à eux. Nos outils continuent d'avancer: peut-être qu'un utilisateur extérieur aura l'impression que ça stagne depuis un an ou deux, mais il y a eu énormément d'efforts faits en terme de fiabilité et de vision à long terme, maintenant qu'on a réellement des upgrades de packages fonctionnelles depuis quelques versions.

En ce qui concerne sqlite, la réponse sera longue. D'abord, ce n'est pas une nécessité. Perl a permis de gagner énormément de temps par rapport aux outils équivalents chez Net et Free, et donc la vieille base « plate » dans /var/db/pkg donne des performances décentes jusqu'à 1000/2000 packages installés. J'ai un temps de développement limité, j'ai préféré consacrer mon énergie à rendre les choses plus dynamiques, comme par exemple savoir faire des mise-à-jour au vol sans avoir à télécharger une base de données pour commencer.
Il y a aussi les risques inhérents à un manque de synchronisation entre l'upstream et l'installation locale, à l'installation locale et la base. Il y a aussi le fait que certaines infos, comme les packing-lists à proprement parler, sont des objets structurés complexes qu'une base sqlite n'aidera pas. Techniquement, passer sur sqlite nécessiterait d'avoir sqlite dans le système de base, ce qui est possible, et l'interface perl correspondante, ce qui est bien plus problématique. S'il faut aller plus vite, on a encore de la marge:

- pkg_add utilise un client ftp externe. Passer sur du http 1.1 en interne, même si c'est relativement complexe, permettrait de gagner énormément en vitesse.

- je crois que PC-BSD fait quelque chose de similaire, mais on peut envisager de garder un build de packages et de fabriquer le nouveau build en comparaison avec l'ancien. Ça permettrait d'éviter de toucher aux fichiers qui n'ont pas réellement changé, et on doit pouvoir découpler la packing-list de la tarball correspondante. Le but, ça serait de mettre en début d'archive les nouveaux fichiers, et de reléguer en fin de package les fichiers qui ne bougent pas, d'où possibilité de ne pas télécharger tout un package pour une mise-à-jour. Pas d'idée sur les gains réels à attendre par contre. Mais c'est vachement plus intéressant que sqlite.

Note que nos packages comportent deux bases de données: sqlports et pkglocatedb, l'une qui est effectivement une base sqlite, utilisée fréquemment par l'équipe de maintenance, puisqu'elle contient toutes les meta-infos de tous les ports, et l'autre qui est une base locate(8), extrèmement utile pour déterminer quel package installer pour avoir quel fichier.

landry@ : Pas de sqlite dans le basesystem (problème de la poule et de l'oeuf) mais des outils autour de pkg_* utilisant sqlite sont disponibles dans les packages (pkglocatedb, sqlports, pkg_mgr…)

---

LinuxFr.org : À ton avis est-ce une duplication des efforts ou bien chaque gestionnaire de paquets à sa justification technique ?

espie@ : C'est une duplication des efforts. À côté, le gros du boulot dans le pkg_add d'OpenBSD, c'est le travail de conception et pas le code. Donc si les voisins reprennent nos bonnes idées, c'est déjà ça. Bon à côté, sociologiquement, c'est impossible que Free ou Net reprennent mes outils: ils n'ont pas de ligne directrice bien établie, avec un système de ports variante « auberge espagnole ». Beaucoup de leurs développeurs sont toujours encroûtés dans l'idée « je recompile à partir des sources ». Les nouveaux outils vont sans doute les amener à passer à l'idée de distribution, avec des packages binaires fiables. De ce côté, PC-BSD a clairement compris les enjeux.

landry@ : pkg_add en perl était là il y'a > 5 ans… à ce moment, les pkg tools des autres OS étaient « rustiques ». Après, FreeBSD et pkgsrc n'ont probablement pas importé notre pkg_add car il était en perl, non présent dans leurs basesys respectifs.

---

LinuxFr.org : Dans ton diaporama sur le développement de pkg_add j'ai lu cette phrase: "OpenBSD is an hostile environment, and that's GOOD for quality". Est-ce que tu peux expliquer un peu plus ce que tu veux dire ?

espie@ : Tout simplement qu'il y a des gens brillants prèts à faire des critiques constructives, et à te forcer à donner le meilleur de toi-même. C'est souvent la version #10 d'un patch qui va être finalement committée, et même si c'est chiant sur le moment, c'est vrai que les versions #1 à 6 sont de la merde, et #7 à #9 sont juste acceptables…

---

Questions spécifiques pour landry@

LinuxFr.org : Est-ce que tu peux faire le point sur Xfce dans OpenBSD ? Est-ce que toutes les fonctions de la version 4.8 seront disponibles ?

landry@ : À part l'automontage des devices via thunar-volman (qui ne fait pas partie du core d'Xfce, qui dépendait de HAL, qui dépend de udev/gudev/udisks), tout marche, et c'est comme ca depuis quelques années. Thunar 1.2 avec gvfs marche pour samba, ftp, webdav. Pour les partages sftp://, il faut utiliser un agent ssh, on ne peut pas avoir de prompt login/password, mais c'est une limitation de gvfs sur OpenBSD. J'ai peu de temps pour écrire du code pour Xfce, mais je m'assure qu'il continue à compiler/marcher, via un buildbot qui doit finir d'être configuré.

---

LinuxFr.org : Est-ce qu'il est facile de maintenir les divers ports Mozilla ? Quels sont les challenges techniques ? Quels sont les patchs par rapport à l'upstream ?

landry@ : Facile une fois qu'on connaît le code, le mode de fonctionnement de l'upstream (tout passe par le bugzilla, les diverses branches, etc) et les bonnes personnes à contacter en cas de soucis dans une partie du code.
Le souci pour les ports est la multiplicité, quand il y a une release de mozilla, il y'a 2 ou 3 releases de firefox, une de seamonkey, une de thunderbird, une de xulrunner, qui ne viennent pas tous des mêmes branches, etc… La codebase est énorme, et bouge beaucoup, donc certains patchs valides à un instant T sont à revalider à T+1. Mozilla supporte officiellement Linux/OSX/Windows 32 bits/PC, avec certains en 64 bits, alors qu'OpenBSD supporte en plus macppc et sparc64, donc de temps en temps il faut se battre pour que ça ne soit pas trop cassé sur les architectures « exotiques ».

Je passe énormément de temps à upstreamer les patches qui sont dans le portstree, mais heureusement certaines personnes chez Mozilla voient cela d'un bon œil, donc les choses se passent plutôt bien. Monter un buildbot dédié sur plusieurs architectures aide bien à suivre le développement du trunk, et à faire remonter les problèmes en amont des releases.

---

Questions spécifiques pour gilles@

LinuxFr.org : Quelle est la situation sur smtpd ? Où en est le projet ?

gilles@ : OpenSMTPD a eu un développement très très intense durant ses premiers mois puis des divergences avec un autre développeur ont commencées a rendre les contributions difficiles pour les externes et pour moi-même, j'ai fini par prendre un petit break… les testeurs et contributeurs aussi.
Le projet a stagné durant pas loin d'un an puis comme c'était du gâchis je me suis remis dessus il y a quelques semaines. Le projet est de nouveau très actif, il y a de nouveau des testeurs et des contributeurs aussi bien en interne qu'en externe.
Actuellement le projet n'est pas encore prêt pour la production mais il ne manque pas grand chose et on table sur 2 ou 3 releases pour l'activer par défaut à la place de sendmail.
Je m'attaquerai au portage par la suite.

---

LinuxFr.org : Une fois que le projet sera terminé quels sont les avantages techniques de smtpd par rapport à sendmail ?

gilles@ : Techniquement le but n'est pas de rendre smtpd supérieur à sendmail, mais de faire en sorte qu'il existe une alternative simple, fiable, et qui sache répondre à 95% des cas d'utilisation.
Actuellement, sur mon propre serveur j'ai un OpenSMTPD qui :

• écoute en inet4 et inet6
• authentifie les utilisateurs
• gère les aliases
• accepte des mails pour des domaines primaires
• accepte des mails pour des domaines virtuels
• fait office de serveur MX de backup pour deux ou trois domaines

La config fait moins de 10 lignes et pourrait être condensée sur 4 ou 5 lignes compréhensibles si je prenais la peine de le faire. Le tout sans avoir besoin d'un bouquin grâce à une syntaxe très lisible.
ÇA c'est le gros avantage par rapport à sendmail !
Après il y a d'autres fonctionnalités très sympa prévues, mais c'est un peu la surprise ;-)

---

Questions spécifiques pour miod@

LinuxFr.org : On dit que porter du code pour le faire tourner sur une architecture exotique est un bon moyen pour trouver des bugs. Est-ce que c'est vrai ? Est-ce que tu as des exemples ?

miod@ :

<ficus> He commented out the stuff that tried to use 4*atan(1) for PI, and uncommented the stuff that defined PI as 3.1415926535...
<ficus> Seems to work.
<ficus> Why on earth they want to derive PI at runtime is beyond me..
<ficus> Do they think it's going to change? :P
<miod> Of course. in a few years, they'll use GNU pi instead.

C'est vrai. Il y a les différences simplement dues à l'architecture du processeur et du MMU :

- Différence d'endianness (le mot 0x12345678 écrit en mémoire devient 0x78563412 sur un processeur little-endian, et 0x12345678 sur un processeur big-endian) ;

- Taille des registres, et par conséquence des types élémentaires du langage C (la popularisation des amd64 a fait beaucoup de bien pour corriger les problèmes simples de mélange de types 32 bits et 64 bits, néammoins certains problèmes ne se voient que sur des systèmes 64 bits big-endian: le fait d'écrire un pointeur (donc 64 bits) en mémoire et de le relire en tant que quantité 32 bits. En little-endian, si les 32 bits de poids fort sont à zéro, la troncature n'a aucun effet. En big-endian, ce sont les 32 bits de poids fort qui sont lus, et ça se voit tout de suite) ;

- Comportement lors des accès non alignés (par exemple lire un mot de 32 bits à une adresse non multiple de 32 bits): là où certains processeurs comme les x86 vont automatiquement décomposer l'accès en plusieurs cycles de lecture ou écriture de plus petite taille, et réassembler les morceaux pour que ce soit transparent, d'autres processeurs lèvent une exception.

- Les superstars du cache. Un cache, c'est une mémoire associative qui est composée de « lignes » de taille fixe. Les lignes du cache sont identifiées par leur « index », et ont différents attributs (en particulier l'information si la ligne contient des données valides et, dans un cache à écriture différée (writeback), si elles ont été modifiées mais non répercutées en mémoire), ainsi qu'un « tag ».

Dans un cache simple, à chaque index correspond une ligne. Dans un cache N-voies plus performant, à chaque index correspond N lignes. Le calcul de l'index et du tag sont deux fonctions (au sens mathématique) permettant de faire correspondre une adresse mémoire à une ligne de cache. Lorsque le processeur recherche des données dans le cache, il détermine l'index et le tag correspondant à l'adresse mémoire accédée, et si une des lignes de cache de l'index contient le même tag, c'est la bonne.

Les ennuis commencent lorsqu'on utilise le MMU, car il y a en fait deux adresses utilisables pour chaque fonction: soit l'adresse virtuelle, soit l'adresse physique (obtenue après passage par le MMU). Si le cache utilise les adresses physiques pour l'index et le tag (cache PIPT), il est (aux problématiques d'écriture différée près) totalement transparent pour le système. C'est le grand luxe, et c'est le cas des caches des systèmes x86. Mais pour des raisons de performance (et de coût en transistors), la plupart des processeurs modernes non-x86 utilisent l'adresse virtuelle pour l'index, et parfois aussi pour le tag (on a donc des caches VIPT et VIVT). Dès que le cache est VI, le système doit s'en mêler. D'une part, puisqu'il est VI, il est nécessaire de le purger à chaque changement de contexte (puisque les traductions d'adresse vont changer). Ensuite, il est possible, toujours par le jeu de la traduction d'adresse, d'avoir plusieurs lignes, d'index différent, pointant vers la même adresse physique.

Certains caches sont capables de détecter cette situation et de le gérer de façon transparente. C'est Byzance. D'autres détectent cette situation mais se contentent de lever une exception: on peut détecter le problème et essayer de le contourner. Mais la plupart des caches ne détectent rien (pour économiser des transistors) et ont un comportement indéfini dans ce cas (et en général, pas beau à voir). Dans ce cas il est de la responsabilité du système de faire en sorte que cette situation d'alias ne se produise jamais. Pour corser le tout, sur certaines plate-forme, les caches L1 et L2 fonctionnent de façon différente: par exemple L1 est un cache VIPT et L2 est un cache PIPT. Ce qui nécessite un certain soin lorsqu'il faut invalider une partie du cache…

- les espaces d'adressage superviseur et utilisateur séparés: sur les processeurs qui ne partagent pas l'espace d'adressage, il est nécessaire d'utiliser des instructions spécifiques pour copier des données d'un espace d'adressage à un autre (programmation des registres SFC et DFC sur m68k, instructions .usr sur m88k, instructions ldws/stws sur pa-risc, etc). Ceci est masqué par les fonctions copyin() et copyout() sous BSD, et copy_from_user() et copy_to_user() sous Linux, mais un programmeur qui ne teste que sur x86 risque d'oublier d'utiliser ces fonctions et de faire un vulgaire memcpy(), puisque cela fonctionne très bien… sur sa machine.

- l'ordre des écritures en mémoire. Sur les processeurs modernes (ainsi que tous les superscalaires), il est possible que, pour des raisons d'optimisation, les opérations d'écriture en mémoire ne soient pas répercutées dans l'ordre dans lequel les instructions les ont effectuées. De plus, certains processeurs ont un « write buffer » qui rend ces modifications non immédiates. Du code qui dépend du séquencement des écritures peut ne pas fonctionner correctement sur une autre plate-forme, tant que des instructions explicites de synchronisation et/ou d'éviction du « write buffer » n'ont pas été effectuées. En particulier certains périphériques communiquant avec le processeur par un système de boîte aux lettres peuvent mal fonctionner, si l'écriture déclenchant le relevé de la boîte aux lettres par le périphérique est effectuée avant les écritures du message en boîte. Les contrôleurs SCSI QLogic en particulier sont très sensibles à ce problème.

Ensuite, il y a les différences dues aux bus d'extension des machines.
Par exemple, les « BIOS » de certains types de machines (SGI, HP pa-risc) n'initialisent pas les bridges PCI-PCI, ou seulement certains modèles spécifiques, ce qui empêche des cartes d'extension (comme des adapteurs réseau multiports) de fonctionner tant que personne n'a écrit le code d'initialisation ad hoc (i.e. l'équivalent d'un BIOS PCI pour ces machines). Les mêmes cartes fonctionneront bien sûr du premier coup dans un compatible PC.
Sur d'autres systèmes, les adresses mémoire transmises à un périphérique capable de faire des accès DMA ne sont pas des adresses mémoire physique, mais des adresses qui sont traduites par un MMU dédié (un IOMMU), afin de réduire le risque d'écrasement d'une autre zone mémoire en cas d'erreur logicielle dans le pilote…ou dans le périphérique lui-même. Il est donc nécessaire de faire le travail de programmation de l'IOMMU, pour savoir quelle adresse passer au périphérique pour que l'IOMMU redirige le transfert vers la bonne zone.

---

LinuxFr.org : À lire les interviews de développeurs OpenBSD on s'aperçoit que l'architecture Sparc64 est assez populaire et elle est souvent mentionnée. Qu'est-ce que cette architecture a de spécial ?

miod@ :

<tt> miod, we should get you a ultra1
<miod> what for?
<tt> i mean, they are outdated junk, so you'd love one

Cette architecture est l'une des plus éloignées du traditionnel x86: 64 bits, big-endian, ne supporte pas les accès mémoire non alignés, cache L1 VIVT avec I$ et D$ séparés, mais cache L2 PIPT, espaces d'adressage noyau et utilisateur séparés, et plusieurs modes de gestion des écritures en mémoire (RMO/PSO/TSO). Et bien sûr un IOMMU par bus.
De plus, on trouve de nos jours des machines UltraSPARC raisonnablement rapides à des prix très modiques, et disposant de bonnes possibilités d'extension (USB, PCI…).

La ligne du parti est actuellement que tout développeur qui écrit un pilote pour un composant qui existe sous forme de carte PCI doit faire marcher son pilote sur sparc64 avant que celui-ci soit considéré comme digne de confiance pour être utilisé sur autre chose que les systèmes x86.

---

LinuxFr.org : Est-ce que tu peux expliquer un peu ce qu'est StackGhost et pourquoi c'est limité à Sparc ? En quoi est-ce différent de StackGuard ?

miod@ :

<deraadt> - struct hme_softc *sc = (struct hme_softc *)sc;
<deraadt> + struct hme_softc *sc = (struct hme_softc *)self;
<deraadt> You lucky bastard, Jason.
<jason@> *nod*
<jason@> I have NO idea how that worked...
<deraadt> welcome to register windows.

Les processeurs sparc et sparc64, ainsi que les ia64 (et, pour ceux qui s'en souviennent, les AMD 29k) ont une particularité: ces processeurs ont beaucoup de registres internes, mais seul un sous-ensemble des registres est visible à un moment donné : il s'agit d'une « fenêtre » sur l'ensemble des registres. À chaque appel de routine, la fenêtre « glisse » pour dégager des registres disponibles pour la nouvelle routine, tout en préservant les registres de la routine appelante. En fait, il y a un peu de recouvrement, de façon à pouvoir passer des données par les registres entre les deux fonctions.

Sur sparc (et sparc64), il y a à chaque instant 32 registres visibles: 8 registres globaux (%g0 à %g7), qui ne sont pas concernés par la fenêtre, et 24 registres glissants. Ces 24 registres glissants sont eux-mêmes divisés en trois groupes de 8: 8 registres d'entrée (%i0 à %i7), 8 registres locaux (%l0 à %l7), et 8 registres de sortie (%o0 à %o7). Quand on souhaite appeler une fonction, on place les données à lui transmettre (ses paramètres) dans les registres de sortie, et on appelle la routine. Celle-ci effectue un glissement de fenêtre, qui fait sortir de son « champ de vision » les registres %i et %l de l'appelant, « renomme » les registres %o de l'appelant en %i, et dégage 16 nouveaux registres pour fournir les %l et %o de la routine. Quand celle-ci a terminé son travail, elle place ses résultats dans ses registres %i, et retourne à l'appelant en provoquant un glissement dans l'autre sens: celui-ci retrouve ses registres %i et %l préservés, avec le résultat de la routine dans ses registres %o.

C'est un mécanisme plutôt élégant, mais malheureusement (pour le développeur de système) il y a un hic : le nombre de registres n'étant pas infini, tôt ou tard, on finit par épuiser tous les registres. Dans ce cas, le glissement provoque une exception, et le système doit alors sauvegarder l'ensemble des fenêtres utilisées en mémoire (sur la pile) et les marquer comme disponibles. Il y a une exception pour chaque sens de glissement: dans un cas (overflow, lors d'un énième appel de sous-routine), il faut sauvegarder les fenêtres et les marquer comme utilisables à nouveau, et dans l'autre cas (underflow, au retour de cette sous-routine) il faut restaurer les fenêtres et les marquer comme remplies à nouveau.
(Le mécanisme de glissement n'est pas automatique mais doit être explicitement demandé par la routine appelée, ceci afin de permettre à des routines simples n'ayant pas besoin de plus de 8 registres pour leur fonctionnement de ne pas utiliser de nouvelle fenêtre, se contentant d'utiliser les registres %o)

StackGhost est un mécanisme simple qui consiste, lors de la sauvegarde des fenêtres sur la pile, d'effectuer une transformation (un « ou exclusif » avec une valeur aléatoire, différente dans chaque processus) du contenu des registres qui contiennent les adresses de retour des fonctions. De cette façon, du code malicieux essayant de remplacer une adresse de retour par l'adresse de son choix ne peut plus fonctionner.

StackGuard, c'est quelque chose de totalement différent. Il s'agit de la première extension de GCC pour ajouter une protection contre les débordement de tampon des variables locales à la compilation, et qui a inspiré par la suite ProPolice et la fonctionnalité équivalente (-fstack-protector) présente dans gcc à partir de la version 4.1.

---

LinuxFr.org : Sous Linux le nombre de plate-formes ARM qui sont supportées explose littéralement. Est-ce que tu peux faire le point du support de l'architecture ARM sous OpenBSD ?

miod@ : ARM est une architecture relativement peu développée chez OpenBSD, essentiellement faute de développeurs motivés et ayant du temps à consacrer à cette plate-forme.
À l'heure actuelle, OpenBSD fonctionne sur une partie de la gamme Sharp Zaurus (les C-1000 et C-3x00, supportés par OpenBSD/zaurus), ainsi que sur certaines appliances à base de 80321 telles que le Thecus N2100, supportées par OpenBSD/armish.
Il y a également des efforts plus ou moins aboutis de portage sur Palm Pilot (OpenBSD/palm, qui a des problèmes de stabilité) et sur BeagleBoard et BeagleBoard xM (OpenBSD/beagle). De plus, il y a eu quelques impasses comme un portage avorté sur plate-forme Moko (OpenBSD/moko), et je crains que le portage sur Gumstix (OpenBSD/gumstix) ne prenne le même chemin.
Un de nos développeurs attend depuis plus d'un an sa commande d'un touchbook de Always Innovating, donc il est peu probable qu'OpenBSD soit un jour porté sur cette intéressante machine (et que cette société soit pérenne). Parmi les systèmes dignes d'intérêt pour un portage, on a laissé tomber le Sheevaplug et le Guruplug, de fiabilité plutôt douteuse (surtout le Guruplug). Nous lorgnons actuellement sur la PandaBoard qui semble promise à un bel avenir.

Malheureusement le manque de temps est la principale raison de la faible activité sur cette plate-forme. Theo envisageait il y a quelque temps d'organiser un mini-hackathon dédié aux portages ARM. Il risque d'avoir lieu courant 2012.

Aller plus loin

• OpenBSD (251 clics)
• Sortie d'OpenBSD 4.9 (82 clics)
• Soutenir le projet (48 clics)