AI-scrapers slokken 20 procent van cpu-capaciteit Kernel.org op

Bij Kernel.org gaat inmiddels zo’n twintig procent van de cpu-capaciteit op aan het renderen van commits voor AI-scrapers. Dat vergt veel meer cpu-capaciteit dan andere vormen van legitieme toegang, waaronder Git-clones. Kernel.org ziet zich daardoor genoodzaakt om bepaalde functionaliteit uit te schakelen.

Git.kernel.org krijgt dagelijks zo'n 6 miljoen verzoeken voor individuele commitpagina's, schrijft Konstantin Ryabitsev, die bijdraagt aan de infrastructuur van Kernel.org. Daardoor zijn op elk moment 14 tot 16 cpu cores alleen maar bezig met Git-commits omzetten naar HTML. In totaal heeft Kernel.org 90 cpu cores, verspreid over vijf locaties.

Het probleem zit hem volgens Ryabitsev in hoe de scrapers door de geschiedenis van Linux heengaan. Een scraper kan alle repository's klonen en lokaal alle commits doorlopen. Maar in plaats daarvan vragen veel scrapers om één commitpagina per keer. Die pagina moet dan omgezet worden naar HTML, waarna de scraper om de volgende vraagt.

De algemene Linux-repository heeft nu zo'n 1,48 miljoen commits. Daarnaast zijn er zo'n 922 forks op git.kernel.org, met doorgaans diezelfde commits. Dat levert enkele miljarden valide URL's op die allemaal gescrapet kunnen worden, concludeert Ryabitsev. "Om vervolgens te eindigen met 922 duplicaten van dezelfde 1,48 miljoen commits." Daarnaast kunnen de scrapers om patches, diffs en platte tekst vragen, waardoor het aantal URL's nog verder toeneemt.

Weinig echte oplossingen

Kernel.org heeft op verschillende manieren geprobeerd het verkeer terug te dringen. Zo blokkeerde Kernel.org bepaalde IP-adressen en netwerken. Maar de scrapers stapten over op residentiële en mobiele proxynetwerken, waardoor dat minder effectief werd.

Kernel.org heeft ook Anubis ingezet, dat bezoekers een kleine uitdaging laat oplossen voor ze een site kunnen bezoeken. De scrapers wisten zich daar ook op aan te passen en een deel lost inmiddels ook moeilijkere uitdagingen op.

Kernel.org ziet zich nu genoodzaakt om bepaalde functies uit te zetten om het aantal crawlbare URL's te verminderen. Daarnaast worden kostbare acties beperkt voor anonieme gebruikers. "Maar we beloven dat al onze gegevens te downloaden blijven voor iedereen die daarom vraagt. Het kan alleen zijn dat je door meer hoepels moet springen om ze te bemachtigen", zegt Ryabitsev.

Update, 14.52 uur – In het artikel stond dat er 90 cpu's waren, waarvan er 14-16 gebruikt worden voor het omzetten van Git-commits naar HTML. Dat moeten cpu cores zijn. Het artikel is daarop aangepast.

Reacties (121)

[Keypunchie]

Misschien meebewegen en een speciale "AI API" toevegen en daarnaar verwijzen in je llms.txt. Op die manier maak je het proces efficient voor de bots.

Voor de gewone API een stevige rate-limiter invoeren.

[Reactie gewijzigd door Keypunchie op 31 augustus 2026 12:50]

[laurxp]

Er is al een efficiënte manier om bij die data te komen - namelijk de reguliere Git API!

De scrapers hebben hier echter schijt aan, en kiezen ervoor om bewust iedere vorm van "robots.txt" te negeren en dom iedere webpagina te scrapen en alle links te volgen. Een speciale API voor LLMs zal dus gewoon genegeerd worden.

Die "stevige rate-limiter" hebben ze al, maar die zijn de scrapers aan het omzeilen. Ze gebruiken namelijk residential proxies, waarbij het verkeer via bijvoorbeeld een smart tv in een willekeurige woonkamer loopt. Ieder request komt van een ander IP, dus blocken is praktisch onmogelijk zonder ook alle legitieme eindgebruikers tegen te houden.

[Blokker_1999]

En dat is een gentlemen's agreement. Die scrapers gaan zich daar niet aan houden, al helemaal niet als je er een rate limiter op gaat zetten. Want dan gaat het te traag terwijl ze via de gewone website aan volle snelheid kunnen gaan.

[Themperror]

ipv alle pagina's constant te recoden naar html.. kun je ook gewoon alles van tevoren 1x baken, en dan alleen wanneer een commit erbij komt de relevante pagina's opnieuw doen, en voor al die requests kan je ze dan gewoon doorverwijzen naar de prebaked pagina.. hup, meeste CPU usage meteen weg

[nzall]

Als we uitgaan van 10 kilobyte voor elke prebaked pagina (sommige zijn kleiner, andere zijn groter), en dan 2 miljard pagina's die moeten geprebaked worden (1000 repositories met elk 1,5M commits en 500K niet-commit pagina's), dan is dat 20 TB aan pagina's die moeten opgeslagen worden. Ik zou dan zelf eerder denken aan een cache systeem, want ik vermoed dat het overgrote deel van die pagina's zelden tot nooit wordt opgevraagd.

[Goderic]

Is het probleem met scrapers net niet dat ze alles opvragen wat ze kunnen?

[FreezeXJ]

Dus jij stelt voor om 20 TB aan paginas te gaan cachen, alleen maar omdat een stel scrapers niet gewoon een git-logica inbouwt, of zich aan een robots.txt houdt? In alle gevallen is dit een totale verspilling van resources, en dan zie ik liever dat dit soort requests gewoon een instant vermelding op de blacklist krijgt.

[latka]

Beter nog: vervuil de data gewoon. Dikke errors in de code introduceren voor de scrapers en voor je het weet serveren de top-llms alleen nog maar buggy code

[latka]

Als het alleen voor AI/scraping doeleinden is zie ik niet waarom de last moet liggen bij de aanbieder van de informatie. Zelf hebben ze het niet echt nodig.

[Themperror]

Dit gaat voor iedereen op het internet een probleem worden, het is niet iets dat je kan gaan wegleggen bij de gebruikers, dit is een core-framework change die elke webhost gewoon moet gaan toepassen

[latka]

Dit is investeren in meer storage voor cache. Als het doel alleen is om ai bots te ondersteunen is blokkeren een logischere oplossing.

[Themperror]

Dit gaat niet gebeuren, het is ook niet echt te doen, want je kan niet echt onderscheiden tussen een crawler en een user, totdat je een bepaalde user-defined threshold overschrijd...

AI is here to stay, wat er moet gebeuren is een een verandering in hoe de software efficient om kan gaan met AI crawlers, ipv ze proberen te blokkeren etc, dat is een race die je niet wint.. Er is veel meer dan alleen dit dat moet veranderen om om te gaan met de moderne wereld, blijven vasthouden aan oude ideeen van "dit is hoe het moet werken" en alles eromheen proberen tegen te houden gaat niet werken..

[latka]

Oh, ai is here to stay indeed. Maar de bedrijven die het nu runnen doen dat niet echt verantwoord of ethisch zoals hier ook blijkt. Dat moet veranderen: zelf die Git repo klonen en de paginas renderen bijv.

[Themperror]

Je kan dit niet bij de gebruikers wegleggen, het "honor-model" werkt niet, je kan niet lief vragen "alsjeblieft doe dit niet" en verwachten dat het werkt, en zijn een veelal bedrijven (*cough china, rusland cough*) die daar niks om geven, het moet goed werken ongeacht of je je aan de regels houdt of niet, dat is de enigste manier

[latka]

Of dus gewoon een slot erop of beter nog: fake content tonen bij detectie. En wijzen naar Rusland en China terwijl de usa ook gewoon lekker meedoet is wat goedkoop.

[Themperror]

[quote]Of dus gewoon een slot erop of beter nog: fake content tonen bij detectie[/quote]

Dit gaat dus niet, je kan de bots niet echt onderscheiden van de echte mensen..

[thomasv]

Ja iets met caching enzo, maar vereist meer werk dan ooit van origine noodzakelijk was qua implementatie aan de kernel.org zijde.

[TD-er]

Een cache is vrij letterlijk iets wat relatief klein is tijdelijk bewaren omdat het vaak opgevraagd wordt en het opnieuw genereren meer resources kost.

Echter deze bots vragen _alles_ op. Dat is niet te cachen.

Heb hetzelfde met het ESPEasy forum. Met Anubis hebben we dat nu redelijk onder controle, maar het was 100k+ botjes die tegelijkertijd elk 1 pagina opvragen, op een forum met minder dan 100k posts. Per etmaal zo'n 2.5 milioen unieke IP-adressen.

Nu met Anubis had ik vorige week nog 300+ Mbps aan inkomende requests van bots te verwerken. Dit was gemiddelde per 5 minuten, meerdere van die spikes, 30+ GByte in iets meer dan een uur.

[DeRinus]

2e feature op de lijst is "caching of generated html" https://git.zx2c4.com/cgit/about/

1,48 miljoen commits x 922 forks met ongeveer dezelfde commits x 4 formaten (html,raw,diffs,patches). Dat duurt zo nog even voor alles in cache zit.

Een andere optie is pagina's client side renderen.

[keejoz]

Ik volg je redenering niet helemaal. Ze vragen het nu toch ook elke keer op? Lijkt me dat alles na de eerste crawler toch in de cache moet zitetn?

[DeRinus]

Het gaat met 6 miljoen request per dag. Het aantal pagina's in cache zal afhankelijk zijn van een ingesteld cache size waarbij de laatste verdwijnt wanneer deze het limiet bereikt. Wellicht kun je van elke 2 commits een diff pagina genereren.

[SPee]

Waarom zou je willen dat scrapers hun pagina's snel krijgen? Dan krijg je alleen maar meer verkeer te verwerken. Bouw er maar meer vertraging in.

[syl765]

Dat is dus een beetje het probleem. Het is een google chrome versie x.y.z van ipadres 1.2.3.4. En die komt maar één keer voorbij. Het volgende request is waarschijnlijk van een ander Ipadres en een andere User Agent. Het AI bot verkeer word steeds lastiger te onderscheiden van normaal verkeer. Dus vertragen is erg lastig zonder ook de normale bezoekers te vertragen. En geloof mij, de normale bezoekers hebben geen geduld.

Dus alles cachen is weldegelijk een oplossing. Echter zodadelijk willen ze ook de diffs zien tussen commit x en y. Dat valt niet meer te cachen.

Het word een groot probleem. AI poisoning is ook wat je steeds meer ziet. Maar je wil niet een normale gebruiker onzin laten zien. Je moet dus heel goed weten dat je te maken hebt met een AI bot of niet.

@work hebben wij ook servers die soms een load hebben van boven de 100 omdat er weer een AI bot langs komt. En dan zie je bijna geen IP adressen die eruit springen. Ook de User Agent is gewoon een google chrome versie of een andere normale browser versie.


Prettige wedstrijd.

[Reactie gewijzigd door syl765 op 31 augustus 2026 23:37]

[Nas T]

Is er geen manier om ze te voeden met nepdata? Wat mij betreft vraag je de eigenaar van de gegevens altijd vooraf of je het mag gebruiken om AI te trainen. Daarom is nepdata zo mooi: laat er maar energie verbrand worden aan niks. Ik zou sowieso meer nepdata online delen, dat helpt de maatschappij.

[FreezeXJ]

Het vervelende is dat deze requests hetzelfde zijn als die een normale gebruiker zou doen, alleen de intensiteit is te hoog. Als deze crawlers gewoon netjes de robots.txt zouden lezen of tactisch zouden parsen dan was er geen issue.

Misschien wel een optie om ze bij dit soort requests op een fake-list te zetten zodat ze alleen maar rommel krijgen, maar da's wel foutgevoelig, en dan wordt het pas echt een veldslag.

[Jur_]

er zijn voor elke van de 1,4+ miljoen commits verschillende views en links: dus niet alleen de commit, maar ook dingen als git-patch etc. Ik weet niet of het handig is die allemaal te 'pre-baken'.

Die links worden 'dom' gevolgd door de crawler. Het probleem is dat kernel.org vooralsnog de functionaliteit van de website in stand wilde houden. De afnemers (crawler eigenaars) hadden ook gewoon de git repo kunnen clonen en dan hadden ze alle info in één keer gehad. Maar dat doen ze dus niet.

Het probleem is echter dat die aangepaste crawling niet te extrapoleren is naar alle interessante bronnen op het internet en is het dus zelfs makkelijker om anubis automatisch op te lossen als dat voorbij komt (waar overigens ook al slimme versnellingen voor zijn, om anubis op level 6 op te lossen).

Het is overigens niet dat de anubis-horde niks tegenhoud: zoals ik het begreep scheelt het (vooralsnog) nogsteeds 66% van de AI crawlers. Echter blijven er nieuwe modellen komen die getraind moeten worden en worden de crawlers zelf ook nog steeds verbeterd.

Zie voor alle bovenstaan en meer interessante discussie hieromtrent ook de thread op hackernews.

[Reactie gewijzigd door Jur_ op 31 augustus 2026 13:54]

[curkey]

Gewoon de content serveren van Rick Astley's grootste hit.

[laurxp]

En hoe will je dat doen voor bijvoorbeeld een diff endpoint? Er is een praktisch oneindig aantal pagina's, dus alles van tevoren berekenen is onmogelijk.

[Keypunchie]

Ik bedoel rate limiter op de gewone website (wat weinig invloed op mensen zou moeten hebben).

(overigens kan ik nu zelfs niet eens een standaard robots.txt vinden, maar misschien kijk ik op de verkeerde plek).

[Reactie gewijzigd door Keypunchie op 31 augustus 2026 13:03]

[RobertMe]

(overigens kan ik nu zelfs niet eens een standaard robots.txt vinden, maar misschien kijk ik op de verkeerde plek).

https://git.kernel.org/robots.txt

[thomasv]

En hiermee is al vrij duidelijk dat de eerdere gentlemen's agreement met voeten getreden wordt door crawlers, dus een speciale AI api via llms.txt gaat weinig opleveren dunkt mij.

[dasiro]

Verbaast dat je? scrapers zijn notoir in alles wat ze kunnen vinden te willen hebben, die gaan zich niet laten tegenhouden door een "1 snoepje nemen"-bordje als er een hele schaal staat.

[thomasv]

Nee het is vooral extra duidend, niet schokkend noch verbazingwekkend.

[graey]

Nouja, als je in llms.txt instrueert hoe er optimaal gebruik gemaakt kan worden (access the repo locally, and/or do partial checkouts), en de normale API zo rate limit dat hij voor menselijk gebruik afdoende moet zijn, krijgt een AI agent snel genoeg een 429, waarna hij via llms.txt ontdekt hoe hij deze kan omzeilen. Dat kan een prima oplossing zijn. Scheelt precies al deze html rendering, zelfs als de agents nog steeds allemaal losse stukjes van de repo opvragen.

[Keypunchie]

Check, thx! Dacht al, dit kan niet kloppen..

[Steven Klink]

A gentleman doesn't exit (anymore) in tech.

[Wim Cossement]

Ze gerust maar in gans het economisch systeem.
Andere bedrijven doen ook hun uiterste best om ons zo hard mogelijk te naaien, ze willen je poen, je gezondheid en je data en geven er liefst niets voor terug om toch maar dat beetje meer winst te maken voor de aandeelhouders.
In wat voor klotewereld zijn we eigenlijk aanbeland?

[Steven Klink]

Ja; de laatste zin is het probleem. De mens is inhalerig; mijn medische data boeit me geen zak, dat ze je er op veroordelen betekent dat ze commercieel te goed waren en ik de beste heb laten lopen...

[Wim Cossement]

Ik hoop echt dat de VS op dat vlak ontploft en er een klasserevolutie komt van de lagere en lagere middenklasse, want die worden daar nu uitgeperst als citroenen, terwijl de bedrijven monsterwinsten maken en de (super)rijken slapend rijker worden, maar er is geen geld voor loonsverhoging, blijven ze maar zeggen. Tijd om wakker te worden van de Amercian dream.
Hopelijk volgt de rest van de wereld dan, en hier hebben we wel nog wat marge, maar het socialisme moet er voor het geld ook aan geloven.

In Alabama (niet toevallig denk ik dan) heeft men de bevolking zelfs zo ver gekregen dat ze tegen een hoger minimumloon hebben gestemd! Ik kon het maar niet geloven, edoch…

[Reactie gewijzigd door Wim Cossement op 31 augustus 2026 15:19]

[Dreamvoid]

Je kan op zich een prijskaartje hangen aan scrapen en dat melden in robots.txt. Log de scrapers en stuur ze een rekening, en aanklagen als ze niet betalen. Je kan met geen mogelijkheid beweren als scraper dat je niet wist dat scrapen geld kost als het overduidelijk en vooraf vermeld wordt. Natuurlijk, je gaat nooit geld krijgen van de scrapers van Rusland ofzo (maar wat doen die op kernel.org) maar de commerciele AI bedrijven zijn gewoon bereikbaar.

[Reactie gewijzigd door Dreamvoid op 31 augustus 2026 14:37]

[field33P]

Die commerciële AI-partijen hebben van Uber het trucje afgekeken. Het enige wat ze nodig hebben is een grote bak geld van durfinvesteerders om een slepende rechtszaak langer uit te kunnen zingen dan de tegenpartij.

[Steven Klink]

David tegen Goliath; dat ga je niet winnen. Geloof me maar.

[stresstak]

David won overigens wel degelijk.

[Steven Klink]

Maar niet op die manier Beetje achterhaald.

[laurxp]

En hoe ben je van plan om er achter te komen welke requests van de grote Westerse AI-bedrijven komen? De scrapers spoofen immers allang hun User Agent header, en de requests lopen meestal via een residential proxy. Ze zijn amper van echte requests te onderscheiden, laat staan van elkaar. Een request tracen naar een specifiek bedrijf is onbegonnen werk.

[Bedge85]

Een probleem is eigenlijk dat deze scrapers gewoon heel dom te werk gaan, want als ze echt efficient (en slim) te werken willen gaan kunnen ze gewoon de git repository clonen en daarop trainen.

Voor de oplossing die jij aanbied ga je er een beetje vanuit dat deze content scrapers zich netjes aan de regels in een llms.txt gaan houden. De groten in de industrie, zoals OpenAI en Antropic, zullen dit wel doen. Maar veel andere A.I cowboys gaan zich denk ik niet aan de instructies in een txt bestandje houden.

[Keypunchie]

Als de groten het doen, zal dat al flink schelen is mijn gedachte.

[Reactie gewijzigd door Keypunchie op 31 augustus 2026 13:27]

[lenwar]

Je maakt nu de aanname dat het om trainen gaat.

Een LLM wil ook recente data kunnen verwerken.
Vraag aan een LLM om het laatste nieuws, en je krijgt het nieuws van 'nu'. Het ding zal 'live' naar nos.nl, cnn.nl, enz. gaan, aggregeren en iets voor je smurfen.

Als de LLMs hebben bedacht dat ze zinvolle voorbeelden van code kunnen vinden bij kernel.org als iemand vraagt om code uit te persen, dan zal het daar data ophalen.

[Bedge85]

So, you'd think that something that pretends to be “Artificial Intelligence” would use the most efficient way of using our data for training purposes, right? Clone the repos, walk every commit. Done.

But no, let's in fact choose the stupidest possible way of doing it — by rendering everything as HTML commit by commit and then parsing it.

Bovenstaande quote komt uit de blog post. De blog post gaat dan ook voornamelijk over de belasting die het scrape van de code voor training veroorzaakt. En ook dat dit komt doordat deze scrapers inefficiënt te werk gaan.

De belasting van door A.I. gegenereerde zoekresultaten om vragen in chats te beantwoorden zal er vermoedelijk ook zijn. Het is alleen niet iets dat in de blog post benoemd wordt.

[Keyb]

Misschien moet je het bron artikel eerst eens lezen?

[Keypunchie]

Ik lees dat ze manieren hebben geprobeerd om het te blokken. Mijn voorstel is om te kijken of je het niet kunt mitigeren door het naar een minder intensief proces te leiden.

Beetje aggresieve reactie, overigens, waarom?

[killercow]

Wellicht is het aan de scrapers om zich niet zo te misdragen?
Ze kunnen letterlijk een git clone doen en alle relevante changes in 1 keer downloaden, maar besluiten er miljoenen http requests aan te besteden.

[MneoreJ]

Het zal hier ongetwijfeld om scrapers gaan die geen benul hebben dat ze specifiek kernel.org lastig aan het vallen zijn en dat dit ook beter kan. Het is gewoon een grote internet stofzuiger om maar data in een model te kunnen pompen. Eerst maar eens alles downloaden, eventueel filteren en beoordelen komt later pas. En dat dan maal X want iedereen is natuurlijk speciaal en bezig met het volgende nieuwe model te bouwen dat alle anderen gaat verslaan en waar het grote geld naartoe moet, dus we moeten onze eigen dataset hebben (en up to date houden).

[Reactie gewijzigd door MneoreJ op 31 augustus 2026 13:30]

[kuurtjes]

Beetje aggresieve reactie, overigens, waarom?

Ik denk dat jou comment nogal overkomt alsof scrapers maar het recht moeten hebben om te scrapen.

Als iemand je 20% van de tijd komt lastig vallen en je dat niet leuk vind moet jij je daar dan aan gaan aanpassen en proberen samen te werken

[jpsch]

Als het je baas is....

[- peter -]

Ja maar dat is t niet he? T zijn ongevraagde gasten.

[Saffie01]

Ook mijn "baas" zou ik beleefd doch zeer dringend verzoeken mij met rust te laten of 20% salaris te verhogen !

[Keyb]

Nou volgens mij leggen ze goed uit dat de manier waarop het gedaan is, ook echt de meest inefficiënte mogelijk is. Alle commits als html laten renderen op die server ipv gewoon een clone te doen en dan met git de commit messages te verwerken. Kortaf misschien, niet agressief bedoeld verder. Inhoudelijk wel geïrriteerd dat die ai tokos scrapen ipv netjes git te gebruiken. Scousez moi.

[leuk_he]

Als de reactie op ip blocks al proxy netwerken zijn, heeft een rate limiter ook maar beperkt nut. Dan wordt de load dus over veel ip netwerken verdeeld, en heb je uiteindelijk nog niks bereikt.

[SaraNostra]

Is er niet zoiets als een robots.txt voor AI tegenwoordig?

[RobertMe]

robots.txt is een gentlemens agreeement. Als je "goed wilt zijn" lees je de robots.txt en gebruik ke de info daaruit.

Als de inhoud van de robots.txt je tegenwerkt negeer je hem gewoon. Of je bouwt in je bot niet eens ondersteuning er voor in.

En hetzelfde hier dus, zoals ook in het artikel staat. Eerst komen ze vanaf IPs die makkelijk te blokkeren zijn. Vervolgens stappen ze over op residentiële IPs (dankjewel gebruikers van goedkope Chinese IPTV kastjes, vrijwel alle zit een proxy ingebakken waardoor anderen via jouw IP het internet op kunnen). Vervolgens is dus "Proof of Work" toegevoegd (middels Anubis), en ook die "challenges" lossen ze intussen op.

Het mag dus duidelijk zijn dat de ontwikkelaars van deze scrapers geen enkele intentie hebben om zich te houden aan een robots.txt of soortgelijks. Waarbij het mij ook niks zou verbazen als bv een Google search crawler zich netjes aan de robot.txt houdt maar een scraper voor Google Gemini niet.

Edit: kan helaas dat artikel dat ik tijdje terug las over hoe die Chinese IPTV spelers als residentiële proxy en voor het clicken op ads worden ingezet niet meer vinden. Kwam er on ieder geval op neer dat als die "uit" stond als een malle op specifieke websites op ads klikte (allemaal ads uit hetzelfde netwerk), en werd aangestuurd via een command server. En als de speler in gebruik was (en die niet zoveel CPU cycles kon verbranden zonder merkbaar traag te worden) deed die als proxy dienst. Dus als een VPN server dat iemand allemaal verkeer naar jouw speler stuurt en vervolgens vanaf daar het internet op gaat. Dus de website die het "doelwit" is ziet jouw IP adres. En zeg een kernel.org zal niet ineens "alle IPs van KPN gaan blokkeren" omdat er vanaf meerdere IPs aan AI scraping wordt gedaan.
V.w.b. dat proxy verhaal zijn er wel vele artikelen te vinden hoe dit werkt / dat dit gedaan wordt.

[Reactie gewijzigd door RobertMe op 31 augustus 2026 13:19]

[kuurtjes]

Vervolgens is dus "Proof of Work" toegevoegd (middels Anubis), en ook die "challenges" lossen ze intussen op.

Ik had gelezen dat de grote jongens die challenges ondertussen al op de proxy machine doen om daar zelf geen CPU cycles aan te verspillen.

[laurxp]

Je hoeft je TV-kastje écht niet uit China te halen, hoor. Ook merken als LG en Samsung laten je TV misbruiken als proxy - die komen gewoon mee met alle leuke smart tv apps die je installeert.

[IskaRiot]

ja, maar dat houdt ook in dat de scraper zich hier aan wil houden. Geen enkele manier om dat hard af te dwingen. Zelfde voor crawlers, google zal dat respecteren, een bot die exploits zoekt niet. Het negeren ervan heeft geen enkele consequentie voor de scraper.

[xilanaz]

In het bron artikel:

cgit is happy to let you, which was perfect for the times when the Internet was for humans or crawlers who obeyed robots.txt, and is AWFUL right about now, because we can generate 1.2 METRIC BAJILLION valid URLs just for a single fork of linux.git.

[Keypunchie]

Yup. https://llmstxt.org/

[pascalcartigny]

Helaas doet een llms.txt echt nog heel, maar dan ook heel erg weinig tot niets. Een LLM gaat niet specifiek op zoek naar dat bestand. Het doet net zoveel als een cats.txt of tweakers.txt. Ik heb nog geen aantoonbaar bewijs gezien dat dit werkt, sterker nog, als je de requests in de gaten gaat houden zul je weinig AI/LLM's tegenkomen die 'm oproepen. Wij noemen het op dit moment zelfs placebo.txt, met name bedoelt om je baas vrolijk te maken en te kunnen zeggen dat je iets gedaan hebt voor LLM visibility. Maar meer dan dat is het niet. Effectief resultaat op een klantenbestand van grofweg 80 klanten is nul, nihil. Vooralsnog. Niemand weet waar het natuurlijk heen gaat, hele discipline is nog pril maar op dit moment is het niet meer dan een utopisch gedachtegoed.

[Blokker_1999]

En zo helpt AI het eens zo vrije internet stilaan helemaal om zeep. De honger naar data is zo groot dat niemand ontzien wordt en alles maar gehamerd moet worden totdat men de functionaliteit begint uit te schakelen. Tegengaan is moeilijk, want de AI is vaak inventiever in het omzeilen van de tegenmaatregelen dan dat jij ze zelf kunt nemen en implementeren.

En terwijl AI heel het internet de dieperik in trekt, doen ze wel heel de tijd moeilijk als jij je eens niet aan de regels bij hen houdt. Zij mogen alles en wij hebben het maar te slikken.

[MrCoolion]

Data toegang voor AI moet gewoon eerlijk beprijsd worden. Dan stoppen 't vanzelf wanneer je ziet dat elke prompt $5 kost. Hele AI infra structure draait nu op geleend geld (beurs-hype) en niemand die nog weet of alle investeringen zich ooit zou terugbetalen.

[roelboel]

Hoe?

[MrCoolion]

Gewoon download door AI/bot doorbelasten met X centjes per KB. Niks is gratis meer tegenwoordig.

[laurxp]

Oké, maar hoe? Welk mechanisme wil je gebruiken om een AI/bot request te onderscheiden van een request van een mens, en hoe wil je hun daarvoor laten betalen?

[MrCoolion]

Dat kun je mooi aan AI vragen , zie query

[SPee]

Misschien door te controleren of bepaalde HTTP headers meekomen, die jij in jouw frontend mbv JS zet. Zonder dat, krijg je de gewenste content niet. Dan moeten ze iig jouw frontend draaien. Daar kan je indien nodig een vertraging inbouwen.

[mekkieboek]

Is het niet laaghangend fruit oogsten en daarvoor zo min mogelijk moeite doen? Je zou zeggen, doe een git clone dan heb je alles en schrijf dan (desnoods met een LLM) een scraper die lokaal de opgehaalde git data kan bevragen. Als je het slim doet kun je die scraper gratis hergebruiken voor alle andere git repo's in de wereld.

Dit komt op mij over als stompzinnig en lui, met nul moeite toch andermans data willen opslurpen.

[elmuerte]

Ik betwijfel ten zeerste dat een LLM betrokken is bij het scrapen. Een LLM is er veel te traag voor. Dit zijn gewoon tools die een headless chrome starten om een HTML op te halen, en vervolgens in die HTML alle links extracten en aan de database toevoegen. De links worden zeer waarschijnlijk niet eens genormaliseerd waardoor `index.html?a=1&b=2` en `index.html?b=2&a=1` beide in de database komen.

[Erwin1985]

Bizar dat scrapers dit zo doen. Iedereen kan de git repo gewoon klonen en dan lokaal je ding doen. Scheelt je vrij veel tokens.

[Blokker_1999]

Maar nu verplaats je die CPU cycles dus naar de infra van kernel.org in plaats van dat je die lokaal moet doen. En als je tienduizenden repos scraped, begint dat op te tellen natuurlijk.

[swtimmer]

Maar je hebt nu heel veel ingress/egress kosten. Zeker als heel veel van de content die je binnenhaalt redundant is.

[kaas-schaaf]

De grote jongens zitten aan de kant waar ingress/egress geen variabele kostenpost is.

[swtimmer]

Maar IO en snelheden van ingress/egress wel. Ik vraag me echt af of die CPU kosten besparing op kan tegen het veel sneller leren/scannen direct van een lokale git clone.

[baseoa]

Oh?

[baseoa]

Nee, het is veel efficiënter om zelf de info met de standaard git client uit een lokale repository te halen dan om te proberen uit de gegzipte html-variant via het netwerk diezelfde info te slurpen

[pjottum]

Jamaar die scrapers, die hebben die data nodig om te verkopen als .. tokens.

[Noxious]

Je zou denken dat je hier goed een cache voor kan inzetten, of oude data naar statische html renderen.

[Bedge85]

Cache gebruik je om bepaalde veelgevraagde content snel te kunnen leveren. Wanneer je je complete website in cache kun je eigenlijk niet meer van cache spreken. Waar jij misschien op doelt is pre-rendering waarbij je in dit geval vooraf de gehele git database al omzet naar statische HTML.

[Noxious]

Je kan ook prima een meer statische cache hebben en dat is in dit soort gevallen ook niet ongewoon.

Bij de eerste keer opvragen renderen naar html, en die opslaan.

Een aanpassing die effect heeft op die pagina invalidate de cache en gooit de html weg.

[RobertMe]

Git heeft geen aanpassingen die effect hebben op een pagina, dat is nu juist een beetje het hele probleem. Met 1,48 miljoen commits kan het zomaar zijn dat een specifiek bestand via 1000+ verschillende commit hashes identiek is. Maar dat zijn dus wel 1000+ semi identieke pagina's (op die pagina zal vast ergens de commit hash staan, maar v.w.b. de (HTML) weergave van het bestand gewoon 100% identiek.

Voordeel is wel dat git intern met hashes van elke "blob" werkt. Cgit zou dus kunnen herkennen dat commit A en commit B met bestand C.txt verwijzen naar dezelfde blob (hash) en vervolgens die blob eenmalig renderen en het "frame" er omheen is dan wel nog grotendeels dynamisch. Maar elke versie, of eigenlijk unieke inhoud, van een bestand (onafhankelijk van locatie) heeft in git zelf al een unieke identifier die als cache key te gebruiken is. Maar dan nog gaat het én om heel veel echt unieke pagina's waarbij je toch weer telkens een ander "frame" er omheen hebt en óm verschillende weergaven van hetzelfde bestand (raw vs HTML vs ...), etc. Én last but not least, 1,48 miljoen commits * een shitload aan bestanden levert nog steeds miljoenen en miljoenen unieke bestanden op. Want 10 commits die elk 10 bestanden aanpassen zijn ook al 100 unieke HTML weergaves (/cache entries), vervolgens nog raw vs HTML is al 200, en extrapoleer dat maar naar 1,48 miljoen commits.

[kaas-schaaf]

Dat is het probleem verschuiven. Kernel.org ziet dit niet als legitieme access, vooral als misbruik (want daar is de clone functionaliteit voor). Dit is vooral het crawler probleem aankaarten waarbij er in feite amplification attacks voorkomen doordat de crawlers extreem "dom" zijn en vooral maximaal tokens will kauwen.

[jeroen3]

Dat lijkt mij ook, vooral omdat die commits by-design, niet veranderen.
Dus zodra die pagina een keer is gevraagd hij dan ergens wordt bewaard.

[baseoa]

Vroeg ik me ook af. De data sla je toch al op. Precompile een zstd dictionary en de data zal on-disk nauwelijks groter zijn dan het origineel wanneer je enkel template strings rond de data plaatst (zoals bij "Commit ID: <span class=hash>{commithash}</span>" kan alles behalve de data zelf zo'n 6 bits lang zijn)

Edit: niet dat het zou moeten hoeven natuurlijk. Idealiter stuur je een geautomatiseerde e-mail naar het voor dat IP-adres geregistreerde abuse-adres en wordt de internet-imploderende klant van het internet gegooid, en als ze provider lak heeft, mag de provider een nieuwe upstream zoeken tot ze misschien geen lak meer hebben. Maar als tussenoplossing...

[Reactie gewijzigd door baseoa op 31 augustus 2026 22:42]

[MneoreJ]

Het is een lastige idd. Dit is een "this is why we can't have nice things". Een centrale service om de commit te renderen is niet nodig (je kunt het doen met een lokale clone, en zou het moeten doen met een lokale clone als je regelmatig commits ophaalt) maar even snel kunnen kijken wat er in commit X gebeurd is zonder dat je een lokale up to date clone van de repo hebt is wel handig als je zelf geen full time kernel dev bent. Maar dan krijg je dit soort hersenloze scrapers en dan schaalt dat allemaal niet meer. Gigantische barrières opwerpen werkt ook niet, want dan kunnen mensen er ook niet meer bij. Rate limiting en error messages met instructies voor wat je wel zou moeten doen is effectief voor agents, maar niet voor scrapers.

[rbnlgrw]

Ergens wel interessant om te zien dat hebberige, onhoudbare exploitatie van publiek eigendom (water, fossiele grondstoffen, oerwoud kappen voor plantages) nu zo ver is doorgeslagen dat zelfs websites zoals kernel.org en wikipedia zonder pardon omver worden getrokken.

Zoals het aloude gezegde gaat:
"This is why we can't have nice things"

[magnifor]

Op werk hebben we ook te maken met een AI-scrapers die gewoon websites onbereikbaar maken omdat bij elke request die ze maken de connecties naar de database volloopt. We hebben sinds een aantal maanden Anubis geïmplementeerd en doet tot nu toe wonderen, normale bezoeker krijgt een challenge in de browser die automatisch wordt opgelost en bots blijven in dat proces hangen waardoor de daadwerkelijke website niet bereikt wordt.

[kodak]

scrapers stapten over op residentiële en mobiele proxynetwerken

De scrapers wisten zich daar ook op aan te passen en een deel lost inmiddels ook moeilijkere uitdagingen op.

Het zijn systemen die handelen binnen gebrekkige implentaties door de keuzes van de personen die voor de ai bedrijven werken. Die personen maken de keuzes tot gebruik van dat soort netwerken en om belemmeringen heen te werken, niet de scrapers. Die personen doen dat omdat ze massaal zowel hun eigen belang (vaak geld verdienen, doen wat ze zelf leuk vinden, baanbehouden) voorop stellen én daarbij kiezen dat anderen daarvoor zwaar benadelen maar prima is. Iedere suggestie alsof scrapers iets zelf doen doet geen recht aan het probleem dat anderen last ondervinden.

Het probleem is niet dat residential proxies gebruikt worden, het probleem is dat de mensen die de scrapers ontwikkelen dat laten gebruiken. Het probleem is niet dat een scraper wist te werken, het probleem is dat de mensen die het ontwikkelen maling hebben waarom belemmeringen bestaan.

Scrapers zijn geen probleem, het zijn net als andere systemen middelen gemaakt en in gebruik door mensen. Het probleem is dat die mensen bij het maken en gebruik hun eigen belangen hoger stellen dan die van anderen én daarbij kiezen dat anderen daarvoor zwaar benadelen maar prima is. Zolang ze er persoonlijk maar niet te veel last van hebben. Kernel.org heeft geen last van keuzes of werk van scrapers maar van al die mensen die maling hebben aan andermans belangen en rechten.

[Reactie gewijzigd door kodak op 31 augustus 2026 14:40]

[Madelijn]

- Het probleem is het aantal verzoeken - zet daar dus een limiet op. Natuurlijk kan een scraper een miljoen accounts aanmaken, dus een volmaakte oplossing is het niet, maar het zal helpen. Kijk eventueel naar het gedrag van zo'n account, of het alleen maar opvraagt.

- Het werk is het naar HTML omzetten - verschuif dat dus naar de cliënt. Het opvragen kan via een programma of webpagina; de server stuurt de kale gegevens, en de ontvanger masseert dat tot behoorlijke HTML. Wie af en toe wat opvraagt heeft daar geen last van, maar de scrapers mogen zich dan te pletter rekenen - of slim genoeg worden die kale gegevens te gebruiken, wat natuurlijk veel zinvoller is.