Marc SCHAEFER wrote:
On Wed, Jul 26, 2006 at 11:26:25AM +0200, Thierry de Coulon wrote:
Mais si on veut absolument que tout utilisateur Linux devienne un
administrateur serveur... on continuera a avoir une situation ou même quand
un fabricant a la gentillesse de proposer un driver il faut d'abord aller
suivre un cours pour être capable de l'installer.
Je m'insurge contre l'idée que les pilotes doivent être téléchargés par
l'utilisateur du serveur WWW ou FTP du fabricant du matériel. Le
fabricant n'a pas les connaissances d'intégration système -- ni même de
GNU/Linux de base -- pour produire quelque chose de qualité suffisante,
et on voit bien en pratique ce que cela donne.
Les pilotes devraient être installables automatiquement depuis la distribution,
de manière testée et intégrée. C'est d'ailleurs ce qui se fait pour la
plupart du matériel aujourd'hui. L'utilisateur n'a pas du tout
besoin d'être administrateur, la distribution se chargeant de ce travail
coûteux et répétitif -- tant que l'utilisateur ne casse pas cette belle
harmonie en installant n'importe quoi n'importe comment.
Mais comment faire cela ?
Le monde idéal:
- les fabricants de matériel s'arrangeraient avec les développeurs
(kernel, X, etc) pour intégrer le pilote *libre* assez tôt avant
la vente du produit matériel. Ils pourraient aussi définir des
standards de communication rendant l'utilisation de pilotes génériques
efficace plutôt qu'un pilote par matériel. Cela fonctionne très
bien par exemple pour tout ce qui est stockage USB. Un seul pilote
générique.
le monde réel:
- les fabricants de matériel produisent des pilotes de qualité
insuffisante, en propriétaire, en ne supportant qu'une plateforme
processeur et ne respectant pas les standards minimaux de packaging,
cela produit des bugs que les distributions et les développeurs
libres doivent corriger à leurs frais sans disposer des
informations nécessaires, voire en violant les termes de la licence
lorsqu'ils veulent faciliter l'installation aux utilisateurs. Les
fabricants ont tendance, plutôt qu'à utiliser des méthodes compatibles
d'accès, à brouiller les pistes et rendre la situation plus complexe.
Quand ils en auront assez de sortir des paquetages avec les modules
compilés pour chaque version du noyau sur chaque distribution (je me
souviens avoir croisé un site avec ce genre de drivers pour des cartes
HBA, peut-être une 30aine de versions sur la même page), ils feront
peut-être du libre.
Il est clair que c'est difficile pour le client de comprendre
l'intérêt d'un pilote libre pour son matériel quand le pilote
propriétaire est téléchargeable sur le site du constructeur avec le
script qui va bien pour l'installer (installation d'un rpm, voire d'un deb).
Sauf que, quand on doit attendre après le constructeur qu'il sorte un
nouveau module compilé pour pouvoir upgrader le noyau (au hasard, qui a
de grave failles de sécurité locales pour prendre un cas récent), le
client est tout de suite plus sensible à ce genre de choses.
Les pilotes "binaire-compatibles" tendent à relativiser ce problème,
mais je suis prêt à parier que le "support" (si bien vendu par RedHat,
Novell et autres) n'existe plus dans ce cas là (il leur faut en général
pas grand chose pour faire "sauter" le périmètre de support).
Bref, il faut faire remonter l'info autant que possible aux
constructeurs pour leur signaler l'agacement que leur pilotes
propriétaires suscitent (exemple à mon avis qui les touchera plus qu'un
discours d'évangélisation).
Theo de Raadt (fondateur/leader d'OpenBSD) n'y va pas par quatre
chemins pour ce genre de choses et a bien raison :
http://marc.theaimsgroup.com/?l=openbsd-misc&m=115021011809884&w=2
--
Christophe Sahut
_______________________________________________
gull mailing list
[email protected]
http://lists.alphanet.ch/mailman/listinfo/gull
