Benoît Sibaud a écrit 10399 commentaires

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

Correction fusionnée et déployée.

$ apt-cache search typespeed
typespeed - Éliminez les mots traversant votre écran en les tapant correctement
xletters - saisie au clavier de mots en chute libre avant leur atterrissage

Le premier pour moi (je ne connaissais pas le second). Et j'avais initialement appris à taper sur une machine à écrire électronique (écran monoligne) en recopiant/résumant des règles de jeux de rôle il y a fort fort longtemps.

Et au final je ne crois pas que ça soit la vitesse de frappe soit un élément si important que ça (probablement passé un certain plancher / minimum) : il faut savoir quoi taper à un moment, que ça soit de la programmation, l'écriture d'un roman, une liste de courses ou un poème pour sa banque, ce qui implique des cycles arrêt de la saisie / réflexion / reprise de la saisie, très significative dans la vitesse moyenne de frappe.

Eau, air et cultures sont vitaux à très court terme.

Pétrole et minerai sont très utiles dans nos sociétés (le premier étant plus facile à remplacer que le second).

Après il y a des services en ligne/numériques vitaux : les appels d'urgence, probablement le temps et le positionnement satellite indirectement, les communications pour les forces de l'ordre et de secours, la météo (vigicrues, etc.), la grille électrique et son pilotage, le contrôle aérien si on veut des avions, le contrôle maritime si on veut des bateaux, le contrôle et les alarmes de centrales énergétiques et autres usines Seveso2, etc.

Faut sans doute se méfier d'un biais médiatique qui résumerait le "en ligne" à X/TikTok, Netflix/Prime, Youtube ou ChatGPT (qui ne sont pas vitaux).

Visiblement un souci sur la validation des adresses ajoutées récemment (dans le cas où l'on n'a pas encore d'adresse définie justement…). Correction temporaire en place.

Merci de rester courtois dans les échanges. La dernière phrase du commentaire précédent a été supprimée.

Merci de rester courtois dans les échanges.