nud a écrit 906 commentaires

Et je ne suis pas le seul à le dire

Ben en fait le lien que tu cites dit exactement cela: au risque de me répéter, le backend wayland va fonctionner out of the box, sauf si on utilise du X11 directement (les appels gdkx11*). Donc si ton appli ne fait pas appel à X11 directement mais n'utilise que l'API Gtk+, ce sera transparent (et c'est le cas pour la plupart des applications Gtk+). Donc tu ne devrais même pas avoir de les applications, surtout que dans gtk+ 3 les backends sont dynamiques.

Les seules API non compatibles sont les APIs qui permettaient d'aller chipoter directement dans les entrailles de X11. C'est normal, et elles ne sont pas accessibles directement sous win32 par exemple...

Les autres mentions sont des bugs du backend Wayland.

Tout à fait, GTK intercepte les messages X11 et les retransmet sous forme d'events

C'est en fait GDK qui fait cela, et les événements sont les mêmes quelle que soit la plateforme. Si la plateforme a des messages différents, Gdk s'occupe de faire la traduction ou le remplissage, comme sous OSX ou Win32.

Et je ne vois pas de quoi tu parles quand tu parles de plugins et de multiplication de "serveurs de messages". La plupart des plugins des applications Gtk+ sont in-process (ce n'était pas forcément le cas avec bonobo mais ça a disparu il y a longtemps) et de toute façon la partie génération/émulation/gestion des messages du système de fenêtrage est géré par Gdk et inaccessible pour l'application. Elle ne verra aucune différence et tu peux d'ailleurs le vérifier dès aujourd'hui avec les applications Gtk+ que krh utilise dans Wayland.

on peut difficilement la rajouter d'office sur toutes les applis GTK qui trainent

Ouvre les yeux. C'est le protocole wayland qui va dire à l'application si oui ou non le compositeur veut que tu dessines tes propres décorations. Si tu n'es pas en wayland, tu ne les dessines pas, point. Et de toute façon, dessiner soi-même les décorations est déjà possible avec X11 même si pas supporté au niveau du protocole.

Après on peut imaginer un serveur RPC qui traine dans un coin et qui gère à la fois la création des messages et les décoration de fenêtres.

Il n'y a pas besoin d'un tel serveur RPC. La création des messages est faite par Wayland, l'émulation des anciens messages X11 pour les widgets virtuels (qui étaient avant des fenêtres X mais n'en sont plus depuis un certain temps) est faite par le toolkit. Les décorations peuvent être faites par le compositeur s'il le souhaite, sinon je suppute que les décorations seront un peu différentes pour chaque toolkit (comme les décorations de chromium sont déjà différentes par ailleurs) mais il est fort possible d'avoir une spécification fd.o pour un thème de décorations.

Mais même les applis codées en GTK ou en QT parfait sont à réécrire. Wayland fait moins de chose que X11, toutes les choses qui ne sont pas faites par Wayland doivent désormais être faites au sein de l'appli. Ca implique nécessairement de revoir tout le code, à moins de vouloir lancer un émulateur X complet avec gestion des inputs + un décorateur de fenêtre qui fait mini-wm avec chaque fenêtre.

Sauf que les choses en question sont normalement gérées par le toolkit. Par exemple, à cette heure, Gtk+ génère des événements "virtuels" pour les "client-side windows", càd pour l'émulation côté client des anciennes fenêtres X. Il y a aussi une branche pour les "client-side decorations"... qui a priori devraient être identiques pour toutes les applications qui utilisent Gtk+ et devraient réutiliser le thème gnome-shell.

Donc, en fait, non. À moins de faire des trucs tordus avec la Xlib directement (ce qui a toujours été découragé), il ne faudra pas toucher les applications Gtk+3. Pas plus que les applications Qt4 par ailleurs.

Ici (Iceweasel 10 sous Debian) cette page ne contient rien... Est-ce censé utiliser WebGL ? Est-ce que WebGL est supposé fonctionner sous linux des temps-ci ?

Bof, c'est une justification foireuse: du même constat tu pourrait dire, faisons X12 qui vire tout le code mort/inutilisé (draw stippled line) mais qui garde XRender.

Faire cela reviendrait au même:

• tu aurais besoin d'un serveur X11 complet quelque part (probablement un X11 rootless comme celui utilisé avec Wayland) pour les applications Motif et autres qui utilisent les fonctionnalités enlevées que "personne" n'utilise;
• tu aurais besoin de mettre à jour tous les toolkits pour t'assurer qu'ils n'utilisent pas de fonctionnalité dépréciée.

Bref, il faudrait toucher toutes les applications. Sauf qu'en plus:

• Tu aurais toujours dans les pieds le vieux code et le vieux design prévus pour des choses qui n'existent plus (les fonctions que tu proposes de supprimer);
• Tu aurais toujours les grosses misfeatures de X11;
• Tu aurais de toute façon un serveur incompatible avec les autres;
• Tu conserverais une partie du protocole X11 (mais pas tout) donc tu serais compatible avec l'existant (mais pas vraiment).

Donc, autant partir d'une feuille blanche:

• On peut faire supprimer les problèmes que l'on connaît avec le design de X11;
• On peut faire quelque chose de plus adapté à l'utilisation actuelle qu'un design datant des années 70/80
• On peut faire plus simple et plus accessibles pour attirer du sang neuf;
• On ne casse au final pas plus la compatibilité qu'avec un protocole X "simplifié" comme énoncé plus haut.

Ceci dit, si on avait baptisé Wayland X12 sans rien changer d'autre, peut-être n'y aurait-il pas eu matière à troll.

Alors plusieurs petites choses:

• Il y aura un serveur X embarqué dans Wayland (un rootless X server), un peu similaire au support X11 dans MacOS je suppose, pour faire tourner des applications X11 comme si elles étaient "natives".
• Les toolkits les plus courants ont déjà le support pour wayland donc y'aura même pas besoin de patcher.

Par contre oui, y'a des applications qui attaquent directement X pour certains trucs, en particulier en Gtk (apparemment la pratique est très rare avec Qt, probablement parce que les gens qui font du Qt s'intéressent davantage à avoir une application portable). Et oui, les drivers X11 propriétaires seront probablement pétés. J'imagine que les drivers propriétaires qui vont directement dans le noyau seront épargnés?

oufti faut le (sa)voir... On peut avoir un truc un peu plus evident?

Tant qu'à faire autant altérer l'interpréteur markdown pour automatiquement modifier les adresses e-mail dans les contenus et commentaires.

Epiphany propose de stocker les mots de passes sans faire usage de ce même M.D.P. principal.

Ce n'est pas tout à fait exact. Epiphany stocke les mots de passes dans le keyring de Gnome, qui est déverrouillé automatiquement lors du login, via PAM. Ceci ne fonctionne évidemment que si le mot de passe de session et le mot de passe du keyring sont identiques.

Dans un autre cas, ou si tu récupères le fichier login.keyring et le mets sur une autre machine, tu auras besoin de ton mot de passe originel pour le déverrouiller.

Moi ça m'a pas fait rire. Quelqu'un peut expliquer?

Depuis que je suis passé à Linux, j'ai l'œil brillant et le poil lisse!

Oui bon ça dépend du but poursuivi aussi.

Ne peut-on pas exporter du contenu du vrai linuxfr (par exemple les dix dernières dépèches, les 20 derniers journaux, etc) en anonymisant les comptes des gens et supprimant les données non publiées sur le site (karma, etc) ?

La graine (seed) c'est le nombre que tu utilises pour initialiser ton générateur de nombres pseudo-aléatoires. Souvent on initialise avec time() pour avoir quelque chose qui a l'air réellement aléatoire, mais utiliser toujours la même graine peut servir à reproduire la même suite de nombres, par exemple pour la génération automatique de niveaux d'un jeu.

Le salage (salt) c'est une valeur que tu introduis dans ton hashage pour faire en sorte que hasher deux fois la même valeur ne produise pas le même résultat. Comme ça si dix utilisateurs ont comme mot de passe "linuxfr", la base de données stockera des valeurs différentes. Craquer un mot de passe évite alors de craquer les autres en une fois.

ce trou existe avec l'extension.

Qu'est-ce qui empêcherait un attaquant potentiel d'installer sa propre extension pour afficher les mots de passe ?

À part entière!

ça se contrôle en cli par la commande « nm ».

Euh, tu ne confondrais pas avec le nm(1) de binutils des fois ?

NAME
       nm - list symbols from object files

DESCRIPTION
       GNU nm lists the symbols from object files objfile....  If no object files are listed as arguments, nm assumes the file a.out.

Pour moi tous les problèmes "pratiques" semblent limités à Network Manager, qui est bien pratique sur un PC de bureau mais reste très limité quand on sort du tout venant. D'un autre côté, je doute qu'il soit nécessaire de se taper Network Manager sur un serveur comme le monsieur semble dire.

La différence c'est que dans le cas présent, l'historique avant la mise sous licence apache concerne un contenu propriétaire sur lequel les droits n'ont pas été cédés (on ne sait pas ce que contient l'historique en question). Le fait que l'historique commence avec un "first commit" correspondant au code libéré.

Le cas de red hat est ici différent vu que le "big patch" correspond à des modifications sur du code libre.

Je suis content, mes seuls mots de passes souvent utilisés sont '1234' et '0000', aka "les mots de passes bidon pour les comptes de développement sur les VM".

Ça serait sympa d'avoir le même pour gnome-keyring (et accessoirement d'avoir un moyen de stocker les mots de passes de firefox dans gnome-keyring)

Une annonce relative à un logiciel sans avoir de screenshot ça donne toujours comme un goût de trop peu.

"langue" étant un mot féminin, tu aurais dû terminer par "compliquée". À moins d'une exception bien sûr.

Quel est l'avantage de XUL sur GtkBuilder ou QML si c'est pour faire une application en C++ à 100% ?

Quel est l'intérêt d'utiliser xulrunner ci c'est pour coder l'intégralité de l'application en C++ ?

En fait j'ai l'impression que le position: fixed n'est supporté que quand on a ceci:

<meta name="viewport" content="width=device-width" />

Ça implique une modification assez agressive de la CSS pour que linuxfr puisse être consulté sans zoom (grosso merdo il faut que le site passe sur une largeur de 320px).