Mais les deux aspects sont mélangés dans la vrai vie aussi.
Par exemple quand OpenSSL 1.1.x n'est plus maintenu par l'équipe de développement et qu'il faut passer à OpenSSL 3.x, tu fais quoi ? Rester sur une vieilles bibliothèques avec potentiellement des failles pas corrigées ? Ce n'est pas une bonne réponse. Et passer à OpenSSL 3.x qui a une rupture de compatibilité avec sa précédente version t'ouvre la porte à des problèmes de compatibilité avec ton logiciel existant ce qui implique potentiellement un travail énorme sur des composants que tu ne maitrises pas. C'est là qu'on voit la difficulté de maintenir un OS complet dans le temps, dont une distribution Linux, ce sont des problématiques qu'ils voient tout le temps et ils doivent arbitrer.
Et là j'ai pris l'exemple de OpenSSL, mais tu as ça pour tout, que ce soit les bibliothèques de base (dont glibc), les langages de programmation comme Python 2, le noyau, etc.
C'est vraiment difficile et je dirais même infaisable sans une armée de développeurs et de testeurs dédiés.
Si tu souhaites une maintenance sur la durée, donc au delà de 1-2 ans, tu auras ce problème tôt ou tard quelque part. Et probablement un peu partout à la fois.
Puis tu as un autre soucis, la compatibilité des applications. Google fourni de plus en plus d'API, que ce soit de sécurité ou de fonctionnalités pour les applications Android. C'est bien, mais du coup si tu veux que ton téléphone puisse exécuter l'application de ta banque, il faudra probablement une version pas trop ancienne. Donc tu ne peux pas rester avec ton Android 4.4 maintenu à bout de bras avec tes petites mains, si tu veux exploiter les fonctionnalités de ces applications tierces il faudra aussi passer à des versions d'Android plus récentes.
Pour être confronté à cette problématique au boulot dans un contexte bien plus facile je vois bien la difficulté de la tâche, ce n'est pas se chercher des excuses, mais l'écosystème n'a rien que permette de faire ça facilement. Les projets ne sont pas synchronisés, chacun fait à sa sauce dans son coin (Python 2 est abandonné à une date différente de OpenSSL 1.1, et Linux n'a pas d'API stable dans le temps, etc.), il n'y a pas une armée de développeurs pour gérer ces problèmes pour les industriels consommateurs de ces produits, etc.
Ceux qui font ça ce sont les distributions Linux, et on voit la galère que c'est pour eux, et ils sont très nombreux à le faire. Red Hat c'est aussi beaucoup de monde qui fait ça et difficilement et même parfois ils décident de passer à des versions majeurs en cours de route car maintenir sans bouger pendant 10 ans c'est difficile. Et ce n'est pas pour rien que Snap et Flatpak poussent et sont poussés car ça résout certaines de ces difficultés de maintenance.
Ce n'est pas un hasard non plus si Mark Shuttleworth a une époque avait lancée une idée polémique de synchroniser certains projets majeurs de l'éco-système sur le rythme de publication d'Ubuntu. Cela a fait jaser, mais sur le fond il a pointé un vrai problème qui n'a jamais été résolu.
[^] # Re: Quelqu'un saurait m'expliquer ?
Posté par Renault (site web personnel) . En réponse au lien Fin du support logiciel sur le Fairphone 2 (mars 2023). Évalué à 10.
Mais les deux aspects sont mélangés dans la vrai vie aussi.
Par exemple quand OpenSSL 1.1.x n'est plus maintenu par l'équipe de développement et qu'il faut passer à OpenSSL 3.x, tu fais quoi ? Rester sur une vieilles bibliothèques avec potentiellement des failles pas corrigées ? Ce n'est pas une bonne réponse. Et passer à OpenSSL 3.x qui a une rupture de compatibilité avec sa précédente version t'ouvre la porte à des problèmes de compatibilité avec ton logiciel existant ce qui implique potentiellement un travail énorme sur des composants que tu ne maitrises pas. C'est là qu'on voit la difficulté de maintenir un OS complet dans le temps, dont une distribution Linux, ce sont des problématiques qu'ils voient tout le temps et ils doivent arbitrer.
Et là j'ai pris l'exemple de OpenSSL, mais tu as ça pour tout, que ce soit les bibliothèques de base (dont glibc), les langages de programmation comme Python 2, le noyau, etc.
C'est vraiment difficile et je dirais même infaisable sans une armée de développeurs et de testeurs dédiés.
Si tu souhaites une maintenance sur la durée, donc au delà de 1-2 ans, tu auras ce problème tôt ou tard quelque part. Et probablement un peu partout à la fois.
Puis tu as un autre soucis, la compatibilité des applications. Google fourni de plus en plus d'API, que ce soit de sécurité ou de fonctionnalités pour les applications Android. C'est bien, mais du coup si tu veux que ton téléphone puisse exécuter l'application de ta banque, il faudra probablement une version pas trop ancienne. Donc tu ne peux pas rester avec ton Android 4.4 maintenu à bout de bras avec tes petites mains, si tu veux exploiter les fonctionnalités de ces applications tierces il faudra aussi passer à des versions d'Android plus récentes.
Pour être confronté à cette problématique au boulot dans un contexte bien plus facile je vois bien la difficulté de la tâche, ce n'est pas se chercher des excuses, mais l'écosystème n'a rien que permette de faire ça facilement. Les projets ne sont pas synchronisés, chacun fait à sa sauce dans son coin (Python 2 est abandonné à une date différente de OpenSSL 1.1, et Linux n'a pas d'API stable dans le temps, etc.), il n'y a pas une armée de développeurs pour gérer ces problèmes pour les industriels consommateurs de ces produits, etc.
Ceux qui font ça ce sont les distributions Linux, et on voit la galère que c'est pour eux, et ils sont très nombreux à le faire. Red Hat c'est aussi beaucoup de monde qui fait ça et difficilement et même parfois ils décident de passer à des versions majeurs en cours de route car maintenir sans bouger pendant 10 ans c'est difficile. Et ce n'est pas pour rien que Snap et Flatpak poussent et sont poussés car ça résout certaines de ces difficultés de maintenance.
Ce n'est pas un hasard non plus si Mark Shuttleworth a une époque avait lancée une idée polémique de synchroniser certains projets majeurs de l'éco-système sur le rythme de publication d'Ubuntu. Cela a fait jaser, mais sur le fond il a pointé un vrai problème qui n'a jamais été résolu.