GoboLinux

GoboLinux reaviva el interés por simplificar radicalmente los diseños de sistemas de archivos tipo Unix instalando cada programa en su propio directorio claramente nombrado (por ejemplo, `/Programs/App/Version`) y usando enlaces simbólicos para mantener la compatibilidad con rutas tradicionales. Los comentaristas contraponen este enfoque legible para humanos con la disposición histórica, a menudo confusa, de FHS, y con sistemas más complejos como Nix, Guix, Flatpak y los contenedores, que priorizan la reproducibilidad o el aislamiento sobre la transparencia. Muchos ven GoboLinux como un experimento elegante pero de nicho, cuyas ideas aún podrían inspirar modelos de empaquetado y de sistema de archivos más accesibles en los sistemas principales.

La idea central de GoboLinux

  • Sustituye el FHS tradicional de Unix por un árbol por aplicación: por ejemplo, /Programs/App/Version/…, con índices centrales como /System/Index/bin.
  • Las rutas heredadas (/bin, /usr/bin, /usr/sbin, etc.) son enlaces simbólicos a estos índices, por lo que el software tradicional sigue funcionando.
  • Objetivos: una disposición legible para humanos, autoexplicativa; instalación y eliminación de aplicaciones más sencillas; menos confusión de “¿dónde fue a parar este archivo?”.

Reacciones al diseño del sistema de archivos

  • Muchos lo encuentran “obviamente sensato” y más intuitivo que la disposición histórica de Unix, que algunos ven como una acumulación de restricciones heredadas del hardware.
  • Otros defienden FHS: tiene razones coherentes (aunque históricas); llamarlo un “desastre” ignora la estabilidad y el conocimiento institucional; cambiarlo arriesga una “deuda técnica” de otro tipo.
  • A un subconjunto no le gustan aspectos cosméticos: directorios con mayúscula (por ejemplo, /Programs) evocan Windows “Program Files” y resultan incómodos de escribir, aunque la autocompletación de shell insensible a mayúsculas lo mitiga en gran medida.

Comparación con macOS, Windows, Android

  • Varios señalan similitudes con los bundles de apps de macOS y con Program Files de Windows, donde las aplicaciones viven en sus propios directorios.
  • Contraargumento: macOS y Windows siguen dispersando la configuración y el estado (por ejemplo, ~/Library, el registro), y desinstalar puede ser un lío.
  • Android se cita como una realización más completa: distribución de apps en un solo archivo, directorios fuertes por aplicación y sandboxing.

Relación con Nix, Guix, Spack, Flatpak, etc.

  • Algunos ven Gobo como una respuesta anterior y más simple a problemas que después abordaron Nix/Guix/Spack y los contenedores.
  • Nix/Guix: usan rutas de almacén basadas en hashes para una reproducibilidad estricta; son más potentes técnicamente, pero mucho menos legibles para humanos, lo que algunos consideran una gran barrera para su adopción.
  • Spack se destaca como un punto intermedio: rutas nombre-versión-hash más “vistas” configurables que pueden parecerse a un árbol más semántico.
  • Flatpak/Snap: se centran en la distribución y el sandboxing; su complejidad y duplicación difieren del enfoque de Gobo en la claridad del sistema de archivos.

Usabilidad, facilidad de aprendizaje y preocupaciones multiusuario

  • Quienes lo apoyan sostienen que Gobo reduce la carga cognitiva y facilita que los no expertos entiendan dónde vive el software.
  • Los críticos se preocupan por las implicaciones en entornos multiusuario/servidor y por la pérdida de convenciones familiares, aunque Gobo mantiene el aislamiento mediante directorios versionados y evita mezclar paquetes.
  • Algunos quieren disponer de disposiciones al estilo Gobo encima de distros existentes; Gobo soporta un modo “rootless” en el directorio home de un usuario.

Madurez y adopción

  • El proyecto tiene unos 20 años, con un ecosistema modesto y de evolución lenta; las recetas/paquetes pueden ir por detrás de las distros principales.
  • Varios expresan nostalgia y admiración por su persistencia, pero reconocen que por amplitud y comodidad de empaquetado terminan usando Debian/Ubuntu/etc.