Estou tendo problemas para entender os formatos executáveis ​​do Linux e os pacotes de distribuição de software. Existem muitas distribuições diferentes do próprio Linux, e parece que cada pacote de software foi compilado separadamente para cada distribuição. Por que é isso? Entendo que alguns "pacotes" foram criados para serem instalados em diferentes distribuições, mas o formato executável do software é diferente?

Além disso, por que muitos usuários do Linux preferem as versões de prompt de comando dos aplicativos e as versões da GUI? Eu posso entender a necessidade de pequenas pegadas, mas até os aplicativos da GUI podem ter pequenas pegadas, se forem codificados corretamente.

Gerenciadores de pacotes e dependências

A maioria das distribuições Linux usa gerenciadores de pacotes para instalação e remoção de software. Os gerenciadores de pacotes oferecem alguns benefícios, como a possibilidade de usar um repositório central a partir do qual (quase) qualquer parte do software pode ser baixada, a organização de partes do software em pacotes configuráveis ​​que podem ser instalados como um grupo coeso e os principais benefícios: automático manipulação de dependência e rastreamento do que os pacotes de alterações fazem para que possam ser desinstalados.

Determinadas peças de software podem exigir que determinadas bibliotecas ou outros programas executem tarefas que seriam redundantes se fossem reimplementadas nessa peça de software. Pacotes permitem a expressão dessas dependências.

Diferenças: formatos e estratégias de pacotes

Existem vários gerenciadores de pacotes diferentes. Cada um foi criado porque os existentes não atendiam às necessidades de algumas pessoas. Cada gerenciador de pacotes requer pacotes em seu próprio formato.

Além disso, diferentes distribuições têm requisitos diferentes do software incluído. Existem vários softwares que podem ter recursos diferentes, dependendo das opções fornecidas quando compiladas do código-fonte para o executável de uma máquina. Algumas distribuições desejam fornecer conjuntos completos de recursos e uma experiência rica, enquanto outras desejam fornecer uma experiência o mais enxuta e simples possível, e há tudo no meio. Além disso, a distribuição pode decidir formatar sua estrutura de diretórios de maneira diferente ou usar um sistema init diferente. Eles podem decidir agrupar o software de maneira diferente: pode haver um pacote chamado "dev-utils" em duas distribuições diferentes, mas uma versão incluiyaccenquanto o outro não. Devido a essas diferentes necessidades, as distribuições optam por compilar o software de maneiras diferentes.

É por isso que, mesmo que você tenha um pacote no formato correto para o seu gerenciador de pacotes, ele poderá não funcionar se o pacote for destinado a uma distribuição diferente. Por exemplo, esse pacote pode depender da yaccinstalação, e expressou essa dependência exigindo o pacote "dev-utils", mas o seu "dev-utils" não inclui yacc. Agora há um pacote instalado com uma dependência não atendida.

Não é realmente um problema.

Uma grande parte de ser uma distribuição Linux é manter um repositório de software central. A distribuição cuida de manter tudo isso para você. Isso realmente facilita a instalação do software. Você normalmente usa o gerenciador de pacotes para procurar e selecionar alguns pacotes e, em seguida, pede para instalá-los; cuida do resto para você. O processo de instalação do software Windows inclui a busca de software em sites de terceiros, tentando localizar o link de download apropriado, o download, a verificação de vírus e a execução de um programa de instalação que, em seguida, faz várias perguntas irrelevantes. Toda essa bagunça não é o padrão no Linux.

O repositório não pode incluir tudo

Agora, pode haver casos em que um software necessário não esteja no repositório da sua distribuição. Os pacotes fornecidos por um repositório de software são um dos recursos diferenciadores das distribuições. Quando você não consegue encontrar o software necessário nos repositórios de sua distribuição, existem três caminhos possíveis (na verdade, dois mais uma maneira de realmente estragar tudo).

Repositórios da Comunidade

Muitas distribuições têm repositórios não oficiais que são mantidos por pessoas não associadas à distribuição. O Ubuntu os chama de PPAs, o Fedora os chama de Repositórios de Pessoas do Fedora. O Arch Linux não possui um nome específico para repositórios de terceiros , mas possui seu AUR, que é uma coleção de "receitas" para pacotes (nota: existe apenas um AUR). Você pode primeiro tentar instalar um pacote de uma dessas fontes, pois é fácil desinstalá-las se elas não funcionarem.

Compilar a partir do código-fonte

Se você não conseguir encontrar um repositório não oficial com o que precisa, compilar a partir do código-fonte não será difícil. Você precisa ter o pacote de desenvolvimento da sua distribuição instalado; isso inclui itens básicos como um compilador, vinculador, analisador e outras ferramentas geralmente necessárias para a compilação de software. Em seguida, você encontra o código-fonte do projeto (que quase sempre é empacotado em um .tgzou .tbz(chamado de "tarball"). Faça o download em seu próprio diretório em algum lugar, extraia-o (use tar -xf filename.tgze, geralmente, vá para o diretório que ele criou. esse diretório pode ser um arquivo chamado READMEou INSTALL. Se existir, vá em frente e leia-o; a maioria deles pede para você fazer a mesma coisa. As próximas etapas são executadas em uma linha de comando. Execute lse procure um arquivo executável chamadoconfigure. Se existir, execute-o fazendo ./configure; às vezes, pode demorar alguns minutos. Isso geralmente executa alguns testes para descobrir como a sua distribuição tem as coisas configuradas e garante que você tenha as ferramentas necessárias para compilar esse software. O próximo passo é executar make. Na verdade, isso compila o software e provavelmente levará algum tempo - de alguns minutos a horas, dependendo do tamanho do software que você está compilando. Feito isso, você corre make install. Isso instala o software, que envolve a cópia dos produtos da compilação para os locais apropriados no seu sistema de arquivos. Depois disso, o software estará disponível para uso.

Esta foi uma seção longa, mas está resumida como "README, ./configure, make, make install" . Essa é a rotina para lembrar.

Instale um pacote de outra distribuição (não faça isso)

Listo isso apenas porque é uma alternativa, mas quase certamente não terminará bem. É possível instalar pacotes para outras distribuições, e você pode querer fazer isso. Bem, não. Não faça isso até entender seu sistema muito bem. Na verdade, não vou colocar nenhum comando aqui mostrando como fazê-lo, mesmo que seja possível. Se você chegar a esse ponto em que parece ser a única opção, não instale o pacote usando o gerenciador de pacotes; em vez disso, retire as coisas do pacote e coloque-as no sistema manualmente, juntamente com as notas sobre o que você fez para que você possa desfazê-lo, se necessário.

O bit da linha de comando

Algumas pessoas preferem a linha de comando pelas vantagens que ela oferece. Estes podem ser resumidos em três coisas:

• Facilidade de automação
• Velocidade (em comparação com clicar em todo o lugar em uma GUI)
• Expressividade

O maior deles é a expressividade; existem coisas que podem ser feitas em uma linha de comando que não são possíveis em uma interface gráfica.

Por fim, as instruções da linha de comando são frequentemente fornecidas em fóruns úteis como este, porque é muito mais fácil transmitir as informações corretas do que dar instruções do tipo "clique aqui, depois, ali e então".

Desculpe pela resposta longa. Se você quer o rápido e sujo, basta ler o resumo.

Sumário

• O formato executável é o mesmo.
• Existem gerenciadores de pacotes diferentes que não são compatíveis, mesmo que os programas empacotados sejam. (Você pode ver um pacote como um arquivo de instalação, como .msiarquivos).
• Basicamente, diferentes distribuições / versões têm versões diferentes das bibliotecas principais e, por motivos de consistência e estabilidade, os aplicativos precisam ser construídos com base nessas versões. (Versão Linux do dll hell).
• Distribuições diferentes fazem as coisas de maneiras ligeiramente diferentes e, em alguns casos, podem ser um problema de compatibilidade.
• A linha de comando pode ser mais rápida e a linha de comando unix é muito melhor que a linha de comando do Windows.

Gerenciadores de pacotes

Primeiro de tudo, gerenciadores de pacotes. O objetivo principal de um gerenciador de pacotes é manter um banco de dados de pacotes instalados e os arquivos que constituem esse pacote.

Os gerenciadores de pacotes permitem fácil instalação de pacotes e, geralmente, também fácil remoção. Eles também permitem que os pacotes especifiquem vários scripts que talvez precisem ser executados na instalação / remoção para manter a consistência do sistema (como registrar o pacote em algum banco de dados relacionado ao subsistema).

Gerenciadores de pacotes diferentes

Existem vários gerenciadores de pacotes diferentes, com diferentes pontos fortes e fracos. Exemplos são o rpm e o gerenciador de pacotes debian (arquivos .deb), mas existem outros. Esses gerenciadores de pacotes obviamente precisam de formatos diferentes e, portanto, não são compatíveis.

Distribuições ou versões diferentes

Como a maioria das distribuições Linux é de código aberto, há muito mais reutilização de código do que nos sistemas Windows. Um aplicativo pode usar várias bibliotecas para várias partes de sua funcionalidade. Essas bibliotecas também costumam fazê-lo, às vezes a mesma biblioteca.

Infelizmente, as bibliotecas existem em versões diferentes e algumas delas não são compatíveis (especialmente a compatibilidade binária para executáveis ​​pré-compilados). Múltiplas versões podem coexistir nos sistemas Unix (menos dll dessa perspectiva), mas na maioria dos casos, o uso de duas versões diferentes de uma biblioteca em um programa em execução está causando falhas.

Portanto, as distribuições binárias geralmente atualizam sua própria versão para passar para novas versões de vários pacotes principais (em outros casos, você precisa de grandes atualizações).

Outros arquivos diferentes

As distribuições também diferem na maneira em que arquivos específicos estão localizados e em como a configuração é gerenciada. Dependendo do pacote que pode ter um impacto nesse pacote.

Linha de comando

O Unix é principalmente um sistema operacional de estação de trabalho e servidor. Isso significa que ele foi projetado com administradores de sistema profissionais em mente. A automação é uma parte importante da caixa de ferramentas de administração do sistema e os scripts de shell são a maneira de fazê-lo. Tente adicionar os principais nomes de arquivos de 0 a 1000 no gerenciador de arquivos gráficos.

Como os administradores geralmente administram muitas máquinas, eles precisam fazer o mesmo em vários sistemas. Usando ferramentas como o ssh, é extremamente fácil executar a tarefa em vários sistemas de uma só vez, e aguarde até o computador fazer o trabalho.

Especificação precisa, automação e repetibilidade tornam a linha de comando muito melhor em potencial do que ferramentas gráficas para tarefas de administração. O Unix também tem um número de shells diferentes disponíveis e essa competição criou shells extremamente poderosos que são quase incomparáveis ​​com o prompt de comando do Windows.

A Microsoft realmente entendeu isso bem e oferece o powershell como uma substituição da linha de comando, assim como a versão mais recente do Windows Server é administrada principalmente pela linha de comando.

Os formatos executáveis ​​são todos iguais nas distribuições, mas os executáveis ​​podem exigir software subjacente adicional para funcionar corretamente. Se você observar as distribuições baseadas no Redhat, o produto de instalação é uma rpm, que incluirá todos os requisitos para um determinado pedaço de software e, por padrão, não o instalará, a menos que os requisitos sejam atendidos. ( yumé uma alternativa pararpme é usado por algumas versões baseadas em Redhat). Por definição, uma GUI deve ter uma área de cobertura muito maior do que uma interface de prompt de comando. A filosofia subjacente do UNIX é simplificar tudo para que uma determinada tarefa funcione da maneira mais eficiente possível. É por isso que existem tantos utilitários que executarão uma única tarefa com a saída dessa tarefa capaz de encadear a entrada de outra tarefa para fazer outra coisa.

Distros diferentes têm pré-requisitos de instalação diferentes. No entanto, existem RPMs ou DEBs (ou outros pacotes para outros sistemas de gerenciamento de pacotes), que funcionam para mais de uma distribuição. A filosofia do Linux torna os códigos-fonte prontamente disponíveis. Ao compilar seu próprio software, é praticamente a mesma rotina em todas as distribuições, e é sempre o mesmo .tar.gzarquivo que você usa.

RPMs compilados são mais como parte do sistema; um aplicativo em si, como uma entidade autônoma, deve ser distribuído e compilado em todos os destinos.

Suas segundas perguntas são algo completamente diferente ... Bem, "muitos usuários de Linux" preferem aplicativos CLI por vários motivos diferentes, o espaço reduzido de memória é apenas um motivo. Ao usar o SSH, os aplicativos CLI fazem mais sentido, especialmente ao trabalhar fora do local em servidores. Frequentemente, esses servidores não têm ambientes gráficos instalados. Ao executar programas não daemonizados, eles são muito fáceis de abortar. Ctrl- c, e o programa acabou. Além disso, muitos programas se registram no console, tornando mais fácil a depuração. Ao programar, você está fazendo a maior parte da compilação no console. Faz mais sentido para a depuração rápida de compilação. É isso ou, ao ler os arquivos de log, às vezes, a leitura do console é mais rápida.

Arco. Ou FreeBSD, que é desenvolvido como um todo. (RHEL, SLES e similares são $ upported como um todo.)

Uso do laptop: hortelã

Hackabilidade utilizável: Arch.

Hackabilidade sádica: Genoo.

Hackabilidade divertida: LFS.

Capacidade de suporte (servidor): RHEL, Ubuntu LTS, FreeBSD (diferente do Linux).