samedi 11 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Le projet Debian lance une consultation sur les firmwares non-libres

Posté par Lucas (page perso, ). Modéré le 29 août 2006.
0
Dans un message sur la liste de diffusion debian-devel-announce, le responsable du projet Debian, Anthony Towns, fait le point sur la présence de contenus non libres dans la section principale (main) de Debian, dont notamment les firmwares nécessaires à certains pilotes de matériel (modems usb, cartes réseau, wifi...).

Le principal problème qu'ils posent est le fait qu'il n'est actuellement pas possible d'installer Debian sur un système nécessitant un paquet (contenant un firmware) provenant de la section non-free de Debian. Cela remet en cause la sortie (prévue en décembre) de Debian Etch, à cause des modifications qui seraient nécessaires à l'installateur de Debian.

Toutefois, pour la première fois, le projet Debian s'ouvre à une double consultation : d'une part, classiquement, auprès de ses développeurs et d'autre part, auprès des utilisateurs (via un vote sur un forum). Les solutions possibles peuvent se résumer à :
  • Sortir Etch comme prévu, avec des firmwares non-libres dans 'main'
  • Sortir Etch comme prévu, mais sans les firmwares non-libres dans 'main'
  • Retarder la sortie d'Etch jusqu'à ce que les modifications nécessaires aient été faites dans l'installateur.

> Lire la suite (133 commentaires, moyenne: 3,1).   [dépêche : 660 caractères]

Il faut noter que, alors que des questions directes et à une seule réponse possible sont posées aux utilisateurs, il est demandé aux développeurs de classer les 3 options selon leur ordre de priorité. Il n'est donc pas possible de comparer directement les opinions des utilisateurs et celles des développeurs.

Il faut aussi remarquer que c'est la deuxième fois en quelques mois que le projet Debian se pose ainsi la question d'un compromis avec la liberté. Ainsi, en mars dernier, le projet avait décidé dans une résolution générale que les documents sous licence GNU Free Documentation License étaient libres s'ils ne contenaient pas de section invariante.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Et bien ...

Posté par jr lamoule (page perso, ) le 29/08/2006 à 06:16. (lien). Évalué à 4.

Je trouve qu'il est etonnant qu'ils ne se rendent compte que maintenant du probleme !
Debian a toujours ete plus que pointilleux concernant les questions de savoir si un composant de la distrib est libre ou pas. Il est quand meme enorme de passer a cote du fait que l'installateur limiterait les fonctionnalites disponibles en fin de compte a l'utilisateur a cause de son hardware....

Personnelement je serai plutot d'avis de repousser etch. Ca me semble etre la position la plus equilibree : d'un cote, debian gardera une distribution "libre", et de l'autre les utilisateurs pourront choisir en leur ame et conscience d'integrer des modules non libres sur leur machine.

Le choix de sortir Etch en l'etat n'aura qu'une consequence : au pire degouter les utilisateurs de linux, au mieux les pousser a choisir une autre distribution (qui a dit Ubuntu ? ). Et ensuite, les debianneux pourront continuer a cracher leur venin sur les autres distributions qui leur piquent des utilisateurs.

Enfin pour finir, je dois dire qu'il est triste de retarder la distrib juste a cause de l'installateur. Le plus simple n'est il pas de le laisser tomber au moins pour la release de etch, quitte a le reintegrer apres ? Je ne suis plus un debian-user mais je me souviens qu'a l'epoque l'installateur fonctionnait tres bien.

Quel que soit le pour et le contre...

Posté par Julien MOROT (Jabber id, page perso, ) le 29/08/2006 à 08:42. (lien). Évalué à 3.

je trouve dommage de se poser cette question seulement maintenant alors que la base a déjà été gelée pour la sortie de etch.
Si ça continue, les mêmes retards que pour la sarge risquent de se produire. Il aurait été plus judicieux de se poser la question au début du cycle de développement.

Une 4ème option ?

Posté par Sigmatador () le 29/08/2006 à 08:55. (lien). Évalué à 5.

Suis-je le seul à apprécier la politique d'OpenBSD: pas de blob point à la ligne ?

Si je devais transiger sur du closed source ca serait en user-land et certainement pas dans l'espace du noyau. Je ne vais surement pas faire tourner du code fermé et donc non-auditable en mode non protégé.

Sans parler du design souvent discutable de ces blobs (exemple du driver wifi intel qui réinvente 4 fois la roue alors qu'on aura bientôt (j'espère) la superbe pile devicescape)

Je sais c'est contraignant, pour l'achat de mon portable en trouver un ayant à la fois un chip graphique intel et un chip wifi atheros n'a pas été facile, mais vu la stabilité je ne changerai pour rien au monde (enfin si mais quand les futurs chip intel g965 et chip atheros 802.11n seront sortis ^^)

Le problème c'est qu'avec le succès de la plateforme centrino, ca va devenir très dur de trouver autre chose que du intel en chip wifi intégré. Donc si le travail d'ingénieurie inverse et de redesign complet du driver wifi intel commencé pour OpenBSD 4.0 pouvait inspiré Linux ca serait vraiment une bonne chose.

Plus d'info:
http://linuxfr.org/~patrick_g/21744.html

mon humble avis

Posté par karmatronic () le 29/08/2006 à 08:57. (lien). Évalué à 1.

personnellement,je ne suis pas d avis de retarder le lancement de la nouvelle release,et plutot surpris que cette option soit envisagée:
c est le plus gros reproche fait á Debian ces dernieres annees que celui de ces incessants retards et si je comprends qu on retarde une sortie pour des raisons de sécurité ou de fiabilité,le "dogmatisme" est un mauvais motif,et qui discrédite linux en géneral.
bon je reste evidemment grand fan de debian,la meilleure distrib,et de loin :)

Juste histoire de ...

Posté par Pierre Habouzit (page perso, ) le 29/08/2006 à 09:39. (lien). Évalué à 10.

Le mail en question (du DPL) occulte complètement le fait que des réflexions sont en cours, au niveau des développeurs, et que une GR est en préparation sur le thème des firmwares.

L'annonce du DPL se moque complètement de ces propositions, et ne les évoque même pas. On les trouve ici:

http://lists.debian.org/debian-vote/2006/08/msg00032.html
http://lists.debian.org/debian-vote/2006/08/msg00215.html
http://lists.debian.org/debian-vote/2006/08/msg00185.html


Ce sont ces propositions qui vont déterminer quel sera le futur de Debian vis à vis des firmware, et pas le pseudo-poll proposé dans l'annonce.

Ce mail sur debian-devel-announce@l.d.o est une man½uvre populiste, qui reflète largement un état de conflit intense interne à Debian, et il serait maladroit de s'en féliciter. Sans parler du fait que n'importe quel développeur peut faire des annonces sur d-d-a et que ceci n'est pas nécessairement un statement du projet.

--
Pierre Habouzit <madcoder@debian.org>

Pondération

Posté par herodiade () le 29/08/2006 à 09:43. (lien). Évalué à 10.

L'idée que Debian puisse envisager un « compromis avec la liberté » pourrait décevoir certains, mais il ne faut pas surévaluer le problème : il ne s'agit pas de rendre Debian peu à peu non libre, ou de commencer à intégrer n'importe quel logiciel dans main.
En fait le cas des firmwares est spécifique, pour au moins trois raisons :

1) Le cas des firmwares est spécifique. Il s'agit de code qui ne tournera pas sous l'OS (sous Linux), ni même sur le CPU principal, mais dans le matériel ; les problèmes habituels des drivers proprios : de sécurité (backdoors etc.), d'évolution de l'OS (freinée par les drivers propriétaires), de stabilité du système (fragilisée), de maintenabilité etc. ne se posent pas spécifiquement. Lorsque vous achetez (ou vendez) un ordinateur domestique, il contient généralement une foultitude de tels firwmares déjà intégrés dans le matériel. Tout le monde s'accommode de ça, faute de choix (achèteriez vous un PC sans son bios ?) ; mais de nos jours, pour économiser une peu de ROM, les fabriquants préfèrent de plus en plus fréquemment que les firmwares soient chargés dans le matériel à la volée par l'OS plutôt qu'intégrés d'emblée dans une puce.
Cette proposition ne se résume donc pas a un « nous voudrions faire admettre n'importe quel logiciel non libre dans main, celui-ci est un candidat parce qu'il est très utile ». Pour preuve, si l'acceptation des firmwares est proposée, ce n'est pas le cas pour les drivers non libres (nVidia, ATI, ...).
En somme, on pourrait comparer la problématique des firmwares à celle des images plutôt qu'à celle des logiciels : on (les distros Linux, le site gnu.org, Wikipédia ...) ne refuse pas d'intégrer une image sous prétexte qu'elle n'est pas fournie avec ses fichiers « sources » de développement (PSD Photoshop, XCD Gimp, photos initiales ...), ce qui importe c'est le droit de réutilisation et redistribution (et éventuellement modification).

2) En pratique, outre la question de l'utilisabilité d'un OS sans les firmwares adaptés au matériel, un autre problème se pose pour Debian : le fait d'enlever les firmwares binaires du kernel demande beaucoup de ressources et de temps, des compétences précieuses (devs. kernel) et c'est une opération a réitérer à chaque mise à jour. En bref, cette tache ralentie fortement le projet. Par exemple le choix du kernel d'Etch (2.6.17 ou 2.6.18) est fortement subordonné à cette question (pas le temps d'intégrer 2.6.18 s'il faut enlever les firmwares avant de le tester dans sid).

3) Le code source des firmwares en question serait probablement bien souvent inexploitable avec les outils (la toolchain) GNU car les microgiciels sont souvent développés avec des environnements de dev. propriétaires (donc quand bien même nous disposerions des sources, nous ne pourrions pas facilement construire les packages binaires à partir d'elles, c'est le fameux « ftbfs »).

La question fréquemment évoquée à ce sujet est celle de l'utilisabilité d'un OS qui ne peut pas s'installer sur son contrôleur SCSI (ou SATA, RAID ...), ou qui ne peut pas initialiser les cartes réseau, à une époque où les firmwares externes (chargés par l'OS) deviennent la nouvelle norme. Vous voyez, ce n'est pas la seule question à se poser.