Matthieu Moy a écrit 3251 commentaires

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 ?

Tu compares le traçage par StopCovid à celui de Google, des cartes bancaires et des bornages des téléphones mobiles, mais c'est passes sous silence une énorme différence. StopCovid ne conserve ces informations que sur les téléphones des deux personnes qui ont été proches physiquement. Tant que personne ne se déclare malade, l'info ne sort pas des deux téléphones. Quand quelqu'un se déclare malade, le strict minimum nécessaire est transmis, c'est à peu près la même info que celle qui est déjà transmise au fichier Contact Covid manuellement, sauf qu'une application mobile permet d'étendre la démarche aux personnes qu'on ne connaît pas.

Il n'y a pas eu de rupture de stock, mais quand il y avait un stock de 140 millions de masques pour 67 millions d'habitants, ça aurait été difficile de prétendre qu'il y en avait assez pour les soignants et pour que chaque français puisse aller en acheter une boîte de 10 en pharmacie, non ?

On peut certes regretter les captchas version Google

On peut le regretter, mais il faut aussi voir quelle information fuite vers Google avec ce CAPTCHA. À ma connaissance, c'est utilisé à la création du compte (pour éviter les bots qui créeraient des milliers de comptes automatiquement), donc il me semble que l'info fuitée est seulement le fait que l'utilisateur a créé un compte. Je me permet d'espérer que les gens en désaccord avec ça n'utilisent pas déjà le play store de Google, parce que sinon, scoop, Google sait déjà que tu as installé l'application avant que le CAPTCHA ne soit lancé.

j'imagine mal un DRH acheter une batterie de téléphones pour faire ses entretiens

D'autant que le protocole ROBERT derrière StopCovid prévoit justement d'émettre volontairement des faux positifs, donc un DRH qui voudrait vraiment savoir si un candidat tombe malade dans les 2 semaines suivant l'entretien (je me demande pourquoi il voudrait le faire, mais bon), n'a que deux réponses possibles : « non », il ne s'est pas déclaré malade, ou « peut-être », mais jamais « oui ».

Et quand Mélenchon termine son intervention en demandant aux gens de l'enlever de leurs carnets d'adresses s'ils installent StopCovid, je me dis que pour ce qui est d'évaluer les risques sur ma vie privée, je ferais mieux d'écouter quelqu'un de mieux informé que lui.