curl fonctionne sur 100 systèmes d’exploitation
(daniel.haxx.se)- curl limite les changements afin de continuer à être compilé et testé même dans d’anciens environnements ; dans une pull request récente, il était aussi exigé de ne pas casser la compatibilité avec les plateformes historiques ni avec le
time_t32 bits - L’enjeu principal n’est pas de conserver une longue liste de plateformes, mais de respecter la promesse de stabilité ABI/API pour que le comportement reste inchangé lorsque les utilisateurs mettent à niveau
- Plus que le nombre d’utilisateurs d’un système d’exploitation donné, ce qui compte est qu’il existe des personnes qui s’en occupent réellement et corrigent les problèmes ; tant qu’il reste un mainteneur, les plateformes peu utilisées peuvent continuer à être prises en charge
- curl et libcurl se sont diffusés grâce à un principe centré sur la portabilité, consistant à rester « compilables et exécutables » sur des systèmes d’exploitation, architectures CPU et configurations atypiques très variés
- La principale raison pour laquelle d’anciennes commandes curl échouent tient davantage à l’évolution de l’environnement Internet — disparition d’hôtes et d’URL, passage de HTTP à HTTPS — qu’aux changements de curl lui-même
Critères de changement pour ne pas casser les plateformes historiques
- Dans une pull request récente de curl, les changements ne pouvaient être fusionnés dans le dépôt de code git que s’ils ne cassaient pas la compilation ou les tests sur les plateformes historiques
- Le changement concernait
time_t, et curl prenant déjà en charge les typestime_t32 bits, ce comportement devait être conservé - Le
time_t32 bits a déjà un usage limité et pourrait devenir encore plus contraignant à mesure que 2038 approche, mais de nombreuses plateformes historiques restent encore sur des versions 32 bits - Cette exigence complique le travail des contributeurs, mais, dans curl, elle est considérée comme faisant partie du processus qui rend un changement abouti
La compatibilité est une promesse qui dépasse le nombre de plateformes
- Le projet curl s’efforce en permanence de maintenir la stabilité et la compatibilité de l’ABI et de l’API
- Une application utilisant libcurl au milieu des années 2000 peut être mise à niveau vers une version récente de libcurl, sans recompilation de l’application, tout en continuant à fonctionner de la même manière
- On peut aussi s’attendre à ce qu’un script curl écrit au début des années 2000 fonctionne presque de la même manière avec les versions actuelles de curl
- Cette compatibilité n’est pas un simple argument marketing, mais un principe central de curl et libcurl
- Les utilisateurs peuvent compter sur curl
- Même lorsqu’une version contient des bugs, le projet cherche à fournir des mises à jour permettant de passer à une nouvelle version sans les douleurs habituelles des mises à niveau logicielles
- L’attitude consistant à ne pas casser sans nécessité ce qui fonctionne déjà fait partie des critères de maintenance
Ce sont les mainteneurs qui déterminent la prise en charge
- Le nombre d’utilisateurs d’une plateforme donnée n’est pas la principale motivation qui détermine si curl continuera à la prendre en charge
- Le critère le plus important est de savoir qui prend le travail en charge et si la maintenance nécessaire est réellement effectuée
- S’il existe un contributeur qui vérifie que curl continue de fonctionner sur une plateforme, curl peut continuer à s’y exécuter même si cette plateforme est réputée peu utilisée
- Le moment où une plateforme disparaît de fait de curl est celui où le code nécessaire à cette plateforme n’est plus maintenu
- Même du code non maintenu peut rester fonctionnel pendant plusieurs années
- Il peut aussi falloir longtemps avant de découvrir que curl ne fonctionne plus sur une plateforme donnée
- À l’inverse, même pour une plateforme très utilisée, la maintenance devient difficile s’il manque des mainteneurs ayant la volonté et les connaissances nécessaires pour traiter ses problèmes spécifiques
Pourquoi curl s’est diffusé dans des environnements variés
- curl et libcurl se concentrent fortement sur le fait de pouvoir être compilés et exécutés dans le plus grand nombre d’environnements possible
- Cette volonté de continuer à fonctionner même dans des configurations singulières ou étranges est l’une des raisons de leur diffusion sur de nombreux systèmes d’exploitation et architectures CPU
- De nombreux utilisateurs et entreprises continuent d’utiliser des plateformes anciennes, de niche ou historiques
- Pour eux, maintenir les capacités de transfert de curl est souvent préférable sur le plan de la sécurité à une implémentation de remplacement faite maison
- Lorsqu’il n’est pas nécessaire de casser une fonctionnalité, il est jugé préférable de laisser les utilisateurs existants continuer à dépendre de curl
La suppression de prise en charge est lente et publique
- curl supprime aussi parfois certaines prises en charge
- Les principales suppressions concernent la prise en charge de bibliothèques tierces dont l’usage décline et qui disparaissent progressivement, mais cela peut aussi arriver dans d’autres domaines
- L’abandon de prise en charge se fait lentement, prudemment et avec une communication publique
- Les utilisateurs qui veulent être informés doivent pouvoir connaître les changements à l’avance
- Ils doivent pouvoir se préparer ou s’opposer à une proposition si elle leur paraît injustifiée
- Si les utilisateurs ne peuvent pas percevoir de changement de comportement, cela n’est pas considéré comme une modification
- curl est conçu pour les utilisateurs, et si ceux-ci veulent qu’un comportement continue d’exister, ce comportement doit être maintenu
La vraie raison pour laquelle les anciennes commandes échouent
- Les protocoles et versions d’Internet apparaissent et disparaissent au fil du temps
- La plupart des lignes de commande curl écrites en 2002 pourraient ne plus fonctionner telles quelles aujourd’hui
- La raison de l’échec peut ne pas être curl lui-même, mais les noms d’hôte et URL utilisés à l’époque, qui ne fonctionnent plus
- L’une des principales raisons pour lesquelles une commande curl de 2002 ne fonctionne plus telle quelle aujourd’hui est le passage de HTTP à HTTPS
- Même si certains sites utilisaient TLS ou SSL en 2002, ce n’était pas courant à l’époque, et les versions du protocole TLS utilisées alors peuvent aujourd’hui être considérées comme non sûres
- Les bibliothèques TLS modernes et curl peuvent refuser de se connecter à d’anciennes configurations TLS qui n’ont pas été mises à jour
- Même si l’on avait conservé un exécutable curl de 2002 et qu’on l’exécutait aujourd’hui, il pourrait ne pas réussir à se connecter aux sites HTTPS modernes
- Ce n’est pas dû aux changements de curl, mais à l’évolution de la couche des protocoles de transport
1 commentaires
Commentaires sur Hacker News
C’est une réalisation impressionnante. Curl est vraiment un outil formidable.
Il est intéressant que Daniel ait mis en avant
time_tsur 32 bits comme point important de compatibilité. Si l’objectif est de continuer à fonctionner sur de nombreux systèmes d’exploitation, c’est tout à fait logique. Cela dit, 2038 n’est plus qu’à 14 ans, et c’est bien plus proche de maintenant que de la date de sortie initiale de curl. Je me demande à partir de quand l’effort nécessaire pour continuer à prendre en charge le temps sur 32 bits ne sera plus jugé utile. Mon pari serait environ 3 mois après la date Y2K38, voire plus tardIl y a quelque chose que les développeurs apprennent quand ils se rapprochent des équipes d’exploitation : plus il y a de dépendants, plus la charge augmente. L’infrastructure et les systèmes centraux, dès qu’un nombre suffisant de choses en dépend, perdent en agilité, et le moindre changement devient vraiment difficile.
Si, dans son propre service avec un backend et un frontend, on veut refondre l’API entre les deux, qui s’en soucie ? Il suffit de le faire.
Mais si l’on veut supprimer un cas limite bizarre du template de base parce que « c’est moche », il faut alors regarder 20 vieux services, 20 services à moitié modernisés que personne ne veut toucher, puis encore 50 services qui les utilisent. Rien que pour estimer l’ampleur du changement, il faut déjà faire tout ce travail. Et à ce stade, on ne parle même pas encore de l’exécution effective du changement ni de rétro-ingénierie de secrets obscurs.
Je ne dirais pas que c’est un travail glamour, mais faire évoluer toute la couche inférieure sans que personne ne s’en aperçoive, tout en continuant à soutenir les vedettes sous les projecteurs, c’est une source de fierté pour les roadies ou les administrateurs
La liste contient aussi pas mal de choses sans nouvelle release depuis plus de 25 ans. Ils produisent encore des builds actuels pour SCO, Xenix, OS/2, NextStep ?
J’ai déjà utilisé certains de ces systèmes et je sais que curl y existe, mais dans mon expérience, c’était toujours une version d’au moins 15 ans.
Si l’on dit qu’on ne veut pas casser une matrice de support, alors qu’une grande partie de cette matrice date de bien plus de 10 ans depuis le dernier build, comment savoir qu’elle n’est réellement pas cassée ?
Pour Xenix, je ne sais même pas si un build est encore possible. Le GCC le plus récent qu’on puisse viser est la 2.7, et c’est déjà une version préhistorique. Avec du code réseau en plus, encore davantage. J’imagine que cela veut surtout dire « à une époque, ça fonctionnait sur ces systèmes »
À propos de l’idée que « de nombreux utilisateurs et entreprises s’obstinent sur des plateformes anciennes, de niche et legacy, et qu’on n’y peut rien », la plupart des gens — y compris les développeurs propriétaires en closed source — produisent des logiciels dont la licence commence par quelque chose comme « ce programme est distribué dans l’espoir qu’il sera utile, mais sans aucune garantie, y compris sans garantie implicite de qualité marchande ou d’adéquation à un usage particulier ».
Cela coûte peu.
À l’inverse, certains, dont moi, développent des logiciels pour lesquels l’adéquation à l’usage est garantie, avec des garanties explicites et absolues.
C’est très cher et très lent.
Si une panne peut tuer quelqu’un, détruire l’environnement ou provoquer des pertes de plusieurs millions de dollars, alors il est logique de continuer à utiliser des plateformes anciennes et de niche qui ont été examinées minutieusement pendant 30 ou 40 ans par des développeurs très lents et très prudents.
C’est en tout cas ce que je me dis quand je regarde Ada sur INTEGRITY sur PowerPC
Si la mort d’une seule personne peut entraîner des pertes de plusieurs millions de dollars, alors il vaut mieux ne pas utiliser un logiciel ou une plateforme dont le vivier de développeurs est aussi restreint que « le nombre de jongleurs français atteints de la maladie de Wilson »
Une des raisons de cette popularité est probablement la licence permissive. Je pensais que c’était une licence MIT, mais elle semble un peu différente [1]. Quelqu’un connaît la différence principale avec MIT, en termes simples ? La page copyright n’entre pas dans les détails.
[1] https://curl.se/docs/copyright.html
« À l’exception de ce qui figure dans le présent avis, le nom du détenteur du copyright ne doit pas être utilisé dans la publicité ou la promotion de la vente, de l’usage ou d’autres transactions portant sur ce logiciel sans autorisation écrite préalable du détenteur du copyright »
[1] https://spdx.org/licenses/curl.html
Je pensais qu’il y aurait presque 100 versions de Linux à elles seules, donc c’est surprenant qu’on arrive à 100 même en comptant toutes les versions de Linux comme un seul système d’exploitation
D’après mon expérience personnelle, écrire du code en tenant compte de plusieurs systèmes legacy tend globalement à améliorer le code
On suit mieux les bonnes pratiques bien connues comme le nommage, les types et la modularisation, et, sauf dans les parties explicitement balisées, la conformité aux standards s’améliore aussi. Les abstractions deviennent plus solides, il y a moins de bugs, surtout sur les plateformes modernes, et le système de build devient plus robuste. Cela rend aussi la compatibilité avec les plateformes futures presque automatique, ou au moins très facile à obtenir.
En revanche, si l’on ne vise que quelques systèmes legacy, ce n’est pas forcément vrai, car on peut survivre avec une combinaison de rustines étranges et de hacks
C’est étrange de lister FreeDOS, DR-DOS et MS-DOS comme des systèmes d’exploitation distincts. Ils sont très proches les uns des autres et, contrairement aux différentes familles Unix, sont en pratique compatibles ABI
Et pourtant, il y a encore des gens qui veulent réécrire ça en Rust. Rust peut-il réellement cibler toutes ces architectures et tous ces systèmes d’exploitation ?
Lecture connexe : un billet expliquant comment curl est né et quelle histoire il a traversée (1)
(1) https://daniel.haxx.se/blog/2023/03/20/twenty-five-years-of-...