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 Filesde 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.