elf32 a écrit 113 commentaires

Il faut Python 3.6 pour les f-strings je crois.

Ok, donc le problème n’était pas le « « Cloud », mais plutôt le cloud provider.

C'est intéressant, ces deux articles de GitLab. Mais au final on a pas eu le fin mot de l'histoire. Dans la situation initiale, ils avaient un gros problème d'IOPS en tournant sur les VM du cloud, donc ils veulent tourner sur du matos en dur.

À la fin, ils décident de ne plus sortir du cloud. Ok, mais comment ils ont résolu le problème d'IOPS, alors ?

Ma technique secrète pour développer des applications (souvent backend Web) rapides, c'est de me servir d'un vieux RPi 2 comme machine de dev. Avec une carte microSD bas de gamme, qui plus est.

C'est pour pousser les gens à utiliser l'app, je suppose. Enfin, attends… l'app n'est-elle pas bloatée elle aussi, en fait ?

Je ne suis pas un fan de Brave (je garde mon Firefox), mais voici la réponse de Brendan Eich (CEO et fondateur de Brave) à cet article. À lire avec recul et scepticisme, bien entendu, mais la rigueur exige que l'on prenne tout de même en compte sa réponse.

D'ailleurs, y a-t-il un effort pour changer ça, vu qu'ils réécrivent de grandes portions en Rust? Ça serait une bonne occasion, après tout. Mais j'en doute.

Oui, il y a Servo qui est prévu, écrit en Rust par Mozilla et contributeurs. Par ailleurs, Servo se veut embeddedable par design, contrairement à Gecko:

Servo is a modern, high-performance browser engine designed for both application and embedded use.

Je ne fais plus de PHP, et je n'ai jamais vraiment apprécié le langage. Mais ayant été un gros utilisateur de PHP (surtout PHP7) pour le boulot, je suis quand même content de voir que le projet avance bien, et dans le bon sens.

Je pense que je serai amené à refaire du PHP un de ces jours (peut-être que ça sera du PHP8, qui sait ?), et je sais déjà que je ne partirai pas avec un si mauvais a priori.

Prendre Symphony comme exemple de framework PHP, ce n'est pas vraiment lui rendre hommage (sauf depuis la v4, éventuellement). Bref, je pense qu'on peut comparer Django (que j'apprécie beaucoup) avec quelque chose de plus ressemblant.

Si c'est juste une histoire de DNS, résoudre en utilisant la fonctionnalité DoH implémentée dans Firefox sera peut-être plus intéressant, car ça évite de tout faire passer par le proxy alors qu'il n'y en a pas besoin.

Même si on aime pas cette feature, l'activer temporairement dans Firefox le temps qu'on est connecté au réseau public ça fait l'affaire.

C'est donc une bonne chose. Hélas à la Shinsei, la carte n'est pas renouvelée.

Pour la sécurité, j'ai quelques doutes. Le principe en soi me paraît pas mal, et ça a le mérite d'être low-tech.

Mais la carte n'a que 50 combinaisons possibles. À chaque fois que l'une d'entre elle est utilisée, elle se retrouve aussitôt « corrompue ». Au bout d'un certain nombre de connexions, les 50 combinaisons s'en retrouvent ainsi « épuisées ». Il faudrait carrément un livret avec une centaine de grilles, chacun d'entre elles encodant des milliers de combinaisons possibles, je pense. Ou bien, il faudrait changer de carte dès qu'on a atteint par exemple X connexions sur le portail en ligne.

Heureusement, et malgré une interface rappelant le début du Web, le site fonctionne très bien sous Firefox sur Linux !

Il me semble que les Coréens préféreraient à une époque utiliser autre chose que de l'UTF-8 pour représenter leurs caractères (j'ai plus le nom en tête). Peut-être que c'était à cause de ça que le site marchait que sous Windows et IE ? (genre un jeu d'encodage foireux sous Linux et OS X mais okay sur Windows)

Ma banque du Japon a un système assez rigolo.

Il faut entrer son numéro de compte (figurant sur la carte de retrait du compte) puis le code PIN (de la même carte), puis un code secret (6-12 caractères) que l'on mémorise.

Mais ce n'est pas fini ! On a une carte physique (qui doit être maintenue secrète) contenant une grille de correspondance (la "Security Card") où chaque case fait figurer un caractère. Pendant le login, le système génère aléatoirement une série de cases unique, et l'on doit, à l'aide de la carte, décoder et insérer le résultat pour finaliser la connexion.

Et voilà !

Si vous avez rien compris, voici l'image qui illustre ce qu'est la Security Card : https://www.shinseibank.com/english/guide/imgs/index/step3.gif

Django 3 est asynchrone

Hum… Django 3 supporte maintenant l'interface ASGI, mais est-il vraiment, vraiment, asynchrone pour l'instant ? :)

Comme tu l'expliques bien, il y a encore des choses à faire. En attendant, je ne dirais pas que Django 3 est asynchrone de façon utile dans le cas présent.

Pour une organisation de droit français, opter pour un TLD .fr me semble plus raisonnable qu'un .org. Cela n'engage que moi mais j'aurais plutôt tendance à faire confiance à l'Afnic (qui gère les TLD français dont le .fr), pas que administrativement mais aussi techniquement.

Voici ce qu'on peut lire sur leur site :

L’Afnic est une association à but non lucratif issue en 1998 de l’Institut National de la Recherche en Informatique et Automatique qui avait hébergé cette activité pionnière de l’Internet français depuis le milieu des années 1980. Sa gouvernance est multipartite c’est-à-dire qu’elle associe pouvoirs publics, utilisateurs et secteur privé.

L’Afnic est une association indépendante, qui ne reçoit aucune subvention et fonctionne comme une entreprise. Le financement de l’activité et de son équipe est entièrement assuré par la mise à disposition de ses prestations.
Cf. https://www.afnic.fr/fr/l-afnic-en-bref/presentation/missions-de-l-afnic-et-axes-strategiques-2017-2019-6.html

Ça a l'air plutôt sain.

Je ne comprends pas bien ton post scriptum. En quoi un site qui est de toute façon public peut-il être « épié » par la NSA ou la DGSE ?

Je ne sais pas si officiellement le fr de LinuxFR veut dire « francophone » ou « France », mais en tout cas le nom alternatif semble assez clair : « Da Linux French Page ». Pour moi, ce nom ça fait clairement référence à la France et non pas à la francophonie. (mais ça reste possible hein)

Donc pip installe les paquets décrits dans requirements.txt et rpm intègre avec l'écosystème final (notamment la version de python).

Je ne suis pas familier avec la famille RedHat/CentOS/Fedora mais ce commentaire m’intrigue beaucoup. Y a-t-il un procédé « officiel » pour faire un RPM deployable en prod prenant en compte et isolant des dépendances grâce à un requirements.txt et à un virtualenv ?

Parce que ma boîte faisait bosser leurs devs avec Gentoo, donc il fallait compiler le noyau (ou voler la config d'une autre distro déjà existante, ce que je n'ai pas fait) au moment d'installer sa machine de travail.

Mais c'était cool, j'ai appris des trucs.

Super ! Merci beaucoup ! Je vais tester ça.

Je ne doute pas de tes observations, mais est-ce qu'il y a moyen de vérifier l'apport de fluidité de façon objective plutôt que par le ressenti ?
Je me pose la question car chez moi (une Debian, un i5 récent, les drivers Intel installés et reconnus par FF) , activer ou non Webrender ne semble pas changer grand chose. Du coup j'aimerais bien faire les observations sans risquer de subir un effet placebo.

Ça ouvre la porte à pas mal de systèmes reposant sur email.utils, exploitant le mécanisme du "magic link" envoyé par e-mail, que ce soit pour l'authentification ou bien la réinitialisation de mot de passe.

OK, je comprends beaucoup mieux l'intérêt d'avoir la main sur la norme, maintenant. Merci !

La « rétro-ingénierie » d'une telle norme n'est-elle pas triviale ? Qu'apporte la norme, en plus du layout qui lui est de toute évidence consultable rien qu'en regardant le clavier ? Ou bien, en lisant le code source d'une implémentation libre (genre Xkb) ?