>conformité aux normes légales (je pense en particulier aux cartes wifi ou aux puces gsm/3g ici)
Je peux très bien dépasser largement les réglementations en amplifiant le signal avec une boite de ricoré, doit-on interdire la vente de boite de ricoré ?
Les gens qui ont envie de ne pas respecter la loi, ce n'est pas un ridicule problème technique qui va les arrêter.
>un firmware a un accès très bas niveau au matériel, ce qui signifie qu'il peut potentiellement l'endommager (ou pire, endommager le matériel auquel il est connecté)
Bah ton noyau c'est pareil, il peu très bien cramer ton processeur s'il gère pas bien l'extinction en cas de surchauffe, ou pour prendre un exemple concret linux peu très bien te cramer un lecteur CDROM : http://forum.hardware.fr/hfr/OSAlternatifs/Logiciels-2/distr(...)
Donc si on suis ton raisonnement, filer les sources du noyau, c'est trop dangereux, il vaut mieux filer un blob.
>obstacles légaux : le code n'appartient pas forcément complètement au constructeur, il peut aussi y avoir des NDA sur certaines partie du matériel
Hola, faut savoir, je croyais que c'est tout petit ces blobs ? Tu vas pas passer par un prestataire externe pour une broutille qui fait 100 lignes de C.
> Bref, faut voir le firmware comme faisant un tout avec le matériel.
Dès lors que le matériel va offrir des fonctionnalités différentes en fonction de ce qu'on lui injecte en entrée, on peu pas prétendre que ça forme un tout.
>Maintenant, là où je critique la position de la FSF, c'est qu'elle est complètement hypocrite par rapport à ça. Prenons deux cartes, A et B. A possède sont firmware en RAM, B en flash. En dehors de ça, les deux cartes sont absolument identiques, le firmware est aussi le même.
Est-ce que l'on peu changer le firmware de A pour changer les possibilités de la carte ? Si oui, alors pourquoi est-ce qu'on s'en foutrais d'avoir les sources ? Dans le cas de B, faire des modifications est autrement plus complexe et risqué, et encore faut avoir les outils adéquates.
>Pour la FSF, un driver pour la carte A sera "mauvais", parce qu'il devra inclure un firmware non libre, ce qui lui fera déconseillé n'importe quel OS qui supportera cette carte. Il n'y aura en revanche aucun problème pour la carte B.
Bah oui, c'est la Free SOFTWARE Foundation, donc elle ne se préoccupe que de ce qui rentre dans le cadre du logiciel, logique. Si t'as pas moyen de modifier le fonctionnement d'un composant de manière logiciel, ça ne rentre pas dans le crédo de la FSF.
Cela étant je ne conspuerais pas sur une hypothétique Free Hardware Foundation qui en serait le pendant sur le matériel. Réclamer de façon systèmatique que les "sources" des circuits avec la documentation explicative soit fournie. Par exemple ça ferait baisser les probabilités de portes dérobés codés en dur.
>Mais au nom d'un idéal de "pureté" des distributions, on se retrouve à conseiller des cartes qui ne sont en aucun cas plus libre, mais par contre, elles seront assurément plus chères
Tu conseils ce que tu veux, la FSF elle conseille par rapport aux objectifs qu'elle s'est fixé, ou est le soucis ? Personne force qui que ce soit à suivre à la lettre les conseilles de la FSF.
>Au final, le libre et l'utilisateur n'y gagnent rien, superbe exemple d'aberration qu'on obtient quand on suit aveuglément une idéologie.
Je ne suis pas si sûr que toi, tu peux peut être dire que c'est des sales intégristes de merde, mais c'est comme ça qu'on en viens à la libération du code GL de X11 (via gnewsense), ou à des projets de matos libre. Et au final l'utilisateur, même celui qui se contre branle du libre, il y gagne.
>La position d'OpenBSD (on inclut les firmwares du moment que leur licence autorise la redistribution) est bien plus cohérente.
Chacun voit midi à sa porte. Un blob sera intégré ou pas selon où il sera mis (qui à dit DMC ?), moi ça paraît pas transpirer la cohérence à plein flots.
[^] # Re: Blobs et blobs
Posté par psychoslave__ (site web personnel) . En réponse au journal Le système que j'utilise est-il libre ?. Évalué à 0.
Je peux très bien dépasser largement les réglementations en amplifiant le signal avec une boite de ricoré, doit-on interdire la vente de boite de ricoré ?
Les gens qui ont envie de ne pas respecter la loi, ce n'est pas un ridicule problème technique qui va les arrêter.
>un firmware a un accès très bas niveau au matériel, ce qui signifie qu'il peut potentiellement l'endommager (ou pire, endommager le matériel auquel il est connecté)
Bah ton noyau c'est pareil, il peu très bien cramer ton processeur s'il gère pas bien l'extinction en cas de surchauffe, ou pour prendre un exemple concret linux peu très bien te cramer un lecteur CDROM : http://forum.hardware.fr/hfr/OSAlternatifs/Logiciels-2/distr(...)
Donc si on suis ton raisonnement, filer les sources du noyau, c'est trop dangereux, il vaut mieux filer un blob.
>obstacles légaux : le code n'appartient pas forcément complètement au constructeur, il peut aussi y avoir des NDA sur certaines partie du matériel
Hola, faut savoir, je croyais que c'est tout petit ces blobs ? Tu vas pas passer par un prestataire externe pour une broutille qui fait 100 lignes de C.
> Bref, faut voir le firmware comme faisant un tout avec le matériel.
Dès lors que le matériel va offrir des fonctionnalités différentes en fonction de ce qu'on lui injecte en entrée, on peu pas prétendre que ça forme un tout.
>Maintenant, là où je critique la position de la FSF, c'est qu'elle est complètement hypocrite par rapport à ça. Prenons deux cartes, A et B. A possède sont firmware en RAM, B en flash. En dehors de ça, les deux cartes sont absolument identiques, le firmware est aussi le même.
Est-ce que l'on peu changer le firmware de A pour changer les possibilités de la carte ? Si oui, alors pourquoi est-ce qu'on s'en foutrais d'avoir les sources ? Dans le cas de B, faire des modifications est autrement plus complexe et risqué, et encore faut avoir les outils adéquates.
>Pour la FSF, un driver pour la carte A sera "mauvais", parce qu'il devra inclure un firmware non libre, ce qui lui fera déconseillé n'importe quel OS qui supportera cette carte. Il n'y aura en revanche aucun problème pour la carte B.
Bah oui, c'est la Free SOFTWARE Foundation, donc elle ne se préoccupe que de ce qui rentre dans le cadre du logiciel, logique. Si t'as pas moyen de modifier le fonctionnement d'un composant de manière logiciel, ça ne rentre pas dans le crédo de la FSF.
Cela étant je ne conspuerais pas sur une hypothétique Free Hardware Foundation qui en serait le pendant sur le matériel. Réclamer de façon systèmatique que les "sources" des circuits avec la documentation explicative soit fournie. Par exemple ça ferait baisser les probabilités de portes dérobés codés en dur.
>Mais au nom d'un idéal de "pureté" des distributions, on se retrouve à conseiller des cartes qui ne sont en aucun cas plus libre, mais par contre, elles seront assurément plus chères
Tu conseils ce que tu veux, la FSF elle conseille par rapport aux objectifs qu'elle s'est fixé, ou est le soucis ? Personne force qui que ce soit à suivre à la lettre les conseilles de la FSF.
>Au final, le libre et l'utilisateur n'y gagnent rien, superbe exemple d'aberration qu'on obtient quand on suit aveuglément une idéologie.
Je ne suis pas si sûr que toi, tu peux peut être dire que c'est des sales intégristes de merde, mais c'est comme ça qu'on en viens à la libération du code GL de X11 (via gnewsense), ou à des projets de matos libre. Et au final l'utilisateur, même celui qui se contre branle du libre, il y gagne.
>La position d'OpenBSD (on inclut les firmwares du moment que leur licence autorise la redistribution) est bien plus cohérente.
Chacun voit midi à sa porte. Un blob sera intégré ou pas selon où il sera mis (qui à dit DMC ?), moi ça paraît pas transpirer la cohérence à plein flots.