Je commence à véritablement détester les drivers propriétaires. Il y a toujours les arguments classiques: "C'est pas libre", "L'équipe kernel ne vous apportera aucune aide si vous avez un kernel "tainted"", etc ...

De mon point de vue, c'est surtout une catastrophe pour porter ces drivers d'une version à l'autre du noyau. Pas la peine de demander de l'aide à l'entreprise originaire du driver. Réponse classique: "On ne supporte que la version 2.6.4/gcc2.95 du noyau" [1]. Pire, parfois, vous n'avez qu'un .ko. Dans ce cas, il n'est mais pas envisageable de choisir un autre compilateur ou une autre version du kernel (ni certaines options de compilation). Evidement, rapidement, vous vous retrouvez sur votre système avec un driver qui ne fonctionne que en 2.6.8 et un autre que en 2.6.30. Il faut bien en porter un des deux. C'est généralement là que les choses se gâtent. On se rend compte que les auteurs ont gardé le code fermé, non pas pour préserver un soi-disant secret de fabrication, mais pour éviter qu'on les prennent pour des codeurs du dimanche [2]. Bref, porter un driver ça n'est pas forcément évident. Si il est mal codé, c'est pire: on risque de faire apparaitre des bugs "latents". Et si il vous n'avez ni les sources, ni les spécifications du matériel, ça devient un véritable casse-tête de comprendre les problèmes.



Par conséquent, pour avoir retarder le développement de certains de mes projets, je délationne : Fglrx, Nvidia (bien que le suivis du mainstream soit suffisament proche pour qu'il y ait peu de problèmes), DVS (fabriquant de cartes d'acquisition vidéo), Intel Poulsbo (Libre, mais personne n'est capable de comprendre ce qu'il fait), TrueFFS (Disk On Chip), etc...

Notes

[1] Oui, bien souvent les versions sont hors d'age

[2] Je suis sûr que parfois, ce sont les stagiaires qui développent les drivers