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.