Je ne crois pas que ce soit une bonne idée de reprendre Theo sur ce point, de surenchérir, de mettre Debian et OpenBSD en opposition.
D'une part, parce qu'il s'agit d'une invitation à réagir destinée à la collectivité au sens large, que cela concerne les utilisateurs de GNU/Linux autant que ceux d'OpenBSD, et que les utilisateurs de Debian se sentent probablement tout autant concernés, et sont plutôt les bienvenus pour se faire entendre auprès d'Intel. D'ailleurs, si bizarre que cela puisse paraître, si Debian accepte (provisoirement) ces firmwares illégaux, c'est justement parce qu'elle veut être plus radicale encore qu'OpenBSD, en refusant carrément les firmwares librement distribuables mais non libres & opensources (ce qui est une tache énorme, donc débattue et régulièrement repoussée, c'est pourquoi, pour le moment, rien n'est fait et on a donc paradoxalement quelques firmwares "illégaux" qui traînent encore).
Second point, il y a une incompréhension endémique entre ces deux mondes de développeurs. L'objectif des deux communautés est le même (pouvoir fonctionner sur le matériel actuel en gardant un système le plus libre possible), les stratégies et enjeux diffèrent légèrement.
Sur ce point de divergence, il faut rappeler que que « développeur » ne signifie pas la même chose dans « développeur Debian » et « développeur OpenBSD ». Le développeur Debian travaille plutôt à l'intégration, au packaging, à la correction/remontée de bugs et à la redistribution & upgrade de logiciels tier, le plus souvent développés par d'autres (ce qui les rend plus sensibles aux questions de procédure et redistributions, compatibilité de licences, d'où l'objectif du "tout, même les firmwares, libre et avec les sources" pour le moment bloquant mais plus radical que "tout libre, mais les firmwares peuvent être seulement redistribuables"). Tandis que la fonction principale d'un développeur OpenBSD est d'écrire du code, ce qui le rend plus sensible aux questions de documentation du matériel, aux NDA - qu'ils refusent radicalement - mais moins sensibles au besoin d'avoir les sources pour les firmwares : ils n'auraient pas le temps ni les outils ni les compétences pour modifier le code des firmwares, fussent-ils libres (et ils ont besoin de réagir tout de suite, quitte à être moins exigeants / plus pragmatique, contrairement à Debian qui peut se permettre d'attendre de trouver un consensus sur des exigences plus "idéaliste", car les firmwares sont déja là dans Linux et avec eux le support du matériel dans un kernel développé par d'autres).
De plus, comme dit plus haut, « The firmware problem is a Linux [kernel] problem, not a Debian problem » (car c'est en amont les devs. kernel qui incluent souvent ces firmwares dans le kernel vanilla, tandis que sous OpenBSD, les développeurs noyau sont les mêmes personnes que ceux qui font l'OS => problématique différente).
[^] # Debian, OpenBSD: objectifs convergents & petites diffs. conjecturelles
Posté par herodiade . En réponse à la dépêche Intel seulement open pour le business. Évalué à 8.
D'une part, parce qu'il s'agit d'une invitation à réagir destinée à la collectivité au sens large, que cela concerne les utilisateurs de GNU/Linux autant que ceux d'OpenBSD, et que les utilisateurs de Debian se sentent probablement tout autant concernés, et sont plutôt les bienvenus pour se faire entendre auprès d'Intel. D'ailleurs, si bizarre que cela puisse paraître, si Debian accepte (provisoirement) ces firmwares illégaux, c'est justement parce qu'elle veut être plus radicale encore qu'OpenBSD, en refusant carrément les firmwares librement distribuables mais non libres & opensources (ce qui est une tache énorme, donc débattue et régulièrement repoussée, c'est pourquoi, pour le moment, rien n'est fait et on a donc paradoxalement quelques firmwares "illégaux" qui traînent encore).
Second point, il y a une incompréhension endémique entre ces deux mondes de développeurs. L'objectif des deux communautés est le même (pouvoir fonctionner sur le matériel actuel en gardant un système le plus libre possible), les stratégies et enjeux diffèrent légèrement.
Sur ce point de divergence, il faut rappeler que que « développeur » ne signifie pas la même chose dans « développeur Debian » et « développeur OpenBSD ». Le développeur Debian travaille plutôt à l'intégration, au packaging, à la correction/remontée de bugs et à la redistribution & upgrade de logiciels tier, le plus souvent développés par d'autres (ce qui les rend plus sensibles aux questions de procédure et redistributions, compatibilité de licences, d'où l'objectif du "tout, même les firmwares, libre et avec les sources" pour le moment bloquant mais plus radical que "tout libre, mais les firmwares peuvent être seulement redistribuables"). Tandis que la fonction principale d'un développeur OpenBSD est d'écrire du code, ce qui le rend plus sensible aux questions de documentation du matériel, aux NDA - qu'ils refusent radicalement - mais moins sensibles au besoin d'avoir les sources pour les firmwares : ils n'auraient pas le temps ni les outils ni les compétences pour modifier le code des firmwares, fussent-ils libres (et ils ont besoin de réagir tout de suite, quitte à être moins exigeants / plus pragmatique, contrairement à Debian qui peut se permettre d'attendre de trouver un consensus sur des exigences plus "idéaliste", car les firmwares sont déja là dans Linux et avec eux le support du matériel dans un kernel développé par d'autres).
De plus, comme dit plus haut, « The firmware problem is a Linux [kernel] problem, not a Debian problem » (car c'est en amont les devs. kernel qui incluent souvent ces firmwares dans le kernel vanilla, tandis que sous OpenBSD, les développeurs noyau sont les mêmes personnes que ceux qui font l'OS => problématique différente).