Glandos a écrit 1345 commentaires

Encore faudrait-il que l'éditeur ait la même interprétation que le compilateur… C'est pas gagné :)

Oui, c'était un peu mon analyse, mal exprimée.

La reconnaissance faciale sur photos, ça coûte cher, et ça rapporte peu d'argent. Et en plus, c'est mal vu, donc autant l'arrêter.

Le cœur de métier de Facebook et Meta, c'est de vendre des profils ciblés aux annonceurs. Et pour cela, tout est bon. Savoir que telle personne est un peu fatiguée aujourd'hui permettra de lui annoncer des p'tites pilules dynamisantes. Savoir qu'il a été en vacances avec sa famille et Tata Micheline, c'est probablement moins rentable.

Je sais que c'est de la sur-simplification, et de la rétro-analyse. Moi, ça me semble crédible.

https://www.lemonde.fr/pixels/article/2021/11/02/facebook-va-mettre-fin-a-la-reconnaissance-faciale-sur-sa-plate-forme_6100707_4408996.html

En bref : les photos mises en ligne ne seront plus analysées pour y trouver les personnes se trouvant dessus.
Les anciennes données seront supprimées.

C'est assez nouveau de la part de Facebook d'aller dans ce sens-là, mais peut-être que le ratio bénéfice-risque n'est pas bon. Après tout, ça ne rapporte pas forcément grand-chose de savoir qui est sur la photo…

Je me suis posé la question aussi, mais d'après l'exemple, même si le souci est multiple, il vient surtout le problème des commentaires.
La plupart des langages de programmation utilise l'ASCII (globalement hein), ou en tout cas, l'alphabet latin, donc de gauche à droite.

Mais les gens, en commentaire, mettent ce qu'ils veulent : arabe, japonais, et j'en oublie, de droite à gauche. Donc, quelque part, il faut bien inverser le sens…

/me invoque la modération pour changer le titre en :

Le site gouvernemental de la Sécurité Routière force la surveillance

Ah, j'ai un problème de communication quand je suis outré / choqué / en colère.

C'est mal. C'est mal, parce que ça revient à faire tout ce que je critique chez les monopoles des réseaux sociaux : jouer sur les émotions fortes.

Mais du coup, le site ne marche pas sans Javascript, et sans rien dire.

Alors, testons : « Le site gouvernemental de la Sécurité Routière force la surveillance » ?

C'est vraiment mentionné que c'est dépendant de la commune de circulation. En tout cas, dans l'article du Monde.

Mais merci pour le retour d'expérience.

Et pour un Linux qui a marché, combien de projet ont échoué derrière ?

OK, je découvre des problèmes non anticipés, merci pour le retour d'expertise. Il se peut que ça me serve un jour.

Du coup… j'ai envie de suggérer quelque chose : stocker l'identité en deux champs distincts.
1. L'identité réelle, pour affichage, pour les humains, l'État Civil.
2. L'identité normalisée pour une machine, permettant de faire des recherches.

Exemple avec Marie-Stéphanie d’Alembert:
1. Marie-Stéphanie d’Alembert
2. marie stephanie d alembert

J'y ai même mis l'apostrophe typographique dans le 1. Cette étape est faite lors du stockage. Lors de la requête, le client transforme le champ de requête en forme normalisée, envoie la requête au serveur qui n'a qu'à faire un WHERE prenom_norm LIKE '%request%';.

Les index marchent, c'est au client de se payer le coût de la transformation.

Alors… qu'est-ce que j'ai pu oublier qui viendrait contredire une efficacité de ce modèle ? ;)

En gros, les caractères diacritiques ne sont pas affichable, sauf l'apostrophe et le tiret. Et lors d'une recherche patient, il ne faut tenir compte ni de l'un, ni de l'autre.

Pour des recherches efficaces de personnes, il faut donc avoir l'identité sans ces caractères. Pour un affichage avec ces caractères, il faudrait donc persister la variante avec caractères diacritiques, soit, grosso modo, stocker 2x le nom et le prénom des personnes, l'une à la forme normalisée et l'autre à des fins d'affichage. Ceci, afin de limiter les doublons.

Je répondrais : LC_COLLATE. Et en Javascript : localeCompare. C'est aussi possible en Java, et même en C++

Donc : on stocke la forme officielle. Et quand on fait une recherche, on utilise la comparaison qui sait comparer des noms dans la langue.

L'identité de quelqu'un, c'est important. C'est l'outil qui doit s'adapter à l'humain, et pas l'inverse.

J'ai déjà entendu des gens parler du « tiret du six » sans avoir jamais compris le truc. Si quelqu'un peut me passer la référence, j'en suis preneur. Ça doit être typiquement français non ?

Oui, c'est lié au clavier AZERTY de France. Sur la touche « 6 » accessible en majuscule, il y a le « - ». Et sur le « 8 », il y a le « _ ». C'est pour lever l'ambiguïté sur les deux que les gens parlent de « tiret-du-6 ». Pour les typographes, ça n'a aucune espèce d'ambiguïté, mais… c'est comme ça.

https://www.beeper.com/ en fait un peu plus, pour 10$ par mois.

C'est un fait objectif, je n'ai vraiment pas d'avis sur la pertinence de ces tarifs.

Certaines entreprises commerciales ont choisi le même chemin : https://www.budde.de/

Tu voulais dire : « À ma connaissance » ?

Non, c'est juste pour troller le trolleur en chef ;)

Je sens comme une pointe d'ironie, je me trompe ?

Je vais être le premier à reconnaître que mettre des diacritiques pour faire joli, c'est un peu du même acabit que la complexification de l'orthographe à des fins élitistes.

Mais enfin, les diacritiques, quand elles changent le son des phonèmes, c'est important. Si on vire les diacritiques en vietnamien, ça devient n'importe quoi. Certes, le français est moins ambigu, mais quand même.

Les administrations tardent réellement. Voir l'excellente ressource http://accentuez.mon.nom.free.fr/index.php

On trouvera donc sur http://accentuez.mon.nom.free.fr/Proces.php :

La Banque postale a justifié de l'impossibilité technique de porter les signes diacritiques sur les noms patronymiques mentionnés en majuscules dans les documents automatisés générés informatiquement ; qu'ayant ainsi caractérisé l'obstacle objectif à la correction demandée, les juges du fond ont pu en déduire que, dans cette limite, la banque se trouvait déchargée de son obligation de faire, justifiant dès lors légalement leur décision

Je dis ça, je dis rien :)

It’s even more disappointing looking at the source code to see that support for it was ~1-2k lines of code

C'est le moment de forker :)

Merci pour ce résumé. J'ai vu passer ça grâce à YTCC qui est une chouette interface TUI à vos abonnements, et qui lit les vidéos à l'aide de MPV.

Ceci dit, je charge tout en 480p, et j'ai pas beaucoup senti la différence du coup. Dès fois, ça laggue un peu. Mais quitte à en faire bondir beaucoup ici, regarder une vidéo de e-penser, de Fouloscopie ou de Technology Connections en 1080p, c'est … pas franchement différent :)

David Carlos Gomes Inigo Non Complet

Comme ça ? ;)

Saint-Quentin-la-Motte-Croix-au-Bailly : trente-huit caractères, soit quelques-uns de trop pour tenir sur le nouveau format de la CNI, plus petit que le précédent.
[…]
Avertie, la commune a finalement conseillé à toutes les personnes dont les demandes n’étaient pas urgentes d’attendre que le ministère de l’intérieur règle le problème – qu’il n’avait visiblement pas anticipé. « Des évolutions techniques sont en cours et devraient être opérationnelles avant la fin de l’année 2021 », a-t-on expliqué place Beauvau au Courrier Picard, en affirmant que de « l’espace supplémentaire » serait libéré pour les noms de commune particulièrement longs.

C'est beau. Et pourtant, y a pas grand chose à normaliser sur une CNI.

Pendant un temps, la vérification était faite sur les 5 derniers mots de passe. Je changeais 5 fois de mot de passe d'affilée.

Aaaah oui, j'ai ça aussi dans mon organisation. Et la question se pose alors… Oui, vous la sentez venir ? Hmmmmmm…

Comment détecter que des sous séquences sont identiques entre deux mots de passe ?

J'ai envie de croire très fort que c'est une comparaison qui est faite en mémoire vive, lorsque le système possède l'ancien et le nouveau mot de passe que l'utilisateur vient de saisir dans le formulaire de changement.

Mais honnêtement, j'ai plutôt envie de penser que c'est plus mal fait que ça. Par contre, j'ai pas trop envie de chercher comment ça pourrait être mal fait :)

Je retiens la R24 (page 30) :

Si la politique de mots de passe exige des mots de passe robustes et que les systèmes
permettent son implémentation, alors il est recommandé de ne pas imposer par dé-
faut de délai d’expiration sur les mots de passe des comptes non sensibles comme les
comptes utilisateur.

Et la R25 complémentaire :

Il est recommandé d’imposer un délai d’expiration sur les mots de passe des comptes
très sensibles comme les comptes administrateurs. Ce délai d’expiration peut par exemple être fixé à une durée comprise entre 1 et 3 ans.

Donc bientôt, fini les mots de passe Windows des entreprises qui expirent tous les 3 mois.

On y croit !

Ce programme est vraiment efficace. Disponible sur https://qarmin.github.io/czkawka/ il n'est pas aisé à prendre en main, mais ça fait plein de trucs. Trouver les similaires, trouver les identiques, et plein d'autres choses.

Visiblement, ce sont des mandats judiciaires exigeant de Google de donner des informations sur des gens ayant fait certaines recherches. D'où le surnom de keyword warrants.

Donc, la police ne va pas débarquer en mode SWAT. Mais il ne faut pas minimiser non plus, sans toutefois courir partout en hurlant. Le gouvernement américain utilise les sources d'informations là où elles sont. Google n'est pas obligé de garder l'historique de recherche des gens.

Oh, et puis bien sûr, ça ne concerne pas que Google : Microsoft (avec Bing) et Yahoo ont eu le même genre de requête.