Dring a écrit 1211 commentaires

  • [^] # Re: L'écriture inclusive, c'est de la merde.

    Posté par  . En réponse au journal Quelques joyeusetés que nous réserve le futur…. Évalué à 2.

    Pour clarifier, les 3 points que je citais sont les objectifs que je me fixerai.

    Et pour être encore plus précis, je considère que l'écriture inclusive qu'on croise actuellement…
    - essaye de mettre à égalité masculin et féminin (donc objectif atteint ici)
    - est trop difficile à lire et à écrire
    - représente une rupture trop importante (introduction d'une nouvelle ponctuation, rendu audio lourd pour les non/malvoyants)

  • # On a des choses à apprendre...

    Posté par  . En réponse au lien Stockage, mobilité, bureaux-abris… Face aux coupures de courant, la tech ukrainienne s’organise. Évalué à 5.

    …pour préparer les jours froids de cet hier…

  • [^] # Re: L'écriture inclusive, c'est de la merde.

    Posté par  . En réponse au journal Quelques joyeusetés que nous réserve le futur…. Évalué à 2. Dernière modification le 29 novembre 2022 à 15:45.

    Ploum a expliqué plus haut que l'usage de l'écriture inclusive dans cette nouvelle découlait d'une approche artistique, et c'est vrai que ça colle bien au sujet, donc chapeau bas.

    Pour ma part, je partage aussi les autres avis : si je devais lire ça en permanence, ça me fatiguerait beaucoup. Très désagréable, lourd à l'écriture et à la lecture, toujours à se demander si c'est une faute de frappe ou intentionnel, bref ça dessert la cause que c'est supposé défendre.

    Je suis toujours à la recherche d'une réforme de la langue française qui…

    • ne mettrait effectivement pas le masculin sur un piédestal
    • n'impliquerait pas un gros effort à la lecture / écriture
    • ne serait pas une rupture trop importante par rapport à l'existant, car c'est ce qui a tué la réforme Toubon et tuera toute réforme trop violente
  • # Explications ?

    Posté par  . En réponse au lien Metawatt - Comparez les scénarios de transition énergétique électrique. Évalué à 2.

    Je suis pas sûr tout suivre.

    Sur l'analyse d'impact en 2050, pour les scénarios Negawatt, je vois encore du nucléaire (ça reste même le plus gros poste sur la version 2022).
    https://metawatt.fr/impact/production/final

    Par contre, dans le détail du scénario, pas de nucléaire du tout, ni dans la version 2017, ni dans la version 2022.
    https://metawatt.fr/scenarios/negawatt-2022

    Quand je regarde la source (https://www.negawatt.org/IMG/pdf/scenario-negawatt-2022-rapport-complet-partie5.pdf), pages 11 et 13 je ne vois effectivement plus de nucléaire.

    Du coup, la page sur l'analyse d'impact, elle veut dire quoi exactement ? Si on regarde le second graphique, ça indique "production totale de aujourd'hui jusqu'en 2050". Donc c'est du cumulé ? Et c'est vrai aussi pour le premier graphique même si il ne le dit pas ?

  • # Moui… mais…

    Posté par  . En réponse au journal Douze facteurs dans ta tronche. Évalué à 8.

    Je suis plutôt d’accord avec la vision « le dogme c’est mal ».

    Mais c’est quoi qui te gêne avec l’idée du « 1 repo pour 1 app » ?

    Et tu ne penses pas que pour les logs, pour une exécution dans un cloud type kubernetes, le point 11 soit également valide ? Dans le principe, on doit généralement considérer qu’on n’a aucun stockage à disposition puisque en cas du destruction du node, tout peut et va disparaître.

  • # Phoronix

    Posté par  . En réponse au journal Vie et mort (?) de JPEG-XL. Évalué à 10.

    J’aimerais comprendre comment le mec derrière Phoronix, qui signe tous ou pratiquement tous les articles de ce site, fait pour suivre tous ces sujets.

    Là il écrit « j’étais tranquillement en train de regarder tous les changements de code dans le code de Chrome quand je suis tombé sur ce commentaire ».

    Boudiou ! On a l’impression qu’il fait ça au petit déjeuner avant sa demi-heure quotidienne de LKML. Certes il est journaliste et tout ça est dans son domaine de prédilection, mais j’ai quand même envie de dire « respect ».

  • [^] # Re: Mauvais côté

    Posté par  . En réponse au lien Cahier d'idées pour un navigateur écologique. Évalué à 2.

    Bien sûr que si les clients doivent s’alléger aussi. C’est pas l’un ou l’autre, c’est les deux.

  • # Has been?

    Posté par  . En réponse au journal Quel service choisir pour héberger une liste de diffusion ?. Évalué à 10.

    Pour les boomers et les retraités, utilise ton mur facebook.

    Pour les milleniums, fais des posts Insta qui renvoie vers des vidéos YouTube.

    Pour les morveux, fais une vidéo tiktok - sans texte car de toute façon ils ne savent pas lire.

  • [^] # Re: Non linéaire ?

    Posté par  . En réponse au sondage Ton éditeur de vidéo non linéaire favori. Évalué à 4. Dernière modification le 18 octobre 2022 à 12:53.

    C'est ma compréhension aussi :

    • linéaire = une seule piste vidéo, pas de montage, juste un enchaînement de plusieurs séquences.
    • non-linéaire = plusieurs pistes vidéos et audios, possibilité de faire des chevauchements et d'y glisser des transitions, etc
  • [^] # Re: En quoi c’est écologique ?

    Posté par  . En réponse au lien Cahier d'idées pour un navigateur écologique. Évalué à 3.

    Quand je vois le PC de mon épouse qui se retrouve à 100% de CPU et de disque dur après avoir ouvert 2 ou 3 sites moisis, j’ai un peu du mal avec l’approche « oui mais c’est compliqué de bien mesurer ».

    Il me semble qu’on doit quand même pouvoir isoler les gros sites bien merdiques. Et si c’est pas parfait, tant pis, il faut démarrer quelque part puis améliorer par itérations.

  • [^] # Re: En quoi c’est écologique ?

    Posté par  . En réponse au lien Cahier d'idées pour un navigateur écologique. Évalué à 1.

    On en a parlé ici (https://linuxfr.org/users/lolop/liens/impact-ecologique-du-numerique) de celui là. Je comprends pas qu'à chaque fois qu'on parle écologie, y a toujours quelqu'un pour opposer une approche à une autre, comme si il n'y avait qu'une seule vérité, un seul chemin à suivre.

    Si on suit l'adage "tant qu'il y a quelqu'un pour acheter, il y aura quelqu'un pour vendre", si on commence à faire des navigateurs qui restreignent l'utilisation de services non écologiques par défaut, ça encouragera aussi à faire un peu moins n'importe quoi côté serveur.

    Si on met en exergue au consommateur ce qu'il engendre, il peut déclencher un cercle vertueux. C'est un peu l'idée qui transparaît autour de l'idée d'avoir un indicateur, bien visible, qui dise "cette page est un tas de fumier d'un point de vue écologique" (l'idée "Rendre perceptible le poids d'une page").

  • # Intéressant

    Posté par  . En réponse au lien Cahier d'idées pour un navigateur écologique. Évalué à 5.

    J'allais gueuler en disant qu'il y avait déjà des initiatives de faire des navigateurs (et même des protocoles) plus légers.

    Mais là, l'initiative est surtout une réflexion sur ce qui pourri le web - et c'est franchement intéressant.

  • [^] # Re: Avis pour pinephone

    Posté par  . En réponse au journal ManjaroARM se fait épingler par Asahi Linux. Évalué à 3. Dernière modification le 07 octobre 2022 à 08:07.

    Non d'un p'tit bonhomme, c'est que tu as raison. Par contre, est-ce que c'était vraiment volontaire ?

  • # Dommage…

    Posté par  . En réponse au lien Impact écologique du numérique. Évalué à 10.

    …qu’à la fin de cet article qui évoque quand même la frugalité numérique il y ait un lien pour payer en bitcoins… la poutre, l’oeil, toussa…

  • [^] # Re: Avis pour pinephone

    Posté par  . En réponse au journal ManjaroARM se fait épingler par Asahi Linux. Évalué à 5.

    Mon avis, c'est que cette phrase était là juste parce qu'elle était rigolote, et qu'il ne fallait pas la prendre au premier degré. Mais je te laisse te faire ton avis sur la question.

  • # Reconnaissance vocale

    Posté par  . En réponse à la dépêche LibreOffice 7.4, un maître numéro de version. Évalué à 5.

    Je suis depuis plusieurs années à la recherche d'un logiciel de reconnaissance vocale qui s'intègrerait bien dans LibreOffice sous Linux.

    Même un greffon qui enverrait les données à un service web me contenterait tant pour l'instant je suis tout nu sur le sujet.

    A noter : mes différents essais pour l'instant avec des solutions type Google GSuite ne m'ont pas donné grande satisfaction. C'est très efficace tant qu'on fait des phrases bidons, puis quand on essaye de vraiment dicter un texte, c'est la cata. Et pour peu qu'on souffre d'un défaut d'élocution (ce qui n'est pas rare pour les personnes polyhandicapées), le taux de reconnaissance devient ridicule. Et comme il n'y a pas de module d'apprentissage…

  • [^] # Re: Messagerie

    Posté par  . En réponse à la dépêche Dernières avancées du côté de Thunderbird. Évalué à 4.

    Question naïve : tu as été voir dans les modules existants (IRC, XMPP, …) comment ils "enregistraient" le protocole auquel ils répondaient ?

    Je sais, ta question c'est pas "est-ce que je peux y arriver en lisant tout le code de TB", mais est-ce que c'est enfin documenté, mais au cas où…

    J'ai été jeter un oeil rapide, ça n'a pas l'air facile à trouver de toute façon.

  • [^] # Re: Pour des raisons de sécurité

    Posté par  . En réponse à la dépêche Dernières avancées du côté de Thunderbird. Évalué à 10.

    J'imagine que l'argument ne porte pas sur le langage et que le débat interne n'a pas été C vs JavaScript. Mais plutôt implémentation maison avec des failles mémoires contre librairie largement utilisée par une communauté plus large.

    Si c'est bien ça, l'argument de la sécurité se défend, vraiment.

    Je rejoins l'avis général : c'est triste de voir du JS se faufiler partout y compris dans des clients natifs. Mais je me souviens aussi que Thunderbird (et Firefox avant lui) utilisaient XUL, qui était déjà un truc interprété, mal aimé pour sa lenteur et sa consommation mémoire - donc y-a-t-il vraiment une régression ici ?

  • # Contenu faible

    Posté par  . En réponse au lien Firefox 105 !. Évalué à 3.

    Alors peut-être que sur cette release il y a eu beaucoup de travail de fond, mais les notes de version ne font pas rêver.

    Y a pas grand chose pour l’utilisateur qui soit visible ou notable. La faute à un calendrier peu favorable ? Ou « the next big thing » accapare les développeurs  ?

  • [^] # Re: Pérénité ?

    Posté par  . En réponse au journal Clés de sécurité, pas assez utilisées. Évalué à 10.

    Ou si on la perd au pire moment ? (c'est toujours au pire moment que ces trucs arrivent, loi de l'emmerdement maximum oblige)

  • # Attendre…

    Posté par  . En réponse au lien The Merge, la mise à jour cruciale d’Ethereum, a eu lieu: et maintenant ?. Évalué à 2.

    Tout est dans le titre. Il va falloir attendre et observer ce qui se passe. Peut-être juste quelques jours, peut-être des semaines.

  • [^] # Re: Efficacité énergétique réelle?

    Posté par  . En réponse au journal WikiHouse: les plans de pièces de maison sous licence CC BY-SA. Évalué à 4.

    Comme indiqué, j'ai déjà largement réduit ma consommation de viande. Et diminuer le lait, j'ai déjà commencé (mais c'est dur !). Ma consommation de thé est montée en flèche par contre.

    Mais c'est pas la question, et ce n'était qu'un exemple.

    Ces dernières années, j'ai mis en place plein d'actions qui correspondent à ta liste. Et il m'en reste plein à accomplir. La question, c'est comment les prioriser. Et pour chaque poste, savoir quelle est la bonne décision ou (et tu l'as très bien fait pour le lait) donner des clés pour savoir quelle est la bonne décision dans un contexte donné.

    Et je demande pas qu'on me les liste ici, la question c'est "est-ce que ça existe quelque part" ? Y'a deux liens qui ont été fournis qui répondent au moins partiellement. Mais un site du genre "tu prends conscience, tu veux agir, impec' : voilà quoi faire, dans quel ordre et à quoi faire attention / les questions à se poser".

  • [^] # Re: Efficacité énergétique réelle?

    Posté par  . En réponse au journal WikiHouse: les plans de pièces de maison sous licence CC BY-SA. Évalué à 5.

    Merci pour les liens.

    Le premier (ekopedia) ne me paraît pas ultra pratique/adapté par rapport à mon besoin.

    Le second (appropedia) semble plus proche de mes attentes. J'ai été voir la page "Sac en papier vs sac plastique" (https://www.appropedia.org/Paper_versus_plastic_bags) et c'est le genre de chose que je cherche. Par contre, la conclusion me surprend beaucoup :

    • le mieux c'est du réutilisable, et du coup, c'est le plastique qui gagne. OK, ça je comprends, le sac plastique peut durer très longtemps. Par contre, j'aurai indiqué "y'a encore mieux : le panier en osier.

    • si on veut vraiment du jetable, c'est le sac en plastique qui gagne, parce que ça consomme moins à la production, parce que c'est quand même un peu réutilisable. Je m'attendais pas à cette conclusion, et comme les éléments sont pas chiffrés…

  • [^] # Re: Efficacité énergétique réelle?

    Posté par  . En réponse au journal WikiHouse: les plans de pièces de maison sous licence CC BY-SA. Évalué à 5.

    Tiens, ça me fait penser.

    Il y a, quelque part, une liste des actions individuelles qu'on peut engager, classées de "faciles" à "complexes", ou au moins catégorisées, pour se faire un plan d'attaque ?

    Comme indiqué par Zenitram, on fait tous des petits gestes, mais pas nécessairement les plus importants. Et une liste de pointeurs pour chaque action pour savoir comment la faire serait bienvenue. Et sans oublier ceux qui font "mal" (logement collectif, limitation des naissances, etc.).

    Par ailleurs, pour les petites actions, pas facile de savoir "quoi faire". Je prends toujours l'exemple du lait. J'ai une famille qui consomme beaucoup de lait :

    • on fait beaucoup de cuisine nous-même (et pas mal de pâtisserie)
    • on fait nos yaourts nous-même
    • on boit beaucoup de lait nature (petit déjeuner, goûter, etc.)

    Pour l'instant, j'achète soit des briques tetrapak, soit des bouteilles en plastique, j'ai aucune idée de ce qui est le moins pire. Mais j'ai jamais vu de vrai consigne claire, ou au moins de source d'information fiable. Tetrapak, on dirait du carton, mais à l'intérieur il semble y avoir plus que ça. Alors, recyclable facilement ? Et diminuer la consommation de lait, OK, mais on remplace les protéines par quoi ? Je vais pas me mettre à bouffer plus de viande, et j'ai déjà mon quota de pois secs et équivalents.

    C'est juste un exemple, mais juste pour dire : pour le quidam de base, c'est difficile de savoir quoi faire. Et avoir un site sur lequel on pourrait s'appuyer pour chaque action, ce serait cool. Un wikipedia de l'écologie. Quelqu'un a un lien comme ça ?

    Je dis wikipedia car il n'y a pas de vérité absolue, et un truc un peu neutre, détaillant les différents avis serait vraiment bien. Mais bon, pas facile.

  • [^] # Re: Broker de messages

    Posté par  . En réponse à la dépêche Oubliez les web services, utilisez des tubes nommés. Évalué à 2.

    Une architecture possible c'est :

    • Kafka pour distribuer les évènements (il s'est passé "ça" sur "cette ressource", de manière ultra simple)
    • des APIs pour aller chercher l'info complémentaire, à partir d'un identifiant

    J'ai pas encore de bonne vision de Kafka, mais j'ai cru comprendre qu'une gestion fine des permissions pouvait être un peu complexe, là où les APIs s'appuient sur le mécanisme "naturel" des applications. D'où l'intérêt de ne pas publier trop de trucs. Le défaut, c'est que potentiellement, avec cette approche, si le consommateur prend trop de temps à aller chercher les données, il peut rater des états intermédiaires.

    • app "source" publie l'info sur l'objet X qui a le statut 1
    • app "cible" reçoit le message, mais est en train de prendre le thé
    • app "source" publie l'info sur l'objet X qui a le statut 2
    • app "cible" reçoit le message, mais touille le sucre
    • app "source" public l'info sur l'objet X qui a le statut 3
    • app "cible" se réveille, traite les 3 messages, appelle l'API 3 fois, et récupère 3 fois le statut 3 et a perdu les étapes intermédiaires

    Evidemment, si on envoie aussi l'état intermédiaire dans le message, et que l'application source garde tous les états, c'est pas grave, mais c'est le type de situation où il est préférable d'envoyer plus de données dans l'évènement.

    En entreprise, ce que j'ai souvent vu, c'est du MQ (donc du message point à point) où on balance l'ensemble des informations nécessaire pour le destinataire. C'est pas très beau d'un point de vue architecture, mais ça marche, et l'infra est adaptée pour supporter des gros volumes de gros messages. Moins de contraintes pour l'émetteur. Du vrai couplage faible.