SChauveau a écrit 389 commentaires

Merci. C'est bon à savoir.

Dans le cas présent, comme l'URL du bit.ly était donné dans un vrai lien vers r.siba-mail.contralia.fr, j'ai juste supposé qu'il renvoyait vers cet domaine donc je n'ai même pas essayé de le résoudre. J'aurai aussi pu le faire de façon sécurisé depuis une VM ou avec wget ou curl.

Je suis président d'un petit club sportif avec une assurance de la MAIF.

Début janvier, je reçois un e-mail (voir ci-dessous) intitulé «MAIF - Signature de votre Avenant au contrat Assurance multirisque Raqvam Associations et Collectivites (Societaire XXXXXXX)» m'expliquant que je dois signer un avenant de contrat relatif à certains risques liés au COVID et que si je ne le fais pas, l'assurance du club pourrait être annulée.

Cela ne surprendra personne mais le club reçoit quasi-quotidiennement des e-mails de fishing (banques, assurances, services administratifs, …) et j'effectue donc quelques vérifications simples pour me débarrasser des fraudes les plus évidentes.

Le texte de l'e-mail est bien rédigé sans grosses fautes d'orthographes. C'est un bon point. Ils indiquent également que je n'ai pas répondu à une précédente demande datant de septembre 2021 et je trouve en effet un ou plutôt 2 anciens e-mails similaires dans mon dossier SPAM.

Maintenant, les gros problèmes qui expliquent pourquoi les précédents e-mails ont fini dans le SPAM!

Pour commencer, l'expéditeur n'est pas maif.fr ou un autre site clairement associé à l'assureur mais no-reply@pes.docapost-bpo.com.

Franchement, ça pue.

Ensuite, le message contient 2 liens.
1. Un lien 'signer' vers le domaine r.siba-mail.contralia.fr avec un URL de plusieurs centaines de caractères (genre encodage en base 73)
2. Un lien 'bit.ly/questions-avenant' à «copier dans la barre d'adresse de votre navigateur web» pour accéder à la FAQ MAIF. Il s'agit en fait d'un autre URL à rallonge vers le domaine r.siba-mail.contralia.fr.

À ce moment de l'analyse, mon détecteur de SPAM vient d'exploser. Il est évidemment hors de question de cliquer sur un lien r.siba-mail.contralia.fr dans un email envoyé par pes.docapost-bpo.com pour la MAIF. La seule chose qui m'a retenu d'envoyer cet e-mail rejoindre ses copains dans le dossier SPAM est que le numéro de sociétaire MAIF était correct. Ce n'est pas une information secrète mais cela ne se trouve pas facilement surtout qu'il s'agit d'un contrat d'assurance assez récent.

J'ai évidemment fait un petit tour par l'espace personnel du club sur https://maif.fr mais je n'y ai trouvé aucune mention d'un avenant de contrat à signer. Cela aurait été trop simple.

Au final, j'ai du perdre une ou deux heures à me renseigner sur contralia.fr et docapost-bpo.com et leurs rapports avec la MAIF. Après moult tergiversations (et croyez moi, j'ai moulté longtemps), je suis arrivé à la conclusion que cet avenant de contrat était réel.

Et la où je ne sais pas si je dois rire ou pleurer, c'est concernant le lien vers la FAQ. Dans le message, il s'agit d'un vrai lien cliquable vers r.siba-mail.contralia.fr (donc non cliquable pour toute personne censée) alors que 'bit.ly/questions-avenant' redirige vers la page https://www.maif.fr/faq-contrat-multirisque-asso-collectivites que je n'aurais pas hésité à consulter si l'URL n'avait pas été caché.

Donc je dis «Bravo à la MAIF, à Docapost et à Contralia».

Dans github, je pense que l'interception du '/' fait parti des raccourcis claviers qui peuvent se désactiver avec : menu Settings, Accessibility, désélectionne 'Character keys' et enfin Save.

Pour gitlab, je n'ai pas de compte donc je ne peux pas tester.

Pour avoir des emojis avec Compose, il suffit de les ajouter dans son fichier ~/.XCompose.

Voici un example (avec un préfixe un peu long mais facile à changer)
https://gist.github.com/m93a/9b2056cb867f08a3fddce0004200841a

Et pour conserver les combinaisons par défaut, on s'assurera que le fichier .XCompose contient une ligne include "%L.

Pour ceux qui ne veulent ou ne peuvent pas installer TAC ou TAC-verif sur leur smartphone, il toujours possible d'utiliser un émulateur Android sur un ordi. Je l'ai fait pour avoir TAC-verif sur le portable Windows d'une association sportive et cela marche nickel (avec Bluestacks).

L'heure et aussi le jour peuvent changer entre les appels de 'date' dans ton script. Par exemple, si il est exécuté à 23:59.999, le dernier appel utilisant 'tomorrow' risque de s'exécuter après minuit, donc le lendemain et ton serveur ne se réveillera pas avant le 'lendemain du lendemain' soit 24 heures trop tard.

Les headers contiennent aussi des variables et fonctions static.
Il est probable que certains changements modifient l'ordre dans lequel les fichiers headers sont chargés. Dans ce cas, l'ordre d'apparition des objets static sera aussi modifié dans le binaire.

Et j'ai aussi trouvé ceci qui semble indiquer qu'Android supporte un nombre limité de tailles pour les icones:

https://tekeye.uk/android/android-icon-size

Est ce que cela ne viendrait pas de ça?

https://developer.android.com/distribute/google-play/resources/icon-design-specifications

When creating your artwork, ensure it conforms to the following:

• Final size: 512px x 512px
• Format: 32-bit PNG
• Color space: sRGB
• Max file size: 1024KB
• …

La différence tient peut être au fait que l'UK est dans un pic essentiellement Omicron alors que la situation Française est un hybride: On vient juste de passer le pic Delta (à 80K cas/jour) mais avec un Omicron qui grandit exponentiellement. En considérant le délai usuel de 1 ou 2 semaines, ont peut supposer que les gens actuellement en réanimation sont principalement des deltas.

En faisant l'hypothèse qu'Omicron est moins sévère que Delta, on peut espérer que la pression sur les hôpitaux va diminuer rapidement avec la disparition du Delta.
Mais bon … la seule chose certaine concernant ce virus est qu'il est difficile de faire des prédictions fiables.

Ou alors c'est juste sous Linux.

# pwd
/home/foobar 
# mkdir C:\users\ccov48
# cd C:\users\ccov48
# pwd
/home/foobar/C:usersccov48

Dans bash et probablement d'autres shells, le caractère \ est «the escape character. It preserves the literal value of the next character that follow.»

Elle avait peut être peur que Linux lui vole un 'c' ou un 'u'.

https://www.youtube.com/watch?v=M-_5JJmNB6E

Et un autre intérêt de cette série est que les dialogues en anglais avec le faux accent français sont assez facile à comprendre pour ceux qui auraient quelques difficultés à comprendre l'anglais.

Après cela n'aidera sûrement pas à améliorer votre prononciation :-)

Dans un genre assez différent, j'aime bien "Allo Allo". Il s'agit d'une série anglaise des années 80 et dont l'action se déroule en France pendant la 2nd guerre mondiale. On suit les aventures de René, propriétaire d'un café, qui se retrouve embarqué contre son gré dans des histoires entre les résistants et les allemands.

C'est un humour très british. Cela ne vole pas haut. Ce qui rend cette série assez unique, ce sont les accents français, allemands et même anglais que prennent les acteur anglais. Les personnages sont très stéréotypés et tout le monde en prend pour son grade.

L'extrait que tu cites est assez bizarre.

it could be calculated that the median corrected infection fatality rate (IFR) was 0.10% in locations with a lower than average global COVID-19 population mortality rate [176].

Pour ceux qui ne comprennent pas l'anglais, cela dit que la fatalité après infection est de 0.10% dans les endroits où la mortalité due au COVID est faible. Cela me semble un peu circulaire. Jetons un coup d'œil à la référence [176]. En fait, ce papier est une méta-analyse de plusieurs études de mortalités et pour une raison que je ne comprends pas vraiment, ils ont regroupés les études en fonction du taux de mortalité. Le paragraphe d'où est issue la citation est

Median corrected IFR was 0.10% in locations with COVID-19 population mortality rate less than the global average (<73 deaths per million as of July 12, 2020), 0.27% in locations with 73-500 COVID-19 deaths per million, and 0.90% in locations exceeding 500 COVID-19 deaths per million.

Ils ont donc gardé le 0.10% en "oubliant" les 2 autres catégories à 0.27% et 0.90%.

Le chiffre de 0.14% avancé dans la phrase suivante est également très suspect. La référence [177] est une page web contenant les enregistrements vidéo de 9 heures de réunions du WHO. Il est possible qu'à un moment quelqu'un sorte le chiffre de 0.14% mais je n'ai pas envie de me taper 9h de réunion pour en être certain.

Pour citer Jean-Pierre Coffe, «c'est de la merde». Aucun article scientifique sérieux n'utilise des citations aussi foireuses.

Cela ne ressemble à aucun des logos classiques d'ARPANET. Le fait qu'il soit bicolore serait plutôt l'indication d'un logo récent (post 90). De plus, ARPANET est un acronyme donc un logo ARPANet n'est pas très logique.

Je pencherai plutôt pour le logo d'une entreprise chinoise donc quasiment invisible car cachée derrière le Great Firewall.

Il est dommage que le texte à droite du logo soit illisible.

Mon opérateur (celui avec le logo rouge) me permet de renvoyer les messages téléphoniques de mon fixe vers mon email. Sans cela, je pense que je les écouterais jamais.

Il y a aussi la description du Projet NERA qui ne veux absolument rien dire.

Il ne faut pas non plus oublier que, sans compter le CO2 ajouté par l'homme, l'effet de serre est important pour la température terrestre. La moyenne à la surface de la Terre est d'environ 14°C mais sans les gaz à effet de serre présents naturellement dans l'atmosphère (H2O, CO2, CH4, …), elle serait d'environ -18°C soit 32°C de moins.

https://www.nationalgeographic.org/article/greenhouse-effect-our-planet/4th-grade/
https://energyeducation.ca/encyclopedia/Earth_Temperature_without_GHGs

Donc oui, la vapeur d'eau est un gaz à effet de serre important. La raison pour laquelle ce n'est pas un problème pour le réchauffement climatique est qu'il y a tellement d'eau liquide sur Terre que l'atmosphère est naturellement saturée de vapeur d'eau. C'est un état d'équilibre et comme le dit Anthony Jaguenaud, rajouter de la vapeur d'eau cause «roulement de tambour … de la pluie».

Voici une analogie qui en vaut une autre. Imaginons une baignoire se remplissant au rythme constant de 1 litre par minute mais pendant une minute, le débit est réduit de 7% soit 0.93 l/m. Le fait important est que malgré une réduction du débit, le volume d'eau dans la baignoire a augmenté constamment pendant toute l'expérience.
C'est pareil, pour le CO2. Une réduction de 7% des émissions ne signifie pas que le taux global de CO2 dans l'atmosphère s'est réduit mais simplement qu'il a augmenté un peu plus lentement que les années précédentes.
Pour faire simple, le taux de CO2 global dans l'atmosphère n'a PAS BAISSÉ (sauf variations saisonnières normales) pendant la crise du COVID et il n'y a donc aucune raison d'observer des effets.

Je doute fort que les 2 itérateurs de std::find puissent être utiles au compilateur.

L'itérateur est un concept de haut niveau qui est probablement inconnu du compilateur. Il faut bien différencier les règles définies dans les APIs et celles définies dans le langage lui même (et la lib std de c++ est une api). Le compilateur C++ n'a normalement aucune idée de la sémantique associée aux std::iterator, std::string, std::vector, etc. Il ne voit que des classes et ne peux faire aucune hypothèse sur la sémantique. Si demain, je renomme tout les 'iterator' en 'foobar' cela devrait fonctionner pareil.

C'est différent dans d'autre langages tels que Fortran où de nombreuses fonctions sont intrinsèques au langage et ont donc une sémantique connue du compilateur.

Cela ne signifie pas que le compilateur C++ ne peut jamais exploiter ce genre d'information. En général, il faut que le programmeur fournisse l'information explicitement, par exemple, sous la forme d'un pragma ou d'un attribut.

Je n'ai pas regardé dans les compilateurs actuels, mais en règle général, la vectorisation n'est pas possible dans les boucles non-pures, c'est à dire contenant un break ou un return conditionnel. Je ne dis pas que c'est toujours impossible mais c'est rarement intéressant donc les compilateurs n'essayent même pas.

Je tiens aussi à signaler que strictement parlant, la vectorisation SSE proposée ici est illégale. Le problème est que les données sont lues par blocs de 4 int (donc 16 octets). En pratique, cela signifie que la boucle vectorisée peut lire 1, 2 ou 3 int supplémentaire. Cela pourrait causer un dépassement de tableau et donc un 'segfault'. Un bon compilateur ne fera pas cela.

Remarque: Le fait que les indices lus soient tous inférieurs à n n'a pas d'importance car, du point de vue du compilateur, l'argument n n'indique pas la taille du taille du tableau. Par exemple, si l'utilisateur est certain que son tableau contient au moins une fois la valeur, il pourrait décider d'utiliser n=INT_MAX.

J'imagine qu'ICC fait quelques tests supplémentaires sur les alignements des pointeurs dans son implémentation de std::find(). Cela entraîne évidemment un petit surcoût qui peut ne pas être négligeable quand n est petit. C'est une information que le compilateur ne possède généralement pas (sauf inlining ou analyse inter-procedurale).

Il ne faut pas non plus oublier que pour respecter les conventions d'appels, les codes vectorisés doivent aussi sauver et restaurer plus de registres (push/pop dans la pile). C'est un autre surcoût qu'il faut prendre en compte pour décider si la vectorisation est intéressante.

PS: Dans ton benchmark, toutes les fonctions sont dans le même fichier. Il n'est pas impossible qu'ICC réussisse à optimiser std::find en inlinant systématiquement tout les appels de fonctions (donc potentiellement plus d'info sur n et sur l'alignement des données). Obtiens tu les même perfs quand find_int_cpp() est compilé dans un fichier séparé?

Trouver des bugs c'est bien mais as tu essayer de remonter l'information vers les responsables du site? Pour rappel, un bug inconnu des développeurs n'existe pas même si il affecte des milliers d'utilisateurs.
Après, il est vrai qu'il n'est pas toujours facile de trouver comment remonter l'information. C'est fini l'époque où chaque site web proposait un formulaire de contact ou un email webmaster.

En effet. Un floutage réduit drastiquement la quantité d'information disponible alors qu'un filtre comme swirl se contente de déplacer les pixels en conservant la quasi totalité des informations. Inverser un floutage me semble donc très difficile ou même impossible.
Par contre, cela peut probablement s'envisager sur une vidéo. Un algorithme futé devrait pouvoir reconstituer assez fidèlement les détails d'un visage en combinant plusieurs dizaines ou centaines d'images floutées.
D'une certaine façon, c'est déjà ce que fait le cerveau avec les vidéos en basse résolution. Individuellement chaque image peut sembler floue et bruitée mais l'animation fait apparaître des détails.
Ce genre de technique existe aussi en astronomie où des centaines d'images de mauvaise qualité peuvent être combinées pour produire une image haute résolution.

Ce n'est pas une mais 666 lois qui viennent d'être promulguées au Texas.

L'impression PDF de Firefox produit un PDFs contenant une image bitmap avec une résolution de 300 ppi. La qualité d'impression sera donc assez moyenne mais c'est probablement suffisant pour un relevé bancaire ou une attestation de la sécu.