nud a écrit 898 commentaires

Surtout que Baldur's Gate (en tout cas le 2) fonctionnait nativement sous Linux.

Merci pour ta réaction.

Je suis d'accord que le problème est aussi au niveau du navigateur. Cependant tous les navigateurs utilisent les mêmes polices par défaut donc le problème se pose partout. En pratique rare sont les gens qui changent les polices par défaut du navigateur, ne fut-ce que parce que changer ces polices et leur taille rend illisible la moitié du web. Enfin en fait je crois que le bug est surtout dans la police, qui aurait pu faire de meilleurs choix au niveau du hinting.

Concernant la justification technique, juge par toi-même en affichant l'image suivante à sa taille réelle (en haut, DejaVu, et en bas, Open Sans):

Le problème se situe à certains points où la police "saute", donc oui si tu zoomes à 300% ta police sera parfaite. C'est généralement dérangeant uniquement au moment du "saut", pas pour des tailles plus grandes. Evidemment, le saut en question se trouve à l'endroit dérangeant, sinon ce ne serait pas drôle. Et le problème est bien lié au hinting, comme l'atteste le bout de screenshot en haut à droite, avec hinting désactivé (oui c'est une solution mais ça rend le texte bien moins lisible également, le texte est flou). Et bon, je ne suis pas sous Windows, mais sous Linux, avec Iceweasel (Firefox) 24.3.

Pour le contournement si la demande est implémentée, il est encore plus simple pour l'utilisateur avisé que le changement de police: il suffit de désactiver la possibilité pour les sites d'utiliser leur propre police, et en plus ça prendra effet pour tous les sites qui utilisent le même procédé (et les mêmes polices que celles proposées). De toute façon il s'agit évidemment au final d'une décision à vocation esthétique.

Notez bien que je n'émets pas d'avis particulier sur la police à utiliser, il est tout à fait envisageable d'en discuter. "Open Sans" me semble néanmoins un bon candidat vu sa popularité, et c'est pour cela que je l'ai utilisée dans la capture d'écran de ce commentaire.

Juste pour mentionner dans le contexte de cette entrée du suivi mon journal sur une config ansible pour créer une machine virtuelle "LinuxFR", et le dépôt git associé:

• Toi aussi installe ton propre linuxfr en trois lignes de bash… et contribue!
• Dépôt git

Apparemment on pouvait utiliser un disque luks sous windows avec FreeOTFE, mais ça a plus l'air trop maintenu (le domaine a l'air d'avoir disparu) et ça ne résoud pas le problème de l'ext3.

Tu devrais faire un patch plutôt que de donner un fichier css, car sinon la maintenance est impossible.

En plus les fichiers SCSS sont bien faits, il est probable que tu puisses tout simplement redéfinir les variables de couleurs et importer le style "parent". C'est ce qui est fait pour les différentes couleurs de RonRonnement. Voici RonRonnenent-Vert.css.scss pour l'exemple:

@charset "UTF-8";

$C_CLAIR: #E9E6E4;
$C_BANDEAU: #96BD0D !default;
$C_FONCE: #93877B;
$C_INTER: #93877B;
$C_BAS_FOND: #E4E4E4;
$C_FOOT: #D4D1CF;
$C_MIBLANC_MIFOOT: #E9E8E7;
$C_CONTAINER: #F9F9F9;
$C_MENU: #4C575F;

$C_BD1: transparentize($C_BANDEAU, 0.84);
$C_BD2: transparentize($C_BANDEAU, 0.67);
$C_BD3: transparentize($C_BANDEAU, 0.50);
$C_BD4: transparentize($C_BANDEAU, 0.33);
$C_BD5: transparentize($C_BANDEAU, 0.17);

@import '../RonRonnement';

Il est aussi possible de rajouter des bouts de CSS pour "recouvrir" les déclarations existantes. Ça fait des fichiers beaucoup plus courts et simples à maintenir.

Certes, mais ça implique de modifier la config de l'environnement de développement du dépôt linuxfr.org, qui utilise dlfp.lo, et je voulais éviter autant que possible toute déviation par rapport au dlfp officiel…

Et ma connaissance de ruby et de rails étant inexistante, je ne sais pas comment faire pour avoir une config dynamique qui n'imposerait pas la modification "par machine" d'un fichier suivi dans le git (le but est quand même de faciliter le développement donc il faut que le dépôt soit propre).

Ça veut dire aussi: patches accepted pour ceux qui savent comment faire :-) Une étape en moins dans la todo ça serait génial.

Les études sont plutôt exprimée en termes de nombre de caractères, pas en pixels. En voici une pour l'exemple.

Les 1350px ne sont pas une vérité absolue, ça s'appelle un compromis.

Zenitram, juste une petite question personnelle: qu'utilises-tu comme écran pour visiter linuxfr ? (taille et résolution)

LinuxFr rentre pour moi (ce qui n'a aucune importance ;-) ) dans la catégorie des sites qui se foutent des indications des utilisateurs

Ce n'est pas vrai, la taille de l'écran n'est pas une indication donnée volontairement par l'utilisateur, c'est juste un état de fait. Et il est également dangereux de considérer que l'avis de la minorité la plus vocale est celui qui est partagé par le plus grand monde. D'autant plus que ici les contre-arguments tendent sur l'idéologie et ne sont pas étayés visiblement par un cas pratique et les données y afférentes.

Je suis limite surpris que personne n'ait rouspété sur les autres changements cosmétiques de la CSS par défaut d'ailleurs.

L'entrée du suivi dit:

Je ne pense pas que le contre-argument souvent évoqué ("on peut naviguer avec une fenêtre qui n'est pas maximisée") ait une valeur parce que les navigateurs à onglets et les bureaux modernes en général (que ce soit gnome 3, kde 4 ou windows 8) ne poussent pas vraiment à l'utilisation de petites fenêtres.

La pratique, c'est qu'à part quelques power users (dont tu fais sans doute partie) s'amusent à avoir des petites fenêtres ou utilisent un gestionnaire de fenêtres à pavage, mais même ici, je suis certain que la majorité des gens utilisent généralement leur navigateur en plein écran.

Aussi, les gens utilisent des onglets, et s'il faut une taille différente pour chaque onglet, c'est ingérable: cela imposerait de redimensionner sa fenêtre en fonction de l'onglet sur lequel on se trouve pour avoir la taille idéale.

Je suis à fond pour une mise en page fluide et adaptative, mais il faut rester pratique.

Mais voila : un écran n'est pas un journal, je peux avoir une plus grosse police de caractères (par exemple).

Actuellement sur linuxfr la taille de la police est fixe. Si on passe à une taille de police relative à la largeur de l'écran (comme sur ce site par exemple) on peut alors imaginer une mise en page 100% fluide (modulo le problème des images).

Mais j'imagine que les gens vont se mettre à rouspéter que la taille des caractère va être trop grosse, bien qu'ils puissent la contrôler en redimensionnant la fenêtre. Ceci dit, les possesseurs d'écrans à haut dpi (genre écran 15'' en 1920x1080) dont je fais partie en seraient sans doute très heureux. C'est d'ailleurs la solution que je suggérais dans l'entrée du suivi :-)

Mais de quoi je me mêle? Si je règle la largeur de mon navigateur à 1000 px, c'est que je veux que le site s'affiche sur 1000 px.

En même temps le max-width est à 1350px, et sous cette largeur le comportement ne change pas d'un poil. Jusqu'à preuve du contraire 1000px c'est inférieur à 1350px.

Grosso modo ça ne concerne que les psychorigides qui possèdent un écran HD.

ça peut d'ailleurs être rigolo de passer à 30% quand les écrnas 4K apparaitront

Quand les écrans 4K apparaîtront, tu ne voudras sans doute pas avoir un site avec des lignes de 12 pixels de haut et de plus de 500 caractères de long.

Le problème est la taille physique des caractères. La taille dans la CSS devrait sans doute être relative à la taille en pixel de l'écran. L'entrée du suivi initiale (l'as-tu lue?) dit même:

Alternativement ou en complément, il serait envisageable de "zoomer" automatiquement la taille des polices et images afin d'obtenir le même résultat: la réduction de la taille des lignes mais c'est peut-être plus compliqué à mettre en œuvre de façon satisfaisante notamment en ce qui concerne les images si on veut que ça ressemble à quelque chose.

Je pense qu'il faut comprendre le max-width actuel comme un quick fix en attendant mieux.

Au moins ce ne sont pas des mis au bout des lignes comme les RFC que tu prends comme exemple.

Quelles sont les autres alternatives ?

Si on plonge un petit peu dans l'histoire, on peut retourner à l'époque où Gnome cherchait un langage de script à mettre en avant pour la version 3, afin d'éviter d'avoir 150 langages comme c'était le cas dans Gnome 2. C'est Javascript qui a été choisi, car l'un des critères principaux était le fait que le langage soit dynamique et ne vienne pas avec sa propre plateforme (comme python, perl, etc). D'autres langages qui correspondent à ces critères sont scheme/lisp et lua, mais en fait ça écarte de facto la plupart des langages "barbus" habituels comme python, ruby ou perl…

Bon, en pratique les applications écrites en python n'ont pas été réécrites pour autant…

Même si tout y est, je suis sûr qu'un peu de clarté ne ferait pas de mal.

checkthis.com n'a pas l'air d'apprécier le greylisting…

C'est pas censé être du SIP Lync?

Ça ne fonctionne pas avec les bons vieux clients SIP des familles, genre Ekiga, Jitsy et consorts?

Le danger d'une liste, c'est qu'on en oublie toujours.

GNOME sera présent au FOSDEM et organise quelques trucs comme chaque année, notamment un Beer Event le samedi soir.

De la même manière avec les tags, quand on "ajoute" un tag déjà présent en cliquant sur le marque page, le tag devrait se modifier en petite croix et permettre de supprimer le tag directement.

J'ai cru remarquer qu'il y avait deux modèles d'icones 'marque page' suivant qu'il s'agit d'un tag qu'on a ajouté ou pas, mais parfois c'est une croix qui s'affiche. Je n'en comprends pas bien la logique mais à mon avis ça devrait être uniformisé.

Bien que Nautilus 3.6 de notoriété publique supprimait la vue arborescente entre autres fonctionnalités, cette vue est de retour dans Nautilus 3.8 et suivants. J'en veux pour preuve cette capture d'écran du Nautilus de Debian Sid:

La fonctionnalité est désactivée par défaut. Pour l'activer il faut aller dans les préférences et cocher la case qui va bien dans l'onglet Affichage. Ça va encore plus vite que de rajouter un ppa et d'installer un nouveau programme.

En vous remerkiant!

Je me suis toujours dit que j'avais un petit côté avant-gardiste.

AES est bi-directionnel donc si tu trouves la clef tu peux tout décrypter directement.

Avec le hash au moins, il faut encore cracker tous les hashs car la fonction de hashage n'est pas bi-directionnelle. C'est alors la force du mot de passe en lui-même qui compte.

Si le sel n'est pas aléatoire, ça ne sert à rien.
Si le sel est aléatoire, tu dois l'avoir en clair, si tu le hashes tu ne le retrouveras jamais.

De toute façon, la première faille de sécurité est en fait de vouloir se prendre pour un expert en crypto:

• How to safely store a password
• Use BCrypt Fool!

Question con: comment tu fais pour vérifier ton mot de passe ? Il te faut stocker la valeur aléatoire que tu utilises d'une façon ou d'une autre, soit en l'ajoutant en clair au hash (comme crypt() et bcrypt()), soit en utilisant une valeur connue, dérivée de l'utilisateur (son username, son id multiplié par 1313, etc) sinon tu ne seras jamais en mesure de recalculer le même hash, car la valeur aléatoire sera différente à chaque fois.

Si le préfixe/suffixe est suffisament court, tu peux aussi trouver directement le hash dans une rainbow table sans préfixe.

Avec un peu de bol, et vu que théoriquement plusieurs strings pourraient avoir le même hash mais que c'est hautement improbable voire impossible avec des strings de longueur raisonnable, le hash et le mot de passe associé dans la rainbow table seront équivalents à la concaténation du salt et du mot de passe.

Quid de la fonction crypt() ? Cette fonction utilise un algorithme configurable (md5, blowfish, sha-256 ou sha-512) avec un salt de la même façon que l'explication de bcrypt(), la lenteur artificielle en moins (crypt() n'applique pas la fonction de hash plusieurs fois). Comme pour bcrypt, l'algorithme choisis influence la "force" du hash.

Il faut aussi mentionner que, tant pour crypt() que pour bcrypt(), le salt est intégré (en tant que préfixe) au hash final, après le numéro de l'algo de hashage utilisé. Donc, pour vérifier si un mot de passe est correct, il suffit de vérifier que (b)crypt(passwd, passwd) == hash.

Bref, si vous n'avez pas de bcrypt() disponible, utilisez crypt() plutôt qu'une solution "à la main"…

Reporte des bugs ;-)