Top
Best
New

Posted by zdw 1 day ago

Creepy Crawlies(people.kernel.org)
1279 points | 636 commentspage 14
oowa 16 hours ago|
TLDR basically old tech is not optimized for scrapers / slurpers / etc. to the point it would take 42^n to solve all possible combinations. Why? Murphy's law. Solution for OP is to ignore for now. Otherwise Use or invent something else. Easy enough. other notes... Anubis and other gatekeepers dont work perfectly, but ok for now.
calvinmorrison 19 hours ago||
I love to see the 'leet kernel hackers and maintainers' struggling with basic volume. Each page load should cost you near nil. Us lowly PHP developers have been caching shit for close to twenty years.

Learn how to cache your application and your cpu usage should be almost zero. In fact basically any read should cost nothing in comparison to writes.

riknos314 18 hours ago||
The amount of memory required to cache all possible diffs (defined as an ordered pair of commits) would likely be in the exobytes. At current ram prices that's easily a trillion dollars of ram to run that cache lol. Git focuses on making diff calculations efficient largely because the space of possible diffs is very expensive to enumerate.

The following from Claude: """ A diff between two randomly chosen commits usually spans years of history, so it's not a few KB — the tree itself is ~1.5 GB of text, and a multi-year span rewrites a large slice of it. Call it 100–200 MB per pair on average: 8.5×10¹¹ pairs × ~2×10⁸ bytes ≈ 10²⁰ bytes, or ~150 exabytes """

riknos314 18 hours ago|||
I'm not sure if the website allows for diffs against arbitrary tree states, but if it does than the diff space is completely unbounded, and the ram demand is theoretically infinite.
calvinmorrison 17 hours ago|||
cache all of them? no... but you could cache some of them, likely the newer are accessed more frequently.
desterothx 2 hours ago|||
Yes, and it still wouldnt help you since they are trying to fetch everything for each of the 921 forks, as stated in the article (same commits need to be cached again on a forked branch)
zbentley 12 hours ago|||
Per the article, the vast majority of traffic is scrapers that are generating effectively random, permuted URLs. Even if they're already caching their popular-with-real-humans most recent data, that efficiency gain is a tiny drop in a very large bucket.
inigyou 19 hours ago||
It's running a diff between two arbitrary blobs of text. Do you actually have a solution or are you just saying to remove the feature from the site entirely?

> Us PHP developers

I can tell.

calvinmorrison 18 hours ago||
it's not an insult. yes. cache heavily. shitty php stacks serving trillions of dollars of ecommerce sales have managed to do it for a long time.
inigyou 9 hours ago|||
Can you explain how a cache lets you avoid serving a request for the first time?
zbentley 12 hours ago|||
Those ecommerce stacks serve a large fixed number of pages. cgit does not.

Imagine if WooCommerce had a route "/product/<sku1>/compare/<sku2>" which displayed an auto-generated comparison between any two product pages.

Now imagine running a million-SKU WooCommerce site, where each product page was 100kb of text.

Now imagine scrapers are permuting those URLs.

How would you cache that?

That's what cgit/kernel.org and many other Git forges are dealing with. These aren't static websites, even if the underlying Git repo is largely static; they're rendering arbitrary diffs and other generated-on-the-fly views into Git history. The ability to do that is a large part of the value of a Git UI.

petesergeant 23 hours ago||
> Training an LLM on content produced by the LLM gives it the equivalent of a digital prion disease

Is it foolish of me to have expected more from a blog post on kernel.org?

theandrewbailey 23 hours ago|
Are you trying to say that's bad writing? I think it's a good metaphor for a documented phenomenon: https://en.wikipedia.org/wiki/Model_collapse
Lerc 22 hours ago|||
As the article states, this phenomenon may be documented, but there is no consensus that it describes any practical reality.

The predicted consequences have now had time to manifest, and have not done so. This makes the claim either false or overstated. Perhaps there will be issues in the future, but to date there have been many claims that AI development will stall (for a variety of reasons). If they were the critical weaknesses they have been portrayed as, models would not have advanced to the level they are today.

If you have a hypothesis, make a clear prediction based upon it. If you start pushing the date forward after each failed prediction, you end up looking like a hapless doomsday cult. If your hypothesis is correct however, your prediction should actually happen. Then provided you have not made so many predictions to get one right by chance, people will take what you have to say seriously.

desterothx 1 hour ago||
You state it as if its only the quality of the hypothesis that matters, but you are ignoring an important part of it, timing. During the 08 financial crisis Burry had a hypothesis that was correct, however he almost went bankrupt still because he thought it would happen earlier than it did because of the government bailouts. He was pushing the day forward, and was looking like a "hapless doomsday cult". His hypothesis still turned out correct
petesergeant 17 hours ago|||
Training on large quantities of LLM-generated synthetic data is an important part of training LLMs.
charcircuit 11 hours ago||
How about making cgit more efficient at serving these pages. There's no excuse for burning a ton of CPU power on purely static pages when you have generous resources available to you.
userbinator 19 hours ago||
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?

I'm strongly convinced that these aren't "AI crawlers"; they're just plain DDoSes done by those who have interests in turning the Internet into a dystopian walled garden with "security", and now they have a convenient scapegoat to blame. Don't you find it too coincidental with the rise in identity/age verification and other attempts at silencing free speech on the Internet?

It's widely known there are questions that LLMs can't solve, and once in a while an obvious example appears, so a simple CAPTCHA-like challenge with an HTML-only form would be the logical "defense". Instead there's a huge interest in pushing JS-required proof-of-work (as others have pointed out, these attackers have far more compute than the average user) and remote attestation (there are already providers with huge farms of mobile devices that can defeat this easily).

Things just don't add up.

desterothx 1 hour ago|
The questions the LLMs can't solve puts you in a cat and mouse game. They sure can solve most of those with the correct tooling, and i would argue its easier to create this tooling than it is to keep innovating with new questions LLMs cannot answer
leoqa 22 hours ago||
It seems clear to me we are moving towards a world where you will have to perform device attestation to access the internet. The spam/abuse is too great and accelerating.
okanat 20 hours ago|
What prevents people from obtaining or buying such devices and automating them? Using TVs as proxies is just one example of that. People will be willing to give their ID cards away too, if you pay them or beat them enough.
inigyou 19 hours ago||
In fact they already do this. Buying 100 android phones and chargers is cheaper than reverse engineering whatever you're trying to automate - or was, before AI.
leoqa 16 hours ago||
.. and we ban those device ids and move on. Your capital is lost.
inigyou 9 hours ago||
Evidence shows otherwise. There are people making lots of money from these device farms. Right now. This isn't hypothetical.
andruby 22 hours ago||
A creepy crawly is a South African invention to clean your swimming pool. The company that introduced them in the 70ies is called Kreepy Krauly. Also popular in Australia.

https://kreepykrauly.co.za/about-us/

Symbiote 20 hours ago|
It's a childish word for an insect.
adangert 14 hours ago||
Curious, if serving bots (and traffic) is the main concern here, why is a distributed git solution like radicle not considered?

https://radicle.dev/

znnajdla 23 hours ago|
Put a CDN in front and let them absorb the load? Seriously, this is static content, which is so cheap to serve it should be free.
ninglor 22 hours ago||
This is not meaningfully static content. Look at the charts in TFA. There is a combinatorial explosion of distinct URLs which the crawlers can and do request.
jopsen 22 hours ago|||
They allow you to diff commits, which is an awesome feature.

But if bots a crawling diffs between all possible commits it's crazy.

CDN will do nothing, because it's new urls each time. You can maybe find a CDN provider that block bots.

inigyou 19 hours ago||
No CDN blocks bots. Some claim to. None do.
grep_it 22 hours ago||
Did you read the article?

“[…]because we can generate 1.2 METRIC BAJILLION valid URLs just for a single fork of linux.git.”

jwilk 20 hours ago||
From the HN guidelines <https://news.ycombinator.com/newsguidelines.html>:

> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".

inigyou 19 hours ago||
What if it's really obvious they didn't read the article?
znnajdla 6 hours ago||
I did read the article. It just didn't occur to me that their combinatorial explosion of diffs was scrape-able. To be honest that sounds like an scrapers tarpit / honeypot now, because there is no value in scraping trillions of diffs. Sounds like the issue could be fixed by putting the diffs in a frontend app, not scrapable by URL, only by clicking around the app.