GoboLinux

Artigo original ↗ Discussão no Hacker News ↗

O GoboLinux reacende o interesse em simplificar radicalmente os layouts de sistemas de arquivos no estilo Unix, instalando cada programa em seu próprio diretório claramente nomeado (por exemplo, `/Programs/App/Version`) e usando links simbólicos para compatibilidade com caminhos tradicionais. Os comentaristas contrastam essa abordagem legível por humanos com o layout histórico, frequentemente confuso, do FHS e com sistemas mais complexos como Nix, Guix, Flatpak e contêineres, que priorizam reprodutibilidade ou isolamento em vez de transparência. Muitos veem o GoboLinux como um experimento elegante, porém de nicho, cujas ideias ainda poderiam inspirar modelos de empacotamento e sistemas de arquivos mais acessíveis em sistemas convencionais.

A ideia central do GoboLinux

  • Substitui o FHS tradicional do Unix por uma árvore por aplicação: por exemplo, /Programs/App/Version/…, com índices centrais como /System/Index/bin.
  • Caminhos legados (/bin, /usr/bin, /usr/sbin, etc.) são links simbólicos para esses índices, então o software tradicional continua funcionando.
  • Objetivos: organização legível por humanos, autoexplicativa; instalação/remoção de aplicativos mais fácil; menos confusão de “para onde foi esse arquivo?”.

Reações ao design do sistema de arquivos

  • Muitos consideram isso “obviamente sensato” e mais intuitivo do que o layout histórico do Unix, que alguns veem como uma acumulação de restrições de hardware legadas.
  • Outros defendem o FHS: ele tem razões coerentes (embora históricas); chamá-lo de “bagunça” ignora estabilidade e conhecimento institucional; alterá-lo arrisca uma “dívida técnica” de outro tipo.
  • Um subconjunto não gosta de aspectos estéticos: diretórios com inicial maiúscula (por exemplo, /Programs) evocam o Windows “Program Files” e parecem estranhos de digitar, embora a conclusão automática no shell sem distinção de maiúsculas/minúsculas atenuе bastante isso.

Comparação com macOS, Windows, Android

  • Vários apontam semelhanças com os bundles de apps do macOS e com Program Files do Windows, onde os aplicativos vivem em seus próprios diretórios.
  • Contraponto: macOS e Windows ainda espalham configuração/estado (por exemplo, ~/Library, registry), e a desinstalação pode ser bagunçada.
  • Android é citado como uma realização mais completa: distribuição de aplicativos em um único arquivo, diretórios fortes por aplicativo e sandboxing.

Relação com Nix, Guix, Spack, Flatpak, etc.

  • Alguns veem o Gobo como uma resposta anterior e mais simples aos problemas depois tratados por Nix/Guix/Spack e contêineres.
  • Nix/Guix: usam caminhos de armazenamento baseados em hash para reprodutibilidade estrita; são mais poderosos tecnicamente, mas muito menos legíveis por humanos, o que alguns argumentam ser uma grande barreira à adoção.
  • Spack é destacado como um meio-termo: caminhos nome–versão–hash mais “views” configuráveis que podem parecer uma árvore mais semântica.
  • Flatpak/Snap: focam em distribuição e sandboxing; sua complexidade e duplicação diferem do foco do Gobo na clareza do sistema de arquivos.

Usabilidade, facilidade de aprendizado e preocupações com multiusuário

  • Defensores argumentam que o Gobo reduz a carga cognitiva e torna mais fácil para não especialistas entenderem onde o software vive.
  • Críticos se preocupam com implicações para multiusuário/servidor e com a perda de convenções familiares, embora o Gobo mantenha isolamento por diretórios versionados e evite misturar pacotes.
  • Alguns querem layouts no estilo Gobo disponíveis por cima de distros existentes; o Gobo oferece um modo “rootless” no diretório pessoal do usuário.

Maturidade e adoção

  • O projeto tem cerca de 20 anos, com um ecossistema modesto e de evolução lenta; receitas/pacotes podem ficar atrás das distros mainstream.
  • Vários expressam nostalgia e admiração por ele persistir, mas reconhecem que usam Debian/Ubuntu/etc. por padrão, pela amplitude e conveniência do empacotamento.