Pour ce qui est du noyau, demande l'avis de Reiser. Linux audite aussi le code
Je ne crois pas que l'auteur de la dépêche sous-entendait « à la différence des devs du noyau Linux, qui ne vérifient pas les patches », ce serait une contre vérité.
L'auteur dit « tout code dans le noyau ou le userland », et c'est le groupement des deux qui est significatif: lorsque le daemon bgp (userland) est maintenu et corrigé par l'un des devs principaux du stack tcp/ip du noyau (firewall et routage par ex.), ou le système de ports/package par un des mainteneurs de gcc/libc, et, dans l'ensemble, quand le userland est relu, audité, vérifié par les devs noyau, on peut dire qu'il y a une intégration robuste, une vérification attentive du code source, sans trop de zone d'ombres. À mon sens, ce « tout le code dans un même cvs » est vraiment une caractéristique importante, significative de la démarche des BSD.
À ce sujet, je voudrais compléter ma réponse à la remarque de Denis Bodor, qui nous soupçonnait désobligement d'élitisme gratuit, en indiquant ce qui fait que, passé la curiosité, je suis resté fidèle à OpenBSD comme un de mes systèmes favoris.
Je crois qu'on pourrait comparer OpenBSD à Debian (l'autre de mes OS favoris) parce qu'ils mettent tout deux le paquet (ha ha ha) sur la qualité, fût-ce au détriment de la tentation pour le dernier cri, et sont tout deux des projets militants ardemment pour le libre. Ce sont en somme des frères qui s'ignorent ;)
Mais ils ont une façon toute différente d'aborder la question de la qualité, c'est pourquoi la comparaison est intéressante (Debian représenterai ici les distros Linux, et OpenBSD les *BSD). Ce genre de comparaison permet de bien voir la différence de « culture » entre les deux familles d'OS, en deçà des objectifs communs:
* L'« unité de base de travail », si l'on peut dire, pour Debian est en gros le package ; pour OpenBSD ce serait plutôt le fichier/ligne de code source.
* L'outil central du projet (celui qu'on suit pour savoir ce qui se passe, dont on donne souvent les liens, où l'on voit ce qu'il y a a faire, dont les devs et même les utilisateurs suivent les changements etc.) est dans le cas de Debian, plutôt le bugtracker, dans le cas d'OpenBSD, le cvs. Par ex.: lors de la mise à jour d'un logiciel sous OpenBSD, de nombreuses personnes (y compris les simples utilisateurs) vont voir passer le commit sur le cvs et lire le source de la modif. Chez Debian cela se traduit plutôt, en pratique, par une mise à jour du package que des centaines de personnes vont tester et éventuellement commenter via le bugtracker.
* La méthode principale de QA (quality assurance), en simplifiant à peine, est pour Debian le testage intensif à grande échelle et la correction systématique des RC bugs ; pour OpenBSD, ce serait plutôt re-audit permanent du source, son "nettoyage" progressif, et l'intégration régulière, dans ce code, de nouvelles méthodes de renforcement.
* Les développeurs OpenBSD sont beaucoup moins nombreux. Mais ils sont tous développeurs au sens « qui écrivent (et surtout, lisent) du code ». Chez Debian, un développeur est surtout quelqu'un qui fait des packages. Mais chez Debian, les utilisateurs ont plus d'importance: la communauté est très vaste et efficace pour chasser les bugs, voir les corriger. Le nombre plus réduit d'utilisateurs d'OpenBSD ne permet pas de bénéficier de tests aussi intensifs avant les releases, ce qui impose une plus grande prudence sur les changements des sources des logiciels. Un exemple: les utilisateurs Debian sont invités à participer aux BSP (Bug Squashing Parties), où l'on chasse les bugs ; mais seuls les devs OpenBSD participent aux Hackatons (où l'on lis/écrit du code).
* Une attention égale, chez Debian, à tout les packages officiels (je veut dire qu'ils n'ont pas de bugs RC dans une release). Sous OpenBSD, le focus est intense sur le noyau et le userland de base (qui comprend quand même perl, un serveur smtp, un serveur web etc) mais les logiciels tiers (externes) en package sont moins attentivement surveillés.
* Sous OpenBSD, on préfère généralement se ramasser violemment (segfault en userland, panic dans le noyau) au moindre bug/comportement peu orthodoxe, rarement de « laisser couler tant que ça passe » (cf. l'utilisation de propolice, W^X, des "guard pages" à la electric fence activées par défaut, et dans une moindre mesure, de strlcpy/strlcat etc.).
* Une conception de la qualité qui, chez OpenBSD, donne plutôt préséance à la simplicité (init BSD, non utilisation des modules noyau, kernel générique ...) et chez Debian à la souplesse (support des situations très exotiques).
* En pratique, OpenBSD semble avoir une vocation moins « universaliste » que Debian. Par exemple si on bidouille sont kernel Open, on sort des clous et du système supporté. Ou autre exemple, un effort moindre pour intégrer tout les logiciels libres possibles sous forme de packages chez Open. Ou encore, une plus faible volonté de satisfaire tout les utilisateurs: dans tout les cas, OpenBSD donnera préséance à la cohérence et à l'unité (ne cherchera pas, par ex, à supporter quelque chose dont ils pensent que ça "bloaterai" un peu le système), quand Debian place le respect de ses utilisateurs -et donc de leurs besoins- au coeur même de sa « constitution ».
Donc voilà, s'il fallait confirmer ce que Denis Bodor dit plus haut, que certains BSDistes adoptent peut-être ces systèmes parce qu'ils sont moins grands publics, on devrait ajouter que ce n'est alors pas par élitisme anti débutant, mais plus souvent pour le plaisir de trouver des projets de plus petites taille, à dimension plus "humaine", ou plus "familliale", dont on peut facilement suivre les moindres changements, les hésitations, les petits pas audacieux, les bonheurs et malheurs, comprendre ce qui se passe, connaître les participants, etc. (ce que devait être Linux il y a quelques années, mais aujourd'hui: abonnez vous seulement à la LKML !).
Mais bien sûr je crois que le point important, exposé plus haut, c'est une affaire de goût: passée la curiosité initiale, on adoptera facilement un BSD si l'on est plutôt "cathédrale" que "bazar", plutôt intéressé par l'unité ou l'intégration/cohérence "anal retentive" que par la complétude, si on est plus en phase avec des projets sourcecode/cvs-centrics que packages/bugtracker-centrics, avec les petits pas prudents plutôt que les grandes révolutions suivis de long tests intensifs, par la rigueur un peu rigide plutôt que la souplesse peut-être un peu laxiste, par la méritocratie ferme (voir psychorigide et despotique) plutôt que la démocratie directe, par la beauté du code source plutôt que celle du système de packages ...
Ça fait un très long commentaire pour linuxfr, mais j'avais vraiment envie que les *BSD soient plus connus et mieux compris, après que la remarque de Denis m'ai irrité.
Pour finir: il ne faut pas croire qu'on choisisse *BSD à l'exclusion de (ou au mépris de) GNU/Linux ! On peut aimer et utiliser les deux systèmes. Si je compare plus haut les GNU/Linux et *BSD, ce n'est pas tant pour les opposer que pour montrer la cohérence et spécificité de leurs démarches respectives.
[^] # Re: Mouaip
Posté par herodiade . En réponse à la dépêche L'alternative BSD. Évalué à 10.
Je ne crois pas que l'auteur de la dépêche sous-entendait « à la différence des devs du noyau Linux, qui ne vérifient pas les patches », ce serait une contre vérité.
L'auteur dit « tout code dans le noyau ou le userland », et c'est le groupement des deux qui est significatif: lorsque le daemon bgp (userland) est maintenu et corrigé par l'un des devs principaux du stack tcp/ip du noyau (firewall et routage par ex.), ou le système de ports/package par un des mainteneurs de gcc/libc, et, dans l'ensemble, quand le userland est relu, audité, vérifié par les devs noyau, on peut dire qu'il y a une intégration robuste, une vérification attentive du code source, sans trop de zone d'ombres. À mon sens, ce « tout le code dans un même cvs » est vraiment une caractéristique importante, significative de la démarche des BSD.
À ce sujet, je voudrais compléter ma réponse à la remarque de Denis Bodor, qui nous soupçonnait désobligement d'élitisme gratuit, en indiquant ce qui fait que, passé la curiosité, je suis resté fidèle à OpenBSD comme un de mes systèmes favoris.
Je crois qu'on pourrait comparer OpenBSD à Debian (l'autre de mes OS favoris) parce qu'ils mettent tout deux le paquet (ha ha ha) sur la qualité, fût-ce au détriment de la tentation pour le dernier cri, et sont tout deux des projets militants ardemment pour le libre. Ce sont en somme des frères qui s'ignorent ;)
Mais ils ont une façon toute différente d'aborder la question de la qualité, c'est pourquoi la comparaison est intéressante (Debian représenterai ici les distros Linux, et OpenBSD les *BSD). Ce genre de comparaison permet de bien voir la différence de « culture » entre les deux familles d'OS, en deçà des objectifs communs:
* L'« unité de base de travail », si l'on peut dire, pour Debian est en gros le package ; pour OpenBSD ce serait plutôt le fichier/ligne de code source.
* L'outil central du projet (celui qu'on suit pour savoir ce qui se passe, dont on donne souvent les liens, où l'on voit ce qu'il y a a faire, dont les devs et même les utilisateurs suivent les changements etc.) est dans le cas de Debian, plutôt le bugtracker, dans le cas d'OpenBSD, le cvs. Par ex.: lors de la mise à jour d'un logiciel sous OpenBSD, de nombreuses personnes (y compris les simples utilisateurs) vont voir passer le commit sur le cvs et lire le source de la modif. Chez Debian cela se traduit plutôt, en pratique, par une mise à jour du package que des centaines de personnes vont tester et éventuellement commenter via le bugtracker.
* La méthode principale de QA (quality assurance), en simplifiant à peine, est pour Debian le testage intensif à grande échelle et la correction systématique des RC bugs ; pour OpenBSD, ce serait plutôt re-audit permanent du source, son "nettoyage" progressif, et l'intégration régulière, dans ce code, de nouvelles méthodes de renforcement.
* Les développeurs OpenBSD sont beaucoup moins nombreux. Mais ils sont tous développeurs au sens « qui écrivent (et surtout, lisent) du code ». Chez Debian, un développeur est surtout quelqu'un qui fait des packages. Mais chez Debian, les utilisateurs ont plus d'importance: la communauté est très vaste et efficace pour chasser les bugs, voir les corriger. Le nombre plus réduit d'utilisateurs d'OpenBSD ne permet pas de bénéficier de tests aussi intensifs avant les releases, ce qui impose une plus grande prudence sur les changements des sources des logiciels. Un exemple: les utilisateurs Debian sont invités à participer aux BSP (Bug Squashing Parties), où l'on chasse les bugs ; mais seuls les devs OpenBSD participent aux Hackatons (où l'on lis/écrit du code).
* Une attention égale, chez Debian, à tout les packages officiels (je veut dire qu'ils n'ont pas de bugs RC dans une release). Sous OpenBSD, le focus est intense sur le noyau et le userland de base (qui comprend quand même perl, un serveur smtp, un serveur web etc) mais les logiciels tiers (externes) en package sont moins attentivement surveillés.
* Sous OpenBSD, on préfère généralement se ramasser violemment (segfault en userland, panic dans le noyau) au moindre bug/comportement peu orthodoxe, rarement de « laisser couler tant que ça passe » (cf. l'utilisation de propolice, W^X, des "guard pages" à la electric fence activées par défaut, et dans une moindre mesure, de strlcpy/strlcat etc.).
* Une conception de la qualité qui, chez OpenBSD, donne plutôt préséance à la simplicité (init BSD, non utilisation des modules noyau, kernel générique ...) et chez Debian à la souplesse (support des situations très exotiques).
* En pratique, OpenBSD semble avoir une vocation moins « universaliste » que Debian. Par exemple si on bidouille sont kernel Open, on sort des clous et du système supporté. Ou autre exemple, un effort moindre pour intégrer tout les logiciels libres possibles sous forme de packages chez Open. Ou encore, une plus faible volonté de satisfaire tout les utilisateurs: dans tout les cas, OpenBSD donnera préséance à la cohérence et à l'unité (ne cherchera pas, par ex, à supporter quelque chose dont ils pensent que ça "bloaterai" un peu le système), quand Debian place le respect de ses utilisateurs -et donc de leurs besoins- au coeur même de sa « constitution ».
Donc voilà, s'il fallait confirmer ce que Denis Bodor dit plus haut, que certains BSDistes adoptent peut-être ces systèmes parce qu'ils sont moins grands publics, on devrait ajouter que ce n'est alors pas par élitisme anti débutant, mais plus souvent pour le plaisir de trouver des projets de plus petites taille, à dimension plus "humaine", ou plus "familliale", dont on peut facilement suivre les moindres changements, les hésitations, les petits pas audacieux, les bonheurs et malheurs, comprendre ce qui se passe, connaître les participants, etc. (ce que devait être Linux il y a quelques années, mais aujourd'hui: abonnez vous seulement à la LKML !).
Mais bien sûr je crois que le point important, exposé plus haut, c'est une affaire de goût: passée la curiosité initiale, on adoptera facilement un BSD si l'on est plutôt "cathédrale" que "bazar", plutôt intéressé par l'unité ou l'intégration/cohérence "anal retentive" que par la complétude, si on est plus en phase avec des projets sourcecode/cvs-centrics que packages/bugtracker-centrics, avec les petits pas prudents plutôt que les grandes révolutions suivis de long tests intensifs, par la rigueur un peu rigide plutôt que la souplesse peut-être un peu laxiste, par la méritocratie ferme (voir psychorigide et despotique) plutôt que la démocratie directe, par la beauté du code source plutôt que celle du système de packages ...
Ça fait un très long commentaire pour linuxfr, mais j'avais vraiment envie que les *BSD soient plus connus et mieux compris, après que la remarque de Denis m'ai irrité.
Pour finir: il ne faut pas croire qu'on choisisse *BSD à l'exclusion de (ou au mépris de) GNU/Linux ! On peut aimer et utiliser les deux systèmes. Si je compare plus haut les GNU/Linux et *BSD, ce n'est pas tant pour les opposer que pour montrer la cohérence et spécificité de leurs démarches respectives.