Matthieu Moy a écrit 3254 commentaires

Pas besoin de point d'intérêt spécifique pour avoir un numéro de rue dans openstreetmap !

Sans pousser au gaspillage, on peut raisonnablement dire « j'ai envie d'économiser, mets une qualité d'image faible » ou « j'ai besoin de bonne qualité, j'accepte une vidéo plus grosse » sans viser pile une taille donnée. Avec un support de type CD, c'est très bête d'avoir une vidéo de 400 Mo parce que les 300 Mo qui restent sur le support ne seront utilisées par personne (donc on aurait pu avoir une meilleure qualité gratos), et encore plus bête d'avoir une vidéo de 700+epsilon Mo, parce que là ça ne tient plus.

Je ne crois pas qu'on puisse avoir les deux mêmes, justement un intérêt du système est que les clés sont uniques et non-duplicables. Et l'intérêt d'avoir deux clés différentes, c'est qu'on peut révoquer l'une sans révoquer l'autre si on la perd.

Mais il suffit d'associer les deux clés au compte (ça se fait en quelques minutes et sans difficulté), et si on en perd une d'associer la 3ème clé tout juste achetée au compte, pour remplacer la première perdue.

Si tu chiffres ton disque dur avec, aucune idée. Mais pour les authentification 2FA classiques, l'idée c'est de toujours avoir plusieurs solutions pour s'identifier. Le premier conseil simple : ne jamais acheter une clé d'authentification toute seule, mais en acheter deux (une au porte clef, une qui reste à la maison bien au chaud). Et dans la plupart des cas, les services qui utilisent 2FA proposent d'autres moyens que la clé, par exemple ça peut être la clé ou le smartphone avec une application spécifique ou une appli TOTP générique. Et à peu près partout où j'ai activé une 2FA, le site web m'a donné une dizaine de tokens à usage unique à stocker en sécurité (par exemple à imprimer et ranger dans un endroit physiquement sécurisé). Mais contrairement à un mot de passe, c'est à usage unique, donc si on doit les utiliser, ça ne peut être que pour un dépannage ponctuel ou le temps de mettre en place une autre solution de sécurité.

la moindre falsification se verra sauf faille de sécurité. […] le fautif.

… mais une fois que tu auras vu qu'il y a falsification, il te faudra un moyen de savoir qui est l'authentique, et qui est « le fautif » (je te cite sur « le », mais le problème est justement que ça peut être « les »). Si tu as X utilisateurs qui disent que c'est eux qui ont la bonne version, et Y utilisateurs qui te disent que non, c'est eux, comment décides-tu qui as raison ? Si tu monitores le noyau Linux, fastoche, tu écoutes Torvalds (parce que c'est lui en qui tu as confiance, on en revient à la notion de confiance). Dans le cas général, il te faut un protocole pour trouver un consensus. Git ne répond pas à cette question et n'a jamais cherché à le faire. Le protocole peut être un vote à la majorité (X > Y), mais à ce moment là tu es très vulnérable aux comptes multiples (je crée 1000 utilisateurs GitHub, ou 1000 adresses emails qui prétendent que le mauvais hash est l'authentique, et la majorité se met à prétendre un mensonge). Tu peux imaginer des protocoles plus évolués, et si tu le fais le résultat va probablement mériter de s'appeler une blockchain (qui en gros fait un vote à la majorité, mais à la majorité de la puissance de calcul dans le cas du proof-of-work et à la majorité de finance en proof-of-stake).

Ça n'enlève rien à Git, qui est un très bon outil pour ce pour quoi il a été fait, et ça ne fait pas de la blockchain une techno miracle. Mais prétendre que le chaînage des hash de Git te donne les mêmes garanties qu'une blockchain, c'est avoir une vue très très partielle du fonctionnement et des garanties offertes par les blockchain.

Un commit est horodaté, et ses commits-fils pointent vers lui (leur hash dépend notamment du/des commit(s) parent(s)). En quoi la blockchain ferait-elle mieux que git (ou autre DVCS) ?

Les timestamps des commits sont trivialement falsifiables. Le chaînage des commits de Git te donne des garanties intéressantes : si tu fais confiance au dernier commit, tu peux faire confiance à tous ses ancêtres. Mais si tu ne fais pas confiance au dernier commit, tu n'as rien du tout. Si je te dis « fais un git clone de mon dépôt https://example.com/git/, tout ce qu'il y a dedans est authentique », je peux très bien tricher, j'ai peut-être un commit daté d'il y a 10 ans qui dit que Mr XXX a le diplôme YYY, et que Mme ZZZ a transféré la somme TTT à Mr UUU, alors que c'est moi qui viens de forger ce commit. Ce que t'apporte une blockchain, c'est d'avoir un consensus entre les participants qui te dit en gros « les ancêtres du commit XYZ sont authentiques ». Tu peux avoir le même genre de chose avec Git et les commits signés via GPG si tu fais confiance à la personne qui signe le commit, mais comme expliqué dans d'autres commentaires ici, l'intérêt de la blockchain est de ne pas avoir besoin de faire confiance à une personne en particulier.

Des gros clusters, oui, mais sauf erreur de ma part ça fait un moment que ce n'est plus rentable de monter du bitcoin sur cartes graphiques, vu que c'est un calcul assez facile à accélérer sur des ASICS (contrairement à Ethereum qui avait choisi un calcul memory-bound qui a donc surtout besoin de RAM rapide, qu'on trouve dans les cartes graphiques).

Différence minime, mais là on parle de gens qui ont des algos répartis sur des data-center de taille déraisonnablement grandes, donc des améliorations minimes ont un vrai impact sur la facture d'électricité et celle d'achat de machines.

La FAQ de Carbon est assez parlante sur ce point : Why not a garbage collected language, like Java, Kotlin, or Go? (notez l'emphase sur le mot « contrôle », pas sur « performance »).

Faudrait penser à changer Wikipedia https://en.wikipedia.org/wiki/Open-source_software

Et aussi les dictionnaires, parce que ouvert et disponible, ce sont deux mots assez différents dans ceux que j'ai pu consulter.

trouver des erreurs sans des binaires sans avoir les sources.

Ce qui est assez fort en vrai ! ;-)

Mais plus sérieusement, c'est une force de ces outils : on peut les utiliser dans rien changer au build (genre en tant qu'enseignant, juste ajouter valgrind devant la ligne de commande d'exécution sans avoir à subir les atrocités que l'étudiant a écrit dans son Makefile…).

J'ai l'impression qu'il manque un test qui est pourtant important pour distinguer les approches/outils :

#include <stdio.h>

int main(int argc, char** argv)
{
    int values[4] = {1, 2, 3, 4};
    int other_values[4] = {10, 20, 30, 40};
    printf("%d\n", values[4]);
    return 0;
}

L'exécution du code compilé avec GCC va déclencher un accès à other_values[0] qui est "légitime" au sens où c'est une valeur qui existe, qui est proprement initialisée. Valgrind n'y voit que du feu (et ne pourrait pas trop faire autrement), mais address sanitizer ajoute le check de débordement de tableau qui va bien à la compil et trouve l'erreur à l'exécution.

Oh, ben, c'est-à-dire, la polysémie, moi j'ai jamais été mais si on me paye le voyage, oui je veux bien.

Cf. discussion ici : https://linuxfr.org/forums/programmation-python/posts/bibliotheque-verification-passe-sanitaire

La première chose à faire si tu trouves une alternative, c'est de vérifier qu'elle est légale (la situation a peut-être changé depuis la dernière discussion, mais tu risques gros si tu ne vérifies pas).

Attention, aux dernières nouvelles TAC verif était la seule application autorisée :

https://www.liberation.fr/checknews/que-risque-la-personne-qui-controle-le-pass-sanitaire-si-elle-nutilise-pas-tousanticovid-verif-20210820_XTBVEUSHZRHMJDQT4QS5JIRCRM/

Je suppose que c'est pour éviter que les gens utilisent un clone qui enregistre les QR codes en plus de les vérifier.

Le \0 du -printf est un début, mais il faut aussi apprendre au reste du pipe à ne découper que selon les \0 et à ignorer les \n. Pour l'instant sort -n va joyeusement trier les lignes et non les fichiers, et tail -n 1 coupera toujours la dernière ligne même si ce n'est que la moitié d'un nom de fichier.

Pour être robuste : ne pas programmer en shell ;-). Utiliser la sortie de ls pour autre chose que l'afficher à un humain, c'est mal™.

Dans pas mal de cas, on peut faire des trucs robustes à coup de find ... -print0, qui utilise \0 comme délimiteur (et ça, c'est effectivement interdit dans un nom de fichier), mais je ne vois pas d'équivalent de ls -t avec find, ni d'équivalent de -print0 pour ls, donc je ne vois pas de solution raisonnable en shell.

Si on veut pinailler, on notera que cette solution ne marche pas si le nom de fichier contient un retour charriot.

(mais il faut avouer que mettre des retours charriots dans ses noms de fichiers, c'est pas très utile et ça sert surtout à casser les scripts shell pour le plaisir ;-) )

D'autant plus que les chiffres officiels sont (étaient ?) très largement sous-estimés.

Si on en croit cet article, « sous-estimé » est un euphémisme :

https://www.rfi.fr/fr/asie-pacifique/20210720-inde-le-nombre-de-morts-li%C3%A9-au-covid-19-pourrait-%C3%AAtre-10-fois-sup%C3%A9rieur-au-bilan-officiel

Et si le CDC n'est pas assez crédible :

Efficacy and effectiveness of COVID-19 vaccines against SARS-CoV-2 infection: interim results of a living systematic review, 1 January to 14 May 2021.

Euh, oui, j'avais fait l'hypothèse que c'était évident pour tout le monde, mais s'il faut le préciser : une personne non infecté n'est pas contagieuse. Donc la protection contre l'infection implique une réduction de la transmission. Le meilleur moyen de ne pas refiler le virus à son entourage, c'est de ne pas l'attraper soi-même.

Et oui, on peut ajouter à ça la réduction de la charge virale qui fait que même infecté, un vacciné est moins contagieux qu'un non-vacciné (ça a été vérifié et mesuré sur la transmission des soignants à leur conjoint au Royaume-Uni, flemme de retrouver la référence). Mais même sans cet effet, l'efficacité du vaccin sur la transmission est déjà très clair.

Le site du CDC indique que les vacinnés Pfiwer ont une charge viral moindre,

Tu as regardé la table 1.b je suppose, mais regarde la table 1.a. Je compte 15 études « real-world » sur la protection des vaccins contre l'infection. Le fait qu'il y ait des études sur la charge virale n'enlève rien aux études sur l'efficacité du vaccin.

Je prends arbitrairement la première ligne qui parle de protection après la deuxième dose : https://www.medrxiv.org/content/10.1101/2021.04.08.21255135v1 « Conclusions and Relevance Ongoing vaccination efforts are preventing SARS-CoV-2 infection in the general population in California. Vaccine hesitancy presents a barrier to reaching coverage levels needed for herd immunity. ».

Et je me permets de re-citer la page du CDC qui me paraît quand même assez peu ambigu, « Multiple studies from the United States and other countries demonstrate that a two-dose COVID-19 vaccination series is highly effective against SARS-CoV-2 infection (including both symptomatic and asymptomatic infections) ».

Ce qui est vrai, c'est qu'il y a très peu d'études cliniques randomisées en double aveugle. C'est dommage, mais ça s'explique assez bien : les tests ont été fait au plus vite en priorisant l'étude de l'efficacité contre les formes graves, et maintenant qu'on a ces résultats ça serait assez délicat de refaire des études en injectant un placébo à des gens qui auraient pu être protégés par le vaccin. Mais il y a quand même une étude intéressante (toujours sur la page citée ci-dessus) : « In the Moderna trial, among people who had received a first dose, the number of asymptomatic people who tested positive for SARS-CoV-2 at their second-dose appointment was approximately two-thirds lower among vaccinees than among placebo recipients (0.1% and 0.3%, respectively) ». C'est un test limité, ça ne teste que la première dose, mais c'est quand même bien une étude sur l'efficacité contre l'infection.

Pour commencer, aucune étude ne prouve un quelconque effet positif des vaccins sur la transmission du virus

Si, au contraire, il y en a des dizaines ! Voir par exemple une liste sur le site du CDC. Regarder les lignes « infection », et je cite : « Multiple studies from the United States and other countries demonstrate that a two-dose COVID-19 vaccination series is highly effective against SARS-CoV-2 infection (including both symptomatic and asymptomatic infections) ».

Et si on veut rester de ce côté-ci de l'atlantique, l'institut pasteur qui estime qu'une personne vaccinée a 12 fois moins de chances de transmettre le virus.

il faudrait tout de même multiplier par 20

C'est le problème avec les exponentielles : multiplier par 20, c'est multiplier par 2, un peu moins de 5 fois de suite. Dans un contexte où tout double environ tous les 15 jours, ça arrive en un peu plus de 2 mois si la progression ne s'arrête pas.

De la même manière, mulpliplier par 250, c'est encore multiplier par 2, 8 fois de suite, ça arrive en environ 4 mois, toujours si la progression ne s'arrête pas.

On souhaite tous que mon « si la progression ne s'arrête pas » soit une hypothèse qui ne tienne pas, mais les deux moyens qu'on a trouvé pour arrêter, c'est les restrictions de libertés ou l'immunité collective (via vaccin ou contamination).

Mais pour la saturation des hôpitaux, serais-tu d'accord pour dire que, même aujourd'hui, on ne devrait plus avoir le problème car les personnes "à risques" seront vaccinés ?

La question n'est pas de savoir si moi je suis d'accord, mais ce qu'en pensent les gens dont c'est le métier.

L'institut pasteur n'est pas d'accord avec toi : https://modelisation-covid19.pasteur.fr/evaluate-control-measures/impact-partially-vaccinated-population/

« […] un pic d’hospitalisations similaire au pic de l’automne 2020 pourrait être observé en l’absence de mesures de contrôle »

Je te laisse aller lire le reste de la page, c'est un résumé compréhensible par un non-spécialiste très instructif de l'étude.

Les chiffres en Angleterre sont quand même très encourageants,

Je t'invite à regarder quelques courbes :

• Nombre de décès quotidien, sur une échelle en log
• Nombre de patients en soins intensifs, toujours sur une échelle en log
• Nombre d'hospitalisations quotidiennes, encore une échelle en log

Laquelle de ces courbes trouves-tu encourageante ?