Publié dans Logiciel

10

Ubuntu 21.04, alias Hirsute Hippo, est disponible en bêta

Ubuntu 21.04, alias Hirsute Hippo, est disponible en bêta

À 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.

10

Tiens, en parlant de ça :

Puce Snapdragon X Plus

Qualcomm dévoile son Snapdragon X Plus et trois variantes du modèle Elite

Plus moins bien

12:29 Hard 5
Un crâne ouvert au sommet sert de piscine à un homme qui se baigne dans une bouée canard, le tout sur fond rouge tirant vers le noir.

Transhumanisme, long-termisme… des idéologies aux racines eugénistes ?

Science artificielle

11:31 IASociété 17
Un ordinateur avec un drapeau pirate sur fond rouge

Corrigée depuis deux ans, une faille Windows activement exploitée par des pirates russes

Faille 1460-days

09:00 Sécu 11
10

Fermer

Commentaires (10)



Hirsute Hippo est ainsi propulsée par un noyau Linux 5.11 (comme dans Fedora 34)




Il est même déjà packagé et distribué sur la version 33 de Fedora.


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…


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.



(reply:1864949:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
Est-ce que c’est toujours aussi facile de se connecter en remote à une application GUI par un ssh -X ?




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.



(quote:1865079:127.0.0.1)
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.




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) ?




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.




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 ;-) ).



(quote:1864949:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
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…
Tu as un tuto pour faire ça ?
Ça m’intéresse beaucoup de pouvoir prendre le contrôle à distance d’une instance Ubuntu distante.



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.



OlivierJ a dit:


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.




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


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.


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