Dring a écrit 1102 commentaires

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.

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

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.

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

…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…

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.

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…

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.

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 ?

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  ?

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

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

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

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…

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.

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.

Est-ce vraiment un contre-argumentaire, dans la mesure où il est dit la même chose :
"Deliverability for self-hosted emails has never been harder".

Certes, il est plus facile de créer son serveur mail, mais si de toute façon les mails n'arrivent pas au destinataire…

Parce que le lien donné ici ne fait que rediriger vers un autre article :

https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-towel-the-oligopoly-has-won.html

100% d'accord sur oauth2. J'ai l'impression qu'on attend encore "la" solution qui permettra de faire tout ça plus simplement.

Pour les échanges interbancaires, c'est un domaine que je connais bien, et j'ai jamais entendu parler de PeSit. Une recherche sur internet semble faire un lien avec Axway CFT, qui est très utilisé en effet, mais est hautement merdique (je connais plusieurs centaines de personnes prêtes à tuer pour s'en affranchir).

De mon côté, les "protocoles" que je connais le mieux :
- SWIFT ; à la fois un réseau, un protocole, et une plateforme. Dans sa dernière mouture, c'est du XML, très, très, très chiant à manipuler. Plutôt orienté backoffice.
- FIX, un protocole et un format. Plutôt compact et efficace, orienté temps réel car utilisé pour le frontoffice/trading.
- CFT, SFTP et MQ (avec une ligne louée dédiée pour les communications vers l'extérieur), avec en général du CSV, du XML ou du texte à taille fixe
- Et les bons vieux formats type ETEBAC, qui sont pas trop interbancaires, mais plus pour des PME "non-orienté finance" pour générer des virements. Pendant longtemps, ça allait aussi avec une solution de télématique - mais j'ai pas touché à ça depuis 25 ans. Peut-être que c'est là que PeSit est utilisé ?

Toutafé ; et de toute façon, si on a des contraintes de temps réel ou pseudo temps réel, la latence induite par HTTP n'est juste pas acceptable.

A problème différent, solution différente.

…par rapport à un tube nommé, c'est aussi que ce n'est pas du point à point.

Quand on crée un webservice, il peut être utilisé…
- par l'interface utilisateur
- par des services extérieurs à l'entreprise
- par le petit process d'à côté

Et ça, c'est vachement pratique.

Ben déjà, les webservices suivent une route intéressante. De SOAP et les monstres qui allaient avec (l'artillerie XML et le WSDL de description), on migre progressivement vers REST/JSON.

Ca reste de l'artillerie lourde, mais passer par HTTP permet de profiter de plein de bonnes choses. Et notamment :
- oauth2 pour sécuriser les canaux.
- une simplification des règles firewall puisque tout passe par le port 443 sans pour autant sacrifier à la sécurité (cf. oauth2)
- une grammaire standard (PUT, GET, POST, DELETE, …)
- des fonctionnalités intégrées (le choix du format de réponse quand le serveur le supporte, la description de l'encodage et du format retourné, …)

Ca reste trop complexe, mais comme dit plus haut, on n'est plus dans un monde de bisounours où on peut faire confiance à une machine juste parce qu'elle est dans le même réseau, ou à un même process juste parce qu'il est sur la même machine.

A propos du format de réponse, le grand classique c'est JSON, mais avec un service REST rien n'empêche de faire du XML (pour les nostalgiques), du CSV, du fixed-length, du Excel, du PDF, du OpenDocument, …

Je viens seulement d'aller suivre le lien et regarder la discussion de l'époque.

Il est clair que la démarche de Mike Saunders (côté LibreOffice) est assez maladroite, et comme le fait remarquer son correspondant Peter Kovacs (côté Apache OpenOffice), il aurait été bien avisé d'utiliser un canal de communication privé pour commencer à discuter du sujet.

Même si on parle de projets open source, demander au projet X de rajouter sur son site "au fait, y'a aussi le projet Y qui est bien plus à jour que le nôtre", c'est pas loin, comme dit, d'être toxique.

Après, la discussion prend forcément un tour très émotionnel et peu constructif.

Dommage, car le point reste ; aujourd'hui (et c'est redit par pas mal de personnes dans le thread) OpenOffice est souvent utilisé "à tort" car les personnes ignorent l'existence de LibreOffice qui est quand même plus moderne, plus riche, plus mieux.

Par ailleurs, la proposition de tout fusionner sous l'égide de AOO, si ça doit résoudre des problèmes de licence autrement insolubles, me paraît acceptable. La "marque" OpenOffice restant toujours plus populaire que LibreOffice.

Heureusement Notes est en grosse perte de vitesse. Même IBM ne l’utilise presque plus.

Comme on dit par chez moi : il y a ceux qui sachent, et ceux qui croivent sachoir :-).