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

Mas eles dão instruções como

cd downloaded_program
./configure
make install

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

Por que não colocar aqueles dentro de um arquivo zip para download, como nos aplicativos do Windows? Existe alguma razão pela qual eles precisam ser compilados pelo usuário?

Vamos analisar os fatores ...

Análise :

DEPENDÊNCIAS DE ACORDO COM A PLATAFORMA : Existem alguns problemas que surgem em um ambiente em que os desenvolvedores estão criando e mantendo várias variantes específicas de uma arquitetura de um aplicativo:

• É necessário um código-fonte diferente para diferentes variantes - Diferentes sistemas operacionais 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 arquivos de cabeçalho diferentes 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 construção para diferentes plataformas variam. As diferenças podem envolver detalhes como locais do compilador, opções do compilador e bibliotecas.

• Construções para diferentes variantes devem ser mantidas separadas - Como existe uma única árvore de origem, é necessário ter cuidado para garantir que os módulos de objeto e os executáveis ​​de uma arquitetura não sejam confundidos 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 criado para o SunOS – 4.

• Todo sistema operacional possui 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 conjuntos de instruções diferentes ( Comparação de Arquiteturas de Conjunto de Instruções ). Portanto, a saída do compilador é distinta para cada arquitetura (Ex: x86, x86-64, ARM, ARM64, IBM Power ISA, PowerPC, 6800 da Motorola, MOS T 6502 e tantas outras )

SEGURANÇA :

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

MERCADO : Nesta seção, existem muitos fatores, mas tentarei resumir:

• Nem toda empresa pretende 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 disponibilizar o software o mais amplamente possível, mas isso 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. O fornecimento de binários para todas as arquiteturas e plataformas implica compilá-lo, testá-lo e mantê-lo em todas as plataformas. Às vezes, esse trabalho é mais 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.

Existe uma variedade de plataformas e ambientes de software tanto * nix quanto outros , que o software pode ser executado, permitindo que você construa um aplicativo (ou biblioteca para usar com aplicativos) é a única maneira realista de oferecer suporte. muitas combinações desses componentes como um item de software "bom". Obviamente, 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 compreender o que está errado e como corrigi-lo) para o usuário ou terceiros para mergulhar e corrigi-lo, mesmo que o criador não exista / não possa / não exista mais para fazê-lo.

A distribuição de software como código-fonte também permite a verificação independente de que o software faz o que alega e não faz algo desagradável em vez de ou também - o que, apesar de reduzir o nível de confiança que se deve ter no criador, realmente o aprimora!

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

A maneira normal de instalar software no Ubuntu, como na maioria das outras distribuições Linux e, geralmente, na maioria das variantes do Unix, é instalar um pacote. No Ubuntu, você abre o centro de software ou outro gerenciador de pacotes e navega no 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 na sua máquina.

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

Baixar o software do autor em formato compilado é um último recurso. Você só precisa fazer isso se o software não for popular o suficiente para ser empacotado ou se precisar absolutamente 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, geralmente é distribuído na forma de origem e não na forma binária. Há duas razões principais pelas quais isso acontece frequentemente no mundo Linux, mas raramente no mundo 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 Linux é muito mais diversificado. Binários diferentes são necessários para cada conjunto de versões incompatíveis da biblioteca, o que geralmente significa binários diferentes para cada versão de cada distribuição. O Windows "resolve" isso fazendo com que cada autor do pacote 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 utiliza; se um bug for corrigido em uma biblioteca, cada programa que o usa deve enviar uma atualização) e liberar uma nova versão do sistema operacional apenas a cada três anos. O Unix tem muito mais diversidade e hábitos de correção de bugs muito mais oportunos, e resolve os problemas de distribuição de bibliotecas criando binários diferentes para diferentes distribuições.

O Linux roda em mais do que apenas 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 executar 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 roda em 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 da plataforma, mas o código que ele hospeda precisa estar em conformidade com o código de máquina da plataforma. Você notará 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 personalizada do Linux que use diferentes interrupções, vinculadores etc., ainda preciso do código-fonte para compilar o código. Mesmo que o código-fonte não tenha instruções de construção específicas da plataforma, cada plataforma é diferente e pode não executar um ELF a partir de um sistema diferente.

O motivo original da distribuição como fonte certamente foi a diversidade da plataforma; a comunidade Linux continuou essa metodologia por isso e por novos motivos, parcialmente políticos.

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

Os sistemas operacionais comerciais alcançam compatibilidade de aplicativos a longo prazo, sendo muito disciplinados sobre inovação; uma nova interface de recurso / software sempre precisa ser adicionada em adição a uma antiga - exigindo que duas coisas sejam mantidas, e o preço de alterar qualquer coisa após o lançamento precisa ser considerado muito alto. Como alternativa, você pode adotar o fato de obsolescência planejada do aplicativo junto com qualquer pessoa que esteja criando software para o seu sistema operacional (isso não é uma sugestão da MS, mas de outro fornecedor do sistema operacional).

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

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 funcione 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 compatibilidade com plataformas (software e hardware) para as quais esses binários são liberados.

Considere que, no Windows, os binários são a forma mais conveniente e portátil para compartilhar software. Como a fonte de compilação não faz parte do modelo usual de distribuição de software do Windows, a Microsoft se esforçou ao longo dos anos para garantir que os binários funcionassem em várias versões de seu sistema operacional: http://www.joelonsoftware.com/articles/APIWar.html

A maioria dos softwares Linux é 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 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.

A principal razão pela qual eu pessoalmente não gosto de apenas obter um executável de um programa é porque gosto de verificar primeiro o que o código-fonte está realmente fazendo (principalmente porque gosto de ver o código dos outros), mas conheço vários outros que também verificam o código-fonte quanto a códigos maliciosos.

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

Não tenho certeza de que seja verdade, mas imagino que no início da Internet, porque a largura de banda da rede era ruim, às vezes poderia ser 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 é menor que o software em formato compilado. Portanto, distribuir um software com fonte de código parece ser a melhor maneira de compartilhá-lo, desde que os usuários possam compilá-lo.

Além do fato de existirem muitos sistemas unix executados em diversas plataformas, considere apenas os problemas que o software Windows enfrenta nesse modal de distribuição, mesmo que eles realmente precisem se preocupar apenas 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 do software Windows simplesmente ignora 64 bits e envia apenas software de 32 bits, deixando-o com um software abaixo do ideal, se você tiver um sistema de 64 bits. Depois, existem bibliotecas. Um fornecedor de software não deseja que você receba erros estranhos ao executar o programa se você não tiver a biblioteca adequada já instalada, portanto, apenas inclua a biblioteca no 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. Na melhor das hipóteses, o programa B contém uma versão mais recente da biblioteca compatível com versões anteriores, portanto, se você instalar o programa B apósprograma A, as coisas funcionam, mas instalá-las na ordem inversa deixa você com a versão mais antiga da biblioteca e, portanto, o programa B é interrompido. 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 alterar o nome da biblioteca; portanto, não importa em que ordem você instala os dois programas, o primeiro será interrompido. Isso é chamado de "dll hell".

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 programa em vez de em um diretório compartilhado, de modo que cada programa possui todas as suas próprias bibliotecas privadas e nunca será compartilhado entre si, o que derrota o todo ponto de dlls em primeiro lugar e você acaba usando muito mais memória e espaço em disco e tempo baixando todas as bibliotecas duplicadas.

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