Glandos a écrit 1433 commentaires

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, 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.

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.

Vous avez des réponses ?

Je pense que PipeWire résout quand même bien le problème. Normalement, les interfaces de compatibilité avec JACK fonctionnent bien aujourd'hui.

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.

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.

https://www.theatlantic.com/politics/archive/2025/03/signal-group-chat-attack-plans-hegseth-goldberg/682176/

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).

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.

https://linuxfr.org/users/wilk/liens/typescript-porte-en-go

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.

Ç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. ?

/tmp [1] ❯ dd if=/dev/urandom of=/tmp/random bs=1k count=100M
dd: erreur d'écriture dans '/tmp/random': Aucun espace disponible sur le périphérique
9713473+0 enregistrements lus
9713472+0 enregistrements écrits
9946595328 octets (9,9 GB, 9,3 GiB) copiés, 25,2258 s, 394 MB/s
⏎                                                                                                                                                                                                                                             /tmp ⏰25s227ms[1] ❯ hyperfine "b3sum /tmp/random" "md5sum /tmp/random" "b3sum --num-threads 1 /tmp/random"
Benchmark 1: b3sum /tmp/random
  Time (mean ± σ):     466.7 ms ±   1.7 ms    [User: 5416.9 ms, System: 434.7 ms]
  Range (min … max):   464.9 ms … 469.2 ms    10 runs

Benchmark 2: md5sum /tmp/random
  Time (mean ± σ):     12.341 s ±  0.011 s    [User: 11.300 s, System: 1.040 s]
  Range (min … max):   12.322 s … 12.356 s    10 runs

Benchmark 3: b3sum --num-threads 1 /tmp/random
  Time (mean ± σ):      2.965 s ±  0.021 s    [User: 2.696 s, System: 0.267 s]
  Range (min … max):    2.945 s …  3.010 s    10 runs

Summary
  b3sum /tmp/random ran
    6.35 ± 0.05 times faster than b3sum --num-threads 1 /tmp/random
   26.44 ± 0.10 times faster than md5sum /tmp/random

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.

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 ?

https://github.com/microsoft/typescript-go

Pas étonnant pour un projet comme TypeScript de publier son code, mais j'aime bien mettre le lien.

Y a quand même des lockfile pour ça.

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.

Ç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

En fait, c'est là https://github.com/MichiganTypeScript/typescript-types-only-wasm-runtime

Il est où le code, hein ?

Attend, la vidéo mentionne 177To de code source. Ouais, bon, euh, ça va, je te crois.