Comments URL: https://news.ycombinator.com/item?id=48522316

Points: 188

# Comments: 27

You can tell it just that. Happened to me too but after instructing it to leave the review to me Fable was useful for hours of frontend iterations without significant token usage.

...

handleClick({clientX: els.bar.getBoundingClientRect().left + els.bar.getBoundingClientRect().width / state.n * state.target })

Do you mean directly == raw shell access on your production server?

Following the logic their agents should be able to find and make money with niche businesses cheaper than human entrepreneurs.

https://web.archive.org/web/20260430011533/https://www.heise...

I personally live close to a commercial Asbestos dump (an old mine) and absolutely nobody cares about it. It's so unimportant it doesn't even have a Wikipedia article.

Yet the second radioactive waste is concerned (even if it's just old rubble) everybody seems to lose their minds and refuses to even think rational.

Just doing the basics goes a long way with a tiny fraction of the effort. Yes it will leave some percent on the table but this is hardly the end of the world. With their own compiler they have full control over the entire chain and might be able to make up for that with their own language-specific optimizations.

Go has a custom compiler, too, it's not as good as LLVM, so what?

Everybody can do that now with zero training.

LLMS are the ultimate equalizer. You won't have a future if you can only do average things fast. It's time to become eccentric, and the academic bubble is perfect for that.

EU expects to use Russia's frozen assets as collateral/reparations for repayment when Russia gives up/Ukraine wins. Everybody knows that Ukraine cannot repay themselves.

> whether that means nukes or the other weapon that has worked really well in Ukraine (killbots), is going to be massively unpopular.

This thinking dominates the current discourse and it is shockingly stupid. Making nukes and drones is bad and unpopular, alright.

So instead we "prepare for war" and "get ready for hard times" because it sounds so brave, so heroic and abstract. Politicians are suddenly allowed to spend staggering amounts of money on defense companies - people love it - and nobody wants to ask what exactly is the scenario we are preparing for.

Why? Name one scenario where EU needs a bigger army and masses of barely-trained conscripts.

If you say "Ukraine loses", why not spend all effort on helping Ukraine instead?

> So, I am all for better health care, better education, less dependency on foreign gas and oil, better funding for goverment programs ...

You do realize that preparing for war is insanely expensive and can only be funded by cutting all those other nice things? Also, what do we need education for if we actually expect many people to die in World War style ground warfare?

How about: Let's build some nukes, spend the rest of the money on Ukraine support, and forget about ground war conscription lunacy?

So this is the best way to generate extreme load and stress-test the internal architecture of an HTTP/1 server. But yeah the sendfile approach only works for this kind of testing and not in the generic case.

If you only received ~80KB for 10M requests the server probably terminated the connection early before processing all requests (like nginx does after 1k requests on one TCP keepalive socket if you use the default configuration). Check the responses-XXX.txt files to see what happened. You then need to either adjust the server configuration or use multiple sockets with the max keepalive requests the server can handle.

If you run this tool on the same machine as the server process, the requests file is likely held in the file system cache (RAM and shared by all threads) and every recv() call by the server under test is essentially a memory copy at the speed of the machine's memory bandwidth, which can easily be >>10GB/s or millions of requests per second per connection. This is also way faster than typical servers can even parse HTTP/1.

But highly optimized servers running straight HTTP/1 without TLS or backend logic on multiple threads should absolutely hit multiple millions of requests per second with this tool. Researching how fast an HTTP/1 server can get was the reason I made this in the first place.

Try the -shutwr option if the server doesn't close the connection itself. I used it to test lots of exotic implementations and there are weird things going on in overload situations and around connection management. NodeJS for example started dropping connections on localhost(!!) on high load.

The tool was built for high values of keepalive requests, if the server is too fast just use more requests, e.g. -n 1000000 or something similar. Unfortunately some servers close keepalive connections after quite few requests, nginx has a default of 1000 for example.

This is just a simple tool I hacked together as a student to collect some data, didn't spend any time making it more accessible/user friendly, sorry.