Glandos a écrit 1402 commentaires

S'il vous plaît, ça va trop vite pour moi, et y a rien dans Wikipédia sur ce sujet :

Qu'est-ce qu'un « faf » ? Un acronyme, un sobriquet ?

Jamais vu un article de Phoronix aussi long…

Ça ressemble à un pivot de Intel, connu pour fabriquer du matériel, et qui va probablement vendre du logiciel à la place. Enfin, ptêt que je vais trop vite en besogne…

Je suis désolé, je viens de lire l'entretien avec RMS.

Et donc, ça n'a rien d'open du tout. Pour moi, un système open, ça serait de pouvoir monter dans le bus avec une pièce de 2€, et voilà. La carte bancaire reste un moyen de tracer, très efficace.

J'ai sévèrement lutté pour avoir un titre de transport anonyme pour mes enfants : même les guichetiers ne savaient plus comment faire, tellement personne ne demande, tellement c'est caché sur le site. Si j'avais le temps, j'irai voir le défenseur des droits, la CNIL, etc. J'ai pas le temps, je râle sur place, c'est tout.

Merci pour la recherche.

Encore heureux que la biométrie n'est pas obligatoire pour accéder à la cantine. Ça serait bien injustifiable si c'était le cas. Franchement, c'est quoi le problème avec les cartes de cantine ? Tu la perds ? Ben tu la re-paye, oui, OK.

Si je barre une partie du texte à signer, que vaudra cette autorisation ?

Le droit à l'image n'est pas acquis par défaut. Donc tu mets ce que tu veux, c'est opposable.

Évidemment, une fois que les images ou voix sont publiées publiquement, c'est trop tard. Donc… il faut compter aussi sur la confiance.

Mon exemple, un peu détourné, était celui de la biométrie pour le passage à la cantine du collège de mon fils : on a refusé, mais ils ont quand même pris son empreinte, j'imagine qu'ils n'ont pas lu la réponse…

Bon bah, il a carrément créé https://github.com/tt-rss/tt-rss pour être complètement plus clair.

Je valide aussi, wn était le contributeur externe le plus actif. D'ailleurs, c'est plutôt lui qui pilotait la maintenance, fox ne faisait que valider.

Je suis content qu'il ait pris les rênes, parce que tt-rss contenait effectivement plein de dépôts git séparés, qu'il semble avoir tous copiés. Après, dommage pour le choix de GitHub, mais OK :)

Alors, ça ne couvre pas du tout mon cas d'utilisation. Des fois, je ne suis pas sur mon ordinateur. Des fois, je ne suis même pas sur mon propre appareil, ou bien je ne peux pas installer de client terminal pour accéder à une session Emacs via tmux.

Et puis, le RSS, c'est surtout du Web. Donc souvent, je clique sur les liens de l'article pour aller plus loin, voir les flux non complets (derrière un paywall), et dans le terminal, ça ne va vraiment pas le faire, désolé :)

Les choses commençaient à évoluer dans le bon sens.

Attention, je n'excuse rien de ce qui s'est passé avant, il a eu un comportement et des réactions inacceptables.

Simplement, ces derniers temps, les réponses étaient plus objectives, plus terre-à-terre. Ça vient peut-être de pair avec la fermeture totale, je ne sais pas.

Le San Francisco Standard rappelle que la Cour suprême chinoise a déjà statué qu’il était illégal de contraindre les travailleurs à travailler à ce rythme sans compensation supplémentaire et que ce phénomène “a suscité des protestations et des accusations d’esclavage moderne, et a été lié à des morts d’ouvriers”.

C'est-à-dire que citer la justice chinoise pour contrer une démocratie les USA, c'est assez rigolo quand même.

C'est bon, j'ai ma réponse : https://github.com/yt-dlp/yt-dlp/issues/14404#issuecomment-3330980464

Je me suis demandé pourquoi ils n'ont pas utilisé bun (https://bun.sh/) qui utilise le moteur JS de Safari, donc normalement, ça tient la route.

Après, deno c'est du V8, ça va aussi, mais bun est quand même pas mal plus rapide.

Ouais, mais bon, la géométrie sur les espèces ayant évoluées pendant des millions d'années (et je suis gentil), ça finit en coup de bol pour nous finalement, non ?

quand on fait des sérologies Lyme aux prétendus malaldes du Lyme, elles reviennent systématiquement négatives.

Contexte : j'ai eu un membre de ma famille touché par Lyme.

Question : cette personne m'a dit que les tests faits en France sont conçus pour détecter les bactéries présentes principalement en Amérique du Nord, et qui sont beaucoup moins présentes en Europe de l'Ouest, et notamment en France. J'ai cru comprendre que c'était un sujet très contesté, alors si quelqu'un avait des références… Ça m'aiderait :)

(Oui, c'est question n'avait pas de point d'interrogation, et désolé Liorel, ce n'est pas ton domaine de compétence, mais peut-être tu connais quand même quelque chose sur ça…)

Je ne moinsse pas beaucoup, et je n'ai pas moinssé ce lien, mais je trouve pourtant qu'il n'a pas trop sa place ici.

Il n'y a pas de ligne éditoriale sur LinuxFR, mais à part le fait que ça concerne des comptes Mastodon, c'est quoi le rapport ?

Attention hein, j'ai bien conscience de la tragédie que subit la population de Gaza, ça mérite de l'attention, mais ce n'est pas le genre de contenu que je cherche quand je viens ici.

Bon courage à eux quand même :/

Commandes

/tmp/ncdu : ncdu 2.9.1 binaire statique téléchargé depuis https://dev.yorhel.nl/ncdu
ncdu : ncdu 1.22 de Debian/unstable
/tmp/gdu_linux_amd64 : gdu 5.31 téléchargé depuis https://github.com/dundee/gdu/releases/tag/v5.31.0

Mon disque est un SSD Samsung 850 Pro

Par défaut, gdu utilise 16 CPU, je l'ai donc testé à 8 également, pour le comparer à ncdu que je n'ai que testé à 8. Après tout, c'est le nombre de cœurs physiques de ma machine. Et je l'ai testé avec 1 seul CPU, pour le comparer à ncdu sur la non-parallélisation.

Les tests sont lancés avec hyperfine.

Test 1 : TMPFS de 4,2Go

Mon /tmp possède un dépôt git de 1 Go et un cache de cargo en train de compiler. On teste donc la vitesse de calcul.

Summary
  /tmp/ncdu -0 -o /dev/null -t8 '/tmp' ran
    1.91 ± 0.60 times faster than ncdu -0 -o /dev/null '/tmp'
    2.63 ± 0.85 times faster than /tmp/ncdu -0 -o /dev/null '/tmp'
    3.50 ± 1.10 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null --max-cores 8 '/tmp'
    4.25 ± 1.41 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null '/tmp'
    6.80 ± 2.14 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null --max-cores 1 '/tmp'

Test 2 : /home/glandos

Là, j'ai exclu les points de montage, j'ai du NFS, donc je n'ai gardé que ce qui se trouve sur mon SSD. J'ai fait également une première passe à blanc pour tout mettre dans le cache. Il y a quand même 144 Go.

Summary
  /tmp/ncdu -0 -o /dev/null -t8 -x '/home/glandos' ran
    3.02 ± 0.05 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null -x '/home/glandos'
    3.19 ± 0.06 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null --max-cores 8 -x '/home/glandos'
    4.18 ± 0.07 times faster than /tmp/ncdu -0 -o /dev/null -x '/home/glandos'
    4.47 ± 0.08 times faster than ncdu -0 -o /dev/null -x '/home/glandos'
   11.43 ± 0.21 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null --max-cores 1 -x '/home/glandos'

Test 2bis : on enlève les caches

hyperfine est lancé avec --prepare "echo 3 > /proc/sys/vm/drop_caches" (et oui, j'ai lancé ça en root, c'est plus simple) qui va vider le cache entre chaque commande. Les commandes ne sont exécutées que 3 fois (au lieu de 10), parce que c'est vraiment trop lent sinon.

Summary
  /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null -x '/home/glandos' ran
    1.12 ± 0.02 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null --max-cores 8 -x '/home/glandos'
    1.25 ± 0.05 times faster than /tmp/ncdu -0 -o /dev/null -t8 -x '/home/glandos'
    7.01 ± 0.13 times faster than /tmp/ncdu -0 -o /dev/null -x '/home/glandos'
    7.04 ± 0.15 times faster than ncdu -0 -o /dev/null -x '/home/glandos'
    7.87 ± 0.15 times faster than /tmp/gdu_linux_amd64 --non-interactive --no-progress --output-file /dev/null --max-cores 1 -x '/home/glandos'

Test bonus

ncdu 2.9.1 compilé en statique fait 768280 octets, soit 768 ko.
gdu 5.31 compilé en statique fait 15413432 octets, soit 15 Mo.

Ma conclusion

Le parallélisme, c'est bien, mais j'ai l'impression que ncdu va rester mon choix. Ça va quand même plus vite sur tous les cas, sauf la version sans cache avec 16 flux d'exécution, et je n'ai même pas testé ncdu avec 16 flux…
Et tout ça dans moins de 1 Mo statique, s'il vous plaît.

Après, OK, gdu est plus joli.

D'après https://dev.yorhel.nl/ncdu la version 2 de NCDU possède le parallélisme également. Mais je ne l'ai pas testée, elle n'est pas empaquetée, et c'est en Zig, bref, ça me demande un gros effort :)

Mais je ne me souviens plus de son nom !
En gros, ça permettait de rentrer une URL, et le site renvoyait dans une iframe le contenu du site original en remplaçant certains mots par d'autres, rendant le texte complètement loufoque. C'était rigolo, en tout cas en 2005.

Cette conclusion dit :

Installing packages 25x faster isn't "magic": it's what happens when tools are built for the hardware we actually have.

L'article est plutôt généraliste. Vous pouvez le lire en diagonale si les allocateurs mémoires n'ont pas de secret pour vous. Mais ça explique bien pourquoi Bun est plus rapide, et ce n'est pas seulement parce que c'est écrit en langage compilé (Zig).

Quant à une portée de variable limité à un bloc qui ne soit pas une boucle ou une fonction, je peine à imaginer un cas où c'est d'un usage convainquant ; je suis preneur d'un exemple.

with open("/etc/hosts") as f:
  print(f.readlines())

C'est assez utile, les context managers en Python, et c'est justement fait pour ça :)

Je ne sais pas si je ferai le changement. Déjà parce que j'utilise un certificat wildcard, ensuite parce que mon serveur héberge également un serveur IMAP (dovecot) SMTP (postfix), XMPP (prosody), qui ont également besoin de certificats, et donc j'aurais de toutes façons besoin d'un truc pour eux.

Mais mon cas d'utilisation n'est pas la seule vérité dans ce monde, évidemment que c'est très utile d'avoir le serveur Web qui gère tout seul le certificat :)

Oui, enfin, nginx est dispo dans beaucoup de distro. Compiler un module nginx, c'est vraiment facile ET rapide.
Bien plus que d'installer un conteneur docker qui doit avoir accès à un volume sur le disque en dehors de son conteneur je trouve. En tout cas, c'est moins alambiqué.

Après, je n'ai pas encore lu le module en Rust, peut-être qu'il ne faudra pas le recompiler à chaque version ?

Note: Dino m'a bien transmis la demande de connexion, mais il ne me permet pas de répondre, dommage :/ Gajim m'a permis de le faire :)

Avec poezio, ça a marché. Il m'a juste fallu le temps de retrouver comment changer d'onglet :)

C'est vraiment intéressant. Par contre, si on veut pouvoir profiter de cette flexibilité, il faut que ça soit rapidement itérable, et là, c'est forcément du script.
Je crois que c'est vaguement possiblement avec Java aujourd'hui (coucou jshell), mais il faudrait un truc de script pour vraiment en profiter. Après, c'est pas la panacée :

• Python. Probablement ce qu'il y a de mieux, mais pas sans défaut
• JS. Ahah, même si avec bun, ça peut le faire
• Perl, bienvenue dans les années 2000
• Shell, bienvenue dans les années 1970
• lua, l'écosystème est limité, mais le langage se prête à se genre de chose

Par contre la stupidité des réseaux de recharge où un conducteur de véhicule électrique devrait avoir une dizaine de cartes de différents réseaux… vive le marché libre et auto-régulé…

Ça, je ne comprends pas. On ne peut pas dire qu'on a besoin de X kWh, payer (par CB ou cash), et se faire livrer ? Ça veut dire que si tu viens de l'étranger, sans carte bancaire, tu fais comment ?