curl rodando em 100 sistemas operacionais
(daniel.haxx.se)- O curl limita mudanças para continuar sendo compilado e testado mesmo em ambientes antigos; em um pull request recente, também exigiu a condição de não quebrar a compatibilidade com
time_tde 32 bits e plataformas legadas - O ponto central não é manter uma lista grande de plataformas, mas cumprir o compromisso de estabilidade de ABI/API, para que tudo continue funcionando quando os usuários fizerem upgrade
- Mais importante do que o número de usuários de um sistema operacional específico é se há alguém realmente cuidando e corrigindo problemas; se houver mantenedores, até plataformas com poucos usuários podem continuar recebendo suporte
- O curl e a libcurl se difundiram por sistemas operacionais, arquiteturas de CPU e configurações incomuns graças a um princípio centrado em portabilidade: manter tudo em estado de “compila e executa”
- O principal motivo para comandos antigos do curl falharem costuma estar mais nas mudanças do ambiente da internet, como o desaparecimento de hosts e URLs e a transição de HTTP para HTTPS, do que em mudanças no próprio curl
Critério para mudanças que não quebrem plataformas legadas
- Em um pull request recente do curl, as mudanças só puderam ser mescladas ao repositório de código git se não quebrassem a compilação nem os testes em plataformas legadas
- A mudança envolvia áreas relacionadas a
time_t, e o curl já oferece suporte ao tipotime_tde 32 bits, então esse comportamento precisava ser preservado - O
time_tde 32 bits já tem uso limitado e pode ficar ainda mais restrito à medida que 2038 se aproxima, mas muitas plataformas legadas ainda permanecem em versões de 32 bits - Esse tipo de exigência torna o trabalho dos contribuidores mais difícil, mas no curl isso é tratado como parte do processo de tornar uma mudança completa e bem acabada
Compatibilidade é um compromisso maior do que o número de plataformas
- O projeto curl trabalha continuamente para manter a estabilidade de ABI e API e a compatibilidade
- Uma aplicação que usava libcurl em meados dos anos 2000 pode fazer upgrade para a libcurl mais recente sem recompilar a aplicação e ainda funcionar da mesma forma
- Também é de se esperar que scripts do curl escritos no início dos anos 2000 funcionem quase da mesma maneira nas versões mais recentes do curl
- Essa compatibilidade não é apenas uma frase de marketing, mas um princípio central oferecido pelo curl e pela libcurl
- Os usuários podem depender do curl
- Mesmo que uma release contenha bugs, o projeto busca oferecer atualizações que permitam migrar para uma nova versão sem a dor comum de upgrades de software
- A atitude de não quebrar sem necessidade aquilo que já funciona bem faz parte dos critérios de manutenção
O que determina o suporte são os mantenedores
- O número de usuários de uma plataforma específica não é a principal motivação para o curl continuar dando suporte a ela
- O critério mais importante é quem assume o trabalho e se a manutenção necessária é realmente feita
- Se houver um contribuidor verificando que o curl continue funcionando em determinada plataforma, ele pode continuar rodando mesmo em plataformas conhecidas por terem poucos usuários
- O momento em que uma plataforma praticamente desaparece do curl é quando o código necessário para ela deixa de ser mantido
- Código não mantido ainda pode permanecer funcionando por muitos anos
- Também pode levar muito tempo até se descobrir que o curl já não funciona mais em uma plataforma específica
- Por outro lado, mesmo em uma plataforma com muitos usuários, a manutenção fica difícil se faltarem mantenedores com vontade e conhecimento para lidar com questões específicas dela
Por que se espalhou por tantos ambientes
- O curl e a libcurl têm forte foco em compilar e executar no maior número possível de ambientes
- A atitude de mantê-los funcionando até em configurações peculiares ou estranhas é um dos motivos pelos quais eles se espalharam por vários sistemas operacionais e arquiteturas de CPU
- Muitos usuários e empresas continuam usando plataformas antigas, de nicho ou legadas
- Para eles, manter a funcionalidade de transferência do curl costuma ser melhor em termos de segurança do que uma implementação alternativa feita internamente
- Se não houver necessidade de quebrar uma funcionalidade, aplica-se o julgamento de que é melhor permitir que os usuários existentes continuem dependendo do curl
Remoção de suporte é lenta e pública
- O curl também remove alguns suportes de tempos em tempos
- Os principais alvos de remoção são suportes a bibliotecas de terceiros cujo uso está diminuindo e desaparecendo, mas a remoção de suporte também pode ocorrer em outras áreas
- A descontinuação de suporte é feita de forma lenta, cuidadosa e comunicada publicamente
- Usuários interessados precisam poder saber das mudanças com antecedência
- Os usuários devem poder se preparar ou se opor caso a proposta pareça injustificada
- Se os usuários não conseguem perceber uma mudança de comportamento, isso não é considerado uma mudança
- O curl foi feito para os usuários, e se eles continuam querendo determinado comportamento, esse comportamento deve ser mantido
O verdadeiro motivo de comandos antigos falharem
- Protocolos e versões da internet surgem e desaparecem com o passar do tempo
- A maioria das linhas de comando do curl escritas em 2002 pode não funcionar hoje exatamente como antes
- O motivo da falha pode não ser o próprio curl, mas os nomes de host e URLs usados na época que já não funcionam mais
- Um dos grandes motivos para um comando curl de 2002 não funcionar hoje exatamente da mesma forma é a transição de HTTP para HTTPS
- Mesmo que houvesse sites usando TLS ou SSL em 2002, isso não era comum na época, e as versões do protocolo TLS usadas então podem hoje ser consideradas inseguras
- Bibliotecas TLS modernas e o curl podem recusar conexão com configurações TLS antigas que não foram atualizadas
- Mesmo que você tenha guardado um executável do curl de 2002 e o execute hoje, ele pode não conseguir se conectar a sites HTTPS modernos
- Isso não ocorre por causa de mudanças no curl, mas por causa de mudanças na camada do protocolo de transferência
1 comentários
Opiniões no Hacker News
Uma conquista impressionante. O Curl é uma ferramenta realmente abençoada.
Achei interessante Daniel destacar o time_t de 32 bits como um ponto importante de compatibilidade. Se o objetivo é continuar funcionando em vários sistemas operacionais, faz todo sentido. Só que 2038 agora está a apenas 14 anos de distância, muito mais perto de hoje do que da época em que o curl surgiu. Fico curioso para saber quando o esforço de dar suporte a tempo de 32 bits deixará de ser considerado valioso. Meu palpite é uns 3 meses depois da data Y2K38, talvez até mais.
Há algo que desenvolvedores aprendem ao se aproximarem das equipes de operação. Quanto mais coisas dependem de você, maior o peso. Infraestrutura e sistemas centrais, quando passam a sustentar coisas demais, perdem agilidade, e até mudanças pequenas ficam realmente difíceis.
Se você tem seu próprio serviço com backend e frontend e quer refazer a API entre os dois, quem se importa? É só fazer.
Mas, se você quer eliminar algum caso de borda estranho no template padrão porque ele é “feio”, precisa olhar para 20 serviços antigos, 20 serviços meio modernizados nos quais ninguém quer mexer e mais 50 serviços que usam isso. E isso é só o trabalho necessário para entender o tamanho da mudança. Nesse ponto, nem estamos falando ainda de executar a mudança de fato ou de fazer engenharia reversa de segredos obscuros.
Eu não diria que é um trabalho glamouroso, mas manter os protagonistas brilhando enquanto você troca tudo por baixo sem que ninguém perceba dá orgulho a roadies e administradores.
Há várias coisas na lista que não têm um lançamento há mais de 25 anos. Ainda estão fazendo builds atuais para SCO, Xenix, OS/2, NextStep?
Já usei esses sistemas e sei que o curl existe neles, mas, na minha experiência, esse curl sempre tinha pelo menos 15 anos de idade.
Se você diz que não quer quebrar uma matriz de suporte, mas boa parte dessa matriz passou muito mais de 10 anos desde o último build, como saber que ela de fato não foi quebrada?
Não sei se seria possível fazer build para Xenix. O GCC mais recente que dá para usar como alvo é o 2.7, e ele próprio já é antigo. Ainda mais considerando o código de rede. Provavelmente é mais um “em algum momento isso funcionou nesses sistemas”.
Sobre a frase “incontáveis usuários e empresas insistem em plataformas antigas, de nicho e legadas, e não há nada que possamos fazer”, a maioria das pessoas, incluindo desenvolvedores de software proprietário de código fechado, faz software cuja licença começa com algo como “este programa é distribuído na esperança de que seja útil, mas SEM NENHUMA GARANTIA, sem sequer a garantia implícita de COMERCIALIZAÇÃO ou ADEQUAÇÃO A UM DETERMINADO FIM”.
Isso tem custo baixo.
Já alguns, incluindo eu, desenvolvemos software com adequação ao propósito garantida, com garantias explícitas e absolutas.
Isso é muito caro e lento.
Se algo quebrar e alguém puder morrer, o meio ambiente puder ser destruído ou o prejuízo puder chegar a milhões de dólares, faz sentido continuar usando uma plataforma antiga e de nicho que foi examinada minuciosamente por desenvolvedores muito lentos e cuidadosos ao longo de 30 ou 40 anos.
Pelo menos é isso que digo a mim mesmo quando estou olhando Ada no INTEGRITY em PowerPC.
Se a morte de uma pessoa pode gerar prejuízo de milhões de dólares, então o certo é não usar software ou plataforma cujo grupo de desenvolvedores seja tão pequeno quanto o “número de malabaristas franceses com doença de Wilson”.
Acho que um motivo dessa popularidade é a licença permissiva. Imaginei que fosse a licença MIT, mas parece ser um pouco diferente [1]. Alguém sabe explicar, em termos simples, quais são as principais diferenças em relação à MIT? A página de copyright não traz uma explicação detalhada.
[1] https://curl.se/docs/copyright.html
“Exceto conforme contido neste aviso, o nome de um detentor de direitos autorais não deve ser usado em publicidade ou de outra forma para promover a venda, o uso ou outros negócios com este Software sem autorização prévia por escrito do detentor dos direitos autorais.”
[1] https://spdx.org/licenses/curl.html
Achei que só as versões de Linux já chegariam perto de 100, então é surpreendente que sejam 100 mesmo contando todas as versões de Linux como um único sistema operacional.
Pela minha experiência pessoal, escrever código levando em conta vários sistemas legados geralmente deixa o código melhor.
Você passa a seguir melhor práticas conhecidas de programação, como nomenclatura, tipos e modularização, e também melhora a conformidade com padrões, exceto nas partes claramente marcadas. As abstrações ficam mais sólidas, há menos bugs especialmente em plataformas modernas, e o sistema de build também fica mais robusto. Ele se torna automaticamente compatível com plataformas futuras ou, no mínimo, muito fácil de tornar compatível.
Mas, se você mirar apenas alguns poucos sistemas legados, talvez isso não se aplique, porque dá para sobreviver com uma combinação de remendos e hacks peculiares.
É estranho listar FreeDOS, DR-DOS e MS-DOS como sistemas operacionais separados. Eles são muito parecidos e, ao contrário de diferentes famílias Unix, são na prática compatíveis em ABI.
Ainda assim, há gente querendo reescrever isso em Rust. O Rust consegue realmente ter como alvo todas essas arquiteturas e sistemas operacionais?
Leitura relacionada: um texto sobre como o curl nasceu e qual foi sua história (1)
(1) https://daniel.haxx.se/blog/2023/03/20/twenty-five-years-of-...