grg0

"The lies are lies" being a true proposition is too meta for the average human brain.

And how does Rust help? As far as I know, an integer overflow in Rust panics in debug but just wraps in release (a bad choice in my opinion). Would it help specifically in the code execution part of the exploit?

It is not obsolete insofar as it is a good source of Q/A material, which is useful to both humans (directly or indirectly) and bots. The only part of it that is obsolete is the search/query part. If the AI companies had an ounce of decency, they would see no problem injecting money into the platform to continue seeding that Q/A material which they have directly profited from. But investing in a commons is not on the playbook for vulture capitalism.

Thanks for pointing that out, it does explain many things. It's tiring to read about languages and projects like they are some hot shit that makes everything before it obsolete when in reality it's just a different set of trade-offs. We should approach discussions more objectively like your comment does and less like a marketing slide.

Not to take away from your point, but client_max_body_size "Sets the maximum allowed size of the client request body." That is different from how much the server/service is allowed to allocate internally to service the request.

Interesting, thanks for elaborating.

The problem is not finding limits, although that does take decent engineering for anything non-trivial. The problem is that a hard limit assumes your requests have a relatively uniform distribution of memory requirements. Otherwise, you are wasting memory. Or you have N limits instead, which just complicates the problem.

Resize: realloc invalidates pointers. If you're saying allocate more chunks and link them, that is technically no longer an arena?

Requesting virtual memory and committing lazily seems a good trade-off except on Windows, which does not allow to over-commit. Somehow I don't find that very satisfying because it relies on the OS and on the hardware to provide virtual memory support. But maybe it's just what it is.

As opposed to allocating a bunch of memory you won't need?

Allocating virtual memory up front and committing lazily might be a good trade-off, until it isn't. So I'm not actually sure and hence why I asked the question.

> Now all of your allocations during that connection are guaranteed to be freed instead of having to keep track of them individually

And how do you size the arena?

> keep track of them individually

I think this is an exaggeration of the problem. This is what RAII semantics in C++ are for.

> avoiding that kind of invisible code

The invisible code is traded for defer statements right after initialization that are obvious and therefore mostly just noise, and also a problem if you forget to call them. This isn't an issue with RAII. I get the point of not wanting invisible code, but defers don't seem much of an improvement either. A trade-off at best.

The truth is really a middle ground and the fact that you won't get the design right the first time around until you have built that hardware programming experience and learned from past mistakes. But this statement doesn't make for a good marketing stunt.

> This continues with enough request bursts on our testing until the process runs out of memory

Curious, how much memory and how many requests does that take to exhaust?

The US voting system is probably not a good starting point for modeling such systems :)

I actually like the web design, so colourful. Beats any mainstream site riddled with ads.

Unfortunately, there are no hot singles in my fusion reactor.

Which is not to say that they are necessarily auto-vectorizing. You know wassup when you see vaddsd instead of vaddpd. And ideally you'd use AVX-512 to saturate a modern cache line if you can afford to drop support for the older devices.

The scams do leave voicemails now, and they use voice genAI per the parent comment.

If someone really wants to get a hold of you, they can knock on your door.