Surtout qu'il est clairement expliqué dans le lien donné que dans Linux, c'est celui qui change l'interface qui doit mettre à jour le code de tous les modules qui l'utilise.
Cela reste une perte de temps, et surtout cela suppose que le noyau maintien tous les drivers/modules. Tu me diras c'est peut être pour ca qu'on a un bousin monolithique.
Pour les modules qui ne sont pas dans le noyau vanille et qui doivent donc être modifiés par leur mainteneur ben c'est soit que leur qualité est insuffisante soit...qu'ils ne sont pas libres.
Ou tout simplement qu'ils ne sont pas intégrés au processus de devel du noyau.
Evidemment quand les modifs sont en "interne" au noyau, les APIs stables ne sont pas forcement "utiles", mais il faut faire le raisonnement inverse : cette instabilité des APIs "ferme" le noyau, dans cette dépêche cette fermeture se fait au dépend des pilotes binaires non libre, mais d'une manière générale cela reste une fermeture tout court, aussi bien aux pilotes libres maintenus par des tierces personnes.
Même en supposant qu'un constructeur décide de faire des pilotes "libres", il est normal qu'il souhaite en être le mainteneur principal, mais le modèle de devel du noyau (modèle fermé par changement incéssant des interfaces) l'obligerait à laisser son contrôle à d'autres développeurs.
En fait le noyau est l'anti-thèse des standards. Il ne respecte rien, même en interne. C'est comme si OOo 1.1.3 était incompatible avec OOo 1.1.2 incompatible avec 00o 1.1.1, etc.
Les interfaces c'est comme les standards, il n'a jamais été écris qu'ils ne pouvaient pas évoluer, ce n'est pas pour autant qu'ils ne doivent pas exister et être stable, par soucis d'interopérabilité et d'ouverture.
Et je suis convaincu que cette mauvaise foi concernant les pilotes binaires n'est qu'une façon de cacher des lacunes flagrantes d'architecture et d'organisation au coeur du noyau.
Voilà tout ca pour dire que le noyau lui même contribue au final à son manque de succès auprès des fabriquants matériels.
[^] # Re: esfedq
Posté par TImaniac (site web personnel) . En réponse à la dépêche Pilotes binaires dans Linux: quel est le problème ?. Évalué à -1.
Cela reste une perte de temps, et surtout cela suppose que le noyau maintien tous les drivers/modules. Tu me diras c'est peut être pour ca qu'on a un bousin monolithique.
Pour les modules qui ne sont pas dans le noyau vanille et qui doivent donc être modifiés par leur mainteneur ben c'est soit que leur qualité est insuffisante soit...qu'ils ne sont pas libres.
Ou tout simplement qu'ils ne sont pas intégrés au processus de devel du noyau.
Evidemment quand les modifs sont en "interne" au noyau, les APIs stables ne sont pas forcement "utiles", mais il faut faire le raisonnement inverse : cette instabilité des APIs "ferme" le noyau, dans cette dépêche cette fermeture se fait au dépend des pilotes binaires non libre, mais d'une manière générale cela reste une fermeture tout court, aussi bien aux pilotes libres maintenus par des tierces personnes.
Même en supposant qu'un constructeur décide de faire des pilotes "libres", il est normal qu'il souhaite en être le mainteneur principal, mais le modèle de devel du noyau (modèle fermé par changement incéssant des interfaces) l'obligerait à laisser son contrôle à d'autres développeurs.
En fait le noyau est l'anti-thèse des standards. Il ne respecte rien, même en interne. C'est comme si OOo 1.1.3 était incompatible avec OOo 1.1.2 incompatible avec 00o 1.1.1, etc.
Les interfaces c'est comme les standards, il n'a jamais été écris qu'ils ne pouvaient pas évoluer, ce n'est pas pour autant qu'ils ne doivent pas exister et être stable, par soucis d'interopérabilité et d'ouverture.
Et je suis convaincu que cette mauvaise foi concernant les pilotes binaires n'est qu'une façon de cacher des lacunes flagrantes d'architecture et d'organisation au coeur du noyau.
Voilà tout ca pour dire que le noyau lui même contribue au final à son manque de succès auprès des fabriquants matériels.