Même si la communauté Open Source sera bien entendu déçue, ce choix était le plus pragmatique pour rationaliser le développement et limiter les pertes de temps, avec le bonus non négligeable de limiter les fuites.
J'aurais proposé l'autre solution : tout le développement est public. Avec de la gestion de projet privée, si vous voulez, mais tous les commits arrivent au fur et à mesure.
Parce que là, ça devient du gros code dump, c'est donc impossible de contribuer à AOSP. Pas que j'en avais vraiment envie, mais ça sent le sapin pour les contributions.
Sur ma machine Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz avec 32 Go de RAM :
/tmp ❯ dd if=/dev/urandom bs=1k count=10M of=/tmp/random
10485760+0 enregistrements lus
10485760+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 42,7199 s, 251 MB/s
/tmp ❯ hyperfine 'xxhsum -H3 /tmp/random' 'b3sum /tmp/random' 'b3sum --num-threads 1 /tmp/random'
Benchmark 1: xxhsum -H3 /tmp/random
Time (mean ± σ): 1.757 s ± 0.260 s [User: 0.467 s, System: 1.288 s]
Range (min … max): 1.484 s … 2.242 s 10 runs
Benchmark 2: b3sum /tmp/random
Time (mean ± σ): 1.054 s ± 0.036 s [User: 5.877 s, System: 0.770 s]
Range (min … max): 1.013 s … 1.136 s 10 runs
Benchmark 3: b3sum --num-threads 1 /tmp/random
Time (mean ± σ): 3.600 s ± 0.102 s [User: 3.047 s, System: 0.549 s]
Range (min … max): 3.470 s … 3.743 s 10 runs
Summary
b3sum /tmp/random ran
1.67 ± 0.25 times faster than xxhsum -H3 /tmp/random
3.42 ± 0.15 times faster than b3sum --num-threads 1 /tmp/random
Sur 1 thread, XXH3 est bien plus rapide que BLAKE3, ça prend environ la moitié du temps.
Par contre, vu la parallélisation, BLAKE3 gagne. Après, ça se prête bien aux gros fichiers (dans mon cas, 10 Go), sur un système qui ne fait pas 30 vérifications en même temps. Sur des condensats de paquets TCP, vaut ptêt mieux partir sur du XXH en effet :) (Plein de connexions en parallèle, données tellement petites que lancer un thread prend trop de temps).
Les industriels de la filière empoisonnent les gens sans scrupules. Que ce soit une justice américaine intéressée par l'oseille plutôt qu'une justice luxembourgeoise intéressée par la santé publique, si ça peut faire avancer le schmilblick, pour moi, c'est bien.
Ça permet à l'utilisateur de refuser le chargement d'une application web dans son navigateur si la signature ne correspond pas à celle du développeur.
Pour l'instant, c'est fait par une extension Firefox, donc c'est débrayable à l'envi.
Les personnes qui ont fait ça ont en tête le cas d'utilisation des applications auto-hébergées type Element, CryptPad, et donc SecureDrop, pour lesquelles l'utilisateur/utilisatrice a besoin de savoir si le code reçu n'est pas infecté.
Pourquoi pas. Tant que c'est transparent et débrayable, ça me va.
Par contre, comment ça marche si on veut personnaliser un peu une application, avec des images, des mentions légales, etc. ?
En fait, c'était vraiment une question plus ouverte : est-ce que BLAKE3 est simplement méconnu, ou bien est-ce que c'est le comportement habituel de ne pas se précipiter sur le nouveau truc à la mode ?
Alors, effectivement, si on part du principe qu'on a besoin de Docker pour déployer des services de production, chaque service prendra beaucoup de place. Même si, il me semble, Docker fonctionne sur le principe de couche avec OverlayFS, donc deux conteneurs utilisant la même base ne devrait pas prendre 2 fois l'espace disponible.
Mais mon idée derrière tout ça, c'est que Docker est une solution qui permet d'aller vite, mais qui est bien plus consommatrice de ressources qu'un paquet RPM/DEB. Et on a l'avantage de bénéficier du support logiciel de sa distribution, et de mieux maîtriser la chaîne des dépendances.
Ce que j'apprécie, et que l'auteur n'aime pas, c'est que justement, je mets à jour tout mon système d'un simple apt -U full-upgrade, et la sécurité est assurée. Si un conteneur Docker est affecté par une faille, il faut le cibler, et le mettre à jour « manuellement ». J'imagine qu'il y a des outils pour automatiser ça, mais ça revient à mon postulat de base : il faut plus de ressources pour utiliser Docker (un gros stockage pour les images, des outils d'automatisation). Et mon défaut, c'est de considérer que l'informatique n'a pas des ressources illimitées, et d'essayer de les économiser au maximum. Je deviens un peu chatouilleux sur le sujet :)
Comparer Python et Go en utilisant Docker, c'est huhuhu.
Sur ma Debian, si j'ai deux scripts Python, j'ai effectivement un gros stock de départ avec la bibliothèque standard. Et après, j'ai quelques octets par script.
Avec Go, c'est 10 Mo par binaire.
Parce que j'utilise pas cette gabegie de dépenses de ressources que représente Docker.
La qualité du code ne dépend clairement pas du langage. En plus, l'article présente Python comme un problème de qualité de code, tout en parlant juste au dessus de C++ pour les performances. C'est très paradoxal, écrire du bon code C++ est bien plus difficile que du bon code Python.
La gestion des dépendances en Python est connue pour être bordélique, mais au moins, y a un fichier pyproject.toml qui les listes toutes. La chaîne de dépendances est facilement analysable par un humain, au moins au premier niveau. En Go, il faut simplement lire chaque fichier, et lire les imports. Merci, c'est cool.
Et enfin, les outils, qui ne sont plus écrits en Python. Oui, ça fait longtemps que Python est utilisé pour faire du calcul numérique. Qui utilise numpy, qui n'est pas codé en Python. Ça fait longtemps que Python est utilisé pour faire du code d'entrée, afin de faire quelque chose de simple.
Je rajouterais que quand un binaire Go ne marche pas, c'est très compliqué de le patcher. En Python, on édite le fichier, ça marche.
Je conclus : j'aime beaucoup déployer des binaires en Go/Rust. C'est simple, ça marche, c'est rapide. Mais de là à jeter le Python en production pour ces arguments, c'est non recevable.
Non parce que ses habitants ont hérités d'un nom qui sonne tellement fort le laboratoire pharmaceutique (ou la société de service) que je me demandais ce que c'était.
La chronique n'a pas franchement d'intérêt. Elle manque tellement de profondeur que c'est navrant de se surprendre à avoir pitié de ce genre d'écriture fait pour soulever le cœur des lecteurs avec des émotions faciles.
Euh, je voulais dire quoi déjà ? Ah, oui, bien sûr, les automates. Non parce que l'autrice émet un constat qu'on a tous plus ou moins fait : les interfaces sont parfois confuses (au mieux), parfois à chier (soyons polis). Pourtant, on n'est pas dans le dark pattern, la RATP a bien envie d'en vendre le plus possible des tickets quand même.
Donc je n'ai pas de solution, mais pour moi, c'est clairement un problème d'expérience utilisateur mal fagotée. Oui, les gens s'énervent plus facilement en face d'une machine. Mais en même temps, ça pourrait être plus ergonomique…
[^] # Re: Magie de GIT
Posté par Glandos . En réponse au lien Organic Maps abandonne Github et migre sur Forgejo. Évalué à 6 (+4/-0).
Tu perds quand même tous les tickets, les discussions, la gestion de projet associée.
C'est pour ça que des gens pensent que Fossil est mieux. Je ne suis pas fan, mais je comprends le principe.
[^] # Re: VO ?
Posté par Glandos . En réponse au lien Affaire Signal : textos intégraux. Évalué à 4 (+2/-0).
https://www.theatlantic.com/politics/archive/2025/03/signal-group-chat-attack-plans-hegseth-goldberg/682176/
# Et si on l'avait faite à l'envers ?
Posté par Glandos . En réponse au lien Google passera le développement d’Android entièrement en interne cette année. Évalué à 8 (+6/-0).
J'aurais proposé l'autre solution : tout le développement est public. Avec de la gestion de projet privée, si vous voulez, mais tous les commits arrivent au fur et à mesure.
Parce que là, ça devient du gros code dump, c'est donc impossible de contribuer à AOSP. Pas que j'en avais vraiment envie, mais ça sent le sapin pour les contributions.
[^] # Re: J'ai pas toujours envie que mon hash crypto aille vite...
Posté par Glandos . En réponse au journal BLAKE3, le condensat cryptographique qui laisse les autres sur le quai. Évalué à 3 (+1/-0).
Sur ma machine Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz avec 32 Go de RAM :
Sur 1 thread, XXH3 est bien plus rapide que BLAKE3, ça prend environ la moitié du temps.
Par contre, vu la parallélisation, BLAKE3 gagne. Après, ça se prête bien aux gros fichiers (dans mon cas, 10 Go), sur un système qui ne fait pas 30 vérifications en même temps. Sur des condensats de paquets TCP, vaut ptêt mieux partir sur du XXH en effet :) (Plein de connexions en parallèle, données tellement petites que lancer un thread prend trop de temps).
[^] # Re: amende anti-europe
Posté par Glandos . En réponse au lien Roundup : Bayer/Monsanto condamné à verser 1,94 milliards d'euros à un homme atteint d’un cancer. Évalué à 6 (+4/-0).
D'accord, mais si je mets en relation cette actualité : https://www.lemonde.fr/planete/article/2025/03/21/les-administrateurs-de-l-anses-gendarme-francais-des-pesticides-denoncent-un-projet-de-mise-sous-tutelle-par-le-gouvernement-et-les-filieres-agricoles_6584274_3244.html
Je me dis que : « hé ben tiens, pourquoi pas ? »
Les industriels de la filière empoisonnent les gens sans scrupules. Que ce soit une justice américaine intéressée par l'oseille plutôt qu'une justice luxembourgeoise intéressée par la santé publique, si ça peut faire avancer le schmilblick, pour moi, c'est bien.
# Pendant ce temps là, dans un univers parallèle
Posté par Glandos . En réponse au lien Microsoft utilise Go pour son portage Typescript (et expliquent pourquoi ce n'est pas écrit en Rust). Évalué à 6 (+4/-0).
https://linuxfr.org/users/wilk/liens/typescript-porte-en-go
[^] # Re: Il fait tiède
Posté par Glandos . En réponse au lien ubuntu envisage de migrer les coreutils vers des équivalents en rust (uutils). Évalué à 10 (+9/-0).
https://sylvestre.ledru.info/coreutils-fosdem-2025/#47
L'auteur principal le dit : ce n'est pas un problème de sécurité. Les utilitaires GNU coreutils sont très bien de ce point de vue là.
Donc l'argument d'Ubuntu est mauvais.
# Si j'ai bien compris
Posté par Glandos . En réponse au lien Introducing WEBCAT: Web-based Code Assurance and Transparency. Évalué à 5 (+3/-0).
Ça permet à l'utilisateur de refuser le chargement d'une application web dans son navigateur si la signature ne correspond pas à celle du développeur.
Pour l'instant, c'est fait par une extension Firefox, donc c'est débrayable à l'envi.
Les personnes qui ont fait ça ont en tête le cas d'utilisation des applications auto-hébergées type Element, CryptPad, et donc SecureDrop, pour lesquelles l'utilisateur/utilisatrice a besoin de savoir si le code reçu n'est pas infecté.
Pourquoi pas. Tant que c'est transparent et débrayable, ça me va.
Par contre, comment ça marche si on veut personnaliser un peu une application, avec des images, des mentions légales, etc. ?
[^] # Re: J'ai pas toujours envie que mon hash crypto aille vite...
Posté par Glandos . En réponse au journal BLAKE3, le condensat cryptographique qui laisse les autres sur le quai. Évalué à 3 (+1/-0).
Ouais donc md5 est lent et nul, même comparé à un b3sum sur un seul CPU :)
Mon /tmp est monté en RAM avec du tmpfs, donc la vitesse de lecture est maximale.
[^] # Re: Formulation amusante
Posté par Glandos . En réponse au journal BLAKE3, le condensat cryptographique qui laisse les autres sur le quai. Évalué à 6 (+4/-0).
Oooooh, tout de suite :)
En fait, c'était vraiment une question plus ouverte : est-ce que BLAKE3 est simplement méconnu, ou bien est-ce que c'est le comportement habituel de ne pas se précipiter sur le nouveau truc à la mode ?
# Le code semble disponible
Posté par Glandos . En réponse au lien Typescript porté en Go. Évalué à 6 (+4/-0).
https://github.com/microsoft/typescript-go
Pas étonnant pour un projet comme TypeScript de publier son code, mais j'aime bien mettre le lien.
[^] # Re: Oui, mais pas ce que je retiens comme vrais problèmes de Python
Posté par Glandos . En réponse au lien Difficile de recommander Python en production . Évalué à 4 (+2/-0).
Y a quand même des lockfile pour ça.
[^] # Re: Huhu
Posté par Glandos . En réponse au lien Difficile de recommander Python en production . Évalué à 6 (+5/-1). Dernière modification le 08 mars 2025 à 15:33.
Alors, effectivement, si on part du principe qu'on a besoin de Docker pour déployer des services de production, chaque service prendra beaucoup de place. Même si, il me semble, Docker fonctionne sur le principe de couche avec OverlayFS, donc deux conteneurs utilisant la même base ne devrait pas prendre 2 fois l'espace disponible.
Mais mon idée derrière tout ça, c'est que Docker est une solution qui permet d'aller vite, mais qui est bien plus consommatrice de ressources qu'un paquet RPM/DEB. Et on a l'avantage de bénéficier du support logiciel de sa distribution, et de mieux maîtriser la chaîne des dépendances.
Ce que j'apprécie, et que l'auteur n'aime pas, c'est que justement, je mets à jour tout mon système d'un simple
apt -U full-upgrade, et la sécurité est assurée. Si un conteneur Docker est affecté par une faille, il faut le cibler, et le mettre à jour « manuellement ». J'imagine qu'il y a des outils pour automatiser ça, mais ça revient à mon postulat de base : il faut plus de ressources pour utiliser Docker (un gros stockage pour les images, des outils d'automatisation). Et mon défaut, c'est de considérer que l'informatique n'a pas des ressources illimitées, et d'essayer de les économiser au maximum. Je deviens un peu chatouilleux sur le sujet :)# Huhu
Posté par Glandos . En réponse au lien Difficile de recommander Python en production . Évalué à 10 (+15/-4).
Comparer Python et Go en utilisant Docker, c'est huhuhu.
Sur ma Debian, si j'ai deux scripts Python, j'ai effectivement un gros stock de départ avec la bibliothèque standard. Et après, j'ai quelques octets par script.
Avec Go, c'est 10 Mo par binaire.
Parce que j'utilise pas cette gabegie de dépenses de ressources que représente Docker.
La qualité du code ne dépend clairement pas du langage. En plus, l'article présente Python comme un problème de qualité de code, tout en parlant juste au dessus de C++ pour les performances. C'est très paradoxal, écrire du bon code C++ est bien plus difficile que du bon code Python.
La gestion des dépendances en Python est connue pour être bordélique, mais au moins, y a un fichier
pyproject.tomlqui les listes toutes. La chaîne de dépendances est facilement analysable par un humain, au moins au premier niveau. En Go, il faut simplement lire chaque fichier, et lire les imports. Merci, c'est cool.Et enfin, les outils, qui ne sont plus écrits en Python. Oui, ça fait longtemps que Python est utilisé pour faire du calcul numérique. Qui utilise numpy, qui n'est pas codé en Python. Ça fait longtemps que Python est utilisé pour faire du code d'entrée, afin de faire quelque chose de simple.
Je rajouterais que quand un binaire Go ne marche pas, c'est très compliqué de le patcher. En Python, on édite le fichier, ça marche.
Je conclus : j'aime beaucoup déployer des binaires en Go/Rust. C'est simple, ça marche, c'est rapide. Mais de là à jeter le Python en production pour ces arguments, c'est non recevable.
[^] # Re: tiens donc, un lien YT qui n'est pas largement moinsė
Posté par Glandos . En réponse au lien La recherche dans un moment orwellien aux États-Unis, regrettent plusieurs scientifiques français. Évalué à 5 (+3/-0).
Ça aurait mieux avec une source française ? https://www.radiofrance.fr/franceinter/podcasts/l-invite-de-8h20-le-grand-entretien/l-invite-de-8h20-le-grand-entretien-du-mercredi-05-mars-2025-7562174
[^] # Re: On veut voir le code !
Posté par Glandos . En réponse au lien Doom now runs in @TypeScript types. What a journey this one's been.. Évalué à 4 (+2/-0).
En fait, c'est là https://github.com/MichiganTypeScript/typescript-types-only-wasm-runtime
# On veut voir le code !
Posté par Glandos . En réponse au lien Doom now runs in @TypeScript types. What a journey this one's been.. Évalué à 3 (+1/-0).
Il est où le code, hein ?
Attend, la vidéo mentionne 177To de code source. Ouais, bon, euh, ça va, je te crois.
# C'est une commune
Posté par Glandos . En réponse au lien Commune de Meylan récompensée pour sa politique numérique, label « Territoire numérique libre ». Évalué à 2 (+0/-0).
Je précise que Meylan est une commune.
Non parce que ses habitants ont hérités d'un nom qui sonne tellement fort le laboratoire pharmaceutique (ou la société de service) que je me demandais ce que c'était.
Sinon, bravo à eux !
[^] # Re: Reproductibilité, vérifiabilité et musiciens de Brême
Posté par Glandos . En réponse à la dépêche Programmer des démonstrations : une modeste invitation aux assistants de preuve. Évalué à 2 (+0/-0).
« … seront toujours nos compagnons ! »
Oui, j'ai beaucoup écouté ça aussi.
# Du boulot pour les responsables UX
Posté par Glandos . En réponse au lien [Monded'Automates] Il fait quoi, derrière sa vitre, le gars de la RATP qui ne vend plus de tickets ?. Évalué à 2 (+1/-1).
La chronique n'a pas franchement d'intérêt. Elle manque tellement de profondeur que c'est navrant de se surprendre à avoir pitié de ce genre d'écriture fait pour soulever le cœur des lecteurs avec des émotions faciles.
Euh, je voulais dire quoi déjà ? Ah, oui, bien sûr, les automates. Non parce que l'autrice émet un constat qu'on a tous plus ou moins fait : les interfaces sont parfois confuses (au mieux), parfois à chier (soyons polis). Pourtant, on n'est pas dans le dark pattern, la RATP a bien envie d'en vendre le plus possible des tickets quand même.
Donc je n'ai pas de solution, mais pour moi, c'est clairement un problème d'expérience utilisateur mal fagotée. Oui, les gens s'énervent plus facilement en face d'une machine. Mais en même temps, ça pourrait être plus ergonomique…
[^] # Re: Piratage des liens
Posté par Glandos . En réponse au lien Go : attaque de la chaîne d'approvisionnement masquée par le cache des librairies. Évalué à 2 (+0/-0).
Ah, merci.
Je sais pourquoi je n'aime pas trop la déclaration des dépendances de Go du coup :)
# Piratage des liens
Posté par Glandos . En réponse au lien Go : attaque de la chaîne d'approvisionnement masquée par le cache des librairies. Évalué à 1 (+0/-1).
Le texte de l'article affichent des liens avec pour texte « github.com/boltdb-go/bolt » qui renvoie vers https://socket.dev/go/package/github.com/boltdb-go/bolt
Sérieusement ? C'est quoi ce phishing de bas étage ?
# Surveillance
Posté par Glandos . En réponse au journal Let's Encrypt arrête l'envoi des mails prévenant de l'expiration des certificats. Évalué à 6 (+4/-0).
Je suis en automatique, mais je surveille quand même : https://github.com/Matty9191/ssl-cert-check
D'ailleurs, je surveille pas que moi. ssl-cert-check envoie des courriels :)
[^] # Re: Dépendance à Microsoft
Posté par Glandos . En réponse au lien ICC braces for swift Trump sanctions over Israeli arrest warrants. Évalué à 9 (+7/-0).
Ah, j'aurais pas fait ça. Mais c'est peut-être pour ça que je ne suis pas employé par la CPI :)
# Les disques enregistrables grand public
Posté par Glandos . En réponse au lien Sony cesse la production de Blu-ray, MD et MiniDV. Évalué à 2 (+0/-0).
Si j'ai bien compris, c'est la production de disques BluRay inscriptible. C'est pas tout à fait la même chose que l'arrêt complet des BluRay.
Ça permet de mettre un terme au piratage. Oh, enfin presque :)