Sabayon Linux 10 : une distribution un peu lourde à digérer ?

Le 13 septembre, l’équipe de Sabayon Linux a présenté la 10ième version officielle de sa distribution, dérivée de la Gentoo Linux.

Les notes de publications sont savoureuses. Non content de proposer une version de développement de l’implémentation libre du standard OpenGL, à savoir Mesa 9 en date du 31 août, ils cassent gentiment la technologie systemd.

Sur l’intégration de la pré-version de Mesa 9 :

« Mesa 9, drm stack, KMS

Mesa 9 is not out yet, but you can get a taste of it in Sabayon 10 already, which is shipping with a 2012-08-31 snapshot of Mesa 9 and updated libdrm and drivers stack. Out of the box Kernel-Mode-Setting experience has been improved for Intel and Matrox video cards as well, while due to conflicts with fglrx, radeon KMS still requires some scripty help (but this will be addressed once Linux 3.6 is out). Please have a look at our footnotes if you have problems booting your system on AMD hardware. »

Ce qui donne traduit :

« Mesa 9, drm stack, KMS

Mesa 9 n’est pas encore sorti, mais vous pouvez y goûter dans Sabayon 10, qui propose un instantané de développement de Mesa 9 en date du 31-08-2012 et des versions à jour de libdrm et des pilotes. L’expérience immédiate [vous traduiriez comment out-of-the box ?] du Kernel-Mode-Setting a été amélioré pour les cartes vidéo Intel et Matrox aussi, mais à cause de conflits avec fglrx, le KMS avec Radeon requière encore une petite aide au niveau des scripts (qui sera corrigée quand Linux 3.6 sortira). Veuillez jeter un oeil au notes de fin de page si vous avez des problèmes pour démarrer votre système du matériel AMD »

Et pour le cassage de systemd :

New udev, kmod stack

As many other distributions, we were tempted by systemd to the point that we made it easier to migrate to it through Portage (and you can do that as well, with some trickery). This required a new udev-systemd snapshot and the migration to kmod, from module-init-tools. Our team, more precisely Joost Ruis, decided to benchmark OpenRC (our current init system) against Systemd and the results were a bit disappointing. While Systemd has proved to be faster, our real world scenarios simulation showed that the difference is well below 8 seconds for the boot process. Does this justify the move towards a less-tested and for many controversial technology? Not yet, our boot is fast enough. Do the average people restart their system more than 5 times a day? We don’t think so.

Ce qui donne traduit :

Nouvel udev, nouvelle pile kmod

Comme beaucoup d’autres distributions, nous avons été tenté par systemd au point que nous avons rendu sa migration plus facile dans Portage (et vous pouvez le faire aussi bien, avec quelques manipulations). Cela a nécessité une nouvel instantané de udev-systemd et la migration vers kmod, à partir du module-init-tools. Notre équipe, plus précisément Joost Ruis, a décidé de comparer OpenRC (notre système actuel init) contre Systemd et les résultats étaient un peu décevants. Alors que Systemd s’est avéré être plus rapide, nos simulations en mode réel ont montré que la différence est bien en dessous de 8 secondes pour le processus de démarrage. Est-ce que cela justifie le passage à une technologie moins testée et controversée par de nombreuses personnes ? Pas encore, notre démarrage est assez rapide. Est-ce que la moyenne des gens redémarrent leurs systèmes plus de 5 fois par jour ? Nous ne le pensons pas.

8 secondes de différence, c’est quoi ? Une gorgée de café ou deux ? En prenant un démarrage par jour pour un utilisateur « lambda », ça fait quoi au bout de 365 jours ? 48 minutes gagnées par an, c’est vrai, c’est négligeable au final 😀

Mieux vaut casser l’affichage en proposant une version instable de MesaGL que d’utiliser une technologie moins testée – il est vrai que les utilisateurs de Fedora Linux, OpenSuSE, Mageïa, Frugalware Linux et autres ArchLinux sont une minorité – que de remettre en question une technologie plus confidentielle comme OpenRC 🙂

Mais trève de polémiques stériles, attaquons donc le test et récupérons en bon condamné par Hadopipirate… utilisateur d’une technologie à la base de l’internet actuel, à savoir le réseau BitTorrent l’image ISO. J’ai récupéré en bon Gnomiste indécrottable l’image en 64 bits avec Gnome 3.

Après un démarrage d’une bonne quarantaine de secondes, Gnome 3.4 m’a accueilli. J’ai donc lancé l’installateur qui est celui déjà employé auparavant, ce bon vieil Acanonda. Inutile de s’apesantir dessus. Il fait le boulot qu’on lui demande, point barre :]

Au bout d’un grosse grosse vingtaine de minutes (la première capture d’écran annonce 12h05, corrigé un tout petit peu plus tard par le daemon nptd, et celle de fin 14h 28), la distribution est installée, et est prête à l’emploi.

Et fait étrange, alors que l’image Live fait démarrer Gnome-Shell, le premier démarrage se fait en mode restreint, lançant Chromium, outil dont je ne suis pas un super fanatique 🙁

Le mieux étant de montrer la distribution en action.

Plusieurs questions se posent à la fin de ce rapide test : est-ce que la distribution est lente ou est-ce un effet de bord de la virtualisation ? Je sais par expérience que la perte de vitesse entre mon archlinux réelle et une virtualisée doit être au grand maximum de 5%. Idem entre la Viperr 02 virtualisée et celle qui est installée sur mon ordinateur portable.

Pourquoi castrer ainsi l’environnement Gnome ? Si le paquet Gnome Documents n’est pas installé, une de ses dépendances, tracker pour ne pas le nommer – casse l’expérience en rendant l’outil Carnet de contacts inopérants.

Pour l’installation d’un logiciel comme Mozilla Firefox est aussi lente ? Est-ce un effet de la virtualisation aussi ? Et pourquoi dire qu’on est avec les dernières versions de logiciels, alors qu’on propose LibreOffice 3.6.0 (alors que la 3.6.1 est sorti il y a quoi, 15 jours environ),

En juin dernier, je parlais de la Sabayon Linux 9 en disant que l’installation était longue et lourde. Je n’ai cependant pas penser aux additions virtualbox, et j’avoue que cela m’est sorti de l’esprit.

Dommage qu’elles ne soient pas chargées par défaut quand l’installation se fait dans une machine virtuelle. Mais ce n’est qu’un contretemps rapide à résoudre si on aime mettre les mains dans le cambouis 🙂

Je concluerais en disant : j’espère que c’est un effet de la virtualisation, mais que c’est lent… Que c’est lent, mais que c’est lent ! 🙁

6 réflexions sur « Sabayon Linux 10 : une distribution un peu lourde à digérer ? »

  1. non : ce n’est pas un effet de la virtualisation…
    c’est effectivement lourd et lent et le gestionnaire de paquets est du même accabit par rapport à d’autres distribs user-friendly issues des originales (debian/lmde, arch/chakra, par exemple.
    je l’ai installée par 2 fois « en dur » à 1 an d’intervalle et à chaque fois j’ai été un peu déçu. dommage, car elle est vraiment facile à installer et à utiliser.

      1. sur ce coup précis j’ose le sempiternel « la photocopie ne vaut pas l’original »…
        je pense que tout ça provient du fait que le gestionnaire doit cumuler les sur-couches ou bien qu’il ne soit pas bien né.
        mais bon : je reste admiratif du travail fourni et ne me prononce que dans le cadre d’une comparaison avec d’autres.

  2. > 8 secondes de différence, c’est quoi ? Une gorgée de café ou deux ? En prenant un démarrage par jour pour un utilisateur « lambda », ça fait quoi au bout de 365 jours ? 48 minutes gagnées par an, c’est vrai, c’est négligeable au final

    1. Plus c’est rapide plus les utilisateurs seront satisfait
    2. Ça améliore l’image des distributions GNU/Linux
    Donc bon, la vitesse c’est quand même important, même si cette distribution ne vise pas le noob de base…

    > J’ai récupéré en bon Gnomiste indécrottable l’image en 64 bits avec Gnome 3.
    > Et fait étrange, alors que l’image Live fait démarrer Gnome-Shell, le premier démarrage se fait en mode restreint, lançant Chromium, outil dont je ne suis pas un super fanatique
    Tiens, tout le contraire de Linus Torvalds… Utilisateur de Xfce et de Chrome il me semble.

  3. Eh bien moi qui suis ancien utilisateur debian, j’ai migrer vers sabayon à la version 6, depuis rolling release les versions se succèdent sur mon pc desktop sans accro, ni problèmes. Elle est chez moi aussi rapide qu’une debian et extrèmement stable, autant que ma debian stable mais aussi a jour que ma sid donc… oui pour moi elle correspond a l’idée que j’ai de « dernier logiciel » l’exemple de libre office n’est pas criant de retard faudrait pas non plus pousser mémé…

    Rigo et sulfur sont lent et tout autant immonde que la chose qui sert de gestionnaire de paquet sous fedora, rigo tout particulièrement ( ami de fedora vous ne serez pas trop perdu !) par rapport à synaptic en revanche ce fut un choc pour moi et c’est un fait; d’un autre coté je n’utilise jamais d’installation graphique je lui préfère donc equo en terminal qui lui est simple efficace, rapide après un simple classement des serveurs par equo repo mirrorsort sabayon-weekly

    Concernant l’utilisation de mesaGl je suis d’accord avec toi, concernant systemd j’approuve le choix d’attendre encore tout comme certain sous arch partage cet avis qui fait tant de bruit ( toutefois je te rejoint sur le fait contradictoire d’approuver mesa et pas systemd la logique eu voulut de ne mettre ni l’un ni l’autre ou les deux!)

Les commentaires sont fermés.