Journal Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
42
28
sept.
2014
Ce journal a été promu en dépêche : Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement.

0Linux est pour rappel une distribution indépendante (basée sur rien d'autre qu'elle-même) sous licence CeCiLL. Créée en 2010, elle s'adresse à un public francophone. Elle et a une vocation généraliste et est proche de Slackware (absence de PAM, pulseaudio ou systemd, scripts d'init à la BSD).

D'anciens journaux sur Linuxfr.org :

Cela fait maintenant 4 ans que je développe et maintiens 0Linux, une distribution GNU/Linux complète. Un projet à la charge de travail ahurissant que j'ai entrepris seul mais qui m'a ô combien appris sur les plus infimes rouages de ce super OS. Alors, où en est-on, domine-t-on le monde ? A-t-on derrière nous une armée de développeurs qui empaquètent à tout va, un forum qui déborde de discussions passionnés, des blogs de fans qui postent des captures de leur bureau et des e-mails de sponsors qui se bousculent dans notre file d'attente de courriel ? Que nenni.
Suis-je, a contrario, toujours là à coder seul devant mon écran poussiéreux, à maintenir un logiciel dont tout le monde se fout éperdument ? Non plus.

Pour reprendre le journal de 2011 :

Pour info, la liste de diffusion compte 5 membres, il n'y a pas de forum, juste un wiki (5 membres aussi), 0 est dans la liste d'attente de Distrowatch (tout en bas) et le canal IRC dépasse rarement les 5 personnes.

Elle n'a pas attiré les foules ni défrayé la chronique avec des fonctionnalités inédites ; elle a une documentation plutôt maigre et une base d'utilisateurs anecdotique mais elle a néanmoins bien grandi :

  • plus de 1400 paquets
  • 4 personnes contribuent régulièrement au projet (en code ou en hébergement/ressources)
  • une « infrastructure » qui compile automatiquement les paquets modifiés sur des serveurs dédiés, ce qui a permis de compiler sur 2 architectures depuis une seule arborescence de sources: x86_64 multilib et i686
  • un site dédié
  • bien plus de membres et de visiteurs
  • un forum
  • un gestionnaire de paquets fiable (toujours Spack) et un outil de mise à jour et d'installation, 0g, qui gère maintenant les dépendances
  • un bureau KDE ultra-complet
  • un catalogue en ligne des paquets (en cours de construction)
  • 0Linux vient tout juste d'être intégrée à Distrowatch

0Linux est aujourd'hui une distro Linux sans prétention mais assez complète, intégrant pas mal de bureaux et d'environnements graphiques (flux/openbox, Enlightenment, KDE, MATE, Xfce, GNOME est en cours), des serveurs, des jeux, des applis pour le mutimédia, etc. et a même ses propres fonds d'écran contribués. Les outils spécifiques à la distro sont tous en shell, y compris la gestion des paquets et des mises à jour ainsi que l'installateur.

Elle a eu sa période systemd puis est revenue aux scripts à la BSD pour de multiples raisons qui ne sont pas le sujet de ce journal, a eu un bug tracker pour faire du suivi de tâches qui a finalement été supprimé mais qui a tout de même servi.

Après tout ce temps (et cette énergie), je suis plutôt satisfait du résultat : 0Linux est une distribution agréable que j'utilise quotidiennement, y compris pour bosser ou faire tourner des serveurs et elle attire sporadiquement des curieux qui reviennent (parfois) ou qui ne font que passer (souvent). Un hébergeur veut même la proposer dans les systèmes installables sur leurs serveurs dédiés.

Alors, qu'est-ce qui est le plus difficile dans la maintenance d'une distrib' ?

Être à jour peut être un vrai calvaire. Outre la difficulté à avoir un canal stable, régulier et léger d'informations sur les sorties (comprendre : pas noyé dans le torrent de messages d'une mailing list de développement ou bien sur un site qui ne change pas d'URL tous les mois), certains softs peuvent sortir plusieurs releases par semaine (voire par jour !), et de plus en plus cassent allègrement l'API/l'ABI (ou les deux) sans changer de manière adéquate leur numéro de version, quand ils ne réclament pas des libs sorties il y a 10 minutes pour compiler des softs qui n'ont pas bougé (oui GNOME, c'est de toi que je parle).

La visibilité du projet : il faut communiquer souvent, y compris sur les réseaux sociaux qu'on ne porte pas dans son coeur, et prier pour être intégré dans les sites populaires qui ont autorité de facto et qui peuvent vous ignorer pendant des années (là c'est de toi Distrowatch, que je parle).

La sécurité : il faut veiller à ce que ses paquets ne soient pas troués et consulter régulièrement les différentes ressources sur la sécurité.

Bref, tout ça mis bout à bout avec les autres tâches régulières, écrire des recettes, poster des articles, coder pour automatiser au maximum, tester, tester, tester, ça fait un sacré boulot.

Ce que je regrette :

  • la documentation, elle est bien trop maigre mais j'ai si peu de retours que je ne sais même pas si elle est consultée.
  • la dynamique du projet : je m'attendais, peut-être naïvement, à voir des enthousiastes arriver par wagons et me proposer de contribuer ou bien d'avoir des propositions de fusion avec d'autres projets : niet. Idem à propos de la constitution d'une communauté autour du projet, ça reste sporadique (mais on gagne en qualité ce qu'on rate en quantité et c'est finalement pas plus mal ainsi). Inutile de vouloir susciter un intérêt significatif du public, ça reste une simple distribution parmi tant d'autres.

Comment je vois le futur : un port ARM me plairait baucoup (j'ai déjà une toolchain) ainsi qu'un « Live » avec installateur graphique. J'aimerais également avoir une interface web pour administrer les serveurs de construction, consulter les logs, gérer les files d'attente de compilation, etc.

Cette activité m'a appris énormément mais m'a aussi montré les limites du shell et de Bash. Je pense donc me tourner vers Python3 à l'avenir, ce que j'en ai vu jusque là m'a beaucoup plus.

J'oublie certainement beaucoup d'autres aspects, mais c'est la raison pour laquelle ce post n'est qu'un journal. Je développerai en commentaire ou dans un autre journal ce que j'ai pu avoir oublié.

Quelques liens pour finir :

  • # Dibab?

    Posté par  . Évalué à 3.

    Est-ce que Dibab pourrait être utile ?

    • [^] # Re: Dibab?

      Posté par  . Évalué à 1.

      Effectivement, on pourrait trouver des synergies.

      Ok pour ARM, mais quel(s) machine(s) tu comptes supporter ?

      • [^] # Re: Dibab?

        Posté par  (site web personnel) . Évalué à 1.

        Mes CFLAGS pour ARM sont les suivants : FLAGS="-O2 -march=armv7-a -mfpu=vfpv3-d16 -pipe". J'ai néanmoins des RaspBerry Pi (rev. B) à disposition qui à priori me feraient tester d'abord sur cette machine.

        Le code n'est néanmoins pas tout à fait prêt pour ARM (il me manque uniquement le "-gnueabi" dans la triplette cible et aucun patch/code spécifique n'a été écrit pour le moment, notamment concernant l'amorçage).

        Je ne sais pas dans quelle mesure Dibab pourrait se « synergiser » avec 0Linux, tu as des idées ?

        Il faut savoir que 0Linux a quelques spécificités (rien n'est figé néanmoins) :

        • pas de systemd
        • pas de pulseaudio (présent néanmoins, mais uniquement pour disposer des libs pour contenter Steam)
        • pas de PAM
        • LDFLAGS="-L/usr/lib${LIBDIRSUFFIX} -Wl,-O1,--as-needed,--sort-common"
        • mécanisme multilib 32 bits pour x86_64 (/usr/lib pour le 32 bits, /usr/lib64 pour le 64,), le reste est « pur » et standard, libs dans /usr/lib
        • Présence des répertoires /usr/man et /usr/info (/usr/share/{info,man} sont des liens symboliques)
        • modules noyaux, pages de manuels et pages info compressés avec xz

        • [^] # Re: Dibab?

          Posté par  . Évalué à 1.

          J'ai commencé à faire des build pour Raspberry Pi également, mais je n'ai toujours pas tranché entre la cross compilation et la compilation sur une machine virtualisée.

          • Dibab n'utilise pas systemd, pulseaudio, ni PAM
          • Je n'ai pas de LDFLAGS spécifique. peux-tu commenter les tiens ?
          • je n'utilise pas de multilib, j'ai deux versions, 32 et 64 bits.
          • je ne met pas de "man", ni "info" (le public visé n'en a, a mon avis, pas besoin)
          • mes "modules" sont en squashfs

          • [^] # Re: Dibab?

            Posté par  (site web personnel) . Évalué à 2.

            Dibab n'utilise pas systemd, pulseaudio, ni PAM

            Bieeen !

            Je n'ai pas de LDFLAGS spécifique. peux-tu commenter les tiens ?

            L'éditeur de liens est optimisé (comme celui de Gentoo), (voir man ld) ; en gros il allège le nombre de bibliothèques liées à chaque binaire et procède à une optimisation et un tri dans les symboles. Voir aussi chez Gentoo.

            Si je linke sur /usr/lib${LIBDIRSUFFIX} c'est essentiellement pour gérer le multilib sous x86_64 (où $LIBDIRSUFFIX se vide quand on passe en 32 bits pour linker sur /usr/lib. De là on compile avec CC="gcc -m32", c'est apparenté à une compilation croisée mais ça ne l'est pas vraiment, le compilateur sous x86_64 produisant aussi du 32 bits nativement.

            je ne met pas de "man", ni "info" (le public visé n'en a, a mon avis, pas besoin) mes "modules" sont en squashfs

            Je gagnerais énormément d'espace disque si je supprimais la documentation, mais c'est sciemment que chaque paquet de 0linux dispose du maximum venant de l'upstream (sûrement trop).

            Il faut surtout voir que les projets auraient à partager leurs ressources, si c'ets faisable et surtout ce qu'il auraient à y gagner.

            • [^] # Re: Dibab?

              Posté par  . Évalué à 1.

              Ce qu'il y aurait à y gagner :

              • Discussions autour des choix des versions de librairies
              • Echanges de tests avant les sorties en version "stable"

              Mais c'est vrai qu'on ne vise pas le même public, LinuxConsole/AlbatrOS/Papyrus sont des distributions pour néophytes, alors que 0Linux est plus "pédagogique"

              Est-ce que vous connaissez un endroit (forum, ml) d'échange entre des équipes de développeurs de distribs francophones ?

              • [^] # Re: Dibab?

                Posté par  (site web personnel) . Évalué à 2.

                Est-ce que vous connaissez un endroit (forum, ml) d'échange entre des équipes de développeurs de distribs francophones ?

                Non, ça n'existe pas ! :) Les échanges que j'ai eus se sont toujours passés sur IRC : #0linux sur Freenode

  • # tres interessant, continu!!!

    Posté par  (site web personnel) . Évalué à 1.

    Bonjour a toi,
    Je ne ferais pas comme certain qui passe leur temps a demander ce qu'apporte de plus tas distribution par rapport a un tel ou ce qui pourrait me faire quitter la mienne pour aller sur la tienne. Je dirais par contre, que ton projet me plais, ça a l'air d'etre solide, l'installation comme je les aime, surtout baisse pas les bras, et continue a aimer ce que tu fais!
    J'aime bien ces petites distribution pas trop connu, la tienne, frug(ma chouchoute), et slitaz que j'adore.

    amicalement

    • [^] # Re: tres interessant, continu!!!

      Posté par  . Évalué à 7. Dernière modification le 28 septembre 2014 à 17:31.

      Je ne ferais pas comme certain qui passe leur temps a demander ce qu'apporte de plus tas distribution

      Bah moi je vais le faire (désolé): Avec le recul, et la quantité de travail titanesque que tu sembles décrire, est-ce que tu ne penses que ça en valait la peine pour une communauté de plus ou moins 5 personnes?
      N'a tu jamais considéré réunir des forces avec des micro-distributions afin d'espérer obtenir un meilleur résultat? Ou de te focaliser sur un objectif autre que généraliste afin de te placer sur une niche qui pourrait sembler plus intéressante pour autrui?

      • [^] # Re: tres interessant, continu!!!

        Posté par  (site web personnel) . Évalué à 9.

        Je t'ai moinssé parce que tu sembles oublier la motivation première du Monsieur : apprendre en mode fun (et laborieux). Ce qui est admirable, c'est qu'il décide de partager le fruit de son travail : ce qui semble intéresser aussi quatre autres personnes. Pari gagné ! (partages-tu ton travail ? et combien sont près à t'aider pour ça ?)

        Il semblerait quand même que cette petite distro se donne une grande ambition (je cite le site) :

        0Linux tente d’être un système francisé autodidactique afin de favoriser l’apprentissage de l’utilisation d’un système Linux : de nombreux fichiers de configuration sont traduits en français et contiennent des commentaires sur leur utilisation …

        Rien que pour ça j'ai envie de l'installer dans une machine virtuelle pour aller fouiller tout ça. Et j'avoue qu'avoir un OS francisé me tente énormément.

        Merci, aux six gus, de le faire.

        « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

  • # Qualité ?

    Posté par  . Évalué à 5.

    Je cite :

    plus de 1400 paquets
    4 personnes contribuent régulièrement au projet (en code ou en hébergement/ressources)

    Je me demande quel niveau de qualité est atteint quand 1400 paquets sont maintenus par 4 personnes.

    • [^] # Re: Qualité ?

      Posté par  (site web personnel) . Évalué à -9. Dernière modification le 28 septembre 2014 à 17:26.

      si c'est 4 personnes qui sont a fond dans leur distributions, ça ne peut etre que de qualité!
      vaut mieux 4 petits travailleurs que 1000 grands faineants…

    • [^] # Re: Qualité ?

      Posté par  (site web personnel) . Évalué à 8.

      De quoi parles-tu exactement quand tu parles de qualité : veux-tu dire par là « les binaires sont vérifiés et ne sont pas pétés », « chaque binaire est testé en environnement de production », « chaque symbole est vérifié », « les paquets sont recompilés en continu », « la doc est présente, bien rangée et compressée aux bons endroits», « les logs de compilation sont présents », « les mises à jour de sécurité arrivent le jour même des découvertes de failles », etc. ?

      Il y a plein d'aspects à considérer quand on veut faire des paquets de qualité et c'est un concept subjectif. Archlinux fait des paquets de très bonne qualité, ça n'en empêche pas certains de péter occasionnellement lors de la publication, par exemple. Slackware, qui compte 800 à 900 paquets est à la base maintenue par une seule personne (c'est cela dit moins vrai aujourd'hui) et la qualité de ses paquets est connue et reconnue (de plus, GNOME était présent à l'époque où le dev était seul).

      Techniquement, les paquets sont vérifiés à l'empaquetage et à l'installation (liens symboliques, emplacements, santé des binaires) puis tout le système hôte est scanné pour s'assurer qu'aucun binaire n'est cassé (auquel cas le serveur ordonne la recompilation de chaque paquet concerné), les fichiers de configuration sont préservés, les permissions sur les fichiers services également, un mécanisme reposant sur Busybox permet de prévenir tout cassage sur les paquets critiques (comme glibc, bash ou coreutils) et une documentation sur la santé de chaque paquet (logs de construction, paquets en dépendances, liste des libs partagées) est intégrée à la doc de chaque paquet.

      Ce n'est certainement pas optimal et on est très loin d'une infra à la Debian où chaque paquet est inspecté et testé en profondeur mais pour une distribution d'amateur, marginale et spécifique, je trouve qu'on s'en tire pas trop mal quand on regarde derrière soi.

      • [^] # Re: Qualité ?

        Posté par  . Évalué à 1.

        Il y a plein d'aspects à considérer quand on veut faire des paquets de qualité et c'est un concept subjectif.

        Tu as donné plein de critères au-dessus qui montrent que la qualité n'est pas un concept subjectif :-) Il est à géométrie variable, ce qui est légèrement différent.

        Techniquement, les paquets sont vérifiés à l'empaquetage et à l'installation (liens symboliques, emplacements, santé des binaires) puis tout le système hôte est scanné pour s'assurer qu'aucun binaire n'est cassé (auquel cas le serveur ordonne la recompilation de chaque paquet concerné), les fichiers de configuration sont préservés, les permissions sur les fichiers services également, un mécanisme reposant sur Busybox permet de prévenir tout cassage sur les paquets critiques (comme glibc, bash ou coreutils) et une documentation sur la santé de chaque paquet (logs de construction, paquets en dépendances, liste des libs partagées) est intégrée à la doc de chaque paquet.

        Ok, donc à part les paquets critiques, c'est une vision statique de la qualité basée sur la présence des artefacts d'installation, grosso modo. Après j'imagine que vous avez tellement peu d'utilisateurs que vous recevez rarement des retours sur le fonctionnement réel des logiciels installés.

  • # Bravo

    Posté par  (site web personnel) . Évalué à 1.

    Seul quelques regrêts:
    Aucun support NLS
    aucune gestion des dépendances et comme résultat certains gros paquets peuvent se lier à des softs incongrus.
    Gestionnaire de paquet non évolutif écrit en ..script.
    Recettes pas des plus simples
    Paquets non splités
    Pour ce qui est de la collaboration ce n'est pas de ne pas avoir essayé

    • [^] # Re: Bravo

      Posté par  (site web personnel) . Évalué à 1.

      aucune gestion des dépendances et comme résultat certains gros paquets peuvent se lier à des softs incongrus.

      je lis :

      un gestionnaire de paquets fiable (toujours Spack) et un outil de mise à jour et d'installation, 0g, qui gère maintenant les dépendances

      Gestionnaire de paquet non évolutif écrit en ..script.

      j'ai pas essayer , je suis en train de télécharger une iso pour voir, je suis curieux de voir comment ça se passe.

      Recettes pas des plus simples

      celle la tu l'as deja faite pour une autre… je regarde un paquet simple comme tellico, et c'est a ce que je m'attendais, simple peut etre encore plus simple que arch et frug…(pour tellico),firefox par exemple me parait plus simple aussi. en tout cas j'aime bien ses recettes.

      Paquets non splités

      la oui ça peut devenir génant pour celui qui veut une partie d'un bureau mais pas tout.

      • [^] # Re: Bravo

        Posté par  (site web personnel) . Évalué à 1.

        Recettes pas des plus simples

        Oui partant du principe que ce qui peut être automatisé y a aucune raison de le spécifier.

        0g, qui gère maintenant les dépendances

        Il parle des dépendances runtime pas de compilation…

        Paquets non splités devenir génant pour celui qui veut une partie d'un bureau mais pas tout.

        Je parlais des paquets genre qt4 qui fait 250 Mb parce que la doc est founi avec. j'ose pas imaginer la taille de qt5

        Nombreux paquets firefox, libreoffice, etc ne sont pas compilés, formaté pour 0linux

  • # Généraliste ?

    Posté par  (site web personnel) . Évalué à 3.

    Je ne pense pas que le créneau "généraliste" puisse encore être pris dans les distribs.

    J'imagine que quelques choses de pointu, peut encore l'être.

    L'autre jour, je me demandais si il existait une distribution pour serveur parano. Le genre de truc généré puis passé presque entièrement en read only.

    Je pense aussi qu'il manque une distribution à la pointe, mis à jour, sécurisé, mais de "base", où il serait facile de rajouter des sources externes (genre laisser firefox se mettre à jour seul, etc…).

    "La première sécurité est la liberté"

    • [^] # Re: Généraliste ?

      Posté par  (site web personnel) . Évalué à 2.

      Je rajouterais aussi la création de guidelines pour les codeurs de logiciel. J'en ai demandé plusieurs fois, pour un de mes logiciels, sans recevoir aucun (en dehors de : utilises les outils standards).

      Peut être que tu pourrais définir une API REST spécifique pour déclarer une nouvelle version ?

      "La première sécurité est la liberté"

    • [^] # Re: Généraliste ?

      Posté par  (site web personnel) . Évalué à 2.

      Les trucs basé sur ostree, comme atomic ?

  • # Retour sur systemd

    Posté par  . Évalué à 2.

    Elle a eu sa période systemd puis est revenue aux scripts à la BSD pour de multiples raisons qui ne sont pas le sujet de ce journal

    Vendredi est dans deux jours, il est encore temps de faire un journal ou une dépêche prête à péter tous les records. Plus sérieusement, ça pourrait être très intéressant ce genre de feedback, vu que systemd semble avoir beaucoup d’attrait auprès des mainteneurs de distros de part la charge de travail qu’il semble leur enlever; qu’en est-il pour 0linux ?

    PS: http://0.tuxfamily.org/doku.php/communaute/papier_peints <--- le doku wiki semble down

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.