Tarnyko a écrit 490 commentaires

Wayland et Gnome (3): Des projets un peu dogmatiques à mon goût et qui n'écoutent qu'eux mêmes… Au final, d'autres ayant des compétences sur les sujets qui fâchent font Cinnamon et waypipe, certes, mais ces attitudes n'aident pas le libre.

Assez d'accord sur GNOME ;-).
Mais en réalité le concepteur de Wayland (Kristian Høgsberg) avait fourni un PoC équivalent à Waypipe. C'est juste que la fonctionnalité était jugée "non-core" (l'objectif de Wayland était orthogonal) et n'intéressait pas de développeurs assez qualifiés pour la finaliser… jusqu'à maintenant.

Tout comme conchier X: Je préfère un truc qui marche à travers le réseau que gagner des FPS au jeu, même si les deux ce serait l'idéal.

L'écosystème Linux moderne (entre l'embarqué, les designers, les gamers/Steam/Valve…) , s'est clairement déplacé du premier besoin vers le second.
Personnellement, ça ne me choque pas qu'on considère que l'objectif d'un serveur d'affichage est… d'"afficher au mieux", le réseau étant une fonction annexe.
L'intérêt d'X aujourd'hui est historique, et consiste surtout à conserver la compatibilité avec les vieilles applications et OS legacy (les BSD notamment).

Une petite vidéo de MATE tournant sur PinePhone .

waypipe serait typiquement une brique (centrale) d'une solution type x2go.
Il serait même possible de détecter automatiquement le protocole (X11 ou Wayland) en fonction de la présence/absence de sockets et variables d'environnment.

Intéressant. Là je tourne à la mémoire, et manque honnêtement de maîtrise récente du sujet (= il n'est pas impossible que tu aies raison). Il faudrait aussi que je fasse des benches pour comparer tout ça.

• True 64 Unix sur station alpha
• des vieille machine DEC dépassée avec écran Monochrome
• quelques stations PC/GUN/Linux sous redhat (je crois)

Wow ! On est bien loin de Wayland avec du matos de cet âge (ça démarre à RHEL 8).

Sur un tel parc, non seulement le forwarding X11 c'est le plus logique, mais sûrement tout ce qui est disponible aussi (j'imagine pas les versions modernes de freerdp, Xvnc… compiler sans patch sur DEC ou Tru64). Et pis, pas trop de contraintes de bande passante non plus sur un tel LAN.

waypipe permettra sûrement une migration sans douleur dans, disons, dix ans :-).

Se baser sur une expérience perso pour déterminer ce que les autres font, et décréter que ça sert à rien n'est pas une bonne idée.

Mais si ! C'est comme couper un serveur quand on te demande s'il sert encore : ça génère des appels, et après tu sais ;-).

Ensuite il y a les usages ludiques sur les écrans des collègues sans leur permission évidemment

Ca sent le xhost + lancé plus que de raison ça ;-).

Vous êtes sous quelles versions de distributions (à la louche, comme ça) ?

J'ai utilisé XFCE pendant deux ans avant de passer sous GNOME 2/MATE.

Je dirais qu'alors que XFCE fournit juste la base d'un bureau, avec peu d'outils basiques qui sont à compléter par d'autres pris ailleurs ; MATE a l'ambition de fournir un bureau complet et "auto-contenu".

Cas typique : l'éditeur de texte. Sous XFCE c'est "mousepad", et il se contente d'afficher du texte avec éventuellement la coloration syntaxique. Sous MATE c'est "pluma", et il le fait aussi; mais supporte les plugins, la correction orthographique, les macros…

Autre cas : la visionneuse PDF, le gestionnaire d'archives ZIP… XFCE ne propose rien de tout ça (tu vas donc installer p.ex. "Xpdf" et "P7ZIP") mais MATE propose "atril" et "engrampa" qui, bien que moins avancés que les 2 précédents, sont cohérents dans leur look et font le job dans 90% des cas.

En résumé : XFCE c'est Windows 98. MATE c'est Windows 98 avec des freewares ;-).

Détails sur la transparence X11/GL .

En gros, ça ne fonctionne out-of-the-box qu'avec OpenGL 1.0 (mode soft) ou des drivers graphiques parfaitement aligés (mode hard). La faute à l'absence de gestion du mécanisme des extensions OpenGL par le code historique.
Pour de véritables applis utilisant OpenGL 2.x+, il faut installer p.ex. VirtualGL qui va rajouter sa couche d'abstraction ; c'était le fameux "autre outil" dont j'avais oublié le nom.

Apparemment, même si ce n'est pas automatisé, la possibilité existerait :

It's possible to set up the local and remote processes so that, when the connection between the the sockets used by each end breaks, one can create a new forwarded socket on the remote side and reconnect the two processes. For a more detailed example, see the man page.

La formulation est un peu ambigue ; mais oui ce serait vraiment sympathique de retrouver sa fenêtre à partir d'un autre poste ! Il faut une petite infra quand même pour tester (deux machines avec Wayland en plus du "serveur") ; je regarde ça à l'occasion.

Excellente question :).
Alors, en n'oubliant pas que c'est basé sur le mode de transport choisi (ici, SSH); voici après avoir coupé la connexion :

La wl_shell_surface cesse de répondre au "ping" et le compositeur affiche donc le sablier. Ca reste comme ça pendant 15 secondes; je rétablis et après encore 10 secondes:

Je ne sais pas jusqu'à combien ça "tient" (je dirais : autant que la capacité de SSH à se reconnecter en mode texte selon le paramétrage) mais ça tourne !

Il y a méprise :). Ce que je voulais dire, c'est que le forwarding "à poil" tel qu'expliqué dans les tutos n'est quasi-jamais utilisé. Ou plutôt si, mais pas tout seul.
Dans ma capture, il y a un lecteur vidéo, mais on n'entend pas le son; il faudrait créer un pipe PulseAudio.
Si je fais "Fichier"-"Ouvrir", je vois les répertoires du poste distant, mais pas les miens; il faudrait monter un sshFS distant et me positionner automatiquement dessus.
Etc…
waypipe est super-utile, mais en tant que "brique" d'un système plus complexe, un serveur d'application avec une interface de gestion et une DB d'utilisateurs. Un Terminal Server effectivement.

La vanne sur X11 vient surtout de sa lourdeur de base (pas de compression !) et qu'il faut installer plein d'autres outils pour avoir un vrai truc, genre la 3D que propose simplement waypipe avec DMABUF.

En fait, la principale conséquence de ça, c’est : si tu mets à jour l’outil sur une machine, il faut le mettre à jour partout.

J’ai posé la question à l’auteur de savoir si un versionnage de son protocole pourrait résoudre 90 % du problème, et si oui ce qui s’y oppose (j’attends la réponse).

Merci de ta réponse très détaillée !
Donc Mir est le serveur d'affichage choisi par MATE pour fournir le protocole Wayland -une fois que le taf sera complet.
C'est un choix original et j'imagine une manière de capitaliser le travail fait sur Mir, devenu moins visible une fois qu'il a échoué à imposer son propre protocole -la plupart des autres "petits" projets utilisent libweston ou wlroots.

Je me demande quelle est encore la "base installée" de MATE.
Avec le passage à GTK+3, il a perdu beaucoup de son originalité ; de plus lagge beaucoup derrière avec des dépendances vintage (notamment X11).
Je suppute une base "entreprise", qui sera contente que ça "juste marche" mais n'ira pas jusqu'à faire de l'évangélisme.

(PS : la phrase "support de Wayland via Mir" est un mystère pour moi, non pas technique mais sur les motifs -pourquoi ? Quelqu'un en sait plus ?)

The offline installer will also become commercial-only. We found that this feature adds utility on a company-wide level, which allows us to make commercial licenses more attractive to enterprises without significantly inconveniencing open-source users.

L'installeur hors-ligne, il est surtout utile pour les utilisateurs Windows/macOS qui se contentent de "consommer" le toolkit et veulent pouvoir dire à leur boss : "Bien sûr, j'utilise la version officielle".

Les autres, même sur ces OS, peuvent très bien compiler et maintenir une version eux-mêms.

Ca ne me choque pas, pas plus que la plus plus-contraignante restriction LTS (dont, sous Linux, on s'est toujours bien passé). Qt est très utilisé, mais la boîte ne s'y retrouve pas toujours -certains grands comptes veulent le beurre et l'argent du beurre en exploitant les libertés OSS.

Haha :).
Exactement (d'où le choix de Borland C également comme environnement de dév.: présence du plugin kivabien, toussa).
Après c'est chez un client que je ne vois plus; j'ignore comment ils ont maintenu/remplacé la bête, à l'époque on était déjà plus qu'en fin de vie -avec p.ex. une carte ISA sans spare.

Ah ben ça c'est clair :D.
Un sys. embarqué x86 basé sur FreeDOS, j'en ai plus vu depuis 12 ans (un vieux monstre industriel avec de l'IPX, des cartes ISA et un connecteur Paradox). Et il utilisait pas DJGPP mais plutôt Borland-truc, ce qui fait de toi mon seul utilisateur DJGPP connu. Chapeau bas ;).

Pour quelle finalité, si je peux demander ?

est-ce que vous avez connaissance de cas d'utilisation concret, ayant abouti à la réalisation, voire la commercialisation d'un produit, avec un OS construit avec Yocto ?

Tizen.

Buildroot, c'est avec un bon vieil /etc/inittab des familles, et c'est sans systemd !!!

Tu peux te passer de systemd avec Yocto aussi.

Après, je ne prétends pas que cela soit facile.
La manière dont je vois les choses est : Yocto est plus configurable, plus connu (=vendable) dans l'industrie. Buildroot est plus léger, plus simple d'usage pour des petits projets.

Quel était le souci avec MATE ? (sachant qu'il est en GTK3 depuis un certain temps déjà)

Je prédis un grand avenir à cette extension ; elle est déjà installée sur 4 postes et je ne vois pas la tendance s'inverser :).

J'en ai fait une version Chromium; rien de fou, je me suis contenté d'y ajouter le wrapper PolyFill. Penses-tu que ça vaille le coup d'un pull request, ou … ?

Intéressant.
Je viens d'essayer la dernière version, présentée comme étant compatible FF56 ; mais les menus déroulants restent désespérement vides (testé avec Win7+IE8, Win7+IE10).
Tu sais quelle version de FF il faut ?

La Traban des OS.
C'est éprouvé, prévisible. Pour peu de dénicher les bonnes pièces, ça fonctionne encore aujourd'hui.
T'en voudrais juste pas une nouvelle ;).

Je viens de mettre l'image, ça mérite bien sûr un nouveau commentaire ;) .

As-tu des exemples existants en tête ?

En legacy: Le plugin Chrome Frame pour IE (obsolète), permettait de switcher la vue d'Internet Explorer, du moteur Microsoft Trident vers Blink.

En actuel: non, absolument pas. C'est justement pour ça qu'il y a une carte à jouer pour vous ;-).