La nouvelle mouture de l’environnement Wine, dédié à l’exécution des programmes Windows en environnement Linux, apporte une première étape dans la prise en charge de Wayland.
Le serveur graphique, qui prend peu à peu le relai de X.org au sein des distributions, bénéficie ainsi d’un début de support dans Wine 8.4. Il ne s’agit pour l’instant qu’une partie du socle technique, Wine n’étant, en l’état, pas encore capable de fonctionner avec Wayland.
Bien qu’il s’agisse d’une évolution importante, elle n’est pas exploitable, la version 8.4 restant relativement mineure. Elle n’apporte en effet que diverses corrections, ainsi qu’un nettoyage du code pour la gestion des IME (Input method editor).
Si Wine est installé depuis des dépôts, la mise à jour est peut-être déjà disponible, selon la distribution utilisée. Sinon, les binaires sont proposés dans leur dernière version sur le site officiel.
Commentaires (23)
#1
Un peu HS, mais vu que c’est le sujet qui s’en rapproche le plus…
Aujourd’hui, c’est aussi le 25e anniversaire de cURL (ou curl), un petit programme qui est un peu partout dans notre informatique (même sur Mars !). Et pour l’occasion, il sort en version 8.0.0, après être resté plus de 20 ans en versions 7.x.x !
#2
#2.1
J’ai peut être pas compris, mais Je crois qu’il y a un Curl sur Windows : https://curl.se/windows/microsoft.html
(intégré depuis 2017, mais il y a un build séparé)
#3
Wayland… Ce truc nouveau qui a notre époque oublie totalement que l’ancêtre X11 fonctionnait très bien à travers le réseau! C’est quand même ballot de casser un cas d’usage qui reste fréquent et dont l’absence va obliger à tirer un bureau complet à travers un VNC ou autre RDP. Enfin pour ce qui est installé avec un environnement de bureau complet: Les systèmes headless gagnaient notablement en confort d’utilisation avec un X11 frame-buffer léger comme xvfb. A condition de se limiter côté applicatif à des trucs codés sans une tétrachiée de dépendances gnome/kde (nedit, rxvt-unicode… plutôt que des éditeurs/terminaux usuels de DE complets).
J’ai hâte!
#3.1
Ce n’est pas parce que Wayland existe que X org n’existe plus.
Ils n’ont rien “cassé”.
Ils ont répondu au cas où le client et le serveur X étaient tous 2 sur la même machine et allégeant le tout. On était quand même avec une architecture étrange où l’on avait ajouté tout une partie qui permettait d’accélérer les perfs quand on était sur une machine unique tout en gardant une architecture pensée pour le fonctionnement en réseau.
#4
Pour cela et bien d’autres choses (dont un vrai shell), Cygwin rends Windows supportable et a sans doute évité bien des fracassages de PC par des unixiens irrités d’être contraints à bosser sur un sous-OS par une IT biberonnée au clicodrome de Redmond ne sachant rien gérer d’autre en parc!
#5
D’un autre coté, ca s’appelle vivre avec son temps.
UNIX (et implicitement X window system) n’a pas été conçu pour être l’OS d’un PC desktop.
A la base c’est fait pour s’exécuter sur un serveur, avec un accès via des terminaux.
Avoir le combo “Linux+Terminal” sur le même PC Desktop, ca remet en cause la pertinence de X window system.
Utiliser tout le temps X dans les conditions d’un PC Desktop, au motif de faciliter les rares cas d’accès distant, c’est de la surconception (overdesign). Ca serait l’équivalent d’utiliser tout le temps SAMBA/NFS pour écrire sur son propre disque-dur local.
#5.1
Alors, moi j’ai un cas d’usage à part, le support à distance sur Linux pour mon service, avec Mesh Central, qui ne fonctionne qu’avec X :/
#6
Nouveau, nouveau.. Si je prends l’exemple de Fedora, c’est par défaut depuis 2016.
Je suis le premier à qui ça complique de migrer; Xfce n’étant qu’aux prémices du support de Wayland; il y a quand même des gains, ne serait-ce que en sécurité.
Bon anniversaire Curl
#7
yep. Depuis W10 v1803:
https://devblogs.microsoft.com/commandline/windows10v1803/
#8
Vivre avec son temps… et renvoyer à la VT texte. Comment dire???
Les cas d’usage de X11 à travers le réseau (et idéalement via ssh en X11 forwarding) sont très nombreux au contraire. Et Wayland les a hélas totalement négligé.
#8.1
Wayland ne les a pas négligés. Ce n’est pas sa cible qui est le desktop.
Comme je te l’ai déjà répondu, X org existe toujours et peut être installé sans problème si tu en as besoin. Il doit même pouvoir être installé en plus de Wayland.
#9
Bien entendu que les cas d’usage de X à travers le réseau sont nombreux… puisque dès le départ, il est fait exactement pour ça !
Mais plus haut, on te parle d’un cas différent, devenu plus que courant : lorsque le serveur graphique est sur le même ordi que le client (le cas de 100% des ordis individuels, juste en passant…).
Wayland, d’après ce que je lis sur les forums, est fait exactement pour ça. De plus, et c’est un des arguments majeurs qui a poussé à la création de Wayland, X présenterait des failles de sécurité difficilement colmatables.
Sources :
ICI une FAQ très simple sur Wayland. (Lire : en particulier “Pourquoi Wayland est nécessaire ?”)
ICI au chapitre 2, tu verras pourquoi X est bien moins sécurisé que Wayland, notamment pour les applications bancaires, mais pas seulement (c’est un exemple, mais il est très parlant).
#10
Quel noob ce logiciel, les grands éditeurs modernes seraient déjà à la version
328442781-5.Et un changelog lisible, ah làlàlà faut tout leur apprendre !
Ca c’est un vrai changelog !
#11
Fort existe toujours… mais pour combien de temps ? Il y a quand même un risque d’abandon quand Wayland sera définitivement installé et qu’il faudra faire évoluer Xorg.
#12
Heu… oui. c’est le postulat même du projet Wayland.
Wayland: Prioriser le cas d’utilisation “Desktop” (terminal+server sur le même PC) au détriment du cas d’utilisation “terminal distant”.
X Window System: Prioriser le cas d’utilisation “terminal distant” au détriment du cas d’utilisation “Desktop”.
On ne va pas se mentir, si X Window System était si bien que cela pour le cas d’utilisation “Desktop”, il serait utilisé nativement dans Android, IOS ou MacOS.
#13
Pour les mobiles, c’est certes pas le meilleur choix. Pour MacOS, c’est déjà plus discutable.
Puis comme dit plus haut, si Wayland prends le pas sur X11, il y a le risque que ce cas d’usage disparaisse.
AMHA, avec le réseau de plus en plus au coeur des usages, négliger cet aspect est tout sauf une caractéristique de modernité pour Wayland. Entre se centrer sur le desktop et ne pas permettre un usage à travers le réseau, il y avait un juste milieu pour éviter un tel manque.
#14
C’est possible. Mais si ca arrive, c’est aussi que ca correspondra à la demande.
Si l’avenir pour les utilisateurs c’est CSS/Javascript et HTTP/Websocket, il n’y a pas d’intérêt technique à maintenir l’architecture X Window pour les utilisateurs.
Mais je ne doute pas que les admins/supports voudront maintenir X Window pour leur cas d’utilisation personnel. Du moins jusqu’à ce qu’une nouvelle génération considère comme “acceptable” de faire du remote desktop sur un serveur façon RDP.
#15
C’est un peu le problème global d’une génération gâchis (ici de bande passante, idéalement sur un débilophone changé tous les 2 ans) qui en prime se permets de donner des leçons sur le sujet.
#15.1
On est quand même passé sur les réseaux locaux de 10 Mb/s partagés sur un même coaxial à la création de X Window System (en 1984) au Gb/s sur un switch (et même plus). Donc, même pour les
comme moi, il est envisageable de passer un peu plus de données pour faire des accès distants. Même si moi, j’aurais plutôt tendance à accéder à distance par ssh en ligne de commande.
#16
Ton exemple est bien parlant: xwindow a été concu pour une architecture mainframe + terminaux légers (dumb terminals), et qui s’en rapproche le plus actuellement est l’interface web des services en ligne.
En ce qui concerne l’administration, j’ai une vision assez simple: pas d’interface graphique sur un serveur car cela augmente inutilement sa charge, ses bibliothèques donc sa surface d’attaque et cela augmente les problèmes de maintenance. Donc, soit des xterm en ssh, soit des appli qui accèdent en ssh comme gigolo pour les fichiers ou vmm our gérer graphiquement les vm via libvirt.
Du coup, j’utilise les équivalents de vnc quand je dois accéder à l’affichage d’une vm pour son installation par exemple, chose qui esrde toute manière impossible avec xwindows
#17
Voir “ssh -XC toto@machine” pour avoir le meilleur des 2 mondes (X11 forwarding avec compression à la volée). En prime, intégration sans heurts des fenêtres de la machine distante sur le bureau de la machine locale.
Pour une machine headless, ou installer un environnement de bureau complet est superflu (pour rester poli) mais qui peut gagner en confort d’utilisation pour de la configuration/développement à tirer quelques outils graphiques (éditeur, terminaux…) via le réseau, là encore X11 fait un job dont Wayland est incapable à travers une simple connexion ssh si on a installé le minimaliste xvfb.
Faut juste choisir des outils fait par des gens qui savent encore largement se contenter des dépendances d’un système basique (cad pas grand chose au delà de la libc), excluant donc largement ceux de Gnome/KDE qui ont le don de tirer des dépendances proches d’un bureau complet pour un simple éditeur. Bref, plutôt un nedit/rxvt-unicode qu’un gedit/gnome-terminal.
#18
Encore un qui a pu jouer à retirer les bouchons! Un truc que les moins de 50 ans ne peuvent pas connaître…