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.

4 réflexions sur « Unity-2D, nouvelle victime de la limite des 700 Mo ? »

  1. Victime de la maintenance qu’il faut pour lui selon moi. Tout a été codé en Qt alors que ce n’est pas vrai pour Unity (3D). C’est suffisant pour arrêter les frais et mettre les développeurs de la version 2D à travailler sur un projet plus utile.

    1. C’est surement la raison première de l’éjection du projet du CD officiel. Cependant, 20 ou 30 Mo sur une image qui en fait 700, c’est toujours cela de pris.

      Car il ne faut pas oublier que la base d’Ubuntu est quand même bien fournie par défaut : il y a des monstres de gourmandises comme LibreOffice (facilement 150 Mo).

      Ensuite, avoir lancé un projet en QT dans un environnement se basant sur GTK, c’est vraiment kafkaïen comme situation.

  2. Bonjour!

    Dites moi si je me trompes, mais je crois bien que je suis bon pour changer de distro.
    En effet, je n’utilisais que Unity 2d, la version 3d me semble trop lourde et tout simplement plus consommatrice d’énergie.

    Ubuntu commence à me taper sur le système avec toutes ces décisions qui ne servent qu’à imposer leur interface plutôt qu’une autre, vous me direz qu’on peut en installer d’autres, mais franchement, je trouve ça agaçant d’accumuler plein d’interfaces différentes.

    Vous n’auriez pas une distribution à me conseiller, de préférence une assez simple (avec logithèque par exemple ou bien synaptic au pire) qui serait en rolling release?

    J’avais dans le viseur LMDE, mais je n’ai pas testé chez moi necore, est-ce que la reconnaissance matérielle est aussi bien que celle d’ubuntu?

    Merci.

    1. Si vous utilisez unity-2D, en effet. Mais il n’y a pas que la taille qui rentre en ligne de mire, c’est aussi la lourdeur de maintenir 2 version de l’interface et qui prend du temps.

      Pour la reconnaissance matérielle, entre les deux LinuxMint, la meilleure serait la Linux Mint tout court. La LMDE doit avoir un niveau de reconnaissance du matériel comparable, mais le plus simple est de se faire une clé USB démarrable et de voir le résultat.

      Ensuite, Linux Mint (version DE ou pas), propose Cinnamon qui utilise les technologies dérivées de celle de Gnome-Shell.

      Bref, à vous de voir !

Les commentaires sont fermés.