nud a écrit 977 commentaires

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

Oui mais on pouvait pas comparer ses stats en temps réel aussi facilement.

Sauf que ça reste assez lourd à utiliser, le terminal vit souvent plus longtemps que l'éditeur de texte, et il n'y a pas d'onglets dans le terminal de gedit.

Ensuite, le terminal de gedit n'a pas été "pensé", je l'ai juste implémenté pour faire cesser les bug reports, apparemment des gens se servent de ce genre de trucs. (pour ma part je ne me sers que de terminaux externes)

Et que dire des "pros" qui revendent des produits bases sur debian stable et qui vont encore devoir upgrader...

C'est pas vraiment tabless, c'est une espèce d'exposé pour les pages web. C'est pas con quand tu as plein de pages ouvertes, mais c'est probablement pas top quand tu as que deux ou trois onglets.