Blog d'un enthousiaste du logiciel libre, utilisateur de GNU/Linux et auto-hébergeant ses services Internet.

Faire de sa Fedora un système 100% libre

Fedora, comme la plupart des distributions GNU/Linux, contient une part (plus ou moins importante) de composants non-libres. Il s'agit la plupart de temps de micro-code nécessaire à certains drivers pour fonctionner correctement avec le matériel. Ces composants, bien que propriétaires, sont inclus par défaut dans Fedora car ils peuvent-être cruciaux, par exemple pour un utilisateur dont la connexion à Internet passe par un chipset WiFi demandant un blob. Ces bouts de code (que l'on nomme firmwares, ou blobs) peuvent-être présents dans le système sous la forme de fichiers séparés (que l'on trouve généralement dans /lib/firmware) mais il peuvent également être inclus au noyau (sous la forme de grands tableaux de chiffres présents dans le code source).

Vous vous demandez peut-être pourquoi je pense qu'il est important de ne pas utiliser ces petites parties de code (et donc de chercher à utiliser un système 100% libre). Mon argument principal est que, ces micro-logiciels contenant certaines instructions pour communiquer avec le matériel, le fait qu'ils ne sont pas libres est une entrave délibérée à la compréhension du fonctionnement interne du matériel. Je pense que de telles entraves ne sont pas admissibles. Alors bien sûr, lorsque j'ai vraiment besoin du matériel (par exemple d'un blob pour le WiFi, si c'est le seul moyen de connexion à Internet disponible), je vais m'en servir, parce-que je pense qu'utiliser une toute petite partie de logiciel non-libre me sera plus bénéfique que de ne rien faire, mais c'est un avis personnel. De plus, si on considère que beaucoup de schémas de l'électronique du matériel que l'on utilise ne sont pas disponibles, on peut également penser qu'il s'agit d'une entrave à notre compréhension du matériel que l'on utilise et que c'est inacceptable. Pourtant, j'utilise quand-même ce matériel.

Mais bien entendu, lorsque ces blobs non-libres ne sont pas ou peu nécessaires, il est meilleur d'utiliser un système 100% libre. Mais si votre machine contient du matériel pour lequel de tels blobs sont nécessaires, il ne vous sera probablement pas bénéfique d'installer un système 100% libre.

Si vous souhaitez savoir si votre matériel sera correctement supporté sans ces composants non-libres, il vous est possible :

Le matériel problématique sera le plus souvent : les cartes WiFi et certaines cartes graphique :

  • Les cartes ATI/AMD demandent, pour la plupart, un blob pour fonctionner correctement avec le pilote libre radeon
  • Les cartes nVidia ne requièrent aucun blob avec le pilote nouveau mais celui-ci est encore à un stade expérimental

Maintenant que tout ceci est dit, passons à la pratique. On va commencer par ajouter le dépôt du projet Linux-libre, contenant notamment un noyau sans blobs.

Toutes les opérations sont à effectuer sous l'utilisateur root :

# rpm --import http://linux-libre.fsfla.org/pub/linux-libre/SIGNING-KEY.linux-libre
# rpm -i http://linux-libre.fsfla.org/pub/linux-libre/freed-ora/freed-ora-release.noarch.rpm

On va ensuite recréer le cache de la liste des paquets :

# yum makecache

Le dépôt est maintenant installé et configuré. L'étape suivante consiste à lister tous les paquets non-libres installés sur le système. Le dépôt Linux-libre dispose d'un paquet entrant en conflit avec les paquets non-libres de Fedora. Pour l'installer :

# yum install freed-ora-freedom

YUM devrait échouer en listant les paquets créant le conflit. Par exemple :

--> Traitement du conflit : freed-ora-freedom-6-1.noarch entre en conflit avec microcode_ctl
[…]
--> Traitement du conflit : freed-ora-freedom-6-1.noarch entre en conflit avec xorg-x11-drv-ati-firmware
--> Traitement du conflit : freed-ora-freedom-6-1.noarch entre en conflit avec rt73usb-firmware
[…]
--> Traitement du conflit : freed-ora-freedom-6-1.noarch entre en conflit avec alsa-firmware

Pour les supprimer, on utilise la commande :

# yum remove *-firmware microcode_ctl

Pourtant, le paquet freed-ora-freedom ne pourra toujours pas s'installer. En effet, les paquets du noyau Linux (kernel, kernel-headers) entrent eux aussi en conflit : il s'agit du noyau Linux contenant des blobs. On va donc installer la version Linux-libre, qui ne contient pas ces blobs :

# yum install kernel-libre kernel-libre-firmware perf-libre

Il faudra ensuite redémarrer la machine et booter sur le kernel-libre (en le sélectionnant dans le GRUB). On vérifie que l'on a bien démarré sur le kernel-libre (cherchez -libre dans le nom du kernel) :

$ uname -r
2.6.35.11-libre.83.fc14.i686

Si tout c'est bien déroulé et que l'ordinateur reste utilisable, on peut supprimer les paquets du kernel d'origine :

# yum remove kernel

Il faudra penser à jeter un œil au fichier /boot/grub/menu.lst pour éventuellement y corriger les erreurs et s'assurer que le kernel-libre démarrera automatiquement.

Vous pouvez maintenant installer le paquet freed-ora-freedom, qui vous garantira qu'aucun paquet non-libre ne sera réinstallé :

# yum install freed-ora-freedom

Si le paquet kernel-headers a été installé, il sera nécessaire de le replacer par kernel-libre-headers pour l'installation de freed-ora-freedom :

# yum remove  kernel-headers

Les dépendances de kernel-headers seront supprimées : gcc glibc-devel glibc-headers libtool. On va maintenant installer kernel-libre-headers et les paquets précédemment supprimés :

# yum install  kernel-libre-headers gcc glibc-devel glibc-headers libtool

Il sera maintenant possible d'installer le paquet freed-ora-freedom.

Commentaires

Par : ANDRE Ani — Date : 16/03/2011 (08:33)

très bon article, intéressant.
ce serait bien s'il y avait plus de distros completement libre.

Par : Pierre — Date : 16/03/2011 (13:53)

"le fait qu'ils ne sont pas libres est une entrave délibérée à la compréhension du fonctionnement interne du matériel"
Je pense que tu es plus royaliste que le roi!

Ces microprogrammes sont utilisés en lieu et place de circuit électronique afin d'économiser les couts de production et de permettre la mise à jour du matériel (changer un fichier est plus simple que de changer de composants électroniques).

Réponse : Je sais bien, le problème est le même, que ce soit un firmware non-libre ou un circuit électronique dont les schématics ne sont pas disponibles. La petite différence est peut-être qu'il est plus facile d'intégrer des fonctions malveillantes dans un firmware que dans un circuit électronique. Cf : http://www.framablog.org/index.php/post/2011/02/02/debian-squeeze-firmware-libre. Et encore, si on parle de puces électroniques embarquées, ça revient au même.

Je préfère utiliser du matériel nécessitant des firmwares "fermés" que du matos plus cher avec plus de circuits intégrés mais sans firmware. Dans ce cas là, demander les plans au constructeur pour mieux comprendre le fonctionnement est illusoire et surtout non fondé. C'est pourquoi exiger des constructeurs l'ouverture des firmwares est, à mon sens, non fondé (contrairement à la fourniture de pilotes sous linux!)

Réponse : Si j'ai bien compris : demander les plans du hardware quand tout est dans des circuits intégrés c'est inutile. Je suis à peu près d'accord là-dessus. Je pense par contre qu'exiger l'ouverture des firmwares (à la fois ceux exécutés par les drivers et ceux présents dans les puces électroniques embarquées) présente un réel intérêt pour comprendre comment ça marche. Quoiqu'il en soit, le matériel pour lequel de telles spécifications sont disponibles est très rare et je préfère ne pas avoir cette liberté totale (de comprendre l'intégralité du truc) que de ne pas utiliser le produit.

Par : bochecha — Date : 17/03/2011 (11:07)

Merci pour le lien vers h-node, je me suis toujours demande comment faire pour savoir si j'avais besoin de ces blobs et si oui desquels.

Par contre, pour ce qui est de linux-libre, il y a une petite difference.

Le kernel de kernel.org ne contient aucun blob binaire [1], ils sont tous dans un git externe: linux-firmware. Sous Fedora, ils sont dans le paquet linux-firmware.

Si tu n'installes pas ces firmwares, le kernel ne les chargera pas. En revanche, s'ils sont installes, ils seront charges dynamiquement au besoin.

La ou linux-libre va beaucoup plus loin, c'est qu'il patche le code du kernel pour enlever cette fonctionnalite de chargement dynamique : meme s'ils sont installes ils ne seront pas charges. L'idee (selon Alexandre Oliva, dev de linux-libre) est que si le kernel essaie de charger ces blobs non libres, alors il incite l'utilisateur a utiliser du logiciel non libre.

Libre a chacun de se faire son opinion et de decider qui de kernel.org ou de Oliva a raison, la n'est pas la question (et je me garderai bien de lancer moi-meme un troll sur un blog ne m'appartenant pas). Neanmoins, il me paraissait important d'apporter la precision, au vu de la flamewar qui avait eu lieu sur LWN a ce sujet il y a quelques temps. [2]

[1] Je sais, il en reste encore dans le kernel upstream, mais c'est considere comme un bug. avid Woodhouse a entrepris de tous les sortir et les envoyer vers linux-firmware, et si ce n'est pas le cas actuellement, il suffit de se retrousser les manches et de lui donner un coup de main ;)

[2] http://lwn.net/Articles/413927...

Propulsé par Dotclear — Thème « PaulK »