# Métodos de obtenção de pacotes binários e Gobo Linux

## fernandotcl

Estava pensando no quanto o gento é uma distro flexível (por isso o nome meta-distribuição), e em quantos métodos diferentes de obtenção de binários são possíves/viáveis. Resolvi tentar enumerá-los e pedir as suas opiniões.

Pacotes GRP - Tecnologia que está na lsita TODO da 2004.1 agendada para o fim de abril.

Prós - 1) Tecnologia nativa do Gentoo; 2) Permite a coexistência entre pacotes compilados e binários.

Contras - 1) Tecnologia relativamente nova, pois apesar de pacotes binários não serem novidade no Portage, será a primeira tentativa oficial de se criar um repositório GRP; 2) Falta de pacotes em abundância, levará tempo até que haja uma base sólida; 3) Inicialmente, não devem existir muitos servidores distribuindo esses pacotes.

Pacotes DEB + APT - Usar somente pacotes dos servidores Debian

Prós - 1) Ampla base de pacotes; 2) Muitos servidores distribuindo os pacotes; 3) Tecnologia antiga e amadurecida; 4) Ferramentas gráficas de atualização; 5) apt-src pode substituir o Portage.

Contras -  1) Pacotes realmente atualizados somente na versão testing; 2) Altamente dependente do Debian, tem dependências como Debconf, uma ferramenta exclusiva da distro; 3) Incompatibilidade com os pacotes compilados pelo Portage.

Pacotes RPM + APT - Implantação original da Conectiva para trasnferência de pacotes RPM usando o APT

Prós - 1) Larga base de pacotes; 2) Tecnologia relativamente madura; 3) Ampla gama de pacotes RPM fora dos repositórios é encontrada; 4) Ferramentas gráficas de atualização como o Synaptic.

Contras -  1) Incompatibilidade com os pacotes compilados pelo Portage; 2) Há de se tomar cuidado com pacotes para distros específicas.

Pacotes RPM + Red Carpet - Sistema de atualização da Ximian

Prós - 1) Larga base de pacotes; 2) Tecnologia relativamente madura; 3) Ampla gama de pacotes RPM fora dos repositórios é encontrada; 4) Ferramenta gráfica de atualização; 5) Ótima integração com o Gnome.

Contras -  1) Incompatibilidade com os pacotes compilados pelo Portage; 2) Há de se tomar cuidado com pacotes para distros específicas. 3) Sem o Open Carpet, somente repositórios Ximian são aceitos.

Pacotes RPM + Red Carpet + Open Carpet - Serviço para o Red Carpet que permite a utilização de canais não-Ximian

Prós - 1) Larga base de pacotes; 2) Tecnologia relativamente madura; 3) Ampla gama de pacotes RPM fora dos repositórios é encontrada; 4) Ferramenta gráfica de atualização; 5) Integração com o Gnome.

Contras -  1) Incompatibilidade com os pacotes compilados pelo Portage; 2) Até a versão atual (0.2), não parece não estar tão "polido" como os outros serviços da Ximian, mas isso deve mudar com o tempo; 3) É necessário enganá-lo para que reconheça o Gentoo como uma distro RPM (como Fedora, por exemplo), e atualize o sistema como atualizaria esta distro. Isso não deve ser um problema, bastando usar os canais com pacotes independentes de distro.

Pacotes RPM + YUM - Atualizador/Instalador de RPMs

Prós - 1) Larga base de pacotes; 2) Tecnologia relativamente madura; 3) Ampla gama de pacotes RPM fora dos repositórios é encontrada; 4) Ferramenta gráfica de atualização.

Contras -  1) Incompatibilidade com os pacotes compilados pelo Portage; 2) É necessário hackeá-lo para baixar pacotes neutros de distro e reconhecer o Gentoo. Não deve ser tão simples assim.

Quero a opinião de vocês, ouvir sugestões, críticas, etc. Ainda muita coisa pode estar errada nessa lista, e muita coisa deve ter me escapado também.

Não votei porque não conheço o suficiente para ter uma opinião formada, e porque devo ter esquecido uma ou outra técnica. Mas por enquanto votaria no Open Carpet.

Links: FRESH RPMS, Red Carpet, Open Carpet

ATUALIZAÇÃO:

Pacotes RPM + YUM - Atualizador/Instalador de RPMs do SUSE

Prós - 1) Larga base de pacotes; 2) Tecnologia relativamente madura; 3) Ampla gama de pacotes RPM fora dos repositórios é encontrada; 4) Ferramenta gráfica de atualização.

Contras -  1) Incompatibilidade com os pacotes compilados pelo Portage; 2) É necessário hackeá-lo para baixar pacotes neutros de distro e reconhecer o Gentoo. Não deve ser tão simples assim;

Obs.: O YaST centraliza a configuração do sistema, algo não muito popular entre os usuários Gentoo, apesar de ser uma medida que apoio. É escrito em Qt, diferentemente dos outros, escritos em GTK2. Esses são pontos polêmicos e que devem ser levados em contra, e eu não gostaria de classificá-los como positivos ou negativos.Last edited by fernandotcl on Mon Mar 22, 2004 1:22 am; edited 2 times in total

----------

## AllissonAzevedo

Na minha opinião a melhor forma de obtenção de binários concerteza é o dpkg + apt-get do debian, mas eu queria ver algo diferente, ao inves de buscar os pacotes do debian eu acho mais interessante adaptar o estilo de empacotamento para o gentoo, resumindo:

No debian o pacote samba é dividido em outros 11 como mostrado abaixo

samba - LanManager-like file and printer server for Unix.

samba-common - Samba common files used by both the server and the client.

smbclient - LanManager-like simple client for Unix.

swat - Samba Web Administration Tool

samba-doc - Samba documentation.

smbfs - Mount and umount commands for the smbfs (kernels 2.2.x and above).

libpam-smbpass - pluggable authentication module for SMB password database

libsmbclient - Shared library that allows applications to talk to SMB servers

libsmbclient-dev - libsmbclient shared libraries

winbind: Service to resolve user and group information from Windows NT servers

python2.3-samba: Python bindings that allow access to various aspects of Samba

No gentoo é apenas um pacote, o samba-xxx que contém tudo isso ai acima.

----------

## fernandotcl

 *AllissonAzevedo wrote:*   

> Na minha opinião a melhor forma de obtenção de binários concerteza é o dpkg + apt-get do debian, mas eu queria ver algo diferente, ao inves de buscar os pacotes do debian eu acho mais interessante adaptar o estilo de empacotamento para o gentoo, resumindo:
> 
> No debian o pacote samba é dividido em outros 11 como mostrado abaixo
> 
> samba - LanManager-like file and printer server for Unix.
> ...

 

Realmente os repositórios do Debian não primam pela organização.  :Wink:  E os DEBs são muito dependentes do Debian.

O que eu acho interessante e benéfico para a introdução do Linux no desktop em geral é a adoção de um padrão de pacotes binários. Os RPMs não são padrão, mas são adotados em larga escala.

Já binários para o Gentoo seriam outra dor de cabeça para os distribuidores, pois seria mais um formato a ser criado para cada programa distribuído.

----------

## Operador Nabla

Eu sempre gostei do APT, mas não gosto muito dos formatos de pacotes RPM e DEB (a estrutura deles é meio complexa e problemas de compatibilidade entre distribuições baseadas nestes pacotes, principalmente as baseadas em RPM, sempre aparecem).

Gostaria muito de ver um port do APT para lidar com formatos de pacotes mais simples (mais ou menos como o Portage já faz).

----------

## fernandotcl

Estava pensando, o CD Live do Gentoo não serve para essas instalações.

Um CD Live para essas instalações tem que ter um Portage configurado para instalar diretamente no HD. Assim, poderíamos começar uma instalação baseada em RPMs ou DEBs simplesmente fazendo um "emerge rpm" ou "emerge dpkg" para o HD.

Vou dar uma olhada no catalyst.

----------

## AllissonAzevedo

Realmente um port do apt para lidar com os binários do gentoo (os .tbz2) seria bastante interessante   :Very Happy: 

----------

## fernandotcl

 *AllissonAzevedo wrote:*   

> Realmente um port do apt para lidar com os binários do gentoo (os .tbz2) seria bastante interessante  

 

O Portage já faz o que o APT faz. Só não temos ainda repositórios binários oficiais. Deveremos ter por volta de 22 de abril, a data prevista para o lançamento do 2004.1. Certamente os servidores sejam preparados até antes.

Quando os repositórios binários sairem, modificaremos o make.conf e passaremos a usar "emerge -gk <nome_do_pacote>".

Mas um frontend para o Portage que incluisse esses repositórios seria muito útil. Se tivesse a qualidade do Red Carpet melhor ainda.  :Wink: 

----------

## fernandotcl

Uma coisa que está me fazendo desistir dos RPMs é a ininteroperabilidade ( :Shocked: ) entre os pacotes de distros diferentes.

Alguém sabe dizer no que difere, por exemplo, um RPM para o Fedora Core 1.x e outro para o Mandrake 9.1?

Eu acho que é a versão do padrão RPM utilizado. Parece que a RH quando atualiza o padrão não mantém compatibilidade anterior. Nesse caso, haveria problemas em se manter um sistema de pacotes com variação do padrão RPM utilizado? E não existem programas que façam essas conversões?

----------

## Operador Nabla

Deixe-me relatar uma coisa que aconteceu comigo.

Certa vez, estava tentando instalar no meu Conectiva 9 uma versão do xmame mais atual, com os RPMs da FreshRPMs (acho que é este o nome), que são RPMs para Red Hat. Na lista de dependências do pacote, tinha um tal de alsa-lib. Só que, no Conectiva, o mesmo pacote tinha o nome libalsa2. Conclusão: uma instalação simples falhava, mas uma forçada funcionava perfeitamente, com o xmame rodando numa boa, tudo legal (até o próximo apt-get, infelizmente).

----------

## fernandotcl

 *Operador Nabla wrote:*   

> Deixe-me relatar uma coisa que aconteceu comigo.
> 
> Certa vez, estava tentando instalar no meu Conectiva 9 uma versão do xmame mais atual, com os RPMs da FreshRPMs (acho que é este o nome), que são RPMs para Red Hat. Na lista de dependências do pacote, tinha um tal de alsa-lib. Só que, no Conectiva, o mesmo pacote tinha o nome libalsa2. Conclusão: uma instalação simples falhava, mas uma forçada funcionava perfeitamente, com o xmame rodando numa boa, tudo legal (até o próximo apt-get, infelizmente).

 

Isso é um ponto negativo grande. Enquanto um pacote para o Conectiva tem como dependência libalsa2, o mesmo para o Red Hat tem que ter como dependência o alsa-lib. São todos RPMs, mas totalmente incompatíveis entre si.

São distros comerciais, que não se importam com o usuário, querem constituir sua base de pacotes e nem consultam o nome que está sendo adotado nas outras.

A questão é a seguinte: para implantar os RPMs no Gentoo, eles teriam que pertencer a uma só "marca", ou seja, escolher entre MDK, SUSE, Fedora ou RH. O problema é que são incompatíveis pacotes até entre versões de distros. Ou seja, um pacote para RH9 é incompatível com um para RH8.

Poderíamos escolher então uma marca e uma versão. Digamos que escolhemos RH9. Mas um dia, pacotes RH9 não serão mais suportados e não serão mais feitos pela Red Hat. Não poderíamos simplesmente mudar de pacotes. Isso implicaria na reinstalação completa do sistema, uma contradição ao padrão Gentoo IORF (Install Once Run Forever  :Wink: ).

Pelo momento eu considero RPMs arriscados. DEBs eu já tinha descartado porque são muito dependentes do Debian e muito desorganizados IMO. TGZs do Slackware eu nunca tinha nem pensado.  :Very Happy: 

Eu voto no Blue Carpet - Ferramenta gráfica de manutenção e instalação de pacotes GRP e compilados, altamente intuitiva e inteiramente integrada ao Gnome.  :Very Happy: 

----------

## Operador Nabla

Você conhece o GoboLinux?

Os caras que o criaram fizeram grandes inovações em comparação às demais distribuições GNU/Linux, sendo a de maior destaque uma completa reestruturação da árvore de diretórios (/usr, /bin, /etc e outros agora são apenas links para os novos diretórios, para manter a compatibilidade). Um fator com o qual eles se preocuparam ao refazer a árvore de diretórios foi organizar o processo de instalação dos pacotes de tal modo que todos os arquivos referentes a um determinado pacote fiquem apenas no diretório destinado a este pacote (nada de bibliotecas de diferentes pacotes no mesmo diretório). Além de ter uma vantagem didática (você finalmente vai poder descobrir facilmente a qual pacote pertence aquele arquivo estranho...), esta iniciativa faz com que a própria árvore de diretórios atue como um gerenciador de pacotes (para desisntalar um pacote, basta apagar a pasta em que ele foi instalado e remover os posteriores links quebrados), bem mais simples que os atuais gerenciadores de pacotes baseados em banco de dados. E para criar um pacote, basta compactar o diretório em que o programa foi instalado.

O GoboLinux também dispõe de scripts para automatizar a instalação de pacotes a partir dos códigos-fonte, mas a coisa me parece ainda muito precária. Imagino que uma possível adaptação do Portage cairia como uma luva para o GoboLinux.

Depois que eu conheci o GoboLinux, decobri que ainda há muito o que se aprender sobre soluções em empacotamento e muitas idéias interessantes hão de aparecer.

PS: Para quem não sabe, o GoboLinux é uma iniciativa brasileira.

----------

## fernandotcl

 *Operador Nabla wrote:*   

> Você conhece o GoboLinux?
> 
> Os caras que o criaram fizeram grandes inovações em comparação às demais distribuições GNU/Linux, sendo a de maior destaque uma completa reestruturação da árvore de diretórios (/usr, /bin, /etc e outros agora são apenas links para os novos diretórios, para manter a compatibilidade). Um fator com o qual eles se preocuparam ao refazer a árvore de diretórios foi organizar o processo de instalação dos pacotes de tal modo que todos os arquivos referentes a um determinado pacote fiquem apenas no diretório destinado a este pacote (nada de bibliotecas de diferentes pacotes no mesmo diretório). Além de ter uma vantagem didática (você finalmente vai poder descobrir facilmente a qual pacote pertence aquele arquivo estranho...), esta iniciativa faz com que a própria árvore de diretórios atue como um gerenciador de pacotes (para desisntalar um pacote, basta apagar a pasta em que ele foi instalado e remover os posteriores links quebrados), bem mais simples que os atuais gerenciadores de pacotes baseados em banco de dados. E para criar um pacote, basta compactar o diretório em que o programa foi instalado.
> 
> O GoboLinux também dispõe de scripts para automatizar a instalação de pacotes a partir dos códigos-fonte, mas a coisa me parece ainda muito precária. Imagino que uma possível adaptação do Portage cairia como uma luva para o GoboLinux.
> ...

 

Isso é fantástico. Eu achava que só eu não gostava de como alguns pacotes são instalados.  :Wink: 

Vou dar uma olhada, talvez seja possível trazer isso pro Gentoo. Isso mata dois coelhos com um tiro só: de um lado, a sistema de empacotamento, e de outro, os arquivos de configuração que são deixados pelos programas.

Se você pensar bem, as coisas foram simplificadas com o Gobo. Nele não existe gerenciamento de pacotes porque qualquer pacote pode ser instalado.

Eu acho iniciativas como essa extraordinárias. Isso só vem a mostrar a flexibilidade infinita do Linux.

Vou testar no VMware. Você já testou?

----------

## Enderson

O GoboLinux saiu na capa da última edição da Revista do Linux, vale a pena

dar uma lida na matéria, e visitar o site http://www.gobolinux.org

é realmente uma distribuição "Alternativa", e segundo os criadores é

"A sua última distribuição".

Vale a pena testar, e incentivar estsa distro brasileira, que é no mínimo 

inovadora.

----------

## fernandotcl

Ok, se o mérito maior da distro são os symlinks, então façamo-os. Eu vou testar isso no VMware quando tiver um tempo (acho que já tem umas 3 coisas pra testar na fila  :Very Happy: ), mas acho que dá certo logo depois de formatar as partições criar esses links.

EDIT:

Devia ter lido os docs antes...  :Embarassed: 

Tem também que implantar os "três scripts mágicos" do Gobo no Portage.

Esse Gobo também tem suas disvantagens. Entre elas, as maiores são a desorganização da árvore, já que pra manter compatibilidade anterior são criados inúmeros SymLinks, e a dificuldade em atualizar os pacotes.

O site diz que a distro é uma das mais fáceis de se atualizar, mas isso não é verdade, já que eles não tem um Emerge ou um APT.

Na verdade, isso que o Gobe está fazendo é mais hype. É um LFS modificado.

A LSB estabelece padrões que são organizados. O que acontece muitas vezes é uma falha na criação do ebuild ou do programa. Como nesse tópico.

Talvez possamos excluir os arquivos de configuração simplesmente seguindo os padrões da LSB. Os programas que não forem excluídos devem ser adaptados, e não o contrário.

Retificando, meu voto ainda fica no Blue Carpet.  :Very Happy: 

----------

## Operador Nabla

Só mais alguns comentários.

Sobre os symlinks do GoboLinux, a coisa vai além. Em vez de você instalar arquivos em /usr/bin, /usr/lib, etc., você os instala em um diretório próprio (de um modo geral, eles têm a cara /Programs/<Pacote>/<Versão>, por exemplo). Existe um único diretório em que são armazenados todos os symlinks para os executáveis instalados --- /System/Links/Executables/ --- e outro, para os symlinks para as bibliotecas --- /System/Links/Libraries/. Os antigos /usr/bin, /bin, /usr/lib, /lib, etc. são, na prática, symlinks para estes dois diretórios. Isso permite algo curioso: uma única entrada nas variáveis PATH e LD_LIBRARY_PATH.

Sobre o Portage, fuçando os arquivos da lista de discussão do GoboLinux, descobri que já há voluntários portando o Portage para esta distro. Além disso, os desenvolvedores estão aprimorando um sistema para instalação de pacotes direto dos fontes, chamado Compile. Pelo que eu entendi, ele será mais "modesto" que o Portage, mas este é freqüentemente citado nos artigos que eu li falando sobre o Compile.

----------

## fernandotcl

 *Operador Nabla wrote:*   

> uma única entrada nas variáveis PATH e LD_LIBRARY_PATH.

 

Isso é bem curioso.  :Smile: 

 *Operador Nabla wrote:*   

> Sobre o Portage, fuçando os arquivos da lista de discussão do GoboLinux, descobri que já há voluntários portando o Portage para esta distro. Além disso, os desenvolvedores estão aprimorando um sistema para instalação de pacotes direto dos fontes, chamado Compile. Pelo que eu entendi, ele será mais "modesto" que o Portage, mas este é freqüentemente citado nos artigos que eu li falando sobre o Compile.

 

O Portage já faz o que o Gobe faz, só que com acrônimos. Por exemplo, um jogo vai sempre para "/usr/games". São as classes. A classe dos jogos instala tudo sobre jogos para "/usr/games". O Portage segue estritamente estas regras.

O problema de se criar pastas como Programs e Depot é que isso pode vir a se tornar um sistema de arquivos parecido com o do Windows, onde cada um escreve o que quer onde quer.

A questão dos arquivos de configuração remanescentes pode ser facilmente contornado pelos desenvolvedores. Eu considero uma falta de ética criar arquivos de configuração fora do ~ on-the-fly. Dessa maneira nenhum instalador consegue deletar esses arquivos. Vide XFce4. Tentem instalar e depois desinstalar.

----------

## Operador Nabla

Mudando um pouquinho o papagaio de poleiro, quando levantaram a questão do GoboLinux num outro fórum em que eu participo, eu fiz uma pergunta, curiosidade mesmo. Vou aproveitar e perguntar aqui:

Vocês sabem de onde vem os nomes dos diretórios /usr, /etc e outros?

----------

## fernandotcl

 *Operador Nabla wrote:*   

> Mudando um pouquinho o papagaio de poleiro, quando levantaram a questão do GoboLinux num outro fórum em que eu participo, eu fiz uma pergunta, curiosidade mesmo. Vou aproveitar e perguntar aqui:
> 
> Vocês sabem de onde vem os nomes dos diretórios /usr, /etc e outros?

 

Do "/etc" eu não sei... Mas dos outros você pode ver nas páginas de manual de hierarquia (man hier) ou [url=http://www.freebsd.org/cgi/man.cgi?hier(7)]aqui[/url].

Segundo isso, "/usr" vem de aplicativos de usuários, enquanto "/bin" são os aplicativos da máquina, digamos assim.

----------

## Operador Nabla

Certa vez, eu li em algum artigo que muita gente pensa que /usr vem de uma abreviação da palavra user, mas que, na verdade, esse nome vem de "Unix System Resources".

----------

## fernandotcl

 *Operador Nabla wrote:*   

> Certa vez, eu li em algum artigo que muita gente pensa que /usr vem de uma abreviação da palavra user, mas que, na verdade, esse nome vem de "Unix System Resources".

 

Eu lembro que tinha alguma coisa parecida com a origem do nome Tux, que não seria de Tuxedo, e sim de Torvalds Unix. Eu acho que é tudo viagem.  :Very Happy: 

----------

## Operador Nabla

 *fernandotcl wrote:*   

> (...) já que pra manter compatibilidade anterior são criados inúmeros SymLinks (...)

 

Eu não queria me estender muito sobre o GoboLinux porque, em primeiro lugar, desviaria o rumo do tópico e, em segundo lugar, não o conheço muito bem ainda. Mas acho que seria interessante dizer mais uma coisa.

Na prática, estes symlinks ficam OCULTOS no sistema, mas OCULTOS DE VERDADE (não aparecem nem mesmo com um ls -a ou numa sessão SSH ou FTP).

Eu acho que é aqui que entra a outra contribuição interessante dos caras do GoboLinux: a ferramenta GoboHide, que consiste em um patch no kernel e um programa que filtra certas chamadas ao kernel para ler o conteúdo dos diretórios, não exibindo entradas que você marcou com o programa gobohide para serem ocultadas. O usuário root (ou melhor, gobo) tem total controle para adicionar, remover e visualizar a lista de entradas da árvore de diretórios que devem ser ocultadas. Assim, esta camada de compatibilidade fica completamente oculta e o usuário final nem vai sentir a presença dos symlinks.

É esperar pra ver se a coisa vai evoluir bem (o projeto GoboLinux é meio recente ainda).

PS: Just in case, estou votando em GRP + Portage.

----------

## fernandotcl

 *Operador Nabla wrote:*   

>  *fernandotcl wrote:*   (...) já que pra manter compatibilidade anterior são criados inúmeros SymLinks (...) 
> 
> Eu não queria me estender muito sobre o GoboLinux porque, em primeiro lugar, desviaria o rumo do tópico e, em segundo lugar, não o conheço muito bem ainda. Mas acho que seria interessante dizer mais uma coisa.
> 
> Na prática, estes symlinks ficam OCULTOS no sistema, mas OCULTOS DE VERDADE (não aparecem nem mesmo com um ls -a ou numa sessão SSH ou FTP).
> ...

 

Eu não sou um especialista em segurança, aliás muito longe disso, mas um patch que faz com que certos arquivos fiquem totalmente invisíveis não me parece 100% desejável.

Fora do escopo da segurança, eu odeio arquivos ocultos no estilo do Windows, e certamente odearia arquivos ocultos como esses do Gobe. Mas isso é só minha opinião.

 *Operador Nabla wrote:*   

> É esperar pra ver se a coisa vai evoluir bem (o projeto GoboLinux é meio recente ainda).

 

Concordo. Espero que a distro cresça, levando o nome do Brasil para o exterior, e que algumas de suas revoluções virem padrão.

Btw, eu estava pensando, digitar "cd /Programs/Mozilla\ Firefox\ 0.8/firefox" não me parece muito agradável...  :Very Happy: 

 *Operador Nabla wrote:*   

> PS: Just in case, estou votando em GRP + Portage.

 

/me também. Pena que não fiz uma opção GRP + Blue Carpet.  :Wink: 

----------

## Operador Nabla

 *fernandotcl wrote:*   

> Eu não sou um especialista em segurança, aliás muito longe disso, mas um patch que faz com que certos arquivos fiquem totalmente invisíveis não me parece 100% desejável.
> 
> Fora do escopo da segurança, eu odeio arquivos ocultos no estilo do Windows, e certamente odearia arquivos ocultos como esses do Gobe. Mas isso é só minha opinião.

 

Arquivos ocultos no Windows são um porre mesmo, pois você tem de configurar as Opções de Pasta para poder acessá-los. Mas no caso do GoboLinux, os arquivos, apesar de ocultos, são perfeitamente acessíveis (só que você vai ter de adivinhar o nome deles, pois nem completar o comando com o TAB dá). Enfim, um recurso legal para quem quer esconder algumas coisas indesejáveis (ou que não precisam ser acessadas com freqüência, como camadas de compatibilidade) e melhorar a estética da árvore de diretórios, bem como dificultar o acesso a determinados arquivos por parte de usuários indesejados, ou o que mais a sua imaginação mandar (eu adoro ficar fuçando estas coisinhas mirabolantes; faz parte do meu perfil profissional).

Mas eu estive pensando: Se juntarmos as idéias deles de implementar uma solução robusta para ocultação de arquivos e usar outro username para o usuário root (acho que outros já fazem isso), com a idéia do Gentoo em utilizar os PAMs para permitir que apenas um seleto grupo de usuários possa logar como root com sucesso, dá pra armar um bom esquema para impedir que usuários indesejados loguem como root, pois poderiamos, além de esconder a senha do root, esconder o próprio username dele.

 *fernandotcl wrote:*   

> Btw, eu estava pensando, digitar "cd /Programs/Mozilla\ Firefox\ 0.8/firefox" não me parece muito agradável... 

 

Se você está se referindo às maiúsculas, os caras já pensaram nisto e configuraram a shell (eles usam zsh --- até aí, nada de mais, eles não são os únicos a não usar bash, pois na faculdade a gente usa Debian com a tcsh) para arrumar automaticamente as maiúsculas quando você completa o comando com o TAB. Além disso, no seu exemplo, acho que o caminho correto fica /Programs/Firefox/0.8/ , sem espaços.

PS: Desculpe-me por estender tanto assim o assunto do Gobo, mas é que eu sou meio impulsivo quando encontro coisas novas e interessantes para aprender (foi assim quando eu descobri o Gentoo há pouco tempo e acabei trocando o Debian por ele) e, por outro lado, sou sempre impelido a tentar resolver possíveis mal-endentidos que eu acabo, direta ou indiretamente, criando. Enfim, minha relação com o GNU/Linux é um tanto peculiar, eu acho.

Mas prometo que não toco mais no assunto. Já desvirtuei por demais o seu tópico.

----------

## fernandotcl

 *Operador Nabla wrote:*   

> Arquivos ocultos no Windows são um porre mesmo, pois você tem de configurar as Opções de Pasta para poder acessá-los. Mas no caso do GoboLinux, os arquivos, apesar de ocultos, são perfeitamente acessíveis (só que você vai ter de adivinhar o nome deles, pois nem completar o comando com o TAB dá). Enfim, um recurso legal para quem quer esconder algumas coisas indesejáveis (ou que não precisam ser acessadas com freqüência, como camadas de compatibilidade) e melhorar a estética da árvore de diretórios, bem como dificultar o acesso a determinados arquivos por parte de usuários indesejados, ou o que mais a sua imaginação mandar (eu adoro ficar fuçando estas coisinhas mirabolantes; faz parte do meu perfil profissional).

 

Concordo que arquivos realmente ocultos têm sua importância, mas por outro lado também pode ter suas vulnerabilidades. Não conheço suficientemente nem o Linux nem o Gobo para detalhar como, mas presumo que essas devem existir.

Agora imagine extrair um .tar.gz com um arquivo invisível e não lembrar o nome do arquivo...

E outra coisa, em que tipos de arquivos você consideraria a invisibilidade uma coisa boa? Imagino que queira saber todos os arquivos em meu ~, então presumo que não seja esse diretório. Quem sabe tornar invisíveis tudo menos ~? Mas então como editaríamos arquivos em "/etc"?

Prós --> Gostaria de uma invisibilidade parcial, que pudesse ser implantada de acordo com o usuário. Por exemplo, o usuário Joe não pode ler, escrever ou executar (em outras palavras, ver também está incluído) nada além de ~, o que promove uma grande user-friendability. Só superusuário pode ver estes níveis. Para mim isso fica bom.

 *Operador Nabla wrote:*   

> Mas eu estive pensando: Se juntarmos as idéias deles de implementar uma solução robusta para ocultação de arquivos e usar outro username para o usuário root (acho que outros já fazem isso), com a idéia do Gentoo em utilizar os PAMs para permitir que apenas um seleto grupo de usuários possa logar como root com sucesso, dá pra armar um bom esquema para impedir que usuários indesejados loguem como root, pois poderiamos, além de esconder a senha do root, esconder o próprio username dele.

 

É uma boa idéia. Mas o nome do usuário root precisa ser gerado aleatoriamente, senão com a futura dominação do Gentoo sobre todos os computadores da face da Terra ( :Very Happy: ) o nome de usuário Gentoo já será bem conhecido, assim como hoje é o root.

 *Operador Nabla wrote:*   

>  *fernandotcl wrote:*   Btw, eu estava pensando, digitar "cd /Programs/Mozilla\ Firefox\ 0.8/firefox" não me parece muito agradável...  
> 
> Se você está se referindo às maiúsculas, os caras já pensaram nisto e configuraram a shell (eles usam zsh --- até aí, nada de mais, eles não são os únicos a não usar bash, pois na faculdade a gente usa Debian com a tcsh) para arrumar automaticamente as maiúsculas quando você completa o comando com o TAB. Além disso, no seu exemplo, acho que o caminho correto fica /Programs/Firefox/0.8/ , sem espaços.

 

Melhora bem, sem dúvida. Estranhamente estou sentindo que vou ter que clicar em resume e continuar o download antes abortado do Gobo Linux.  :Very Happy: 

 *Operador Nabla wrote:*   

> PS: Desculpe-me por estender tanto assim o assunto do Gobo, mas é que eu sou meio impulsivo quando encontro coisas novas e interessantes para aprender (foi assim quando eu descobri o Gentoo há pouco tempo e acabei trocando o Debian por ele) e, por outro lado, sou sempre impelido a tentar resolver possíveis mal-endentidos que eu acabo, direta ou indiretamente, criando. Enfim, minha relação com o GNU/Linux é um tanto peculiar, eu acho.
> 
> Mas prometo que não toco mais no assunto. Já desvirtuei por demais o seu tópico.

 

Isso é uma boa qualidade num mundo competitivo. É de se notar sua presença nos tópicos mais polêmicos aqui no fórum, como no caso do APT funcionando com o Portage. Mentes "evolutivas" são sempre bem vindas.  :Wink: 

A quantidade de [OFF-TOPIC]'s não é culpa sua ou minha, e sim uma conseqüência do debate. Sem dúvida nenhuma, o tópico está ofuscado, mas isso não é uma razão para não postar mais sobre isso. Por favor, continue a falar do Gobo.

Se os moderadores não se incomodarem, porque não fazer um fork do tópico? Pelo que vi, recentemente só se tem moderado aqui material "potencialmente" perigoso às leis dos Estados Unidos da America, como complexos programas em C para mostrar um pouco de 1337... (espero queimar a língua)

Enquanto isso, continuemos o debate do sistema de empacotamento paralelo ao debate do Gobo.

----------

## fernandotcl

Operador, você está pensando em passar informação do Gobo para o Gentoo ou do Gentoo para o Gobo?

----------

## Operador Nabla

Com calma...

Eu conheço muito pouco o GoboLinux. Na verdade, só consegui um tempinho para instalá-lo em casa ontem, mas já tinha lido sobre ele na extinta Revista do Linux (essa vai me deixar saudades... Foi ela que me apresentou o Gentoo e o Gobo); a matéria sobre ele está muito boa.

Quando eu li que o processo de instalação de pacotes dele era baseado diretamente nos códigos-fonte, uma palavra me veio imediatamente à cabeça: Portage.

E acho que o que eu pensei fazia todo sentido. Hoje eu estava visitando a página de documentação do Gobo e encontrei duas apresentações "data show" dos criadores do Gobo para download (recomendo a leitura para quem nunca ouviu falar dele). No último slide de uma delas, entitulada "Perspectivas", encontrei as seguintes palavras:

 *Quote:*   

> Build system
> 
> - Projeto de uso da Ebuild (leia-se Portage, eu acho) Tree (base de dados de regras para compilação de programas)
> 
> - Colaboração com Gentoo Linux e outros projetos

 

Enfim, de algum modo, eles parecem estar realmente interessados no Portage.

Eu ainda não me inscrevi na lista de discussão deles, mas pretendo fazê-lo em breve. Aí eu vou ver lá o que eles estão fazendo com relação ao Portage.

----------

## Operador Nabla

Tem um tópico aqui sobre "Portage e outras distros", não tem?

Nós já vimos isso acontecer com o APT: concebido para trabalhar originalmente com pacotes DEB, foir portado pela Conectiva para trabalhar com os pacotes RPM e, de quebra, os usuários Debian e Conectiva ganharam o Synaptic.

Do mesmo modo, seria interessante ver o Portage portado para outras distros...

----------

## fernandotcl

 *Operador Nabla wrote:*   

> Quando eu li que o processo de instalação de pacotes dele era baseado diretamente nos códigos-fonte, uma palavra me veio imediatamente à cabeça: Portage.
> 
> E acho que o que eu pensei fazia todo sentido. Hoje eu estava visitando a página de documentação do Gobo e encontrei duas apresentações "data show" dos criadores do Gobo para download (recomendo a leitura para quem nunca ouviu falar dele). No último slide de uma delas, entitulada "Perspectivas", encontrei as seguintes palavras:
> 
>  *Quote:*   Build system
> ...

 

Eu acredito que não estejam interessados no Portage, e sim em criar um sistema de empacotamento neutro.

O sistema de gerenciamento do que nós conhecemos como ebuild e eles como recipe é descrito aqui.

Em momento algum o Portage é citado. De fato, o Gobo parece ser altamente inspirado no Gentoo, mas tem diferenças que fazem dele incompatível com o Portage.

Basicamente, podemos dizer que enquanto o Gentoo e o Gobo têm sistemas de instalação parecidos, o sistema de desinstalação é totalmente diferente.

E ebuilds não poderiam ser reutilizados, pois os recipes diferem muito deles. O link mostra um recipe típico, de duas linhas ( :Shocked: ) enquanto um ebuild costuma ter dezenas. Se eu não me engano, um "emerge sync" chega a trocar 5Mb de dados com o servidor, enquanto um pacote de 150 recipes (os servidores do Gentoo têm cerca de 4000 ebuilds segundo o site) "pesa" 150Kb.

A filosofia também se parece muito com a do Gentoo, mas é mais flexível. Isso me agradou muito.

 *Operador Nabla wrote:*   

> Eu ainda não me inscrevi na lista de discussão deles, mas pretendo fazê-lo em breve. Aí eu vou ver lá o que eles estão fazendo com relação ao Portage.

 

Eu pretendo me inscrever também. Estou baixando a iso e vamos ver no que dá.

Por enquanto eu fico com o Gentoo.  :Very Happy: 

----------

## Operador Nabla

Eu preciso ler mais sobre o Compile e os Recipes...

Já experimentou uma busca no Google. Você vai encontrar um thread na lista deles com o título "GoboLinux + Portage = GoboPorts". É um projeto de voluntários. Este me parece tender mais para o Portage do que para o Compile.

----------

## fernandotcl

 *Operador Nabla wrote:*   

> Eu preciso ler mais sobre o Compile e os Recipes...
> 
> Já experimentou uma busca no Google. Você vai encontrar um thread na lista deles com o título "GoboLinux + Portage = GoboPorts". É um projeto de voluntários. Este me parece tender mais para o Portage do que para o Compile.

 

Eles tem bastante documentação no site oficial, acabei de ler isso:

 *Quote:*   

> Sarah Sholu iniciou a escrever ferramentas para a interação com o Portage durante nossa breve romance com o projeto Gentoo

 

Lendo isso me faz pensar que uma integração com o Portage foi pensada e começou a ser desenvolvida, mas foi abortada.

Essa citação veio daqui.

----------

## fernandotcl

Descobri dois canais do Gobo no IRC: #gobo e #gobolinux, ambos no freenode.

Estarei lá amanhã e vou falar com o pessoal sobre o Portage, etc (se alguém estiver lá  :Very Happy: ). À tarde e à noite, eu acho.

----------

## Operador Nabla

Confesso que nunca usei IRC na vida  :Embarassed:   . Boa sorte!

----------

## fernandotcl

 *Operador Nabla wrote:*   

> Confesso que nunca usei IRC na vida   . Boa sorte!

 

Eu usei uma vez... e não gostei.  :Very Happy:  Não gosto da delimitação de temas. Mas já que é o que se usa...

Btw, gostei muito do LiveCD.

----------

## Gotterdammerung

Pelo pouco que li aqui, achei bastante interessante a iniciativa do pessoal do Gobo Linux de reestruturar a árvore de diretórios para seguir uma organização melhor segundo o parecer deles, mas acho que seria mais interessante ainda eles seguirem o padrão definido pela LSB. Senão, daqui a algum tempo teremos especialistas em versões de linux completamente perdidos em outras versões. 

Eu acho extremamente válida a personalização, mas um mínimo de padrão deve existir.

Com relação a melhor forma de instalação, eu já usei Red Hat, Conectiva, e Debian, além do Gentoo. De todos esses, Os baseados em RPM são extremamente complexos de serem atualizados devido a essa confusão na árvore de dependência dos pacotes. Em cada distro é uma novela diferente. 

Os pacotes DEB até que são bastante tranquilos de atualizar, mas não permitem a convivência com RPM ou TGZ. O grande diferencial do DEB é o uso das APT-Tools, mas estas podem ser adaptadas a qualquer sistema de pacotes.

O sistema emerge do Gentoo foi o que me pareceu mais organizado, e mais tranquilo de ser atualizado. Além disso, permite a co-existência com outros sistemas de pacote sem problemas. Com a vinda dos GRPs, acredito que a tendência é só melhorar. 

Não vejo nenhum motivo para usar RPM ou DEB em detrimento do sistema atual de pacotes do Gentoo, que, além do mais, é atualizado muito mais rapidamente para as novas versões disponíveis no mercado que os outros dois citados.

----------

## Enderson

 *Scitale wrote:*   

> Eu acho extremamente válida a personalização, mas um mínimo de padrão deve existir.

 

Concordo que deva existir um padrão, mas a inovação só mostra que não

há limites para a criatividade, e quem sabe eles não criam um padrão?

Pelo que li sobre o Gobo Linux, eu creio que os diretórioa ainda irão existir nos 

mesmos lugares, como /etc /etc/init.d e /lib/modules e tal, mas existe a

opção de ir pelo caminho mais simples definidos pelo Gobo Linux.

É bem mais fácil se você acabou de instalar o Linux e quer conhecer como

funciona sem nem consultar uma documentação, sai andando pela estrutura

de diretório, que tem nomes bem intuitivos, e descubrir pra que serve cada 

coisa.

----------

## Operador Nabla

Um fator que eu achei interessante no Portage é que, como ele é flexível e trabalha perfeitamente com a instalação a partir dos fontes, não é necessário esperar que os distfiles sejam colocados nos mirrors Gentoo para poder instalar. Se não estiver lá, o sistema se encarrega de pegar os fontes diretamente no site do desenvolvedor (ou em qualquer outro discriminado no ebuild). Aliás, os prórpios ebuilds me chamaram a atenção, pois são meros "bash scripts com adereços", algo que me lembra, mesmo que vagamente, a iniciativa dos Ícones Mágicos, do Kurumin.

O outro fator levantado, a rapidez com que os ebuilds são atualizados, também é interessante, mas não sei por quê, mas tenho a sensação de que justamente os pacotes de que eu mais necessito (programas matemáticos e científicos), não têm os seus ebuilds atualizados com a mesma freqüência dos outros. Um hábito que eu acabei desenvolvendo é visitar várias vezes ao dia o site http://gentoo-portage.com/ para ver quais são os ebuilds novos.

E mesmo se o ebuild que você quer não está lá, você mesmo pode escrevê-lo com relativa facilidade (se você tiver os conhecimentos necessários).

Agora é só esperar pelo GRP...

----------

## fernandotcl

 *Scitale wrote:*   

> Pelo pouco que li aqui, achei bastante interessante a iniciativa do pessoal do Gobo Linux de reestruturar a árvore de diretórios para seguir uma organização melhor segundo o parecer deles, mas acho que seria mais interessante ainda eles seguirem o padrão definido pela LSB. Senão, daqui a algum tempo teremos especialistas em versões de linux completamente perdidos em outras versões. 
> 
> Eu acho extremamente válida a personalização, mas um mínimo de padrão deve existir.

 

Eu sou a favor de padrões. Só que padrões devem evoluir.

----------

## Gotterdammerung

 *fernandotcl wrote:*   

>  *Scitale wrote:*   Pelo pouco que li aqui, achei bastante interessante a iniciativa do pessoal do Gobo Linux de reestruturar a árvore de diretórios para seguir uma organização melhor segundo o parecer deles, mas acho que seria mais interessante ainda eles seguirem o padrão definido pela LSB. Senão, daqui a algum tempo teremos especialistas em versões de linux completamente perdidos em outras versões. 
> 
> Eu acho extremamente válida a personalização, mas um mínimo de padrão deve existir. 
> 
> Eu sou a favor de padrões. Só que padrões devem evoluir.

 

De fato devem evoluir, o problema é se essa evolução vai ocorrer gradativamente conforme o uso ou desuso, segundo afirmava Darwin, ou se essas evoluções ocorrerão de maneira descontrolada como mutações no DNA. 

Tudo bem que hajam evoluções, contanto que sejam bem documentadas.   :Wink: 

----------

## Operador Nabla

 *Scitale wrote:*   

> (...)conforme o uso ou desuso, segundo afirmava Darwin(...)

 

A teoria evolutiva do "uso e desuso" não é de Darwin, mas de Lamarck.

 *Scitale wrote:*   

> (...)ou se essas evoluções ocorrerão de maneira descontrolada como mutações no DNA.

 

Esta é a teoria evolutiva de Darwin (apenas trocando descontrolada por aleatória ou estocástica).

 :Wink: 

----------

## fernandotcl

 *Operador Nabla wrote:*   

>  *Scitale wrote:*   (...)conforme o uso ou desuso, segundo afirmava Darwin(...) 
> 
> A teoria evolutiva do "uso e desuso" não é de Darwin, mas de Lamarck.
> 
>  *Scitale wrote:*   (...)ou se essas evoluções ocorrerão de maneira descontrolada como mutações no DNA. 
> ...

 

Teorias evolutivas aparte  :Very Happy: , O Gobo Linux é um sistema operacional Linux com os diretórios ocultos por um patch que garante a total compatibilidade anterior anterior com o FSH da LSB. Isso promove uma evolução gradativa entre o sistema antigo e o novo, sem quebrar nada.

Quem sabe se algum dia isso se tornar padrão, esse legacy file system oculto será extinto. Eu não prevejo isso. Pelo contrário, prevejo uma utilização cada vez mais freqüente de links simbólicos que poderão fazer uma localização do /.

Para nós isso é trivial, já que temos todas as letras de "Programs" em nosso teclado. Agora imaginem os chineses para digitarem isso com aqueles teclados unicode de 1001 teclas...  :Very Happy: 

----------

## Gotterdammerung

 *Operador Nabla wrote:*   

>  *Scitale wrote:*   (...)conforme o uso ou desuso, segundo afirmava Darwin(...) 
> 
> A teoria evolutiva do "uso e desuso" não é de Darwin, mas de Lamarck.
> 
>  *Scitale wrote:*   (...)ou se essas evoluções ocorrerão de maneira descontrolada como mutações no DNA. 
> ...

 

querelho! me enrolei mesmo! pelo menos deu pra entender o que eu queria dizer?   :Laughing: 

----------

## Phk

Aparte das novas discussões de história da biologia, e voltando ao tópico original:

 Isto é apenas so a minha opinião:  *Quote:*   

> PORTAGE Rewlz 

 

O resto ja tem barbas, e ja xateia  :Razz: 

----------

## Operador Nabla

Eu só tenho uma pequena queixa sobre o Portage: em alguns casos, ele não informa devidamente o total em downloads que ele deve fazer (por exemplo, se eu começo e interrompo um emerge -f <pacote>, vendo em seguida um emerge -pv <pacote>, a saída deste não informa o quanto falta para baixar de <pacote>, mas indica simplesmente 0 kB, como se <pacote> já tivesse sido inteiramente baixado). Outra situação dessas é quando ele baixa arquivos "surpresa", cujo tamanho não é somado ao resultado que aparece na saída de um emerge -pv. Se você não tomar a iniciativa de ler o ebuild, nunca saberia de antemão quais são estes arquivos "surpresa" (quem já instalou o tetex-2.0.2 deve saber do que eu estou falando).

----------

## Operador Nabla

Não queria recussitar este tópico sobre o GoboLinux (eu até deixei-o um pouco de lado, mas continuo acompanhando, de longe, sua evolução), mas a evolução dos ebuilds da Portage Tree está me remetendo mais uma vez à questão da reorganização da árvore de diretórios do Linux.

Não sei se vocês já perceberam, mas não é raro, durante uma atualização, que um dado pacote seja integralmente movido de um diretório para outro. Talvez o exemplo mais recente que eu posso dar é o do X.Org. Com os ebuilds para a versão 6.8.2, o diretório /usr/X11R6/ foi extinto, tornando-se um mero symlink para /usr/ (por questões de compatibilidade com outros programas). Agora, todas as bibliotecas do X.Org vão para /usr/lib/, os binários vão para /usr/bin/ e por aí vai.

Somando-se a isto as questões das instalações multislot e da desinstalação de pacotes, coisa que não era muito comum no Unix (quando a árvore de diretórios foi organizada da maneira que conhecemos hoje), mas que se tornou muito comum com as distribuições Linux atuais, fico imaginando se o Portage poderia acabar convergindo também para uma reorganização da árvore de diretórios.

Vou dar uma olhada nas outras salas do Gentoo Forums para ver o que já se discutiu sobre isso.

----------

