maybe not great naming. Sounds very similar to the rapper D4vd, who was just arrested for murdering a 14 year old girl
Dav2d
101–110 of 199 posts
Re: Dav2d
#102maybe not great naming. Sounds very similar to the rapper D4vd, who was just arrested for murdering a 14 year old girl
Actually it's closer to https://youtube.com/@dave2d who is a popular tech YouTuber
Re: Dav2d
#103Re: Dav2d
#104Not on topic, but wow the internet has very quickly devolved into: click -> "making sure you're not a bot", click -> "making sure you're a human", click -> "COOKIES COOKIES COOKIES", click -> "cloudflare something something"
We had to set it up on the parts of VideoLAN infra so the service would remain usable. Otherwise it was under a constant DDoS by the AI bots.
[dead]
Re: Dav2d
#105AV2 video codec delivers 30% lower bitrate than AV1, final spec due in late 2025 (videocardz.com) | Oct 2025 | 277 points | 223 comments | https://news.ycombinator.com/item?id=45547537
Re: Dav2d
#106Earlier quoted context omitted.
That codecs should be written in safer languages given that they usually process untrusted files. There have been a number of serious hacks from file parsing bugs due to them being written in unsafe languages. There's literally a DSL designed for this purpose (Wuffs) so it would be interesting to hear why they didn't use it.
The people who write DSLs for video codec asm, or who claim that it's fine to use intrinsics or X higher-level language and it will still be fast enough to be usable, are simply wrong and have never been able to demonstrate otherwise. Having said that I do think you could write a DSL to generate safe performant asm for a video codec. Just not a platform-independent one. It would still have to be asm.
It sounds like your second statement contradicts your first. But also, WUFFS exists and it looks like the Google Chrome GIF decoder ships in it: https://github.com/google/wuffs
Re: Dav2d
#107Earlier quoted context omitted.
We had to set it up on the parts of VideoLAN infra so the service would remain usable. Otherwise it was under a constant DDoS by the AI bots.
Maybe I’m naive about this, but I didn’t expect AI scrapers to be that big of a load? I mean, it’s not that they need to scrape the same at 1000+ QPS, and even then I wouldn’t expect them to download all media and images either? What am I missing that explains the gap between this and “constant DDoS” of the site?
Yes, it's that BIG of a load: https://status.sr.ht/issues/2025-03-17-git.sr.ht-llms/
Re: Dav2d
#108Earlier quoted context omitted.
You cant really cache the dynamic content produced by the forges like Gitlab and, say, web forums like phpbb. So it means every request gets through the slow path. Media/JS is of course cached on the edge, so it's not an issue. Even when the amount of AI requests isnt that high - generally it's in hundreds per second tops for our services combined - that's still a load that causes issues for legitimate users/develope…
You kind of can though. You serve cached assets and then use JavaScript to modify it for the individual user. The specific user actions can't be cached, but the rest of it can.
Totally. Remember slashdot in the 1990s used to house a dynamic page on a handful of servers with horsepower dwarfed by a Nintendo Switch that had a user base capable of bringing major properties down.
Re: Dav2d
#109Earlier quoted context omitted.
What are you even implying?
It’s not Rust, therefore it’s bad. Or something. This is getting rather tedious.
I don’t think it’s unfounded. Media codecs have been one of the top sources for serious vulnerabilities. The code is incredibly complex, and takes complex input from untrusted sources.
Decoders are one of the best places for rust because they are both performance critical and security critical.
JPEG-XL couldn’t get off the ground until they recreated the decoder in Rust since none of the browsers wanted to touch it. And the apps that did utilise the C based libjxl ended up hit with vulnerabilities in it.
Re: Dav2d
#110Earlier quoted context omitted.
You cant really cache the dynamic content produced by the forges like Gitlab and, say, web forums like phpbb. So it means every request gets through the slow path. Media/JS is of course cached on the edge, so it's not an issue. Even when the amount of AI requests isnt that high - generally it's in hundreds per second tops for our services combined - that's still a load that causes issues for legitimate users/develope…
You kind of can though. You serve cached assets and then use JavaScript to modify it for the individual user. The specific user actions can't be cached, but the rest of it can.
The "can't" comes from the fact that VLC is not going to rewrite their forum software or software forge.
Software written in PHP is in most cases frankly still abysmally slow and inefficient. Wordpress runs like 70% of the web and you can really feel it from the 1500ms+ TFFB most sites have. PhpBB is not much better. Pathetic throughput at best and it has not gotten better in decades now.
I don't know how GitLab became so disgustingly slow. But yeah, I'm not surprised bots can easily bring it to its knees.