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.
