Unity-2D, nouvelle victime de la limite des 700 Mo ?

La nouvelle a fait beaucoup de bruit. Unity-2D, la version « non accelérée » de l’environnement de Canonical ne sera plus disponible sur le support d’installation.

Florent Gallaire a écrit sur son blog un excellent billet où il crie sa déception face à la décision de Canonical – qui doit savoir mieux que ses utilisateurs – quoi faire de sa distribution, non ?

Et pose une question intéressante :

Mais alors que se passera-t-il lorsqu’un ordinateur n’aura pas les capacités 3D nécessaires à Unity, si l’on ne peut plus avoir recours à Unity 2D ? La solution choisie par Canonical est la même que celle que Red Hat a mise en oeuvre pour GNOME Shell et qui fonctionne depuis Fedora 17 : utiliser LLVMpipe, qui est basé sur Gallium3D, pour émuler en software les fonctionnalités 3D manquantes du hardware.

Ceci implique très logiquement de gros problèmes de performance et, le plus grave selon moi, une compatibilité limitée aux seuls processeurs x86. Or, en plus du Toshiba AC100 et de son processeur ARM, j’utilise aussi de vieux Macs équipés de processeurs PowerPC comme desktop…

Pour info, j’utilise actuellement le pilote nouveau et son extension nouveau-dri sur ma distribution. Qui dépendent d’un certain Mesa 8.0.x, donc du LLVMpipe dont parle Florent sur son blog. Et mis à part un léger ralentissement au démarrage, Gnome Shell fonctionne aussi bien, sinon par endroit mieux qu’avec le pilote nvidia officiel. Mais fermons cette rapide parenthèse.

Une question est pourquoi virer Unity-2D alors qu’il fonctionne partout ? Une réponse possible ? Sa taille. En effet, et dans une tradition digne de Kafka, Unity-2D n’utilise pas GTK, mais QT et Metacity. Et puis, jetons un oeil aux paquets composant unity-2d, dixit le page du projet du launchpad.

J’ai pris les tailles des paquets en 64 bits, car il faut bien se tourner vers l’avenir de l’informatique, non ? 😀

J’ai uniquement donné la taille des paquets indispensables. Les bibliothèques de développement n’étant pas indispensables, je ne l’ai pas cherchée, ainsi que le transitional package.

Total : 1496 + 42 + 42 + 423 + 163 = 2166 Ko, soit 2 gros Mo. Pourquoi le virer dans ce cas ? Parlons des dépendances des paquets cités.

Pour Unity-2d-launcher :

Soit : 904 Ko. Donc, on en est à 3070 Ko. Toujours pas de quoi justifier de virer l’environnement. Passons donc à unity-2d-panel et ses dépendances communes avec Unity-2d-spread :

Total : 668 + 231 + 8860 + 140 + 12475 + 124 : 13638 Ko. Soit 13 Mo.

Le total d’unity-2D ? 3070 + 13638 = 16708, soit un peu plus de 16 Mo. Sans oublier Metacity et son paquet Metacity-common qui rajoute respectivement 867 et 1168 Ko. Donc, si on prend ce qui compose la plus grosse partie d’unity-2D, on arrive à 18743, soit en gros 18,30 Mo. Sur un support qui en pèse 700, ça fait 2,61%. Ce n’est rien 2,61% sur une image ISO. Mais si on veut rester dans les 700 Mo, grapiller 18 Mo ça aide vraiment.

Et il ne faut pas oublier que sur l’ISO officielle, il y a des outils qu’on s’attend à avoir, comme une trousse bureautique, comme LibreOffice… Le coeur de la suite bureautique pesant à lui seul… 117 412 Ko (ou encore 114,66 Mo) soit 16,38% du total d’une ISO de 700 Mo.

Donc entre sacrifier l’expérience utilisateur en ne lui fournissant pas une trousse bureautique dès le départ ou sacrifier un environnement de bureau, le choix est très vite fait si on veut proposer une distribution grand public, non ?

Et comme abandonner le support des symboliques 700 Mo serait un mauvais choix pour de nombreux marchés informatique, on risque de voir encore d’autres logiciels être boutés hors des images ISOs dans les mois et années qui viennent.

Ah, les contraintes du format CD… Ou au moins de sa taille de 700 Mo.

Quand j’ai commencé à m’intéresser au monde des distributions GNU/Linux, c’était vers 1996-1997. A l’époque, il fallait se créer deux disquettes au minimum pour démarrer un système minimal qui permettait de lancer l’outil d’installation.

Les CDs d’installation démarrant tout seul doivent dater de 1999 ou de l’an 2000. Quant aux liveCD, le premier, DémoLinux date de l’an 2000. 12 ans déjà, 4 ans au minimum avant une certaine distribution au nom de code bizarre, Warty Warthog, sorti courant octobre 2004.

Et depuis, sauf pour les distributions les plus gourmandes, une ISO d’installation d’une taille maximale de 700 Mo (capacité maximale d’un CD) est resté l’étalon.

En mai 2010, je parlais du problème de cette taille étalon. En dehors du fait que je pensais – et c’est toujours le cas – que des distributions à publication fixes semestrielles sont difficile à respecter coté stabilité, je parlais de sacrifices nécessaires coté logiciel.

Pour respecter la « sacro-sainte » limite des 700 Mo, on est obligé de faire la croix souvent sur des logiciels phare comme Gimp, ou encore OpenOffice.org.

Or, la publication récente de Linux Mint 9 propose une version en liveDVD qui contient des logiciels comme VLC et OpenOffice.org (assez indispensable de nos jours une suite bureautique) en complément de la version classique.
[…]
Car 6 mois, c’est déjà court pour stabiliser une distribution, et rester dans le cadre du format CD coté taille obligera constamment soit à augmenter le niveau de compression, en utilisant des outils comme xz soit à faire des sacrifices plus ou moins bien compris par les utilisateurs.

Sans le vouloir, j’ai eu le nez creux avec un peu d’avance. Lisant le site PcInpact, je suis tombé sur cet article, « Debian abandonne l’environnement GNOME au profit de Xfce »

Si on s’arrête à la une (comme de nombreuses personnes seraient tentées de le faire), on pourrait se dire : encore un coup dans la tronche de Gnome, mais il faut lire l’article pour tomber sur un morceau intéressant, je cite :

Un changement voulu en grande partie à cause du poids de GNOME qui augmente. Or, les développeurs veulent maintenant un objectif de taille raisonnable pour la distribution, notamment en ce qui concerne la distribution par images ISO de type CD.

D’ailleurs, si on se plonge sur le « commit » qui a mis en place ce choix, le commentaire est très clair.

« This ensures that the desktop will fit on CD#1, which gnome currently does not. » ce que l’on peut traduire par « Cela assurera que le bureau tiendra dans le CD 1, ce que gnome n’est pas capable de faire en ce moment ».

Bien entendu, pour les vieilles machines, avoir un support CD minimal quand on a un réseau de qualité moyenne, c’est l’idéal. Cependant, dans les pays développés ou pour les personnes pouvant faire une installation en réseau, voire mettre un ISO plus grosse que les 700 Mo sur une clé USB, le problème ne se pose pas.

Donc, nous assistons encore une fois à une obligation de trancher dans le vif pour respecter le sacro-saint format de 700M des images ISOs.

Pour combien de temps encore ?