Ubuntu 21.04, alias Hirsute Hippo, est disponible en bêta
Le 02 avril 2021 à 07h36
2 min
Logiciel
Logiciel
À quelques semaines de l’arrivée de sa nouvelle Ubuntu, Canonical en publie la bêta, ainsi que celle des variantes officielles : Kubuntu, Lubuntu, Ubuntu Budgie, UbuntuKylin, Ubuntu MATE, Ubuntu Studio et Xubuntu.
D’un point de vue technique, Ubuntu fait un bond en avant. Hirsute Hippo est ainsi propulsée par un noyau Linux 5.11 (comme dans Fedora 34) et signe surtout le passage à Wayland par défaut pour les sessions utilisateur. Comme dans toutes les distributions Linux qui l’ont adopté, X.org reste présent en solution de secours.
Canonical s’est montré particulièrement frileux sur le sujet, l’éditeur répétant avec les années qu’il fallait s’assurer que toutes les applications fournies et les plus courantes fonctionnaient parfaitement avec Wayland, ce qui n’était pas le cas de certains logiciels.
Contrairement à Fedora toutefois, Ubuntu ne plonge pas encore dans GNOME 40 et reste ainsi sur GNOME 3.38. La raison officielle est que la nouvelle mouture est bien trop récente et qu’il faut attendre les inévitables correctifs liés à la maturité. Officieusement, on peut se demander si Canonical n’a pas souhaité éviter un trop plein de changements aux utilisateurs, qui pourraient déjà rencontrer des incompatibilités avec Wayland.
Parmi les autres nouveautés, on note l’arrivée de Mesa 21.0 et donc des derniers pilotes graphiques open source, GCC 10 comme compilateur par défaut, l’intégration de XWayland ou encore l’activation des LTO (link-time optimizations), qui permettent une augmentation générale des performances dans le système.
Le 02 avril 2021 à 07h36
Commentaires (10)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 02/04/2021 à 08h07
Il est même déjà packagé et distribué sur la version 33 de Fedora.
Le 02/04/2021 à 10h00
Ma méconnaissance totale de Wayland me fait poser la question:
Est-ce que c’est toujours aussi facile de se connecter en remote à une application GUI par un ssh -X ?
Pasque oui, X11 c’est une usine à gaz, mais pouvoir le tunneliser par SSH c’est quand-même pratique…
Le 02/04/2021 à 12h39
Très bien, j’irai donc tester afin de voir s’il y a eu des améliorations sur le support multi-écran multi-DPI.
Le 02/04/2021 à 18h04
Non. Wayland et X ne sont pas le même type de truc, même si au final l’un peu remplacer l’autre.
X est un protocole. Un protocole permettant de faire transiter des messages entre un serveur d’affichage et des clients (appli). Ces messages peuvent passer à travers une connexion réseau… ou pas. On s’en fiche tant que les messages transitent. C’est la fameuse “network transparency”.
Wayland une spécification. La spécification d’un serveur d’affichage “local”. Le lien entre client (appli) et serveur passe par une bonne vieille API. Donc, par nature, ce n’est pas routable de manière transparente.
pour faire de l’affichage distant avec Wayland:
choix 1: utiliser un module d’affichage (compositor) dédié, genre “wayvnc”.
choix 2: faire tourner un serveur X en tant que client (appli) wayland, et faire du ssh -X comme d’hab.
Le 02/04/2021 à 22h33
J’ai envie de dire que ça dépend de l’API ; si elle passe par un appel réseau (même local genre socket Unix) ça peut donc être “routable” vers une autre machine ; enfin si j’ai bien compris ce que tu as décrit.
De quelle manière un client Wayland (un processus) communique avec le serveur d’affichage (un autre processus) ?
Merci pour l’info.
(c’est marrant de voir un commentateur “127.0.0.1” répondre à un autre “33A20158-…”, les machines parlent aux machines ;-) ).
Le 03/04/2021 à 14h35
Le 03/04/2021 à 18h45
Oui, mais malheureusement je ne peux pas la partager, car je l’ai écrite pour distribution interne à la société, pendant le temps de travail :-(
En gros, une application graphique X11 exploite une variable d’environnement nommée DISPLAY qui donne le port où se connecter pour parler avec le serveur d’affichage X11.
En pratique ce que je fais, c’est que je lance localement sur mon Windows un serveur X11 (j’utilse MobaXTerm) puis via un terminal je me connecte en SSH vers ma machine Linux distante. Il ne me reste plus qu’à faire un export DISPLAY=192.168.1.23:0.0 (à changer selon ta config évidemment). Lorsque maintenant, via ce terminal je lance une commade graphique comme git gui ou gitk, la commande tourne sur mon Linux distant, mais l’affichage se fait sur mon Windows local…
Attention que ce n’est pas une “prise de contrôle à distance” comme on le ferait avec VNC ou Remote Desktop ! Notamment, tu ne verras pas le bureau, ou le dock.
Le 03/04/2021 à 14h37
Tu as raison. D’ailleurs Wayland se définit lui meme comme un protocole entre un client et un compositor donc ca aurait pu être pensé pour être routable. Je trouve le terme “protocole” un peu trompeur pour Wayland car ce n’est pas du tout comparable au protocole X.
Je vais tenter une analogie:
Les clients X envoient chacun un fichier HTML. Le serveur X fait le rendu de chaque HTML (rendering) sous forme d’une grosse image bitmap. Puis le serveur X affiche chaque bitmap dans une fenêtre distincte à l’écran (composition).
Les clients Wayland envoient chacun un bitmap (rendering). Le compositeur Wayland affiche chaque bitmap dans une fenêtre distincte à l’écran (composition).
Bref, avec X, c’est le serveur qui fait le travail de “rendering” et de “composition”. Alors qu’avec Wayland, le client fait le “rendering” et le serveur fait seulement la “composition”.
Avec cet analogie, on comprend mieux pourquoi c’est plus simple de router avec X: par nature les clients X gèrent des messages qui sont indépendants du rendering.
On comprend aussi pourquoi Wayland est plus “puissant”: le client Wayland a un contrôle total de son propre rendering, il n’est donc pas limité par les possibilités du “langage” X ou du serveur X.
https://wayland.freedesktop.org/docs/html/ch01.html
Le 03/04/2021 à 15h00
Merci de ces explications. J’ai dû les lire il y a des années et j’ai un peu lâché l’affaire depuis, j’ai quasiment tout oublié côté Wayland et autre Mir.
Le 04/04/2021 à 14h45
Bon, j’ai un peu regardé les docs. Il semble clair que le client Wayland doit être en mesure de “partager” un framebuffer avec le serveur. Il semble donc acquis que les deux doivent résider sur la même machine, ce partage ne peut pas se faire via un transfert réseau.
Donc si un client supporte à la fois le protocole Wayland et le protocole X, je suis sauvé. Si un client n’implémente que Wayland, il va falloir louvoyer.
https://wayland.freedesktop.org/faq.html#heading_toc_j_8