PROJET AUTOBLOG


FredericBezies

source: FredericBezies

⇐ retour index

La guerre des modèles de publication de distributions, le retour ?

lundi 5 février 2018 à 10:22

Mon collègue blogueur Seb95 a décidé – à son corps défendant – de relancer cette éternelle guerre de modèles de publication concernant les distributions GNU/Linux dans le billet suivant au titre des plus diplomates : « Manjaro: les Français, allez-vous faire foutre… Ou pourquoi je ne conseille pas cette merde de Manjaro »

Il y a un point que je voudrais aborder, c’est cette partie de l’article, que je cite :

mais une rolling n’est pas adapté à de vrais débutants, de ce que je vois et de ceux que je connais, les personnes qui me font confiance et qui sont dépendant de moi, ne seront jamais capable de se retrouver dans le flux perpétuel des mises à jour de cette distribution.

On tombe dans une forme de travers qui consiste à prendre son expérience pour la généralité. Outre le fait qu’il y a une forme de subordination (liée à l’envie de ne pas se prendre la tête), on peut se dire certain(e)s débutant(e)s mettent parfois de la mauvaise volonté à ne pas faire les efforts minimaux.

Il est vrai que les personnes en question n’ont pas des trucs hors de prix à décrocher qui s’appelle permis de conduire. Mais fermons cette rapide parenthèse.

Ensuite, Seb nous parle de la Frugalware, distribution qui n’a jamais su se vendre et qui a fait des choix stratégiques qui lui ont tranché la gorge sans oublier d’être un des distributions les plus buguées que je connaisse cf ce genre de billet datant de 2013, ou encore la Sabayon qui est soutenue par ses développeurs comme la corde soutient le pendu.

Les deux modèles ont des imperfections, ce qui est montre le côté artificiel de conflit. J’y viens dans la suite de cet article.

Comme disait Vladimir Illitch Oulianov, « Les faits sont têtus ». Dans les faits têtus du monde libre de 2018 ? L’accélération des sorties de logiciels est le plus gros de tous. C’est un des principaux problèmes des fixed releases.

LibreOffice a un cycle de vie de 6 mois entre deux versions majeures.

En 2017, nous avons eu la 5.3.0 (1er février 2017) et la 5.4.0 (29 juillet 2017). En 2016 ? La 5.1.0 (le 10 février 2016, le jour de mes 42 ans) et la 5.2.0 (le 4 août 2016).

Idem pour Gnome (mars et septembre de chaque année), Plasma (février et août de chaque année). N’oublions pas les navigateurs internet qui sont mis à jour toutes les 8 semaines ce qui fait 6 publications par an.

Il est vrai que sans une grosse connexion, maintenir à jour une rolling release tient du parcours du combattant. Il est vrai qu’il y a eu le bug du thème bien moisi de Manjaro. Mais ce genre de bug, il est indépendant du type de publication de la distribution.

Il n’est pas obligatoire d’être à la course à la dernière version du logiciel. Mais avoir une version récente au niveau des équipes de développement permet d’être certain d’avoir du support en cas d’emmerdements.

Il faut aussi que l’équipe derrière la rolling release ne prenne pas le melon, et c’est souvent le cas avec des projets qui deviennent un peu trop rapidement connu, et qui ont une croissance trop rapide pour être gérée correctement.

Mais les fixed ne sont pas à l’abri d’emmerdes monstrueuses. Si on prend la distribution qui est synonyme de Linux dans le grand public, peut-on passer à côté de l’énorme boulette des ordinateurs équipés de circuits UEFI briqués par la Ubuntu 17.10 ?

C’est largement plus emmerdant qu’un fond d’écran qu’on ne peut pas changer, non ? Mais qui dit fixed release dit aussi devoir passer par des contournements si on a besoin de logiciels plus récents, ne serait-ce que par exemple Mate 1.18 qui est arrivé un peu trop tard pour être inclus dans le cycle de développement de la Debian GNU/Linux 9 alias Stretch.

Les rétroportages sont une solution mais c’est aussi comme un cautère sur une jambe de bois, comme le montre l’article de Seb95 sur l’installation de Mate 1.18 sur Debian GNU/Linux Stretch.

Autre limitation d’une partie du monde des fixed release : il est parfois difficile d’avoir certains logiciels récents. Je prendrai le cas de Mozilla Firefox 57 et suivant sous Debian. Pour Fedora, des paquets pour les versions 57 et suivantes sont directement empaquetées par les développeurs de la distributions pour la version 26 et la version 27.

Bien que par défaut Debian se synchronise sur la version ESR de Mozilla Firefox, des utilisateurs préfèrent la version « court terme ». Manque de chance, l’arrivée tardive du compilateur rust complique la tâche des utilisateurs.

À moins de jouer avec l’apt-pinning ou de passer par l’installation de l’archive officielle, pas de voie de sortie pour le moment. Je me demande comment l’équipe de Debian gèrera cela avec la prochaine version ESR, la 60.0…

Donc pour conclure, AUCUN modèle n’est parfait. Ce n’est pas parce que Debian oblige à faire des contorsions pour certains logiciels assez cruciaux que je vais bazarder toutes les fixed releases.

Ce n’est pas parce que l’équipe de Manjaro international a pris la grosse tête qu’il faut jeter toutes les rolling releases.

Il ne faut pas jeter le bébé avec l’eau du bain. C’est ainsi que je concluerai cet énième article sur cette guerre inutile entre deux modèles de publications de distributions GNU/Linux. Modèles qui ont tous deux leurs qualités et leurs défauts.

En vrac’ de fin de semaine…

samedi 3 février 2018 à 10:29

Comme chaque fin de semaine, l’habituel en vrac.

Côté logiciel libre, informatique et internet.

Côté culture ?

Bon week-end 🙂

Guide d’installation d’Archlinux, version de février 2018.

jeudi 1 février 2018 à 08:26

Voici la cinquante-deuxième version du tutoriel pour installer une Archlinux, que ce soit avec une machine virtuelle, utilisant un Bios ou un circuit UEFI. Cette version rend obsolète celle de janvier 2018.

Pour les captures d’écran, je suis parti d’une image ISO intermédiaire créée avec l’outil Archiso. Au moment où j’envoie l’article en ligne, le 1er février vers 8 h 30 du matin, l’ISO de février 2018 n’est pas encore disponible.

Si vous avez besoin d’une image ISO en 32 bits, le projet archlinux32 vous en proposera une.

Merci à Angristan pour sa suggestion au niveau de l’installation des polices d’affichage et à Simon B pour sa remarque sur le double-démarrage de distributions GNU/Linux. Midori a été enlevé, son développement semblant être au point mort 🙁

Côté environnements : Gnome 3.26.2, Plasma 5.11.x, Xfce 4.12.0 et Mate-Desktop 1.18.0 en gtk3. J’ai surtout faire du nettoyage dans les paquets à installer, virant Midori entre autres.

NB : si vous voulez faire une installation avec l’UEFI, il faut utiliser cgdisk, gfdisk ou gparted, et créer un partitionnement GPT. Sinon, ça plantera !

Ce n’est pas un tutoriel à suivre au pied de la lettre, mais une base pour se dégrossir. Le fichier au format zip contient :

Le guide en question est sous licence CC-BY-SA 4.0 à compter du mois de mai 2016.

Bonne lecture et n’hésitez pas à me faire des retours en cas de coquilles !

Le monde du libre actuel part en couilles, épisode bonus : en dehors de l’anglais, point de salut ?

mercredi 31 janvier 2018 à 08:27

Je ne pensais pas avoir à écrire de nouveau dans cette série, mais des événements récents m’ont fait comprendre qu’il manquait un point que je n’avais pas abordé… Celui de la tendance au développement d’une monoculture linguistique, celle de l’anglais.

Une « crise » récente, qui restera connue sous le nom du « je peux pas changer mon putain de fond d’écran » a permis de mettre ceci en avant.

En gros, bien que le bug fut connu depuis des mois par l’équipe du forum auto-proclamé communauté francophone pour Manjaro, l’info n’avait jamais été remontée auprès des développeurs. J’ignorais pourquoi jusqu’à très récemment…

Philip Muller a apporté la réponse dont vous trouvez la capture d’écran et la traduction ci-après.

Traduction rapide et rendue plus correcte au niveau du français.

Ok, encore une fois à propos de la situation. Notre langue de communication est seulement l’anglais. Point final. Nous ne faisons que la gestion de la qualité qu’en anglais et en allemand. Pour toutes les autres langues, nous ne pouvons tout simplement pas faire attention.

Nous avons des membres dans notre équipe de base qui parlent italien ou espagnol. De plus, nous traduisons le Guide de l’utilisateur en anglais et en français, parce que le membre de notre équipe qui fait notre documentation vient du Canada. Comme il utilise principalement KDE, cette question n’a jamais été portée à son attention. Pour les captures d’écran, il utilise toujours le thème par défaut que nous avions décidé d’utiliser.

Le forum français nous a demandé s’ils pouvaient utiliser le domaine manjaro.fr et se rapporter un peu sur nos thèmes. C’est tout. Notre équipe est UNIQUEMENT sur le forum.manjaro.org. Ensuite, nous avons un forum officiel allemand, auquel je ne participe pratiquement pas et c’est tout.

Ainsi, seules les DEUX langues valables pour être officiellement testées sont l’ANGLAIS et l’ALLEMAND. C’est tout. Nous avons eu un peu de sang sur cette question et quelques cliques générales que certains pourraient avoir avec cela, mais encore une fois, nous n’avons tout simplement pas le temps de faire des contrôles de qualité sur les langues que nos développeurs utilisent. Cependant, nous pourrions résoudre les problèmes, si nous le pouvons sur d’autres langues, lorsqu’ils sont mieux documentés et que nous pouvons suivre les instructions de reproduction.

Nous pourrions trouver le temps de rechercher Manjaro sur Internet en fonction des termes de recherche en anglais, mais on ne peut pas explorer dans les forums basés sur les langues étrangères pour nos développeurs. Je suis ainsi que le reste de l’équipe vraiment désolé pour ce fait.

Cela permet enfin d’éclairer la situation non ? Donc si vous ne parlez pas anglais, dommage pour vous. Si vous pensiez que les forums locaux ont une quelconque influence, dommage pour vous. Je ne sais pas si c’est la même chose pour les autres distributions, mais une chose est claire : en dehors de l’anglais, point de salut.

Cela est dommage. Car il faut que l’on m’explique pourquoi certains logiciels s’énorgueillissent d’être multilingue au maximum pour chaque nouvelle version disponibles. Pour la façade ? Pour la gloriole ?

Il y a aussi le problème des rapports de bugs. Il est vrai que parfois, certains rapports sont incomplets, mais dans le cas de la « crise » qui nous intéresse, les infos étaient assez simples à apporter et à reproduire dans une machine virtuelle.

Même si les traducteurs automatiques sont de la merde en barre, est-ce trop dur de passer 10 minutes à essayer de pondre quelque chose de potable, tout en s’excusant de ne pas être parfaitement bilingue avec l’anglais ?

J’ai la chance de savoir m’exprimer un peu dans la langue de Shakespeare. Si un forum francophone dont les seuls liens sont l’autorisation d’un nom et d’une charte graphique ne trouve pas 5 minutes pour dire : « Salut, on a trouvé quelque chose qui cloche, ça vous intéresse ? », que doit en tirer comme conclusion ?

Que c’est une coquille vide pour faire remonter des problèmes au niveau international ? Qu’elle – l’équipe faisant fonctionner le forum – ne voulait que les avantages sans les inconvénients ? Que c’est une « cold-line » à peine incarnée ?

Dommage que le logiciel libre semble être désormais abonné à une seule forme de communication pour que certaines informations finissent par remonter : la gueulante.

Tout le monde est responsable dans ce genre d’histoire. Se l’ôter en disant « On n’a aucune obligation de faire remonter une info ! », c’est juste balancer un gros doigt d’honneur aux personnes qui développent les projets. Elles ne sont pas omniscientes.

On se plaindra de la mauvaise qualité d’une partie de la logithèque libre après… Que l’on soit utilisateur ou développeur dans le monde du libre, on est dans la même barque… Nier cette évidence… Bref, besoin de rajouter quelque chose ?

Je ne le pense pas, l’article a été suffisamment long ici !

« Les larmes d’Alyssa » d’Isabelle Rozenn-Mari, un bon thriller pour les fans et les autres :)

dimanche 28 janvier 2018 à 16:23

Fin 2017, Isabelle Rozenn-Mari, dont j’avais dévoré le cycle des « enfants de Dana » ou son roman primé « Souviens-toi Rose », m’avait contacté pour me proposer une offre que je ne pouvais refuser : être dans les béta-lecteurs de son nouveau roman « Les larmes d’Alyssa ».

Je m’étais promis d’en parler à la sortie. C’est chose faite en cette fin du mois de janvier 2018.

Comme d’habitude, Isabelle Rozenn-Mari nous fait voyager en Bretagne, région de prédilection de ses oeuvres.

Le synopsys du roman ? Alyssa vient de voir mourir sous ses yeux son compagnon, lâchement poignardé en plein Paris. Pour fuir les mauvais souvenirs, la voila qui retourne vers le petit village de Bretagne, Daoulmar où vit sa grand mère avec qui elle a une relation privilégiée.

À peine arrive-t-elle à destination que d’une série d’événements macabres dans une église abandonnée qui l’est tout autant se déclenche.

Surtout les questions s’accumulent au fil des pages. Quel lien peut-il y avoir entre les événements et ceux intervenus une dizaine de siècles auparavant quand des troupes vikings ravagèrent la région ?

Les incessants aller-retours temporels plus ou moins prononcés permettent à la personne qui lit ce roman de rassembler petit à petit les pièces du puzzle. Mais Isabelle Rozenn-Mari a été suffisamment inventive pour n’arriver à donner les explications finales qu’après avoir dépassé les quatre-cinquième du roman.

Je ne vous spolierai pas le plaisir ni la surprise de fin. Une seule remarque : ne pensez pas avoir tout compris trop tôt, vous seriez déçus 🙂

Je ne suis pas un grand amateur de thriller, mais le mélange policier, fantastique et historique, l’ambiance lourde de ce petit village donne envie d’aller jusqu’au bout du texte.

Je vous conseille donc ce roman, l’ayant vraiment dévoré en l’espace de trois jours même si Isabelle m’avait fait comprendre qu’il n’y avait pas le feu au lac pour le terminer.

Vous passerez un excellent moment avec ce nouvel opus d’Isabelle. Faites-moi confiance 🙂