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

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.
Après la première dépêche, cette seconde regroupe les réponses de :

• Matthieu Herrb (matthieu@): spécialiste du serveur graphique X.org.
• Antoine Jacoutot (ajacoutot@): mainteneur de GNOME et auteur de sysmerge.
• Damien Bergamini (damien@): auteur de multiples pilotes pour les périphériques sans fil.
• Alexandre Ratchov (ratchov@): auteur du serveur de son aucat.

Les questions sont, bien évidemment, les mêmes que celles posées lors de la première dépêche. On retrouve donc la division entre questions générales et, en fin d'entretien, quelques questions plus spécialisées à destination de chacun d'entre eux en fonction de leur domaine de prédilection. À noter que Damien a choisi de ne répondre qu'à ces questions spéciales.
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. Pour 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 matthieu@
• Questions spécifiques pour ajacoutot@
• Questions spécifiques pour damien@
• Questions spécifiques pour ratchov@

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 ?

matthieu@ : En ce qui me concerne c'est un choix réfléchi. Au départ le choix d'un BSD (NetBSD) par rapport à Linux ou aux autres Unix commerciaux, puis lors de la création d'OpenBSD, le choix de suivre Open plutôt que Net qui à l'époque était en train de stagner dangereusement.

ajacoutot@ : J'imagine que chacun possède son propre parcours qui le mène à contribuer à OpenBSD, tout comme c'est le cas pour quelqu'un contribuant à Linux, donc ce qui suit est, par définition, très personnel.

Mon choix de contribuer découle du fait que j'utilise principalement OpenBSD pour tous mes besoins informatiques : personnels et professionnels. J'ai débuté ma contribution active avec un portage de cyrus-imapd dont j'avais besoin à l'époque.
Ce qui m'a poussé à me tourner vers OpenBSD en premier lieu a été sa simplicité. La plupart des gens pensent que le développement de cet OS est exclusivement orienté sécurité ce qui est faux. Une de ses grandes forces, pour moi, est qu'il est livré avec une configuration par défaut qui a été pensée afin de fonctionner immédiatement (« just work »). Les fichiers de configuration sont simples et clairs, la documentation (i.e. man(1)) est excellente et à jour. On a également une politique très claire en ce qui concerne les options : moins il y en a, meilleur c'est. En outre, un véritable travail d'intégration est effectué, que ce soit dans le système de base ou dans les paquets. Pas besoin d'éditer ni de tuner 36 choses avant d'avoir un système fonctionnel. Et OpenBSD contient tout ce qui est nécessaire à une machine Unix « de base » (workstation ou serveur), à savoir DNS, DHCP, NTP, SNMP, SMTP, LPR, LDAP, NFS, YP, HTTP… ainsi qu'un environnement de développment complet (make, gcc, m4…), le tout avec une empreinte très réduite (et qu'on ne vienne pas sortir l'excuse qu'un compilo sur un serveur c'est dangereux).

L'idée d'avoir une séparation claire entre le système de base et les applications tierces ainsi que de préférer l'utilisation de paquets binaires plutôt que de compiler (via les ports) est aussi séduisante. Cela apporte une grande cohérence au système (e.g. le userland sera toujours synchronisé avec le noyau). Est beaucoup privilégiée également la non prolifération des applications effectuant la même chose (« one tool for one job »).
Le fait qu'une attention particulière soit apportée à la sécurité est pour moi la cerise sur le gâteau, c'est une chose de moins à se soucier puisque d'autres, bien plus compétents que moi sur le sujet, ont déja fait une grosse partie du boulot. Du coup, la plupart des daemons utilise la séparation ou l'abandon des privilèges (privilege separation et privilege dropping) et certains sont fournis « chrooté » par défaut (comme Apache ou Bind).

ratchov@ : La première fois, j'ai trouvé qu'OpenBSD était une plateforme de développement simple, carrée et bien documentée. Alors j'ai commencé à l'utiliser. Quand on utilise un système on trouve toujours des améliorations à faire.

---

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 ?

matthieu@ : Oui les hackathons sont un des points forts d'OpenBSD, qui a été là aussi parmi les précurseurs il y a plus de 10 ans. Le fait que les développeurs se rencontrent physiquement apporte beaucoup. On se comprend mieux ensuite dans les échanges virtuels en ayant une représentation mentale plus riche de ses interlocuteurs.
En plus des hackathons, la présence de stands OpenBSD dans tous les évènements Open Source importants en Europe pendant près de 10 ans a également permis de faire connaître OpenBSD à un grand nombre de personnes et de rencontrer des développeurs ou des futurs développeurs. Je trouve regrettable que cela se soit (mal) terminé.

ajacoutot@ : Alors là que ce soit bien clair, les hackathons sont indispensables :-)
Tout d'abord oui c'est un évènement social, mais qui a son importance dans le contexte d'un développement décentralisé. Mettre un visage sur un nom est essentiel et facilite la communication et le développement futur. Des groupes se créent autour d'un projet spécifique, des liens d'amitié sont noués et finalement, on joint l'utile à l'agréable. La devise la plus importante (souvent relayée par Theo d'ailleurs) c'est « Have fun ! » .
D'autre part, les hackathons sont souvent le lieu où un projet est démarré ou finalisé. On profite qu'une grande majorité des développeurs affiliés à un développement spécifique soient tous au même endroit afin de lancer des idées et débuter un design ou mettre un terme et committer un développement commencé plus tôt.
Je pense que toutes les personnes qui se réunissent afin de travailler sur un centre d'intérêt commun peuvent se retrouver dans le concept des hackathons. Pour moi OpenBSD ne serait pas ce qu'il est sans cela (autant de mon point de vue égoïste parce que c'est fun que d'un point de vue plus objectif de production de code).

---

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éfinirais ?

matthieu@ : La question est vaste. Il y a des points communs sur lesquels les développeurs et les utilisateurs se retrouvent. Certains sont liés à des questions de fond (la licence, la volonté de rester indépendants, le choix de faire simple tout en ayant un système utilisable,…) et d'autres sont plus du folklore (puffy, buveurs de bière, trolls…). Le problème c'est que la plupart des gens ne voient que ce folklore.

ajacoutot@ : Je ne sais pas trop s'il existe une « culture » OpenBSD. Ce qui est certain c'est que la grande majorité des gens qui contribuent sont généralement des personnes expérimentées. N'étant pas un système d'exploitation dit grand-public ni « mainstream », il est très rare de se retrouver à l'utiliser sans avoir au préalable eu un parcours assez large dans l'informatique. En outre, OpenBSD ne se prête pas trop au « tuning » (qui est très bien pour apprendre mais très chiant pour la production). Comme indiqué précédemment, la configuration par défaut a rarement besoin d'être touchée (sauf évidemment lors de contraintes spécifiques ce qui n'est pas le cas de 95% des installations). Du coup, certaines personnes qui aiment jouer avec les flags/knobs se tournent plus vers Linux ou FreeBSD pour commencer, puis viennent vers OpenBSD lorsqu'elles ont acquis les connaissances qu'elles souhaitaient et ne trouvent plus d'intérêt à pousser des boutons mais recherchent un système simple, stable et qui fonctionne tout de suite.

Donc je dirais que la communauté OpenBSD est généralement plus mûre que celle de Linux (ce qui n'est pas un jugement de valeur, attention) avec un héritage Unix plus prononcé. De là à savoir s'il existe une « culture »… moi je pense que non.
À la rigueur on pourrait parler d'une culture BSD plus générale, issue de l'histoire de ces systèmes, de leur mode de développement et de leur licence.

ratchov@ : Pour moi la « culture » OpenBSD, se résumerait à essayer de faire des choses simples et correctes. Culture du travail avec une touche de perfectionnisme.
Préserver la liberté de pouvoir modifier le code est l'autre facette. Et là, je ne parle pas que des licences, mais aussi de la simplicité du code et du design. Parce que même si la licence permet de modifier un programme, si il est trop compliqué il devient quasi-impossible à modifier. On est, alors, dépendant de son auteur.

---

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 ?

matthieu@ : De manière générale dans la conduite de projets (qu'ils soient basés sur le bénévolat ou dans le monde professionnel) un leader fort est un des ingrédients qu'on retrouve souvent dans les projets qui marchent.
Cela dit Theo dépend trop d'OpenBSD et cela va forcement devenir problématique un jour. J'espère qu'il arrivera à continuer à exister lorsque OpenBSD sera arrêté. C'est vrai aussi dans l'autre sens, mais ça tout le monde le sait…

ajacoutot@ : Je pense que pour un projet open source d'envergure c'est une bonne solution (Linux suit le même mode d'ailleurs). Je ne dis pas que c'est la meilleure mais elle convient parfaitement aux buts sans concession de ce projet spécifique (OpenBSD) et prévient l'émergence de petits groupes de pression liés à une entreprise par exemple. Mais si l'on prend l'inverse comme Debian, avec son administration de type « parlement européen », on voit que cela fonctionne aussi pour leurs besoins.
Pour être tout à fait honnête je n'ai pas d'avis tranché sur la question. Je pense que le mode de gouvernance fait partie intégrante de la « personnalité » d'un projet open-source et que les gens qui y sont attirés le sont (souvent) aussi par cet aspect.
Le bon mode de fonctionnement est celui qui convient aux développeurs, aux utilisateurs et à l'amélioration du système.

ratchov@ : Theo n'est pas un « dictateur ». Theo a sa copie du système (le repository, i.e., la référence) et il en fait ce qu'il veut ; il y met ce qu'il aime et enlève ce qu'il n'aime pas. Il ne force personne a contribuer ou à utiliser OpenBSD, il ne m'a jamais imposé quoi que ce soit, par exemple.
En revanche, il a les pieds sur terre, il sait ce qu'il veut ; en plus de développer, il s'assure de la cohérence du système et techniquement il est de très bon conseil.

---

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 ?

matthieu@ : À la fois la licence et la qualité du code.

ajacoutot@ : La liberté, celle de pouvoir distribuer notre projet de la manière dont on le souhaite et celle de pouvoir évoluer librement sans être tributaire des évolutions parfois autoritaires de la GPL (c.f. question suivante). D'autant plus que cela attise la compétition ;-)

---

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" ?

matthieu@ : Pour moi c'est avant tout le « copyleft ». Au point que je ne retrouve jamais le terme positif qu'utilisent ses défenseurs francophones pour dire « contaminant » ou « viral ».
Je ne suis pas du tout convaincu que cet aspect de la GPL ait eu un impact significatif sur la base de code libre existante. Il y a en effet peu d'exemples où la contrainte de mettre ses sources à disposition ait été transformée par une organisation en opportunité sincère de favoriser le développement ouvert d'un logiciel.
Dans la plupart des cas, c'est le service minimum (un serveur plus ou moins caché fournit un vague code source mal packagé, sans instructions de compilation ni docs de programmation) peu ou pas utilisable.
Et en second, la complexité du texte (qui atteint des sommets avec la v3) est également un élément rebutant.

ajacoutot@ : Si je devais faire une comparaison rapide et hasardeuse, pour moi la GPL est comme la politique étrangère des États-Unis forçant la mise en place de la « démocratie » à travers le monde. Sur le papier cela pourrait paraitre une bonne chose mais la réalité est toujours beaucoup plus compliquée. Les bien-pensants s'acharnent à imposer un mode de fonctionnement : en gros je te force à être libre. J'y vois là une sérieuse contradiction entre être obligé de se soumettre à certaines règles et la liberté de créer sans restrictions.
Sous OpenBSD on privilégie non pas la licence BSD historique mais une licence MIT-like (cf. /usr/share/misc/license.template) qui dit globalement :

- Respectez le copyright (i.e. ne pas dire qu'on a écrit ou que l'on possède le code lorsque ce n'est pas le cas).
- Ne venez pas pleurer devant ma porte si le programme ne fonctionne pas comme vous le souhaitez (i.e. pas de garantie). Pour le reste, faites ce que vous voulez avec mon code, vendez-le, créez des machines à mastiquer des bébés ou des vaccins contre le cancer ou que sais-je…

Après, comme toutes les guerres de religion, chacun possède sa propre philosophie en la matière et est persuadé de détenir la vérité… Personnellement, je n'aime pas les contraintes ni dire aux autres ce qu'ils doivent faire, j'aime qu'on me fiche la paix et la licence d' OpenBSD me convient bien ;-) Ce que j'essaie de dire est que le choix d'une licence, lorsque celui-ci est réfléchi, est généralement très personnel. Je pense que le projet GNU s'est tiré une balle dans le pied à long terme avec la version 3 de la GPL… à voir.
Cela étant je suis un pragmatique et je comprends que dans certaines circonstances la GPL puisse séduire des entités commerciales au démarrage d'un projet.

ratchov@ : J'avoue que je n'ai jamais eu le courage de lire attentivement les 10 pages de la GPL jusqu'au bout. Je trouve que c'est trop de mots, alors que je veux juste dire « prenez le code et faites en ce que vous voulez ».
Mais je trouve que les querelles de licences sont un faux problème et détournent l'attention d'un problème plus important.

À la base la GPL était là pour garantir la possibilité d'étudier, et de modifier le code ; c'est vraiment très bien. Mais de nos jours on écrit du code open source inutilement compliqué, non-documenté, ou sous NDA [non-disclosure agrement]. Est-ce que je peux l'étudier ? Non, parce qu'il est trop compliqué et/ou je n'ai pas la documentation. Est-ce que je peux le modifier ? Non, pour la même raison. Alors, qu'est-ce qu'il me reste à faire à part l'utiliser sagement et espérer que l'employé d'Intel qui l'a écrit corrige les bugs. Alors quelle serait, de ce point de vue, la différence entre du code open source trop compliqué et un binaire gratuit ?

Je caricature un peu, en réalité ce n'est ni blanc ni noir, mais je trouve que ces « blobs open source » prolifèrent de plus en plus, et à mon humble avis, il faut être vigilant avec le code. Par exemple, pour ce qui est des pilotes, on pourrait éviter de se rendre dépendant de matériel compliqué ou non-documenté.
Oops.. je m'égare.

---

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 ?

matthieu@ : Je ne connais quasiment pas PC-BSD. Mais pour ce que j'en connais, je ne vois pas trop ce que voudrait dire un équivalent basé sur OpenBSD.
Apparemment les développeurs de FreeBSD ont abandonné progressivement les machines de bureau et les laptops (il suffit de voir dans une conf BSD qu'ils utilisent presque tous des Macs comme laptops), laissant ainsi une place pour un projet comme PC-BSD.
A contrario, presque tous les développeurs OpenBSD que je connais utilisent au quotidien OpenBSD sur leurs stations de travail ou sur leurs laptops. Par conséquent OpenBSD « just works » sur ces machines et il n'y a pas besoin d'un projet spécifique pour ce type d'usage.

ajacoutot@ : Je pense que faire un dérivé orienté desktop (ou autre d'ailleurs) n'est pas la solution. J'ai très peu joué avec PC-BSD donc je n'émettrai pas d'avis particulier, ce que j'ai vu fonctionnait bien.

Je préfère le concept d'un système généraliste qui puisse s'adapter en fonction des besoins et se transformer en desktop « user-friendly » ou en serveur critique avec quelques modifications simples. La plupart du temps, un script de post-installation (ou même à lancer interactivement plus tard) est largement suffisant et je sais de quoi je parle car une partie de mon boulot est de déployer des infrastructures sous OpenBSD, tous services confondus, cela inclut un environnement de bureau pour utilisateurs non informaticiens.
Pour moi les dérivés sont intéressants dans le sens où ils permettent de s'affranchir de certaines contraintes liées au système sur lequel ils se basent, mais ne sont pas une fin en soit : éventuellement les avancées doivent pouvoir se retrouver dans le système initial.
Il me semble qu'à une période NetBSD avait lancé un projet pour améliorer et démocratiser leur desktop tout en ne s'affranchissant pas du système de base. Je ne sais pas où en est ce projet ni s'il existe toujours, mais je pense que ce genre d'initiative est plus intéressante que de créer un nouvel OS du type NetBSD-Desktop.

ratchov@ : Je pense que ce n'est pas souhaitable. OpenBSD est utilisable en desktop. S'il a des défauts, il me paraît plus avantageux d'améliorer le système plutôt que de dépenser de l'énergie à en maintenir un dérivé.

---

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 ?

matthieu@ : Les 2 ne sont pas incompatibles. Le réservoir des gens suffisamment curieux capables d'apprendre à installer et utiliser OpenBSD est immense. D'un point de vue citoyen face à la technologie, l'approche d'utiliser un système que l'on peut comprendre et analyser me paraît très importante.
En outre, par expérience, on peut très bien faire utiliser des machines sous OpenBSD à des gens qui n'y comprennent rien et ne veulent ou ne peuvent pas faire cet effort d'apprentissage. Il suffit d'avoir dans leur entourage une ou plusieurs personnes volontaires pour assurer un peu d'assistance.
Et pour ces derniers, la tâche est bien plus intéressante et gratifiante qu'en faisant cela pour un système propriétaire ou même pour les usines à gaz que sont devenues les distributions GNU/Linux les plus populaires.
Mais, même si la culture d'une certaine sobriété et simplicité progresse dans la société, pour l'instant le marketing du « toujours plus » de fonctionnalités, de ressources, de complexité, etc. a encore de beaux jours devant lui et cela restreint le champ de développent de systèmes comme OpenBSD.

ajacoutot@ : En aucune façon je ne vois l'intérêt d'une barrière à l'arrivée de nouveaux utilisateurs, j'en vois une en revanche à l'arrivée de bébés « assistés ».
Ce qu'il faut voir c'est que la communauté OpenBSD est bien plus petite que celle de Linux. Cela engendre un certain comportement qui pourrait paraître élitiste ou méprisant sur les listes de diffusion (RTFM et consorts). La raison est que lorsque l'on reçoit une question qui a été posée 50 fois, le renouvellement de nouveaux utilisateurs n'étant pas assez rapide, ce sont toujours les mêmes qui se retrouvent à devoir répondre encore et encore, alors qu'une simple recherche de 10 secondes dans les archives aurait été suffisante pour que la personne trouve elle-même la solution… et comme on est humain, ça énerve.
Sous Linux, ces questions sont souvent prises en charge par de récents utilisateurs qui sont heureux de pouvoir aider à leur tour (et du coup les anciens n'ont pas besoin de s'énerver ;-)). Bien entendu je généralise.

D'autre part, on demande tout de même aux utilisateurs d'effectuer un minimum de travail avant de poser une question. OpenBSD possède l'une des meilleures documentations du monde libre (objectivement) et les FAQ disponibles sur le site, traduites en plusieurs langues, permettent de résoudre la plupart des problèmes de base. D'ailleurs le nom de FAQ est mal utilisé, il s'agit plus d'un « handbook » comme sous FreeBSD. Je pense que tout le monde est d'accord pour dire qu'il est un peu énervant de recevoir un mail toutes les 5 minutes avec une question du genre: « comment je change la disposition de mon clavier ? » ou « comment j'installe firefox ? » alors que la solution est à portée de main. Ces personnes ont bien trouvé le site pour télécharger l'ISO d'installation, trouver la documentation est encore plus facile, il faut juste se donner la peine de la lire.

ratchov@ : On essaie de faire du code simple, correct et bien documenté; ensuite l'utilise qui veut. À ma connaissance personne ne cherche à attirer des utilisateurs, et personne ne cherche à mettre une barre à l'entrée.
Les considérations techniques passent en premier, et font qu'OpenBSD est largement utilisable pour quiconque prend le temps de comprendre la documentation.

---

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

matthieu@ : Je n'en sais trop rien. Mais j'espère qu'on pourra disposer dans le futur d'un bon compilateur C/C++ libre supportant de nombreuses architectures matérielles. GCC s'éloigne de ces critères, il y a donc une place à prendre.

ajacoutot@ : Je n'ai pas trop d'avis sur la question. Ce qui est certain c'est que pour le moment GCC reste incontournable. Cela étant, grâce au passage à la GPLv3 beaucoup de vendeurs, notamment dans l'embarqué, commencent à se détourner de GCC au profit d'autres compilateurs (cela est également vrai pour d'autres logiciels). Un gros problème de GCC est qu'il implémente beaucoup d'extensions non standards.
Il me semble que FreeBSD peut à présent être totalement compilé avec LLVM/Clang, mais reste le problème des ports (paquets), donc GCC sera encore utilisé un certain temps. Les choses vont forcément bouger à un moment car, si je ne dis pas de bêtises (j'en dis souvent), à part DragonFlyBSD les autres BSD ont refusé de mettre à jour GCC à partir de la version qui est passée sous GPLv3.

ratchov@ : Je suis plutôt enthousiasmé par pcc. Certains prétendent qu'il génère du code pas très optimal. Mais je ne pense pas que ce soit un problème, pour l'audio en tout cas. Je m'explique: le code léger, n'a pas besoin d'être optimisé, puisque la charge qu'il génère est par définition négligeable. Le code lourd, quant à lui, est généralement lourd à cause de son architecture. Un compilateur qui optimise bien pourrait améliorer sa performance, mais c'est un petit gain par rapport à ce qu'on gagnerait en améliorant l'architecture.
Je ne crois pas que ce raisonnement s'applique à tout, mais à ce que je peux voir, l'audio n'a pas besoin de beaucoup d'optimisations. Un petit compilateur, simple et modeste conviendrait.

---

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 ?

matthieu@ : Dans l'état actuel (licence CDDL, développement fermé par Oracle, avenir incertain) ZFS n'a aucune chance d'arriver dans OpenBSD.
Mais c'est un sujet important. Même si on arrive à vivre avec UFS(2), quand on a goûté aux fonctionnalités étendues de ZFS, ça devient addictif et on a du mal parfois avec les limites de UFS.

ajacoutot@ : Tout d'abord, UFS2 n'est utilisé que pour les gros systèmes de fichiers (genre >= 1To), pour le reste le défaut est toujours UFS (aka FFS). La différence entre notre implémentation et celle des autres BSD est qu'elle ne gère pas les attributs étendus pour le contrôle d'accès.
ZFS ne sera jamais intégré à OpenBSD pour une raison simple : sa licence.
HAMMER (développé par l'équipe talentueuse de DragonFlyBSD) serait un candidat plus probable en théorie, mais d'après ce que je sais, mis à part quelques regards jetés ici ou là, il n'y a rien sur le grill en ce moment. En outre, bien que développé sur un système BSD, porter HAMMER est très très loin d'être trivial car cela demande un gros travail sur le vfs(9) actuel.

Je pense que la problématique du système de fichiers est très importante. FFS/UFS existe depuis « toujours » et est très stable. En revanche, je dois admettre que ses performances ne sont pas dignes d'un système moderne. Les raisons sont multiples, et ne sont pas uniquement liées à UFS lui-même mais également à la couche vfs(9). Cela étant, pas mal de boulot est en cours sur le sujet.
Pour moi, c'est un point faible objectif d'OpenBSD, lorsque les choses sont bien faites, je pense que les performances d'un système de fichiers peuvent être bonnes sans pour autant sacrifier la stabilité ni la préservation des données.

---

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 ?

matthieu@ : rtheads avance doucement. Je n'ai pas cherché à l'évaluer récemment, je n'ai donc pas d'infos de comparaisons.
L'implémentation actuelle de pthreads, malgré ses limites, marche plutôt bien, puisqu'on arrive à faire tourner presque tous les monstres actuels (firefox & Co, OpenOffice,…) qui usent et abusent des threads.
Mais en liaison avec ta question suivante, rthreads est nécessaire pour pouvoir exploiter au mieux les machines multiprocesseurs.

ajacoutot@ : Je ne te remercie pas d'aborder le sujet des threads, je vais encore faire des cauchemars cette nuit !
Avec le système de fichiers, les threads gérés en userland sont pour moi le deuxième gros défaut objectif d'OpenBSD. Le plus gros problème n'est pas la performance (bien qu'il y ait un impact évident), mais le fait que par définition des threads en mode userland ne sont pas de vrais threads, cela demande de « tricher », comme par exemple de placer tous les descripteurs de fichiers en mode O_NONBLOCK (non bloquant). Les conséquences sont parfois problématiques (j'ai pas mal de problèmes sous GNOME, que je suis obligé de contourner avec des hacks pas très jolis ici ou là).
Cela étant, rthreads avance… doucement… C'est un sujet très complexe et chez nous, une seule personne est vraiment intimement liée à son développement, avec seulement un peu d'aide ici où là. Disons que si je suis optimiste, rthreads pourra devenir le défaut d'ici 1 à 2 ans, mais qui sait, on a vu des développements s'accélérer de façon exponentielle sous OpenBSD (comme le passage vers gcc4).

Les threads ne sont vraiment pas mon domaine donc je ne préfère pas répondre à la question de la comparaison avec les diverses implémentations, les autres le feront certainement bien mieux que moi.

---

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 ?

matthieu@ : Je ne pense pas que casser le biglock introduise nécessairement d'avantage de complexité dans le noyau. Ça peut même apporter une meilleure sécurité, par exemple grâce à une meilleure identification des interfaces entre les sous-systèmes du noyau.

ajacoutot@ : Avec la simplicité, clairement non. Avec la sécurité, du coup pas vraiment non plus : complexité et sécurité ne faisant généralement pas bon ménage. D'après ce que je sais, le Giant Lock est là pour très longtemps sous OpenBSD. Oui, c'est clairement un frein à la performance mais le projet est tout simplement trop petit pour le moment pour travailler sur un sujet aussi complexe, sensible et rarement finalisé du premier coup. Cela prendrait tout simplement beaucoup trop de temps (plusieurs années) pour bien faire les choses (« get it right »). Après, comme indiqué précédemment, je dis souvent des bêtises, donc qui sait ;-)

---

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 » ?

matthieu@ : Il y a des échanges et du partage de code. Mais c'est bien qu'il y ait plusieurs projets avec des personnalités et des objectifs variés. Ça permet au plus grand nombre de s'y retrouver.

ajacoutot@ : Non ce n'est pas chacun dans son coin, il y a pas mal de partage de code et certains développeurs ont un « commit access » dans plusieurs des BSD. Disons qu'en ce qui concerne le userland, les avancées ou corrections de bogues sont généralement partagées entre tous les BSD lorsque cela est possible. Pour le noyau c'est différent, chacun a évolué dans des directions assez diverses.
J'ai pas mal utilisé FreeBSD dans le passé mais j'en suis revenu, trop de boutons et des paquets binaires de piètre qualité (FreeBSD encourage plutôt la compilation à partir des ports, à la gentoo - où alors mettre en place une machine de build). Cela étant, c'est un très bon système sous bien des aspects, simplement trop compliqué à mon goût.
J'ai également utilisé NetBSD dans le passé aux alentours de la version 1.6 mais énormément de choses ont évolué depuis donc je ne préfère pas commenter plus avant. J'ai juste du mal à comprendre l'orientation générale du projet.

Je m'arrêterai là avec la comparaison, après ça devient une guerre de clocher, les goûts et les couleurs… Je préfère parler de ce que j'aime chez OpenBSD plutôt de ce que je n'aime pas chez les autres.

ratchov@ : Dans le domaine de l'audio, de temps en temps je regarde ce que les autres OS font, mais OpenBSD s'en est pas mal éloigné, donc il y a de moins en moins d'échanges de code possibles. Par contre, c'est toujours intéressant de voir comment les autres ont résolu les problèmes qu'on essaie de résoudre, ça donne des idées et on évite de faire les mêmes erreurs que les autres.
Réciproquement, j'essaie d'éviter les constructions qui pourraient compliquer gratuitement l'utilisation de code OpenBSD par d'autres systèmes.

---

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 ?

matthieu@ : Oui, mais pas seulement de la complexité de configuration. Il y a aussi derrière une complexité d'implémentation. Le tout crée un système très difficile à analyser pour garantir que les séparations que l'on a voulu implémenter sont réellement assurées.

ajacoutot@ : Oui, c'est encore une fois une question de complexité. Il est difficile d'implémenter MAC et RBAC correctement sans créer d'effets indésirables sur le reste du système. De plus, peu d'installations en ont un réel besoin, la plupart du temps, les simples permissions Unix et une configuration bien pensée sont suffisantes.

Attention, je ne dis pas que MAC et RBAC n'ont pas un véritable intérêt, simplement celui-ci n'est pas assez important pour justifier leur développement sous OpenBSD pour le moment. Maintenant si quelqu'un débarque avec du code simple, clair et sécurisé, je ne pense pas qu'il y ait un véto à leur arrivée dans le système un jour, mais ce n'est pas une priorité, loin de là. Mais je comprends que cela puisse manquer pour certains.

ratchov@ : Les permissions Unix suffisent à régler tous les problèmes d'administration de la vie de tous les jours. C'est simple et efficace. Les rares fois que j'ai vu RBAC utilisé, c'était pour faire ce que les permissions Unix permettaient déjà de faire : paresse ou méconnaissance des permissions Unix ? Bref, pourquoi créer un second système de permissions ? Plus compliqué, plus de travail, et plus de chance de se tirer une balle dans le pied.

---

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égâts sur le plan médiatique ou bien que finalement cela aura eu des effets positifs en terme de revue de code ?

matthieu@ : Le seul effet intéressant c'est en effet le regain d'intérêt pour le code d'IPSec qui a permis de trouver des bugs, mais rien que l'on puisse sérieusement soupçonner d'intentionnel.

ajacoutot@ : Sur le plan médiatique, je ne pense pas qu'il y ait eu de véritable impact, en tous cas ce n'est pas flagrant. Mais personnellement, je participe généralement peu au blabla.
Cette histoire aura finalement eu un effet positif puisqu'elle a forcé un nouvel audit de cette partie du code et d'autres bogues ont été trouvés puis corrigés.
Après, ce que j'en pense… aucune idée, disons que mon intime conviction est que la base de l'histoire est probablement vraie, mais n'est pas spécifique à OpenBSD. Je pense que beaucoup d'entités aimeraient pouvoir implémenter des backdoors dans les systèmes d'exploitation, mais entre vouloir et pouvoir, il y a un fossé. Si tentative il y a eu, je pense qu'elle n'a pas fonctionné, mais c'est juste une supputation.

ratchov@ : Bien sûr, il y a eu de la revue de code.
Mais cette histoire, au-delà d'OpenBSD, a surtout permis de rappeler qu'on ne peut faire confiance qu'à du code simple. Quand on a affaire à du code compliqué, qu'on ne comprend pas, on n'a d'autre choix que de gentiment dire à son auteur « merci m'sieur » et d'être dépendant de lui, donc moins libre et potentiellement plus vulnérable.
J'espère que, sur le plan médiatique, c'est ce message qui est passé.

---

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 ?

matthieu@ : Pas de commentaire sinon "Don't feed the Troll".

ajacoutot@ : Je laisse Marc Espie répondre à cette question, il connait bien le sujet.

ratchov@ : Formellement, ce qu'il dit est très juste: quand on ne vérifie pas la longueur de la chaîne avant de la copier, si on préfère qu'elle soit tronquée plutôt qu'elle ne déborde sur d'autres variables, alors il faut utiliser strlcpy().
Mais c'est pas du tout le problème ! Il faut, bien sûr, toujours vérifier la longueur de la chaîne avant de la copier. Le code de retour de strlcpy() permet de faire cette vérification très simplement alors que celui de strcpy() ne le permet pas et nécessite donc un appel à strlen() ou équivalent.
Autrement dit strlcpy() simplifie le code correct. Le code faux, reste faux quelle que soit la fonction qu'on utilise.
Peut-être des gens pensent qu'on utilise strlcpy() pour se dispenser de la vérification de la taille de la chaîne avant de la copier. C'est totalement faux.

---

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 ?

matthieu@ : Autant que je sache c'est indépendant. Le concept théorique est bien plus ancien que l'apparition de PaX et de W^X. C'est la difficulté d'implémenter ce concept sur l'architecture Intel en absence de protection en exécution par page qui bloquait. Les gens qui ont développé PaX et W^X se connaissaient et ont pu échanger des idées avant d'arriver à l'implémentation finale.

ajacoutot@ : En ce qui concerne W^X, Marc et Miod pourront répondre mieux que moi.
Pour le manque de reconnaissance je n'ai pas d'avis, mon besoin personnel de reconnaissance étant proche de "NULL" j'ai du mal à comprendre. Mais bon le monde de l'open source est rempli de gens à l'égo hypertrophié qui savent tout sur tout et qui souffrent d'être entourés de moutons tellement moins intelligents qu'eux…

Cela étant GRSecurity/PaX a été un très bon projet et un très bon moteur pour l'implémentation de processus de sécurité sous Linux, mais le problème est que les applications n'ont pas suivi, c'est à dire que tourner avec le patch GRSecurity « cassait » certains programmes et plutôt que de trouver un moyen de les corriger on conseillait aux gens de tourner sans le patch. En tout cas, c'était comme ça il y a quelques années…

---

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 ?

matthieu@ : en tant qu'administrateur système dans une partie de ma vie professionnelle ça m'embête un peu. C'est mitigé par le fait que même non supportée, une installation d'OpenBSD est tellement robuste qu'il n'y a pas de conséquences pratiques à ne pas upgrader à temps.
Et en plus une mise à jour d'un système OpenBSD est tellement simple et rapide que cela n'est malgré tout jamais vraiment problématique lorsque la mise à jour devient indispensable.
Je ne connais pas la solution miracle pour améliorer la situation à l'intérieur du projet : assurer un support sur la durée digne de ce nom demande énormément de ressources et de compétences.

ajacoutot@ : Moi je travaille avec OpenBSD et le marché de l'entreprise et le support d'un an me va parfaitement. J'ai connu beaucoup plus de problèmes avec des mises à jour sous Debian qui d'une version à l'autre transforme les 3/4 du système qu'avec OpenBSD. Je préfère mettre à jour plus souvent et par petits incréments plutôt que de passer le bulldozer tous les 3 à 7 ans.
Après chacun à son environnement de production spécifique qui s'adapte plus ou moins bien au rythme des mises à jour.

ratchov@ : Sachant que la mise à jour d'OpenBSD est très simple, demander aux gens de mettre à jour leur système tous les 6 mois n'est vraiment pas grand chose. Il ne faut pas oublier que nous, développeurs, utilisons OpenBSD en production, et qu'on est confronté aux problèmes de mises à jour. Cette façon de faire me semble très efficace.

---

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 ?

matthieu@ : C'est quelque chose qui resurgit régulièrement. Les distributions Linux majeures, Gnome (et X.Org) sont aujourd'hui développés essentiellement par des sociétés commerciales qui ont des objectifs de rentabilité financière à court-terme. Cela conduit d'une part à vouloir prendre la place de Microsoft comme monopole sur le marché et à éliminer des objectifs des projets tout ce qui n'est pas directement rentable (prise en charge d'architectures obsolètes, de systèmes différents, …).
En cela, ils ne se comportent pas de façon ni plus ni moins scandaleuse que Apple, Sun ou Microsoft. C'est juste que, comme le code est censé être libre, certains sont davantage frustrés des choix faits par ces entités.

Une fois de plus on voit que pour la notion de logiciel libre ait un sens, il faut que le développement soit fait avec la volonté explicite et forte de partage et de maintien d'une diversité. La licence ne suffit pas.

ajacoutot@ : J'interviens peu dans ce genre de blabla. Pour faire court, c'est toujours la même chose, certains linuxiens veulent remplacer Windows en adoptant ses même modes de fonctionnements (qu'ils dénoncent sous Windows mais trouvent normaux sous Linux).
À l'arrivée, la décision revient au projet GNOME, veulent-ils devenir un OS à part entière basé sur le noyau Linux, ou un environnement de bureau pour systèmes POSIX. C'est leur choix, s'ils souhaitent devenir Linux-only et bien nous migrerons vers d'autres environnement plus ouverts. Personnellement, j'utilise GNOME au quotidien, ainsi que cwm, openbox et fvwm. Dans le passé, j'ai utilisé pas mal KDE (1->3).
C'est aux projets finaux de décider s'ils veulent dépendre de telle ou telle technologie. Le lobbying de Lennart est compréhensible, il défend sa paroisse et visiblement n'a pas les compétences pour concevoir un projet multi-OS/plateforme sans que cela n'entrave sa créativité.

ratchov@ : D'une part je trouve que ce n'est pas souhaitable qu'OpenBSD ait toutes les fonctionnalités qu'a Linux (difficile à maintenir, choses plus urgentes à faire, inutile, moche, manque de temps, etc.)
Il se trouve que des programmes qui se veulent portables dépendent de ces « nouveautés » de Linux. Si ces programmes sont vraiment portables, alors cette dépendance devrait être optionnelle. C'est le cas de Xfce par exemple, où udev est optionnel.
J'ai suivi un petit bout de la discussion sur Xfce. Les développeurs ont choisi d'abandonner HAL, un framework qui leur semblait inapproprié, je trouve ça très bien. C'est certainement pour dégraisser et/ou améliorer Xfce, et si c'est le cas, alors le port OpenBSD ne pourra être que meilleur.

---

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

matthieu@ : Trouver des journées de 48 ou 96h pour arriver à avancer sur tous les chantiers en cours…

ajacoutot@ : Hmm… aucune idée. Je suis sûr que si je cherchais je trouverais bien quelque chose, mais là comme ça, rien d'évident ;-)

ratchov@ : Je ne changerai rien au process de développement ; il est simple, léger et efficace. Personne ne doit rien à personne. On ne perd pas de temps inutilement. Que demander de plus ?

Sur le plan technique, je rêve qu'un jour on se recentre un peu plus sur les fonctionnalités de base pour améliorer leur qualité ; et arrêter de s'épuiser en courant derrière des fonctionnalités sexy poussées par les constructeurs pour vendre toujours plus. Par exemple : j'utilise le serveur Xorg avec de l'accélération graphique et plein d'extensions, mais il n'est pas très stable, voire il ne marche même pas sur certaines machines. Je le troquerais volontiers contre un bête framebuffer, lent mais stable.

---

Questions spécifiques pour matthieu@

LinuxFr.org : Quelles sont les mesures spécifiques que prennent les développeurs OpenBSD pour sécuriser X ?

matthieu@ : On a introduit dans X quelques bouts de la méthode OpenBSD : audits de code (il y a eu des corrections faites également en amont dans XFree86 puis X.Org suite aux audits sur les chaînes de format ou encore sur la sécurité de l'utilisation des signaux), séparation des privilèges (dans xconsole, xterm, et le serveur X lui-même)…

Cela dit le serveur X reste un problème en matière de sécurité, principalement parce qu'il viole allègrement le principe de séparation entre le noyau et le mode utilisateur. À terme kernel mode setting (KMS) permettra de déplacer le problème, en ayant un serveur X non-privilégié.

---

LinuxFr.org : Le kernel mode setting va devenir de plus en plus indispendable avec les cartes graphiques modernes. Ou en est OpenBSD sur ce sujet ?

matthieu@ : On y travaille, mais ça ne progresse pas vite. Pour l'instant on a même plutôt fait l'inverse avec le pilote Intel : backporter la prise en charge de puces qui ne sont gérées qu'avec KMS dans Linux vers le mode UMS.
Ce qui coince avec KMS c'est que ça revient à transférer une grosse partie du code des pilotes X dans le noyau. Il faut éviter de créer des failles en copiant les erreurs et les bugs existant dans le code Linux.
KMS soulève aussi des questions de philosophie de gestion de la console : doit-on, comme le noyau Linux, passer la console en mode graphique au plus tôt possible lors du démarrage ou bien rester en mode texte VGA jusqu'au démarrage du serveur X ? Le mode graphique offre des avantages (moins de « clignotements » de l'écran dus aux changements de mode ; si le noyau crashe alors que X tourne, pas besoin de restaurer d'abord le mode texte pour pouvoir utiliser ddb, le débogueur noyau…), mais au prix d'une complexité pas évidente à gérer…
Par ailleurs, on voit bien avec KMS que la majorité des développeurs de X.Org ne s'intéressent qu'aux cartes graphiques les plus récentes et laissent tomber les utilisateurs de matériels plus anciens. Ainsi le fossé se creuse et les cartes plus anciennes ne sont en pratique plus prises en charge. Or elles ont encore des utilisateurs.

Même si on a dans le projet OpenBSD des développeurs passionnés par le support des matériels obsolètes, on n'a pas les forces nécessaires pour assumer toutes les défaillances des autres projets dans ce domaine.

---

LinuxFr.org : Quels sont les modèles de cartes graphiques à privilégier si on veut passer sous OpenBSD ?

matthieu@ : Dans le matériel récent, c'est pour l'instant sur les cartes Intel (à l'exception des GMA500/poulsbo) qu'on a les meilleurs résultats, suivi par les cartes AMD/ATI (Radeon r200 à r600).
Mais dans les 2 cas il faut éviter les toutes dernières générations.
Et surtout éviter au maximum nVidia, en particulier sur les portables. Le pilote "nv" ne gère pas correctement les cartes récentes, le pilote propriétaire n'existe pas pour OpenBSD (tant mieux ?), et le pilote "nouveau" n'a pas été porté et personne n'y travaille.

---

Questions spécifiques pour ajacoutot@

LinuxFr.org : Est-ce que tu peux présenter un peu sysmerge ? Quelles sont les différences avec mergemaster ?

ajacoutot@ : Première différence :
usage: mergemaster [-scrvhpCP] [-a|[-iFU]] [-m /path] [-t /path] [-d] [-u N] [-w N] [-A arch] [-D /path]
usage: sysmerge [-bd] [-s [src | etcXX.tgz]] [-x xetcXX.tgz]

Pour résumer, restons simples :-)
sysmerge(8) a démarré comme un fork de mergemaster. En gros, j'ai pris mergemaster, supprimé la plupart des options et n'ai gardé que 3 ou 4 fonctions (notamment les boucles utilisées dans la comparaison des fichiers). Tout le reste a été développé « from scratch » en m'inspirant de l'évolution de mergemaster, etcupdate et post-install (NetBSD) et etc-update (Gentoo).

Mon optique est de supprimer l'interactivité au maximum et je pense y être parvenu. La plupart des mises à jour d'une release à l'autre vont affecter une bonne vingtaine de fichiers sous /etc, /root et /var et la plupart du temps, seuls un ou deux fichiers demanderont d'être mergés manuellement (via sysmerge directement), parfois même aucun. Bien entendu je ne considère pas le développement comme achevé, j'ai encore quelques idées pour automatiser encore plus.

J'en profite pour mentionner une option souvent oubliée dans sysmerge : -b, aka batch mode. Elle est très utile lorsque l'on souhaite mettre à jour un parc de machines car sysmerge va alors mettre à niveau tout ce qu'il peut tout seul et sauvegardera les fichiers nécessitant une intervention manuelle. En scriptant cela et via ssh, on peut migrer de larges installations très facilement.

---

LinuxFr.org : Comme tu es le co-auteur de rc.d tu es sans doute bien placé pour porter un jugement sur les différents sytèmes d'init. Quelle est la philosophie du système d'OpenBSD ?

ajacoutot@ : Comme pour le reste : KISS.
$ wc -l /etc/rc.d/rc.subr
123 /etc/rc.d/rc.subr

On a voulu un système qui soit très simple dès le départ. Lorsque je regarde les autres systèmes d'init rc, la plupart des scripts sont gigantesques, certains illisibles (Debian) donc je me demande l'utilité première d'implémenter un framework…
Voici à quoi ressemble un script rc de base sous OpenBSD :

-------------------------------8<------------------------
#!/bin/sh
#
#{mathjax} OpenBSD`

daemon="/usr/local/bin/foobar"

./etc/rc.d/rc.subr

rc_cmd $1
-------------------------------8<------------------------`

On ne peut pas faire plus simple. Si un daemon demande l'ajout de paramètres par défaut, on rajoute simplement daemon_flags="-o blah" et c'est tout. Évidemment on peut outrepasser les options par défaut en rajoutant la ligne qui va bien dans /etc/rc.conf.local. Cette construction convient à 90% des daemons, pour le reste on peut changer les fonctions rc_start, rc_stop… directement dans le script mais cela reste l'exception.

Le parti pris est de créer un système simple et suffisant pour la majorité des daemons. Ensuite, si cela ne suffit pas c'est le script de démarrage lui-même qui doit être modifié dans le paquet et pas le framework.
Cela étant notre système est encore assez jeune et il évolue en fonction des paquets qui migrent d'un lancement statique avec rc.local vers rc.d.

---

LinuxFr.org : Est-ce que rc.d va gérer également le base system dans le futur ?

ajacoutot@ : Nous avons déja développé un patch qui fait cela. Après il faut qu'on en discute. L'implémentation actuelle (non committée) pour le système de base préserve le comportement historique, c'est-à-dire qu'aucune modification dans la façon de démarrer les daemons du système de base n'est nécessaire. Mais reste le problème du temps de démarrage. Sur un système moderne cela peut prendre jusqu'à une ou deux secondes supplémentaires ce qui pose problème pour les architectures lentes comme sparc… Donc on est en train d'étudier la possibilité d'éviter de forker un nouveau shell à chaque invocation d'un script rc et autres…
Ensuite, restera à convaincre les dinosaures du projet :-)

Donc pour résumer, c'est en cours mais rien n'est décidé.

---

LinuxFr.org : Est-ce que tu regardes les systèmes d'init des autres OS ? Est-ce que tu as un avis particulier sur systemd qui est présenté comme la septième merveille du monde ?

ajacoutot@ : Comme indiqué précédemment, oui je regarde les systèmes d'init des voisins.
En ce qui concerne systemd mon avis n'est pas tranché. Le problème est qu'il nécessite la modification des applications qui souhaitent l'utiliser, donc tant que les projets le rendent facultatif, tout est bien dans le meilleur des mondes. S'il devient d'une dépendance obligée, alors cela revient à retirer pas mal de programmes du « marché » pour les systèmes qui ne le supportent pas… et puisque son concepteur refuse d'intégrer des patches qui permettraient de le rendre portable (en théorie), on voit bien où cela mène.

D'un point de vue théorique, l'idée n'est pas mauvaise, c'est plutôt vis-à-vis de l'implémentation que je suis dubitatif. Mais mis à part avoir lu les docs sur le site du projet, regardé l'intervention de Lennard au FOSDEM et joué un peu avec sous Fedora, je n'ai pas plus poussé mes investigations. Repose-moi la question dans un an et j'aurai certainement un recul et une expérience un peu plus grande avec systemd pour pouvoir en parler.

---

LinuxFr.org : Tu es responsable, entre autres, du port GNOME. Comment vois-tu la transition vers la version 3 ? Est-ce que ça va poser des problèmes spécifiques à OpenBSD ?

ajacoutot@ : Le plus gros problème avec GNOME3 est que pour être pleinement exploitable il faut que gnome-shell soit fonctionnel, ce qui n'est pas le cas si le chipset graphique ne prend pas en charge l'accélération matérielle 3D et cela n'est en rien spécifique à OpenBSD. Je vois pas mal de gens qui se plaignent sur les listes de GNOME car ils sont contraints d'utiliser la session de « fallback » (sans gnome-shell et avec un ersatz de gnome-panel) qui est une vraie régression pas rapport à GNOME2 en terme d'ergonomie et de fonctionnalités.
Je mentionne également la décision idiote d'une minorité pour supprimer le menu pour éteindre la machine avec gnome-shell (en fait encore accessible via ALT+… mais bon). Cette décision pourrait se comprendre si l'on avait la certitude que quasiment tous les ordinateurs pouvaient suspendre ou hiberner mais ce n'est pas le cas, ni sous Linux ni sous BSD.

En ce qui concerne OpenBSD il y a plusieurs challenges. Tout d'abord, GNOME3 repose sur pas mal de choses que nous n'avons pas:

1. pam
2. udev (udisk, gudev)
3. comportement des utilitaires de gestion des utilisateurs (usermod…)
4. pulseaudio
5. passage de socket credentials via un message de control (SCM_CREDENTIALS / SCM_CDREDS via cmsg)
6. démarrage de plusieurs sessions X (pour la fonctionnalité de changement d'utilisateur (« switch user »)
7. locales
8. grantpt, ptsname et associés

\1. OpenBSD n'utilise pas pam pour l'authentification mais bsd_auth(3), hérité de BSDi (un BSD commercial n'existant plus). Cela nécessite un portage pour toutes les applications concernées (GDM, gnome-screensaver, …). J'en profite pour dire que certaines applications peuvent utiliser shadow au lieu de pam, mais là encore l'implémentation diffère entre les BSD et Linux, donc autant effectuer le portage vers bsd_auth(3). J'ai porté policykit dans cette optique.

\2. Là, rien à faire pour le moment. Landry (landry@), Jasper (jasper@) et moi-même avons commencé à discuter un peu de ce qu'il serait possible de faire afin d'avoir une fonctionnalité équivalente mais pour le moment rien en vue. Donc on patche les applications en conséquence.

\3. Avec l'arrivée de GNOME3 un nouveau daemon de chez fd.o a fait son apparition : accountsservice. Celui-ci est très centré autour de Linux, j'ai déja patché pas mal de code pour qu'il se comporte correctement sous OpenBSD mais il reste encore du travail. Cela étant ce n'est pas trop compliqué et j'ai bon espoir d'avoir un support complet sous peu.

\4. Ici aussi rien à faire pour le moment. Jasper et moi discutons de l'utilité de porter pulseaudio pour qu'il gère sndio(7), notre framework audio. Honnêtement, je ne comprends pas la décision de GNOME de dépendre sans condition de pulseaudio… du coup on patche en conséquence. Mais contrairement à udev dont on peut se passer pour le moment (on a d'autre moyen d'implémenter l'automount avec hotplugd(8)), pulseaudio est plus problématique car on perd la gestion audio sous GNOME (un peu chiant de devoir passer par la ligne de commande pour changer le son pour un environnement graphique) ainsi que les media-keys.

\5. Cela a été réglé. Eric (eric@) avait fait un patch pour contourner le problème et j'ai depuis travaillé avec upstream (glib) pour que g_unix_connection_send_credentials et g_unix_connection_receive_credentials utilisent g_socket_get_credentials si l'OS ne prend pas en charge de passer les droits dans un message de control.

\6. Limitation sous OpenBSD du fait de notre implémentation sécurisée de X.org. IIRC cela reste possible si l'on baisse le "securelevel" par défaut, mais cela n'est pas acceptable pour une question non seulement de sécurité mais également parce que sous OpenBSD on veut que ça marche sans avoir à bidouiller des fichiers dans tous les coins. Donc, on patche pour que le bouton de changement d'utilisateur n'apparaisse pas.

\7. On commence enfin à avoir une gestion des locales (unicode) qui tienne la route mais le voyage n'est pas terminé et il manque plusieurs utilitaires (e.g. localdef) dont GNOME peut tirer partie.

\8. Ces fonctions sont indisponibles sous OpenBSD pour des raisons de sécurité liées à une race condition. On a openpty à la place. Du coup pour le moment on perd le prompt du mot de passe dans gvfs, ce qui veut dire que l'on ne peut monter des "partages" sftp/ssh qu'avec une clef (e.g. sous nautilus ou les autres file managers utilisant gvfs).

Ensuite il y a évidemment toutes les petites choses classiques comme les fichiers qui ne sont pas installés au même endroit sous Linux et OpenBSD, le fait que les gens de GNOME adorent forcer les chemins dans leur code (e.g. /usr/bin, /usr/share…).

Voilà, j'espère avoir été relativement clair dans toutes ces réponses et donné aux gens l'envie de venir voir ce qu'il se fait chez les autres, c'est toujours instructif (et à mon avis essentiel) pour le développement en général.

---

Questions spécifiques pour damien@

LinuxFr.org : Quel est l'état du support des cartes Wi-Fi dans OpenBSD ? Comment est-ce que cela se compare avec Linux ?

damien@ : OpenBSD 4.9 contient deux nouveaux pilotes pour les clés USB Wi-Fi 802.11n de Realtek ainsi qu'un nouveau pilote pour les puces Atheros USB AR9271.
OpenBSD supporte donc aujourd'hui une grande variété de matériel Wi-Fi de différents constructeurs (Intel, Atheros, Realtek, Ralink etc…). Les clés USB Wi-Fi sont particulièrement bien supportées, il y a donc de grandes chances qu'une clé achetée au hasard soit reconnue par le système et fonctionne.
Comparé à Linux, il manque principalement à OpenBSD le support des cartes PCIe 802.11n de Broadcom et Marvell ainsi que des cartes PCIe 802.11n de Realtek que l'on trouve dans certains ThinkPad. OpenBSD ne supporte pas non plus le standard 802.11n. Bien que certaines parties soient déjà implémentées dans la pile 802.11 générique, il n'y a pas encore de support au niveau des pilotes.
Ceci dit, au vu des problèmes de stabilité et d'interopérabilité que l'on rencontre sous Linux avec les différents pilotes supportant le 802.11n, je dirais qu'il est urgent d'attendre que tout cela se stabilise un peu.
Il n'y a pas non plus de support de WPA-Entreprise ni des réseaux maillés (802.11s) dans OpenBSD. Le support du mode économie d’énergie manque aussi.
Dans une moindre mesure, le support du mode IBSS est aussi très limité, peu de pilotes le supportent et il n'y a pas de support du WPA dans ce mode.
Ayant récemment pris ma retraite d'OpenBSD, j’espère que d'autres développeurs (qu'ils viennent d'OpenBSD ou des autres BSD) reprendront le flambeau.

C'est un travail sans fin, les choses évoluent très vite, il y a sans cesse du nouveau matériel ou de nouveaux standards qui requièrent de nouveaux pilotes ou des ajustements aux pilotes existants. Il faut donc être très motivé, mais cela reste intéressant, on apprend beaucoup de choses. Ce fut pour moi une expérience enrichissante.

---

LinuxFr.org : Est-ce que tu ressens une amélioration sur le front des publications de specs par les constructeurs ? Qui sont les plus coopératifs et qui sont les moutons noirs à éviter ?

damien@ : Il n'y a eu aucune amélioration au niveau de la publication des spécifications matérielles par les constructeurs.
Par contre, ces derniers jouent de plus en plus le jeu de Linux (on l'a vu par exemple récemment avec Broadcom) et produisent des pilotes de meilleure qualité utilisant la pile 802.11 générique de Linux.
C'est évidemment une bonne base (en fait, souvent la seule) pour comprendre le fonctionnement du matériel.
Il n'y a plus vraiment de raison de privilégier un constructeur plutôt qu'un autre aujourd'hui. Le choix se fera donc principalement sur la qualité du matériel et la stabilité des pilotes. On pourra toutefois préférer (pour des raisons pratiques et/ou idéologiques) du matériel ne nécessitant pas de micro-logiciel (firmware) ou dont le micro-logiciel est librement distribuable, ce qui évitera l'installation de paquets externes au système.

---

Questions spécifiques pour ratchov@

LinuxFr.org : Est-ce que tu peux présenter sndio et aucat ?

ratchov@ : sndio est une API (une bibliothèque) que les programmes audio utilisent pour accéder au matériel audio ou aucat (cf. ci-dessous). La sémantique de sndio est très simple, ce qui permet de simplifier le code des programmes, avoir moins de bugs liés à l'audio, donc une meilleure stabilité.
aucat est le daemon audio d'OpenBSD. C'est une couche qui vient s'intercaler entre le matériel audio et les programmes. Pour résumer :

• Le daemon aucat ré-échantillonne et convertit le format des flux audio à la volée. C'est sa principale utilité : permettre à n'importe quel programme de fonctionner sur n'importe quel matériel.
• Plusieurs programmes peuvent utiliser le matériel simultanément, le serveur mixe la sortie de tous les clients et envoie le résultat au matériel. Leurs volumes individuels sont contrôlables par MIDI.
• Une carte son avec beaucoup de canaux peut être « découpée » en plusieurs petites cartes son indépendantes. Par exemple, un programme peut ainsi utiliser la sortie casque pendant qu'un autre utilise les haut-parleurs.
• N'importe quel programme qui sait enregistrer peut utiliser comme source le son qu'un autre programme joue.
• La carte son d'une machine peut être rendue visible sur une autre machine à travers le réseau.
• La latence est déterministe, fixée au démarrage. On peut utiliser le minimum théorique de ce type d'architecture, qui est de trois blocs.

En plus du partage du matériel, aucat permet aux programmes d'interagir entre eux, par exemple synchroniser plusieurs programmes, avoir une horloge MIDI commune. L'idée est de pouvoir utiliser plusieurs petits programmes simples pour achever une tâche complexe. C'est la philosophie d'Unix.

---

LinuxFr.org : Comment est-ce que cela se compare avec Pulseaudio ?

ratchov@ : Je connais très peu pulseaudio. Les fonctionnalités de base de pulseaudio et d'aucat se ressemblent quelque peu, puisque le besoin initial est le même. Je crois que la différence essentielle est dans leurs objectifs, le reste en découle.
Pulseaudio semble être une couche au dessus de ALSA/OSS, conçue pour enrichir le système audio. Il prend en charge beaucoup de codecs, des effets et semble bien intégré à GNOME/KDE. Il vient avec un programme graphique de contrôle du volume, etc.

À l'opposé, sndio est très minimaliste et se veut très proche du matériel ; certaines fonctionnalités ont été supprimées dans le but de simplifier tout le système audio. La principale fonction d'aucat est de gérer l'accès au matériel et de permettre aux programmes d'interagir entre eux. Aussi, il intègre bien le support MIDI.

---

LinuxFr.org : Où en est le support dans les applications audio présentes dans OpenBSD ?

ratchov@ : Actuellement il y a un peu de tout. De quoi écouter de la musique et regarder des vidéos, quelques programmes utiles aux musiciens, de la téléphonie, des jeux.
La totalité des programmes qui utilisaient l'ancienne API audio ont été convertis à sndio. Jacob Meuser a fait un travail énorme dans ce domaine. Certains programmes sont tombés en marche soit parce que des bugs ont été corrigés en simplifiant le code spécifique à l'audio, soit parce qu'aucat est venu combler une incompatibilité entre le logiciel et le matériel.

Il reste pas mal de code à retoucher. Mais les programmes audio sont de plus en plus déterministes.

Aller plus loin

• OpenBSD (195 clics)
• Sortie d'OpenBSD 4.9 (75 clics)
• Soutenir le projet (31 clics)
• OpenBSD-France (142 clics)