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

Posté par  (site web personnel) . Édité par Benoît Sibaud, Nils Ratusznik et palm123. Modéré par bubar🦥. Licence CC By‑SA.
Étiquettes :
27
29
sept.
2014
Distribution

appzer0 a écrit un journal pour évoquer l'état des lieux de la distribution 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).

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 empaquettent à 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.

Logo

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 distribution 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 applications pour le multimédia, etc. et a même ses propres fonds d'écran contribués. Les outils spécifiques à la distribution 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 outil 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 distribution ?

Ê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 liste de discussion de développement ou bien sur un site qui ne change pas d'URL tous les mois), certains logiciels peuvent sortir plusieurs versions 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 bibliothèques sorties il y a 10 minutes pour compiler des logiciels 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.

Capture d'écran

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 chaîne de compilation) 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 plu.

J'oublie certainement beaucoup d'autres aspects, mais c'est la raison pour laquelle ce post n'est qu'un journal (NdM: on a choisi néanmoins d'en faire une dépêche). Je développerai en commentaire ou dans un autre journal ce que j'ai pu avoir oublié.

Quelques liens pour finir :

Aller plus loin

  • # Beyond beyond Linux from scratch

    Posté par  . Évalué à 7.

    0Linux est pour rappel une distribution indépendante (basée sur rien d'autre qu'elle-même)

    Puisqu'il y a eu une dépêche sur LFS il y a peu, tu pourrais décrire les premières étapes de création d'une distribution?

    Par exemple, quelle méthode as tu suivie pour démarrer ta distribution? LFS, justement? Comment se passe le passage d'un système sans aucune gestion de paquets à celui où on peut le mettre à jour facilement?

    • [^] # Re: Beyond beyond Linux from scratch

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

      Pour reprendre le contenu de l'accueil du wiki :

      0linux a pu naître grâce aux méthodes de Linux From Scratch, Cross LFS et DIY Linux pour construire une première chaîne d'outils permettant de compiler pour les 2 architectures, x86 et x86_64. La distribution s'est dans un premier temps beaucoup inspirée de Slackware (appliquer le moins de correctifs possible, utiliser une initialisation à la BSD) pour construire le système final. Elle a sa propre chaîne d'outils depuis 2010 (le nom complet de la « machine » est -0linux-linux-gnu) et se recompile elle-même avec bonheur.

      Le passage d'un système cousu main à un système avec un gestionnaire de paquets se fait quasi naturellement, pourvu que le gestionnaire soit simple et abordable : j'avais commencé à écrire des SlackBuilds (de simples scripts) et à utiliser les pkgtools de Slackware pour reprendre ce que je faisais déjà à la main de manière automatisée. Se lancer directement dans des trucs complets qui gèrent les dépendances et les dépôts tiers comme les outils pour rpm ou deb est à mon sens une erreur si on veut apprendre progressivement la gestion de paquets. Mais la transition se fait sans trop de bobos puis qu'on va simplement greffer un gestionnaire par-dessus un système déjà existant qui va garder une trace des fichiers de chaque paquet afin de pouvoir les désinstaller ou les mettre à niveau.

      Il est vrai que, bien qu'hors-sujet dans la méthode LFS, un gestionnaire de paquets est indispensable pour continuer à maintenir son propre système, sinon il faut tout simplement tout recommencer depuis le début, ça peut vite décourager.

      Je recommande donc personnellement et selon mon expérience Spack ou les pkgtools de Slackware (qui se comporte tous deux de la même ; Spack est de plus compatible avec les paquets Slackware) pour débuter sa gestion de paquets sans s'encombrer de la gestion des dépendances. Sous 0Linux, c'est 0g qui fait les mises à jour en ligne et qui s'occupe des dépendances, le code de 0g est dispo ici. J'en discuterai avec plaisir à quiconque est intéressé.

  • # Test dans blog

    Posté par  . Évalué à 2.

    Ouch, le test montre que l'installeur est très Slackware : il faut faire du fdisk à la mimine. Pour une distribution généraliste, j'ai du mal à suivre : ce mot signifie "grand public" ou "usage bureautique"? Parce que l'installeur est très loin de la première définition…

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Test dans blog

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

      « Généraliste » signifie « non spécialisé » mais en aucun cas orienté débutant. J'ai néanmoins déjà pensé à un installateur automatique qui s'occuperait du formatage et du partitionnement.

  • # Vu de loin

    Posté par  . Évalué à 2.

    Je viens de jeter un œil à cette petite distrib et surtout au site.

    Alors je ne suis pas tellement d'accord : je trouve la doc très bien faite et à mon avis suffisante.
    Je n'ai pas eu me temps de tester mais je pense que je vais faire joujou avec d'ici quelques heures.

    En tout cas bravo pour ce boulot.

  • # Merci pour ce moment

    Posté par  . Évalué à 2.

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

    Alors c'est comme ça ; après tous les trucs bien crapuleux que je t'ai faits en AWK, c'est par voie de presse que j'apprends que je suis lourdé ? :)

    • [^] # Re: Merci pour ce moment

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

      Ah mais pas du tout Monsieur, ça marche très bien comme ça et ça va rester ainsi justement !

      Python va surtout me servir pour certaines administratives lourdes, comme le catalogue en ligne des paquets par exemple. La gestion des paquets ne doit plus changer maintenant, quand ça marche on ne répare pas comme dirait l'autre. :)

      Merci pour ton travail et ta constance au passage, Spack n'a pas la visibilité qu'il mérite, à mon sens.

  • # retour d'experience interesssant

    Posté par  . Évalué à 1.

    Merci pour ce retour d'experience fort interessant et fortement enrichissant pour toi. Bon courage pour la suite.

Suivre le flux des commentaires

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