Mais les constructeurs de merde, ça existe et il faut bien faire avec. D'autant que ce n'est pas complètement manichéen : faire intégrer quelque chose dans l'arbre officiel est un travail de longue haleine qui requiert une forme d'expertise et d'élitisme (et il y a donc une barrière à l'entrée, et la part de marché de Linux ne justifie pas toujours l'investissement, surtout si les API/ABI pètent tout le temps alors que chez la "concurrence" elles sont stables et bien documentées). Quand je propose à quelqu'un de passer sous Linux, il est généralement déjà équipé et ne va pas choisir son matériel spécifiquement en fonction de ce qui est bien supporté, et il faut pourtant éviter que passage sous Linux soit synonyme de régressions... (ou de potentielles régressions futures à la moindre MAJ)
Je continue de penser que proposer des APIs stables (entre versions majeures) pour les gens qui écrivent des drivers ne serait pas un luxe. Je peux comprendre que ceux qui bossent sur la gestion de la mémoire, le scheduler, etc. souhaitent garder une liberté sur l'agencement du code interne, mais je trouve qu'un driver devrait rester un bout de code qui utilise les services du noyau (au même titre qu'une appli est utilisatrice des services des libs dont elle dépend) et non quelque chose qui devrait être fortement couplé aux APIs internes.
[^] # 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 30 octobre 2014 à 12:25.
Mouais si tu veux, façon de parler...
Mais les constructeurs de merde, ça existe et il faut bien faire avec. D'autant que ce n'est pas complètement manichéen : faire intégrer quelque chose dans l'arbre officiel est un travail de longue haleine qui requiert une forme d'expertise et d'élitisme (et il y a donc une barrière à l'entrée, et la part de marché de Linux ne justifie pas toujours l'investissement, surtout si les API/ABI pètent tout le temps alors que chez la "concurrence" elles sont stables et bien documentées). Quand je propose à quelqu'un de passer sous Linux, il est généralement déjà équipé et ne va pas choisir son matériel spécifiquement en fonction de ce qui est bien supporté, et il faut pourtant éviter que passage sous Linux soit synonyme de régressions... (ou de potentielles régressions futures à la moindre MAJ)
Je continue de penser que proposer des APIs stables (entre versions majeures) pour les gens qui écrivent des drivers ne serait pas un luxe. Je peux comprendre que ceux qui bossent sur la gestion de la mémoire, le scheduler, etc. souhaitent garder une liberté sur l'agencement du code interne, mais je trouve qu'un driver devrait rester un bout de code qui utilise les services du noyau (au même titre qu'une appli est utilisatrice des services des libs dont elle dépend) et non quelque chose qui devrait être fortement couplé aux APIs internes.