Une petite mise au point sur mes articles de présentations de distributions GNU/Linux.

Depuis des années, je présente et teste rapidement les distributions GNU/Linux qui me passent sous la souris. Et souvent, certaines personnes me font les mêmes remarques du genre : pourquoi pas d’installation en dur ? Pourquoi ne passes-tu pas plus de temps sur les distributions en question ?

J’ai donc décidé de faire un article qui tient de la mise au point et aussi du coup de gueule, car j’en ai marre de me justifier à chaque fois. C’est la première et dernière fois que je rédige ce genre d’articles.

Premier point : pourquoi utiliser Qemu / VirtualBox et pas une installation en dur ?

Réponse courte : parce que.

Réponse plus longue : car c’est plus souple, plus simple et largement plus rapide et pratique à mettre en oeuvre.

Qemu et VirtualBox propose des machines type, avec du matériel standardisé, et donc plus passe partout que le matériel réel qui équipe parfois les machines. Sans oublier, qu’en cas de problème – fausse manipulation au niveau de l’installation par exemple – je peux virer l’image disque et recommencer à zéro sans avoir à craindre pour mon vrai matériel. Car c’est étrange, mais je considère que les données de mon disque dur sont précieuses.

C’est certain, c’est moins rapide que sur une machine réelle. Mais, c’est tellement plus pratique. Sur une machine réelle, on fait comment pour enregistrer une vidéo depuis le démarrage ? Ma machine principale, je n’ai pas envie de la foirer car une distribution mal embouchée aura maltraité mon grub. Et dans ce domaine, les distributions mal embouchées, ça existe 😉

Deuxième point : pourquoi ne pas faire des tests de plusieurs jours sur chaque machine virtuelle ?

Pour une simple et bonne raison qui tient à l’arborescence et l’historique des distributions GNU/Linux.

En gros, depuis 1992-1993, et les premières distributions, il y a 5 grandes familles.

  1. Celles basées sur les paquets .deb : Debian GNU/Linux et sa floppée de distributions dérivées (comme Aptosid, siduction, SolusOS, SalineOS, etc…), Ubuntu et sa floppée de dérivées (la série des L/K/X/Edu/buntu, les PearOS, ElementaryOS, etc…)
  2. Celles basées sur les paquets .rpm : RedHat (Fedora Linux et RHEL) et ses dérivées (CentOS par exemple), OpenSuSE, Mageïa, (ce qui reste de) Mandriva, PCLinuxOS, etc…
  3. Slackware et ses dérivées : SalixOS pour ne citer que la première qui me viennent à l’esprit. Même la Frugalware Linux est plus ou moins basée à l’origine sur la Slackware.
  4. Les distributions sources : Gentoo, Sabayon, Source Mage GNU/Linux, LFS, etc…
  5. Le reste : Archlinux (et ses dérivées comme Manjaro, Bridge, Chakra), les distributions comme Paldo GNU/Linux (et son empaqueteur en C#), ou des projets plus ou moins étranges comme la GoboLinux.

J’ai simplifié, mais l’idée est là. Sans oublier, qu’il y a en gros un quintet d’environnements de bureau principaux, qui reviennent tout le temps :

  1. Gnome Shell et Unity
  2. Cinnamon
  3. Xfce
  4. KDE SC
  5. Lxde

Ca doit couvrir, à la louche, 85 à 90% des distributions proposant un environnement graphique.

Autant dire qu’on retombe très souvent sur les mêmes combinaisons, du genre : paquets deb + Xfce ou paquets rpm + KDE SC.

Et qu’est-ce qui ressemble plus à une distribution basée sur les paquets .deb avec Xfce qu’une autre distribution qui propose elle aussi des .deb avec Xfce ? On pourrait remplacer Xfce par KDE, .deb par .rpm, et on retomberait sur la même problématique.

Mis à part l’outil de configuration centralisé, une Fedora Linux avec KDE SC ressemblera étrangement à ce que propose Mageïa. Ou encore un duo Archlinux + KDE SC ressemblera à une Chakra Linux.

Il faudra m’expliquer l’intérêt de passer plusieurs jours sur des distributions qui se ressemble aussi bien au niveau du gestionnaire de paquets que de l’interface utilisateur.

Les installateurs se ressemblent tous, la différence ne se faisant qu’au niveau du nombre d’étapes ou de leur compacité en pages à remplir.

Dernier point : certains tests sont très courts en terme de texte écrit.

Il est vrai que vu les parentés entre les distributions, de nos jours, il n’est pas besoin de pondre 3 pages sur l’installation des mises à jour, alors qu’une simple capture d’écran ou une indication pour y accéder est tout autant parlant.

Les distributions se ressemblent toutes plus ou moins. Donc, devrais-je faire une description par le menu de chaque logiciel installé ? Ou simplement dire que telle fonctionnalité précise est proposée par tel logiciel ?

Les différences sont souvent plus subtiles, du genre noyau utilisé, ou encore navigateur utilisé. On pourrait dire le petit détail en plus. J’avoue que je suis toujours étonné de voir une nouvelle équipe proposer une énième debian-like avec tel ou tel environnement de bureau, alors que le marché visé est saturé, pour ne pas dire qu’il vomit au niveau du surnombre de distributions proposées.

Je n’essaye pas de me mettre à la place de l’utilisateur, mais j’essaye de montrer ce qui existe, en essayant de rester neutre, sauf s’il faut dire qu’un produit, présenté comme finalisé n’est en vérité qu’une version au mieux en version béta.

Quand j’ai parlé de la Bridge Linux dans un article récent, on pourrait penser que j’ai été vache, pour ne pas dire le pire des enfoirés sur Terre. Mais cependant, certains petits problèmes mis bout à bout pourrait rebuter l’utilisateur qui aurait envie de se plonger dans la distribution car elle pourrait correspondre à ses besoins.

C’est peut-être l’expression d’un problème plus profond, celui de se faire mousser l’égo en sortant une distribution GNU/Linux car « ça fait bien sur le CV« . On finit par se retrouver avec un nombre impressionnant de distributions qui visent toutes une cible précise mais qui éparpillent leurs forces au lieu de les mettre en commun.

C’est surement le vieux con qui parle ici. Ou une personne qui est lassée de voir autant d’énergie gachée par des luttes d’égo.

22 réflexions sur « Une petite mise au point sur mes articles de présentations de distributions GNU/Linux. »

  1. Un million (au moins!) de fois d’accord avec vous.
    Ne changez rien.
    Même que vous pourriez en rajouter à propos de ces « distros » que ne sont, parfois, que la fantastique somme de travail que celui de changer de fond d’écran…et allez’zou un coup de remastersys…
    Cordialement,
    et très longue vie à votre site.

  2. Je préfère 1000 fois un article court ou tout est dit que trois pages de détails inutiles. En plus c’est un exercice pas évident à réaliser, il faut trouver le bon équilibre.

    C’est nikel comme ça 😉

  3. Tout à fait d’accord avec ce que tu dis ici.
    J’apprécie des tests et les screenshots et screencasts qui me permettent de découvrir rapidement une distribution que je n’aurais pas le temps de tester.

    Une petite erreur : le lien vers le site de GoboLinux pointe en fait sur le site de Paldo.

  4. « …Ou une personne qui est lassée de voir autant d’énergie gâchée par des luttes d’égo. »

    Entièrement d’accord avec cette phrase… et avec le reste de l’article d’ailleurs!…

  5. Bonsoir Frédéric, pour compléter tes dires je rajouterai que si l’on devait installer en dur chaque distribution que l’on souhaite tester, cela deviendrait rapidement une galère sans nom. Imagine le grub avec 27 choix au démarrage…
    En ce qui me concerne, je n’aime pas tester en machine virtuelle pour des raisons de lenteur/lourdeur. J’utilise la clé USB bootable qui me donne un aperçu sans correspondre tout à fait à la réalité d’une installation en dur. Mes essais ne durent pas non plus huit jours puisque mon objectif est le même que le tien, faire découvrir le plus objectivement possible une distribution.
    Alors Frédéric, ne te fais pas de noeud au cerveau car sur ton blog tu es chez toi. Continue à réaliser tes tests comme bon te semble et à nous les raconter à ta façon, c’est comme ça que tu fonctionne et qu’on aime te lire.
    Bonne soirée.

    Claude

    1. La clé USB démarrable n’est pas non plus la panacée, car certaines distributions ne proposent pas de versions utilisables hors installation.

      Lenteur ? Euh, depuis que les émulateurs utilisent les fonctionnalités kvm (intel-kvm / kvm-amd), le ralentissement est proche de presque rien. Le seul ralentissement, c’est lié à l’émulation disque, et vu les progrès faits par les deux principaux ténors du domaine…

      Tester durant 8 jours ne sert pas à grand chose, comme je l’ai précisé, on a le trio .deb / .rpm / autres coté formats de paquets. Idem pour l’environnement de bureau qui se résumé à Cinnamon / Gnome Shell / Unity / Xfce / KDE SC / Lxde. Donc, mis à part un thème différent, euh…

      Mon but est de présenter l’existant, faire une description, et après, libre à chaque personne d’approfondir. Au moins, Qemu / VirtualBox permettent de faire des tests dans un environnement neutre, et donc dans les meilleures conditions possibles, au niveau du matériel, sachant qu’il est impossible à 100% de reproduire toutes les configurations matérielles pouvant exister.

  6. je suis régulièrement tes tests, cela me permets parfois de faire de belles découvertes ou des mises au point pour certaines installations qui peuvent rebuter comme arch par exemple …

    1. Il est vrai que l’installateur scripté d’Arch peut rebuter certaines personnes, et ce n’est pas « un mal » dans le sens que ce sont des personnes qui n’auraient pas adhérés à la philosophie d’Arch au final.

  7. D’accord avec toi sur la surabondance des distributions dérivées qui, amha, ne sers pas vraiment le Libre (quel gaspillage d’énergie !).

    Surtout que désormais, les « grandes » distributions fournissent les outils pour créer une dérivée, même un débutant peut y arriver…

    Si le travail de construire une distribution (ensemble cohérent de paquets, installateur, tests, contrôle qualité, support, distribution, …) est un boulot considérable, utile, et nécessaire, il est vrai qu’un Gnome reste un Gnome.

    Donc j’aimerais que plus souvent, on mesure aussi ce travail à la contribution faite par les développeurs (de la distribution) aux projets dont ils utilisent les sources, en particulier le reversement des correctifs, l’ajout de fonctionnalités, la collaboration. Travail dont bénéficie réellement l’ensemble des distributions, et donc le Libre.

    Qu’une distribution fournisse le noyau 3.7 ou LibreOffice 4.0 me semble sans intérêt. Qu’elle bosse sur ces versions depuis leur première beta, et participe activement à leur développement, et les intègrent rapidement donne tous son sens aux principes fondateurs du Libre.

    1. Donc j’aimerais que plus souvent, on mesure aussi ce travail à la contribution faite par les développeurs (de la distribution) aux projets dont ils utilisent les sources, en particulier le reversement des correctifs, l’ajout de fonctionnalités, la collaboration. Travail dont bénéficie réellement l’ensemble des distributions, et donc le Libre.

      En proposant par exemple des paquets basés sur le code le moins modifié possible, histoire de pouvoir remonter des bogues ?

      En ce qui concerne le noyau 3.7 en testing, il n’y a presque aucune rustine chez archlinux :

      https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux

      change-default-console-loglevel.patch
      fat-3.6.x.patch

      Et si on jette un oeil sur la partie des patchs lors de la compilation :

      # set DEFAULT_CONSOLE_LOGLEVEL to 4 (same value as the ‘quiet’ kernel param)
      # remove this when a Kconfig knob is made available by upstream
      # (relevant patch sent upstream: https://lkml.org/lkml/2011/7/26/227)
      patch -Np1 -i « ${srcdir}/change-default-console-loglevel.patch »

      # fix cosmetic fat issue
      # https://bugs.archlinux.org/task/32916
      patch -Np1 -i « ${srcdir}/fat-3.6.x.patch »

      Autant dire que c’est du patching ultra-light 🙂

      Qu’une distribution fournisse le noyau 3.7 ou LibreOffice 4.0 me semble sans intérêt. Qu’elle bosse sur ces versions depuis leur première beta, et participe activement à leur développement, et les intègrent rapidement donne tous son sens aux principes fondateurs du Libre.

      Dans les deux cas, si cela permet aux mainteneurs – via les retours des testeurs – de mettre la souris sur un bug vicieux, pourquoi pas. Et en ce qui concerne LibreOffice, c’est pas plus mal. C’est un outil assez important pour nombre d’utilisateurs.

      Le plus important est d’avoir un code source le minimum rustiné, cela évite de faire remonter des bugs liés à des patchs propres à la distribution et donc difficilement voire pas reproductible du tout par les codeurs en upstream.

  8. petite erreur « Mis à part l’outil de configuration centralisé, une Fedora Linux avec KDE SC ressemblera étrange… » C’est étrangement je suppose?

    Sinon pour en revenir à l’article moi aussi je préfère des articles longs, mais ce que je fait, je lis ton résumé, regarde le site de la distro, cherche quelques articles sur le net et basta =D.

  9. Hello, juste une question qui me turlupine. Chez Cyrille tu écris qu’Ubuntu t’a dégoûté des distribs à base de .deb. Tu peux développer ou suis-je noobement indiscret ?

    1. C’est surtout un effet tiers des distributions à base de .deb : la multiplicité des ppa et autres dépots tiers qui peuvent – comme d’autres formats de paquets – à des conflits insolubles de dépendances.

      Les paquets ne sont pas très pratiques à créer aussi. Alors qu’il suffit d’un PKGBUILD et d’une simple commande sous Archlinux (un FrugalBuild pour Frugalware, un SlackBuild pour la Slackware, etc…), c’est plus complexe sous Debian et apparentées.

      Enfin les .deb sont souvent des paquets assez « rustinés », et pas vraiment l’idéal pour rapporter des bugs au niveau des développeurs d’origine.

      Voila, ce sont les principales raisons qui me font m’éloigner des distributions basées du .deb.

  10. L’interet de tester en dur est de voir comment la distribution vie.
    Par exemple pour ceux qui ont eu la joie de tester une montée de version sur fedora comprendrons qu’une des qualité d’une distro est d’évoluer sur le long terme.
    Par exemple concernant arch en l’utilisant régulièrement on voit que parfois la mise à jour plante ou est impossible sans MAJ manuelles ou bien sur une gentoo les pb de compil ou de dependances.
    Sur Arch j’ai eu mon PC qui a planté au milieu d’une mise à jour, évidement le reboot ne s’est pas passé bien et j’ai du creuser un peu pour reparer tout ca.
    Ca m’a fait comprendre bien des choses sur le système de package arch qui est rapide mais pas le plus évolué.
    Enfin même avec un systeme de package similaire on voit une grande différence de comportement entre par exemple une ubuntu (avec upgrade régulières) et une siduction en rolling release, on apprécie aussi ca sur le long terme.
    On pourra de plus en utilisant une distro un certain temps comprendre la richesse des packages et fonctionnalités dispos en fonction des besoins.

    1. Et se niquer les autres systèmes en cas de mise à jour qui se passent mal.

      Les mises à jour qui plantent sous Archlinux, c’est combien de fois que j’y ai eu droit en 5 ans d’utilisation ? Une fois par an, la plus grosse ayant été la migration vers glibc 2.16. Mais j’ai pu récupéré la main grace à un live USB.

      Enfin même avec un systeme de package similaire on voit une grande différence de comportement entre par exemple une ubuntu (avec upgrade régulières) et une siduction en rolling release, on apprécie aussi ca sur le long terme.
      On pourra de plus en utilisant une distro un certain temps comprendre la richesse des packages et fonctionnalités dispos en fonction des besoins.

      Ce qui ne se voit pas dès l’installation avec les logiciels proposés par défaut, c’est bien connu.

      Très bien, amuse toi à faire cela, et tu n’auras plus que tes yeux pour pleurer quand une mise à jour se passera mal.

      Chacun voit midi à sa porte, mais tester en dur, c’est parfois pas très utile, étant donné qu’une virtualisation – modulo certaines spécificité liées à son matériel réel – permet de voir vivre la distribution sans risque.

Les commentaires sont fermés.