Et le faire sans scrupule c'est carrément idiot (ou alors c'est un geste militant ?).
Ça n'a rien d'idiot ni de militant. C'est répondre à un besoin de manière efficace en gardant un code sain et non rempli de wrappers et autres choses dédiées uniquement à la compatibilité, chose que le nombre subliminal de developpeur empeche de toute façon de faire. Ça ne gène surtout pas les développeurs utilisateurs (qu'est-ce qu'il en aurait à foutre de la compatibilité binaire ? ils passent de toute manière leur journée à faire tourner GCC et se basent de toute manière toujours sur les dernières versions et ils ont raison), en rien les utilisateurs finaux (qui utilisent soit une version packagée sur leur distri ou sur un liveCD (ou d7) ou alors un binaire statique dans le "pire" des cas).
Encore une fois on ne change pas pour le plaisir, et pour rassurer ceux qui ont la critique stérile facile (manque de compétence, idiotie ???(en même temps jusqu'à présent j'ai ni concu l'archi ni pris de décision de casser la compatibilité binaire, donc finalement je suis pas si visé que ça)) l'archi est suffisement bien faites pour qu'en réalité l'ABI ne change qu'avec l'API, sauf réponse à un problème contextuel émergeant et suffisement grave.
Et étant donné la diversité des projets, je ne vois pas pourquoi il faudrait prendre KDE comme modèle de référence. Surtout que dans mon cas le couplage interface / bibliothèque est très fort, que l'application ce contente d'être une interface plus ou moins intelligente et que la bibliothèque contient tout le moteur qui agit.
Et je ne vois pas non plus pourquoi il faudrait qu'un critère essentiel pour le monde propriétaire doit être respecté coute que coute quand il n'est pas essentiel selon un contexte donné alors que les spécificités du libre font qu'on peut justement s'en passer à un cout relativement faible.
En conclusion, je ne nie pas qu'il existe des domaines ou la compatibilité binaire puisse être interressante (toolkit graphique utilisé par une myriade d'applis, framework) mais il y en a d'autres où elle est un frein (bibliothèque de fonctionalités et non framework, voir quand c'est carrement le moteur de l'application). Tous les types étant représentés dans une distri, et certaines n'ayant rien à gagner par la préservation d'une soit disante sacro-sainte ABI qui dans leur cas ne l'est pas, on ne peut par conséquence pas atteindre une compatibilité binaire sur une distri (même en faisant semblant d'oublier que le concept de temps T de Gaël est une fumisterie).
Et oui le monde des bibliothèques est divers et ce qui est souhaitable et possible avec les unes n'est pas forcement possible avec d'autres, et encore moins souhaitable avec les dernières. Croire qu'à des contextes très différents et variés on peut à tous appliquer les mêmes critères uniformisés sans ce rendre compte qu'ils sont dans certains cas stériles revient à confondre une voiture de tourisme avec un 38 tonnes. Ce n'est pas parce que ce sont des véhicules avec des roues qui roulent sur les routes qu'ils servent à la même chose ni ne sont conçus de la même façon.
[^] # Re: Compatibilite binaire
Posté par Guillaume Knispel . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 7.
Et le faire sans scrupule c'est carrément idiot (ou alors c'est un geste militant ?).
Ça n'a rien d'idiot ni de militant. C'est répondre à un besoin de manière efficace en gardant un code sain et non rempli de wrappers et autres choses dédiées uniquement à la compatibilité, chose que le nombre subliminal de developpeur empeche de toute façon de faire. Ça ne gène surtout pas les développeurs utilisateurs (qu'est-ce qu'il en aurait à foutre de la compatibilité binaire ? ils passent de toute manière leur journée à faire tourner GCC et se basent de toute manière toujours sur les dernières versions et ils ont raison), en rien les utilisateurs finaux (qui utilisent soit une version packagée sur leur distri ou sur un liveCD (ou d7) ou alors un binaire statique dans le "pire" des cas).
Encore une fois on ne change pas pour le plaisir, et pour rassurer ceux qui ont la critique stérile facile (manque de compétence, idiotie ???(en même temps jusqu'à présent j'ai ni concu l'archi ni pris de décision de casser la compatibilité binaire, donc finalement je suis pas si visé que ça)) l'archi est suffisement bien faites pour qu'en réalité l'ABI ne change qu'avec l'API, sauf réponse à un problème contextuel émergeant et suffisement grave.
Et étant donné la diversité des projets, je ne vois pas pourquoi il faudrait prendre KDE comme modèle de référence. Surtout que dans mon cas le couplage interface / bibliothèque est très fort, que l'application ce contente d'être une interface plus ou moins intelligente et que la bibliothèque contient tout le moteur qui agit.
Et je ne vois pas non plus pourquoi il faudrait qu'un critère essentiel pour le monde propriétaire doit être respecté coute que coute quand il n'est pas essentiel selon un contexte donné alors que les spécificités du libre font qu'on peut justement s'en passer à un cout relativement faible.
En conclusion, je ne nie pas qu'il existe des domaines ou la compatibilité binaire puisse être interressante (toolkit graphique utilisé par une myriade d'applis, framework) mais il y en a d'autres où elle est un frein (bibliothèque de fonctionalités et non framework, voir quand c'est carrement le moteur de l'application). Tous les types étant représentés dans une distri, et certaines n'ayant rien à gagner par la préservation d'une soit disante sacro-sainte ABI qui dans leur cas ne l'est pas, on ne peut par conséquence pas atteindre une compatibilité binaire sur une distri (même en faisant semblant d'oublier que le concept de temps T de Gaël est une fumisterie).
Et oui le monde des bibliothèques est divers et ce qui est souhaitable et possible avec les unes n'est pas forcement possible avec d'autres, et encore moins souhaitable avec les dernières. Croire qu'à des contextes très différents et variés on peut à tous appliquer les mêmes critères uniformisés sans ce rendre compte qu'ils sont dans certains cas stériles revient à confondre une voiture de tourisme avec un 38 tonnes. Ce n'est pas parce que ce sont des véhicules avec des roues qui roulent sur les routes qu'ils servent à la même chose ni ne sont conçus de la même façon.