Retrocompatibilidade - O calcanhar de Aquiles do Linux (todas as distros)

Mudam os ícones, o menu, o wallpaper… mas no geral, é o mesmo código da década de 80. A Microsoft não reescreve o Windows a cada nova versão.

1 curtida

Caraca, isso é verdade? Mas e os patchs de segurança e atualizações? Desculpe-me pela ignorância, gostaria de saber mais sobre isto.

1 curtida

Como o nome diz, são remendos, não reescrita completa do código.
O mesmo acontece no kernel Linux e diversos programas complexos. Reescrever do zero é complicado para as empresas, pois podem surgir novos bugs.
Acredito que o Plasma seja a excessão.

3 curtidas

:wave:t2:

Acredito que também iremos ter no futuro o Fuchsia OS da Google, a pronúncia dele é parecida com a palavra inglesa Future, mas não sei se isso teria conexões. O nome Fuchsia se deve a um gênero de flores dado pelo alemão físico e botânico do século 16, Leonhard Fuchs.

Este sistema operacional está sendo escrito do zero pela Google, inclusive o Kernel que deixará de ser Linux e passará a se chamar Zircon e este OS pretende substituir o Android e o Chrome OS fazendo semelhante ao que os OS da Apple fazem (acredito que foco no ecossistema). Mas o projeto deve levar muitos anos (ou não, pois talvez a Google tenha condições para isso levar meses, se ela quiser).

Aparentemente a Samsung pretende trocar o Android pelo Fuchsia no futuro, segundo informações do Techradar da data de 23/12/2021 mas… Isso mostra que o Fuchsia OS está levando anos mesmo :sweat_smile:.

:vulcan_salute:t2:

1 curtida

A Retrocompatibilidade do Kernel Linux e sua Relação com a Portabilidade de Softwares para Novas Versões

Gostaria de contribuir com a discussão.

O kernel Linux é uma parte essencial do sistema operacional que desempenha um papel crítico na execução de aplicativos e na interação com o hardware. Um dos princípios fundamentais que guiam o desenvolvimento do kernel Linux é a retrocompatibilidade, que se refere à capacidade de versões mais recentes do kernel executarem aplicativos e drivers desenvolvidos para versões mais antigas. Essa retrocompatibilidade desempenha um papel crucial na portabilidade de software para novas versões do kernel.

Neste artigo, exploraremos a importância da retrocompatibilidade do kernel Linux e como ela está intrinsecamente relacionada à portabilidade de softwares. Além disso, consideraremos situações específicas, como o uso das bibliotecas gráficas QT e GTK, que podem influenciar a equação.

Retrocompatibilidade no Kernel Linux

A retrocompatibilidade é um dos pilares do desenvolvimento do kernel Linux. Isso significa que o kernel se esforça para garantir que aplicativos e drivers desenvolvidos para versões mais antigas do kernel continuem funcionando em versões mais recentes. Isso é alcançado por meio de várias estratégias e práticas:

1. APIs Estáveis

O kernel Linux mantém APIs (Application Programming Interfaces) estáveis sempre que possível. Isso significa que as interfaces de programação usadas por aplicativos e drivers tendem a permanecer consistentes entre versões do kernel. A estabilidade das APIs ajuda a garantir que os aplicativos escritos para versões mais antigas continuem funcionando sem a necessidade de grandes modificações.

2. Camada de Abstração de Hardware

O kernel Linux fornece uma camada de abstração de hardware, separando os aplicativos do hardware subjacente. Isso permite que os aplicativos e drivers interajam com o hardware por meio de interfaces padronizadas, independentemente das especificidades do hardware subjacente. Essa abstração ajuda a garantir a portabilidade, uma vez que os aplicativos não precisam conhecer os detalhes específicos do hardware em que estão sendo executados.

3. Módulos e Carregamento Dinâmico

O kernel Linux suporta módulos, que são partes do kernel que podem ser carregadas ou descarregadas dinamicamente em tempo de execução. Isso facilita a inclusão de drivers específicos de hardware sem a necessidade de recompilar o kernel principal. Essa flexibilidade ajuda a garantir a retrocompatibilidade, uma vez que os drivers podem ser atualizados independentemente do kernel.

4. Testes Extensivos

Antes de lançar uma nova versão do kernel Linux, os desenvolvedores e a comunidade realizam testes extensivos em uma ampla variedade de hardware para garantir que a retrocompatibilidade seja mantida e que os aplicativos e drivers existentes continuem funcionando.

5. Documentação Abrangente

O projeto Linux oferece uma documentação abrangente para ajudar na portabilidade e na criação de software compatível com o kernel. Essa documentação ajuda os desenvolvedores a entender as práticas recomendadas e as interfaces a serem usadas para garantir que seus aplicativos e drivers funcionem em várias versões do kernel.

A Relação entre Retrocompatibilidade e Portabilidade

A retrocompatibilidade do kernel Linux desempenha um papel crucial na portabilidade de software para novas versões do kernel. No entanto, é importante entender que a retrocompatibilidade do kernel não implica automaticamente na facilidade de portar versões antigas de software para versões mais recentes. A portabilidade de software entre versões de kernel pode envolver considerações adicionais, como mudanças nas APIs e interfaces, dependências de bibliotecas e compatibilidade de hardware.

Mudanças nas APIs e Interfaces

Apesar dos esforços para manter APIs estáveis, podem ocorrer mudanças em APIs específicas em novas versões do kernel. Aplicativos que dependem fortemente dessas APIs podem exigir ajustes para funcionar em novas versões. Portanto, os desenvolvedores devem estar atentos às alterações e atualizar seus aplicativos, se necessário.

Dependências de Bibliotecas

Além do kernel, aplicativos frequentemente dependem de bibliotecas de sistema. A portabilidade de software também envolve garantir que essas bibliotecas estejam disponíveis e sejam compatíveis com a versão do kernel em uso. Isso significa que os desenvolvedores devem considerar a compatibilidade não apenas com o kernel, mas também com as bibliotecas subjacentes.

Compatibilidade de Hardware

Aplicativos que interagem diretamente com hardware específico podem enfrentar desafios adicionais ao atualizar o kernel. As mudanças de hardware podem exigir modificações nos aplicativos para garantir que continuem funcionando de maneira confiável.

QT e GTK: Exemplos de Desafios de Portabilidade

Além das considerações gerais de portabilidade, algumas situações específicas podem influenciar a equação. Por exemplo, as bibliotecas gráficas QT e GTK são amplamente utilizadas no desenvolvimento de aplicativos Linux e têm sua própria dinâmica de versões. Mudanças nessas bibliotecas podem impactar a portabilidade de aplicativos que as utilizam. Os desenvolvedores precisam considerar a compatibilidade dessas bibliotecas com o kernel e com outras bibliotecas para garantir a portabilidade.

Conclusão

A retrocompatibilidade do kernel Linux é fundamental para garantir que aplicativos e drivers desenvolvidos para versões mais antigas do kernel continuem funcionando em versões mais recentes. Isso facilita a transição para novas versões do kernel, minimizando a necessidade de modificações significativas. No entanto, a portabilidade de software entre versões de kernel pode envolver desafios adicionais relacionados a mudanças nas APIs, dependências de bibliotecas e compatibilidade de hardware.

Os desenvolvedores de software precisam estar cientes dessas considerações e investir em testes e validação adequados para garantir que seus aplicativos funcionem de maneira confiável em um ambiente com uma versão mais recente do kernel. A retrocompatibilidade do kernel Linux é uma base sólida, mas a portabilidade bem-sucedida requer atenção aos detalhes e considerações específicas do software em uso.

2 curtidas

Por isso mesmo que eu disse e repeti: foi usado o termo errado. Parabéns pelo conteúdo.

2 curtidas

Brigadu !! :+1:

1 curtida

isso e verdade,ent pq tem versoes pra windows 10 e 11,tem alguma diferença neles?

Essa questão de retrocompatibilidade é importante, e nesse quesito um programa escrito para o Windows XP (ano 2003) permanece rodando até no Windows 10 sem muitos esforços. Mas já pensaram porque isso acontece?
Um dos motivos é a API do Win32 que permaneceu versões após versões retrocompatível, e nesse caso é sim um feito da Microsoft. Outro motivo é que muitos programas do Windows já trazem suas bibliotecas juntos no instalador, uma vez que é raro isso acontecer no Linux.

Porém a retrocompatibilidade no Linux vem melhorando. Hoje, é possível usar um sistema Ubuntu LTS2 por até 10 (dez) anos sem atualizar para uma nova versão (somente recebendo atualizações de segurança e correções). Red Hat, Oracle Linux, EuroLinux, AlmaLinux e outros já saem de largada te dando 10 anos de suporte, o que vai garantir que sua aplicação possa rodar no mínimo 10 anos sem maiores preocupações.

De outro lado, as distribuições focadas no setor empresarial trabalham para que as novas versões não quebrem totalmente a compatibilidade com software legado. É por isso que muitas distribuições carregavam o Python3 quando o Python4 já era o padrão, ou ainda softwares desenvolvidos em GTK2 que continuam executando no Ubuntu desde que essa tecnologia foi abandonada em 2011.

As novas tecnologias como Flatpak, Appimage e Snap estão permitindo que softwares antigos possam ser executados em distribuições modernas, justamente fazendo aquilo que no Windows já é padrão: carregar as bibliotecas necessárias para executar o programa num único pacote. Saiba que na Snap Store há pacotes de programas que foram compilados no Ubuntu 18.04 e que continuam rodando no Ubuntu 23.10 (cinco anos), ou seja, permitindo que software antigo possa continuar rodando em novas máquinas que necessitam de sistema operacional mais novo.

Não apenas isso, mas é possível fazer uma única compilação e rodá-la nas diversas versões do Ubuntu, OpenSuse, RHEL, Fedora, Debian e muitos outras distribuições.

Quando eu usei Slackware na minha máquina, e considerando que na época meu acesso a internet era limitado, eu era capaz de rodar softwares baixados para o Mandriva Linux e Suse Linux numa instalação do Slackware. Eu fazia isso porque não poderia ficar baixando novos pacotes a todo momento, e sempre tinha um backup de pacotes de outras distribuições que eu já havia usado.

Atualmente há um pacote .DEB do Word Perfect, do final da década de 90, totalmente funcional que roda no Ubuntu 22.04 (possivelmente rode até em versões mais recentes).

Quanto a aplicações do Windows, saiba que o Linux é capaz de rodar aplicações que o Windows 10 e Windows 11 não conseguem rodar. Diversas aplicações feitas para Windows 3.1 e Windows 95 não rodam mais nos sistemas modernos da Microsoft, mas várias dessas aplicações rodam nas distribuições Linux modernas através do Wine. Por fim, o Wine permite essa retrocompatibilidade que é maior do que a oferecida pela própria Microsoft.

O Linux é capaz de rodar aplicações legadas do MS-DOS através do Dosbox-X, uma versão do Dosbox adicionada de ferramentas para permitir rodar aplicações (não somente games) da década de 80/90. Aliás, é possível utilizar diversas ferramentas para rodar programas legados, desde contêineres até máquinas virtuais.

2 curtidas

Shell do Windows foi o que mundou. Por trás dos panos é o bom e velho Kernel NT com softlocks para hardware “antigo”. Não é porque tem uma carinha nova que significa que por de baixo dos panos houve mudanças significativas…

2 curtidas

Rumores sobre o Fuchsia rolam por aí desde meados de 2016. Não dá para saber se estão se empenhando muito no desenvolvimento, ou adiando ele.

Há um spoiler sobre ele no Chrome: quase todas as tags em chrome://flags possuem esse nome nas plataformas compatíveis.

3 curtidas

As última grandes mudanças da bases do código do sistema se deram em 2001 com a ascenção do Windows XP, baseado no kernel NT (que até então só circulava nas linhas profissionais do Windows). Desde então, as mudanças de versão para versão são incrementais, com atualizações de alguns componentes do sistema, como o gerenciador de janelas e o shell. Via de regra, você ainda consegue rodar programas feitos pro XP no 11 com alguns míseros tweaks que o próprio Windows já faz por ti. Também não para todos, mas para alguns programas escritos pro 95/98/ME também.

1 curtida

Vou rebater seu argumento com uma história:

O Linux sempre teve soluções CAD meio aquém do Windows e Mac, pensando nisso a Draftsight resolveu lançar seu CAD para Linux. Ele usa Qt e AppImage isso significa que: Mesmo código pra Linux, Mac e Windows e a receita de compilação do software suportaria no mínimo uns 10 anos. A empresa interagia com a comunidade, ouvia feedbacks e chegou até a ganhar semanas de destaque nas maiores comunidades Linux… Aí quando finalmente ganhou tração no mercado o que ela fez? Cortou abruptamente o suporte a Linux, as versões beta foram remotamente bloqueadas e as novas versões passaram a indentificar o Wine e barrar a instalação “por segurança”…

Moral da história: Não adiantou a comunidade acolher, não adiantou ser retrocompativel, não adiantou suportar por 10 anos a mesma API e ABI, a empresa quis ser mal caráter e foi mal caráter, é a exata mesma coisa com Adobe, Microsoft, Epic Games, Roblox Corporation… O problema não é o Linux não suportar as distros em si rodam muito bem os softwares mesmo quando não estão compilados pra Linux, PORÉM por MAL CARATISMO de muitas empresas o pinguim é simplesmente sabotado, o instalador (ou mesmo o próprio software) usam rotinas de verificação ativa do Wine e barram a execução

Então não é porque Linux é um sistema pra devs e os devs não tem do que reclamar, é simplesmente porque as empresas NÃO QUEREM que o software delas rode no linux de nenhuma maneira, curiosamente muitas dessas empresas que sabotam ativamente o Linux tem suas versões para Mac do sistema usando Wine por isso dá pra saber que realmente é sabotagem e sabotagem intencional

3 curtidas

A sua ideia é excelente, não tenho dúvidas disso. O problema é que uma distro com suporte pago como a redhat é caríssima pois é voltado a corporações e não tem uma versão para o usuário comum que é a massacrante demanda pelos softwares pagos como um AUTOCAD da vida.

E ainda que a redhat resolvesse fazer uma versão para o usuário comum, neste momento não adianta eu pagar uma distro enquanto as empresas de softwares estão deixando de produzir suas versões para linux.

O ponto que reclamo é do desleixo das distros com o quesito da segurança de que um mesmo software fechado e pago vai continuar rodando na plataforma independentemente da versão posterior ou atualizações que fizer.

Mas tipo, eu já tomei uma decisão. Como estamos num mato sem cachorro vou ter de me contentar em usar um vmware onde nele manterei rodando o windows e o linux ao mesmo tempo em que farei coisas bem específicas em cada sistema. Até penso em usar o BigLinux, ele me chamou muito a atenção por sua história ao assistir a live " Histórias, Review e Criação | BigLinux" no canal do SlackJeff.

Senti como se fosse a jornada do guerreiro desde sua origem até chegar onde está hoje com todas as suas conquistas, enquanto guardo a esperança de alguma distro se propor a resolver esse dilema juntamente às empresas de softwares $$.

Aliás, qual distro vc usa?

Entendo. Faz sentido.

Sim, eu sei que o linux é capaz de rodar aplicações que o window não pode rodar, mas a questão é: O linux roda as aplicações que eu preciso que rode? Tipo, eu não instalo o linux só pra rodar qualquer programa e poder me gabar de usar linux. O propósito é rodar as aplicações que preciso e não a distro em si mesma embora o ambiente gráfico linux dá um conforto visual e psicológico sem igual ao usá-lo.

Acredito que o dia que alguma distro se propor a debruçar nesse quesito, deverão se subdividir em duas equipes, a que cuida do ambiente visual dela e a equipe que cuida da parte funciona, como kernel, drives, retrocompatibilidade e estabilidade. Cada equipe formada por devs interessandos especificamente por esses assuntos compondo uma distro ■■■■.

Achei interessante compartilhar o vídeo abaixo:

No mais, o avanço do empacotamento em Flatpak e Snap tende a facilitar muito a manutenção de aplicações ao longo do tempo, independentemente da distro.

2 curtidas

Nunca no mundo que esse daí é o motivo para as empresas não quererem portar seus softwares para o Linux. O real motivo é que o Linux deve ter nem 3% do mercado de desktop, fazendo com que as empresas não vejam relevância no Linux.

Já foi falado diversas vezes aqui sobre snaps, flatpaks e AppImages, que resolvem totalmente o problema que você está apontado.

2 curtidas

Grato pela contribuição.