Inferno de dependência: Por que não criar aplicativos portáteis [fechados]

Question

Voltando no tempo para as idades em que eu estava usando o Windows, os aplicativos eram instalados de maneira independente. Isso deixou muita liberdade para o usuário final / sysadmin decidir o que e onde atualizar, o que corrigir e quando sem interferir em outros aplicativos.

No * NIX, as dependências emaranhadas são uma dor de cabeça dolorosa. O PC-BSD tentou superar isso com o PBI , criando aplicativos independentes. AFAIK, isso parece agora obsoleto e eles voltaram para o modo de gerenciamento de pacotes (o PBI agora é um invólucro para portas), e todas as distribuições Linux correm na mesma direção: centenas de dependências até o fim, mesmo Espera-se que os ambientes de desktop dependam dos daemons de gerenciamento do sistema .

Criar aplicativos baseados em centenas de dependências facilita a vida dos programadores, mas cria um problema chocante para usuários finais e administradores de sistema. Por exemplo, eu não posso mais manter uma versão antiga do Debian Etch do aplicativo rodando no Debian Jessie. Eu sei que muitas pessoas virão com a história de segurança e patches e sistemas atualizados, mas OpenSource significa liberdade para determinar o que, quando e onde atualizar. Há razões muito válidas para não atualizar um sistema ou parte dele, ou pelo menos não fazê-lo como os típicos gerenciadores de pacotes * NIX estão conduzindo usuários (ou seja, máquinas trabalhando offline, hardware antigo, compatibilidade com dados antigos que precisam ser mantido para cumprimento, ...). Outras vezes, os administradores de sistema preferem fazer isso em várias etapas para segurança.

Pessoalmente, acredito que eu, como administrador de sistema, deveria decidir o que atualizar, quando e assumir o risco. Com o atual estado de coisas, isso é impossível. (Isto é, ter uma nova versão do libc6 no Debian, isso tem dependências em todos os lugares). Se eu decidir manter dois ou mais repositórios para superar o problema, gero outro pesadelo.

Eu entendo que certas dependências (ou seja, com o MySQL instalado) são aceitáveis, já que esta é uma grande dependência, mas não consigo entender por que as pequenas dependências como bibliotecas não estão simplesmente embutidas no código. O disco é barato. Muitos aplicativos do Linux portados para o Windows conseguiram isso.

EDIT: para garantir que não se baseie apenas em opiniões

Quais são as opções para instalar um software no * NIX (vamos colocar o Debian / FreeBSD para simplificar) para:

• Mantenha uma versão específica de um software em execução por anos sem atualização e garanta que ela possa ser mantida intacta, independentemente do upgrade do SO e das bibliotecas subseqüentes, ala apt-get hold mas para sempre .

• Decida atualizar / fazer downgrade sem conflitos de outros softwares / bibliotecas.

• Instale duas ou mais versões desse software.

Jails / chroot / VMs não são opções, embora sejam as soluções óbvias. Além disso,

• O que especificamente fez o PBI não conseguir atingir essa meta de independência voltando ao gerenciamento de pacotes / portas?

Answer 1

Eu não posso responder por que o PBI não foi bem-sucedido, mas posso responder por que as bibliotecas compartilhadas são preferidas no Linux.

O principal argumento é segurança, que se houver uma vulnerabilidade em uma biblioteca comumente usada, somente essa biblioteca terá que ser atualizada, e não todos os aplicativos que usam essa biblioteca (obrigado para compatibilidade ABI). Isso também significa que (se você ficar na maior parte dos repositórios principais e PPAs (no caso do Ubuntu)), você não precisa ter 4 versões diferentes de uma biblioteca instalada apenas porque seus aplicativos foram compilados contra essas versões (como o Windows). , onde você provavelmente teria versões diferentes das bibliotecas .NET instaladas, ou versões diferentes do tempo de execução visual C ++ instaladas).

No entanto, pode haver alguns casos em que os aplicativos não sejam forçados a usar a versão do sistema das bibliotecas e possam usar sua própria versão. Por exemplo, o Chromium depende de muitas bibliotecas que estão presentes na maioria dos repositórios da distribuição. Em circunstâncias normais, os aplicativos seriam compilados para que as bibliotecas usadas fossem as compiladas pela distro. No entanto, no Ubuntu (pelo menos), o Chromium é compilado com sua própria versão de bibliotecas, porque:

• Usar a versão do sistema de bibliotecas significa que o Chromium teria que ser testado para cada versão do Ubuntu.
• Na maior parte, o Chromium já usa as versões mais recentes das bibliotecas, o que significa que a probabilidade de haver uma vulnerabilidade é muito menor.

Quanto ao argumento de espaço em disco, você poderia argumentar que a instalação de uma versão em debootstrap do Debian Jessie requer menos de 1 GB de espaço em disco, tornando-o ótimo para cartões SD menores. O Windows, por outro lado, requer pelo menos vários gigabytes de espaço em disco.

Em relação ao software antigo, você pode compilar o aplicativo estaticamente e ter a maioria das dependências autocontidas. No entanto, como sua distro pode não ter versões estáticas das bibliotecas disponíveis (na maioria das vezes, o Debian e o Ubuntu não), você precisará compilar essas bibliotecas por conta própria para obter as versões estáticas dessas bibliotecas.

Por fim, um dos princípios do Unix é que cada aplicativo faz apenas uma coisa e é bom nisso. Se aplicativos e bibliotecas estivessem vinculados estaticamente, eles poderiam ser considerados (indiretamente) fazendo muitas coisas.