Ce matin, je tombe sur ce papier. Je suis très content pour son auteur si tout son matériel acheté à SuperU fonctionne "out-of-the-box". Mais même si je suis d'accord avec une partie de la conclusion "il y a de gros progrès", je n'en reste pas moins convaincu que le plus gros problème de GNU/Linux est et reste le support du matériel. Mais ce n'est pas le problème de GNU/Linux en réalité...

Alors soyez indulgent, il est au fond rare que je livre mes pensées sur ce site. Mais en lisant cet article, je n'ai pu m'empêcher de me dire qu'il ne faudrait tout de même pas se leurrer. Le support matériel est, et restera, un problème, non pas de GNU/Linux, pas de tous les OS qui ne sont pas considérés comme rentables par les fabricants. Ce n'est donc pas plus un problème pour les utilisateurs du pingouin, que ceux de *BSD, MacOS, et sûrement bientôt celui de ceux qui déciderons de ne pas céder à la vague "c'est mon choix" (rien compris à cette pub d'ailleurs...) et qui voudrons rester sous Windows XP.

Le vrai soucis est que fabriquer un pilote est un travail complexe pour tout le monde, mais surtout pour les fabricants. Il n'y a qu'a se souvenir des déboires de Creative Labs, AMD ou nvidia avec leurs pilotes... MS Windows. La raison, pour avoir bossé sur ce type de problématique, est double. Tout d'abord, même avec des spécifications "claires" (elles ne le sont jamais...), c'est un travail très compliqué que de faire parler du soft et du hard. Une complexité augmentée pour des constructeurs dont le métier de base est, et reste, la conception de matériel, pas de logiciel... C'est donc un travail hors de leur coeur de métier qui les amène, dans notre économie de marché, à un choix de rentabilité qui n'a au fond rien à voir avec un amour particulier pour MS Windows. Est considéré comme non rentable tout ce qui ne fait pas 80% de parts de marché et ce de manière assez agnostique. Si demain GNU/Linux ou FreeBSD atteignait ce chiffre, ce sont les Windowsiens qui pleureraient. Ce n'est pas demain la veille, certes, mais cela permet de recentrer le débat sur la problématique de base des constructeurs, comment rentabiliser le coût de développement de what-milles pilotes pour autant d'OS à la noix (de leur point de vue). Un effet augmenté par le fait que Microsoft a très bien "compris" cette problématique et l'utilise, comme toujours dans un sens qui l'arrange, en multipliant les partenariats. Une peu la même stratégie que celle appliquée aux développeurs enamourés de SDK Microsoftiens car cajolés par leur commercial fétiche qui leur vante autant leur GRANDE compétence que la facilité avec laquelle ils pourront mettre en oeuvre, grâce au Kit .machin de la mort, l'intranet ultra-puissant passant sur mobile comme qui rigole en trois clicks. Mais ça c'est une autre histoire...

Pour répondre à ce travail compliqué et peu rentable, certains clament que la solution est l'ouverture des spécifications. J'ai comme un doute sur le fait que ces gens là fassent tourner leur propre entreprise. Car lorsque l'on voit la guerre acharnée que se font les constructeurs, on peut comprendre que ce soit pour le peu délicat. Si nVidia produit l'intégralité de ses spécifications, qu'est-ce qui empêche demain un fondeur chinois de pondre une puce 100% compatible pour 20% du prix ? Après on peut être pour ou contre l'économie de marché, mais dans le contexte qu'elle représente aujourd'hui, l'ouverture des spécifications est une éventuelle possibilité (et encore...) pour de très grands fondeurs, ou pour de très petits (qui n'ont pas grand chose à perdre). Mais entre les deux, c'est très risqué. En tout cas ce n'est pas une position qui me semble économiquement viable.

Autre possibilité souvent évoquée, celle de l'Open Hardware. Des spécifications libres et accessibles utilisées par tous les constructeurs. Cela fonctionne déjà pour des choses auxquelles on ne pense même pas. En effet, vous-êtes vous déjà demandé si votre clavier, votre souris ou votre écran allait être compatible GNU/Linux ? Non. Alors oui, le bouton multimédia qui sert à rien, ou le clignotement de la LED de la souris risque de ne pas être pris en charge, mais pour le gros 80% de leurs fonctionnalités cela coule de source. Et cela coule de source car au fond cela a été normalisé par IBM (pour le clavier) il y a des années et qu'il n'y a pas de grandes différences entre un clavier d'il y a 15 ans et celui qui vient de sortir.

Mais pour du matériel plus compliqué, là encore, si un petit fondeur/constructeur peut y trouver son compte, les autres y verraient peut-être la disparition de leurs avantages concurrentiels. Cela nous fatiguerait certes moins les forums, mais il n'y auraient dés lors plus de pro/anti AMD face à des pro/anti nVidia car les deux feraient au fond strictement la même chose (ce qui est le cas de mon point de vue de non-joueur mais là aussi, c'est une autre histoire .

Alors quelle solution puisque l'on ne peut pas demander aux constructeurs d'ouvrir leurs spécifications, ni perdre de l'argent à rédiger des pilotes pour des OS marginaux, ni les obliger à faire tous les mêmes produits ? Peut-être est-ce simplement la structure même des pilotes qu'il faudrait normaliser ? Cela permettrait aux constructeurs de ne faire qu'un pilote pour tous les OS et on arrêterait définitivement de se prendre la tête.

Bien évidement, cela ne peut fonctionner que par grandes classes de matériel car il est difficile d'imaginer une structure de pilote identique entre une carte vidéo et une carte réseau. Mais pourquoi les constructeurs, car ce serait à eux d'y penser, ne se réunissent pas en une sorte d'Open Driver Aliance pour pondre une série de spécifications strictes et rigides pour ces grandes classes de pilotes ? Ce n'est pas une utopie car au fond il existe déjà des choses dans ce domaine. Prenons le cas des cartes réseaux et l'interface NDIS (développé par 3Com et Microsoft). Il est depuis belle lurette possible d'utiliser ces pilotes à l'origine pour MS-Windows sur GNU/Linux. Pourquoi pas (et là je ne parle pas de licence, juste de la théorie un support natif ? Les constructeurs mettraient sur leur boite "compatible NDIS" et basta, l'affaire est réglée. Les devs du kernel perdraient du coup moins de temps à faire un épique reverse-engeneering pour se consacrer à la véritable valeur ajoutée de l'OS. Même principe pour une webcam, ou une carte son, que l'on sorte un peu de ce type d'enfer. Pour des choses aussi basiques, il doit tout de même être possible de faire une interface de pilote totalement universelle. Lorsque l'on sait par exemple que le pilote nVidia pour GNU/Linux est à 90% le même que celui de windows, cela semble dingue pour un gars du logiciel comme moi que tout ce monde ne se soit pas entendu sur une interface commune, pour imposer cela ensuite aux éditeurs d'OS.

Bref, j'ai bien conscience que je viens de me faire plaisir et que j'ai gentiment soufflé dans un violon, voir même, dit beaucoup de conneries. Mais cette histoire de pilote m'a toujours fait halluciner. Et pour conclure sur papier à l'origine du mien, la preuve que le hardware reste le gros problème sous GNU/Linux, et ce même pour quelqu'un qui fait hyper gaffe à ce qu'il achète (Jamais chez SuperU , une petite liste à la Prévert :

• Une imprimante Epson qui imprime à la bonne résolution (et sans bouffer les marges après 2 ans (elle en a 3 , mais environ 10x moins vite que sous Windows.
• Un portable sans wifi, sans entrée Micro et avec une webcam qui refuse de me prendre en photo autrement que la tête en bas...
• Un autre portable avec un pilote Poulsbo merdique (pas de 3D, ceci dit, il semble que cela va changer), qui avait du wifi mais qui n'en a plus avec les dernières générations de kernel (y'a sûrement un howto en russe qui traîne dans un coin...).
• Un casque bluetooth que j'ai finalement donné à un windowsien...
• Deux cartes d'acquisition vidéo qui freeze GNU/Linux et une autre qui refuse de me donner le son.
• Je ne compte plus les puces audio intégrées qui refusent le moindre enregistrement.
• Une WebCam qui fonctionnent très bien, sauf lorsque je la connecte un à hub USB....
• etc, etc, etc... J'en ai un carton plein...

Au final, le matos sous GNU/Linux, c'est comme le bon vin, il y a des millésimes et de manière général, il est bien meilleur lorsqu'on prend le temps de le laisser vieillir.