e-node blog

Nous avons déjà abordé à plusieurs reprises l’aspect graphique de la séquence de démarrage, mais nous allons nous maintenant nous intéresser plus particulièrement à un nouvel élément de cette chaîne de chargement : Xplash ; qui est le résultat du travail des développeurs de Caconical. En effet les grosses nouveautés d’Ubuntu 9,10 se concentrent principalement sur la séquence de démarrage. On va donc avoir droit à un chargement totalement refondu. Avec l’Alpha 5 toute la structure est déjà en place, avec dans l’ordre de démarrage :

• Grub 2
• Upstart 0.6
• Xsplash
• Gdm 2.26

Les alpha testeurs ont déjà découvert le nouveau grub et le nouveau GDM. Toutefois Xsplash, le remplaçant d’Usplash reste discret, tout autant que l’optimisation d’Upstart censée apporter un meilleur temps de chargement. Sur son blog, Scott James laisse filtrer quelques informations, l’occasion pour nous de faire une petite synthèse.

Les gestionnaires d’écrans de chargement actuels

RHGB – pour RedHat Graphical Boot – est le gestionnaire développé et utilisé par Red Hat – et par Fedora il n’y a encore pas si longtemps. Son fonctionnement consiste à charger un serveur X (serveur graphique) temporaire permettant d’afficher assez tôt l’écran de chargement, avant de repasser la main au serveur X principal une fois le chargement terminé. L’avantage de cette méthode est d’avoir rapidement un écran de chargement actif, mais charger et recharger l’écran a l’importunité de provoquer des sauts d’affichage désagréables …

Pour remplacer RHGB est donc apparu Plymouth, qui a pour objectif d’offrir un chargement plus fluide. Pour cela, les développeurs de Red Hat ont réutilisé comme base de départ Usplash – le gestionnaire de chargement développé par l’équipe d’Ubuntu – et y ont apporté de nombreuses améliorations . Mais si Plymouth est une solution séduisante, son inconvénient est de dépendre de KMS … Or, c’est un mode que peu de pilotes supportent à l’heure actuelle. De plus, le chargement de KMS peu provoquer – dans certains cas – un temps de chargement un peu plus long, ce qui entre en conflit avec l’objectif de réduction du temps de chargement que s’est fixé Canonical.

Usplash, dont nous avons parlé plus haut, offre une réelle simplicité et la possibilité d’afficher un écran de chargement en SVGA. Mais reste cependant limité en terme de possibilités de thèmes applicables et ne gère pas convenablement le chargement du serveur graphique, provoquant des effets de clignotement au démarrage.

La solution : Xsplash

Pour les développeurs d’Ubuntu, aucune de ces solutions ne répondait donc aux objectifs fixés pour Ubuntu 10.04, c’est à dire disposer d’une séquence de chargement rapide et fluide.

Les développeurs ont alors fait évoluer Usplash pour fournir un nouveau gestionnaire de démarrage : Xsplash. Dans le même temps, ils ont réalisés un gros travail sur le temps de chargement des modules prioritaires, tels que le serveur graphique et le montage des disques.

Il est donc tout d’abord prévu de charger le classique Usplash, jusqu’au chargement complet du serveur X. Une fois ce dernier chargé, Xsplash prend la main de la façon la plus transparente possible. Le plus gros du travail consiste donc à initialiser rapidement le serveur X. Pour cela, les développeurs d’Ubuntu disposent d’un gros avantage : Upstart ; un autre programme utilisé pendant le boot qui a pour rôle de charger les différents services du système. Au final le seul inconvénient de cette solution est un petit saut de l’écran entre le passage d’Usplash à Xsplash.

Ce choix technique permet de répondre aux objectifs futurs d’Ubuntu :

• Optimiser au maximum le temps de chargement, sans limitations liées aux modules graphiques.
• Offrir un écran d’identification graphique, pour les utilisateurs qui utiliseront le futur cryptage des partitions
• Faciliter la création d’écrans de chargement plus agréables, avec des thèmes modernes et animés (à partir du moment ou le serveur X sera chargé)
• S’affranchir de la compatibilité des pilotes avec KMS

Le travail est aujourd’hui bien avancé. De bons résultats ont été obtenus sur le temps de chargement du serveur graphique et les dernières versions d’UpStart et d’Xsplash devraient offrir un résultat intéressant pour Ubuntu 9.10, résultat qui sera visible lors du passage à la version bêta d’Ubuntu 9.10.

Il semble donc maintenant clair que Karmic Koala sera un jalon important vers un chargement complet du système en 10 seconde.

Une des grandes nouveautés des toutes dernières versions du noyau Linux, c’est l’inclusion du procédé KMS.

Ce procédé est souvent présenté comme le Saint-Graal du démarrage sous Linux.
LE « machin » qui va permettre un démarrage au moins aussi rapide que l’éclair, qui va empêcher les trucs, permettre de faire des bidules et qui, comble du bonheur, va rendre possible la création d’animations de démarrage si jolies, que même tata Michu va abandonner Windows Live Messenger pour passer à GNU/Linux !
Vous l’aurez compris, KMS c’est la révolution, la chose que tout le monde attendait, même si au fond, personne ne sait ce que c’est …

Alors KMS? qu’est-ce que c’est ?

KMS est l’abréviation de Kernel-based mode-setting (aussi appelé plus simplement mode-setting), ce qui signifie Mode de Gestion basé sur le Noyau. Pour être plus clair, on peut dire que c’est un procédé qui permet de gérer l’affichage directement via le noyau Linux.

Historiquement, c’est le noyau Linux qui gère le pilote graphique lors du boot, jusqu’à ce que le serveur X se lance et prenne les choses en mains. Ce fonctionnement n’est que peu optimisé, puisque le pilote est chargé deux fois et que deux éléments distincts le prennent en charge …
Avec KMS, c’est uniquement le noyau qui gère le pilote. Ceci permet de lancer des services graphiques – tel que l’outil de boot graphique plymouth – dès la phase de démarrage de l’ordinateur, indépendamment du serveur X. De plus, comme le pilote graphique n’est plus géré que par le noyau, les transitions entre les différents services d’affichage se font de façon fluide, presque imperceptible.

Mais concrètement, ça fait quoi ?

Vous l’avez compris, la gestion des pilotes graphiques par le noyau change radicalement la façon de gérer l’affichage. Au delà d’une simplification et d’un allègement des services, de nombreux avantages seront directement perceptibles pour l’utilisateur :

• L’image ne « sautera » plus lors de la phase de démarrage de l’ordinateur ou en cas de changement d’utilisateur.
• La mise en veille du matériel sera bien meilleure, car indépendante du BIOS (dont les spécifications sont la plupart du temps tenues secrètes, ce qui complique la tâche des développeurs du noyau Linux et du serveur graphique X.Org).
• L’interface graphique est conservée et ce même en cas de plantage du serveur graphique X.Org. Ceci permettra une expérience de déboguage améliorée par l’affichage graphique des messages d’erreur et facilitera donc le travail des développeurs (nda. enfin le « blue screen of the death » sur nottre bon vieux GNU/Linux !)
• Le serveur X n’a plus à gérer le pilote et peut enfin tourner sans les privilèges root pour se concentrer sur l’affichage (procédé NRX pour « No-Root X »), ce qui accroit sensiblement la sécurité.
• L’amélioration (à venir) du terminal virtuel.

Mais qu’est-ce qu’on attend ?!

Le problème avec KMS, c’est qu’il faut recoder tous les pilotes des cartes graphiques pour qu’ils prennent en charge ce nouveau mode d’affichage.

Pour les pilotes intel ou les autres drivers libres : aucun problème ; la société Intel et la communauté s’occupent de modifier le code pour rendre possible l’utilisation de KMS.
Pour les pilotes propriétaires, c’est une autre paire de manche … En effet, seules les sociétés éditrices de ces pilotes peuvent modifier leur code pour baser l’affichage sur le noyau. Au jour d’aujourd’hui, Nvidia n’a toujours pas communiqué sur ce sujet – et ne semble pas disposé à le faire NVidia a déjà pris sa décision et n’implémentera pas KMS dans ses pilotes pour des raisons de licence ; la seule lueur d’espoir semble donc émaner du pilote libre NouVeau qui a encore bien du chemin à faire … De l’autre côté, les développeurs d’AMD commencent tout juste à travailler à implémentation de KMS.

Cela dit, les chanceux qui possèdent un chipset graphique Intel ou une carte graphique bien gérée par le driver Radeon, auront toute de même la joie de découvrir KMS avec la future version d’Ubuntu !

Pour conclure

Finalement, KMS n’est qu’un retour à la normalité … En effet, depuis toujours, tous les pilotes sont gérés par le noyau Linux, seul le pilote graphique faisait exception. C’est donc la fin de cette « aberration » et le pilote est enfin géré par le noyau, ce qui aurait dû être fait depuis le début …

Mais bon, comme dit le proverbe « Mieux vaut tard que jamais » …

Canonical vient de dévoiler les premiers mockups officiels de la futur séquence de boot. ils s’inspirent en partie des propositions réalisés par certains membres, signe que l’équipe reste à l’écoute de la communauté. Ces premiers mockups ne sont pas définitifs et devraient continuer à évoluer en réponse aux suggestions de la communauté.

Vous pouvez suivre l’évolution du projet officiel ici.

Mat Tomaszewski, un des membres actifs de l’équipe responsable de l’expérience utilisateur pour Canonical, vient de publier un message pour rappeler la fermeture prochaine des appels à participation pour le thème de la séquence de boot.

Cet appel à participation à porté ses fruits, avec quelques idées très intéressantes et le développement officiel de la nouvelle séquence de démarrage devrait rapidement faire écho à ces proposition. Ce thème s’inspirera très probablement des maquettes de la communauté et sera réalisé en tenant compte des exigences suivantes :

• Remplacer la barre de progression par une animation.
• Utiliser un effet de fondu lumineux pour donner une impression de continuité entre l’écran noire d’initialisation et le thème.
• Utilisation du Logo et de la marque Ubuntu.

Aucune date exacte n’a été donnée, mais il semble bien que cette nouvelle séquence de boot « sexy » sera une des grosses nouveautés de Karmic Koala.

A suivre donc…

Avec l’Alpha 2 de Karmic Koala, le tant attendu GRUB 2 est arrivé.

En tant que remplaçant du bon vieux GRUB 1 (dixit GRUB Legacy), il permettra de nombreuses améliorations techniques et offrira une meilleure compatibilité avec les ordinateurs récents.

De belles promesses en perspective !

Pour le moment, sous Ubuntu, Grub 2 ressemble à ceci :

Ce n’est ni plus ni moins que la version de base (non-personnalisée) de GRUB 2 et comme nous l’explique nizarus sur son blog, il est possible de le personnaliser pour le rendre plus agréable.

Bien entendu, l’équipe d’Ubuntu ne compte pas garder cette version basique, mais souhaite y apporter des améliorations significatives, et ainsi respecter la parole du « grand Mark » (Mark Shuttleworth, directeur de Canonical) qui nous a annoncé un boot « sexy ».

Au menu des réjouissances nous avons :
- La disparition du menu du GRUB, qui passera en mode « silencieux » et n’apparaîtra que sur demande de l’utilisateur, via un raccourci clavier.
- La possibilité de crypter les disques, de manière efficace et totale, via KMS, avec une gestion transparente pour l’utilisateur.
- L’arrivée d’un thème uniforme pour le chargement de l’OS : du GRUB jusqu’au GDM. Ceci grâce au travail fait sur le temps de boot qui devrait permettre d’avoir un serveur X totalement opérationnel au bout de 3 seconde ( sur un Dell mini 9)

Des propositions intéressantes …

Le thème fait actuellement l’objet d’un travail graphique, auquel il est possible de participer en faisant des propositions qui pourront inspirer l’équipe chargée de ce thème (à voir ici)

Il est possible de visionner une maquette de chargement sur youtube :
Grub 2 avec ubuntu 9.10

Image d’une des maquettes :

Cet Artwork n’est qu’une proposition, mais il donne un aperçu de ce qu’il est possible de faire avec le nouvel ensemble d’initialisation de l’ordinateur. La vidéo montre un boot de 15 seconde, ce qui s’approche du temps visé pour les futures version d’Ubuntu.