Benoît Sibaud a écrit 9617 commentaires

• instance bloquant https://blog.piaille.fr/le-projet92/
• instance ne bloquant pas https://hub.fosstodon.org/our-position-on-threads (lien https://linuxfr.org/users/misc/liens/our-position-on-blocking-threads )

Ah non pas les mêmes threads.

Loi de Ook:

• "Ook?"
• "Ook" répondit le bibliothécaire

Au resto oui, chez toi tu fais ce que tu veux. Donc je disais juste qu'il faut du coup faire attention à sa propre image mentale d'une assiette et des couverts.

Ah bah non :-( Ca fait 01 du coup. On met le couteau à droite.

C'est risqué (enfin dépendant de la personne surtout), ça dépend si la personne est gauchère ou non.

C'est un truc de l'informatique : ce qui fonctionnait hier peut devenir inapproprié même en ne changeant rien.

C'est un truc vrai dans tous les domaines, c'est juste la durée qui change (voir Ceci aussi passera et sa légende perse, par exemple une version).

Si tu ne fais rien sur un pont ou un bâtiment, il se dégrade et s’effondre.
Si tu ne fais rien sur ta loi, elle devient ultraconservatrice et en décalage avec son époque, inadaptée.
Si tu ne fais rien avec ta nourriture et ta boisson, elles deviennent impropres à la consommation.
Si tu ne fais rien avec tes enfants, ils ne deviennent pas du tout ou alors de façon vraiment sous-optimale.
Si tu ne fais rien avec tes papiers administratifs ou bancaires, ça va mal finir aussi.
Etc., etc.
Il n'y a pas grand chose qui n'ait pas besoin de maintenance ou d'attention. Une certaine spécificité de l'informatique est le rythme assez effréné et l'idée qu'il faut juste aller vite parce que de toute façon ça coûte trop cher de faire mieux et qu'en allant vite on corrigera bien assez tôt. Et le réglementaire a partiellement sifflé la fin de la récré en disant juste « bon ben maintenant vous êtes responsables de vos machins » (notamment en termes de sécurité informatique).

En écoconsommateurs responsables, on prendra des pots en verre et un vilebrequin manuel, on fera un petit trou au fond sans les casser, et on mettra des câbles spéciaux pour audiophiles en or sertis platine et diamant, et on aura une super qualité sur chaque liaison P2P (personne à personne). Charge à chaque personne participant de relayer le message vers une autre personne (ce qui implique qu'il faut transmettre des infos de routage dans le message pour éviter de faire des rediffusions de messages). Bon y a un peu de taf d'organisation au départ.

(sérendipité : je découvre au passage ratchète et racagnac, on dirait deux compères interlopes).

Et quitte à enfoncer une porte ouverte : on ne doit pas nier le ressenti des gens. Les gens ressentent ce qu'ils ressentent. Ensuite on choisit d'en tenir compte, d'ignorer, de mieux ou moins bien se comporter, de changer ou de ne rien faire, d'expliquer, d'en discuter, mais ça ne sert à rien de nier/refuser/contester le ressenti des gens.

https://fr.wikipedia.org/wiki/Robert_Hooke

Hooke est l'inventeur du premier téléphone, le téléphone à ficelle, en 1665.

Pas si loin de LinuxFr.org que ça, il a inventé un média et un endroit pour échanger.

La modération peut aussi bloquer des images, mais le système est plutôt pour bloquer temporairement, souvent le spam (cf https://linuxfr.org/news/img-le-cache-d-images-sur-linuxfr-org , le contenu/commentaire contenant l'image bloquée est dépublié ou édité pour la retirer, et la référence à l'image est supprimée ainsi que son éventuelle version en cache). Si on bloque une image de la tribune temporairement pour la laisser revenir une semaine plus tard, ça peut être répétitif. Deux solutions : sanctionner le compte qui (re)publie une telle image, et faire la tâche pour des listes de blocages permanentes généralisées (lien, image, adresse de courriel, etc.).

Merci de rester courtois dans les échanges (et je dis cela en tant que modérateur).

Avis partagé. Et je supprime le commentaire concerné en conséquence. (ceci est posté avec ma casquette de modérateur).

J’ai toujours trouvé savoureux la manière dont est présenté le calcul du karma :

Tu aurais pu faire la remarque avant, dans le système de suivi par exemple. C'est une bonne idée de clarifier et d'améliorer la doc.

Et c'est fait, merci. Cf https://linuxfr.org/aide#aide-karma

Cf https://linuxfr.org/aide#aide-karma
et commit 73ecdfac4e1a418693fd6445557b6a94a165e40c

en lecture, oui (puisqu'un compte n'est même pas nécessaire). En écriture, il faut un compte (comme les 56 comptes qui y ont écrit sur les derniers 70 jours).

2025/01/12 18:03:34 Files in cache: 18188
2025/01/12 18:03:36 Total img keys in redis: 18631
OK

J'ai remis l'image du coup maintenant que ça marche.

<table id="accounts">
<tr><th>login</th><th>role</th></tr>
<tr><td>Faya</td><td>admin</td></tr>
</table>

(c'est pas fiable une IA)

J'avoue j'ai triché pour LinuxFr.org : je n'ai pas codé l'algo qui définirait un parcours exemplaire permettant de gravir les échelons et de devenir admin stagiaire, puis admin apprenti, puis admin junior, puis admin avant d'être grand mamamouchi admin, je suis allé en base de données pour y mettre un rôle admin. Je crains que d'autres aient fait de même.

Mais c'est aussi (et surtout ?) un problème propre à la modération qui, je pense, ne s'est pas bien adaptée à la tribune pour y faire respecter les règles de modération établies et appliquées sur le reste du site.

Ou bien un problème de la tribune qui, je pense, ne s'est pas bien adaptée à la modération pour y faire respecter les règles de modération établies et appliquées sur le reste du site. Mon avis strictement perso c'est que c'est encore une approche « vous n'en faites pas assez pour moi ».

Je vais caricaturer fortement : on a un spectre de positions possibles qui vont de « moi moule de la tribune on me doit tout » à « « pourquoi je devrais seulement faire quelque chose pour toi personne de la tribune que je n'utilise pas plutôt que rien ce qui serait plus carrément plus facile pour moi » (donc d'un pur individualisme à un autre pur individualisme). J'attendais une proposition que je n'ai pas vu malgré les nombreux commentaires postées : je n'ai pas vu de personnes utilisatrices de la tribune dire « je veut prendre la responsabilité d'assurer la modération sur la tribune » (responsabilisation des personnes concernées), ni de flagrante tentative de convaincre la modération actuelle de l'importance d'être plus présent sur la tribune pour venir y faire le job. Or si tout le monde s'accorde à dire qu'il y faudrait de la modération et qu'on ne trouve personne pour faire le job, il ne reste pas beaucoup de solution que se débarrasser du problème. Fin de l'approche caricaturale.

Éventuellement on a des besoins d'outillage de modération de la tribune. Sur les derniers 70 jours, la tribune couvre une période de 1h à 19h (dit autrement la durée de vie de messages sur la tribune c'était max 19h). Supprimer des messages voudrait dire agir en moins de 19h donc. Sinon on a les habituelles exclusions temporaires. La sanction de karma n'est pas disponible par exemple.

The existential horror of the paperclip factory sur le jeu des trombones ?

Un bon commentaire bien argumenté, étayé et apaisant. Une autre lecture serait que sans les personnes qui sont actives dans les équipes, la tribune produit surtout des liens et des commentaires (pas de dépêche, peu d'éditions de dépêches). On est en tout cas loin d'un lieu d'incubation des contenus rédigés pour le reste du site. Un gros tiers des personnes y ont produit un contenu, plutôt du rapide (surtout des liens).

On peut compter, je pense que ça fait déjà plus que de personnes utilisatrices de la tribune.

Je rectifie ce point sur lequel mon estimation pifométrique était fausse : la tribune c'est 56 comptes qui y ont écrit sur les derniers 70 jours (dont un quart ont écrit moins de 10 messages), et cela comprend 3 de l'équipe de modération et 1 de l'animation de rédaction. À comparer aux 1968 comptes utilisés sur le site sur la même période.

Et pour une réponse partielle (et purement quantitative) sur ce que cela apporte au site, sachant qu'il est difficile de dire si c'est lié à la tribune ou pas, mais ça concerne les personnes utilisatrices de la tribune en tout cas :

Derniers 70 jours	Parmi les personnes écrivant sur la tribune en m'excluant (55)	Parmi les personnes ayant écrit sur le site (1968)
Dépêches	1	76
Liens	103	336
Journaux	7	76
Entrées de forum	4	71
Édition des dépêches	5 personnes	66 personnes
Commentaires	30 personnes	574 personnes

C'est pour cela que l'aide existe. Parce que même moi qui trempe quand même beaucoup dans LinuxFr.org, je ne mémorise pas l'intégralité des algos et du fonctionnel.

Cas hostile

Il existe une réponse technique partielle à cela : le chiffrement homomorphe (ton cloud verra des données chiffrées uniquement, éventuellement il fera des opérations sur des données chiffrées, mais sans les connaître). Les performances sont tellement mauvaises (facteur 10000 ou 100000) qu'il faut un sacré besoin pour justifier la débauche de ressources et donc le coût correspondant. Toutes les opérations ne sont pas possibles (donc fonctionnellement ça peut limiter beaucoup). Et ça n'est pas magique non plus, ton cloud pourrait stocker tes données pour casser plus tard par exemple (l'intérêt pourrait apparaître avec mon exemple suivant). Mais si tu voulais héberger une solution de vote par internet sur un cloud public (je n'ai pas dit que c'était une bonne idée mais bon), tu pourrais lui demander d'additionner des votes sans que le cloud y ait accès en clair (sauf à casser la crypto), et pour un usage ponctuel, le surcoût de ressources pourrait être acceptable. En pratique, c'est très peu utilisé.

Vous ne parlez pas de la même situation je dirais.

Exemple avec chiffres pris au pif :
Si ton service courriel c'est 15% d'un serveur physique, que ton web c'est 25% et que ta base de données c'est 20%, alors tu vas te dire qu'un serveur c'est bien assez en ressources (en disponibilité c'est autre chose). Là on est dans le cas de services unix et du partage sur un système (ça ressemble au cas LinuxFr.org par exemple).
Si ton service courriel c'est 30 à 60% d'un serveur physique, que ton web c'est de 15 à 45% et que ta base de données c'est 20 à 40%, alors tu n'as pas envie de tout mettre sur un seul serveur physique de toute façon, donc plusieurs serveurs, et tu va commencer à avoir pas mal de gâchis de ressources pour éviter des pics de charge qui pourraient coïncider. Là on commence à avoir du mal à mettre plusieurs services par serveur (sans parler du cirque pour les déplacer en cas de besoin).
La promesse de la virtualisation, de Kubernetes, etc., c'est de pouvoir dire je veux des minimums de 30%/15%/20%, je veux un max de 60%/45%/40%, et de compter sur l'infra pour gérer.

Après la disponibilité et la répartition de charges font que mettre 10 instances d'un même service sur un même serveur, ça ne serait pas idéal, donc on met des règles de non-affinité, donc on a besoin de plein de serveurs différents, et puis on fait répartir à des endroits différents, donc on a besoin d'encore plus de serveurs différents. Et on compte sur l'hébergeur d'infra pour mutualiser et rationaliser tout ça (et il margera là-dessus).