Bruno Michel a écrit 3195 commentaires

  • # Corrigé

    Posté par (page perso) . En réponse à l'entrée du suivi Nombre d'avis à 0. Évalué à 3 (+0/-0).

  • [^] # Re: Configurer Nginx ?

    Posté par (page perso) . En réponse à l'entrée du suivi Ajouter un réglage de cache aux nouvelles polices. Évalué à 4 (+1/-0).

    Bon en vrai, la branch master de ce dépôt git n'a pas bougé depuis 2017, c'est peut être pas le bon endroit.

    Je confirme, ça fait quelques temps que Benoît a mis en place un autre dépôt git, avec du ansible. L'objectif est de rendre ce nouveau dépôt git public un jour, mais il faudrait d'abord bien vérifier qu'il n'y a rien de sensible dedans. Et comme il y a plein d'autres choses à faire, ça n'a pas été la priorité jusque là.

    Pour ce qui est du cache sur les polices, j'ai ajouté ça dans le dépôt git, mais je n'ai pas réussi à lancer ansible pour le déployer sur les serveurs. Du coup, j'ai fait la modif à la main directement sur les serveurs. J'espère juste n'avoir rien cassé au passage.

  • [^] # Re: il y a un truc qui me gène

    Posté par (page perso) . En réponse au journal Tristan Nitot devient directeur général de Qwant. Évalué à 8 (+7/-2).

    Je suis curieux de savoir pourquoi tu te sens obligé de répondre, surtout que cette réponse ne me paraît pas très efficace : elle t'inclut dans le problème soulevé, ce qui n'était pas forcément le cas jusque là.

    Est-ce que tu t'es senti visé directement ? Je n'avais pas l'impression que le commentaire de départ te visait particulièrement, mais peut-être l'as-tu ressenti autrement. Si oui, pourquoi ? Est-ce que tu as l'impression que ton commentaire initial a été mal interprété ?

    Est-ce une histoire d'égo ? Tu as pris ce commentaire personnellement parce que tu as souvent tendance à penser que ce que les gens disent te concerne directement ? A priori, j'imagine que non, mais ça reste une possibilité.

    Est-ce une manière de montrer indirectement que tu n'es pas d'accord avec le commentaire auquel tu réponds ?

    Est-ce autre chose ?

  • [^] # Re: Ni bonne, ni mauvaise

    Posté par (page perso) . En réponse au journal Tristan Nitot devient directeur général de Qwant. Évalué à 10 (+29/-4).

    Bon, puisque je suis cité, je vais donner mon avis. J'ai beaucoup de regrets que Tristan n'ait pas réussi à faire pour Cozy Cloud ce qu'il avait réussi à faire pour Mozilla. C'est quelque part un échec et ça s'est particulièrement vu dans son départ, qui sonnait effectivement un peu faux. Par contre, je suis sincèrement convaincu que Tristan croit depuis longtemps dans le Logiciel Libre et que ce n'est pas pour une question d'argent. Je n'ai aucun doute que, dans le cas contraire, il aurait pu partir vers d'autres sociétés et gagner bien plus d'argent. Il a une capacité à simplifier des discours et faire passer des messages simples qui vaut cher sur ce marché. Je suis sûr que les GAFAM ou des licornes françaises à la Criteo auraient pu lui proposer des salaires bien plus importants.

    Les actions de Tristan ne sont ni toutes blanches, ni toutes noires. Il y a aussi des choses qui me gênent, mais globalement, je le considère plutôt comme un allié du Libre. Je trouve déplacées les attaques dans les commentaires, qu'elles visent Tristan, mais aussi d'autres comme Ysabeau ou ZeroHeure. Personne n'est parfait, chacun a ses réflexions, ses contradictions et son mode fonctionnement qui sont plus compliqués que ce que l'on peut en voir publiquement. Les attaques visent des choses superficielles et me semblent contre-productives : si on critique les gens qui essayent de faire des choses, mêmes si elles ne sont pas à la hauteur de nos espérances, on va surtout se retrouver avec plus personne qui n'essaye, pas avec des gens meilleurs selon nos critères.

    J'ai de plus en plus de mal à lire les commentaires de LinuxFr.org, ça manque d'ouverture, de vrais échanges et dialogues, de points de vue différents. Les personnes qui commentent ont l'air de penser qu'elles savent tout, qu'elles font tout parfaitement, et qu'elles n'ont pas besoin des autres. Elles n'essayent pas, ou trop peu, de chercher à vraiment comprendre ce que veulent dire les autres et à se remettre en question.

    Par contre, ça, l'aventure Qwant, on est en droit de se questionner sur ses convictions pour ce qui est du "Libre" en tant que modèle économique viable. Un manque de "Foi", peut-être ?

    Non, je ne pense pas que l'on soit en droit de se questionner sur ce sujet. En tout cas, pas encore, c'est trop tôt, Tristan n'est en poste que depuis quelques jours, il n'a évidemment pas encore pu peser par ses actions sur Qwant en tant que nouveau Directeur Général. Il a auparavant travaillé pour la branche R&D de Qwant, Qwant Research, qui a sorti au moins deux produits sous des licences libres : Qwant Maps et Masq. Encore une fois, ce n'est ni tout blanc, ni tout noir, mais c'est déjà bien mieux que la grande majorité des start-ups.

    Plus généralement, Tristan a beaucoup œuvré pour le Libre, mais ses opinions ont évolué. Aujourd'hui, il considère que ses combats pour le respect de la vie privée et pour l'écologie sont plus importants que celui pour le Logiciel Libre. Ça ne veut pas dire qu'il ne croit plus dans le Logiciel Libre, juste que ce n'est plus une priorité. Comme tout le monde, ses journées ne font que 24h et il ne lui est pas possible d'adresser tous les sujets qu'il voudrait dans ce temps limité. Et je ne vois pas de quel droit j'irai juger que Tristan n'a plus la foi dans le Libre parce qu'il s'est lancé dans l'aventure Qwant, ni même pourquoi j'aurais à juger de la foi de Tristan tout court.

  • # Fait

    Posté par (page perso) . En réponse à l'entrée du suivi Retirer le drapeau d'urgence après la modération d'une dépêche. Évalué à 4 (+1/-0).

  • # Fait

    Posté par (page perso) . En réponse à l'entrée du suivi Retirer le lien site perso sur une fermeture administrative de compte. Évalué à 4 (+1/-0).

  • [^] # Re: LinuxFr.org a eu 29 ans 

    Posté par (page perso) . En réponse au journal LinuxFr.org : seconde quinzaine de juin 2019. Évalué à 5.

    Oui, par contre, ce ne sont pas 29 années terrestres. Le site a été créé fin juin 1998 et a eu 21 années terrestres.

  • [^] # Re: Dynamique

    Posté par (page perso) . En réponse au journal LinuxFr.org : seconde quinzaine de juin 2019. Évalué à 5.

    Pour info, on a des statistiques sur les comptes utilisateurs ici : https://linuxfr.org/statistiques/users, et sur les dépêches (et autres contenus) là : https://linuxfr.org/statistiques/contents.

    Et pour les bilans annuels, oumph écrit généralement une dépêche avec des statistiques variées en début d'année. https://linuxfr.org/news/statistiques-2018-du-site-linuxfr-org est la dernière en date.

  • [^] # Re: Une piste

    Posté par (page perso) . En réponse au message Lister les modifications de conf. Évalué à 3.

    J'ai modifié le commentaire pour corriger la coloration syntaxique.

  • # Bug intéressant

    Posté par (page perso) . En réponse à l'entrée du suivi Coloration syntaxique au comportement étrange. Évalué à 3 (+0/-0). Dernière modification le 09/07/19 à 15:01.

    Les triple backquotes pour fermer la section de code contenait une espace, et ça avait comme effet de bord d'interpréter les deux dollars du code bash comme étant une formule mathématique à rendre avec mathjax. Ce qui faisait un drôle de ménage avec la coloration syntaxique pour le code. J'ai modifié le commentaire en question, mais ça vaudrait le coup de corriger le bug sous-jacent.

  • # Fait

    Posté par (page perso) . En réponse à l'entrée du suivi Liens des commentaires notés négativement en nofollow. Évalué à 3 (+0/-0).

  • # Fait

    Posté par (page perso) . En réponse à l'entrée du suivi Mise à jour logo Red Hat. Évalué à 5 (+0/-0).

  • [^] # Re: Requêtes SQL lentes ?

    Posté par (page perso) . En réponse à la dépêche SEO, SEO, SEO, SEO et aussi le SEO. Évalué à 5.

    Je me demande si la base de données de linuxfr est aussi volumineuse que ça, ou si quelques optimisations ne manqueraient pas (index, …) ?

    Ici, c'était juste des requêtes lancées une fois à la main. On n'a pas cherché à optimiser et encore moins à mettre un index juste pour ça.

    Peut-on consulter le schéma de la BDD ?

    Il y a une version en Ruby ici : https://github.com/linuxfrorg/linuxfr.org/blob/master/db/schema.rb.

  • [^] # Re: Version ansible

    Posté par (page perso) . En réponse à l'entrée du suivi Fichier INSTALL.md détaillé pour guider les nouveaux contributeurs. Évalué à 4 (+0/-0).

    Je confirme, ces URL vont vers le daemon board. Il sert pour ajouter en temps-réel les nouveaux messages de la tribune, mais aussi pour mettre à jour les dépêches dans l'espace de rédaction au fur et à mesure des éditions.

    Dans ma config locale de nginx, j'ai des trucs comme ça :

    # ...
    
    upstream board-frontend {
        server unix:/home/nono/dev/board/board.sock;
    }
    
    server {
        # ...
    
        location ^~ /b/ {
            proxy_buffering off;
            proxy_pass http://board-frontend;
        }
    
        # ...
    }
  • [^] # Re: 1ère série - préparer le terrain dans l'espace de rédaction

    Posté par (page perso) . En réponse à l'entrée du suivi Implémenter le nouveau design de LinuxFR. Évalué à 5 (+0/-0).

    Sans l'ombre d'un doute, vaut mieux les stocker sur le système de fichiers.

  • [^] # Re: 1ère série - préparer le terrain dans l'espace de rédaction

    Posté par (page perso) . En réponse à l'entrée du suivi Implémenter le nouveau design de LinuxFR. Évalué à 4 (+0/-0).

    Si on commence à faire intégrer une image par article, est-ce qu'il faut commencer à proposer le stockage des images directement sur le serveur de LinuxFr ? L'idée, c'est qu'avec ce nouveau design, l'image fait vraiment partie de l'article, du coup, faudrait-il un stockage pérenne ou on continue d'accepter des liens qui peuvent casser ?

    Oui, j'avais en tête de proposer de stocker les images sur le serveur de LinuxFr.org (au moins l'image principale des articles dans un premier temps). Mais je n'ai encore rien fait et vaut mieux ne pas compter sur moi. Un patch est le bienvenu ;-)

  • [^] # Re: Cas d'usage pour le téléchargement en markdown ?

    Posté par (page perso) . En réponse à l'entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 3 (+0/-0).

    J'ai 2 cas d'usage en tête :

    • une très grande majorité des contenus du site sont sous des licences libres, avoir le markdown permet de les réutiliser plus facilement ailleurs
    • ça permet d'apprendre la syntaxe markdown via des exemples : quelqu'un qui voit un contenu avec un tableau, une équation, des notes de bas de page peut aller voir le markdown pour comprendre comment faire quand il voudra écrire un prochain contenu avec l'une de ses fonctionnalités.
  • [^] # Re: CSS à ajuster ?

    Posté par (page perso) . En réponse à l'entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 3 (+0/-0).

    Je ne pense pas que ça vaille la peine de trop se casser la tête pour IE. Tant que les contenus restent lisibles, c'est suffisant.

  • # Humm

    Posté par (page perso) . En réponse à l'entrée du suivi Remplacer "modéré" par "affiché". Évalué à 5 (+0/-0).

    Le « affiché par » me laisse très perplexe. Ça ne me semble pas très compréhensible par le commun des mortels.

  • [^] # Re: Merci pour le patch

    Posté par (page perso) . En réponse à l'entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 3 (+0/-0).

    Très bonne idée !

  • # Merci pour le patch

    Posté par (page perso) . En réponse à l'entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 3 (+0/-0).

    Sommaire

    Merci pour la contribution.

    Pour information, Mathieu m'avait également donné une suggestion pour l'ordre des modifications à faire. Je la mets ci-dessous.


    Décomposition des changements

    Ci-dessous on décompose les changements qui nous paraissent essentiels. On propose d'implémenter ces changements par série, de sorte à garder la cohérence des changements liés entre eux et que chaque série apporte une amélioration perceptible.

    Priorité 1

    1ère série - préparer le terrain dans l'espace de rédaction

    Objectif : lister plus de contenus sur un même écran, inciter à consulter d'abord les contenus publiés sur LinuxFr, et à aller voir les ressources externes dans un second temps.

    • [ ] [Rédaction] faire évoluer le gabarit d'article pour inciter à écrire un chapeau
    • [ ] [Rédaction] faire évoluer le gabarit pour intégrer au moins une image
    • [ ] [Rédaction] faire évoluer le gabarit pour toujours afficher les liens à la suite de l'article
    • [ ] [Rédaction] permettre de créditer les auteurs des images
    • [X] [Actualités] sur la liste des articles, retirer les liens
    • [X] [Actualités] sur les articles, placer les liens externes à la suite du texte

    Dans chaque article, on peut placer les liens externes dans deux colonnes à la suite du texte :

    https://github.com/mjourdan/linuxfr-design/blob/master/experimentations_5/3.1.0_article.png

    Priorité 2

    2ème série - soigner l'accueil

    Objectif : faciliter le premier contact, la compréhension de l'objet du site et des différents types de contenus.

    • [ ] [Navigation] déplacer le menu utilisateur vers la partie droite du bandeau de navigation
    • [ ] [Navigation] ajouter le bouton « À Propos » dans le bandeau du haut
    • [ ] [Navigation] màj la terminologie pour la rendre plus accessible
    • [ ] [Accueil] afficher les unes (?) / actualités / billets séparément avec leurs traitements visuels respectifs
    • [ ] [Accueil] faire apparaître les sondages, derniers messages de forums, et dernières modifications de wiki
    • [ ] [Préférences] supprimer les préférences liées à l'accueil devenues obsolètes

    Sur la maquette ci-après, on a pas de « une » persistante. On garde la possibilité de mettre en avant des articles (cf Paperwork 1.1) mais ceux-ci peuvent descendre dans la liste au fil du temps :

    https://github.com/mjourdan/linuxfr-design/blob/master/experimentations_5/1.0.0_accueil.png

    La barre de navigation en haut et le menu utilisitateur doivent s'adapter au mobile :

    https://github.com/mjourdan/linuxfr-design/blob/master/experimentations_5/barre_de_navigation.png

    3ème série - affiner la liste des articles

    Objectif : inciter à consulter les articles publiés sur LinuxFr, distinguer les différents types de contenus

    • [ ] [Actualités] sur la liste des articles, afficher les chapeaux (ou un texte tronqué) et illustrations
    • [ ] [Actualités] sur la liste des articles, retirer la possibilité de pertinenter / inutiler
    • [ ] [Actualités] sur la liste des articles, implémenter le traitement visuel
    • [ ] [Actualités] sur la listes des actualités, faire apparaître les articles les plus visités et les derniers commentaires

    4ème série - affiner la liste des billets

    Objectif : inciter à consulter les billets, renforcer la distinction articles éditoriaux / billets personnels

    • [ ] [Blogs] sur la liste des billets, afficher les chapeaux et illustrations
    • [ ] [Blogs] sur la liste des billets, retirer la possibilité de pertinenter / inutiler
    • [ ] [Blogs] sur la listes des blogs, faire apparaître les billets les plus visités et les derniers commentaires
    • [ ] [Blogs] sur la liste des billets, implémenter le traitement visuel

    Priorité 3

    5ème série - améliorer le suivi des commentaires

    Objectif : améliorer le confort de navigation parmi les commentaires, augmenter le rapport signal / bruit.

    • [ ] [Commentaires] mise en forme des commentaires (avatars arrondis, notes…)
    • [ ] [Commentaires] mettre en valeur les commentaires jugés pertinents par les auteurs des articles auxquels ils répondent (les messages des autres utilisateurs et ceux des auteurs eux-mêmes)
    • [ ] [Commentaires] permettre de rédiger un commentaire sans perdre le contexte (ni quitter la page ni perdre le suivi des commentaires non lus)
    • [ ] [Commentaires] nouveaux filtres de navigation (selon la note, afficher/masquer les erreurs de français)
    • [ ] [Commentaires] permettre de signaler des erreurs de français (fil positionné à la suite des autres commentaires)

    6ème série - nouvelle barre de navigation

    Objectif : adapter la navigation aux mobiles et aux interfaces tactiles

    • [ ] [Tribune] regrouper les espaces de discussion instantanée
    • [ ] [Tribune] permettre de les afficher/masquer à volonté sur mobile, depuis les barres de navigation
    • [ ] [Navigation] implémenter la nouvelle barre pour naviguer parmi les contenus / commentaires
    • [ ] [Rédaction] implémenter la nouvelle barre pour naviguer dans l'espace de rédaction
    • [ ] [Rédaction] implémenter la nouvelle barre pour rédiger les articles
    • [ ] [Navigation] màj la liste des catégories, plus courte et accessible

    Priorité 4

    7ème série - blogs

    Objectif : transformer les journaux en des blogs attrayants

    • [] [Blogs] soigner la présentation des profils
    • [] [Blogs] permettre d'éditer son profil depuis la page idoine
    • [] [Blogs] séparer les différents contenus par onglets
    • [] [Blogs] permettre d'épingler quelques contenus

    8ème série

    Objectif : améliorer le confort de rédaction & de navigation

    • [ ] [Rédaction] lister l'ensemble des articles et billets auxquels les gens participent sur la page de rédaction
    • [ ] [Notification] mettre en place le système de notification
  • # Benchmarks pas très intéressants

    Posté par (page perso) . En réponse au journal Navigateur web, l'impossible choix. Évalué à 10.

    Pendant un paquet d'années, les navigateurs se faisaient concurrence sur les performances et les benchmarks étaient les juges en la matière. Chaque éditeur avait plus ou moins son benchmark où, étonnamment, son navigateur s'en sortait mieux que dans les benchmarks des autres navigateurs. Depuis 2 ou 3 ans, les éditeurs ont changé de bord et abandonnent ces benchmarks. Ils se sont rendus compte qu'ils étaient arrivés à une situation où améliorer le score pour les benchmarks donnait souvent des résultats moins bons dans la vraie vie (un phénomène de sur-optimisation pour des cas spécifiques).

    D'autre part, les benchmarks mettent souvent en avant les calculs en JS, ce qui est rarement là que l'impression de vitesse pour les utilisateurs se joue. Les accès au DOM ou savoir charger les bonnes ressources au bon moment sont souvent plus importants.

    Bref, aujourd'hui, Firefox est généralement considéré comme le navigateur le plus rapide (suite à pas mal d'optimisations très récentes), suivi de très près par Chrome. Chrome est généralement considéré comme le navigateur le plus avancé en termes de sécurité (séparation en plusieurs processus notamment), suivi de près par Firefox. Derrière, j'entends de temps en temps parler en bien de Falkon, mais les autres navigateurs jouent surtout sur le côté plus léger (moins de fonctionnalités, moins d'extensions, etc.).

  • [^] # Re: Il faudra s'en occuper un jour

    Posté par (page perso) . En réponse à l'entrée du suivi Ruby Sass est déprécié. Évalué à 3 (+0/-0).

    A priori, sass-rails va devenir un wrapper autour de sassc-rails : https://github.com/rails/sass-rails/pull/424.

  • [^] # Re: Yep

    Posté par (page perso) . En réponse à l'entrée du suivi Avoir une meilleure configuration HTTPS. Évalué à 3 (+0/-0).

    On a maintenant un score de A sur https://tls.imirhil.fr/https/linuxfr.org

  • # Il faudra s'en occuper un jour

    Posté par (page perso) . En réponse à l'entrée du suivi Ruby Sass est déprécié. Évalué à 3 (+0/-0).

    C'est effectivement un problème connu depuis un bout de temps. Pour le moment, la communauté Rails n'a pas l'air très décidée sur le chemin à prendre :

    • certains proposent effectivement d'utiliser Dart Sass en l'embarquant dans une gem Ruby, mais personne n'a l'air d'avancer dans ce sens (ie écrire du code et être prêt à le maintenir)
    • d'autres suggèrent de passer à sassc-rails, mais ce n'est pas très clair si le mainteneur de sassc-rails va encore maintenir cette gem très longtemps, et là encore, il n'y a pas de contributeurs
    • enfin, Rails est en train de migrer progressivement de son assets pipeline vers webpack, et possiblement, la manière conseillée d'utiliser sass avec Rails 6.0 sera de passer via webpack.

    Bref, pour le moment, le mieux est sûrement de continuer à attendre https://github.com/rails/rails/issues/32896, sachant qu'il n'y a pas d'urgence. Même si la version Ruby de Sass n'est plus prise en charge officiellement, elle ne va pas s'arrêter de marcher du jour au lendemain.