PC-BSD PBI, quais razões fizeram com que ela fosse descartada?

Question

Quais são as razões técnicas / organizacionais específicas detalhadas que a equipe do PC-BSD enfrentou que acabaram levando-os a desfazer-se do PBI e retornar aos portos?

Foi por causa das dificuldades de compilação e embalagem? Foi por causa de problemas com os hard links que eles criaram? Ou por causa da quantidade de trabalho para coletar dependências e compilar juntos?

Estou curioso para saber por que a mesma equipe que cria um software (digamos GNUCash ) dedica tempo e esforço para fornecer um versão independente para Windows, enquanto o * NIX é deixado como para o compilador / instalador.

Não estou perguntando por que os ports e as bibliotecas são bons (atualizações de segurança fáceis, ...). Eu também não estou perguntando sobre preferências ou opiniões para pacotes vs Windows, apenas as razões técnicas que levaram a sucata PBI. Estou perguntando especificamente por que a rota do PBI (0install, NixOS) é tecnicamente inviável ou amplamente adotada.

    

Answer 1

Na verdade, existem 3 boas razões pelas quais o formato de arquivo PBI foi descontinuado no PC-BSD:

1. O formato PBI foi criado para fornecer um formato de empacotamento para o FreeBSD (nenhum sistema de pacotes "real" existia antes de pkg - apenas a coleção de ports).

   Uma vez que pkg foi finalmente desenvolvido / implementado dentro do próprio FreeBSD (9.2 / 10.0?), quase não havia razão para manter um formato concorrente porque mais pessoas contribuiriam para consertar os pacotes "oficiais" do FreeBSD do que um formato de pacote secundário.

2. O formato de arquivo PBI foi a causa número 1 de problemas do usuário no PC-BSD.

A maioria dos usuários de PC-BSD eram ex-usuários de Linux não entendeu o conceito de um escopo de aplicação restrito / autônomo - então quando o App "A" não conseguiu encontrar / lançar o App "B" (porque "A" estava sendo executado em um contêiner restrito) eles assumiram uma falha no aplicativo / sistema. Isso também ocorreu no momento em que todos os vários aplicativos baseados em Linux estavam constantemente se movendo em direção à integração com o sistema (afastando-se do conceito de um aplicativo independente), portanto, mais e mais aplicativos simplesmente não funcionariam em um ambiente restrito. No momento em que decidimos mudar do PBI para o pkg, havia apenas cerca de 200 aplicativos no FreeBSD que poderíamos empacotar / executar com sucesso dentro de um contêiner PBI restritivo, ao passo que mudando para o sistema padronizado pkg acesso instantâneo a todos os mais de 23.000 pacotes no FreeBSD. Isso também reduziu a sobrecarga do desenvolvedor porque a comunidade do FreeBSD em geral estaria testando / corrigindo aplicativos em vez de ter os (dois) desenvolvedores de PC-BSD também tentando manter versões separadas de tudo.

3. Problemas técnicos

Além do sistema geral de contêineres e das limitações / restrições impostas, houve alguns outros bugs técnicos que apenas nos ajudaram a desfazer todo o formato de arquivo:

• Tempos de carregamento

O início de um PBI levou ~ 30-45 segundos enquanto o pacote levou ~ 2 segundos. Isso se deve principalmente à inicialização dos contêineres e ao carregamento das bibliotecas dentro do contêiner.

• Compilação de aplicativos

Os PBIs precisavam ser compilados com um prefixo de tempo de execução diferente do normal (que os aplicativos ^{supostamente suportam), mas na maioria das vezes os aplicativos tinham caminhos / configurações codificados que impediam app de realmente construir / funcionar corretamente. Isso também significava que, quando nos deparamos com problemas na criação de um aplicativo, nunca conseguimos obter nenhum suporte dos desenvolvedores de aplicativos ou dos carregadores do FreeBSD porque estávamos usando configurações de compilação diferentes.}

• Manutenção do desenvolvedor

Como eu aludi anteriormente, o sistema PBI era extremamente pesado para a manutenção. Os sistemas de compilação sempre apresentavam falhas estranhas ao criar aplicativos (devido à alteração no prefixo de tempo de execução), quando um aplicativo era construído, precisava ser carregado / testado manualmente por um desenvolvedor para garantir isso realmente iniciado (capturando problemas de caminho embutido), e então a meta-informação para o aplicativo também precisava ser atualizada / mantida também (nós ainda mantemos esta informação extra agora - mas tratamos isto como uma sobreposição de informação adicional para o sistema pkg). Então, não foi só muito trabalho para dois caras manterem, mas no final das contas os aplicativos em si mal funcionavam porque não estavam integrados ao ambiente básico do sistema, como a maioria dos aplicativos do Linux foram projetados para fazer.

Observe que, embora o formato de arquivo PBI tenha sido descartado do PC-BSD, ainda estamos dedicados à compartimentação de aplicativos. Em vez disso, nos concentramos em usar subsistemas pré-existentes do FreeBSD (como a estrutura de jails) para garantir contêineres de tempo de execução confiáveis / seguros, enquanto os aplicativos "padrão" que o usuário instala funcionarão normalmente / confiavelmente da mesma maneira que em outros sistemas operacionais.

    

Answer 2

Eu acho que a resposta curta é que o Linux / FreeBSD é o primeiro sistema operacional do servidor, onde bibliotecas independentes e instaladores de GUI não são recursos desejáveis. Equipes que trabalham em distribuições orientadas a desktops têm recursos limitados que são mais bem aproveitados para melhorar a usabilidade da GUI e o suporte de hardware do que escrever uma alternativa de gerenciador de pacotes.

PBI pode ser bom para uso em computadores, mas nunca será adotado pela oferta de distribuição funcionalidade do servidor. Instaladores gráficos e bibliotecas antigas com problemas de segurança ocultos em subpastas não são o que eu quero em um servidor.

O argumento é mais ou menos o mesmo para 0install . Se eu gerenciar um servidor, quero poder instalar / remover um programa específico para cada usuário de uma só vez e atualizar uma biblioteca importante sem procurar suas cópias.

Nix é uma história diferente, tem o potencial de se tornar difundida se for comprovada para ser estável, portátil e ter um bom conjunto de recursos. É difícil discutir isso aqui sem dar opiniões.