landhar
Joined 17 years ago
Joined 17 years ago
> Normally, when engineers try to make software faster, they work from the bottom up. They run a benchmark, look at a flamegraph, find a hotspot, and figure out how to speed up their code by 15% or 20%. The problem with working from the bottom up is that you don't know what the ceiling is. You might be 20% away from the fastest possible code the hardware can run, or you might be 100x away.
> When we started building Gravity, we flipped this question around. We asked ourselves: how fast can a database actually be? Instead of incrementally speeding up our existing query engine, we wanted to start from the physical speed limit of our hardware and file format and work backward. I like to call this “programming at light speed”.
What is described as the “normal” approach to optimizing code is really more the “naïve” approach. Any serious performance optimization work would follow the approach of defining first what’s the ceiling the hardware allows and benchmark against that. And that was already true before LLMs.See for example: https://www.marginalia.nu/log/a_106_native_calls/
Apologies for being nitpicky, but I felt it might be useful for other readers to contextualize that this part of the approach is not novel. Their use of Claude to generate those optimized benchmarks is interesting enough already, so I don’t feel that calling extra attention to this part in their write up is necessary.
I think this is disingenuous. One could say that drones are nowhere the efficiency limit either: a bee can fly for hours on the energy contained in just a few milligrams of honey, while our best battery-powered drones can't stay airborne for more than 30 minutes. But comparing energy efficiency of electric/mechanical devices to their biological counterparts is not an apples-to-apples comparison. There's a world of difference between the energy storage and delivery mechanisms.
And as many have pointed out already in the siblings, it's not just about the compute but the access to petabytes of training data.
Based on my own experience fighting these AI scrappers, I feel that the way they are actually implemented makes it that in practice there is asymmetry in the work scrappers have to do vs humans.
The pattern these scrappers follow is that they are highly distributed. I’ll see a given {ip, UA} pair make a request to /foo immediately followed by _hundreds_ of requests from completely different {ip, UA} pairs to all the links from that page (ie: /foo/a, /foo/b, /foo/c, etc..).
This is a big part of what makes these AI crawlers such a challenge for us admins. There isn’t a whole lot we can do to apply regular rate limiting techniques: the IPs are always changing and are no longer limited to corporate ASN (I’m now seeing IPs belonging to consumer ISPs and even cell phone companies), and the User Agents all look genuine. But when looking through the logs you can see the pattern that all these unrelated requests are actually working together to perform a BFS traversal of your site.
Given this pattern, I believe that’s what makes the Anubis approach actually work well in practice. For a given user, they will encounter the challenge once when accessing the site the first time, then they’ll be able to navigate through it without incurring any cost. While the AI scrappers would need to solve the challenge for every single one of their “nodes” (or whatever it is they would call their {ip, UA} pairs). From a site reliability perspective, I don’t even care if the crawlers manage to solve the challenge or not. That it manages to slow them down enough to rate limit them as a network is enough.
To be clear: I don’t disagree with you that the cost incurred by regular human users is still high. But I don’t think it’s fair to say that this is not a situation in which the cost to the adversary is not asymmetrical. It wouldn’t be if the AI crawlers hadn’t converged towards an implementation that behaves as a DDOS botnet.
Almost 13 years to the day!
I find it really frustrating that I am not able to avoid using whatsapp due to how popular it is to the point that it’s become the go-to communication channel for most things :/
Just wanted to call out that linkhut does have IFTTT integration [0]. Although you will need to pay for an IFTTT developer account if you want to enable that on your self hosted instance. If you need help setting that up let me know, I’ll be happy to walk you through the process (and that way I can write documentation on how to do it).
Edit: I also was under the impression that one could use the webhooks integration [1] to make bespoke integrations (as the documentation says they support passing arbitrary request headers) but haven’t tried it myself, have you tried it and run into any issues? I’d also be happy to help improving support for that workflow.
[1] https://help.ifttt.com/hc/en-us/articles/115010230347-Webhoo...
> The term "soap opera" originated from radio dramas originally being sponsored by soap manufacturers.
Long battery life is an understatement! Even when the battery drops to near 0 the watch is still useable as a plain analog watch for at least a week giving me enough time to find where I left the damn charger (given that I don’t get to use it often at all).
What I don’t get is how this model (analog watch with just enough smarts) hasn’t gained more traction. It seems to me there’s a lot of opportunities in this space, not everything requires a high resolution display.
For instance, with computers, laptops and cell phones being first and foremost business tools it was common in the early days for those to be provided by the employers. That really played a big role in normalizing their presence around the home before they became mainstream products.
I have a hard time seeing a similar thing happening with these goggles, but I’m far from being an expert in these things.
By the way, thanks for marginalia and the great write-ups on your blog.