Est-ce qu'au final on n'est pas simplement en train d'acter le fait que personne ne souhaite maintenir les logiciels?
Traditionnellement, l'évolution des logiciels (compilateurs, systèmes de build, bibliothèques tierces...) demande une maintenance permanente. Ça ne compile plus avec le nouveau gcc parce qu'il est plus strict sur les erreurs de syntaxe, il faut réécrire le code pour s'interfacer avec la dernière API de libxml, il faut contourner un bug du compilateur sur telle ou telle architecture, etc. Un projet actif demande de toujours bricoler pour fournir des paquets qui fonctionnent sur plusieurs OS ou plusieurs distributions. C'est casse pied, mais c'est le prix à payer pour s'assurer que le logiciel soit utilisable, qu'il soit compilé avec des options d'optimisation plus efficaces, qu'il soit compatibles avec les nouvelles technologies, et qu'il s'appuie sur des versions à jour (débuggées, sécurisées, et optimisées) des bibliothèques externes.
J'ai l'impression que l'écosystème actuel n'accepte plus ce coût, et voudrait que les logiciels fonctionnent pour toujours comme au jour de la publication de la première version. Avec un Python d'il y a 10 ans, avec des dépendances qui n'ont pas été touchées depuis 15 ans, avec des interfaces graphiques qui datent de Windowmaker... Si les dépendances sont trop chiantes, paf on distribue le binaire compilé d'un bloc, et si ça marche pas, paf on te met ça dans une machine virtuelle, ça juste marche.
Conda et compagnie, c'est quand même par design pour pallier les trucs pas maintenus, qui ont besoin d'une combinaison précise de dépendances pas à jour, ou pour faire tourner la dernière version d'un logiciel sur un serveur pas super à jour. C'est plus dans nos pratiques collectives de maintenance qu'il y a un problème, non? Je ne vois pas comment ça pourrait être résolu magiquement en bloatant les machines avec 127 versions de chaque dépendance et en priant pour que le système de build et l'environnement de développement trouve la bonne et se débrouille pour trouver quelque chose de plus ou moins compatible sur chaque machine où le logiciel sera distribué...
# Maintenance
Posté par arnaudus . En réponse au journal La cochonnerie en boite que sont les systèmes de dépendances. Évalué à 10. Dernière modification le 22 août 2022 à 15:19.
Est-ce qu'au final on n'est pas simplement en train d'acter le fait que personne ne souhaite maintenir les logiciels?
Traditionnellement, l'évolution des logiciels (compilateurs, systèmes de build, bibliothèques tierces...) demande une maintenance permanente. Ça ne compile plus avec le nouveau gcc parce qu'il est plus strict sur les erreurs de syntaxe, il faut réécrire le code pour s'interfacer avec la dernière API de libxml, il faut contourner un bug du compilateur sur telle ou telle architecture, etc. Un projet actif demande de toujours bricoler pour fournir des paquets qui fonctionnent sur plusieurs OS ou plusieurs distributions. C'est casse pied, mais c'est le prix à payer pour s'assurer que le logiciel soit utilisable, qu'il soit compilé avec des options d'optimisation plus efficaces, qu'il soit compatibles avec les nouvelles technologies, et qu'il s'appuie sur des versions à jour (débuggées, sécurisées, et optimisées) des bibliothèques externes.
J'ai l'impression que l'écosystème actuel n'accepte plus ce coût, et voudrait que les logiciels fonctionnent pour toujours comme au jour de la publication de la première version. Avec un Python d'il y a 10 ans, avec des dépendances qui n'ont pas été touchées depuis 15 ans, avec des interfaces graphiques qui datent de Windowmaker... Si les dépendances sont trop chiantes, paf on distribue le binaire compilé d'un bloc, et si ça marche pas, paf on te met ça dans une machine virtuelle, ça juste marche.
Conda et compagnie, c'est quand même par design pour pallier les trucs pas maintenus, qui ont besoin d'une combinaison précise de dépendances pas à jour, ou pour faire tourner la dernière version d'un logiciel sur un serveur pas super à jour. C'est plus dans nos pratiques collectives de maintenance qu'il y a un problème, non? Je ne vois pas comment ça pourrait être résolu magiquement en bloatant les machines avec 127 versions de chaque dépendance et en priant pour que le système de build et l'environnement de développement trouve la bonne et se débrouille pour trouver quelque chose de plus ou moins compatible sur chaque machine où le logiciel sera distribué...