steph1978 a écrit 3405 commentaires

1500 lignes dans la liste des IP Range.
Qui peuvent se résumer en 70 si les ranges consécutives sont fusionnées.

Disons que pour moi c'est un bad smell car je ne comprends pas comment la liste a été faîte.

Oui, c'est ce qu'ils (qui sont-ils d'ailleurs ?) exposent sur leur site. Ça ne change pas vraiment mon questionnement.

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.

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…

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 ?

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.

J'ai l'impression que ça s'applique à toute boite capitaliste mais la description du cas facebook est instructive

Le premier article a été commenté ici : https://linuxfr.org/users/woffer/liens/difficile-de-recommander-python-en-production

Copier colle le résultat du sélect, oui

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.

Pour le cas qui nous concerne ici : 3.0MB.

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.

Perso je m'en fous pas.

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.

let's celebrate

Moi je m'attendais à pire :

Application error: a client-side exception has occurred (see the browser console for more information).

Pour un truc qui devait parlé de bilou, je suis pas déçu.

Moins impressionnant quand on a l'habitude d'utiliser Tree Style Tab mais ça peut avoir son utilité.

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.

C'est quoi ses règles anti diversité ? Faut que les contractors emploient que des hommes blancs, valides, droitiers, binaires et hétéro ?

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" ?

J'ai vu/lu du 100MHz et du 400MHz…

La publication de MS date du 11.