Porque alguns softwares quebram "sozinhos"?

Como vão pessoas, tudo bem?
Não sou exatamente iniciante no Linux, uso como SO principal há anos já. Porém eu acho que minha dúvida talvez caiba como de iniciante, por isso a tag.

Gostaria que, por gentileza, me ajudassem a entender a razão de alguns softwares, tanto .deb como flatpak, terem a aparência de “quebrarem sozinhos”.

Para exemplificar, eu tenho 3 PCs em casa, sendo 1 desktop com hardware mais moderno rodando Pop_OS (Ryzen 3300x, 32gb DDR4, RX570), 1 notebook Dell i3 de primeira geração também no Pop_OS e 1 netbook Samsung Atom rodando Lubuntu. Os três equipamentos possuem SSD.

Este problema de “ontem estava funcionando, hoje quebrou” menos se manifesta no desktop, ocorreu uma única vez com o flatpak da Steam, que crashava sempre ao iniciar. Desinstalei, instalei o .deb e tudo voltou ao normal, até hoje.

Já no notebook Dell isso me ocorreu recentemente com o Lutris. Uso o Lutris essencialmente para jogos do GoG, jogos antigos como HoMM 3, Doom, Diablo, etc. Lutris estava no sistema havia tempos já, em .deb. Pode ser que tenha acontecido alguma atualização entre uma vez ou outra que abri, o que acontece é que quando eu iniciei o Lutris, não conseguia acessar a biblioteca GoG, ele crashava. Iniciando pelo comando lutris -d retornava o erro GLXBadFBConfig. Crente que era erro do driver mesa ou tretas de compatibilidade do chipset antigo, fiz de tudo, até que consegui acessar a biblioteca ao usar o comando MESA_GL_VERSION_OVERRIDE=4.5. Porém o erro GLX se repetia em todos os jogos que eu tentava rodar via Lutris. Cheguei até a instalar Mesa Kisak mas sem sucesso. Desinstalei e reinstalei o Lutris, mesmo problema. Resolveu quando apaguei o .deb e coloquei o Flatpak, funcionou como se nada tivesse acontecido.

No netbook eu também tive problemas recente com uma distro, a Busenlabs. A distro estava funcionando belezinha, excelente para usar editor de texto no netbook. Um dia eu desliguei normalmente, alguns dias depois quando fui usar, ficava em uma tela preta logo após o boot da bios.

São situações distintas que eu trouxe com o objetivo de ilustrar essa sensação que eu tenho a respeito dessa situação. Na aparência fica o sentimento de “ontem estava funcionando, hoje quebrou”, mas sei que há outras coisas acontecendo que provocam estes problemas. Gostaria que me ajudassem a entender, e se souberem me indicar algum material onde eu possa me informar mais, agradeceria!

Obrigado pela atenção!

1 curtida

Não sei muito bem o que você quer dizer com quebrar “sozinho”, mas coisas complexas podem falhar de forma complexa. O nosso corpo é um bom exemplo disso.

O que você vê como usuário, as mensagens que recebe e a visão que isso te dá daquilo que você está usando, são apenas a parte visível de um grande “iceberg de tecnologias”.

Não a toa uma atualização do sistema pode afetar um jogo que não foi atualizado nesse processo.

2 curtidas

Isso pode acontecer por 2 motivos:

  1. Seu hardware apresentou alguma falha
  2. O software foi atualizado e se tornou incompatível com seu hardware ou (que é mais comum) incompatível com configurações antigas
1 curtida

App’s / softwares sempre vão quebrar independente do formato / OS, parcialmente ou não, frequentemente ou não, sendo LTS ou não…principalmente aqueles com desenvolvimento ativo ou que se relacionam e dependem de outros softwares com desenvolvimento ativo (dependências…) o que importa é a possibilidade de rollback / downgrade / voltar ao estado anterior para mitigar possíveis problemas.

Curiosamente, acabei de precisar de um downgrade para o Telegram
que bugou na ultima atualização e o flatpak me permitiu isso facilmente.

2 curtidas

e se tratando de Lutris a complexidade multiplica…rs atualmente estou me dando mais com Bottles parece menos problemático…

3 curtidas

No caso do meu Libreoffice travou e não abriu arquivos acho que depois que atualizei do Fedora 38 pro 39. Tive que desinstalar e instalar o Flatpak. Por enquanto, está funcionando bem.

1 curtida

Provavelmente a resposta disso são as bibliotecas compartilhadas. Para isso vou falar um pouco sobre os métodos de empacotamento.

Pacotão

Um jeito de distribuir software é empacotando tudo que ele precisa num grande binário, deixando dependências mínimas para o sistema operacional. Esse é o jeito Windows, AppImage, ou os pacotes Android.

Vantagens

  • Inquebrável: Praticamente nunca quebram com atualizações de outros programas ou do sistema operacional

Desvantagens

  • Tamanho: pra cada programa, tudo é reinstalado, ou seja, mesmo um programa para escrever uma linha pode ficar com dezenas de megabytes.
  • Segurança: Depende que uma falha de segurança em um componente seja corrigida diversas vezes por diversos programadores e distribuída como uma atualização de todos os softwares que utilizam aquele componente.

Moral: Bem prático, mas se torna um inferno em questão de segurança. Quase certamente haverá dependências desatualizadas em um sistema que opera dessa forma, pois não acontece de um programa ser marcado como “desatualizado” ou com “potencial risco a segurança” pelo sistema operacional com base nas versões de bibliotecas que ele usa.

Pacotinho

Outro jeito é distribuir o software é um pacote com o mínimo necessário, somente o programa em si, e deixando que as bibliotecas sejam compartilhadas entre todos os programas. O trabalho de gerir essas dependências fica pro sistema operacional, com o gerenciadores de pacotes. É o famoso apt no Debian/Ubuntu/Pop, dnf no fedora, etc…

Vantagens

  • Tamanho: o sistema fica bem mais enxuto pois bibliotecas são compartilhadas.
  • Segurança: Atualizações de bibliotecas são facilmente corrigidas uma vez e se aplicam a todos os softwares que a usam.
  • Segurança: incompatibilidade com dependências desatualizadas evita manter software desatualizado no repositório.

Desvantagens

  • Compatibilidade: Um software precisa ser compatível com a versão da biblioteca incluída no sistema operacional para ser distribuído.
  • Compatibilidade: pequena chance de uma atualização de segurança em uma dependência causar mal funcionamento de um programa.
  • Dificuldade de inovação: Novas funcionalidades em dependências compartilhadas dependem de ciclos longos para serem introduzidas, uma vez que todos os softwares devem suportar a nova versão.

Moral: Importantíssimo para a segurança, mas apresenta desvantagens substanciais para usuários finais. Também se encaixa bem quando os softwares são livres e o código fonte pode ser acessado a qualquer momento para atualizar o sistema. O modelo é temido por softwares proprietários por ser um inferno ter que ficar atualizando o binário a ser distribuído a cada nova atualização de cada uma das centenas de distribuições.

Imutável

Um terceiro método foi desenvolvido para mesclar ambos os pontos positivos dos métodos anteriores (e também dos pontos negativos KKK). Nele o gerenciador de pacotes suporta e gerencia várias versões de bibliotecas compartilhadas. São os chamados sistemas imutáveis, como o Fedora Silverblue, NixOS, etc… O Flatpak opera de forma análoga e pode ser instalado em uma distribuição linux regular.

Vantagens

  • Inovação: softwares recentes podem ser instalados facilmente.
  • Compatibilidade: softwares desatualizados podem ser usados normalmente.
  • Segurança (flatpak): pacotes podem ser instalados mesmo sem privilégios de administrador.
  • Segurança (flatpak): programas rodam em uma “subsistema” (sandbox), somente tendo acesso aos recursos que sejam dados a eles.

Desvantagens

  • Tamanho: pode haver várias versões de bibliotecas instaladas, e no flatpak pode ainda haver mesmas versões instaladas para diferentes usuários.
  • Tamanho (flatpak): depende de subsistemas inteiros como gnome/kde que são gigantescos, e com diferentes softwares precisando de diferentes subsistemas isso pode ficar gigantesco!

Moral: Mostra-se como uma boa opção para o usuário final, tanto para softwares livres que estão usando recursos recém lançados, quanto para softwares proprietários que podem empacotar uma vez para centenas de distribuições. Também é uma ótima ferramenta para desenvolvedores que querem ter acesso à diferentes versões de bibliotecas no mesmo sistema. Em termos de segurança, embora bibliotecas vulneráveis possam ser utilizadas, o gerenciador de pacotes pode avisar quando um software as está usando, e deixar essa escolha de removê-lo para o usuário/administrador. Por outro lado, se o programa está rodando em um subsistema (flatpak), os danos causados por uma brecha são minimizados.

Conclusão

Agora fica fácil entender:

  • O por quê dos servidores GNU/Linux serem tão seguros.
  • A reclamação dos usuários finais com a lentidão das distribuições em incluir os novos programas.
  • A insegurança no Windows por instalar programas, por mais desatualizados que estejam, com privilégios de administrador e sem subsistema de contenção de danos.
  • A extrema compatibilidade do Windows com softwares antigos.
  • A preferência dos softwares proprietários ao Windows
  • Usuários das distribuições linux quebrando seus sistemas por quererem a instalação de um novo programa de fora do repositório.
  • O “estava funcionando até ontem, quando atualizei”, principalmente em distribuições instáveis (de testes) como debian SID e fedora.

Resposta bônus: Sobre quebras aparentemente sem motivos em distribuições estáveis

Não bastasse os pontos de incompatibilidade, também há casos que deveriam funcionar mas não funcionam. São pontos mais ligados a detalhes de programação:

  1. Algumas vezes o programa tem um bug que é passado para a biblioteca, mas não é detectado durante os testes comuns. Quando a biblioteca é atualizada, pode evidenciar o bug do programa e causar um erro (segmentation fault ou acesso não autorizado). Daí vai depender do mantenedor do programa atualizá-lo e distribuí-lo. Pode demorar uma ou duas semanas para a correção chegar.
  2. Algumas vezes a atualização de uma biblioteca pode causar incompatibilidade de ABI. Daí vai depender apenas de recompilar o programa afetado e redistribuí-lo. Esses casos são resolvidos de um dia para o outro.
  3. Erro de disco (geralmente se for hdd antigo) afetando algum programa.
  4. E por último, mas ainda sim importante, aquela alteração de um bit aleatório na RAM ou no disco devido ao constante bombardeio por raios cósmicos, especialmente se você mora em locais altos ou na estação espacial!
2 curtidas

Pessoal, eu queria agradecer a todos vocês pelas respostas, me ajudaram a entender a situação.

Meu agradecimento especial para o @Deleterium que tirou um tempo para me dar uma aula, praticamente. Muito bem elencado e eu acho que você conseguiu entender a origem da minha dúvida, conforme eu te lia, as questões foram fazendo sentido.

Sua resposta me fez pensar na dificuldade que tive ao tentar instalar um software, especificamente o Iramuteq (análise de dados qualitativos), que requer algumas dependências Phyton e R. Por ausência de documentação online com troubleshooting eu não dei conta, acabei instalando ele em uma VM com Windows mesmo.

Resposta Bônus

Não deve ser alteração de bit aleatório pois moro em um fundo de vale danado, tô longe do céu! Hahahaha.

2 curtidas

Este tópico foi fechado automaticamente 3 dias depois da última resposta. Novas respostas não são mais permitidas.