Tant qu'on aura pas une stabilité des APIs du noyau, Linux sera toujours à la traîne pour les drivers de matériel récent, car les constructeurs ne peuvent pas fournir les drivers avec le matériel vendu avec la certitude que ça marchera sur tel ou tel noyau.
Tu crois sincèrement qu'il est là le problème ? Les quelques constructeurs qui veulent sortir des drivers pour Linux n'ont pas de difficultée à le faire. Quelques semaines après le passage de la pile à 4Ko, c'est à dire bien avant que ça ne se retrouve dans la moindre distrib' Linux et que donc ça ne pause le moindre problème aux utilisateurs (sauf à qlqs geeks accrocs à kernel.org qui croient que leur système va s'autodétruire si ils n'utilisent pas la dernière version en date), des drivers NVidia corrigeant l'overflow sont sortis. Non, franchement, si beaucoup de constructeurs ne font pas de drivers Linux, ça n'est pas parcequ'il est trop mouvant ou je ne sais quoi, c'est juste parcequ'ils n'en n'ont rien à foutre des 1% de clients que ça pourrait intéresser.
Quant à l'histoire du logo, bof, pour moi ce qui serait à vérifier pour l'attribuer, ça n'est pas qu'il existe un driver qui va éternellement marcher sur toute la série des 2.X, mais plutôt qu'il y a un drivers qui marche avec les 2.X actuels, et un constructeur qui va le mettre à jour de façon à ce que ça continue. Moi ça me parait parfaitement acceptable de dire, et c'est ça qui compte, que « les NVidia sont supportée sous Linux avec la 3D et tout et tout via un driver proprio ». Alors que pourtant il y a effectivement eu qlqs semaines pendant lesquels ça n'était pas vrai pour la toute dernière version du noyau, mais je vais pas pinailler pour ça.
Accessoirement, quand bien même il y aurait une API à 100% figée pour une série de noyaux, ça ne voudrait pas dire qu'on peut certifier qu'un driver proprio marchera avec 2.X.Z sous prétexte qu'il marche avec 2.X.Y . Rien ne garantit en effet qu'elle n'est pas contournée et qu'il n'y a pas dans le code du driver des hacks qui créeront des incompatibilitées avec des versions futures à cause de changement internes au noyau, ne modifiant pourtant pas l'API. Donc une certification telle que tu l'entends, elle me parait bien illusoire.
[^] # Re: Question ?
Posté par tgl . En réponse à la dépêche Nouveau modèle de développement pour Linux. Évalué à 9.
Tu crois sincèrement qu'il est là le problème ? Les quelques constructeurs qui veulent sortir des drivers pour Linux n'ont pas de difficultée à le faire. Quelques semaines après le passage de la pile à 4Ko, c'est à dire bien avant que ça ne se retrouve dans la moindre distrib' Linux et que donc ça ne pause le moindre problème aux utilisateurs (sauf à qlqs geeks accrocs à kernel.org qui croient que leur système va s'autodétruire si ils n'utilisent pas la dernière version en date), des drivers NVidia corrigeant l'overflow sont sortis. Non, franchement, si beaucoup de constructeurs ne font pas de drivers Linux, ça n'est pas parcequ'il est trop mouvant ou je ne sais quoi, c'est juste parcequ'ils n'en n'ont rien à foutre des 1% de clients que ça pourrait intéresser.
Quant à l'histoire du logo, bof, pour moi ce qui serait à vérifier pour l'attribuer, ça n'est pas qu'il existe un driver qui va éternellement marcher sur toute la série des 2.X, mais plutôt qu'il y a un drivers qui marche avec les 2.X actuels, et un constructeur qui va le mettre à jour de façon à ce que ça continue. Moi ça me parait parfaitement acceptable de dire, et c'est ça qui compte, que « les NVidia sont supportée sous Linux avec la 3D et tout et tout via un driver proprio ». Alors que pourtant il y a effectivement eu qlqs semaines pendant lesquels ça n'était pas vrai pour la toute dernière version du noyau, mais je vais pas pinailler pour ça.
Accessoirement, quand bien même il y aurait une API à 100% figée pour une série de noyaux, ça ne voudrait pas dire qu'on peut certifier qu'un driver proprio marchera avec 2.X.Z sous prétexte qu'il marche avec 2.X.Y . Rien ne garantit en effet qu'elle n'est pas contournée et qu'il n'y a pas dans le code du driver des hacks qui créeront des incompatibilitées avec des versions futures à cause de changement internes au noyau, ne modifiant pourtant pas l'API. Donc une certification telle que tu l'entends, elle me parait bien illusoire.