Marrant, trois issues sur leur repo GH et exactement les question que je me suis posé :
d'où vient la liste des IP ? pourquoi je dois les croire ?
pourquoi 1500 lignes alors que ça tient en 100
pourquoi starlink et pas les autres acteurs GAFAM+NATU+XYZ ? Comme si les autres étaient moins pire que Musk ? Et les utilisateurs légitimes qui n'ont pas d'autres moyens d'accès à Internet, dommage collatéral ?
C'est le problème quand on veut moraliser le net, on tombe vite sur des contres sens.
J'ai écrit un outil un peu similaire, en python aussi. Ça fait du 25kl/s. Donc du même ordre de magnitude. GoAccess affiche 100kl/s … sur un i7.
Je gagne un peu de temps en déplaçant le parsing du log dans un script awk pour produire un format unique en TSV qui est d'ailleurs le facteur limitant dans le pipeline.
Le parsing de date est particulièrement et surprenamment coûteux en Python (et dans d'autre langage d'ailleurs) ; c'est souvent bénéfique de se passer de la lib standard et de faire le parsing soi-même.
Quant aux structures de données, yahi utilise archery, j'utilise defaultdict ; je suppose que cela ne fait pas grande différence.
De toutes façons 1/ il faut profiler pour savoir 2/ il ne faut pas attendre des performances de folie en Python.
J'ai une petite infra avec quelques services. Je génère 5M d'access logs par mois.
Quel temps cela prendrait de générer les statistiques pour ce volume ?
Mais c'est corolaire à ce que je dis : un entreprise n'est pas intrinsèquement bienveillante. Elle l'est si c'est nécessaire à son business. Si elle n'a pas le choix.
J'ai beaucoup aimé, j'attends la suite avec impatience.
J'ai pas résisté pour une des énigmes qui propose une table "confession". J'ai passé ça à un LLM: "dis moi qui a avoué le crime", il l'a trouvé direct.
Pour le reste, beaucoup de jointures et un peu de scrutation oculaire.
On peut construire des bibliothèques partagées en Rust. En particulier pour les utiliser dans d'autres langages compatibles avec l'ABI C. Il y en a pléthore pour Python d'ailleurs car c'est l'approche naturelle quand on veut accélérer des parties calculatoires dans ce langage interprété.
avoir un linker et un partage au niveau du binaire
* Moins d'espace disque ;
* Réutilisation, en mémoire, des pages RO (la section code des librairies) ;
* Load (beaucoup) plus rapide du code ré-allocatable ;
Sans parler des m.a.j. fonctionnelles ou de sécurité.
Cependant, je suis moins convaincu par ces arguments pour plusieurs raisons :
Nos PC ont maintenant des GB de RAM, plus des MB ; la réutilisation de quelques pages de mémoire devient moins intéressants
Les binaires Rust font du load dynamiques des bibliothèques des plus communes : libc, libm.
Plus important, l'approche de Rust est de faire une compilation des dépendances à partir des sources afin, grâce à une analyse statique, de n'embarquer que les fonctions appelées et donc de n'avoir dans le binaire que les instructions réellement utiles à l'application.
Cela a pour effet - outre le fait d'augmenter le temps de compilation :( - de minimiser la taille du binaire à charger, de garantir la sécurité mémoire, mais aussi de réduire la surface d'attaque.
De toute façon, le développeur a toute latitude pour utiliser des bibliothèques chargées dynamiquement, au travers des FFI.
Si c'est écrit en Rust, je me dis qu'il y a des chances que
l'outil soit un binaire standalone et c'est ce que je préfère installer.
l'outil soit rapide et ne prenne pas trop de mémoire pour rien
je puisse le builder si il n'y a pas de release binaire
que je puisse contribuer … quand je saurai faire du Rust pour de vrai
Si c'est écrit en Go, Elixir ou en Python, ça me va aussi, je saurai me débrouiller.
Si c'est écrit en C/C++, je tique un peu plus car je sais que le build sera une galère.
Si c'est écrit en JS/TS, je n'y touche même pas.
Les goûts et le couleurs, ça se discute bien sûr mais là ça annonce la couleur.
J'ai mis foultitude parce que je ne sais pas combien ni leurs tailles.
Mais pour une entreprise du numérique, 6M$, c'est rien du tout. Et d'ailleurs c'est sûrement plus. Mais à nouveau ça reste abordable.
L'hypothèse que tu donnes d'alimenter du RAG est intéressante aussi et générerai probablement un trafic non négligeable et permanent et est en effet encore plus abordable.
Je suis partisan de l'hypothèse que ces crawlers ont été écrit par des gens dont ce n'est pas la spécialité.
J'imagine les trésor d'ingéniosité qu'un produit comme google search a dû mettre dans son crawler : quoi scanner, quand, quand revenir, comment juger la pertinence de ce que je trouve, trouver les liens, stocker de manière efficace, créer des indexes, gérer le débit, les retry, le back-pressure, distribuer le travail à des dizaines/centaines de machines ; et sûrement mille autres qui ne me viennent pas. Et ce pendant des années où le web a grossi / changé.
Là une foultitude de boîtes se sont dit, il nous faut notre LLM, c'est pas si cher que ça (cf deepseek) et ont torché un système de crawling en quelques semaines / mois.
Et on se retrouve à devoir mettre des contre mesures qui pénalisent aussi les utilisateurs légitimes. C'est moche et j'espère qu'ils vont vite s’essouffler.
2016 : l'objectif de réduire à quasi néant l'industrie du smartphone en Europe étant atteint et après avoir dépensés quelques milliards de $ Microsoft jette l'éponge.
Loin de tenir MS dans mon cœur mais leur objectif était de "réduire à quasi néant l'industrie du smartphone en Europe" et il y aurait consacré quelques milliards ? On a des sources de ça ? ça a leaké ? Pourquoi seulement "quasi" ?
Le plus souvent c'est :
- gérer les dépendances -> venv
- performances -> ffi
- images trop lourd -> multi-stages
- difficile à distribuer -> pyinstaller, pyoxyde
Donc faux problèmes, "skill issue".
Alors que ce que tu pointe est réel.
Cela peut s'atténuer avec avec du typage (pydantic est merveilleux) et des linters mais cela nécessite de rajouter quelque chose au langage.
# issues
Posté par steph1978 . En réponse au lien Fuck Starlink. Évalué à -1.
Marrant, trois issues sur leur repo GH et exactement les question que je me suis posé :
C'est le problème quand on veut moraliser le net, on tombe vite sur des contres sens.
[^] # Re: performances ?
Posté par steph1978 . En réponse à la dépêche yahi un agrégateur de statistiques dans l'esprit d'awstats. Évalué à 2.
J'ai écrit un outil un peu similaire, en python aussi. Ça fait du 25kl/s. Donc du même ordre de magnitude. GoAccess affiche 100kl/s … sur un i7.
Je gagne un peu de temps en déplaçant le parsing du log dans un script
awkpour produire un format unique en TSV qui est d'ailleurs le facteur limitant dans le pipeline.Le parsing de date est particulièrement et surprenamment coûteux en Python (et dans d'autre langage d'ailleurs) ; c'est souvent bénéfique de se passer de la lib standard et de faire le parsing soi-même.
Quant aux structures de données,
yahiutilise archery, j'utilise defaultdict ; je suppose que cela ne fait pas grande différence.De toutes façons 1/ il faut profiler pour savoir 2/ il ne faut pas attendre des performances de folie en Python.
[^] # Re: Python 2, abandonné?
Posté par steph1978 . En réponse à la dépêche yahi un agrégateur de statistiques dans l'esprit d'awstats. Évalué à 6.
Par curiosité, pourquoi utiliser debian 8 plus supportée depuis 5 ans alors que debian 12 supporte très bien le matériel ancien ?
J'ai un pc de 2008 en 32bit et il n'a pas de soucis à tourner sous Bookworm…
# performances ?
Posté par steph1978 . En réponse à la dépêche yahi un agrégateur de statistiques dans l'esprit d'awstats. Évalué à 3.
J'ai une petite infra avec quelques services. Je génère 5M d'access logs par mois.
Quel temps cela prendrait de générer les statistiques pour ce volume ?
[^] # Re: intéressant
Posté par steph1978 . En réponse au lien Critique de "Careless people". Évalué à 6.
C'est vrai que c'est le propos.
Mais c'est corolaire à ce que je dis : un entreprise n'est pas intrinsèquement bienveillante. Elle l'est si c'est nécessaire à son business. Si elle n'a pas le choix.
# intéressant
Posté par steph1978 . En réponse au lien Critique de "Careless people". Évalué à 2.
J'ai l'impression que ça s'applique à toute boite capitaliste mais la description du cas facebook est instructive
[^] # Re: Mieux
Posté par steph1978 . En réponse au lien Python en production. Évalué à 2. Dernière modification le 22 avril 2025 à 07:55.
Le premier article a été commenté ici : https://linuxfr.org/users/woffer/liens/difficile-de-recommander-python-en-production
[^] # Re: cheater arrête de cheater :D
Posté par steph1978 . En réponse au journal retour sur SQL noir 🎭. Évalué à 2.
Copier colle le résultat du sélect, oui
# XP: 1900
Posté par steph1978 . En réponse au journal retour sur SQL noir 🎭. Évalué à 2.
J'ai beaucoup aimé, j'attends la suite avec impatience.
J'ai pas résisté pour une des énigmes qui propose une table "confession". J'ai passé ça à un LLM: "dis moi qui a avoué le crime", il l'a trouvé direct.
Pour le reste, beaucoup de jointures et un peu de scrutation oculaire.
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par steph1978 . En réponse au lien Outil de renommage en masse de fichiers écrit en Rust. Évalué à 2.
On peut construire des bibliothèques partagées en Rust. En particulier pour les utiliser dans d'autres langages compatibles avec l'ABI C. Il y en a pléthore pour Python d'ailleurs car c'est l'approche naturelle quand on veut accélérer des parties calculatoires dans ce langage interprété.
Cependant, je suis moins convaincu par ces arguments pour plusieurs raisons :
Nos PC ont maintenant des GB de RAM, plus des MB ; la réutilisation de quelques pages de mémoire devient moins intéressants
Les binaires Rust font du load dynamiques des bibliothèques des plus communes : libc, libm.
Plus important, l'approche de Rust est de faire une compilation des dépendances à partir des sources afin, grâce à une analyse statique, de n'embarquer que les fonctions appelées et donc de n'avoir dans le binaire que les instructions réellement utiles à l'application.
Cela a pour effet - outre le fait d'augmenter le temps de compilation :( - de minimiser la taille du binaire à charger, de garantir la sécurité mémoire, mais aussi de réduire la surface d'attaque.
De toute façon, le développeur a toute latitude pour utiliser des bibliothèques chargées dynamiquement, au travers des FFI.
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par steph1978 . En réponse au lien Outil de renommage en masse de fichiers écrit en Rust. Évalué à 2.
Pour le cas qui nous concerne ici : 3.0MB.
# un jour
Posté par steph1978 . En réponse à la dépêche Hyprland, un compositeur Wayland « tiling ». Évalué à 4.
Un jour je m'installerai un WM Tiling à la place de Gnome.
Je sais qu'il y a une petite marche alors je rechigne mais je sais que ça me plaira.
J'y ai repensé quand j'ai lu cet article : The Future is Niri.
[^] # Re: On s’en fiche que ça soit « écrit en Rust »
Posté par steph1978 . En réponse au lien Outil de renommage en masse de fichiers écrit en Rust. Évalué à 4.
Perso je m'en fous pas.
Si c'est écrit en Rust, je me dis qu'il y a des chances que
Si c'est écrit en Go, Elixir ou en Python, ça me va aussi, je saurai me débrouiller.
Si c'est écrit en C/C++, je tique un peu plus car je sais que le build sera une galère.
Si c'est écrit en JS/TS, je n'y touche même pas.
Les goûts et le couleurs, ça se discute bien sûr mais là ça annonce la couleur.
# 50 de FUD, de lobby, de vente forcée, de tromperie
Posté par steph1978 . En réponse au lien Celebrate 50 years of Microsoft with the company's original source code. Évalué à 3.
let's celebrate
[^] # Re: présentation
Posté par steph1978 . En réponse au lien Celebrate 50 years of Microsoft with the company's original source code. Évalué à 2.
Moi je m'attendais à pire :
Pour un truc qui devait parlé de bilou, je suis pas déçu.
# pas vilain
Posté par steph1978 . En réponse au lien Firefox 137 sait enfin grouper les onglets et supporte le codec HEVC sous Linux. Évalué à 3.
Moins impressionnant quand on a l'habitude d'utiliser Tree Style Tab mais ça peut avoir son utilité.
[^] # Re: concrètement ?
Posté par steph1978 . En réponse au lien Stupeur dans les entreprises françaises après une lettre de l’ambassade américaine à Paris. Évalué à 2.
D'accord, donc des règles anti discrimination positive.
Je vois le dilemme pour une boite française / européenne. Mais ils vont bien trouver une pirouette.
# concrètement ?
Posté par steph1978 . En réponse au lien Stupeur dans les entreprises françaises après une lettre de l’ambassade américaine à Paris. Évalué à 3.
C'est quoi ses règles anti diversité ? Faut que les contractors emploient que des hommes blancs, valides, droitiers, binaires et hétéro ?
[^] # Re: vibe coding
Posté par steph1978 . En réponse au lien Le site de curl désormais à 1,6 Go/minute de trafic à cause des crawlers pour LLMs. Évalué à 3.
J'ai mis foultitude parce que je ne sais pas combien ni leurs tailles.
Mais pour une entreprise du numérique, 6M$, c'est rien du tout. Et d'ailleurs c'est sûrement plus. Mais à nouveau ça reste abordable.
L'hypothèse que tu donnes d'alimenter du RAG est intéressante aussi et générerai probablement un trafic non négligeable et permanent et est en effet encore plus abordable.
[^] # vibe coding
Posté par steph1978 . En réponse au lien Le site de curl désormais à 1,6 Go/minute de trafic à cause des crawlers pour LLMs. Évalué à 10.
Je suis partisan de l'hypothèse que ces crawlers ont été écrit par des gens dont ce n'est pas la spécialité.
J'imagine les trésor d'ingéniosité qu'un produit comme google search a dû mettre dans son crawler : quoi scanner, quand, quand revenir, comment juger la pertinence de ce que je trouve, trouver les liens, stocker de manière efficace, créer des indexes, gérer le débit, les retry, le back-pressure, distribuer le travail à des dizaines/centaines de machines ; et sûrement mille autres qui ne me viennent pas. Et ce pendant des années où le web a grossi / changé.
Là une foultitude de boîtes se sont dit, il nous faut notre LLM, c'est pas si cher que ça (cf deepseek) et ont torché un système de crawling en quelques semaines / mois.
Et on se retrouve à devoir mettre des contre mesures qui pénalisent aussi les utilisateurs légitimes. C'est moche et j'espère qu'ils vont vite s’essouffler.
[^] # Re: Trop de raccourcis ....
Posté par steph1978 . En réponse au lien Qu l'eut cru : les débuts de Nokia. Évalué à 3.
Loin de tenir MS dans mon cœur mais leur objectif était de "réduire à quasi néant l'industrie du smartphone en Europe" et il y aurait consacré quelques milliards ? On a des sources de ça ? ça a leaké ? Pourquoi seulement "quasi" ?
# quelle résolution ?
Posté par steph1978 . En réponse au journal Un super Logic Analyzer DIY pour pas cher. Évalué à 2.
J'ai vu/lu du 100MHz et du 400MHz…
[^] # Re: Pendant ce temps là, dans un univers parallèle
Posté par steph1978 . En réponse au lien Microsoft utilise Go pour son portage Typescript (et expliquent pourquoi ce n'est pas écrit en Rust). Évalué à 2.
La publication de MS date du 11.
[^] # Re: Oui, mais pas ce que je retiens comme vrais problèmes de Python
Posté par steph1978 . En réponse au lien Difficile de recommander Python en production . Évalué à 2. Dernière modification le 23 mars 2025 à 16:49.
Oui, encore faut il que la lib et ses bindings existent
Après, il faut être patient, Mojo arrive.
Et comme cela te titille, regarde codon.
[^] # Re: Oui, mais pas ce que je retiens comme vrais problèmes de Python
Posté par steph1978 . En réponse au lien Difficile de recommander Python en production . Évalué à 2. Dernière modification le 23 mars 2025 à 02:46.
Voici enfin des critiques fondées de ce langage.
Le plus souvent c'est :
- gérer les dépendances -> venv
- performances -> ffi
- images trop lourd -> multi-stages
- difficile à distribuer -> pyinstaller, pyoxyde
Donc faux problèmes, "skill issue".
Alors que ce que tu pointe est réel.
Cela peut s'atténuer avec avec du typage (pydantic est merveilleux) et des linters mais cela nécessite de rajouter quelque chose au langage.