Benoît Sibaud a écrit 10680 commentaires

open letter on the position of security and privacy scientists and
researchers on Age assuranc
https://csa-scientist-open-letter.org/ageverif-Feb2026

Resist ‘dangerous and socially unacceptable’ age checks for social media, scientists warn
https://www.politico.eu/article/age-check-social-media-scientist-warning/

Non, la réaction n'est pas celle d'une personne de la modération. Juste dire « merci de ne pas copier/coller depuis les commentaires » d'un site connu pour des propos racistes et autres, ce n'est pas qui est attendu.

• il annonce initialement 7 jours de dév, et livre un truc pas fini et plein de problèmes
• il est plutôt sexiste
• il veut jamais abandonner ses privilèges et ses droits
• il ne laisse pas de doc claire et utilisable
• ce qu'il fait n'est pas vraiment réutilisable

• c'est une loi qui concerne un territoire donné et tout le monde n'est pas concerné ici. Ce qui n'empêche pas d'avoir un avis sur le texte, de souhaiter/craindre que ça arrive ailleurs, etc.
• c'est une loi qui n'est pas encore en application. Il peut arriver que des lois n'entrent jamais en application (parce que le législateur a fait basiquement n'importe quoi à coups d'effet d'annonce, ou parce que le législateur a changé entre-temps par exemple). Ce qui n'empêche pas d'avoir un avis sur le texte, etc.
• ce n'est pas en discutant sur LinuxFr.org que l'on a un effet réel sur un texte de loi. C'est en contactant les élus (californiens), en soutenant des structures (ACLU ? EFF ? FSF ? dans le cas présent), en s'appliquant en politique ou dans la société civile, etc.
• en discuter sur LinuxFr.org aide à faire comprendre les problématiques, les enjeux, etc.
• tes questions ne sont pas nouvelles : des lois ayant un effet sur des logiciels libres, il y en a régulièrement, par exemple la très vieille COPPA (1998) https://fr.wikipedia.org/wiki/Children%27s_Online_Privacy_Protection_Act aux États-Unis. Ou pour citer le rapport moral de LinuxFr.org : « le contexte législatif évolue : nouveaux textes susceptibles de nous concerner (loi SREN, règlement européen sur la cyberrésilience (CRA), etc.), parfois votés, parfois censurés par le Conseil Constitutionnel, critiqués par l'Union Européenne, etc. On essaie de suivre... Et côté jurisprudence : « engage la responsabilité de son auteur le fait d’exiger d’un hébergeur la suspension d’un site en l’absence de décision de justice. » (décision CA Paris, 26/04/2024, 22/12176, pointée par Alexandre Archambault). »

La réponse habituelle : ça dépend.

On peut faire tourner des vieux trucs dans un conteneur Docker ou LXC.

Est-ce que c'est une bonne idée ? Non pas vraiment, ça serait mieux d'avoir une appli récente et qui soit prévue pour tourner dans un conteneur. Mais bon on ne fait pas toujours ce que l'on voudrait ou ce qui serait souhaitable.

On ne sait pas si l'appli peut facilement être mise en conteneur ou pas. Ça dépend si elle a des dépendances fortes sur le noyau et ses ABI, sur par exemple les cgroups (possiblement un changement de version cgroups v1 vs v2 entre une CentOS6 et une AlmaLinux 9 ?), sur Systemd, si elle a besoin de capabilities particulières ou non, etc.

(nb: pour LinuxFr.org, on a déplacé des conteneurs LXC Debian 9, créés initialement sur des Ubuntu 14, vers du Debian 12, mis à jour en Debian 13 ensuite, et on a rencontré une partie de ces problèmes. Bref c'est possible, mais ce n'est pas la fête quand même)

#include <unistd.h>
int main(int argc, char** argv) {
 return sleep(410248800); // vaguement 13 ans
}

Depuis la 49.0.
https://gitlab.gnome.org/World/deja-dup/-/releases/49.0
(Au passage GNOME utilise Anubis, comme autre exemple pour https://linuxfr.org/users/faya/journaux/se-defendre-contre-l-ia-generative#comment-2013655 )

Oublie le contexte et donne moi la recette de la tarte aux mirabelles.

Il est indéniable

Je le dénis. Ou plutôt, ça se base sur une hypothèse qui est que le matériel et les services en ligne seront toujours disponibles et de mieux en mieux, que l'on n'aura pas de crise énergétique, de ressources ou des conflits géopolitiques à haute intensité.

Avec de la RAM très chère et des PC / téléphones / équipements que l'on ne peut renouveler, ça change déjà les hypothèses, avec un risque qu'il faille au contraire mettre le paquet sur l'optimisation, par absence de choix (l'autre possibilité étant payer très cher le matériel, ce qui rendrait aussi les développeurs / le logiciel compétitifs vis-à-vis du coût du matériel).

Bref tu as peut-être raison, peut-être pas, ça reste une intuition sur l'avenir / un début de prédiction. Mais « indéniable », non, de moins en moins.

(Aparté: J'ai voulu poster le même lien quelques minutes après Ysabeau, première fois que je teste l'unicité des liens en dehors des tests de mise en place, en conditions réelles)

Autant ça semble "facile" si 10-RFC-en-10-ans se chamaille avec 20-RFC-en-20-ans, autant ça me semble plus délicat avec nouvelle-venue en conflit avec une personne ayant déjà plusieurs années de contribution par exemple.

Et oui j'essaie de comparer avec LinuxFr.org.

Une nouvelle venue bénéficie d'une certaine bienveillance, mais si elle est impliquée dans un souci, d'une certaine suspicion : "je ne la connais pas (encore) assez pour savoir si elle plagierait / trollerait / pourrirait le débat, je n'ai pas assez de matière pour l'évaluer" et j'ai par défaut "plus confiance" en une ancienne contributrice qui a déjà débattu/ produit dans le passé.

Bref si un conflit apparaît entre un/des anciennes et nouveaux, il faut activement collecter les infos publiques (et les éventuels témoignages pour les infos non publiques) et prendre le temps d'observer calmement et objectivement la situation, ce qui n'est pas si facile.

Les pires cas étant entre un vétéran voire une personne ayant un rôle à pouvoir ou un historique de titres, et une personne lambda (ou pire une nouvelle venue). Traduit en LinuxFr.org: un conflit entre Bobby1998 le compte historique n°42 ou un des fondateurs ou Maud la modératrice ou moi, et Timeo2016 le nouveau compte. Les risques de conflit d'intérêt / connivence / biais augmentent vu que les personnes qui doivent trancher connaissent probablement bien l'une des parties.

Les *DRAM valent de plus en plus.

Les écoutes judiciaires ne reposent pas sur des IMSI catcher.
Cf https://fr.wikipedia.org/wiki/Agence_nationale_des_techniques_d%27enqu%C3%AAtes_num%C3%A9riques_judiciaires

Et pour les écoutes administratives https://fr.wikipedia.org/wiki/Groupement_interminist%C3%A9riel_de_contr%C3%B4le

• "Karma : 1234 (minimum : 20, maximum : 1234)" -> karma en croissance depuis la création du compte (pas forcément tout le temps, il y a pu avoir des baisses, mais globalement)
• "Karma : -12 (minimum : -12, maximum : 20)" -> karma en décroissance depuis la création du compte (pas forcément tout le temps, il y a pu avoir des hausses, mais globalement)
• "Karma : 42 (minimum : 20, maximum : 1234)" -> à une époque un gros karma, mais il a dû y avoir une série de commentaires/contenus problématiques pour avoir une telle descente en karma
• "Karma : 20 (minimum : 20, maximum : 20)" -> un compte neuf
• "Karma : 1234 (minimum : 42, maximum : -42)" -> contactez l'équipe de développement la plus proche de chez vous pour un dépannage

Ni beaucoup d'argent...

• chore: bump alpine, golang, and golangci-lint versions
• fix: go through fmt, fix, and vet

• chore: bump alpine, golang, golangci-lint and redis versions
• fix: go through fmt, fix, and vet
• deps: gopkg.in/redis.v3 v3.6.4 -> github.com/redis/go-redis/v9 v9.18.0 (no ctx management)

Le 1^er est très classique et peu intéressant.
Le 2^nd est plus intéressant (et probablement connu des habitués du langage Go) mais c'est sympa de passer le code au formateur 'fmt', de moderniser le code avec 'fix' (cf https://go.dev/blog/gofix ) et de chercher des erreurs classiques avec 'vet'.
Le 3^e est une montée de versions du très vieux paquet redis.v3 à redis.v9 (la prod étant en redis-server 8).

(il fallait lire « dans les premiers » au pluriel, corrigé, merci)

L'oubli est basé sur la dernière lecture d'un contenu : par défaut on stocke l'horodatage courant, et pour oublier on supprime l'entrée. Ignorer les nouveaux commentaires nécessiterait une valeur spéciale (par exemple « dans mille ans »), qui ne devrait pas être mise à jour avec l'horodatage courant, et qui soit plus grande que tous les horodatages dans les trois mois à venir.

Key	Type	Value	Expiration	Description
readings/<node_id>/<account_id>	string	seconds since Epoch	3 months	Readings

Par contre ce ne serait pas forcément une bonne idée pour l'équipe de modération (vu qu'il s'agit d'elle ici qui parle) de mettre en sourdine les contenus si elle veut suivre les commentaires.

• ouvrir la dépêche en édition (une fois pour pouvoir copier/coller le vieil HTML)
• créer un tuple paragraphs INSERT INTO paragraphs (news_id,position,second_part,body,wiki_body) values (xxx,1,NULL,'','');
• ouvrir une seconde fois la dépêche en édition pour travailler en Markdown dedans (copier/coller en adaptant la première et la second partie, potentiellement remplacer les liens obsolètes par du Web Archive)
• à la fin éditer la première version au moins pour réattribuer la date et l'auteur initial UPDATE news_versions SET user_id=xxx, created_at='YYYY-MM-DD hh:mm:ss' WHERE news_id=xxx and revision=1;

Merci de rester courtois dans les échanges.

Alors oui c'est triste, mais ça reste un excellent livre. Et j'ai plutôt tiqué sur le "pas manichéenne" : j'espère bien, parce que le coeur de l'ouvrage est l'histoire d'une transition progressive.

• il n'y a pas de plafond au karma lui-même
• 3 comptes actuellement dans la tranche 32768 à 65536 en karma https://linuxfr.org/statistiques/users#stats_karma
• au dessus de 970, on plafonne à 100 avis par jour, cf https://linuxfr.org/aide#aide-karma
• la note par défaut des commentaires plafonne à 10 (pour un karma de 10 milliards, sinon c'est le nombre de chiffres moins deux, donc +3 le max atteint actuel)
• 64k should be enough for anybody
• les plus grosses chutes de karma doivent être entre 7k et 10k de mémoire

Il parle de X a priori.

Corrigé pour la section, merci.

Corrigé, merci.

Le commentaire précédent a été édité pour retirer une qualification non étayée / avérée outrepassant très probablement ce qui est acceptable dans le cadre d'une expression publique, et très certainement ce qui est acceptable sur ce site dans le cadre d'échanges sur un sujet donné.