Por que os programas não são distribuídos em formato compilado?

31

Mas eles dão instruções como

cd downloaded_program
./configure
make install

Isso cria o ELF que é necessário e, provavelmente, alguns arquivos .so.

Por que não colocá-los dentro de um arquivo zip para download, como com os aplicativos do windows? Existe alguma razão pela qual eles precisam ser compilados pelo usuário?

    
por kitty 27.11.2015 / 01:52

10 respostas

33

Vamos analisar os fatores ...

Análise :

DEPENDENCIES DE ACORDO COM A PLATAFORMA : Existem alguns problemas que surgem em um ambiente em que os desenvolvedores criam e mantêm diversas variantes específicas da arquitetura de um aplicativo:

  • É necessário código-fonte diferente para variantes diferentes - Sistemas operacionais diferentes baseados em UNIX podem usar funções diferentes para implementar a mesma tarefa (por exemplo, strchr (3) vs. índice (3)). Da mesma forma, pode ser necessário incluir diferentes arquivos de cabeçalho para diferentes variantes (por exemplo, string.h vs. strings.h).

  • Diferentes procedimentos de construção são necessários para diferentes variantes - Os procedimentos de criação para diferentes plataformas variam. As diferenças podem envolver dados específicos como locais do compilador, opções do compilador e bibliotecas.

  • Os builds para diferentes variantes devem ser mantidos separados - Como há uma única árvore de origem, é preciso ter cuidado para garantir que os módulos de objeto e executáveis de uma arquitetura não se confundam com os de outras arquiteturas. Por exemplo, o editor de link não deve tentar criar um executável IRIX-5 usando um módulo de objeto que foi criado para o SunOS-4.

  • Todo sistema operacional tem seu próprio esquema de gerenciamento de links e deve preparar o arquivo ELF (Executable and Linking Format) conforme necessário.

  • O compilador gerará uma compilação que é uma sequência de instruções e arquiteturas distintas significam diferentes conjuntos de instruções ( Comparação de arquiteturas de conjuntos de instruções ). Assim, a saída do compilador é distinta para cada arquitetura (Ex: x86, x86-64, ARM, ARM64, Power ISA da IBM, PowerPC, 6800 da Motorola, MOS T 6502 e so muitos outros )

SEGURANÇA :

  • Se você baixar um binário, não poderá ter certeza se ele faz o que ele diz, mas você pode tentar auditar o código-fonte e usar um binário compilado em seu sistema. Apesar disso, o usuário Techmag fez um bom comentário em seu comentário, a auditoria do código requer codificadores experientes e competentes para avaliar o código e não é uma garantia de segurança.

MARKET : Nesta seção, há muitos fatores, mas tentarei resumi-lo:

  • Nem toda empresa tem como objetivo alcançar todas as plataformas, depende do mercado e da popularidade das plataformas e do que elas querem vender.

  • O software livre tem o espírito de tornar o software o mais amplamente disponível possível, mas não implica que o software seja projetado para todas as plataformas, depende da comunidade que o suporta.

Conclusão :

Nem todo software é projetado para todas as plataformas. Fornecer binários para todas as arquiteturas e plataformas implica compilá-lo, testá-lo e mantê-lo para todas as plataformas. Isso é mais trabalho que às vezes é muito caro e pode ser evitado se o usuário o compilar em sua própria plataforma. Além disso, o usuário estará ciente do que está executando.

    
por 27.11.2015 / 04:43
10

Existe uma variedade de plataformas e ambientes de software, tanto * nix como outros , que o software pode ser executado, permitindo que você crie um aplicativo (ou biblioteca para usar com aplicativos) é a única maneira realista de suportar tantas combinações desses componentes quanto um item de software "bom". É claro, licenças como a GPL exigem que o código-fonte esteja disponível - portanto, mesmo que o software não funcione corretamente, geralmente é possível (embora possa ser complicado entender o que está errado e como para consertá-lo) para que o usuário ou algum terceiro mergulhe e corrija, mesmo que o criador não exista / não possa mais existir para fazê-lo.

Distribuir software como código-fonte também permite verificação independente de que o software faz o que alega e não faz algo desagradável em vez de - o que, apesar de reduzir o nível de confiança, no criador, na verdade, melhora isso!

    
por 27.11.2015 / 03:27
8

Primeiro, sua pergunta é baseada em uma premissa falha. Programas são distribuídos em formato compilado!

A maneira normal de instalar o software no Ubuntu, como na maioria das outras distribuições Linux e, mais geralmente, na maioria das variantes Unix, é instalar um pacote. No Ubuntu, você abre o centro de software ou algum outro gerenciador de pacotes e navega pelo software disponível. Quando você seleciona um pacote para instalação, os binários (se o pacote contiver um programa) são baixados e instalados em sua máquina.

Por padrão, o gerenciador de pacotes oferece pacotes feitos pelos mantenedores da distribuição. Você também pode encontrar fontes de pacotes de terceiros; O Ubuntu oferece PPA como uma forma padronizada para terceiros oferecerem pacotes.

Baixar o software do autor em forma compilada é um último recurso. Você só precisa fazer isso se o software não for popular o suficiente para ser empacotado ou se você realmente precisar da versão mais recente que não foi empacotada. A maioria das pessoas nunca precisa fazer isso.

Quando o software não é empacotado para uma distribuição, ele geralmente é distribuído em formato de fonte e não em formato binário. Existem duas razões principais pelas quais isso acontece com frequência no mundo do Linux, mas raramente no mundo do Windows. Uma razão é que a proporção de programas de código aberto no Linux é muito maior. Obviamente, se o código-fonte de um programa não estiver disponível, a única forma de distribuição é um binário. A outra razão é que o mundo do Linux é muito mais diversificado. Binários diferentes são necessários para cada conjunto de versões de bibliotecas incompatíveis, o que geralmente significa binários diferentes para cada versão de cada distribuição. O Windows "resolve" isso fazendo com que cada autor de pacotes distribua as bibliotecas que eles usam junto com o programa (conseqüência: seu computador armazena muitas cópias de cada biblioteca, uma por programa que a usa; se um bug é corrigido em uma biblioteca, cada programa usa para enviar uma atualização) e lançando uma nova versão do sistema operacional somente a cada três anos ou mais. O Unix tem muito mais diversidade e hábitos de correção de bugs mais oportunos e resolve os problemas de distribuição de bibliotecas construindo binários diferentes para diferentes distribuições.

    
por 28.11.2015 / 01:36
5

O Linux é executado em mais de uma plataforma de CPU específica. Se você distribuísse arquivos ELF (ou qualquer outro tipo de executável bruto), haveria uma chance de que algumas versões do Linux não pudessem rodar o software. No espírito de tornar o software o mais amplamente disponível possível, é preferível usar o código fonte. Por exemplo, o Linux é executado em processadores Sparc, Intel, AMD, ARM e outros tipos de processadores.

Se o arquivo ELF visasse especificamente processadores Intel, por exemplo, outros tipos de hardware não poderiam executar o software. O ELF é independente de plataforma, mas o código que ele hospeda precisa estar em conformidade com o código de máquina de uma plataforma. Você perceberá quantas distribuições têm pacotes semelhantes (por exemplo, pacotes _386 e _586 quando ele suporta processadores diferentes) - você precisa instalar o arquivo ELF correto para obter a operação correta.

Da mesma forma, se eu decidir criar uma versão Linux customizada que use diferentes interrupções, linkers, etc, eu ainda preciso do código-fonte para compilar o código. Mesmo que o código-fonte não tenha instruções de compilação específicas da plataforma, cada plataforma é diferente e não pode executar um ELF a partir de um sistema diferente.

    
por 27.11.2015 / 11:06
5

O motivo original da distribuição como fonte certamente foi a diversidade de plataforma; a comunidade Linux continuou essa metodologia tanto por isso quanto por novas razões, parcialmente políticas.

Ao contrário de, por exemplo Windows, o Linux historicamente nunca se preocupou em manter qualquer ABI (interface binária de aplicativo) estável por longos períodos de tempo - mantendo a possibilidade de inovar em aspectos como formatos executáveis, APIs de bibliotecas e suporte a novas plataformas de hardware foi considerado mais importante.

Os sistemas operacionais comerciais alcançam compatibilidade de longo prazo com aplicativos, sendo muito disciplinados em relação à inovação; um novo recurso / interface de software sempre precisa ser adicionado em adição a um antigo - exigindo duas coisas para ser mantido, eo preço de mudar qualquer coisa após o lançamento deve ser considerado muito alto. Alternativamente, você pode adotar o fato da obsolescência planejada do aplicativo junto com qualquer pessoa que esteja escrevendo software para o seu sistema operacional (isso não está insinuando a MS, mas sim outro fornecedor de SO).

A obtenção de uma plataforma estável de longo prazo para software distribuído em formato somente binário (fora de uma determinada distribuição Linux) seria considerada indesejável por alguns elementos da comunidade Linux. Como um usuário sem remorso de ambas as plataformas, não estou dizendo que é bom ou ruim; é como é.

    
por 27.11.2015 / 12:00
4

Em muitos casos (pelo menos no mundo * nix), o código-fonte é a versão mais portátil do software. Ter a fonte garante que o software compartilhado funcionará em todas as plataformas que possam suportá-lo (o que, em muitos casos, significa simplesmente compatível com POSIX). A liberação de binários apenas garante a compatibilidade com plataformas (tanto de software como de hardware) às quais esses binários são liberados.

Considere que, no Windows, os binários são a forma mais conveniente e portátil de compartilhamento de software. Como a compilação de código-fonte não faz parte do modelo usual de distribuição de software para Windows, a Microsoft se empenhou ao longo dos anos para garantir que os binários funcionem em várias versões de seu sistema operacional: link

    
por 27.11.2015 / 07:48
3

A maioria dos softwares Linux é de software livre. Ao distribuir o código-fonte com algumas instruções de compilação, em vez de binários, você tem a oportunidade de revisar ou até mesmo editar o código-fonte antes de compilá-lo. Dessa forma, você pode ter certeza do que o programa realmente faz e de que não é prejudicial.

    
por 27.11.2015 / 03:09
0

A razão principal pela qual eu pessoalmente não gosto de apenas pegar um executável de um programa é porque eu gosto de primeiro checar o que o código-fonte está realmente fazendo (principalmente porque eu gosto de ver o código dos outros) mas eu sei de vários outros que também verificam código-fonte para código malicioso.

    
por 02.12.2015 / 19:55
0

Muitas respostas dizem que, na maioria dos casos, os softwares são distribuídos em formato compilado. Eu concordo com essa suposição. No entanto, vejo um caso em que distribuir um software por sua origem é melhor do que distribuí-lo em formato compilado.

Não tenho certeza se é verdade, mas imagino que no início da Internet, porque a largura de banda da rede era ruim, poderia ser às vezes mais rápido distribuir um software por sua origem do que em formato compilado. Como as fontes de código são apenas texto simples, geralmente são menores que o software no formato compilado. Portanto, distribuir um software com código fonte parece ser uma maneira melhor de compartilhá-lo, desde que os usuários possam compilá-lo.

    
por 04.12.2015 / 00:07
0

Além do fato de que existem muitos sistemas unix que rodam em muitas plataformas diferentes, considere apenas os problemas que o software Windows enfrenta desse modo de distribuição, embora eles realmente só precisem se preocupar com uma versão do Windows e uma plataforma. (o PC).

Mesmo com apenas o PC para se preocupar, ainda existem duas arquiteturas: 32 bits e 64 bits. Se você notar, a grande maioria dos softwares Windows simplesmente ignora os softwares de 64 bits e só envia 32 bits, deixando-o com um software sub-ótimo se você tiver um sistema de 64 bits. Então existem bibliotecas. Um fornecedor de software não quer que você receba erros estranhos tentando executar o programa se você não tiver a biblioteca adequada já instalada, então eles apenas incluem a biblioteca com o programa (aumentando o download, mesmo se você já tiver essa biblioteca ). Um segundo programa faz a mesma coisa, mas com uma versão diferente da biblioteca. No melhor dos casos, o programa B contém uma versão mais nova da biblioteca que é retrocompatível, então se você instalar o programa B após programa A, as coisas funcionam, mas instalá-las na ordem reversa deixa você com o versão mais antiga da biblioteca e assim o programa B quebra. Muitas vezes, porém, o fornecedor da biblioteca faz alterações que não são compatíveis com versões anteriores e não se incomoda em mudar o nome da biblioteca, portanto, não importa em que ordem você instale os dois programas, o primeiro será quebrado. Isso é chamado de "inferno dll".

Infelizmente, para evitar isso, a maioria dos softwares do Windows recorreu ao envio de todas as suas bibliotecas em seu próprio diretório de programas, em vez de um diretório compartilhado, assim cada programa tem todas as suas próprias bibliotecas privadas e nunca compartilhará umas com as outras. derrota todo o ponto de dlls em primeiro lugar e você acaba usando muito mais memória RAM e espaço em disco e tempo de download de todas as bibliotecas duplicadas.

É por isso que o software de código aberto é publicado na forma de código-fonte, e os fornecedores de SO criam gerenciadores de pacotes que resolvem os problemas de dependência e baixam apenas os binários pré-compilados que você realmente precisa, sem duplicar bibliotecas. Isso também lida com o fato de que existem muitos sistemas unix diferentes que são executados em muitas plataformas diferentes.

    
por 04.12.2015 / 02:54