Artigo: Dificuldade de Instalar Programas no Linux.

Algo que sempre me deixou curioso é a relativa dificuldade em instalar software em distribuições Linux. Dei de cara com um texto em que o autor procura, ou pelo menos tenta, deixar um pouco mais claro o porquê da sistemática atual ser um tanto confusa, principalmente para novos usuários acostumados com outros sistemas operacionais pensados para desktop.

Nota: Vou procurar melhorar a minha tradução (o autor também não tem o Inglês como língua nativa e isto em alguns momentos complica) e também terminar por colocar a conclusão do autor, em que este sugere algumas melhorias que tornariam todo o procedimento mais simples para desenvolvedores e usuários.

Segue o texto:


Você já ficou maravilhado com outros sistemas operacionais tais como Windows, MacOS ou mesmo BeOS, nos quais a tarefa de instalar softwares é bem mais simples do que em Linux? Nestes sistemas operacionais você pode simplesmente baixar um arquivo .ZIP/.RAR/.EXE/etc, descompactar em uma pasta e rodar diretamento do conteúdo, ou então um instalador gráfico irá te auxiliar por todo o processo de instalação.

Estas facilidades não são encontradas em Linux, no qual há dois modos básicos para instalação de softwares: compilando ou instalando pacotes. Métodos os quais são usualmente complicados e inconsistentes entre si, sem mensionar a dificuldade para os novos usuários. Mesmo nos casos em que o gerenciamento de pacotes é simplificado, como no caso das distribuições mais populares do Linux, os desenvolvedores não conseguem ainda prover pacotes para todas as distribuições, ou mesmo para todas as versões de compiladores.

Neste espaço vou procurar traduzir fielmente o texto onde o autor expõe o porquê da dificuldade dos desenvolvedores proverem aplicativos de maneira mais simples.

Resumidamente, por que não conseguimos instalar e distribuir programas da mesma maneira simples como é feita em outros sistemas operacionais para desktops? A resposta reside no "layout" e funcionalidades do sistema de arquivos do Linux, mantidos assim pelas distribuições Linux por motivo de compatibilidade. Este "layout" é e sempre foi dirigido a ambientes multi-usuários, onde resguardar e distribuir recursos ao longo do sistema (ou mesmo através de uma LAN) era o fator chave para redução do enorme custo armazenamento e utilização de memória. Mas com a tecnologia atual e com a chegada do computador pessoal, muito desta filosofia de gerenciamento de recursos não parece mais fazer sentido.

A seguir o autor relaciona quatro fatores que, em seu ponto de vista, tornam a distribuição de binários e suas respectivas bibliotecas complicadas no Linux.

1. Distribuição por local físico.
2. "Instalações Globais" ou "Inferno das Dependências versus Inferno das Dlls".
3. Diretório corrente não consta no PATH.
4. Ausência de arquivo metadata.

1 - Distribuição por local físico.

Muitas vezes notamos diretórios que contêm os seguintes subdiretórios:

lib/ - contendo bibliotecas compatilhadas.
bin/ - contendo binários/scripts executáveis.
sbin/ - contendo binários somente acessíveis ao "super usuário".

Se você procurar ao longo do sistema de arquivos, você encontrá muitos locais onde estes nomes de diretórios se repetem, por exemplo:

/
/usr
/usr/local
/usr/X11R6

Então você pode se perguntar o porquê de os arquivos serem distribuídos desta maneira. Isto está ligado à razões históricas, como "/" sendo um disco de inicialização ou rom, "/usr" sendo um ponto de montagem global, originalmente carregado a partir de fita magnética, disco compartilhado ou mesmo pela rede, "/usr/local" para instalação local de softwares, quanto ao "/usr/X11R6" o autor não tem idéia, quem sabe pelo seu tamanho muito grande.

Pode ser notado que até recentemente, sistemas baseados em Unix foram desenvolvidos visando tarefas específicas, e nunca para abrigarem uma grande variedade de programas como é no caso dos computadores pessoais. É por isto que não notamos diretórios organizados por finalidade, diferentemente de outros sitemas Unix-Like (principalmente BeOS e OSX), ao invés disto temos estes diretórios organizados por local físico.

Muitos anos atrás, empresas como SGI e SUN decidiram atacar este problema criando o diretório "/opt". Este diretório pensado para conter os programas e seus dados compartilhados (tais como bibliotecas e binários) os quais eram expostados para o "root filesystem" (em /usr) através da criação de links simbólicos. Isto tornava simples a tarefa de desinstalar programas, bastando deletar o diretório do aplicativo e então rodar um script para remoção dos links inválidos. Esta abordagem nunca foi popular entre as distribuições Linux, e mesmo assim esta abordagem não resolve o problema dos pacotes de bibliotecas.

2 - "Instalações Globais" ou "Inferno das Dependências versus Inferno da Dlls".

Devido aos fatos apresentados anteriormente, todos os métodos usuais de instalação de softwares (tanto pacotes binários, assim como fontes) forçam o usuário a instalar globalmente no sistema, disponibilizando para todas as contas. Com esta abordagem, todos os binários vão para locais comuns (/usr/bin, /usr/lib, etc). Apesar de ter suas vantagens, como o uso maximizado das bibliotecas compartilhadas, o método apresenta limitações. Isto faz com que todos os programas se utilizem de um mesmo conjunto de bibliotecas com versões compatíves entre todos eles, o que não permite a instalação de mais de uma versão de um mesmo programa.

Por causa disto também, se torna impossível aos desenvolvedores embutir apenas as bibliotecas necessárias para uma revisão de um binário específico (muito arriscado), então o usuário é forçado a instalar as bibliotecas necessários por si mesmo. Isto nos leva a lidar com o "inferno das dependências", que acontece quando o usuário baixa um programa (fonte, pacote, ou binário compartilhado) e este informa que mais bibliotecas (antigas ou novas) são necessárias para rodar o programa.

Apesar da implementação de bibliotecas compartilhadas no Linux ser mais complexa do que aquelas presentes no Windows, é o sistema de arquivos que não permite a distribuição de binários com as respectivas bibliotecas embutidas, as quais o usuário provevelmente não tem.

Um truque sujo é embutir as bibliotecas dentro do executável, isto é chamado "static linking", mas esta abordagem têm muitos obstáculos, tal como o aumento do uso de memória por instância de programa, "error tracing" mais complexo, e mesmo limitações de licenciamento em muitos casos, sendo assim, este método não é encorajado normalmente.

Para concluir com este ítem, temos que dizer que é difícil para os desenvolvedores distribuírem binários com versões específicas de bibliotecas embutidas. Lembrando que nem todas as bibliotecas precisam ser embutidas, mas somente aquelas que se espera que o usuário não tenha no sistema. Bibliotecas mais utilizadas como "libc", "libz" ou mesmo GTK ou QT podem permanecer disponíveis globalmente no sistema.

Muitos poderiam apontar que esta abordagem lida com o que conhecemos como "Inferno das Dlls", muito conhecido em sistemas Windows. Mas isto atualmente ocorre porque programas que portam bibliotecas fundamentais disponibilizadas globalmente no Windows, sobrescrevem versões atuais com versões mais antigas. Isto em parte acontece porque o Windows não suporta múltiplas versões de uma biblioteca como no Unix, mas também porque, no momento do boot o kernel pode apenas carregar bibliotecas no formato de arquivo 8.3 (você pode ter bibliotecas em formatos de arquivo diferentes deste). Como maneira de se resguardar, desde o Windows 2000 é mantido um diretório com cópias das versões mais recentes das bibliotecas disponíveis no caso de algum programas sobrescrevê-las. Em resumo, "Inferno das Dlls" pode ser definido como a falta de alguma versão específica de biblioteca do sistema.

3 - Diretório corrente não consta no PATH.

Isto é um tanto simples, mas tem que ser também colocado. Por padrão, em sistemas "Unix-Like" o "current path" não é reconhecido como um "path" para biblitecas ou binários. Por causa disto, você pode descompactar um arquivo e rodar o binário nele contido. Muitos binários compartilhados que são disponibilizados usam o expediente de criar um "shellscript" contendo algo como o que segue:

#!/bin/sh

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.
./mybinary

Isto pode ser resolvido de maneira simples adicionando-se "." ao "path" da biblioteca e binário, mas nenhuma distro o faz, porque não é padrão nos sistemas "Unix-Like". Claro que, do ponto-de-vista da aplicação é perfeitamente normal acessar dados a partir de caminhos relativos, então você ainda tem subdiretórios com dados.

4 - Ausência de arquivo metadata.

Sempre nos maravilhamos com o fato de os binários para Windows possuírem seus próprios ícones e nos perguntamos o porquê de não ser da mesma maneira no Linux? Isto ocorre porque não há um modo padrão de definir metadata nos arquivos. Isto significa que não é possível embutir um pequeno pixmap dentro do arquivo. Devido a isto, é difícil explicitar qual binário, ou mesmo arquivo, o usuário deve rodar. Não é possível afirmar que isto seja uma limitação do ELF (Executable and Linking Format), desde que este permitirá adicionar suas próprias seções ao binário, mas há uma certa falta de padronização de como fazer isto.


original: http://www.osnews.com/story.php?news_id=2377
autor: Juan Linietsky

Pacotes TGZ (do Slack) é batata instalar, só não cria os tais ícones...

E a questão das dependências, Geek? fica normal?

[]s

Não faz tanto tempo que uso o Slack (uns 3 meses eu acho :mrgreen, mas nada disso por enquanto...

Mas francamente isso não me "assusta", é chato, mas basta instalar as dependências que o programa pede...

Legal...aliás eu estava tentando acessar o site do Slackware, pois estou tentado a testá-lo....Mas parece que hoje tá parado. .... :?

Acho que a maior razão de não haver "instalações fáceis" no linux é: portabilidade

No windows é fácil; a não ser que você seja um super-admnistrador num super-computador, você vai ter um x86 com a instalação normal do windows. As bibliotecas são mais ou menos as mesmas para tudo funcionar. Um problema disto é que vc roda um programa i386 em qualquer computador, sem as otimizações do i586 ou i686. Somente programas específicos ou que usam libraries específicas aproveitam disso. Os programas q vêm em instalações fáceis normalmente nem têm debug e são cheios de coisas que não queremos.
O programador no windows se importa em vender seu produto para uma máquina parecida com todas as outras.

Já o programador no linux quer ver seu programa rodar em todas as plataformas e arquiteturas, se expandir ao máximo. Para isso ele te dá um código pronto para ser compilado, só precisamos configurá-los ao sistema. Com o código também podemos escolher (através do configure) várias opções; otimizações. Se você quer mesmo ver este programa funcionar, dependencies não são problemas, vc vai atrás.

Se você quer um sistema onde é fácil instalar qualquer programa, volte ao windows. Se quiser ficar com o Linux, não reclame, ele não foi feito para ser um desktop onde se joga paciência e o usuário está pouco se lixando para o trabalho dos programadores.

Obrigado pelo comentário, muito legal...

Só queria reparar uma obervação tua:


Se você quer um sistema onde é fácil instalar qualquer programa, volte ao windows. Se quiser ficar com o Linux, não reclame, ele não foi feito para ser um desktop onde se joga paciência e o usuário está pouco se lixando para o trabalho dos programadores.

Você tem razão quando diz que o Linux não foi pensando para ser usado em desktop como Windows. Mas acontece que, se as distribuições desejam realmente enveredar pelo campo dos usuários domésticos (até mesmo corporativos), aí então, ter-se-á que repensar o modelo a ser adotado neste caso, por razões claras. Note que o autor cita o Mac OSX, o qual trata-se de uma sistema "Unix-Like" poderoso, da família UNIX 4.4 BSD Lite (que foi desenvolvido pela Universidade da Califórina, em Berkeley - BSD = Berkeley Software Distribution), que gerou o Darwin, mantido agora no projeto chamado "OpenDarwin" e que finalmente foi a base para o sistema padrão atual da Apple Computer. É UNIX e não é complicado. O conceito de facilidade não é sinônimo de fraqueza, muito pelo contrário.

Outra coisa, é que o próprio autor do texto é desenvolvedor e ele crê que melhorias neste sentido facilitariam não somente a vida de usuários, mas também de desenvolvedores, estimulando desta maneira uma produção mais intensa e efetiva de bons softwares nativos para Linux.

Concordo com voce e acho que a grande dificuldade para desenvolvedores e para usuários (principalmente os que estão iniciando no linux) é a diferença entre as Distros. Por exemplo: o esquema da
UNITED LINUX é uma boa idéia a ser adotada.

Olá amigo!

Eu parei de comparar os dois sistemas (Windows e Linux), por ainda saber muito pouco sobre Linux, mas confesso que só comecei a entender melhor o Linux, depois que parei de comparar ele com o Windows.

Creio que a maioria se sente um rico que ficou pobre qdo começa a usar Linux, pois começa sem nada, do zero e isso os deixam muito frustrados, assim como eu fiquei no começo.

Giga

BEM ASSIM MESMO QUE EU SENTIA RICO TIPO O JUIZ NICOLAU AO INSTALAR TUDO QUE CONSEGUIA POR AÍ :P

AGORA FICO FELIZ AO ENTRAR NO LINUX AQUI
NO LINUX SOMOS MAIS HONESTOS COM OS SOFTWARES

HEHE

[quote="Ricardo de Castilho"]NO LINUX SOMOS MAIS HONESTOS COM OS SOFTWARES [quote]

Essa frase diz tudo sobre a filosofia do Linux, depois que eu começei a usar o Linux ativamente, começei a pegar somente softwares livres ou freeware para uso, mesmo no windows, aqui em casa somente o Windows é "genérico", o resto é tudo free ou shareware.

Abraços.

[quote="Tux"][quote="Ricardo de Castilho"]NO LINUX SOMOS MAIS HONESTOS COM OS SOFTWARES é bem por ae, o software aberto nos deixa essa liçao quando ele passo a ficar presente no nosso dia-dia, aprendemos a cada vez mais nos livrar da pirataria

Como usuário antigo e desenvolvedor em ambiente Windows (desde da v3.0), e novato no Linux, tenho que concordar que existem maiores facilidades nos processos de instalação e atualização de aplicativos na plataforma da Micro$oft.
Não creio que a complexidade envolvida nos procedimentos deste tipo no Linux seja um grande problema para os usuários com maior conhecimento técnico, porém, maior simplicidade talvez tornasse seu uso em ambientes corporativos ou mesmo nas máquinas tipo desktop nos escritórios mais viável.
Normalmente quando enfrento dificuldades para instalar ou atualizar programas procuro nas fartas fontes de informação existentes na Web ou na própria distribuição e em 90% dos casos consigo encontrar a solução rapidamente.
Creio que para o usuário final (aquele que usa seu computador como ferramenta para o desenvolvimento de seu trabalho - ex. edição de textos ou gráficos, cálculos de engenharia, desenho técnico, etc...) este tipo de procedimento torne o uso do linux contra produtivo.
Acho que dentro de algum tempo teremos inseridos- talvez como evolução normal do SO - alterações na estrutura do linux que permitam que desenvolvedores criem um ambiente de instalação mais simples e acessível para o usuário mais comum. ( Pelo menos faço votos para que assim seja)

Olá amigos.

Será que liberdade demais atrapalha no aprendizado no Linux?

Eu gosto dos arquivos com extensão .bin, hehe :mrgreen:

Instalei a versão full do UT2003 no meu Slackware e foi melzinho na chupeta!

Giga

realmente, problemas de dependência são uma dor de cabeça. Eu mesmo tenho o slackware instalado na minha máquina, uso linux há 2 anos, mas no momento estou sem o gtk2.0 pois para instalá-lo preciso do pango que não compila nem por decreto. Assim sendo fico sem poder instalar muitos programas como o Revolution por exemplo, por falta do gtk. Acho que essa invenção de várias bibliotecas diferentes para fazer o mesmo serviço muitas vezes dificulta a vida do simples usuário que só quer ler emails navegar na web.

É por aí....

Se o GNU/Linux, quero dizer, se as distribuições voltadas realmente para desktop pretendem se desenvolver neste ramo de usuários que , como falou nosso amigo, pretendem apenas ler mail, navegar na net e coisas triviais, porém importantes, tem que realmente repensar os procedimentos.

Podem falar que é fácil, que é cômodo, mas é assim que tem que ser para uso geral. Não adianta oferecer um sistema operativo que precisa vir acompanhado do tão amado "A Bíblia do Linux", que além de livro serve para apoiar mesa, pesa 10 kg.

Eu sou um usuário iniciante em linux. Sempre sofri c/ problemas de dependências ... No começo foi mais difícil ... hj estou me acostumando. Mas falta outra coisa no linux: o visual p/ usuários domésticos, aqueles que somente querem internet, editor de textos etc. O RH8 já tem um visual mto bom, mas as letras no Mozilla são horríveis ... o MDK9 tem belas fontes, mas o visual (KDE 3) ...

Então, a solução foi instalar o KDE 3.1 no MDK90. Mas e as dependências: QT 3.1. O autor do tópico inicial disse que essas bibliotecas não são necessárias, pois são comuns a todos os sistemas, mas como instalar o 3.1. Todos já vem c/ o QT 3.0. Mas p/ atualizar ... não consigo compilar, make e make install, PQ não instala ...

Espero que qdo lançarem o KDE 3.1, venham pacotes pré-compilados p/ cada distribuição ...

Eu acho que esse tipo de usuário deve permanecer no Windows para não "contaminar" o Linux, (pelo menos, por enquanto), eu quero deixar bem claro que não tenho nada contra o Windows ou seus usuários, pois tbm sou um, mas acontece que o usuário de Windows que tem o perfil citado acima, dificilmente irá entender a dificuldade de instalar softwares por exemplo, pra ele deve estar tudo mastigado, e se ele não encontra o que quer, logo sai falando mal do Linux, e é isso que "contamina" o sistema e sua propagação, (dá-se vista, matéria publicada na Folha de SP, que dizia uma série de inverdades negativas em relação ao Linux). Quanto à dificuldade de instalar programas no Linux, tenho aprendido uma coisa, no caso do Mandrake, pacotes ".rpm" costumam ser bem funcionais, apesar de muitos dizerem ao contrário, comigo tem funcionado. Quanto aos fontes para compilar, aprendi que nem sempre a rotina abaixo dá certo:
$ tar -zxvf nome_do-arquivo.tar.gz
$ cd nome_do_arquivo
$ su
# ./configure
# make
# make install
É sempre mais recomendável então, descompactar o arquivo-fonte com $ tar -zxvf nome_do_arquivo.tar.gz, e ai então procurar algum READ-ME no diretório criado e seguir as instruções que estiverem lá, na minha opinião, é mais seguro.

Li tb o README, INSTALL mas nda funcou ... quem sabe sou eu que não entendi ... :lol:

Realmente esse Qt 3.1 no Mandrake tá difícil, o meu Qt 3.0.5 dá pau no Kbabel aleaorioamente, e eu tb naum consigo atualizar... :roll:

Os QT tem tem são ASPLinux e RawHide que não funfam aqui, pelo jeito teremos que esperar alguém atualizar esses pacotes ae, o último para Mandrake é o 1.44 :cry:

Aproventando, alguém sabe o que são esses ASPLinux e RawHide? :?: