Oui, ça paraît une évidence pour beaucoup de lecteurs par ici.
Mais la cible de Nextcloud, c'est tout le monde. Et en général, « tout le monde » n'a que que le Play Store sur son appareil. Voire, doit passer par des textes effrayants lors de l'ajout d'un autre magasin d'applications.
Je me suis un peu mal exprimé, mais disons un service système. Comme https://github.com/sentriz/gonic/ qui avec son mode Jukebox, lance un MPV qui sort du son.
Oui, bien sûr, c'est ce que j'ai fait, mais pourquoi un service système ne pourrait pas… je sais pas, faire des sons ? Comme des alarmes ? Et avec un utilisateur dédié qui n'a pas accès à mes fichiers ?
L'article est intéressant, parce que malgré son titre réducteur, il dit bien que beaucoup de choses bien sont en place et fiables, mais beaucoup de choses manquent.
Et j'ai également une question sans réponse : pourquoi root (ou le système) ne peut pas faire de son ? C'est incompréhensible. J'ai un serveur relié à mon ampli, qui peut jouer de la musique sur demande, mais je dois lancer une session utilisateur pour que ça marche. C'est débile, et ça n'a pas de logique pour moi.
Merci, ça faisait longtemps que j'avais cette histoire en tête.
C'était la Renault Mégane qui était présenté. Ils ont gardé la marque, mais le prototype a perdu beaucoup de choses. Il y avait les portes papillons, le coffre à plateau rétractable, les écrans de télévision à l'arrière, des tonnes de trucs qui faisaient bien rêver les jeunes geeks :)
A priori, l'article de la BBC parlent d'écouteurs à suppression de bruit active. Et pas de casque antibruit « simple ».
Ce n'est pas très clair, mais des articles comme https://noisyworld.org/noise-cancelling-headphones-vs-earmuffs/ montrent que le vocabulaire anglophone parle de earmuffs pour la version passive, et noise-cancelling headphones pour la version active. En tout cas, la notion de headphones est lié à la génération d'un son, et pas juste une atténuation telle que l'expression « casque antibruit » francophone le sous-entend.
Bref, c'est imprécis, c'est dommage. Après, il faut retenir que c'est un phénomène qu'on observe, pour l'instant inexpliqué, on cherche des causes.
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.
[^] # Re: utilisez f-droid
Posté par Glandos . En réponse au lien Google force l'application Nextcloud à ne plus accéder aux fichiers pour être synchronisés. Évalué à 9. Dernière modification le 13 mai 2025 à 14:49.
Oui, ça paraît une évidence pour beaucoup de lecteurs par ici.
Mais la cible de Nextcloud, c'est tout le monde. Et en général, « tout le monde » n'a que que le Play Store sur son appareil. Voire, doit passer par des textes effrayants lors de l'ajout d'un autre magasin d'applications.
[^] # Re: Pourquoi pas root ?
Posté par Glandos . En réponse au lien The audio stack is a crime scene. Évalué à 3.
Je me suis un peu mal exprimé, mais disons un service système. Comme https://github.com/sentriz/gonic/ qui avec son mode Jukebox, lance un MPV qui sort du son.
[^] # Re: Pourquoi pas root ?
Posté par Glandos . En réponse au lien The audio stack is a crime scene. Évalué à 2.
Oui, mais si tu utilises directement ALSA, et que le matériel n'a pas de mélangeur, alors aucune autre application ne peut sortir du son.
[^] # Re: Pourquoi pas root ?
Posté par Glandos . En réponse au lien The audio stack is a crime scene. Évalué à 3.
Oui, bien sûr, c'est ce que j'ai fait, mais pourquoi un service système ne pourrait pas… je sais pas, faire des sons ? Comme des alarmes ? Et avec un utilisateur dédié qui n'a pas accès à mes fichiers ?
# Pourquoi pas root ?
Posté par Glandos . En réponse au lien The audio stack is a crime scene. Évalué à 5.
L'article est intéressant, parce que malgré son titre réducteur, il dit bien que beaucoup de choses bien sont en place et fiables, mais beaucoup de choses manquent.
Et j'ai également une question sans réponse : pourquoi root (ou le système) ne peut pas faire de son ? C'est incompréhensible. J'ai un serveur relié à mon ampli, qui peut jouer de la musique sur demande, mais je dois lancer une session utilisateur pour que ça marche. C'est débile, et ça n'a pas de logique pour moi.
Vous avez des réponses ?
[^] # Re: la raison pour laquelle j'ai arrêté d'espérer la MAO sous Linux
Posté par Glandos . En réponse au lien The audio stack is a crime scene. Évalué à 5.
Je pense que PipeWire résout quand même bien le problème. Normalement, les interfaces de compatibilité avec JACK fonctionnent bien aujourd'hui.
[^] # Re: CO2e ok mais le reste ?
Posté par Glandos . En réponse au lien PoC d'un véhicule Renault: -90 % de CO2e sur tout le cycle de vie comparé à un modèle thermique 2019. Évalué à 2.
Merci, ça faisait longtemps que j'avais cette histoire en tête.
C'était la Renault Mégane qui était présenté. Ils ont gardé la marque, mais le prototype a perdu beaucoup de choses. Il y avait les portes papillons, le coffre à plateau rétractable, les écrans de télévision à l'arrière, des tonnes de trucs qui faisaient bien rêver les jeunes geeks :)
# Potentiel contre-sens
Posté par Glandos . En réponse au lien Les casques antibruit ont-ils des effets néfastes sur notre cerveau ? (traitement du son). Évalué à 9.
A priori, l'article de la BBC parlent d'écouteurs à suppression de bruit active. Et pas de casque antibruit « simple ».
Ce n'est pas très clair, mais des articles comme https://noisyworld.org/noise-cancelling-headphones-vs-earmuffs/ montrent que le vocabulaire anglophone parle de earmuffs pour la version passive, et noise-cancelling headphones pour la version active. En tout cas, la notion de headphones est lié à la génération d'un son, et pas juste une atténuation telle que l'expression « casque antibruit » francophone le sous-entend.
Bref, c'est imprécis, c'est dommage. Après, il faut retenir que c'est un phénomène qu'on observe, pour l'instant inexpliqué, on cherche des causes.
[^] # Re: Magie de GIT
Posté par Glandos . En réponse au lien Organic Maps abandonne Github et migre sur Forgejo. Évalué à 6.
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.
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.
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.
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.
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.
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.
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.
Ç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.
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.
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.
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.
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é à 7. 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.
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.
Ç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.
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.
Il est où le code, hein ?
Attend, la vidéo mentionne 177To de code source. Ouais, bon, euh, ça va, je te crois.