steph1978 a écrit 3375 commentaires

Tu les mets où les macro dans le csv ?

https://yewtu.be/watch?v=bYrkYSHJ_k4

Dans le diagramme données en exemple, je trouve que le positionner le block appname = "docker en dessous de la source prête à confusion.

Le ligne grise est trop fine pour comprendre que l’exécution reprend après le syslog, on (je) a l'impression qu'un nouveau traitement commence.

Je l'aurai plutôt vu en dessous du block appname = "prometheus" ; pour être à droite de la source.

Ne connaissant pas React Flow, je ne sais pas si l'agencement est automatique ou choisi par l'utilisateur. Dans le second cas, c'est d'autant plus facile à corriger ;)

J'ai pas creusé la doc ou le code mais comme c'est évoqué dans le journal, je pose la question ici.

Qu'est ce qui a dicté le choix de badgerdb plutôt qu'un base de données SQL type Postgres ou SQLite si on cherche de l'embarqué ?

Ma compréhension est que l'outil sert à définir et exécuter un traitement sur une source de logs. Je suppose donc que l'outil ne stocke que des données de "gestion", pas les données en elles-mêmes. Ainsi je ne vois pas le besoin d'un stockage spécialisé.

InfluxDB, LogStash, Graphana

Je trouve ces choix judicieux.

Stocker des logs dans ELS, c'est hyper luxueux. Il y a des produits plus économes comme Loki.

En même temps, je lis que - et je connais - des gens stockent leurs logs dans Spl€€€k alors pourquoi pas dans ELS.

Ce que tu stockes sur disque est peu important, en particulier si ça reste en autour de quelques 10aine de MB.

Ce qui est important, c'est le besoin en RAM, CPU, Stockage des data, bande passante.

Ainsi si il faut ajouter 10MB au binaire pour embarquer un moteur de stockage qui permet d'économiser des GB parce qu'il organise mieux les données, j'hésite pas.

De plus, afin de satisfaire les besoins les plus particuliers, son code est conçu pour être facilement étendu, tel un cadriciel (framework).

Qu'est ce qui peut être étendu ? Est-ce qu'il y a de la doc ? Est-ce qu'il y a déjà des réalisation d'extension ?

Ce que tu décris ressemble plutôt à zoxide : "A smarter cd command".

Atuin c'est pour améliorer la gestion de l'historique shell : stockage, recherche, synchro. Pour cela moi j'utilise (une version modifiée de) hishtory.

je n'ai pas su trouver les enregistrements des conférences précédentes, un lien ?

python ou perl

J'ai pas trop creusé ce langage en particulier mais j'aimerai beaucoup un langage comme python mais avec les capacités de redirection du shell : | et >. Donc il y a une niche à prendre.

Des gens font des trucs sérieux : Don’t Write, but Return: Replacing Output Parameters with Algebraic Data Types in C-to-Rust Translation

Don't be evil, be susan.

Et pourtant, Wikipedia, HTTP/3, premier paragraphe:

HTTP/3 uses QUIC, a multiplexed transport protocol built on UDP.[3]

Et dans l'article sur QUIC:

The second change is to use UDP rather than TCP as its basis

Je ne contestais pas la création de vilnérabilité ; je constestais le "volontairement".

Les +:

• le ratio fonctionalités / ratio
• que du HTML/HTTP standard et 3 lignes de JS
• la possibilité de fallback vers un chargement full page

Les -:

• que du remplace, pas d'ajout
• n'instrumente que les a et les form
• pas de gestion de l'historique
• l'utilisation du fragment

C'est une astuce interessante, à garder sous le coude

ou parfois un autre résolveur étatsunien comme 1.1.1.1 ou 9.9.9.9

À noter que Quad9 est suisse, pas américain.

Avoir du matériel Apple, c'est avant tout pour afficher son status social. Par conséquent, on ne peut pas afficher du vieux matériel Apple. Tu es presque obliger de t'excuser "oui c'est iphone 13 mais j'ai commandé le 15, promis".

créé volontairement des vulnérabilités ciblées exploitables

Ils ne parlent pas de transformer du code mis au commun mais plutôt leur base de code.

[…] vraiment bien équipé pour le monde de demain.

Très utile quand on aura plus d'eau potable, plus d'air respirable, plus assez de terres fertiles pour nourrir 10G d'êtres humains.

Je vais voir si mon pote qui est googlisé peut le faire à ma place.

Pas besoin d'être googlisé, pas besoin d'ami :), installe https://f-droid.org/en/packages/com.aurora.store/ et télécharge cette saloperie d'appli.

Pas de soucis avec le moinssage, je ne cherchais pas l'adhésion.

En revanche, je pense que sur ce type d'exercice de résumé/synthèse, un LLM est moins prompt aux hallucinations que sur une question ou une discussion ouverte. Il est borné par 21000 tokens, en génère 700. Sur une question ouvertes, il va prendre 50 tokens en entrée et en générer 500, beaucoup plus de place pour inventer.

Je serai même tenté de dire que si les tournures de texte ne sont pas trop alambiquées, il s'en sortira largement aussi bien qu'un humain. Que moi en tout cas.

Et si on a des sources sur le sujet, ce serait instructif.

"réflexe" supposerait que je le fais systématiquement, tu n'en sais absolument rien.
En l’occurrence, il s'agissait plus de curiosité, de voir ce qu'un LLM pourrait régurgiter.

plutôt que de lire la description

L'un n'empêche pas l'autre. Et puisque tu parles de réflexe, donc d'une pratique généralisée, note que toutes les vidéos n'ont pas une description et un plan bien écrit. Donc ta pratique n'est pas généralisable, cela ne peut pas constituer un réflexe efficace.

tu peut aussi commencer et arrêter à tout moment ta lecture

Mais si le contenu est intéressant, ça va prendre 1h20 alors que lire une synthèse me prendra 15 min.

Mon avis est que je ne vais pas regardé une vidéo de 1h20 sans savoir un peu de quoi cela parle.

La question n'est pas là. L'op s'attendait avec une implémentation naïve et similaire à un ordre de magnétude en faveur du C, car Javascript est dit interprété. Mais ce n'est pas vrai, JS dans Node et d'autres runtime est compilé par un JIT. Fin de l'histoire.

À ma connaissance, aucun runtime JS ne fait ce que tu décris.

Et d'après mes tests, node 20 ne le fait pas:

$ $TIME node wallis.js 
45280,101%,2.08,2.04,0.07,0,48,470,0

$ gcc -o wallis -O3 wallis.c ; $TIME ./wallis 
1516,99%,1.84,1.84,0.00,0,13,1,0

On vois que le JS comme le C n'utilisent qu'un seul CPU à 100% pendant environ 2s.

IMHO l'explication c'est le JIT qui va transformer le JS en instructions natives et donc avec des performance comparable à la compilation AOT du C.