Dans un article publié sur le blog-libre, Cep a pondu un article très intéressant, dont je reproduis ici un morceau qui m’a interpellé :
« […]Ceci me pousse à parler de diversité. Je le dis tout de go, les forks, les dérivés, ne me dérangent pas du tout et pour les iso anecdotiques, et bien je ne les vois pas, je les ignore même.
J’entends souvent crier au gâchis, à la dispersion, la complexité de choix, de développeurs irresponsables et plus soucieux de leur petite personne que de l’intérêt général.
Certes, et après ? de quel droit devrions-nous restreindre les initiatives personnelles ? les travaux et essais de quelques-uns, isolés ou pas et les obliger à se cantonner dans un travail sérié, restreint, pour le soi-disant bien du plus grand nombre ? Non, ces personnes ont tout à fait le droit de tester des projets, voire de se tromper et de se retrouver dans une impasse, une route sans issue, de se décourager ou d’intégrer ensuite une grosse équipe de développement.
Si on avait écouté cette voie d’une prétendue sagesse on en serait peut-être toujours à un monde des distributions Linux cantonné à une Slackware, une Debian, une Redhat. Malgré les très grandes qualités de ces ancêtres qui sont d’ailleurs toujours le tronc commun et indispensable de bien des dérivées, une chose est certaine, les grandes avancées vers la simplification initiée par Ubuntu pour ne citer qu’elle n’aurait jamais eu lieu. Et, à ce titre, la Mint Cinnamon, pur produit de cette possible diversification est un exemple parfait de ses bienfaits.[…] »
Tout ce beau discours, sur lequel je souscris en partie est une façon de mettre la poussière sous le tapis. Car c’est un discours qui est à la fois techniquement recevable, mais complètement inadapté pour populariser le logiciel libre dans son ensemble.
J’aime bien Distrowatch qui montre à quel point cette politique du « on forke car on peut forker » est casse-gueule, polluante, et surtout le meilleur moyen de faire penser que le monde du logiciel libre est digne de la petite section de l’école maternelle.
Une simple statistique qui vaut tous les discours du monde, celle des distributions indexées depuis 2002 par Distrowatch, soit une douzaine d’années.
- Number of all distributions in the database: 790
- Number of active distributions in the database: 291
- Number of dormant distributions: 63
- Number of discontinued distributions: 436
- Number of distributions on the waiting list: 254
Donc, il y a 1,49 fois plus de distributions indexées par Distrowatch sur 12 ans qui ont été abandonnées que de distributions encore maintenues… 55% des distributions listées sont décédées… Ouille !
La simplification initiée aurait-elle eu lieu sans la multitude de forks ? Oui, mais sous une autre forme. Dans un article récent, j’ai repris l’ISO de la Fedora Core 2, qui était un plaisir en comparaison des distributions précédentes. La version d’Anaconda permettait de régler en quelques clics Xorg, ce qui évitait de passer par l’outil de configuration en mode texte.
Comme on dit souvent, il n’y a pas pire sourd que la personne qui se bouche les oreilles avec les mains. Il y a plus d’un an et demi, je rédigeais un billet où je critiquais déjà la politique du fork compulsif et par définition gaspilleurs de ressources.
En août 2014, je parlais à nouveau du sujet, employant un ton plus humoristique.
Mais j’avoue que quand je vois le discours tenu par Cep, je me dis que le chemin pour une certaine prise de conscience est encore très longue. Que je pourrais encore aider Ladislav de Distrowatch à nettoyer la liste d’attente des distributions qui ont passé l’arme à gauche. En l’espace d’un an à raison d’un courrier par trimestre, la liste d’attente a été diminuée d’environ une soixantaine de noms. Ce qui est peu dire du darwinisme inhérent au petit monde des distributions GNU/Linux.
Pour la énième fois, et je sens que ce message ne passe pas, forker pour forker, ça ne sert à rien. Pondre une distribution GNU/Linux basée sur Ubuntu (on en est actuellement à 70 vivantes et 45 abandonnées) comme les caricaturales Micro-R OS ou encore Peach OSI (liste non exhaustive), ça apporte quoi au logiciel libre ? Mis à part encore un peu plus de fragmentation, je ne vois pas.
Forker est dans l’ADN du logiciel libre, je ne le nie pas. C’est nécessaire, d’accord. Mais forker pour forker, pour faire un doigt d’honneur à une technologie (cf l’exemple du site debianfork), quel est l’intérêt et quelle image veut-on donner du logiciel libre ainsi ?
Cela me fait penser au titre de Florent Pagny et sa liberté de penser…
Chacun voit midi à sa porte, et je continuerai de dénoncer les forks compulsifs. Ce n’est pas en ignorant un problème lié à l’abus d’une composante du logiciel libre qu’on le résoudra.
Mais, c’est vrai… Je ne suis que l’emmerdeur de base, l’utilisateur final, somme négligeable au final 🙂
HeLLo,
Je me dénonce -> je suis un « rebuilder » (je préfère ce terme) compulsif, qui + est en mode « enlightened » (& plutôt pour moi même, pour l’instant).
Mais voir arriver par exemple une version manjarienne de E avec la moitié de xfce (redondante) en prime ne m’a jamais convaincu.
Empilez du code, il en restera toujours quelque chose -> Oui, de l’espace disque en moins…
On peut regretter les forks compulsifs inintéressants ou les admettre en tant que nécessité de libérer la créativité, (combien de peintres visionnaires morts dans la misère et la folie? Ne parlons pas des poètes, des plus grands !)
Y-a-t-il un moyen de ne pas perdre ces créatifs bouillonnants autre que les recruter, les acheter, et les faire bosser : chez Windows, Google, une startup ambitieuse ?
Ça c’est ce qui se passe aux US où le critère de qualité est la capacité à fairedu cash…
Autre débat….
Il ne faut pas empêcher les hommes de croire qu’ils peuvent réaliser leurs projets les plus fous. Et si 95% d’entre eux échouent, ce n’est pas grave, l’échec les aura fait grandir.
Le problème est d’ordre pratique. Le logiciel libre apparaît comme un vaste foutoir. Et sans quelques points de repères…
Ou pas… J’avoue que je ne serais pas aussi optimiste ici.
D’ailleurs quelqu’un peut m’expliquer les querelles de clocher entre init et systemd, je comprend rien en quoi c’est différent !
init : https://fr.wikipedia.org/wiki/Init
systemd : https://fr.wikipedia.org/wiki/Systemd
Hmm, des querelles byzantines pour *simplement* savoir si c’est dans un ou plusieurs fichiers (j’ai compris ça en tout cas). Pourquoi tant de disputes ? Bon, je sais que le boot est stratégique, mais quand même !
A ce niveau là, sérieusement…
Il n’y a pas que cela. Il y aussi une histoire de log au format binaire, au lieu du format texte alors qu’une simple modification du fichier /etc/systemd/journald.conf permet l’accès au format texte : il faut définir ForwardToSyslog=yes et avoir un outil à la syslog disponible.
Ou encore le fait que systemd veut trop vouloir en faire. Sans oublier une partie des opposants qui sont contre car Lennart Poettering est derrière.
Autant le système des logs est compréhensible et de l’idée de vouloir trop faire tue le produit, mais qu’à fait Lennart Poettering ? C’est quand même pas un assassin ? Il y a bien une petite polémique avec les *BSD, mais bon, c’est comme l’ancien PDG de Mozilla, on s’en fout de ses opinions tant que ça marche ?
les forks compulsifs
J’espère que tu vas pas aller jusqu’à prétendre que développer autre chose que systemd est « compulsif » Le lien de debian en faisant référence.
Il y a 2 3 choses que je fais quasi tous les jours sur systemV:
1. Choisir mon mode de démarrage au boot en ajoutant 2 3 4 ou 5 à la ligne de commande du kernel.
Tu peux me donner la commande sous systemd je sais qu’elle existe
2. Déactiver Arrêter Lancer un service:
Tu peux également me donner la commande sous systemd je sais qu’elle existe.
3. Analyser un log et mieux filtrer la sortie avec grep
Tu peux encore me donner la commande sous systemd je sais qu’elle existe.
Le problème c’est que:
J’arriverai pas à les retenir… elles sont pour le moins …à rallonge
Mais la question pour moi, est tellement comment dire:
Pourquoi as-t-il fallut changer ce qui existait sur systemV et fonctionnait de façon tellement simple et directe ?
Et enfin il faut savoir qu’un serveur fonctionne TRES bien et surtout sera encore moins vulnérable donc plus stable sans le sous-system DBUS puisque pas de « plugin possible », pas de modification à chaud. Bon d’accord ça devient pointu. Essayez de faire un serveur avec une distro qui utilise systemd et sans dbus 😀 Faites moi signe quand vous aurez réussi.
Pour conclure.
Non je n’ai rien contre Lennart ni rien contre systemd. Simplement je ne me sens pas encore disposé à y passer parce que le besoin n’est pas encore là.
Dans le cas des systèmes d’init, ce n’est pas compulsif, loin de là.
Et pas franchement facile à retenir.
Car les scripts liés à systemV pouvaient tourner au casse-tête en terme de maintenance ?
Chacun voit midi à sa porte, et préfère tel ou tel système d’init en fonction de ses besoins.
Car les scripts liés à systemV pouvaient tourner au casse-tête en terme de maintenance ?
De où tu tiens cette info ?
Aprés 8 ans d’utilisation sur systemV … Vraiment rien à redire
Ca dépend de la rédaction des dits scripts. Certains sont écrits et deviennent illisibles. D’autres moins.