curl se ejecuta en 100 sistemas operativos

• curl limita los cambios para que siga compilando y probándose incluso en entornos antiguos; en un pull request reciente también exigió no romper la compatibilidad con plataformas heredadas ni con time_t de 32 bits
• Lo central no es mantener una larga lista de plataformas, sino cumplir la promesa de estabilidad ABI/API para que todo siga funcionando cuando los usuarios actualicen
• Más que la cantidad de usuarios de un sistema operativo específico, importa que haya alguien que realmente lo cuide y lo corrija; si quedan mantenedores, también pueden seguir soportándose plataformas con pocos usuarios
• curl y libcurl se expandieron bajo un principio centrado en la portabilidad, manteniéndose en estado de “compila y se ejecuta” en sistemas operativos, arquitecturas de CPU y configuraciones inusuales
• La principal razón por la que fallan comandos antiguos de curl suele estar más relacionada con cambios del entorno de Internet, como la desaparición de hosts y URLs y la transición de HTTP a HTTPS, que con cambios en curl

---

Criterios de cambio para no romper plataformas heredadas

• En un pull request reciente de curl, los cambios solo podían fusionarse en el repositorio de código git si no rompían la compilación ni las pruebas en plataformas heredadas
• El cambio estaba relacionado con time_t, y curl ya soporta el tipo time_t de 32 bits, por lo que debía conservar ese comportamiento
• time_t de 32 bits ya tiene un uso limitado y sus restricciones pueden aumentar a medida que se acerca 2038, pero muchas plataformas heredadas siguen estando en versiones de 32 bits
• Este tipo de requisito dificulta el trabajo de los contribuidores, pero en curl se trata como parte del proceso para completar bien un cambio

La compatibilidad es una promesa más grande que la cantidad de plataformas

• El proyecto curl se esfuerza continuamente por mantener la estabilidad ABI y API y la compatibilidad
• Una aplicación que usaba libcurl a mediados de los años 2000 puede actualizarse a la libcurl más reciente y seguir funcionando de la misma manera sin recompilar la aplicación
• También se puede esperar que un script de curl escrito a principios de los años 2000 funcione casi de la misma manera en una versión reciente de curl
• Esta compatibilidad no es un simple eslogan promocional, sino un principio central que ofrecen curl y libcurl
  • Los usuarios pueden depender de curl
  • Incluso si hay una versión con errores, el proyecto busca ofrecer actualizaciones que permitan pasar a una versión nueva sin el dolor habitual de actualizar software
• La actitud de no romper innecesariamente algo que ya funciona bien forma parte de los criterios de mantenimiento

Lo que define el soporte son los mantenedores

• La cantidad de usuarios de una plataforma específica no es el principal motivo por el que curl decide seguir soportándola
• El criterio más importante es quién se hace cargo del trabajo y si realmente se realiza el mantenimiento necesario
• Si hay un contribuidor que verifica que curl siga funcionando en una plataforma, curl puede seguir ejecutándose incluso en plataformas conocidas por tener pocos usuarios
• El momento en que una plataforma prácticamente desaparece de curl es cuando el código necesario para esa plataforma deja de mantenerse
  • Incluso el código sin mantenimiento puede permanecer funcionando durante muchos años
  • También puede pasar mucho tiempo hasta descubrir que curl ya no funciona en una plataforma específica
• Por el contrario, incluso en una plataforma con muchos usuarios, el mantenimiento se vuelve difícil si faltan mantenedores con la voluntad y el conocimiento para atender los problemas propios de esa plataforma

Por qué se extendió a tantos entornos

• curl y libcurl se enfocan fuertemente en compilarse y ejecutarse en la mayor cantidad posible de entornos
• La actitud de mantenerlo funcionando incluso en configuraciones particulares o extrañas es una de las razones por las que se extendió a muchos sistemas operativos y arquitecturas de CPU
• Muchos usuarios y empresas siguen usando plataformas antiguas, de nicho o heredadas
• Para ellos, mantener las capacidades de transferencia de curl suele ser mejor en términos de seguridad que crear una implementación alternativa propia
• Si no hay necesidad de romper una funcionalidad, se aplica el criterio de que es mejor permitir que los usuarios existentes sigan dependiendo de curl

La eliminación de soporte es lenta y pública

• curl también elimina parte del soporte de vez en cuando
• El principal objetivo de eliminación suele ser el soporte para bibliotecas de terceros cuyo uso disminuye y están desapareciendo, aunque también puede ocurrir en otras áreas
• La retirada de soporte se realiza de forma lenta, cuidadosa y con comunicación pública
  • Los usuarios que quieran saberlo deben poder enterarse de los cambios con anticipación
  • Los usuarios deben poder prepararse o, si la propuesta parece injustificada, oponerse
• Si los usuarios no pueden percibir un cambio de comportamiento, no se considera que eso haya cambiado
• curl fue creado para los usuarios, y si los usuarios quieren que un comportamiento continúe, ese comportamiento debe mantenerse

La verdadera razón por la que fallan los comandos antiguos

• Los protocolos y versiones de Internet aparecen y desaparecen con el tiempo
• La mayoría de las líneas de comando de curl escritas en 2002 podrían no funcionar hoy tal como están
• La razón del fallo puede no ser curl en sí, sino que los nombres de host y URLs usados en ese momento ya no funcionan
• Una de las grandes razones por las que un comando de curl de 2002 no funciona hoy sin cambios es la transición de HTTP a HTTPS
• Aunque en 2002 hubiera sitios que usaban TLS o SSL, en ese entonces no era algo común, y las versiones del protocolo TLS usadas entonces pueden considerarse inseguras hoy
• Las bibliotecas TLS modernas y curl pueden rechazar conexiones a configuraciones TLS antiguas que no se han actualizado
• Incluso si se conservara un ejecutable de curl de 2002 y se ejecutara hoy, es posible que no pudiera conectarse a sitios HTTPS modernos
  • Esto no se debe a cambios en curl, sino a cambios en la capa de protocolos de transferencia

[GN⁺]

Opiniones en Hacker News

• Un logro impresionante. Curl es realmente una bendición como herramienta.
  Es interesante que Daniel haya destacado time_t de 32 bits como un punto importante de compatibilidad. Si el objetivo es que siga funcionando en muchos sistemas operativos, tiene todo el sentido. Pero 2038 está a solo 14 años, y hoy está mucho más cerca que el momento en que apareció curl por primera vez. Me pregunto cuándo se considerará que el esfuerzo de soportar tiempo de 32 bits ya no vale la pena. Mi apuesta es que será unos 3 meses después de la fecha Y2K38, o quizá incluso más tarde.

• Hay algo que los desarrolladores aprenden al acercarse a la gente de operaciones. Mientras más cosas dependan de ti, mayor es la carga. La infraestructura y los sistemas centrales pierden agilidad cuando suficientes cosas dependen de ellos, y hasta los cambios menores se vuelven realmente difíciles.
  Si en tu propio servicio, con backend y frontend, quieres rehacer la API entre ambos, ¿a quién le importa? Simplemente lo haces.
  Pero si quieres eliminar un caso límite raro de una plantilla base porque es “feo”, tienes que revisar 20 servicios antiguos, 20 servicios medio modernizados que nadie quiere tocar, y otros 50 servicios que la usan. Y eso es solo el trabajo necesario para entender qué tan grande sería el cambio. En esta etapa ni siquiera estamos hablando de ejecutar el cambio real ni de hacer ingeniería inversa de secretos inescrutables.
  No diría que sea un trabajo glamoroso, pero mantener en pie a las estrellas brillantes mientras cambias todo por debajo sin que nadie se dé cuenta les da orgullo a los roadies o a los administradores.

• En la lista hay bastantes cosas que no han tenido releases en más de 25 años. ¿De verdad todavía están generando builds actuales para SCO, Xenix, OS/2 y NextStep?
  He usado esas cosas, y sé que curl existe ahí, pero según mi experiencia ese curl siempre tenía al menos 15 años de antigüedad.
  Si dicen que no quieren romper cierta matriz de soporte, pero una parte importante de esa matriz lleva mucho más de 10 años desde su último build, ¿cómo saben que en realidad no está rota?

  • Creo que 25 años es incluso una forma bastante generosa de decirlo.
    No sé si se podrá compilar para Xenix. El GCC más nuevo que se podría usar como objetivo es 2.7, y eso ya es antiquísimo. Más aún si consideramos el código de red. Probablemente signifique algo como “en algún momento funcionó en esos sistemas”.
  • En comparación, AmigaOS sigue muy vivo. Su release más reciente salió en 2021.
  • Si Xenix u OS/2 no han cambiado, ¿por qué un build antiguo de Curl se rompería de pronto ahí?
  • SkyOS también es un buen ejemplo. A estas alturas, probablemente sea más seguro eliminarlo que asumir que alguien realmente lo está ejecutando en SkyOS.

• Sobre la frase “muchísimos usuarios y empresas se aferran a plataformas antiguas, de nicho y legacy, y no hay nada que podamos hacer”, la mayoría de la gente, incluso desarrolladores de software propietario y de código cerrado, crea software cuya licencia empieza con algo como: “este programa se distribuye con la esperanza de que sea útil, pero sin ninguna garantía, ni siquiera la garantía implícita de comerciabilidad o adecuación para un propósito particular”.
  Eso tiene bajo costo.
  En cambio, algunos, incluyéndome, desarrollamos software con adecuación para el propósito garantizada, con garantías explícitas y absolutas.
  Eso es muy caro y lento.
  Si cuando algo se rompe puede morir una persona, dañarse el ambiente o producirse pérdidas de millones de dólares, tiene sentido seguir usando plataformas antiguas y de nicho que durante 30 o 40 años han sido revisadas minuciosamente por desarrolladores muy lentos y cuidadosos.
  Al menos eso me digo cuando estoy mirando Ada sobre INTEGRITY en PowerPC.

  • Te contradices dentro de esa misma frase.
    Si la muerte de una persona puede traducirse en daños de millones de dólares, entonces conviene no usar software o plataformas cuyo grupo de desarrolladores sea tan pequeño como “la cantidad de malabaristas franceses con enfermedad de Wilson”.

• Creo que una razón de esta popularidad es la licencia permisiva. Supuse que sería la licencia MIT, pero parece ser algo un poco distinto [1]. ¿Alguien sabe explicar en palabras simples cuáles son las principales diferencias con MIT? La página de copyright no da una explicación detallada.
  [1] https://curl.se/docs/copyright.html

  • Comparada con la licencia MIT, la principal cláusula adicional parece ser esta:
    “Salvo lo contenido en este aviso, el nombre de un titular de copyright no se usará en publicidad ni de otro modo para promover la venta, uso u otros tratos relacionados con este Software sin autorización previa por escrito del titular de copyright”.
  • Como dice la página, parece ser una licencia personalizada inspirada en la licencia MIT/X11. La única diferencia con MIT/X11 parece ser que la parte inicial de la exención de garantías se acortó. Tiene una entrada separada en SPDX [1].
    [1] https://spdx.org/licenses/curl.html
  • Parece una mezcla de la licencia MIT con la tercera cláusula de la licencia BSD 3-Clause.

• Pensé que habría casi 100 versiones de Linux, pero me sorprende que lleguen a 100 incluso contando todas las versiones de Linux como un solo sistema operativo.

  • Sí, aunque están contando iOS, iPadOS y watchOS como sistemas operativos separados, así que en realidad son como 98 sistemas operativos. Eso no es nada… cualquiera podría hacerlo…

• Según mi experiencia personal, escribir código teniendo en cuenta varios sistemas legacy suele mejorar el código en general.
  Terminas siguiendo mejor prácticas de programación conocidas como nombres, tipos y modularización, y también mejoras el cumplimiento de estándares salvo en las partes marcadas explícitamente. Las abstracciones se vuelven más sólidas, hay menos bugs especialmente en plataformas modernas, y el sistema de build se vuelve más robusto. Además, queda automáticamente compatible con plataformas futuras o, al menos, resulta muy fácil hacerlo compatible.
  Eso sí, si solo apuntas a unos pocos sistemas legacy, quizá esto no aplique, porque puedes sobrevivir con una combinación de parches raros y hacks.

• Es raro listar FreeDOS, DR-DOS y MS-DOS como sistemas operativos separados. Son muy parecidos entre sí y, a diferencia de distintos Unix, en la práctica son compatibles a nivel de ABI.

  • Casi. Como todos sabemos, DR-DOS, MS-DOS y PC-DOS eran compatibles en un 99% más o menos, y el problema era cuando tenías la mala suerte de caer en ese 1%. DR-DOS hizo ingeniería inversa de MS-DOS, e incluso la licencia de PC-DOS de IBM no le daba acceso a todo lo que Microsoft hacía en MS-DOS.
  • DR-DOS es un descendiente directo de CP/M con compatibilidad ABI con MS/PC-DOS, así que claramente es un sistema operativo separado. FreeDOS también. Si miras por dentro, cada uno tiene diferencias suficientes.
  • También listaron OPENSTEP y NeXTSTEP como sistemas operativos separados…

• Y aun así hay gente que quiere reescribir esto en Rust. ¿Rust realmente puede apuntar a todas esas arquitecturas y sistemas operativos?

  • ¿Por qué alguien querría reescribir curl? ¿Qué tiene de malo usar C?

• Lectura relacionada: un texto sobre cómo nació curl y qué historia ha tenido (1)
  (1) https://daniel.haxx.se/blog/2023/03/20/twenty-five-years-of-...