Se você criar um executável que funcione em uma versão atual do Windows, esse executável provavelmente funcionará por muitos anos em versões mais recentes do Windows. A Microsoft trabalha muito para garantir isso.
Com o Linux, há uma expectativa de que você tenha o código-fonte do software que está usando e, portanto, quebrar a compatibilidade binária é aceitável, desde que você mantenha a compatibilidade de origem. Isso faz com que as distros eliminem versões antigas de bibliotecas e quebrem periodicamente coisas que costumavam funcionar.
Para quem usa Linux como plataforma de jogos, isso é um problema, pois os jogos tendem a ser distribuídos apenas em formato binário. Isso faz com que as portas do Linux pareçam ruins quando quebram, mas tenho a sensação de que seria mais produtivo tentar resolver esse problema de maneira geral, em vez de esperar que todos atualizem suas portas.
Existem distribuições que tentam preservar a compatibilidade binária, não necessariamente mantendo todas as versões antigas, mas pelo menos mantendo os nomes antigos, de modo que um binário que funciona com a versão n também funcione com a versão n+1?
A coisa mais próxima que posso encontrar é o “Steam Runtime” da Valve, que é uma camada de compatibilidade binária disponível apenas para programas distribuídos pelo Steam.
Responder1
Basicamente isso se resume a:você não pode manter a compatibilidade binária e introduzir novos recursos, uma vez que essas coisas vão diretamente uma contra a outra na maioria dos aspectos. Se você introduzir novos recursos importantes, no finalprecisaalterar a ABI (geralmente logo após as alterações na API). Agora, você pode ter símbolos versionados (como por exemplo o Glibc), mas isso faz com que as bibliotecas aumentem de tamanho (e também pode incorrer em alguma penalidade de desempenho ao carregar um binário na memória) e os desenvolvedores certamente não querem mantê-lo em geral bibliotecas (o código legado contém bugs que ninguém está interessado em consertar).
A maneira usual de contornar isso no lado da distribuição é dupla:
não altere as versões - isso é típico para distribuições de nível empresarial como (em ordem alfabética) RedHat e SUSE, bem como para algumas outras (Debian, Slackware, Ubunty LTS e provavelmente seus clones).
permitir a instalação de várias versões de uma biblioteca ao mesmo tempo.
No distribuidor de aplicativos, isso é feito da mesma maneira que no Windows: coloque tudo o que for necessário no pacote de distribuição. Sim, é assim que geralmente é feito no Windows - essa também é uma das razões para o sistema Windows típico geralmente ter requisitos de espaço em disco várias vezes maiores do que o Linux com a mesma funcionalidade - os aplicativos simplesmente compartilham muito pouco entre si e tenha suas próprias cópias em algum lugar. Você pode pensar nisso como cada aplicativo GTK/Qt que vem com sua própria pilha GTK/Qt. Pode ter algumas vantagens, mas as desvantagens também são abundantes. Por exemplo, do ponto de vista da segurança, é um pesadelo no Technicolor ™ . Se os binários estiverem vinculados estaticamente, é até em FullHD.