> les questions à se poser tout de même par rapport aux blobs fournis dans le kernel, avant de les virer maladivement sont:
Tu parles de blobs. Mais il y a deux types de blob. Ceux exécutés par le noyau (ou l'OS de façon plus large) et les blob qui sont chargés sur un périphérique et exécuté par le périphérique. Pour ce dernier cas, c'est un firmware.
Même en tant que "libriste", j'ai très peu de problème avec les blob-firmware. Pour moi l'OS est libre (tout proprio que soit le hardware et les périphériques qui utilisent des firmwares chargés par le noyau). Mais la distribution ?
Il y a problème pour la distribution. Le problème se pose lorsque, par exemple, tu conseilles une distribution et dis qu'elle est libre (ce qui veut dire que TOUS les sources (y compris les firmwares) sont disponibles). Ben s'il y a un blob-firmware, elle n'est pas libre. Donc il y a tromperie sur la marchandise. C'est emmerdant car c'est moche d'utilise le mot "libre" pour manifestement quelque chose qui ne l'est pas (je n'évalue pas le problème, je dis seulement qu'il y a problème).
> - est-ce qu'il existe réellement un code source...
Si le firmware n'est pas vraiment un blob (par exemple le développeur utilise un éditeur hexa (ça arrive) et il y a la doc), il n'y a pas de problème.
Mais il y a des vrais blog-firmware (qui sont aussi dans Linux vanilla). C'est ici que le problème ce pose (où commence).
La tendance globale (mais non ferme) que je perçois est qu'il faut que ce problème soit pris en compte en upstream. Attention, je ne dis pas que l'upstream va virer les blobs. Mais l'upstream doit faire le nécessaire pour permettre de facilement faire des versions de Linux sans blob. Ceci étant maintenu par l'upstream. Après c'est aux distributions de décider si elles veulent ou non intégrer les blob-firmware.
> - dans le cas où un code source existerait, est-il possible de mettre en œuvre une chaine de compilation pour ces éléments sans faire exploser la complexité de la compilation du noyau?
Je ne vois pas où tu veux en venir. On ne va pas demander au noyau de compiler le firmware. On veut qu'il y ait les sources. On n'interdit pas l'existance du blob (qui peut-être compilé ailleurs).
[^] # Re: toujours cette maladie...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 4.
Tu parles de blobs. Mais il y a deux types de blob. Ceux exécutés par le noyau (ou l'OS de façon plus large) et les blob qui sont chargés sur un périphérique et exécuté par le périphérique. Pour ce dernier cas, c'est un firmware.
Même en tant que "libriste", j'ai très peu de problème avec les blob-firmware. Pour moi l'OS est libre (tout proprio que soit le hardware et les périphériques qui utilisent des firmwares chargés par le noyau). Mais la distribution ?
Il y a problème pour la distribution. Le problème se pose lorsque, par exemple, tu conseilles une distribution et dis qu'elle est libre (ce qui veut dire que TOUS les sources (y compris les firmwares) sont disponibles). Ben s'il y a un blob-firmware, elle n'est pas libre. Donc il y a tromperie sur la marchandise. C'est emmerdant car c'est moche d'utilise le mot "libre" pour manifestement quelque chose qui ne l'est pas (je n'évalue pas le problème, je dis seulement qu'il y a problème).
> - est-ce qu'il existe réellement un code source...
Si le firmware n'est pas vraiment un blob (par exemple le développeur utilise un éditeur hexa (ça arrive) et il y a la doc), il n'y a pas de problème.
Mais il y a des vrais blog-firmware (qui sont aussi dans Linux vanilla). C'est ici que le problème ce pose (où commence).
Il y a ici un long thread sur ce problème :
http://www.redhat.com/archives/fedora-devel-list/2008-March/(...)
La tendance globale (mais non ferme) que je perçois est qu'il faut que ce problème soit pris en compte en upstream. Attention, je ne dis pas que l'upstream va virer les blobs. Mais l'upstream doit faire le nécessaire pour permettre de facilement faire des versions de Linux sans blob. Ceci étant maintenu par l'upstream. Après c'est aux distributions de décider si elles veulent ou non intégrer les blob-firmware.
> - dans le cas où un code source existerait, est-il possible de mettre en œuvre une chaine de compilation pour ces éléments sans faire exploser la complexité de la compilation du noyau?
Je ne vois pas où tu veux en venir. On ne va pas demander au noyau de compiler le firmware. On veut qu'il y ait les sources. On n'interdit pas l'existance du blob (qui peut-être compilé ailleurs).