Ouais enfin, Linux étant un noyau monolithique les drivers font partie du noyau, or tous les constructeurs n'adhèrent pas au mode de développement du noyau car pour nombre d'entre eux ça ne vaut pas le coup/coût de se conformer aux exigences de qualité des devs kernel pour faire rentrer leur code dans l'arbre officiel, et donc (au mieux) le bout de code est maintenu sous forme de module externe. Lorsque ledit driver n'est plus maintenu (parce que ça n'est pas rentable), l'utilisateur est livré à lui-même avec des drivers qui pètent à la première occasion... (car l'utilisateur normal ne sait pas adapter un driver. Tout ce qu'il voit c'est que son device marchait avant la MAJ de sa distro, et ne marche plus après sans aucun moyen simple de corriger le problème, à part jeter son device et en racheter un autre). Ce serait plus commode si le kernel avait des API/ABI stables pour tout ce qui est utilisé par les pilotes de périphériques ("stables" == ne changeant qu'entre versions majeures bien définies, de sorte que le script de MAJ puisse dire "attention, votre device X utilise un driver tierce-partie, la MAJ du kernel que vous vous apprétez à faire risque de rendre ce device non fonctionnel. Voulez-vous mettre à jour le noyau ?")
Evidemment, cette remarque ne s'applique pas aux périphériques USB qui utilisent des drivers userland via libusb. De là à dire que Tanenbaum avait raison d'encourager une approche micro-kernel... ? :)
[^] # Re: Linus a dit : « making binaries for linux [...] is a major fucking pain in the ass »
Posté par karteum59 (site web personnel) . En réponse au journal Pourquoi vous ne devriez pas packager vous-même votre logiciel pour Debian ?. Évalué à 4. Dernière modification le 29 octobre 2014 à 16:00.
Ouais enfin, Linux étant un noyau monolithique les drivers font partie du noyau, or tous les constructeurs n'adhèrent pas au mode de développement du noyau car pour nombre d'entre eux ça ne vaut pas le coup/coût de se conformer aux exigences de qualité des devs kernel pour faire rentrer leur code dans l'arbre officiel, et donc (au mieux) le bout de code est maintenu sous forme de module externe. Lorsque ledit driver n'est plus maintenu (parce que ça n'est pas rentable), l'utilisateur est livré à lui-même avec des drivers qui pètent à la première occasion... (car l'utilisateur normal ne sait pas adapter un driver. Tout ce qu'il voit c'est que son device marchait avant la MAJ de sa distro, et ne marche plus après sans aucun moyen simple de corriger le problème, à part jeter son device et en racheter un autre). Ce serait plus commode si le kernel avait des API/ABI stables pour tout ce qui est utilisé par les pilotes de périphériques ("stables" == ne changeant qu'entre versions majeures bien définies, de sorte que le script de MAJ puisse dire "attention, votre device X utilise un driver tierce-partie, la MAJ du kernel que vous vous apprétez à faire risque de rendre ce device non fonctionnel. Voulez-vous mettre à jour le noyau ?")
Evidemment, cette remarque ne s'applique pas aux périphériques USB qui utilisent des drivers userland via libusb. De là à dire que Tanenbaum avait raison d'encourager une approche micro-kernel... ? :)