GoboLinux, uma distribuição Linux experimental que usa o sistema de arquivos como banco de dados de pacotes

 (gobolinux.org)
3 pontos por GN⁺ 2024-03-01 | 1 comentários | Compartilhar no WhatsApp
  • É uma distribuição experimental que altera bastante as convenções de diretórios das distribuições Linux tradicionais, fazendo a configuração do sistema ser entendida em torno de diretórios por programa
  • Em vez de um banco de dados de pacotes separado, usa o próprio sistema de arquivos como banco de dados, e os programas são organizados por versão em caminhos como /Programs/Nano/8.3
  • A versão mais recente, 017.01, é uma atualização de correção de bugs lançada cerca de 5 anos após o ISO anterior, abordando alguns problemas importantes desse período
  • O fundador Hisham Muhammad deixou a operação após 25 anos à frente, e o projeto passou a ser mantido pelo usuário do GitHub @fyrak1s
  • É possível executá-lo diretamente como ambiente Live ou instalá-lo no disco rígido para testar na prática uma estrutura de sistema de arquivos diferente das distribuições comuns

Como os pacotes são organizados pelo sistema de arquivos

  • GoboLinux é uma distribuição Linux experimental que redefine toda a hierarquia do sistema de arquivos
  • A ideia central é não manter um banco de dados de pacotes separado, mas usar o sistema de arquivos como banco de dados
    • Cada programa fica em seu próprio diretório
    • Exemplos: /Programs/Nano/8.3 e /Programs/GCC/14.2.0
  • Como a estrutura é diferente da de distribuições Linux convencionais, é recomendável que novos usuários leiam primeiro a documentação

Lançamento 017.01 e transição na manutenção

  • A versão atual é a 017.01
    • É um ambiente Live executável a partir de drives USB e DVDs
    • Também pode ser instalado em um disco rígido
    • O ISO pode ser baixado em Downloads
  • A v017.01 é uma atualização de correção de bugs lançada após um intervalo de cerca de 5 anos
    • Trata de alguns problemas importantes surgidos desde o lançamento anterior do ISO
    • As mudanças detalhadas podem ser conferidas nas release notes
  • A manutenção do projeto também mudou
    • O fundador e líder do GoboLinux por 25 anos, Hisham Muhammad, se retirou oficialmente
    • O projeto continua sob a gestão de @fyrak1s
    • Lucas Correia Villa Real, também conhecido como paranoidd, manteve o GoboLinux junto com Hisham até junho de 2021
  • Os pontos de encontro da comunidade se dividem entre chat, fórum e wiki

Leituras relacionadas

1 comentários

 
GN⁺ 2024-03-01
Opiniões no Hacker News

  • Se você é alguém que sente uma rejeição imediata forte ao design do GoboLinux, o documento de 20 anos “I am not clueless”¹ traz bastante contexto e lógica por trás disso
    Ainda não é que a rejeição tenha sumido completamente, mas ela já não é tão forte quanto antes ;)
    ¹ https://gobolinux.org/doc/articles/clueless.html

    • O texto tem uma sensação parecida com a documentação do HTMX ou do Tailwind
      Dá para resumir mais ou menos como: “Sabemos que somos diferentes. É muito simples. Pode não ser familiar, mas é fácil de entender e lidar. Você não precisa usar. Nós gostamos disso e estamos satisfeitos”
    • Na parte make all programs relocatable do texto linkado, ele diz que seria preciso reescrever todos os apps usando libprefix; fico curioso sobre o que libprefix significa aqui
      Pesquisando na web, não aparece nenhum resultado útil
    • Fico me perguntando se boa parte da rejeição reflexiva não vem mais do design aparente do que de aspectos funcionais
      Por exemplo, boa parte da primeira reação vem do uso de maiúsculas: Programs, com P maiúsculo, lembra o Program Files do Windows e causa uma rejeição emocional
      Se eu tivesse que digitar LibX11 em vez de libx11, acho que isso também irritaria um pouco
      O sistema de arquivos do Linux normalmente diferencia maiúsculas de minúsculas, mas nomes de pacotes provavelmente evitariam duplicatas que diferem só por caixa, e também parece improvável que uma distribuição voltada a uma camada amigável ao usuário colocasse diretórios na raiz que diferissem apenas por maiúsculas/minúsculas
      Ainda assim, se os exemplos fossem /packages/libx11/1.6.9, /packages/gcc/9.2.0, acho que a reação inicial teria sido muito menor, e os benefícios não teriam diminuído em nada com esses nomes

  • É realmente uma pena que a ideia do GoboLinux não tenha se firmado na comunidade Linux mainstream
    A estrutura do sistema de arquivos do Linux é uma bagunça completa

    • Concordo, mas fico feliz em ver Nix, Guix e Spack, com o qual trabalho mais, ganhando cada vez mais força ao seguir basicamente a mesma direção
      Fazer isso funcionar corretamente nunca é trivial, e torná-lo eficiente é ainda mais difícil
      Só nos últimos anos sinto que esse modelo chegou perto de ser realmente sustentável para a distribuição da maior parte dos softwares
    • Nix está ficando cada vez mais popular
      No modelo do GoboLinux, você precisa gerenciar manualmente diretórios de versão como /Programs/Xorg/7.0, enquanto o Nix elimina esse problema definindo o caminho de instalação de um pacote pelo hash da receita de build
    • Acho que, hoje, o que faz sentido de forma consistente é mais ou menos /home e /tmp
      O resto está mais para um amontoado onde se coloca qualquer coisa em qualquer lugar
    • Essas ideias certamente me inspiraram
      O GoboLinux foi o primeiro projeto que me mostrou que, no Linux, dá para fazer realmente do jeito que você quiser
    • /opt e /srv, e dependendo do gosto /usr/local/opt, oferecem bastante da vantagem de gerenciar componentes individualmente como no GoboLinux
      Do ponto de vista da distribuição, tudo faz algum sentido
      Se você digita dpkg -S this-file, descobre rapidamente por que um arquivo dentro de /usr existe, e a distribuição tem o papel de desenhar o panorama completo
      Fico curioso para saber qual parte você considera a mais bagunçada

  • Acho interessante que eles mantenham de forma transparente a compatibilidade com a herança Unix mapeando os caminhos tradicionais para os caminhos correspondentes do GoboLinux
    Não há nenhuma mágica especial: /bin é um link para /System/Index/bin, e /usr/bin e /usr/sbin também, da mesma forma, com todos os diretórios de “binários” apontando para o mesmo lugar
    Graças a isso, os arquivos funcionam seja qual for o caminho padrão usado para acessá-los, então talvez seja até mais compatível do que uma distribuição comum, em que um script quebra ao referenciar /usr/bin/foo quando o arquivo real está em /usr/local/bin/foo

  • Perguntando sem saber muito: o macOS funciona mais ou menos desse jeito?
    Sempre achei ótimo o modo como os aplicativos parecem um único “arquivo” que você gerencia arrastando e soltando
    Quando tento descobrir onde algo está e onde é instalado no Ubuntu, sinto que virei um idiota

    • O problema de ser difícil descobrir onde as coisas estão e para onde vão no Ubuntu fica pior porque os gerenciadores de arquivos do Linux tentam esconder partes do sistema de arquivos que não sejam a pasta home ou unidades montadas
      Entendo por que fazem isso
      A estrutura de diretórios de uma instalação Linux comum é um labirinto confuso até para pessoas técnicas, e é ainda pior para os usuários comuns que as grandes distribuições miram
      Mas, no fim, é uma forma de tratar o sintoma, não a causa, e acho que mais distribuições Linux deveriam considerar seriamente modernizar a estrutura do sistema de arquivos, como o Gobo
      Tenho até vontade de tentar fazer isso eu mesmo
      O objetivo seria criar uma estrutura razoavelmente autoexplicativa, que conduza iniciantes para longe de áreas perigosas e em que o gerenciador de arquivos quase não precise esconder nada
    • Os bundles do macOS foram uma boa ideia, e ainda são, mas os apps normalmente ainda espalham coisas por lugares esquisitos como ~/Library
      Fica interessante quando, como no launcher do Minecraft, tudo fica dentro do bundle, incluindo mundos e arquivos salvos
    • Em princípio, concordo que é bom os aplicativos parecerem um único “arquivo”, mas, na prática, muitos apps colocam vários arquivos em ~/Library e /Library
      Mesmo no macOS, não é raro ter que seguir instruções de remoção manual em várias etapas para apagar alguns apps
      Isso é especialmente importante quando o app adiciona itens de login
      O Adicionar/Remover Programas do Windows ao menos oferece um ponto central para executar a desinstalação, e a maioria dos apps segue esse método corretamente
    • No Fedora, consultar o banco de dados rpm é simples
      Não dá para fazer a mesma coisa com dpkg?
    • É exatamente isso que eu detesto no Mac

  • Não gosto muito de o primeiro nome de diretório começar com letra maiúscula
    Ao navegar por caminhos, isso parece trabalho extra, e ter que apertar Shift junto com uma letra ou número toda vez é bem chato no uso cotidiano da linha de comando

    • Segundo o texto linkado acima, em um shell devidamente configurado, como o shell padrão do GoboLinux, digitar /Programs exige exatamente a mesma quantidade de teclas que /usr
      Basta barra, p minúsculo e Tab
    • Ao navegar no PowerShell ou no cmd.exe, por que isso não incomoda nem um pouco? Porque o shell ajuda
      Ele não força você a sacrificar usabilidade para economizar os preciosos ticks e a memória do PDP-11
      Sempre acho engraçado quando fãs de “diferenciação entre maiúsculas e minúsculas é o máximo!” não percebem que isso foi só resultado das limitações do sistema original
      Não é um recurso
      Além disso, essa parte é tratada explicitamente
      Só set completion-ignore-case On já melhora muito a vida
      Porque, mesmo que você não use GoboLinux, deixa de apertar Shift uma vez para cada nome de arquivo que começa com maiúscula
      Ou você pode continuar vivendo como em 1977
      Seu VT100, suas regras
      Depois vi alguém dizendo “por que não usar simplesmente o bash para navegação comum em vez de instalar outro shell”, o que mostra que a pessoa nem conhece direito o próprio shell
    • Gosto como convenção para distinguir de relance se é um diretório ou um arquivo comum
      Além disso, qualquer shell pode oferecer autocompletar sem diferenciar maiúsculas de minúsculas, e o Fish faz isso por padrão
    • As maiúsculas têm o objetivo de evitar conflito com diretórios FSH/legados
    • Não gosto
      Tem cara de Windows

  • Este projeto tem potencial para reduzir bastante a nossa carga cognitiva
    Espero que dê certo
    Correção: agora vi que é um projeto de 20 anos

  • É tão racional que dá vontade de chorar
    Se a desduplicação de várias cópias de bibliotecas for realmente necessária, o sistema de arquivos que cuide disso
    No fim das contas, é duplicação em nível de arquivo, então deve ser resolvida nesse nível

  • Aplicativos de código fechado muito ruins esperam demais do sistema do usuário
    O cliente Steam é um exemplo: ele fornece scripts em bash, não em sh; pressupõe fortemente uma disposição de arquivos ao estilo Debian/Ubuntu por causa dos requisitos de contêiner em espaço de usuário para montagem no Linux; e ainda exige opções peculiares, exclusivas do GNU, em vários comandos
    Também há muitas bibliotecas de 32 bits
    Ainda assim, parece que a ABI continua sob controle, e provavelmente usam a diretiva .symver do gas do binutils
    Pelo menos a bagunça atual está sendo enfiada goela abaixo por meio do Steam, e é difícil escapar dela em qualquer distribuição que não seja uma distro sem jogos

    • A maioria das pessoas não joga, e, mesmo entre usuários de Linux, muita gente provavelmente nem usa apps proprietários
      Mesmo dentro do grupo de gamers, é bem possível que uma parcela considerável tenha um PC dedicado só para jogos

  • Gostaria que alguém muito mais inteligente do que eu explicasse por que isso é melhor, ou se é mesmo melhor, do que snap/Flatpak ou distribuições como NixOS
    Sem entender a fundo, por fora este método parece o mais simples
    Claro, digo isso partindo da minha falta de conhecimento

    • Se estamos falando apenas de colocar cada app em sua própria pasta, isso por si só não basta para isolamento e pode ser tremendamente desperdiçador, dependendo de até onde se leva a ideia
      Há bons motivos para Flatpak e NixOS serem mais complexos
      Por exemplo, eles não armazenam no disco cópias duplicadas da mesma versão exata de uma dependência
    • snap e Flatpak são mais focados em distribuição e são “sandboxed”
      Usei aspas porque há questões de segurança
      O NixOS quebra a compatibilidade com programas existentes, enquanto o Gobo não
      Mas o repositório de pacotes do NixOS é incomparavelmente mais bem mantido que o do Gobo, e o do Gobo é incompleto e fica anos atrasado
      Ainda assim, tudo o que foi mencionado aqui fica atrás da forma como o Android armazena apps
      No Android, cada aplicativo pode ser distribuído como um único arquivo fácil de distribuir, fica devidamente isolado em sandbox e tem seu próprio diretório
      Outro ponto que as outras abordagens deixam passar: cada app tem um subdiretório sob o diretório do app para armazenar seu próprio estado, separado também por usuário

  • Os desenvolvedores do GoboLinux realmente criaram uma disposição do sistema de arquivos inteligível para humanos de forma “inteligente”
    Acho que as antigas convenções UNIX que usamos hoje são bem obscuras numa época em que não existem mais restrições como limite de nomes 8.3, falta de espaço de armazenamento ou problemas com arquivos acima de 1 GB
    Rodei o GoboLinux 012 a 015 por alguns anos em um servidor que antes hospedava software de controle de versão e, no geral, foi muito bom
    O obstáculo era que, se não houvesse o pacote necessário, era preciso criar uma receita
    A própria linguagem de escrita de receitas do GoboLinux era fácil de entender, mas um único pacote muitas vezes dependia de uma dúzia ou de dezenas de bibliotecas, então eu gastava muito tempo rastreando isso, alinhando versões, encontrando URLs de bibliotecas e pacotes e criando receitas de novo
    No fim, migrei para Debian, mas até hoje me dá um arrepio ver arquivos de configuração em /etc e binários em /usr/bin ou /usr/local/bin
    Sou do lado que vê o systemd como incômodo e com tentáculos demais
    É comum usar find para localizar o arquivo .service relacionado; não dá para confiar que ele esteja em um único lugar, e a linha de comando também não é intuitiva
    Em contraste, no Gobo o conjunto de scripts para gerenciar serviços era muito simples e fácil de lidar
    Mesmo assim, a conveniência de poder instalar logo o que é necessário com apt get ou dpkg -i vence o design inteligente e muito mais racional do GoboLinux
    Hoje em dia, o número de distribuições Linux suportadas diminuiu em relação à infinidade de opções de antes, e quase sempre Debian ou Ubuntu vêm incluídos por padrão, então é pouco provável não conseguir instalar um pacote ou programa mesmo fora dos repositórios
    O macOS também certamente usa, em alguma medida, uma abordagem parecida com a do GoboLinux, e por isso, antes das versões recentes bastante hostis ao usuário, era bem fácil lidar com o macOS pela linha de comando
    Por exemplo, unidades USB ficam em /Volumes, e arquivos de configuração de programas ficam sob ~/Library

    • A propósito, se o serviço estiver carregado, basta executar systemctl status foo para que, a partir da segunda linha, ele informe exatamente quais arquivos estão envolvidos
      Por exemplo, na saída de systemctl status getty@tty1.service aparece algo como Loaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled), então dá para saber diretamente que é /lib/systemd/system/getty@.service