Matthieu Moy a écrit 3254 commentaires

le but est-il d'atteindre zéro mort, zéro malade ?

Il me semble que le but qui a toujours été affiché est d'éviter la saturation des hôpitaux.

Pendant la vague de novembre, on était en gros à :
- 50.000 cas officiels par jour, probablement environ 100.000 cas réels car tout le monde n'a pas été testé
- un peu plus de 15000 hospitalisations par jour
- 2500 admissions en réanimations par jour
- 500 décès par jour

On retrouve le chiffre de 0,5% de létalité qu'on lit ici et là.

Les hôpitaux ont été très chargés, mais ont pu soigner les malades. Que se serait-il passé si ça n'avait pas été le cas ? Est-ce qu'on peut vraiment espérer que les malades admis en réanimation auraient pu guérir tranquillement si à la place on les avait renvoyés chez eux ? Inversement, si on considère qu'un malade admis en réanimation n'a aucune chance de survie sans soin, ça veut dire qu'avec des hôpitaux saturés on passerait à 2.5% de létalité, et ça c'est en faisant l'hypothèse que les 15000 autres hospitalisés s'en seraient sortis sans soins.

L'autre réponse que j'ai reçu est "pour protéger les autres"

Rien que protéger les autres d'un système de santé saturé par le COVID, ça vaut déjà la peine. Une personne vaccinée contre le COVID peut tout à fait avoir besoin d'être hospitalisée pour un autre problème de santé, et cette personne appréciera d'avoir un lit d’hôpital disponible si elle en a besoin.

Et même s'ils sont très efficaces, les vaccins ne le sont pas à 100%. Une personne vaccinée est d'autant mieux protégée que 1) son entourage est aussi vacciné (la charge virale diminue avec le vaccin, donc une personne contaminée vaccinée est moins contagieuse) et 2) le taux d'incidence est faible, ce qui est évidemment lié à l'immunité collective et aux vaccins.

on peut toujours se protéger soi-même en conservant les gestes barrières,

Oui, on a montré pendant le premier confinement qu'en restant cloîtrés chez soi on pouvait aller d'un R0 d'environ 3 à un R effectif de 0,5. Cette année, on a un variant deux fois plus contagieux, donc en étant un tout petit peu plus stricts qu'au premier confinement on peut maintenir un R effectif en dessous de 1.

Ou alors, on peut utiliser les vaccins.

Si tu mets du contenu sur YouTube pour la visibilité, ce que tu cherches ce n'est pas les gens qui cliquent sur le lien, mais ceux qui te mettent un pouce en l'air et qui s'abonnent pour que tu sois bien référencé.

Ça se fait effectivement pour la sécurité, y'a des travaux autour de ça au CEA par exemple.

Pour la sûreté dans le spatial, je ne crois pas qu'on arrive à se passer de redondance matérielle : les fautes matérielles liées au rayonnement ont tendance à se propager et à faire sauter plusieurs choses d'un coup. Mais l'étude des interactions entre les mécanismes de tolérance aux pannes hard et le soft est un sujet de recherche intéressant et actif par contre.

J'en ai eu un autre assez joli : un utilisateur n'arrive pas à se connecter à GitLab, erreur HTTP plus ou moins incompréhensible si on essaye de charger la page de login. Ça marche depuis un autre PC, mais même erreur quelle que soit le browser et la connexion internet.

Problème résolu en remettant le PC à l'heure.

L'explication est que le serveur envoyait un cookie avec date d'expiration très proche dans le futur, en se basant sur l'heure du serveur. Si le client avait une horloge mal réglée, le cookie arrivait avec une date d'expiration passée de point de vue du client, et paf.

Alors là, désolé, on sort de mon domaine de compétences !

En théorie, totalement d'accord. Mais en pratique, ton algo tournera sur du hardware, non ?

Qu'est-ce que tu appelles relativement dur en théorie ? […] Est-ce que tu veux dire que ces tests sont en pratique trop lents ?

Oui.

Le papier « Primes are in P » est un résultat théorique majeur, mais qui à ma connaissance n'a pas vraiment changé la pratique (disclaimer : je ne suis pas spécialiste).

Dans la pratique, tout algo est probabiliste, parce que la probabilité de bit flip arbitraire dans un ordinateur n'est jamais nulle. Un algo probabiliste avec probabilité d'erreur 10^-1000, c'est aussi fiable qu'un algo déterministe en pratique. Et si on veut faire de la crypto derrière, la fiabilité de la crypto est aussi probabiliste (un attaquant a une proba non-nulle de deviner la clé secrète du premier coup, mais la proba est assez faible pour qu'on prenne ce risque sans problème). Le fait qu'un algo soit probabiliste n'est pas un problème en pratique tant qu'on peut rendre la proba d'erreur arbitrairement petite. Le fait qu'un algo comme AKS soit en O(nb-bits⁶ ) en temps, ça par contre c'est un problème, presque autant qu'un algo exponentiel.

Et beaucoup de recherches en cours sur la « crypto post-quantique ».

Si P = NP, c'est quand même gagné pour la factorisation en temps polynomial.

Si P != NP, effectivement, ça ne dit pas si la factorisation est polynomiale ou non.

Trouver des nombres premiers et factoriser des nombres en facteurs premiers, ce sont deux problèmes très différents. Trouver des grands nombres premiers, c'est relativement dur en théorie mais assez facile en pratique grâce aux tests de primalité probabilités (qui permettent d'assurer avec probabilité arbitrairement proche de 1 qu'un nombre est premier), et c'est ce qu'on fait quand on génère des clés RSA par exemple. Factoriser un nombre (trouver x et y étant donné x*y), c'est beaucoup plus dur.

D'mon temps « j'ai pensé à héberger mon logiciel libre chez Microsoft, par réflexe », c'était un oxymore. Le monde a changé ;-).

Non, dans les deux cas ce sont des langages de balises qui ressemblent de loin à Markdown, mais chacun avec ses subtilités et une syntaxe différente et incompatible de markdown.

Sur Linuxfr !

Oui, c'est clair que 20€ ça n'est rien, mais si on imagine quelques dizaines ou centaines de personnes prêtes à mettre 20€ chacune, on peut imaginer que quelqu'un réussisse à se salarier en traitant quelques bugs par semaine. Mais y'a un problème de bootstrap pour en arriver là : pour que ça marche, il faut trouver beaucoup de gens prêts à mettre des sous, que les systèmes de bounties décollent, sinon tu resteras seul sur ton bug avec tes 20€. Et tant que participer à un système de bounty consiste à rester tout seul avec ses 20€ sur un bug qui n'intéresse aucun développeur, le système ne décolle pas.

Pour le financement à petite échelle, ce qui marche un peu dans certains cas c'est le financement régulier de développeur (https://www.patreon.com/, https://liberapay.com/, https://fr.tipeee.com/, …). On reste sur le principe « pas un gros budget par personne, mais ça marche si beaucoup de gens donnent », et ça permet à quelques développeurs de passer à plein temps sur leur projet favori (en général, c'est « à plein temps payé au lance pierre », mais bon). Par contre dans ces cas là, on donne en faisant confiance, et les donateurs n'ont pas plus d'impact que les autres sur la priorisation du travail du développeur.

Ce qui est affiché ne correspond pas forcément à ce qu'il y a sur disque, mais à ce qu'il y a dans le cache (RAM). Si le cache n'est pas proprement écrit sur le disque au reboot, alors avant reboot on affiche l'état de la RAM, et après reboot ce qu'il reste, c'est à dire le contenu du disque.

Malheureusement, le projet Dahu est effectivement mort.

Au départ, c'était un projet d'étudiants (que j'encadrais en tant qu'enseignant). Il y a eu une première version incomplète mais fonctionnelle, et avec une base de code assez simple pour que je puisse y contribuer en tant que analphabètenon-spécialiste de techno web.

Le projet a continué mais en ayant empilé un paquet de technos plus évoluées mais non-triviales à prendre en main, et je n'ai plus les compétences pour maintenir le bouzin.

C'est dommage, parce que le concept est bon à mon avis (on n'a rien inventé, l'idée vient du logiciel Wink qui faisait ça avant nous mais en générant du flash et pas du HTML) : les vidéos de démo de logiciels sont pénibles à éditer, souvent pénibles à regarder, mais à ma connaissance personne n'est venu combler ce manque depuis :-(.

Chez tout linuxien qui se respecte, un raccourcis clavier genre Alt-TAB permet de réaliser ton benchmark en moins d'une seconde.

Bah quand même, quand tu vas sur https://snapcraft.io/ et que tu lis « The app store for Linux », avec des sections « Some snaps you may like », « Official snaps from major publishers », ça ressemble beaucoup à un magasin d'application.

Mercurial utilise un système "append-only", où tout ce qui est écrit reste ad-vitam eternam. C'est une bonne propriété de pas mal de points de vues, par exemple c'est incremental-backup friendly. Git s'autorise à re-compresser a posteriori (git gc & cie) et du coup a pas mal d'opportunités d'optimisations en plus. Git peut delta-compresser (= ne stocker que le diff entre deux objets) n'importe quoi avec n'importe quoi au moins en théorie. Il s'autorise à utiliser un algo un peu bourrin, vu que la compression peut se faire en tâche de fond, ou sur les serveurs de l'hébergeur donc ça ne gène pas au quotidien le développeur. Ce que Git stocke c'est un ensemble d'arbres de delta, la racine de chaque arbre est un fichier stocké complètement, et les autres nœuds sont représentés par le delta avec leur père, ça permet de stocker très peu de fichier complètement tout en gardant des chaînes de delta de longueur raisonnables.

Un truc qui peut jouer aussi c'est que le format "pack" de Git utilise peu de fichiers (de grosse taille), alors que Mercurial utilise beaucoup de fichiers relativement petits. En général le filesystem alloue des fichiers par multiples de 4Ko, donc le stockage en petits fichiers fait perdre un peu de place par fichier.

(Disclaimer : je n'ai pas regardé Mercurial depuis des années, y'a peut-être des choses qui ont changé depuis)

TikZ-Timing ?

Je soupçonne une config dans le ~/.inputrc. C'est une config de la lib readline, utilisée par bash et d'autres programmes qui lisent une ligne de commande.

J'avais pareil avec des vieux drivers displaylink, recompilation des modules toutes les quelques dizaines de secondes en tâche de fond. J'ai désinstallé les drivers en question, qui de toutes façons ne marchaient pas vraiment, mais c'est pas hyper satisfaisant …

wget --spider fait à peu près ce que tu veux, mais bizarrement il n'accepte pas de se lancer sur un fichier ou une URL en file://, il lui faut un serveur web.

Pour à peu près le même besoin que toi, j'avais écrit un petit script qui lance un serveur web, lance wget --spider sur la page servie, et arrête le serveur quand il a fini : https://gitlab.com/moy/check-links/

On peut certainement faire plus efficace en parsant le HTML pour extraire les liens, et en vérifiant les liens, sans lancer de serveur web local, mais ça marche (et j'étais surpris de ne pas trouver de solution plus simple pour un besoin aussi banal).

Il semble un peu limite de le condamné à la peine de mort dans ce cas.

Je suis d'accord. On devrait réserver ce genre de peine à des cas plus graves comme la confusion entre infinitif et participe passé.

Euh, j'ai pas l'impression que la courbe 2020 soit vraiment en dessous des autres, si ?