Glandos a écrit 1345 commentaires

Je suis parfaitement d'accord.

Maintenant, parlons de la stdlib du C++, qui a attendu C++11 pour avoir une hash map. Tout le monde s'attend à ce qu'une map soit hashé sur les clés avec un ordre non garanti sur l'itération (oui, même si Python a changé d'avis), permettant d'avoir un temps amorti sur la recherche. C'est dommage je trouve. J'ai été très perturbé d'avoir des std::map au comportement si différent des autres langages.

Peut-être que j'ai été trop drogué au HashMap de Java et de Perl ?

Aaaah, je me souviens, j'utilisais ProcessExplorer de sysinternals.com fait par Mark Russinovich bien avant qu'il ne soit embauché chez Microsoft.

Et depuis, ProcessExplorer reste mieux que l'utilitaire fourni par Microsoft. Mais bon, hein, je dis ça, je dis rien :)

Je savais que je pouvais compter sur le public de ce site.

Merci pour ces précisions !

Ça change d’un précédent boulot où le directeur et co-fondateur considérait que si c’était sur Internet, il pouvait l’utiliser comme il voulait…

Mais… si c'est sur Internet, c'est que c'est vrai !

Mais ? Évidemment qu'on s'en tape de l'avertissement !

Pourquoi ? Parce que I don't care about cookies ne s'utilise pas tout seul, mais soit avec uMatrix, soit avec Cookie AutoDelete, qui rend ces panneaux d'avertissement visibles. À. Chaque. Visite. C'est horrible.

Et puis, j'utilise l'abonnement à la liste AdBlockPlus (dans uBlock Origin), comme ça, pas de code JS supplémentaire dans mon navigateur.

Oui, je ne suis pas un utilisateur lambda, c'est évident…

Je plussoie. Pour avoir installé des Ubuntu partout (sauf pour moi, je suis en Debian/testing, la rolling-release de Debian ;)), les màj de version majeure se font sans efforts. Et les màj de LTS aussi, tous les deux ans seulement.

Ça lui apprendra à s'opposer à la Sainte Propriété.

Han mais Guillaume Champeau fait encore des articles sur Numérama ! https://www.numerama.com/pop-culture/27401-la-plus-vieille-video-de-chats-visible-sur-internet-date-de-1894.html (via https://www.numerama.com/author/guillaumechampeau/)

Comment ça, ça n'a rien à voir ?

Donc il suffira que tu confirmes la première connexion pour que la personne puisse ensuite ajouter sa passkey au compte. Et ça fait un compte partagé sans avoir à partager de mot de passe. Ça me semble pas mal comme fonctionnement.

Merci de me souligner ce fonctionnement, que j'avais… zappé.

Mais tous tes mots de passe sont aussi stockés au même endroit, dans le cloud de Bitwarden (à moins que tu l'auto-héberge à la maison) et dans le cache de ta machine.

C'est ça, je l'auto-héberge. Et aussi, même dans l'autre cas, je choisis mon prestataire. Là, on va être un peu bloqué. Y a Apple, Microsoft et Google, mais grosso-modo, ça dépend du matériel qu'on a acheté, point-barre.

Pour l'un comme pour l'autre je ne pense pas qu'un attaquant d'envergure FBI ait trop de difficultés à y accéder.

Ah ben les forces de l'ordre peuvent accéder à mes mots de passe, mais ça doit être validé par un juge. Et mettre des procédures légales n'empêche pas de mettre des gardes-fous techniques pour éviter la pente savonneuse d'un pouvoir politique qui change les procédures légales.

Et donc soit te doivent le service que tu paies, soit ont intérêt à ce que tu restes pour continuer à se faire du pognon avec tes données.

Dans le deuxième cas, il y a beaucoup d'exemple de gens qui se font fermer l'intégralité de leur compte pour une « entorse » aux conditions générales dans un autre service du fournisseur (tentaculaire…).

Pourquoi avoir 1 passkeys par site voir compte ? Au pire, on crée une clé public que pour ce site.

Avoir différentes identités est une chose très importante je trouve. J'aime bien garder ce principe. Si une clé est corrompue, il ne faut pas tout révoquer.

Pourquoi vouloir enfermer cela dans la mémoire interne et sécurisé du tél ?
Parce que c'est quand même vachement mieux à l'abri d'un casse chez LastPass quand même. C'est un peu le but des TPM, et pour le coup, elles le font bien…

Quelque part… on peut dire que c'est une bonne idée. C'est d'ailleurs le concept même de l'échange défi-réponse de la carte à puce avec un code PIN, autant dire que c'est pas tout jeune. J'ai pas regardé la crypto de ces « passkeys » (est-ce que j'y comprendrais quelque chose ?), mais c'est sûrement plus moderne.

Cependant… Comme le laisse penser le titre ironique de ce lien, c'est sûrement une Fausse Bonne Idée. Déjà, comme le dit l'article, on peut rien sortir soi-même. C'est pas top, au mieux, c'est laborieux. Ensuite, on ne peut pas le partager. Alors là, pardon, mais dans mon foyer, on va pas se créer un compte par personne dans un magasin pour commander. Ou sur LeBonCoin. Non, on a une organisation BitWarden, avec un mot de passe généré partagé. Ça marche.

Et le dernier clou, la sauvegarde dans le cloud. Ahah. Ça, c'est l'argument massue pour me faire m'en aller : tous mes mots de passe, au même endroit, chez un prestataire que je paie pas et qui ne me dois rien. Moui, bon, c'est pas que c'est louche, mais ça ressemble à un test de phishing ? ;)

Si j'avais été un troll, j'aurais dit : Traditional packaging is not suitable for non-Green IT applications.

La plupart des applications qui supportent mal le système traditionnel de paquets sont des trucs basés sur Electron, Node.js, et dans une certaine mesure, Python. Donc des trucs fabriqués avec des briques logicielles qui évoluent tellement vite (Y a une nouvelle version majeure de NodeJS par an) qui rendent l'écosystème forcément fragmenté.

L'exemple de OBS avec FFMpeg est cependant intéressant.

Mais pour avoir observé le comportement de Flatpak et de Nix, ben je préfère le deuxième. Mais c'est une préférence personnelle…

Mais… elle est à l'envers !

Si c'est un clou Microsoft, il se plante tout seul !

Merci pour ce journal, qui expose problème et solution.

Les ressources sont clairement gâchées. 37 Mo, c'est effectivement rien, sauf quand on l'additionne. Bande passante et espace de stockage vont représenter des gigaoctets. Et puis, à chaque mise à jour de l'application, ça va être le même bordel.

Je comprends la raison de ne pas partager des ressources (comme dans une distribution Linux), mais là, ça montre des limites. Un système fonctionnel à la NixOS/Guix ne serait-il pas adapté ?

Tiens, et en dernière remarque, si tu as le temps, tu peux essayer de recompresser les PNG ou les SVG. J'y mettrais pas ma main à couper, mais il y a de fortes chances pour que ça gagne encore. On a même un super logiciel pour ceux qui veulent pas se compliquer la vie.

Lorsque tu lanceras l'application, la page de login s'affichera plus vite que si tu lances un firefox vers la page concernée.

Les caches navigateurs fonctionnent bien. Surtout en PWA.

Un autre aspect, c'est quand même que les gens savent mieux gérer des applications sur leur téléphone que des marques-pages dans leur navigateur.

C'est une réalité. Mais la faute ne vient pas des gens, elle vient des fabricants d'OS (coucou Apple) qui ont vendu le concept d'application (coucou le business) même quand ça n'était pas nécessaire. Et de ce fait, les interfaces des navigateurs sont inadaptées.
Pourtant, j'aime beaucoup le concept de « Installer cette application sur mon téléphone » quand je vais sur une page Web. Ça marche.

Matrix (Element) : 208 Mo

J'y ai pas cru. J'ai ouvert l'APK depuis F-Droid, et dedans, il y a les bibliothèques pour :

• x86_64
• x86
• arm64-v8a
• armeabi-v7a

Alors autant les deux derniers, je comprends, mais les deux premiers, je suis pas sûr que ça soit utile… Et il y a libjingle_peerconnection qui fait 10 Mo environ dans chaque répertoire. Plus un tas d'autre trucs.

Je suis inscrit sur une framaliste de « gens normaux ». Ce n'est pas moi qui la gère, c'est également une « gente normale ». Et plein de destinataire disent ne jamais recevoir certains messages. Je me suis déjà entendu leur dire que la faute n'est pas de Framaliste, mais de leur fournisseur de messagerie (après le leur avoir demandé quand même, je ne vais cracher gratuitement), et l'effet est, comme vous vous en doutez, assez nul. Je ne m'attends pas à ce que les gens changent de fournisseur dès le lendemain, mais à ce qu'ils comprennent qu'ils ne peuvent pas avoir le beurre (une adresse de courriel avec stockage illimité ou presque) et l'argent du beurre (tout ça gratuitement).

Sans blague, super idée, super projet de se focaliser sur l'interopérabilité.
XMPP me faisait briller les yeux en 2005, je l'ai utilisé pendant longtemps, et puis j'ai cédé aux sirènes de Matrix/Element pour son côté « moderne ».
Mais j'ai quand même gardé mon serveur XMPP, avec un relais entre mon salon anonyme ouvert (saurez-vous le trouver) et un salon Matrix. Parce que je trouve ça bête d'avoir deux protocoles ouvert qui ne se parlent pas.

Il faut arrêter d'accuser les clients mails

IBM Notes (ex Lotus Notes). Il est impossible de répondre en dessous du message, on ne peut que écrire au dessus. On ne peut même pas casser une citation en deux pour répondre dedans, on ne fait que rajouter du texte dans la citation.

Oui, on pourrait argumenter que Notes n'est pas un client email, mais une messagerie avec une passerelle vers l'email…

Shortwave a l'air bien, mais… pourquoi ne supporter que GMail ? C'est bizarre comme modèle commercial pour une boîte, de s'appuyer uniquement sur un seul fournisseur de données. J'ai vu plein de boîtes faire des clients Twitter, et… ça s'est pas bien fini pour eux.

C'est vrai. En général d'ailleurs, je m'adapte. Sur debian-devel, je fais du bottom posting. Quand un message est déjà écrit en top posting depuis 5 échanges, je vais pas tout casser juste pour imposer ma vision.

Les clients « modernes » ont tendance à rendre cette différence un peu obsolète d'ailleurs. Outlook Web masque comme il faut les messages précédents, et Thunderbird Conversations permet de faire une navigation en conversation assez pratique.

Le top posting est un enfer. Surtout en entreprise, quand on te transfère un message avec :

• Message original
• Signature HTML avec un GIF animé et l'adresse facebook/téléphone (on a un annuaire)/email (tu viens de m'envoyer un email pour mettre ton email en signature, dude)

Ça, répété en boucle et parfois y a des gens qui ont répondu au milieu en mettant en rouge leur réponse.

Résultat, la molette de ma souris souffre très beaucoup fort pour 10 lignes de texte utile.

En fait, plus j'y pense, plus le fait de pouvoir modifier le message original est un souci. Ce qui se fait dans les logiciels de forum est beaucoup plus utilisable : une page vierge, et on récupère ce qu'on veut citer si on le souhaite.

Mais bon, c'est arrivé bien plus tard.

Après, les coûts de migration sont énormes, mais… ça permet de parier sur l'avenir. Avoir des choses en interne, pour une boîte de la taille de la SNCF, ça a complètement du sens.

Surtout que des petites boîtes comme Capitaine Train ont fait aussi des merveilles avec l'API de la SNCF. Et ça marche. Oui, son successeur Trainline est moins bien, mais ça reste bien quand même.

As the western states rapidly move toward totalitarianism, clampdown on free speech […].

Ah, alors oui, il y a des grandes critiques à faire sur la liberté d'expression. Mais tenir cet argument pour soutenir des solutions russes, c'est quand même bien se discréditer tout seul. La Russie bloque des sites à tour de bras. Et emprisonne les opposants politiques (parfois pire). On repassera pour la liberté d'expression.

J'ai pas réussi à retrouver le message de Jason Donenfeld lors de la conception initiale de Wireguard.

Mais en gros, sur la crypto, il partait de l'expérience de OpenSSL : quand tu veux créer un socket TLS, c'est extrêmement compliqué, à cause du choix des algorithmes cryptographiques.
Sur Wireguard, l'utilisateur n'a pas le choix. C'est un ensemble d'algorithmes, point. Mais il me semble que l'agilité cryptographique n'a pas été oubliée.

Quant à mettre à jour les logiciels, c'est la même chose lors du déploiement de nouveaux algorithmes, y compris pour OpenSSH, TLS, etc.