Visite também: UnderLinux ·  VivaOLinux ·  LinuxSecurity ·  Dicas-L ·  NoticiasLinux ·  SoftwareLivre.org ·  [mais] ·  Efetividade ·  Linux in Brazil ·  Floripa  

Lançado o Gobo Linux 012

“Foi lançado recentemente o Gobo Linux, na sua versão 012. O GoboLinux é uma distribuição Linux alternativa que redefine toda a hierarquia do sistemas de arquivos. No GoboLinux o sistema de arquivos é o gerenciador de pacotes: cada programa está localizado em seu próprio diretório, como /Programs/Xorg/6.7.0/ e /Programs/KDE/3.2.2. Achou interessante? Então acesse o site oficial para maiores informações.

Comentários dos leitores

Os comentários abaixo são responsabilidade de seus autores e não são revisados ou aprovados pelo BR-Linux. Consulte os Termos de uso para informações adicionais. Esta notícia foi arquivada, não será possível incluir novos comentários.
Comentário de Jura
Já era hora de alguma distri: Já era hora de alguma distribuicao colocar todos o programas em um diretorio em separado tendo "a mesma base de diretorio".
Tudo dentro de Programas. Se quiser encontrar algum arquivo de configuracao ou remover o programa basta ir ao encontro do seu respectivo diretorio...
Comentário de
Já era hora: Na verdade o Gobolinux já faz isso há algum tempo... Uma das últimas edições da extinta RdL detalhava o funcionamento do sistema, que mesmo na ápoca não era propriamente recente.
Comentário de Wilfredo
Foi onde conheci o Gobolinux: Quando comprei um exemplar da edição da Revista do Linux com o Gobolinux, fiquei bastante curioso. Quando instalei, gostei do que vi. Recomendo experimentar.
Comentário de Operador Nabla
Mais precisamente, foi na úl: Mais precisamente, foi na última edição da Revista do Linux, a #50, que saiu a matéria de capa com o GoboLinux. Foi através dela que eu conheci esta distribuição, também (assim como foi por ela que eu conheci o Gentoo). Atualmente, embora eu seja um usuário regular do Gentoo, sou um grande entusiasta do GoboLinux (cheguei a mantê-lo instalado na minha máquina por algum tempo, mas a minha experiência foi um pouco desastrosa; assim que eu colocar um HD maior no meu micro, voltarei a experimentar a distro).

Acho que ela ainda precisa amadurecer um pouco, principalmente em relação ao Compile, seu assistente de compilação e instalação de pacotes (essa foi a impressão que a versão 011 me passou; preciso ver como está a versão 012), mas, fora isto, acho o GoboLinux formidável (sua proposta de reorganização da árvore de diretórios me conquistou definitivamente).

E eu estou na torcida para que saia alguma análise sobre o GoboLinux na revista Linux Magazine (eu até já mandei um e-mail para eles sugerindo isso).
Comentário de ricardomoc
Instalador: O seu instalador também é muito bom. Em modo gráfico (se não me engano existe uma opção em modo texto). Se não me engano, é em estilo livecd, não? Ou seja, depois que você acessa o sistema, basta fazer a instalação.

Ricardo Rabelo Mota
Site Católico Nossa Senhora Rosa Mística
http://www.rosamistica.org
Comentário de ricardomoc
Site: Quanto a esta distro, tem um detalhe que me incomoda: é o site deles. Inclusive tem uma mensagem que procuram tradutores para as páginas do site. Ora, o Gobolinux não é uma distro brasileira? Ou será que o site é mantido por algum colaborador estrangeiro?

Ricardo Rabelo Mota
Site Católico Nossa Senhora Rosa Mística
http://www.rosamistica.org
Comentário de Webmarlin
Organização: Tb acho que a estrutura de pastas do Linux poderia ser melhor organizada e, principalmente, padronizada. Se o padrão do Globo Linux ou não... não importa. O fato é que cada distro arruma da maneira que quer e causa uma confusão danada.
Comentário de Hugo
É uma distro brasileira feit: É uma distro brasileira feita para o mundo, por isso a página esta em inglês, traduzir é uma tarefa muito trabalhosa e provavelmente eles, os desenvolvdores, devem ter seus motivos para tentarem "terceizar" a tradução da página.
--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org
Comentário de Hugo
Acho que é esse o pensamento: Acho que é esse o pensamento do GoboLinux, tentar resolver essa confusão das pastas, talvez fazendo outra confusão ;).

Nunca usei o GoboLinux, mas ja li um bocado sobre ela no próprio site e acho legal a ideia de tentar inovar a estrutura de diretórios do UNIX, concordo 100% com os argumentos que o autor da ideia teve para essa mudança.

Seguir padrões tem suas muitas vantagens, porém a tecnologia evolui muito mais lentamente quando é forçada a seguir os padrões... é um dilema cruel...

--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org
Comentário de Cadu
Padronização: As pessoas gostam de reclamar da falta de padronização do Linux. Lá no FISL, uma das reclamações que os representantes das empresas fizeram num debate foi de que o Linux não tem padrões. Um absurdo. O Linux não só tem padrões, como os softwares livres são os que mais seguem padrões. A falta de conhecimento é o que mais gera FUDs como esse.

E por falar em padrão para a organização de arquivos no Linux, ele já existe! Sim, já existe: http://www.pathname.com/fhs/
Comentário de Arkanoid
A idéia de diminuir a quanti: A idéia de diminuir a quantidade de diretórios na raiz de um sistema unix e, de quebra, fazer com que cada programa tenha seu próprio diretório (junto com arquivos de dados, help, imagens e tudo o mais) não é nova... pelo que já li, quem teve primeiro essa idéia foi o NextStep.
Nunca vi um NextStep "ao vivo" claro, mas o projeto GNUstep (www.gnustep.org) tem algumas informações.

--
Distribuidor Regional de Falácia Inglesa Enlatada
Comentário de
Internacional: Várias das páginas do site já têm versão em português, e os desenvolvedores oferecem um caminho claro para quem desejar colaborar na tradução.

Se eu estivesse construindo um produto livre com objetivo de fazê-lo ultrapassar as fronteiras nacionais, acredito que também o divulgaria primariamente em inglês, como ocorre na maior parte (com exceções, claro) de projetos de base européia provenientes de países não-anglófonos (um exemplo que me vem à mente neste momento é o do mplayer), e com projetos transnacionais como o Debian (origem norte-americana) e a Mandriva (franco-brasileira). Divulgar em klingon, em esperanto ou em volapük provavelmente não atingiria a mesma audiência, e divulgar na lingua nacional dos desenvolvedores também não.

Ainda no caso hipotético, acredito que eu faria um esforço para manter divulgação paralela em lingua nacional, e procuraria facilitar que outras pessoas interessadas contribuíssem com a tradução, se desejassem.

E me parece que é o que o pessoal do GoboLinux faz. E a julgar pelo fórum do projeto, me parece que os usuários de fora do Brasil não são poucos. E todos os interessados podem contribuir na tradução para o português e o alemão.
Comentário de StanStyle
Comentando o comentário: É, pouca gente sabe (em geral os "recém-chegados").
Acho que os caminhos usados que divergem de distro para distro, o que acaba gerando, talvez, estes comentários.
No SUSE você costuma encontrar a pasta do kde, do gnome e do OpenOffice.org no /opt. Aqui no Ubuntu a pasta é vazia (apesar de eu ter compilado uns programas dentro dela).
Sei lá, você acaba acostumando com essa diferença, e não sei se alterar (mascarar/ligar) nomes de diretórios seja algo vital. Gosto da idéia de ter bibliotecas de diferentes versões em suas respectivas pastas. Mas quando você para e pensa: Ueh?! Da qui a 6 meses eu vou ter que instalar um nova versão da distro, será que isso realmente vale apena? De fato, pra mim, não.

Comentário de Marcelo Ulianov
nextstep: é só vc dar uma olhada no Mac OS X. ele é o NextStep de hj, se o Steve não tivesse voltado para a Apple. No X, só é exibido ao usuário o que relamente importa. O resto é problema dos desenvolvedores...
Comentário de Hugo
Não entendi bem seu argument: Não entendi bem seu argumento..."ter que reinstalar em 6 meses a distro X". =/

--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org
Comentário de StanStyle
Release: Não entendi bem seu argumento..."ter que *reinstalar em 6 meses a distro X". =/

*Instalar uma versão nova (que tenha os últimos recursos disponíveis, atualizada).

Caso contrário use o Sarge :=)
Comentário de Diogo Lima
E daí...: Realmente ninguém se importa com isso, só os desenvolvedores.
O que importa é ser fácil e ter uma cara bonitinha, de resto
tanto faz se os diretórios são /a ou /b ou /c.
Particularmente, como desenvolvedor eu prefiro o PADRãO original
mesmo com /usr /etc e etc... Por exemplo é bem melhor ter todos
os confs num /etc do que em 500 diretórios diferentes, pensa bem.
Comentário de hamacker
-: Esse argumento não se justifica, se voce tem o aplicativo ABCD e precisa mudar algo na configguração então vá até o diretório dele e edita o arquivo .conf, oras.

Mas esse assunto tá sendo uma "fébre virtual" porque de fato ninguem vai mudar nada com respeito a isso no linux atual. Imagina perder toda a compatibilidade com BSD e unix-likes, isso só traria mais trabalhos aos programadores que no fritar dos ovos mudariam sua atenção para outro unices.

Houve um tempo que meu /opt era um link simbolico para /usr/local, mas o tempo passou e percebi que isso nao adiantava nada pois alguns programas simplesmente tambem não eram instalados em /usr/local, vide o mozilla que se instala /usr/lib/mozilla. Então começei a aprender com as diferenças.

Comentário de Alessandro
Falta padrão: Esta falta de um padrão é prejudicial para o suporte, visto que para podermos dar um suporte via telefone, EMail, ... primeiro temos que saber qual a distribuição, depois a sua versão, depois ter ela instalada ou saber como ela distribui os arquivos e ai sim poder ajudar o usuário.

Para uma empresa que distribui um software para Linux, isso deve ser um tormento, claro falo de softwares específicos.

Acho que todos os unix-likes deveriam suportar este esquema, por ser mais simples e coerente, os mesmos só teriam a ganhar com isso.
Comentário de anom
Mas será que fica mesmo assi: Mas será que fica mesmo assi tão incompativel? Não é so uma questao de, na hora de compilar um programa supostamente feito pro Gobolinux no FreeBSD, usar ./configure --prefix="path_do_BSD" que pode ser automatizado nos tais arquivos de ports? Tou falando em termos de pacotes a serem compilados em ambos os sistemas. No mais, qual o tipo de compatibilidade de que se fala? No FreeBSD o xorg.conf nem está em /etc/X11, pelo menos eu não achei. Para adicionar o kdm o arquivo também é outro, quer dizer, pra mim essa suposta compatibilidade já nem é lá essas coisas. A unica coisa que percebo é que o linux se afastaria do jeitão UNIX de ser, o que pelo menos pra mim, não seria o fim do mundo, contanto que resultasse numa coisa que me parece lógica na adoção destes pacotes autosuficientes em termos de dependências de bibliotecas (se é que entendi a proposta): a diminuição brutal de problemas de dependências e uma compatibilidade muito maior entre pacotes de distros diferentes.

No lugar de dependências fortes entre pacotes, no meu modo de ver, sobram coisas como aplicação depende do X11 pra rodar e coisas mais gerais desse tipo. Assim, supondo que houvesse muitos forks do Gobolinux, algo como GloboLinux, SBTLinux, RedeTVLinux, TVDiarioLinux, etc. me parece que um pacote criado pra qualquer uma delas teria grandes chances de funcionar em qualquer outra, facilitando muito a vida de quem desenvolve. Eu ja não posso falar a mesma coisa das distros baseadas em rpm, e no debian so não acontece o mesmo ainda por que há poucas distros grandes e independentes em termos de arvores de pacotes, se bem que o Ubuntu, que eu uso, já começa a incomodar o pessoal do Debian neste aspecto.
Comentário de MnB Linuxer
...: Não vejo atrativos em uma distro que contrarie todas as regras do LSB e que imita o windows na ierarquia dos diretórios.
Gobo Linux ? isso não é distro, é uma imitação barata do sistema de diretórios do Windows.
Comentário de StanStyle
Ficaria até mais fácil para: Ficaria até mais fácil para criar um vírus para todas as distribuições! COooL :^)
Comentário de anom
Quer dizer que o grande argum: Quer dizer que o grande argumento pra não ter pacotes assim é virus? Não acho que a questao seja essa, até por que há uma maneira razaovelmente boa de impedir isso: a assinatura de pacotes que já existe em varias distribuições.

Ora, contanto que v. baixa um pacote de um repositorio onde os pacotes são assinados e dado que v. confia no autor dos pacotes, há uma certa sergurança sobre a nao existencia de virus/worms/etc. num dado pacote.

Usando o exemplo dos forks do Gobolinux, v. teria compatibilidade entre pacotes de distros diferentes e, dado que todas usem pacotes assinados e, logico, que os mantenedores dos repositórios sejam honestos, o perigo de pacotes infectados me parece tão grande ou pequena quanto é atualmente.

Atualmente, quem usa pacotes de terceiros, como fresrpms, dag e outros pra quem usa Fedora, o faz confiando que os mantenedores não estão incluindo malwares nestes pacotes, certo?
Comentário de StanStyle
Foi uma piada (apesar de ser: Foi uma piada (apesar de ser um pouco relevante).
Sim, pacotes assinados em repositórios oficiais ajudam muito mas devo lembrar que nem todos os programas estão disponíveis em forma de binários. Você então pode compilar você mesmo, ao invés de esperar que alguém o faça. Assinaturas não é a garantia definitiva que você está baixando o arquivo "real", e já vi citações e artigos referindo-se ao tema mas agora não me recordo aonde.
Também tenho que lembrar que boa parte dos quase 17.000 pacotes do repositório do ubuntu+debian, por exemplo, são criados por pessoas da comunidade e provavelmente não podem ser verificados um a um.
Mas isso é outro assunto...
Comentário de Operador Nabla
Depois de ler alguns artigos: Depois de ler alguns artigos dos desenvolvedores do GoboLinux, uma coisa ficou mais ou menos clara para mim: uma das principais motivações para reorganizar a árvore de diretórios da distribuição, colocando todos os arquivos referentes a um determinado pacote em um diretório separado, é facilitar a instalação --- e, principalmente, a desinstalação --- dos pacotes, sem precisar recorrer a algum sistema de gerenciamento de pacotes baseado em bases de dados, como são atualmente o APT e o Portage.

Esta reorganização é facilitada pelo fato de a maioria esmagadora dos programas open source utilizar as ferramentas Autoconf/Automake como assistentes de compilação, que permitem customizar facilmente os diretórios envolvidos. Talvez uma das grandes dificuldades para o GoboLinux consiste nos pacotes que instalam módulos para o kernel, pois não é possível --- até onde eu sei --- configurar múltiplos caminhos de busca dos módulos do kernel e, assim, não dá para manter este módulos isolados no diretório da aplicação --- a menos que sejam criados symlinks.

Com relação à padronização do Linux, muitos de vocês devem estar pensando no FHS, que é o padrão para a árvore de diretórios das distribuições Unix/Linux/*BSD. O documento disponível neste link me passou a idéia de que, de fato, este padrão deveria ser realmente seguido pelas distribuições, mas não necessariamente de modo "físico" --- por exemplo, segundo o FHS, o arquivo grub.conf deveria ficar em /etc, mas quem tem uma partição separada para o diretório /boot tem que deixar o arquivo neste último; a sugestão do próprio documento é manter o arquivo no diretóro /boot e criar um symlink para ele em /etc.

É mais ou menos isso que é feito no GoboLinux: toda a árvore de diretórios prevista no FHS foi implementada de modo "simbólico", não "físico", mapeando para os diretórios das aplicações por meio de symlinks. Além disso, eles tiveram o cuidado de ocultar a árvore FHS para o usuário, utilizando uma ferramenta própria. Com isso, a compatibilidade com programas que confiam na árvore FHS está praticamente garantida. Na verdade, os desenvolvedores do GoboLinux não seguiram o documento FHS "à risca" ao implemetar a sua árvore simbólica (por exemplo, não há distinção entre os diretórios bin e sbin: ambos apontam para o mesmo destino).
Comentário de Diogo Lima
Reinventando: Isso pra mim não facilita, só dificulta porque como tá no próprio
site oficial da distro, eles criam links simbólicos pras libs e pros
binários. Ou seja, tudo bem que dando um rm -rf dá pra apagar facilmente, mas ainda temque catar os links e removê-los. Qual a vantagem disso?
No mais é melhor se preocupar com os maiores problemas como as malditas dependências e a falta de "natividade" de algumas coisas
que já deviam estar "embutidas" no kernel.
Pacotes já existem milhares, padrões já existem até demais é melhor melhorar o q já existe ao invés de ficar inventando e confundindo mais ainda tentando criar um novo padrão.
Se o padrão existente fosse respeitado não haveria problema.
Comentário de
Inovação: Se eu concordasse com "Time que tá ganhando não se mexe" tinha continuado usando XP.

O Gobo é inovador e essa é a vantagem. O sistema como organizado por eles faz sentido e é válido. Quando conversei com os desenvolvedores no fisl 5, e devo dizer que eles foram muito simpáticos ao contrário de outros, eles explicaram que o conceito era tão bom que para instalar em uma máquina um programa já instalado em outra era só copiar a pasta que resolveria o problema. Isso é muito bom se ocorrer realmente.

Eu ainda não usei, pois tive alguns problemas de reconhecimento na máquina onde testei, mas achei um bom conceito e acho que vale a pena ser explorado.

Se um certo jovem não tentasse inventar algo novo, não estaria discutindo Linux com você neste site usando uma distro para digitar isso tudo.

Vinícius Medina
Usuário Linux 383765
É usuário de Linux? Mostre a sua cara!
Comentário de Diogo Lima
Isso pra mim não é nenhuma: Isso pra mim não é nenhuma inovação e sim uma gambiarra no sistema, quero dizer, pensando dessa maneira é melhor abandonar de vez o padrão anterior ao em vez de fazer o sistema pensar que existe ainda.
A implementação desse modo implica em abandonar de vez o terminal e usar 100% gráfico, a razão para o padrão atual é facilitar o modo texto, em gráfico não faz sentido: é só criar um .desktop apontando pro programa onde quer q esteja.
Se a evolução do Gobo for nesse sentido faz sentido pra mim.

Eu apoio, sem dúvida, mas isso esbarra em outras questões tais como a "questão X" dos desktops linux gráficos, a falta de padrão gráfico e a falta de conhecimento dos desenvolvedores que lançam programas sem padronização nenhuma.
Comentário de Operador Nabla
Há uma outra questão que o: Há uma outra questão que o modelo de organização da árvore de diretórios do GoboLinux se propõe a resolver.

Em diversas situações, e por razões ainda mais diversas, algum usuário pode querer manter diferentes versões de um mesmo pacote coexistindo no sistema. Nas distribuições que implementam a árvore FHS "fisicamente", essa torna-se uma tarefa muito difícil. No Portage, existe o conceito de multi-slotting installation, que trata parcialmente esta questão --- digo parcialmente pois o usuário não tem o poder para controlar os slots na hora da instalação e, dependendo do pacote, nem todas as versões podem ser mantidas em coexistência (por exemplo, é possível manter as versões 3.4.1 e 3.3.2 do KDE, mas não as versões 3.3.2 e 3.3.1).

No modelo do GoboLinux, a questão é abordada do seguinte modo: quando um pacote é instalado, todo o seu conteúdo não vai diretamente para o diretório da aplicação, mas para um subdiretório deste, referente à versão que está sendo instalada. No diretório da aplicação, existe o symlink Current, que aponta para o subdiretório da versão atualmente utilizada. As configurações mais simples do sistema são feitas referindo-se a Current em vez de uma versão específica do pacote --- assim, se o usuário quiser trocar a versão de uma aplicação a ser utilizada pelo sistema, basta recriar o symlink Current no diretório da aplicação (há uma ferramenta para automatizar esta tarefa).

Com relação ao gerenciamento de symlinks do sitema (e ao "lixo" que pode se acumular quando muitos pacotes são desinstalados), se não estou enganado, o GoboLinux inclui uma pequena ferramenta que varre o sistema, removendo todos os symlinks quebrados. Um possível procedimento de desinstalação (que o assistente de instalação deveria prover), seria remover o subdiretório daquela versão, juntamente com os symlinks quebrados.

O GoboLinux não é a única distribuição a implementar diretórios da árvore FHS por meio de symlinks. Quem tem o X.Org 6.8.2 instalado no Gentoo já deve ter notado que o diretório /usr/X11R6 não existe mais: toda a instalação do X.Org é feita diretamente sobre o diretório /usr e um symlink /usr/X11R6, que aponta para /usr, é criado para manter a compatibilidade com outras aplicações.

Enfim, acredito que algumas questões ainda precisam ser resolvidas no GoboLinux como um todo. Também acho que a árvore FHS, mesmo "simbólica", deveria ser implementada com um pouco mais de cuidado, seguindo mais "à risca" o documento FHS. Não obstante, seus desenvolvedores têm-se mostrado, no mínimo, competentes ao implementar idéias tão controversas e, ainda assim, manter a consistência da distribuição. E, levando em conta que o projeto GoboLinux é relativamente recente, acredito que muita coisa interessante ainda está por vir. É só uma questão de tempo...
Comentário de vmedina
Mas aí você perde em compat: Mas aí você perde em compatibilidade, não concorda?

Mas calma lá, o Gobo é uma distro. Os criadores fizeram ela conforme eles acharam melhor, e dizem isso abertamente. Os outros problemas do mundo não interessa neste escopo. Até por que não me lembro dela ser voltada para ambiente gráfico.

Na minha opnião, inovação deve ser apoiada sempre.

[]s!

Vinícius Medina
Usuário Linux 383765
É usuário de Linux? Mostre a sua cara!
BR-Linux.org
Linux® levado a sério desde 1996. Notícias, dicas e tutoriais em bom português sobre Linux e Código Aberto. "A página sobre software livre mais procurada no Brasil", segundo a Revista Isto É.
Expediente
Sobre o BR-Linux
Enviar notícia ou release
Contato, Termos de uso
FAQ, Newsletter, RSS
Banners e selos
Anunciar no BR-Linux
BR-Linux apóia
LinuxSecurity, Tempo Real
Suporte Livre, Drupal
Verdade Absoluta
Pandemonium
Efetividade, Floripa.net
sites da comunidade
Ajuda
Moderação
Flames: não responda!
Publicar seu texto
Computador para Todos
Notícias pré-2004
Tutoriais, HCL pré-2004