Les WTF du libre – 1 – Le Forkenstein

Dans l’immensité de choix que propose le monde Linux, il y a des choses stables (les distributions célèbres), des originalités appréciables (Solus, certaines avec ce petit plus qu’on aimerait bien avoir sur son système principal) et les pertes de temps et de développement, appellées aussi DGLFI (voir article sur Pourquoi Manjaro pour cette abréviation).

 

Le monde des DGLFI est un riche monde où chaque fail qui est présent peut aussi être catégorisé. Tout comme il y a plusieurs types de bugs, il y a plusieurs types de DGLFI. Aujourd’hui, je vous explique le forkenstein.

Le terme forkenstein est une contraction de Fork (en informatique, action de reprendre un projet existant et de le modifier afin de l’adapter à ses envies/exigences) et de Frankenstein, célèbre personnage de fiction connu pour son monstre.

 

Le forkenstein, dans le principe, c’est un peu comme jouer ce docteur. On prend des morceaux logiciels foireux/morts cà et là, et on essaie tant bien que mal de faire tenir tout ça dans un OS en priant très fort pour que ça ne tombe pas trop vite. D’habitude plutôt confidentielles, ces DGLFI ont connu un regain suite à l’abandon de l’environnment Unity par Canonical.

Dans la pratique, dans un forkenstein actuel, on a deux éléments potentiellements explosifs :

-Une base (Ubuntu dans le cas des forkenstein unity) en version de développement, parce que ce ne serait pas assez drôle d’avoir au minimum une base stable pour profiter un minimum du “travail” accompli. Certains haut prophètes du néant créateurs d’iso sont persuadés que quelques bugs inhérents au processus de développement ne sont pas un frein à l’utilisation. Soit, je conçois qu’on puisse apprécier le masochisme.

-Un ou plusieurs projet(s) applicatif(s) “vedette” mort(s) ou sur le point de l’être. Cette partie est importante, car là est la particularité du forkenstein.

On tient un concept qui relève du génie. On est encore moins COP21-compliant que la DGLFI champ de mines (article à venir, teaser de furieux) étant donné que l’espérance de vie de ce genre de projet peut se compter en semaines, voir en jours. Effectivement, la base (en développement) évoluant vite de par le processus dans lequel elle est, va très vite rejeter le greffon quasi mort qu’on essaye de lui implanter de force. Il suffit d’une mise à jour d’une librairie importante pour l’application, qui déprécierait quelques fonctions pour faire exploser le tout en vol, sans possibilité d’amélioration (y’en a qui se cassent encore les joyeuses à maintenir des vieux environnements, mais tout le monde n’a pas les ressources de MATE).

 

Effectivement, ça peut être sympa en machine virtuelle (y’a t’il une autre utilité aux DGLFI?) pour voir jusqu’où ça va aller et prendre des paris sur la date de détonation avec les copains, mais le site ultra chiadé Apple style rempli de javascript (en fait un thème wordpress souvent “piraté”) qui vous présentera le projet vous encouragera fortement à l’installer en dur, avec un langage digne d’un consultant en consulting de pourquoi sa version est “mieux” que l’originale. Au final, le seul effet qu’aura ce genre de système est de vous filer une calvitie précoce à force de tenter de corriger les bugs, et de se sentir un peu mort à l’intérieur quand les 3 week ends de patching intensif auront servi a rien quand la base aura dit adieu à quelques dépendances de l’applicatif.

J'aime
0

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Anti-Robots *