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

Posté par (page perso) . Modéré par patrick_g.
60
8
juin
2011
OpenBSD

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

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
#
# $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.

  • # Merci

    Posté par . Évalué à 10.

    Merci pour les deux parties de cet entretien, les questions sont déjà intéressantes à la base, mais les questions sont plus pertinentes et complète qu'on aurait pu le craindre.

    Merci à tous les développeurs qui ont pris le temps d'y répondre. C'est vraiment intéressant. :)

    • [^] # Re: Merci

      Posté par . Évalué à 1.

      n'empêche on n'est pas sur openbsdfr.org ici...

      linuxfr c'était mieux avant ! ;)

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # ratchov@

    Posté par (page perso) . Évalué à 6.

    J'en profite pour signaler que ce monsieur est également l'auteur de midish qui est un ovni dans le monde de la mao. Midish est une sorte de séquenceur/filtre/routeur MIDI qui s'utilise comme un shell : ligne de commande, scripts, langage, variables...

    Même si vous n'êtes pas branché mao, je vous invite à regarder les concepts mis en œuvre, c'est très bien pensé, et d'une grande hackability.

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

  • # licence to troll

    Posté par . Évalué à -1.

    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.

    J'ai eu peur, j'ai cru que la GPL allée être comparée aux nazis (les vrais, pas ceux de l'interface ou de l'orthographe).

  • # Monopole de Linux

    Posté par . Évalué à 9.

    Cette interview met bien en évidence le conflit de philosophie entre le projet OpenBSD et Linux : d'un côté on veut prendre son temps et faire quelque chose de simple mais fonctionnel, de l'autre on rentre plus dans une course à la nouveauté.

    Si je comprends bien, la sécurité du projet OpenBSD provient surtout d'un ensemble de règles de bon sens : « garder un code simple et concis afin de pouvoir tracer son fonctionnement. » Il est évident qu'un code simple et clair est plus facile à sécuriser (car on comprend ce qu'il fait) qu'un plat de spaghetti.

    Par exemple, pour un novice comme moi, je suis plus à même à comprendre le code d'initialisation du noyau OpenBSD que celui de Linux.


    Linux gagne en popularité (ce qui est bien) et en ressources et laisse les autres systèmes sur le bas côté. Avec ce succès, que de plus en plus d'applications ne considèrent que ce système et font aussi l'impasse sur les autres.

    Ne se retrouvons nous donc pas dans la même situation du monopole de Windows où tous les constructeurs et éditeurs ne considèrent que ce systèmes car c'est là que se trouve l'argent ?

    Que Linux avance et « innove » est une bonne chose. Mais je pense qu'il ne faut pas oublier les autres et continuer à utiliser des interfaces standards sur lesquels ils pourront se connecter sinon cela reviendra au même que les systèmes propriétaires qui font tout pour restreindre les accès.

    Certes, le code est libre. Mais faciliter la tâche ne serait pas du luxe et de plus adapter un code fortement centré sur un système n'est pas une chose aisée comme on a pu le voir dans cette interview.

    • [^] # Re: Monopole de Linux

      Posté par . Évalué à 1.

      Tu as raisons, néanmoins OpenBSD propose un mode de compatibilité avec les binaires linux bien évidement.

    • [^] # Re: Monopole de Linux

      Posté par . Évalué à 3.

      Il n'y a pas de conflit. Ce sont juste deux OS qui prennent des directions différentes. Heureusement qu'il existe un OS comme OpenBSD pour les raisons que tu évoque (simplicité, solidité, sécurité…)
      Heureusement qu'il existe un OS comme */Linux pour innover rapidement, être performant et proposer plein de fonctionnalités (quitte à en payer le prix que tu évoque aussi). Par exemple pour les super-calculateurs, c'est typiquement un marché où OpenBSD n'a pas sa place (il ne supporte pas les machines multi-processeur si je ne dis pas de connerie ?).

      Pour les applications loin du noyau qui très difficilement portable sur un autre système que linux, je suis d'accord, c'est d'une bêtise sans nom.

      Please do not feed the trolls

      • [^] # Re: Monopole de Linux

        Posté par . Évalué à 4.

        si si tu dis bien une connerie, :) les SMP sont gérés par OpenBSD avec le noyau bsd.mp au lieu de bsd.

        • [^] # Re: Monopole de Linux

          Posté par (page perso) . Évalué à 6.

          Mais bien entendu, comme spécifié dans l'interview, c'est un Giant Lock qui est utilisé pour gérer les machines multiprocesseur donc l'exploitation de ces processeurs multiples est limitée.
          Clairement le coeur de cible d'OpenBSD n'est pas le marché des supercalculateurs.

          • [^] # Re: Monopole de Linux

            Posté par . Évalué à 1.

            Mais bien entendu, comme spécifié dans l'interview, c'est un Giant Lock qui est utilisé pour gérer les machines multiprocesseur donc l'exploitation de ces processeurs multiples est limitée.

            Seulement si tu passes beaucoup de temps en espace noyau, non ?
            Or, pour des calculateurs, il me semble que tout le temps CPU est (devrait être ?) passé en espace utilisateur.

            • [^] # Re: Monopole de Linux

              Posté par (page perso) . Évalué à 4.

              Ben avec des machines ayant un grand nombre de processeurs tu aura quand même des situations de compétition pour l'accès au noyau.
              Et je ne parle pas des autres problématiques comme par exemple les systèmes de fichiers pour cluster qui, je pense, n'existent pas dans OpenBSD.

              Je n'ai jamais rien vu nulle part concernant des supercalculateurs qui tourneraient sous OpenBSD.

            • [^] # Re: Monopole de Linux

              Posté par . Évalué à 0.

              Ces clusters echangent des donnees a travers le reseau constamment pour beaucoup --> interuption HW --> code noyau execute a chaque paquet qui arrive

              Et ce n'est qu'un exemple...

              • [^] # Re: Monopole de Linux

                Posté par (page perso) . Évalué à 4.

                Ces clusters echangent des donnees a travers le reseau constamment pour beaucoup --> interuption HW --> code noyau execute a chaque paquet qui arrive

                Je ne pense pas qu'une interface réseau émette une interruption pour chaque paquet.

                Pour info, Linux et FreeBSD permettent de désactiver les interruptions matérielle d'une carte réseau pour faire du polling à la place. Ceci permet de gagner en performance sur des cartes gigabits.
                http://www.linuxfoundation.org/collaborate/workgroups/networking/napi
                "Observe that when the NIC receives 890Kpackets/sec only 17 rx interrupts are generated."

                http://www.cyberciti.biz/faq/freebsd-device-polling-network-polling-tutorial/

                • [^] # Re: Monopole de Linux

                  Posté par . Évalué à 1.

                  Même ainsi je présume que la lecture des paquets ce fait par un appel système, non ?

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                  • [^] # Re: Monopole de Linux

                    Posté par (page perso) . Évalué à 2.

                    Non. Les applications vont toujours aller lire les données via des appels systèmes mais le noyau/driver fait le polling des buffers de la carte réseau indépendamment des appels systèmes émis par l'userland.

                    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                    • [^] # Re: Monopole de Linux

                      Posté par . Évalué à 2.

                      Ça ne change pas le problème à moins que le noyau écrive dans l'espace utilisateur. A chaque fois que l'appli veut savoir ce qu'il a reçu ou envoyé, le noyau doit arrêter son polling et il n'est plus possible d'écrire sur le disque dur etc.

                      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                      • [^] # Re: Monopole de Linux

                        Posté par (page perso) . Évalué à 2.

                        Uh ? Le noyau peut poller sur un CPU pendant qu'il traite l'appel système sur l'autre. Après si tu veux éviter de faire passer les données par l'userland tu as bien sendfile(2) (spécifique Linux).

                        En pratique pour OpenBSD je ne sais pas si cette parallélisation, le polling et l'aggrégation d'interruptions sont implémentés.

                        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                        • [^] # Re: Monopole de Linux

                          Posté par . Évalué à 2.

                          Le principe du BKL c'est d'empêcher deux threads en parallèle dans le noyau, ça a une incidence justement surtout quand tu as plusieurs unités de calcul.

                          Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: Monopole de Linux

                  Posté par (page perso) . Évalué à 2.

                  Et les cartes réseau qui sont censées être un peu performante font une interruption tous les X paquets si elles en reçoivent plus que Y par seconde. Ça évite de poller tout en limitant les interruptions.

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Monopole de Linux

      Posté par . Évalué à 2.

      d'un côté on veut prendre son temps et faire quelque chose de simple mais fonctionnel, de l'autre on rentre plus dans une course à la nouveauté

      Mmmmh, c'est un peu trop simple comme comparaison. Et puis, on peut tres bien faire du code simple et fonctionnel tout en innovant, c'est pas deux concepts opposes.

      Exemple recent: un bug dans une fonctionnalite git qui entraine de la perte de donnees, le mainteneur a refuse les patchs corrigeant le probleme parce que ca lui plaisait pas et qu'il faudrait refaire le tout en rearchitecturant un gros paquet de trucs.

      De loin ca ressemble a la philosophie BSD: refuser les hacks pas beaux et prendre le temps de faire les choses correctement. Mais pendant ce temps la, les donnees des utilisateurs sont corrompues (ooops). J'ai comme un doute que beaucoup de projets BSD laisse passer ca (un fix rapide sur la version courante et du boulot pour rearchitecturer pour la version suivante semble plus intelligent), mais je peux me tromper.

      Note: pour la fin de l'histoire, Junio n'utilise pas cette fonctionnalite, n'est pas impacte par le bug et donc n'en a rien a battre que ca soit corrige rapidement ou pas...

      Linux gagne en popularité (ce qui est bien) et en ressources et laisse les autres systèmes sur le bas côté.

      Pour bosser sur un projet qui tourne sur plein d'archis differentes, il est toujours seduisant d'oublier la portabilite et d'aller au plus facile. Prendre en compte les architectures et systemes differents, ca demande beaucoup de travail et beaucoup de temps. Je peux comprendre que certains ne veulent pas se lancer la-dedans.

      Apres, les commentaires condescendants lorsque tu proposes de faire le boulot de portage et les annonces qu'on refusera ton code de toute facon, je pense que quiconque bosse sur des systemes "mineurs" a deja vu ca au moins une fois. C'est heureusement assez rare, mais lorsque ca impacte les briques de basse du systeme le plus populaire, c'est tres tres embetant (Debian a teste avec la glibc, les BSDs en ce moment avec systemd, etc.).

  • # GPL v3 et GCC

    Posté par . Évalué à 2.

    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.

    Pourquoi seulement pour GCC ?
    J'ai regardé, Emacs et compagnies sont à jours et en GPL v3.

    Je n'est pas réussi à trouver la cause exacte.

    • [^] # Re: GPL v3 et GCC

      Posté par (page perso) . Évalué à 2.

      Parce que Gcc fait partie du système de base, alors que les autres sont optionnels (dans les ports).

      • [^] # Re: GPL v3 et GCC

        Posté par . Évalué à 1.

        Oui, mais en quoi la GPL v3 est-t-elle problématique ?

        • [^] # Re: GPL v3 et GCC

          Posté par (page perso) . Évalué à 8.

          Oui, mais en quoi la GPL v3 est-t-elle problématique ?

          Plusieurs des devs que j'ai interrogé pensent que la v3 est plus complexe donc moins utilisable que la v2. Voir par exemple la réponse de Miod dans la première dépêche.

          • [^] # Re: GPL v3 et GCC

            Posté par . Évalué à 1.

            Dans ce cas pourquoi il ne mettent pas GCC 4.6 dans les dépôts (en options) et laisser la 4.2.1 inclue dans la base ?

            • [^] # Re: GPL v3 et GCC

              Posté par (page perso) . Évalué à 4.

              Dans ce cas pourquoi il ne mettent pas GCC 4.6 dans les dépôts (en options) et laisser la 4.2.1 inclue dans la base ?

              Je ne sais pas pour Open mais FreeBSD propose GCC > 4.2.1 dans les ports (certains applis ne compilent qu'avec ça).

              Dans les faits ça ne pose pas de problèmes, tu as même des applis propriétaire installables via les ports (au grand damn de RMS).

              Si les gens veulent utiliser du proprio ou bien même de la GPL42 c'est leur problème.

              les pixels au peuple !

              • [^] # Re: GPL v3 et GCC

                Posté par . Évalué à 1.

                J'ai essayé les ports d'OpenBSD.
                Ils vont jusqu'à 4.3. Ce qui fait que je comprend encore moins...

                • [^] # Re: GPL v3 et GCC

                  Posté par . Évalué à 10.

                  Importer une nouvelle version de gcc, même dans les ports, n'est pas trivial. D'ailleurs le gcc 4 des ports ne fonctionne que sur un maigre sous-ensemble des plate-formes supportées par OpenBSD.

                  Et c'en est décourageant : la cadence des sorties de gcc s'accélère, ce qui est une bonne chose, mais les efforts faits pour ne serait-ce qu'accepter des patches pour les versions antérieures sont proches du zéro.

                  À force de s'entendre dire que son patch permettant de faire tourner gcc X.Y sous OpenBSD concerne une version qui n'est plus maintenue, les fichiers de configuration "officiels" de gcc pour OpenBSD sont un gigantesque poisson d'avril totalement inutilisables, et on passe notre temps à devoir adapter nos patchs, refusés pour cause d'obsolescense déclarée par le steering commitee, à la version du jour qui semble prendre un malin plaisir à tout chambouler.

                  Oui, je sais, tout ceci sonne comme du Calimero dans le texte. Si seulement ce n'était pas la dure réalité )-:

                  En même temps, OpenBSD, ce sont les méchants, ce n'est pas grave s'ils crèvent dans leur coin, de toute façon ils n'ont même pas systemd. (Hé oh, j'ai le droit, on est vendredi !)

                  • [^] # Re: GPL v3 et GCC

                    Posté par . Évalué à -1.

                    Importer une nouvelle version de gcc, même dans les ports, n'est pas trivial. D'ailleurs le gcc 4 des ports ne fonctionne que sur un maigre sous-ensemble des plate-formes supportées par OpenBSD.

                    Mouais, il suffi de faire comme ce qui a été fait pour GCC 4.3. C'est à dire, le mettre dans les ports, mais pas en version par défaut...
                    Ensuite, il faut juste mettre un commentaire sur le makefile, en disant comme quoi sur tel et tel plate-formes il ne marche pas.

                    En tout cas ça me semble bizarre qu'il ne soit pas supporté sur toutes les plate-formes vu que Debian et Gentoo on l'aire de bien fonctionner sur un grand ensembles de plate-formes.

        • [^] # Re: GPL v3 et GCC

          Posté par (page perso) . Évalué à 9.

          Oui, mais en quoi la GPL v3 est-t-elle problématique ?

          C'est expliqué dans la dépêche : on n'a pas réussi à trouver un bsdiste capable de la lire jusqu'au bout.

          les pixels au peuple !

          • [^] # Re: GPL v3 et GCC

            Posté par (page perso) . Évalué à 7.

            Encore moins un humain capable de la comprendre

          • [^] # Re: GPL v3 et GCC

            Posté par . Évalué à 2.

            En même temps c'est cohérent avec leur logique : ils préfèrent un code simple, donc préfèrent également une licence simple.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: GPL v3 et GCC

              Posté par . Évalué à 3.

              Oui c'est exactement comme ça que certains le présente. Trop complexe donc probablement buguée.

              Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: GPL v3 et GCC

          Posté par . Évalué à 2.

          La BSD donne totalement la liberté d'utilisation du code (tu peux en faire vraiment ce que tu veux y compris le "propriétariser", personne ne peut te demander quoi que ce soit), si tu veux vendre du hardware en restreignant la possibilité aux utilisateurs de changer le code qui tourne dessus par signature numérique (tivoïsation), la BSD et GPLv2 t'autorise à utiliser le code pour cette utilisation, pas la GPLv3.
          Ce n'est donc pas étonnant que les BSD-iste "préfèrent" la GPLv2 à la GPLv3: elle est moins contraignante et elle est aussi beaucoup plus lisible..

          • [^] # Re: GPL v3 et GCC

            Posté par (page perso) . Évalué à 1.

            Il y a a mon avis une raison de plus à ce que le projet OpenBSD n'aime pas la GPLv3.

            OpenBSD a forké apache lors de la sortie d'apache 2 sous licence apache 2. Le projet n'aimait pas du tout la licence apache 2 qu'il trouve discriminatoire (la clause antibrevet dit en gros et surement avec des grosses approximations fausses : si tu attaques des gens pour violation de brevets logiciels, tu as plus le droit d'utiliser ce code). Comme la GPLv3 est compatible apache 2...

    • [^] # Re: GPL v3 et GCC

      Posté par . Évalué à 2.

      C'est la license du GCC fourni avec le système de base qui pose problème. Les ports permettent d'installer des softs sous Gplv3.

      • [^] # Re: GPL v3 et GCC

        Posté par (page perso) . Évalué à 2.

        C'est la license du GCC fourni avec le système de base qui pose problème. Les ports permettent d'installer des softs sous Gplv3.

        Et alors ? (je m'interroge)

        les pixels au peuple !

  • # Malthusianisme

    Posté par (page perso) . Évalué à 7.

    En lisant les deux parties de ces entretiens, j'ai l'impression (j'ai dit impression hein) que les BSDistes passent encore plus de temps sur leurs commits que les hackers linuxiens.

    Il en ressort pour moi une impression de malthusianisme du hacker par manque de temps pour la reproductions.

    Vos moitiés acceptent facilement le temps investi pour la communauté? Partagent-elles cette passion? Qu'en est-il de la BSDiste dépourvue de chromosome Y? Ce patrick_g ne pose jamais les bonnes questions!

    Quoiqu'il en soit, je suis reboosté pour tester OpenBSD.

    Prochainement, je vous proposerais peut-être un commentaire constructif.

    • [^] # Re: Malthusianisme

      Posté par . Évalué à 5.

      Qu'en est-il de la BSDiste dépourvue de chromosome Y?

      Les anomalies génétiques c'est toujours terrible… Je suppose qu'il y a des structures plus adaptée que *BSD pour ces gens là

      Please do not feed the trolls

    • [^] # Re: Malthusianisme

      Posté par . Évalué à 2.

      Il en ressort pour moi une impression de malthusianisme du hacker par manque de temps pour la reproductions.

      Tu es sûr que tu ne veux pas plutôt parler de stakhanovisme ?

      • [^] # Re: Malthusianisme

        Posté par (page perso) . Évalué à 2.

        Tu es sûr que tu ne veux pas plutôt parler de stakhanovisme ?

        Certain.

        Le manque de temps vous empêchant de vous reproduire, je parle bien de malthusianisme. Mais je ne dis pas que le stakhanovisme ne s'applique pas également.

        Prochainement, je vous proposerais peut-être un commentaire constructif.

        • [^] # Re: Malthusianisme

          Posté par . Évalué à 2.

          J'ai eu beau me creuser la tête sur ton propos (entre deux séances d'arrachage de cheveux au boulot), j'ai du mal à comprendre sa logique.

          Je ne vois pas le rapport entre le temps consacré à contribuer à un projet libre, et s'interdire les plaisirs de la chair. Et vu le nombre de naissances au sein (ha, ha) des développeurs OpenBSD (3 par an en moyenne ces dernières années), je ne vois rien qui apporte de l'eau à ton moulin.

          En plus on n'est même pas trolldi...

          • [^] # Re: Malthusianisme

            Posté par (page perso) . Évalué à 1.

            Je ne vois pas le rapport entre le temps consacré à contribuer à un projet libre, et s'interdire les plaisirs de la chair. Et vu le nombre de naissances au sein (ha, ha) des développeurs OpenBSD (3 par an en moyenne ces dernières années), je ne vois rien qui apporte de l'eau à ton moulin.

            C'était une (mauvaise) boutade sur la gestion du temps. J'admire les gens qui ont le temps pour un boulot + (beaucoup) collaborer à un projet + une vie sociale. En relisant mon propos, c'est clair comme un matin d'hiver à Dublin.

            C'est ma malédiction personnelle, devoir mourir en expliquant jusqu'à mon épitaphe ;).

            Prochainement, je vous proposerais peut-être un commentaire constructif.

  • # Une bonne lecture

    Posté par . Évalué à 6.

    Bonsoir,

    Première chose, merci beaucoup pour les questions et l'initiative, et merci beaucoup aux développeurs pour leur réponses !

    Deuxièmement, les deux parties sont très bien, je les ai lues toutes les deux aujourd'hui (piouf ça prend du temps ;) ). Je ne connais pas plus que ça le monde des BSD, mais de ce que vous dites dans l'interview, je crois deviner que c'est OpenBSD qui me correspondrait le plus. De plus, cela a démonté trois "préjugés" que j'avais. A savoir l'aspect purement sécurité d'OpenBSD, que les *BSD ne fournissaient pas (ou peu) de ports en binaires (raison pour laquelle je ne suis jamais allé sur Gentoo et que j'ai fait mumuse avec LFS juste pour apprendre) et je pensais que les *BSD étaient plus compatibles entre eux que le laisse penser les réponses. Par contre, je confirme l'impression élitiste que vous dégagez, mais il semblerait que ce soit un effet pas vraiment désiré lié aux objectifs et contraintes que vous vous imposez.

    Pour finir, je suis sous Slackware depuis une dizaine d'années, pour le coté KISS et parce que cela me correspond bien (je trouve). Et j'avoue que je n'ai jamais testé de BSD. Et ces interviews m'ont données envie d'essayer OpenBSD et voir si je peux participer. Ce qui qui me fait tout de même un peu peur, je ne suis vraiment pas une bête en C/C++ et le processus de développement à l'air très exigeant... Sans parler de l'aspect temps qui est un autre problème.

    Bon, déjà, il faudrait que j'installe et teste pour voir. :D

    Merci les gars !

    • [^] # Re: Une bonne lecture

      Posté par . Évalué à 3.

      Pareil ici (surtout pour le 'merci'). Un petit mot sur l'installation, qui ne serait pas conviviale ou ergonomique c'est totalement faux. L'absence de GUI pour l'installateur ne rends pas celui ci moins convivial ou ergonomique. La première fois que j'ai installé un OpenBSD, j'ai dû rebooter parceque j'avais mal lu la manière de formatter le disque. Refaire UNE fois et une seule l'opération avant de la comprendre. On est très loin des questions absconnes de certains installateurs graphiques. Il n'est pas graphique mais il est très facile d'utilisation.

      Hop, moi aussi suis reboosté pour installer OpenBSD sur mon netbook, ça doit faire 5 ans que je n'avais pas touché à Open. (et non je n'irai pas poser de questions déjà documentée :p)

  • # s/OpenBSD/Arch Linux/

    Posté par . Évalué à 5.

    C'est marrant mais en lisant la partie sur rc.d, je me suis dit que OpenBSD pouvait être facilement remplacé par Arch Linux dans le texte :)

    • [^] # Re: s/OpenBSD/Arch Linux/

      Posté par (page perso) . Évalué à 9.

      C'est exact, j'ai oublié de préciser que l'on s'était inspiré d'Arch Linux pour notre implémentation rc.d. Le code est totalement différent, mais la façon de faire est globalement très semblable.

  • # GPL

    Posté par (page perso) . Évalué à 4.

    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.

    Pffff, toujours ce même bon vieux bullshit sur la GPL qui « forcerait » la main des gens.
    Hey ho, la GPL ne « force » que si on l'adopte, hein.
    Le coup de la comparaison démocratie "forcée" des US est donc complètement biaisée, et ça me fait bien marrer qu'elle soit énoncée entourée de pincettes, car le faux message passe quand même, en fin de compte.

    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.

    Lorsqu'on comprend qu'il ne s'agit pas de la liberté du programmeur mais de la liberté du logiciel, il n'y a plus de contradiction.

    • [^] # Re: GPL

      Posté par (page perso) . Évalué à 10.

      pfff désolé pour le ton agressif, ça n'apporte rien à la discussion, j'aurais dû me relire à froid :)

  • # Open vs Net vs Free

    Posté par (page perso) . Évalué à 1.

    Très sympa ces interviews ! Mon expérience avec BSD est assez limitée (j'avais installé FreeBSD il y a quelques années), mais c'est chouette de sortir un peu de Linux.

    Une chose sur laquel vous (les développeurs OpenBSD) semblez insister, c'est la qualité du code (et de la doc) d'OpenBSD. Sans vouloir lancer un troll de compétition, que pensez-vous des autres *BSD à ce niveau-là ? Est-ce une qualité partagé par les 3 projets ou est-ce spécifique à OpenBSD ?

    Il semble aussi que OpenBSD soit très utilisable sur un desktop/laptop. A ce niveau-là, comment se compare-t-il à Free/Net ?

    Dernière chose : vous dites encore utiliser CVS ? L'âge de l'outil ne se fait-il pas sentir ? Une migration vers quelque chose d'autre est-elle prévue ?

    • [^] # Re: Open vs Net vs Free

      Posté par (page perso) . Évalué à 3.

      Dernière chose : vous dites encore utiliser CVS ? L'âge de l'outil ne se fait-il pas sentir ? Une migration vers quelque chose d'autre est-elle prévue ?

      L'utilisation de cvs dans les BSD est historiquement liée au protocole cvsup qui sert à maintenir l'arbre des sources à jour sur les machines.

      OpenBSD utilise une version largement modifiée de cvs. Net BSD également me semble-t-il. FreeBSD utilise svn et cvs conjointement (afin de maintenir cvsup). Je pense que seul DragonFly à fait le choix radical de migrer totalement vers git.

      Au niveau de l'utilisateur final le changement n’apporte pas grand chose. J'ai même le sentiment que git est plus lent que csup lors de l'initialisation de l'arbre des sources.

    • [^] # Re: Open vs Net vs Free

      Posté par . Évalué à 2.

      La question ne s'adresse pas aux gens comme moi, je donne juste mon impression, avec un exemple.

      c'est la qualité du code (et de la doc) d'OpenBSD. Sans vouloir lancer un troll de compétition, que pensez-vous des autres

      Et uniquement sur la partie doc, et uniquement pour comparer à pas mal de linux :

      Chez OpenBSD, si tu te poses la question du support des divers modèles de cartes wifi broadcom, tu trouvera toujours une réponse unique : lis la doc Et la doc est limpide, elle ne parle que des cartes qui sont supportées. Voir ici. C'est clair, limpide : il n'y a rien de superflu, rien d'inutile.

      Cela ressemble un peu à la doc de Gentoo, en encore plus précise. (je prends l'exemple de gentoo car c'est la doc que je trouve loin devant les autres). Il y a des gens capables d'écrire ce type de page d'un trait d'un seul, et d'autres qui passent trente minutes à écrire du blabla et deux heures à factoriser ce blabla (malheureusement je fais aprtie de la seconde catégories). Il n'y a pas besoin d'en rajouter, franchement, non ? Au contraire de linux, souvent, où les docs se mutliplient, se chevauchent, se dédoublent, utilisent des vocabulaires différents. Bref souvent avec Linux les wiki et autres zigouigouis c'est souvent l'horreur. Alors que le support user_to_user peut se faire uniquement sur un forum, qui est prévu pour ça ; plutôt que de multiplier les entrées aprtout sous n'importe quelle forme : la doc, la vraie, elle est carrée et mainstream

      En plus, je sais pas pour vous, mais depuis que google.linux et google/bsd, il y a dix jours, ont disparus ça devient l'enfer pour trouver vite des infos :(

  • # Merci pour cet entretien

    Posté par . Évalué à 6.

    et merci aux développeurs qui ont pris le temps de répondre

    Moi je ne développe rien du tout, j'utilise

    Enfin je ne développe plus : je suis retraitée de l'info indus temps réel où on accepte pas les bugs sur les sites à risques , et donc personne ne se fachait que son code soit vérifié et critiqué par d'autres, au contraire. Et dans le temps réel l'ennemi c'est le temps d'exécution.

    Depuis quelques années le processus de développement de telles applications est soumis à des normes écrites ( une norme chapeau et une norme pae activité )et c'est tant mieux : il faut voir celà comme un support et non comme une contrainte, car avec l'expansion de ces systèmes, il n'était plus possible de transmettre des règles de développement par le "compagnonage", car au tout début de l'info indus c'était plutot artisanal, avec une ambiance sympa, et comme une famille à part de l'informatique conventionelle, un peu méprisée par les blouses blanches parce qu' on codait en assembleur, pour réduire le temps d'éxécution et que les mémoires ferrites n'étaient pas énormes.

    Aussi je me réjouis qu' OpenBSD fasse de l'audit de code.

    Ce que je trouve anormal est que les autres n'en fassent pas.

    Un jour je voulais me lancer dans la conf de mon firewall Linux, et je cherche de la doc sur internet, et voilà que je tombe sur la doc de packet filter.

    Ce fût mon premier contact avec OpenBSD.

    "Ou la la , mais dans le firewall Linux, il manque un paquet de trucs, et PF ça semble plus simple à configurer )"

    J'ai lu jusqu 'au bout. j' avais très envie de passer à OpenBSD, mais avec la réputation d' OS élitiste et austère qu 'il se trainait, j'ai différé mon passage à OpenBSD, perdant ainsi quelques années.

    Cinq ans plus tard , je me suis intéressée à la sécurisation de Linux, pour avoir un serveur sécurisé, non pas que les données que j'ai à y mettre soient confidentielles et précieuses mais ça ne me plairait pas que qqun vienne squatter dans mon PC mal protégé. Un peu comme lorsqu 'on est victime d'un cambriolage..

    J'ai commencé à regarder Gentoo hardened, et là un spécialiste de la question , me dit : "Attention, car le remède risque d'être pire que le mal.." Là aussi on se rend compte qu 'il manque pas mal de choses à Linux. Ce spécialiste n'avait pas tort, car c'est très compliqué à configurer.

    "Allons voir du coté des BSD".

    Encore victime de la rumeur, je me dis " commençons par FreeBSD, réputé plus simple".

    Là je me rend compte que beaucoup de choses sont optionnelles et que ça nécessite la recompilation du kernel. J'en ai fait pas mal avec Gentoo, mais ce n'est pas l'idéal lorsqu 'on débute avec un autre OS.

    Un exemple précis : le cryptage de la swap

    J'avais lu dans la présentation d'OpenBSD : " sécurisé par défaut"

    "Voyons voir si ça correspond à une réalité et sur quels points précis ça porte."

    Je commande mes CD et je lis la doc en les attendant.

    Là on s'aperçoit concrètement qu 'OpenBSD est très simple à installer, même si c'est en ligne de commande. Le ticket d'entrée n'est pas trop cher.

    Vraiment il n' y a aucune raison de frimer parce qu'on a installé OpenBSD.

    Un âne pourrait le faire en suivant la jaquette , s'il savait lire.

    " ah P***** enfin une seule doc à lire " comme chez "FreeBSD " j'en aurais rêvé sous Linux. ils en rêvent encore. Doc un peu technique , mais accessible.

    Enfin un OS qui s'installe rapidement et qui marche, c'est l'idéal et la condition sinequa non, pour le découvrir.

    En ce moment je pense à qqun qui s'emm grave avec ses deux Ubuntu ( U et K ) une ancienne et une nouvelle version, avec deux systèmes différents de numérotations de disques , bien sur l' ancienne version ne boote plus. Il est en train de chercher sa vieille Ubuntu dans ses partitions...

    OpenBSD un OS austère ?

    C'est ce qui vient tout de suite à l'esprit en voyant fwm quand on est habituée à KDE.

    Le temps de lire la doc de trouver un miroir et une demie heure plus tard j'ai mon KDE ( l'ancienne version parce que la nouvelle merci à part de la lourdeur pour quelques gadgets je ne vois pas ce que ça apporte ).

    Autre avantage , oublié les multiples dépots à configurer pour avoir ceci ou celà, après ça prend vingt minutes pour faire le tour pour installer un petit paquet..

    Les fonds d'écran d' OpenBSD, ne sont pas d'une gande qualité artistique ( ce n'est pas ce qu 'on leur demande non plus :)) ) je maîtrise plutot bien Gimp et je refais des fonds d'écrans à ma façon, ils ne respectent pas la charte graphique, aussi je ne les ai pas proposés, mais c'est aussi une belle démo de ce qu 'on peut faire avec Gimp, et je me suis lâchéee pour montrer que cet argument de distro austère pour ne pas passer à OpenBSD ne tient pas la route une seconde. et je maitrisais assez bien la conf de KDE 3 pour tout assortir aux couleurs du fond d'écran.

    Confiante dans mon nouvel OS, je me sens zen et j'attaque un sujet après l'autre. On lit la doc, on suit, ça marche. On est assez loin des distros ou sans se mortifier , point de salut.

    L'installation de nouvelles polices me semblait bien compliquée à ma première lecture de la doc : c'est un peu plus compliqué que de cliquer sur un bouton importer.. Mais je suis allée pêcher des polices, pour Mac ou Windows, ininstallables telles quelles avec KDE, et en suivant la doc d'OpenBSD à la lettre j'ai eu une belle collection de polices, pour faire des logos. De quoi faire une belle station de PAO, ce qui n'est pas la vocation première d' OpenBSD, mais au moins ça ne plante pas.

    Il n'y a rien de plus désagréable lorsqu 'on travaille sur une appli que de devoir sortir la caisse à outils.

    Un OS n'est pas une fin en soi, c'est tout de même fait pour travailler sur des applications.

    Puis j'ai découvert et testé les chflags et les secure level, qui pour moi sont un des grands plus des BSD, avec le fait qu 'ils n'utilisent pas la table des partitions DOS : une des plus grosses bévues de Linux( avec celle d'udev qui m'a passablement emm** avec une carte ).

    J'aime bien cette idée puisqu' on ne sait plus détecter les rootkits , faisons tout pour les empêcher de s'installer. Une solution globale et radicale, au lieu de mettre des cataplasmes les uns à coté des autres, au coup par coup..

    Quelque part : Oui c'est de l'artisanat d' Art.

    Dans ma comparaison des OS , il m'a semblé qu 'en matière de sécurité chez Linux on se dit : ça ne pourra jamais arriver, j'ai mis telle protection, alors que chez OpenBSD, plus réaliste, ils semblent dire : et si jamais ça arrivait

    Les partitions BSD je n'étais pas trop perdue, ayant utilisé et même eu l'occasion de générer un Unix proprio pour le développement de nos applis dans mon job ) à l'époque où le PC était encore un projet..

    C'est Linux qui s'est trompé c'est pas les BSD qui ont compliqué le partitonnement..
    Je comprend que ce n'est pas évident pour qui n'a connu que les PC..

    J'ai installé mon OpenBSD sur un disque entier : il mérite bien un disque pour lui tout seul.

    Une réinstall au bout de qq mois de découverte pour ré-équilibrer la taille des partitions et il a fallu un crash disque ( conséquence d'un déménagement ) pour le tuer.

    Ce qui change le plus avec OpenBSD quand on est habituée à Linux, c'est que ça marche tellement bien qu 'on s'ennuye parfois de ne plus avoir à ferrailler dans le système.

    Ca n'empêche pas de chercher à savoir comment c'est fait et pourquoi ils ont choisi telle option plutôt que telle autre.

    Autre chose que j'aime bien chez les OpenBSD, c'est qu 'ils n'ont pas pris le melon.

    Quand on va sur la mailing list , les questions et les réponses sont très techniques, et c'est pas trop l'endroit pour troller et passer des heures a discutailler sur les mérites ou les tares de telle distro. Ca peut sembler rebutant pour les nouveaux venus à Linux qui avaient le même avis sur Gentoo.

    J'étais en Europe du Nord lorsque j'ai commandé mes CD. Quelques mois plus tard je reçois une invitation pour une réunion OpenBSD. J'appelle : " je débute sous OpenBSD, je ne vous serais d'aucune utilité et je ne vais rien capter de vos discussions " "ca ne fait rien ! viens !" C'était un peu loin, et n'ayant pas de voiture, j'ai décliné l'invitation en attendant une réunion plus proche... car j'ai cru comprendre qu 'on allait pas rentrer de bonne heure, après avoir descendu quelques bocks de bière dans un bar.

    On le voit aussi sur les photos des rencontres , c'est simple , convivial et parfois festif.

    Mais au boulot , j'avais remarqué que les gens qui se prenaient trop au sérieux , c'est souvent pour cacher leurs lacunes ou un manque de personnalité. Quel ennui de refaire la réunion à table. Il faut savoir se lâcher, sans sombrer dans la grivoiserie non plus. J'aimais bien bosser avec les Suisses pour ça , après le boulot, on passe à autre chose. Ca permettait de relâcher le pression quand ça m*** et la solution tombait toute cuite le lendemain.

    Hélas j'ai du rentrer en France juste avant une sorte de woodstock organisé tous les quatre ans aux Pays-Bas et où débarquent les fans des pays voisins. Il faut des terrains immenses. C'est aussi très familial, les gens viennent avec leurs enfants (il y a une garderie, il faut les occuper ) On débarque avec sa tente, et son laptop si on en a un. Mais ça demande une sacrée logistique. Ce n'est pas non plus réservé aux OpenBSD-istes.

    Je regrette bien de ne pas avoir pu y aller : vélo remorque, l' occasion de faire une belle ballade sur plusieurs jours et de rencontrer physiquement d'autres utilisateurs d' OpenBSD et de bien rigoler aussi.

    Ca donne un sentiment d'appartenance à une famille, qu 'on a pas sous Linux avec ses multiples chapelles et les distros d'entreprises.

    Quand aux licences, pourquoi faire simple quand on peut faire compliqué ?

    Certes c'était pas une mauvaise idée de dire si qq un modifie le code, il doit le publier en GPL, mais c'est le plus sûr moyen de récolter un tas de m**** et de perdre la maîtrise et la cohérence du développement.

    Les applis qui me manquent sous OpenBSD , manquent aussi sous Linux.

    Ca concerne principalement la CAO et le développement pour l'embarqué : les fabricants de µ proc donnent souvent des outils pour Windows, prêts à l'emploi et quand il y en a pour Linux ils ne sont pas systématiquement gratuits non plus.

    Certes on peut faire pas mal de choses avec Linux, mais la productivité en prend un sacré coup. Il n' y a absolument rien de compatible avec les interfaces de debug sur le chip.

    FreeBSD proposait des applis de CAO, mais paquet bloqué à la compil, si on tente le déblocage , ça plante.. alors il faut attendre ou passer à Windows.

    Aujourd'hui je vois Linux , comme un entre deux, ce n'est ni un OS très convivial pour débutant comme Windows, ni un OS sécurisé et stable comme OpenBSD, je le trouve même un peu lourd.. Plusieurs fois j'ai eu des problèmes avec des mises à jour. Et un OS un peu trop chronophage.

    Je décrirais un Linuxien comme qqun qui piaffe d'impatience pendant trois mois à attendre la prochaine version et trois mois à essayer de la faire marcher..

    C'est une caricature, mais c'est ce que je vois souvent.

    C'est du en partie à la course entre distros pour sortir une nouvelle version avant les autres avec plein de nouveautés qui ne sont pas toujours au point.

    Cette compétition entre les BSD n'existe pas. Je vois FreeBSD et OpenBSD comme des OS différents. les autres BSd , je ne les vois pas du tout.

    OpenBSD peut être un fabuleux Desktop, mais je suis bien consciente que le windows manager et le navigateur apportent leur lot de vulnérabilités quel que soit l' OS utilisé ( je pense à une en particulier : le click jacking ) ce n'est pas la faute d'OpenBSD. Cependant avec un OS bien monté on peut en limiter les conséquences.

    Si j'ai besoin d'un serveur privé ouvert sur internet aux proches et amis, je sais que je peux le faire sans risques et sans me prendre le chou.

    Un grand bravo à tous les développeurs d' OpenBSD.

    .
    

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.