GoboLinux, una distribución experimental de Linux que usa el sistema de archivos como base de datos de paquetes

 (gobolinux.org)
3 puntos por GN⁺ 2024-03-01 | 1 comentarios | Compartir por WhatsApp
  • Es una distribución experimental que cambia de forma importante las convenciones de directorios de las distribuciones Linux tradicionales, haciendo que la configuración del sistema se entienda alrededor de directorios por programa
  • En lugar de una base de datos de paquetes separada, usa el propio sistema de archivos como base de datos, y los programas se ubican por versión en rutas como /Programs/Nano/8.3
  • La versión más reciente, 017.01, es una actualización de corrección de errores que llega unos 5 años después del lanzamiento ISO anterior y aborda algunos problemas importantes surgidos durante ese tiempo
  • El fundador Hisham Muhammad se retira tras 25 años al frente, y el proyecto queda en manos del usuario de GitHub @fyrak1s
  • Se puede ejecutar directamente como entorno Live o instalar en el disco duro para probar en la práctica una estructura de sistema de archivos distinta a la de las distribuciones habituales

Una forma de organizar paquetes mediante el sistema de archivos

  • GoboLinux es una distribución experimental de Linux que redefine toda la jerarquía del sistema de archivos
  • La idea central es una estructura que no mantiene una base de datos de paquetes separada, sino que usa el sistema de archivos como base de datos
    • Cada programa va dentro de su propio directorio
    • Ejemplos: /Programs/Nano/8.3, /Programs/GCC/14.2.0
  • Como su estructura difiere de la de las distribuciones Linux habituales, a los usuarios que la prueban por primera vez les conviene leer primero la documentación

Lanzamiento 017.01 y cambio en la gestión del proyecto

  • La versión actual es 017.01
    • Es un entorno Live que puede ejecutarse desde unidades USB y DVD
    • También puede instalarse en el disco duro
    • La ISO se puede obtener en Downloads
  • v017.01 es una actualización de corrección de errores publicada tras una pausa de unos 5 años
    • Aborda algunos problemas importantes aparecidos desde el lanzamiento ISO anterior
    • Los cambios detallados pueden consultarse en las release notes
  • También cambió la gestión del proyecto
    • Hisham Muhammad, fundador y líder de GoboLinux durante 25 años, se retira oficialmente
    • El proyecto continúa bajo la gestión de @fyrak1s
    • Lucas Correia Villa Real, alias paranoidd, mantuvo GoboLinux junto con Hisham hasta junio de 2021
  • Los puntos de encuentro de la comunidad se dividen entre chat, foro y wiki

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-03-01
Comentarios en Hacker News

  • Si eres de los que sienten un fuerte rechazo instantáneo ante el diseño de GoboLinux, el documento de hace 20 años “I am not clueless”¹ contiene bastante contexto y razonamiento.
    Todavía no se me quita del todo el rechazo, pero ya no es tan fuerte como antes ;)
    ¹ https://gobolinux.org/doc/articles/clueless.html

    • El tono del texto se parece al de la documentación de HTMX o Tailwind.
      Se puede resumir más o menos así: “Sabemos que somos distintos. Es muy simple. Puede que no te resulte familiar, pero es fácil de entender y manejar. No tienes que usarlo. A nosotros nos gusta y estamos satisfechos con ello”.
    • En la parte make all programs relocatable del texto enlazado dicen que hay que reescribir todas las apps usando libprefix, y me da curiosidad qué significa exactamente libprefix aquí.
      Buscando en la web no salen resultados realmente útiles.
    • Me pregunto si gran parte de ese rechazo reflejo viene más del diseño visual que de elementos funcionales.
      Por ejemplo, buena parte de la primera reacción viene del uso de mayúsculas: Programs con P mayúscula hace pensar en Program Files de Windows, y eso provoca un rechazo emocional.
      Si tuviera que escribir LibX11 en lugar de libx11, creo que me molestaría un poco.
      Normalmente los sistemas de archivos de Linux distinguen mayúsculas y minúsculas, pero los nombres de paquetes seguramente evitarían duplicados que solo se diferencien por eso, y tampoco parece probable que una distro orientada a una jerarquía amigable para el usuario ponga directorios en la raíz que solo se distingan por mayúsculas.
      Aun así, si el ejemplo hubiera sido /packages/libx11/1.6.9, /packages/gcc/9.2.0, creo que la reacción inicial habría sido mucho menor, y con esos nombres las ventajas no se habrían reducido en absoluto.

  • De verdad es una lástima que la idea de GoboLinux no haya logrado consolidarse en la comunidad Linux dominante.
    La estructura del sistema de archivos de Linux es un completo desastre.

    • Estoy de acuerdo, pero me alegra ver que Nix, Guix y Spack, con el que trabajo más que con los otros, están ganando fuerza siguiendo básicamente la misma dirección.
      Hacer que esto funcione bien nunca es algo trivial, y hacerlo eficiente es todavía más difícil.
      Siento que apenas en los últimos años este modelo se acercó a un punto realmente sostenible para la distribución de la mayoría del software.
    • Nix está ganando popularidad poco a poco.
      El modelo de GoboLinux obliga a gestionar manualmente directorios de versión como /Programs/Xorg/7.0, mientras que Nix elimina ese problema al definir la ruta de instalación del paquete con un hash de la receta de compilación.
    • Ahora mismo, lo único que me parece coherente de forma consistente es /home y /tmp.
      Todo lo demás se parece más a un cajón de sastre donde se pone cualquier cosa en cualquier lugar.
    • Esas ideas definitivamente me inspiraron.
      GoboLinux fue el primer proyecto que me mostró que en Linux realmente puedes hacer las cosas como quieras.
    • /opt y /srv, y según gustos /usr/local/opt, sí ofrecen bastante de la ventaja de gestionar los componentes uno por uno, como hace GoboLinux.
      Desde la perspectiva de una distro, todo tiene su propia lógica.
      Si ejecutas dpkg -S this-file, puedes averiguar rápido por qué existe un archivo dentro de /usr, y la distro cumple el papel de darte la visión completa.
      Me da curiosidad qué parte te parece la más desordenada.

  • Me parece interesante que mantengan de forma transparente la compatibilidad con la herencia Unix mapeando las rutas tradicionales a sus equivalentes en GoboLinux.
    No hay magia especial: /bin es un enlace a /System/Index/bin, y lo mismo pasa con /usr/bin y /usr/sbin, de modo que todos los directorios de “binarios” apuntan al mismo lugar.
    Gracias a eso, los archivos funcionan al accederse desde cualquier ruta estándar, así que en cierto sentido puede ser incluso más compatible que una distro normal, donde un script se rompe por referenciar /usr/bin/foo cuando el archivo real está en /usr/local/bin/foo.

  • Preguntando desde la ignorancia: ¿macOS funciona de algún modo parecido?
    Siempre me gustó mucho esa forma en que las aplicaciones parecen un solo “archivo” que manejas con arrastrar y soltar.
    Cuando intento averiguar dónde está algo en Ubuntu y dónde se instala, siento que me vuelvo idiota.

    • El problema de que en Ubuntu sea difícil averiguar qué está dónde y a dónde va empeora porque los administradores de archivos de Linux intentan ocultar partes del sistema de archivos que no son tu carpeta personal ni unidades montadas.
      Entiendo por qué lo hacen.
      La estructura de directorios de una instalación promedio de Linux es un laberinto confuso incluso para gente técnica, y todavía más para el usuario común al que apuntan las distros principales.
      Pero al final eso trata el síntoma y no la causa, y creo que más distribuciones Linux deberían pensar seriamente en modernizar la estructura del sistema de archivos como lo hace Gobo.
      Incluso me dan ganas de intentarlo yo mismo.
      La meta sería crear una estructura razonable y autoexplicativa, que mantenga a los principiantes lejos de las zonas peligrosas y donde el administrador de archivos no tenga que ocultar casi nada para que todo siga teniendo sentido.
    • Los bundles de macOS fueron una buena idea y lo siguen siendo, pero las apps todavía suelen regar cosas en ubicaciones raras como ~/Library.
      Se vuelve curioso con casos como el launcher de Minecraft, donde todo, incluidos los mundos y las partidas guardadas, vive dentro del bundle.
    • En principio estoy de acuerdo con que una aplicación se vea como un solo “archivo”, pero en la práctica muchas apps colocan varios archivos en ~/Library y /Library.
      Incluso en macOS no es raro que para borrar algunas apps tengas que seguir instrucciones de eliminación manual en varios pasos.
      Eso importa todavía más si es una app que añade elementos de inicio de sesión.
      Al menos Agregar o quitar programas de Windows ofrece un punto central desde el cual ejecutar la desinstalación, y la mayoría de las apps siguen bien ese modelo.
    • En Fedora es sencillo consultar la base de datos de rpm.
      ¿No se puede hacer lo mismo con dpkg?
    • Justamente eso es lo que realmente odio de Mac

  • No me convence que el primer nombre de directorio empiece con mayúscula
    Se siente como trabajo extra al recorrer rutas, y tener que presionar Shift cada vez junto con una letra o número es bastante molesto en el uso diario de la línea de comandos

    • Según el artículo enlazado arriba, en un shell bien configurado como el shell predeterminado de GoboLinux, escribir /Programs requiere exactamente la misma cantidad de teclas que /usr
      Solo hace falta barra, p minúscula y Tab
    • Al navegar en PowerShell o cmd.exe, eso no molesta en absoluto porque el shell te ayuda
      No te obliga a sacrificar usabilidad para ahorrar valiosos ciclos y memoria de una PDP-11
      Siempre da risa cuando los fans del “¡las mayúsculas y minúsculas son lo máximo!” pasan por alto que eso fue solo el resultado de restricciones del sistema original
      No es una característica
      Además, esto se aborda de forma explícita
      Con solo set completion-ignore-case On la vida mejora bastante
      Incluso si no usas GoboLinux, porque te ahorras una pulsación de Shift por cada nombre de archivo que empieza con mayúscula
      O puedes seguir viviendo como en 1977
      Tu VT100, tus reglas
      Más adelante vi un comentario de “¿por qué instalar otro shell en vez de usar bash tal cual para la navegación general?”, y eso ya es no conocer ni tu propio shell
    • Me gusta como convención para distinguir de un vistazo si es un directorio o un archivo normal
      Además, cualquier shell podría ofrecer autocompletado ignorando mayúsculas y minúsculas, y Fish lo hace por defecto
    • Las mayúsculas buscan evitar conflictos con los directorios heredados/FSH
    • No me gusta
      Da vibra de Windows

  • Este proyecto tiene potencial para reducir bastante nuestra carga cognitiva
    Ojalá tenga éxito
    Edit: ahora veo que era un proyecto de hace 20 años

  • Es tan razonable que hasta dan ganas de llorar
    Si de verdad hace falta deduplicar múltiples copias de bibliotecas, eso debería encargarse el sistema de archivos
    Al final es duplicación a nivel de archivo, así que debe resolverse en ese nivel

  • Las aplicaciones de código cerrado muy malas esperan demasiado del sistema del usuario
    El cliente de Steam es un ejemplo: entrega scripts bash en vez de scripts sh, da por sentada con fuerza una disposición de archivos tipo Debian/Ubuntu por los requisitos de contenedores de espacio de usuario montados en Linux, y hasta exige opciones raras exclusivas de GNU en varios comandos
    También hay muchas bibliotecas de 32 bits
    Aun así, parece que todavía tienen el ABI bajo control, y probablemente usan la directiva .symver de gas de binutils
    Por lo menos el caos actual nos lo está metiendo Steam por la garganta, y es difícil evitarlo salvo que tu distribución no sea para jugar

    • La mayoría de la gente no juega, y hasta entre los usuarios de Linux muchos probablemente ni usan apps privativas
      Incluso dentro del grupo gamer, es bastante probable que muchos tengan una PC aparte dedicada a juegos

  • Me gustaría que alguien mucho más inteligente que yo explicara por qué esto es mejor que distribuciones como snap/Flatpak o NixOS, o si de verdad lo es
    Sin entenderlo a fondo, por encima este enfoque me parece el más simple
    Claro, lo digo asumiendo mi falta de conocimiento

    • Si solo se trata de poner cada app en su propia carpeta, eso por sí solo no basta para el aislamiento y puede ser tremendamente desperdiciador según hasta dónde se lleve
      Flatpak y NixOS son más complejos por una razón
      Por ejemplo, no almacenan en disco copias duplicadas de exactamente la misma versión de una dependencia
    • snap y Flatpak están más enfocados en la distribución y están “sandboxeados”
      Lo pongo entre comillas por temas de seguridad
      NixOS rompe la compatibilidad con programas existentes, mientras que Gobo no
      Pero el repositorio de paquetes de NixOS está muchísimo mejor mantenido que el de Gobo, que está incompleto y atrasado por años
      Aun así, todo lo mencionado aquí va por detrás de cómo Android almacena las apps
      En Android, cada aplicación puede distribuirse como un solo archivo fácil de desplegar, está correctamente sandboxeada y tiene su propio directorio
      Y, a diferencia de los otros enfoques, cada app tiene un subdirectorio bajo su directorio de aplicación para guardar su estado, además separado por usuario

  • Los desarrolladores de GoboLinux realmente lograron crear una disposición del sistema de archivos que una persona puede entender de forma “inteligente”
    Considero que las viejas convenciones de UNIX que usamos ahora son bastante crípticas en una época en la que ya no existen limitaciones como nombres 8.3, falta de espacio de almacenamiento o problemas con archivos de más de 1 GB
    Hace tiempo ejecuté GoboLinux 012~015 durante varios años en un servidor que alojaba software de control de versiones, y en general fue muy bueno
    El obstáculo era que, si no existía el paquete que necesitabas, había que crear una receta
    El lenguaje para escribir recetas de GoboLinux en sí era fácil de entender, pero a menudo un solo paquete dependía de una docena o varias decenas de bibliotecas, así que me llevaba mucho tiempo rastrear eso, hacer coincidir versiones, encontrar las URL de bibliotecas y paquetes, y volver a crear la receta
    Al final me cambié a Debian, pero todavía me sobresalto cuando veo archivos de configuración en /etc y binarios dentro de /usr/bin o /usr/local/bin
    Estoy del lado de quienes ven a systemd como algo molesto y tentacular
    Es común tener que usar find para localizar archivos .service relacionados, no se puede confiar en que estén en un solo lugar y la línea de comandos tampoco es intuitiva
    En cambio, Gobo tenía un conjunto de scripts para administrar servicios que era muy simple y fácil de manejar
    Aun así, la conveniencia de poder instalar de inmediato lo que necesitas con apt get o dpkg -i vence al diseño mucho más racional e inteligente de GoboLinux
    Hoy en día la cantidad de distribuciones de Linux compatibles se ha reducido desde la infinidad de opciones de antes, así que casi siempre Debian o Ubuntu vienen como base y es poco probable que no puedas instalar un paquete o programa, incluso fuera de los repositorios
    macOS también usa claramente, hasta cierto punto, un enfoque parecido al de GoboLinux, y por eso antes de las versiones recientes, bastante hostiles para el usuario, era bastante fácil manejar macOS desde la línea de comandos
    Por ejemplo, las unidades USB están en /Volumes y los archivos de configuración de los programas están bajo ~/Library

    • Como referencia, si el servicio está cargado, basta con ejecutar systemctl status foo para que desde la segunda línea te diga exactamente qué archivos están involucrados
      Por ejemplo, en la salida de systemctl status getty@tty1.service aparece Loaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled), así que puedes identificar de inmediato /lib/systemd/system/getty@.service