GoboLinux, une distribution Linux expérimentale qui utilise le système de fichiers comme base de données des paquets

 (gobolinux.org)
3 points par GN⁺ 2024-03-01 | 1 commentaires | Partager sur WhatsApp
  • Une distribution expérimentale qui modifie en profondeur les conventions de répertoires des distributions Linux classiques, afin de faire comprendre l’organisation du système autour de répertoires par programme
  • Au lieu d’une base de données de paquets séparée, elle utilise le système de fichiers lui-même comme base de données, et les programmes sont placés par version dans des chemins comme /Programs/Nano/8.3
  • La dernière version 017.01 est une mise à jour corrective publiée environ cinq ans après la précédente version ISO, et corrige plusieurs problèmes importants apparus entre-temps
  • Le fondateur Hisham Muhammad se retire après 25 ans à la tête du projet, qui est désormais repris par l’utilisateur GitHub @fyrak1s
  • Il est possible de l’exécuter directement en environnement Live ou de l’installer sur disque dur pour tester concrètement une structure de système de fichiers différente de celle des distributions habituelles

Une manière d’organiser les paquets à l’aide du système de fichiers

  • GoboLinux est une distribution Linux expérimentale qui redéfinit l’ensemble de la hiérarchie du système de fichiers
  • Son principe central est d’utiliser le système de fichiers comme base de données, sans base de données de paquets séparée
    • Chaque programme possède son propre répertoire
    • Exemples : /Programs/Nano/8.3, /Programs/GCC/14.2.0
  • Comme sa structure diffère de celle des distributions Linux classiques, il est conseillé aux nouveaux utilisateurs de lire d’abord la documentation

Version 017.01 et changement de gouvernance du projet

  • La version actuelle est 017.01
    • Il s’agit d’un environnement Live pouvant être lancé depuis une clé USB ou un DVD
    • Il peut aussi être installé sur un disque dur
    • L’ISO est disponible sur Downloads
  • v017.01 est une mise à jour corrective publiée après environ cinq ans d’interruption
    • Elle traite plusieurs problèmes importants apparus depuis la précédente version ISO
    • Les changements détaillés sont consultables dans les release notes
  • La gestion du projet a également changé
    • Le fondateur et dirigeant de GoboLinux pendant 25 ans, Hisham Muhammad, s’est officiellement retiré
    • Le projet se poursuit désormais sous la direction de @fyrak1s
    • Lucas Correia Villa Real, alias paranoidd, a maintenu GoboLinux avec Hisham jusqu’en juin 2021
  • Les points de rencontre de la communauté se répartissent entre chat, forum et wiki

À lire aussi

1 commentaires

 
GN⁺ 2024-03-01
Avis sur Hacker News

  • Si la conception de GoboLinux vous provoque une forte réaction de rejet immédiate, le document « I am not clueless »¹, vieux de 20 ans, contient pas mal de contexte et de logique
    Mon rejet n’a pas encore complètement disparu, mais il est moins fort qu’avant ;)
    ¹ https://gobolinux.org/doc/articles/clueless.html

    • Le ton de l’article ressemble à celui des docs de HTMX ou Tailwind
      Ça se résume à peu près à : « Nous savons que nous sommes différents. C’est très simple. Ce n’est peut-être pas familier, mais c’est facile à comprendre et à manipuler. Vous n’êtes pas obligés de l’utiliser. Nous, ça nous plaît et ça nous convient »
    • Dans la partie make all programs relocatable de l’article lié, il est dit qu’il faut réécrire toutes les applis en utilisant libprefix, et je me demande ce que signifie libprefix ici
      Une recherche web ne donne rien d’exploitable
    • Je me demande si une bonne partie de la réaction de rejet réflexe ne vient pas de la conception apparente plutôt que des aspects fonctionnels
      Par exemple, une bonne partie de la première réaction vient de l’usage des majuscules : Programs avec un P majuscule rappelle Program Files de Windows, ce qui provoque un rejet émotionnel
      Devoir taper LibX11 au lieu de libx11 serait aussi un peu agaçant
      Le système de fichiers de Linux est généralement sensible à la casse, mais les noms de paquets éviteraient probablement les doublons qui ne diffèrent que par la casse, et une distribution visant une hiérarchie conviviale a peu de chances de placer à la racine des répertoires qui ne diffèrent que par la casse
      Malgré tout, si les exemples avaient été /packages/libx11/1.6.9, /packages/gcc/9.2.0, je pense que la réaction initiale aurait été beaucoup moins forte, et les avantages n’auraient absolument pas diminué avec ce genre de noms

  • C’est vraiment dommage que l’idée de GoboLinux ne se soit pas imposée dans la communauté Linux dominante
    La structure du système de fichiers de Linux est un bazar complet

    • Je suis d’accord, mais c’est encourageant de voir Nix, Guix et Spack, sur lequel je travaille le plus, suivre globalement la même direction et gagner peu à peu en puissance
      Le faire fonctionner correctement n’est jamais trivial, et le rendre efficace est encore plus difficile
      Ce n’est que ces dernières années que j’ai eu l’impression que, pour la distribution de la plupart des logiciels, ce modèle s’approchait réellement d’un niveau maintenable
    • Nix gagne de plus en plus en popularité
      Le modèle de GoboLinux impose de gérer manuellement des répertoires de version comme /Programs/Xorg/7.0, tandis que Nix élimine ce problème en déterminant le chemin d’installation d’un paquet à partir du hash de sa recette de build
    • À mon avis, les seules choses qui ont encore un sens de manière cohérente aujourd’hui sont à peu près /home et /tmp
      Le reste ressemble surtout à un fourre-tout où l’on met ce qu’on veut n’importe où
    • Ces idées m’ont clairement inspiré
      GoboLinux a été le premier projet à me montrer que, sous Linux, on pouvait vraiment faire ce qu’on voulait
    • /opt et /srv, ainsi que /usr/local/opt selon les préférences, offrent pas mal des avantages de GoboLinux pour gérer les composants un par un
      Du point de vue d’une distribution, tout a une certaine logique
      Si vous tapez dpkg -S this-file, vous comprenez vite pourquoi un fichier dans /usr est là, et la distribution joue le rôle de donner une vue d’ensemble
      Je suis curieux de savoir quelle partie vous trouvez la plus chaotique

  • Il est intéressant de voir que les chemins traditionnels sont mappés vers leurs équivalents GoboLinux afin de préserver de façon transparente la compatibilité avec l’héritage Unix
    Il n’y a pas de magie particulière : /bin est un lien vers /System/Index/bin, et /usr/bin comme /usr/sbin font de même, tous les répertoires de « binaires » pointant vers le même endroit
    Ainsi, le fichier fonctionne quel que soit le chemin standard utilisé pour y accéder, ce qui peut même être plus compatible qu’une distribution classique où le fichier réel se trouve dans /usr/local/bin/foo mais où un script référence /usr/bin/foo et casse

  • Question naïve : est-ce que macOS fonctionne plus ou moins de cette manière ?
    J’ai vraiment aimé le fait qu’une application ressemble toujours à un unique « fichier » qu’on gère par glisser-déposer
    Quand j’essaie de comprendre où se trouve quelque chose et où c’est installé dans Ubuntu, j’ai l’impression d’être idiot

    • Le problème qui consiste à avoir du mal à savoir où se trouvent les choses dans Ubuntu et où elles vont est aggravé par le fait que les gestionnaires de fichiers Linux essaient de masquer les parties du système de fichiers qui ne sont ni le dossier personnel ni des disques montés
      Je comprends pourquoi
      La structure de répertoires d’une installation Linux moyenne est un labyrinthe déroutant même pour des personnes techniques, et encore plus pour les utilisateurs ordinaires visés par les grandes distributions
      Mais au final, c’est traiter le symptôme plutôt que la cause, et je pense que davantage de distributions Linux devraient réfléchir sérieusement à moderniser la structure du système de fichiers, comme Gobo
      J’ai même envie d’essayer moi-même
      L’objectif serait de créer une structure raisonnablement auto-explicative, qui éloigne les débutants des zones dangereuses, et qui permette au gestionnaire de fichiers de ne presque rien cacher sans que ce soit un problème
    • Les bundles de macOS étaient une bonne idée et le restent, mais les apps continuent généralement à éparpiller des choses à des emplacements bizarres comme ~/Library
      Ça devient amusant dans des cas comme le launcher Minecraft, où tout, y compris les mondes et les fichiers de sauvegarde, se trouve à l’intérieur du bundle
    • Sur le principe, je suis d’accord avec l’idée qu’une application ressemble à un seul « fichier », mais en pratique beaucoup d’apps mettent plusieurs fichiers dans ~/Library et /Library
      Même sur macOS, il n’est pas rare de devoir suivre des instructions de suppression manuelle en plusieurs étapes pour désinstaller certaines apps
      C’est particulièrement important pour les apps qui ajoutent des éléments de connexion
      L’ajout/suppression de programmes de Windows fournit au moins un point central pour lancer la désinstallation, et la plupart des apps respectent correctement ce mécanisme
    • Sur Fedora, interroger la base de données rpm est simple
      On ne peut pas faire la même chose avec dpkg ?
    • C’est précisément ce que je déteste sur Mac

  • Le fait que le premier nom de répertoire commence par une majuscule ne me plaît pas trop
    Quand on navigue dans les chemins, ça donne l’impression d’une étape supplémentaire, et devoir appuyer sur Shift à chaque fois en même temps qu’une lettre ou un chiffre devient assez pénible dans l’usage quotidien de la ligne de commande

    • D’après l’article lié plus haut, dans un shell correctement configuré, comme le shell par défaut de GoboLinux, saisir /Programs demande exactement le même nombre de frappes que /usr
      Il suffit de taper slash, p minuscule, Tab
    • Si ça ne gêne pas du tout quand on navigue dans PowerShell ou cmd.exe, c’est parce que le shell aide
      Il ne vous force pas à sacrifier l’ergonomie pour économiser les précieux ticks et la mémoire du PDP-11
      Je trouve toujours amusant que les fans du « la sensibilité à la casse, c’est génial ! » passent à côté du fait que ce n’était qu’une conséquence des contraintes du système d’origine
      Ce n’est pas une fonctionnalité
      Et en plus, ce point est explicitement traité
      Rien qu’avec set completion-ignore-case On, la vie devient nettement meilleure
      Parce que, même sans utiliser GoboLinux, cela évite d’appuyer une fois sur Shift pour chaque nom de fichier commençant par une majuscule
      Ou alors vous pouvez continuer à vivre comme en 1977
      Votre VT100, vos règles
      J’ai ensuite vu quelqu’un demander « pourquoi installer un autre shell au lieu d’utiliser bash tel quel pour la navigation normale », ce qui revient à dire qu’il ne connaît même pas correctement son propre shell
    • Comme convention permettant de distinguer d’un coup d’œil un répertoire d’un fichier ordinaire, j’aime bien
      Et n’importe quel shell peut fournir une autocomplétion insensible à la casse ; Fish le fait par défaut
    • Les majuscules servent à éviter les collisions avec le FSH / les répertoires hérités
    • Je n’aime pas
      Ça fait Windows

  • Ce projet a le potentiel de réduire assez fortement notre charge cognitive
    J’espère qu’il réussira
    Modification : je vois maintenant que le projet a 20 ans

  • C’est tellement rationnel que ça en ferait presque pleurer
    S’il faut vraiment dédupliquer plusieurs copies de bibliothèques, c’est au système de fichiers de s’en charger
    Au final, il s’agit de doublons au niveau des fichiers, donc c’est à ce niveau-là qu’il faut résoudre le problème

  • Les très mauvaises applications propriétaires attendent beaucoup trop du système de l’utilisateur
    Le client Steam en est un exemple : il fournit des scripts bash au lieu de scripts sh, présuppose fortement une disposition des fichiers à la Debian/Ubuntu à cause des exigences de conteneur en espace utilisateur pour les montages Linux, et exige même des options particulières propres à GNU pour plusieurs commandes
    Il y a aussi beaucoup de bibliothèques 32 bits
    Cela dit, ils semblent encore garder le contrôle de l’ABI, et utilisent probablement la directive .symver de binutils gas
    Au moins, le désordre actuel, c’est Steam qui nous le force dans la gorge, et il est difficile de l’éviter pour une distribution qui ne fait pas l’impasse sur les jeux

    • La plupart des gens ne jouent pas, et même parmi les utilisateurs de Linux, beaucoup n’utiliseront probablement pas d’applications propriétaires au départ
      Même dans le groupe des joueurs, une proportion importante a sans doute un PC dédié au jeu

  • J’aimerais que quelqu’un de bien plus intelligent que moi explique pourquoi c’est mieux que snap/Flatpak ou que des distributions comme NixOS, ou même si ça l’est vraiment
    Sans comprendre le sujet en profondeur, vu de l’extérieur, cette approche me paraît la plus simple
    Bien sûr, je dis cela en partant du principe que mes connaissances sont limitées

    • Si l’on parle seulement de mettre chaque application dans son propre dossier, cela ne suffit pas pour l’isolation, et selon jusqu’où on pousse l’idée, cela peut devenir extrêmement gaspilleur
      Il y a de bonnes raisons pour lesquelles Flatpak et NixOS sont plus complexes
      Par exemple, ils ne stockent pas en double sur le disque exactement la même version d’une dépendance
    • snap et Flatpak sont davantage centrés sur la distribution et sont « sandboxés »
      Je mets des guillemets à cause des problèmes de sécurité
      NixOS casse la compatibilité avec les programmes existants, alors que Gobo ne le fait pas
      En revanche, le dépôt de paquets de NixOS est incomparablement mieux maintenu que celui de Gobo, qui est incomplet et accuse des années de retard
      Malgré tout, tout ce qui est mentionné ici reste en retrait par rapport à la façon dont Android stocke les applications
      Sur Android, chaque application peut être distribuée sous la forme d’un fichier unique facile à diffuser, elle est correctement sandboxée et possède son propre répertoire
      Autre point que les autres approches oublient : chaque application dispose, sous son répertoire d’application, de sous-répertoires où stocker son état, séparés aussi par utilisateur

  • Les développeurs de GoboLinux ont vraiment rendu l’organisation du système de fichiers compréhensible par les humains, de manière « intelligente »
    À mon avis, les vieilles conventions UNIX que nous utilisons encore deviennent assez obscures à une époque où l’on n’a plus de contraintes comme la limite des noms en 8.3, le manque d’espace de stockage ou les problèmes avec les fichiers de plus de 1 Go
    J’ai fait tourner GoboLinux 012 à 015 pendant quelques années sur un serveur qui hébergeait autrefois des logiciels de gestion de versions, et dans l’ensemble c’était très bien
    Le point de friction, c’était que lorsqu’un paquet nécessaire n’existait pas, il fallait créer une recette
    Le langage d’écriture des recettes de GoboLinux lui-même était facile à comprendre, mais un paquet dépend souvent d’une dizaine, voire de plusieurs dizaines de bibliothèques ; j’ai donc passé beaucoup de temps à les retrouver, faire correspondre les versions, trouver les URL des bibliothèques et des paquets, puis recréer les recettes
    J’ai fini par passer à Debian, mais je sursaute encore en voyant que les fichiers de configuration sont dans /etc et que les binaires se retrouvent dans /usr/bin ou /usr/local/bin
    Je fais partie de ceux qui trouvent systemd pénible et tentaculaire
    Il est courant d’utiliser find pour chercher le fichier .service concerné, on ne peut pas se fier à l’idée qu’il soit à un seul endroit, et la ligne de commande n’est pas intuitive
    À l’inverse, sous Gobo, l’ensemble de scripts pour gérer les services était très simple et facile à manipuler
    Malgré tout, la commodité de pouvoir installer immédiatement ce dont on a besoin avec apt get ou dpkg -i l’emporte sur la conception intelligente et bien plus rationnelle de GoboLinux
    Aujourd’hui, le nombre de distributions Linux prises en charge s’est réduit par rapport aux innombrables choix d’autrefois : Debian ou Ubuntu sont presque toujours inclus par défaut, donc même hors dépôt, il est peu probable qu’on ne puisse pas installer un paquet ou un programme
    macOS utilise aussi clairement, dans une certaine mesure, une approche similaire à GoboLinux, et c’est pourquoi, avant les versions récentes assez hostiles aux utilisateurs, macOS était plutôt facile à manipuler en ligne de commande
    Par exemple, les clés USB se trouvent dans /Volumes, et les fichiers de configuration des applications sous ~/Library

    • À noter que si un service est chargé, il suffit d’exécuter systemctl status foo pour que, dès la deuxième ligne, il indique précisément quels fichiers sont impliqués
      Par exemple, la sortie de systemctl status getty@tty1.service contient quelque chose comme Loaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled), ce qui permet d’identifier directement /lib/systemd/system/getty@.service