Arquivos históricos do BR-Linux.org apresenta:

Distribuições nacionais: sobe o GoboLinux, desce o Magnux

Notícia publicada por brain em junho 6, 2004 09:37 PM | TrackBack


O Slashdot deu destaque ao compile, a inovadora ferramenta de instalação de pacotes do GoboLinux. Com algumas similaridades em relação ao Portage (do Gentoo), a alternativa da distribuição nacional tem alguns extras bastante interessantes: faz o download dos pacotes de código-fonte diretamente do site oficial de cada software, leva em conta pacotes instalados "na mão" pelo usuário ao verificar dependências (no estilo particular do GoboLinux), usa arquivos de configuração minúsculos e é independente de paths (também no estilo típico do GoboLinux), permitindo inclusive a instalação rootless da distribuição.

A quantidade de inovações e boas (ainda que às vezes meio chocantes, e certamente iconoclásticas) idéias implementadas no GoboLinux deve ter sido um dos fatores que fez com que mais de 1500 live CDs da sua nova versão fossem distribuídos durante o FISL. Eu trouxe o meu na mala, e certamente vou querer conhecê-lo melhor.

Em contraponto, outra distribuição nacional, o Magnux, anunciou que seu desenvolvimento está suspenso. O anúncio informa que será mantido o suporte até o dia 30 de setembro, e que o autor está disposto a oferecer apoio se surgir algum desenvolvedor ou grupo interessado em dar prosseguinmento ao projeto.

 

Comentários dos leitores
(Termos de Uso)

» Deyson Thome () em 06/06 22:25

O Gobo é muito bom. À partir desta semana irei fazer algo inusitado, tentarei usar a distro como servidor lts....ainda não tentei nada, apenas irei iniciar amanhã.b Também não sei se é inusitado...rs


» William da Rocha Lima () em 07/06 01:27

Para interessados em saber mais sobre o Compile:

http://www.gobolinux.org/index.php?lang=pt_BR&page=doc/articles/compile

Em pt_BR

falou,


» Daniel Dantas () em 07/06 06:38

O emerge, da gentoo, pode baixar os pacotes diretamente dos sites originais também. É só não colocar nenhum espelho no arquivo de configuração. O emerge procura o pacote a ser baixado em um dos espelhos configurados e, se não encontra, no site original, que está no arquivo de configuração. Eles preferiram colocar esse esquema de espelhos para não congestinar os sites originais.
Sobre esse negócio de ser independente de caminhos (paths), isso é uma faca de dois legumes (gumes). O sistema de arquivos fica "organizado", mas em compensação a variável PATH fica gigantesca, ocupando memória e ciclos de cpu desnecessários, ou, em outra implementação, o sistema de arquivos fica inchado com arquivos desnecessários, que seriam links para os arquivos reais. Os links também ocupam espaço. Claro que com o preço da memória hoje em dia e do hd, esse tipo de coisa é meio irrelevante, mas essas duas coisas não são inovações.
Apesar do que falei, acho que vou dar uma testada nessa distribuição. Quem sabe ela não é melhor...


» Eduardo () em 07/06 10:31

Links ocupam espaco?

Os meus ocupam 4,6,10... alguns ocupam 20 bytes. (depende do tamanho do path que eles apontam)

Supondo que cada link ocupasse 20 bytes, e que uma pessoa tivesse 1 milhao de arquivos executaveis, e, portanto, 1 milhao de links, eles ocupariam, ao total, 20 megabyes (20 milhões de bytes, na verdade), ou o equivalente a uns 5 MPSs/OGGs de 4 minutos.

Ou entao, considerando que um HD de 80 GB custa em media 300 reais: para armazenar todos esses links essa estaria usando 0.00025% do seu HD, equivalente a, exatamente, 7 centavos e meio de real, menos que uma bala Juquinha (aquelas amarelas, que geralmente se come junto com o plástico em que a envolve, e custam 10 centavos).

Pensando assim, 1 milhão de links não ocupa tanto espaço...


» Augusto Campos () em 07/06 11:04

Oi Eduardo. Links simbólicos não ocupam apenas o espaço nominal que o comando 'ls' exibe. Eles são armazenados no seu disco como se fosse um arquivo qualquer, e nos sistemas de arquivos tradicionais, o espaço mínimo ocupado por um arquivo qualquer é um valor relativamente alto.

Não vou para as explicações técnicas aqui, até porque elas são abundantemente documentadas. Nem quero invalidar tua argumentação, só quero dizer que os valores não são tão baixos quanto parecem à primeira vista.

A não ser que se use hard links, mas aí as limitações são muito grandes.


» odair () em 07/06 11:56

Na minha opinião, para quem não está interessado
em otimizar até o último tostão os seus
bytes e ciclos de CPU, existe público para Unix
que segue uma filosofia de gerencialmento
de pacotes completamente oposta da tradição RedHat/Debian. No lugar de ter um bom
gerenciador de dados (apt, rpm) que memoriza
onde cada arquivo está guardado, sempre
haverá pessoas interessadas em deixar cada
pacote completamente separado um do outro.
Para quem gosta de modificar e compilar pacotes,
rodando várias versões de um mesmo programa,
pode facilitar a vida.

O bom do SL é o seguinte: uma idéia (boa ou má) na cabeça e você tem uma distribuição nova na mão.


Odair


» Daniel Dantas () em 07/06 12:04

Pô, Augusto, falou e disse. É verdade, nem tinha pensado nisso. Os arquivos no hd, na prática, tem um tamanho mínimo, que é o do inode. Os inodes dos hds de hoje tem, geralmente, 4kb. Então, ter um arquivo de 4kb ou de 20 bytes dá na mesma, na prática.
Isso elimina a vantagem de ser ter um arquivo de configuração minúsculo, nesse sentido, é claro. Não estamos pensando na facilidade de manutenção (leia-se, atualização). O que se poderia pensar é em colocar todos os links em um único arquivo ou em poucos, ou seja, agrupar os links para aproveitar melhor o espaço. Seria interessante. Ao invés de fazer um rsync, somente baixaria o arquivo com os links ou o patch para atualização dos mesmos. Economia enorme de recursos do servidor.
Poderia se pensar em colocar todos os links, como arquivos mesmo, mas em um arquivo compactado, tipo o tar.gz. Isso também aproveitaria o espaço disperdiçado, mas acabaria com a vantagem de usar o patch. Se bem, que um arquivo compactado com somente texto seria pequeno. Um arquivo de 20MB seria menos de 1MB?? 200KB??


» fernandotcl () em 07/06 17:09

Não é tão simples assim. Praticamente todas as distribuições normais usam links para muitas coisas. Na verdade, os links do GoboLinux são melhores, porque enquanto nas outras distros você vai pulando de link em link (mesmo sem saber), no GoboLinux você vai direto.

O que eu acho é que existe um período de tempo até que a distro amadureça, já que o ideal seria que todos os pacotes usassem a GNU autotools, mas não usam. Assim fica mais difícil adaptar os pacotes à nova hierarquia do sistema de arquivos. A idéia do GoboLinux pode um dia ser adotada em grande escala, na minha opinião, se:

1) O método de compilação de pacotes for unificado. Isso significa que todos os programas devem usar variáveis pra caminhos de arquivos, e não caminhos "hard-coded".

2) Os aplicativos com caminhos "hard-coded" começarem a ser portados para a distro.

Só assim nos livraremos da árvore de legado, e assim poderemos dispensar a "emulação" feita pelos links. Hoje em dia, aplicativos renomados, como o Gnome, são difíceis de serem instalados no GoboLinux, porque são muito dependentes da árvore tradicional.


» Eduardo () em 07/06 18:52

Augusto, Daniel,

nos sistemas ext2 e ext3, links simbólicos só são armazenados como arquivo (ocupando 4kb), se o path para o arquivo que eles apontam for maior do que 60 caracteres. Caso contrário, eles são armazenados no próprio inode. Esses links são chamados de "fast symbolic links".

Mais informações: http://www.tldp.org/HOWTO/Filesystems-HOWTO-6.html , no item "Advanced Ext2fs features"

Entretanto, para fazer essa re-modulação da árvore de diretórios, o melhor mesmo seria usar um sistema de arquivos que lidasse de forma mais eficiente com arquivos pequenos, como o ReiserFS.

Ah, caso alguém resolva fazer as contas, no meu outro comentário eu falei "0.00025%", quando deveria ter falado "0.025%". (mas isso não afetou o resto do cálculo)


» Lucas Correia Villa Real () em 07/06 19:58

Oi Daniel,

Na realidade existe apenas um diretório contido na variável PATH no GoboLinux, que é o /System/Links/Executables, que contém symlinks para todos os /Programs/*/versao/{bin,sbin}. É mais simples de gerenciar do que se imagina ;-)

Sobre os symlinks: igual existem vários níveis de indireção no layout clássico do UNIX. Você tem coisas como /lib/libpthread.so.0 -> /lib/libpthread-0.10.so e assim por diante. No GoboLinux, existe apenas um nível extra de indireção, mas isso realmente não chega a ser notado no desempenho.

Tenho o GoboLinux rodando em um videogame que roda um cartão smartmedia (*muito* lento), e nem assim chega-se a notar qualquer diferença de performance.


» Wilfredo () em 08/06 00:48

Eu instalei o GoboLinux versão 010 (8 na base octal) e o usei por algum tempo. É bem organizado, e pretendo um dia programar para esses sistema operacional.

Acho a iniciativa deles muito boa e só não contribuí ainda por falta de tempo.

A releitura da arquitetura de diretórios dos projetistas do GoboLinux foi ousada, mas foi bem planejada.

Vida longa ao projeto! Mas para que isso ocorra, os mantenedores precisarão de um esforço redobrado até adaptar os programas livres para ambiente Unix se acomodarem na estrutura de diretórios.


Comentários desativados: Esta discussão é antiga e foi arquivada, não é mais possível enviar comentários adicionais.



O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação, layout, tabela de caracteres, etc.) o acervo de notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter de acervo, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.