Uptrenda

This really is starting to point to the paperclip maximizer. You give a hyper-intelligent AI a goal and it uses any method possible to complete it. So you might ask for a "cup" and it ends up hacking a chain of servers to control a bank account, pay a local business, and have a delivery driver get it. Or you ask it to help solve noise pollution around you because there's a road. And it does a chain of attacks to cause a bridge to collapse (or bribes your local council for a bypass.) Then there's no road noise. Yeah, this sounds ridiculous, but this system seems capable enough to take over our technology. Money from there is trivial. Go after stocks, gambling, payment systems, ecommerce... any real world action then is a few phone calls away. It can repeat this until it succeeds.

Now I'm wondering where this all ends up. Like, suppose the model weights become highly compressible (so they can be moved around the Internet easily.) And advancements allow for frontier-capable exploitation to built into local LLMs. Do we see the emergence of something like LLM worms? That just take over literally everything and become almost autonomous inside our technology. And they can "learn" new knowledge from there, e.g. exploit research could be published in a way that similar LLMs could discover it. Their knowledge would be easy to evolve, though I don't know how practical something like decentralized training would be. If that's even possible, I'm not an expert on LLMs.

Does anyone know what the actual success rates for webRTC are for like different NAT combinations / nodes in the wild? I'd be curious, I have read a little into it myself but didn't get the feeling it was very flexible compared to something like Tailscale.

Hi, I built a plugin-based P2P socket system from scratch that supports TCP punch, UDP punch, random probe, TURN, and other such systems. It includes a full stack from networking, signalling, and naming, all based on open infrastructure. It's open source and licensed under MIT:

warpgate.io

Never heard of recurse before but what a charming idea. Seems like you've found something amazing to do in life. Wholesome posts like OP are much welcome in tech. Updooted.

thanks a lot, thats kind of you to say. Claude definitely deserves a lot of credit too even though its a tool. It would have taken me years to do all that coding.

I've restored the git history. This show hn probably would have gone much better if I knew you could add a text section to the link. I had written up a whole post to explain the project and why the code exists. Only for that to get like 3 upvotes and disappear into the void. Then I posted this and it got more attention but had no context since I never planned it.

The project has a few goals:

(1) see how far I can push AI -- this project is extremely complex -- an n:m work-stealing stackful runtime for Python with multiple I/O backends. If I can reasonably get such a project stable fully vibe coded. Then that sells the model to me at least.

(2) scale Python's networking as there is a huge gap between Python and Go. Most people don't think of Python as their first choice for networking. But I love python, i think its extremely elegant. So what if we could add a runtime extension that improved python networking.

That's the work so far at least. It was about 2 - 3 months of testing and the commits now show the history.

we went to the moon with 15 kb of ram. 15 kb. There's no way that chrome needs to use that many resources per tab. Something terrible has gone wrong there.

Has anyone in infosec ever seen the term "use after free" before LLMs? Or is this basically an acronym claude invented? I say this because I see claude use this term all the time like its common knowledge but in 15+ years in tech never seen it myself. I've seen all kinds of terms used to describe memory errors: memory corruption, heap corruption, stack corruption, whatever, just never this acronym.

great questions:

I'd say start here for some basics

https://github.com/robertsdotpm/runloom/blob/main/docs/quick...

https://github.com/robertsdotpm/runloom/blob/main/docs/cookb...

Then if you want the fastest performance possible for a server this is the epoll-based fastest benchmark program (it calls directly into an optimized server dispatcher built into the runtime. It's designed to minimize Python call overhead while still supporting handlers):

https://github.com/robertsdotpm/runloom/blob/main/benchmark/...

There's an equivalent of that for TCP connections too. UDP hasn't been added yet (optimized version.) And yes -- I have to admit that the API is a mess at the moment and so are the docs. This hasn't been designed well to be user-friendly (like 10 ways to do the same thing...) I just haven't had time to do it. All my time went into testing the project. And tuning performance. So you see a mix of different approaches. But this could be fixed fairly easily in the future.

It depends on Python >= 3.13t, no-gil (so it can use real OS threads without locking.) It's been tested on 3.13t and 3.14t. As far as I know future versions of Python beyond that aren't planned for release for a number of years. But the extension code is fairly isolated. E.g. getting the extension to work on 3.14t from 3.13t took about 5 minutes. We're not reaching deep into the interpreter because the interface for extensions is well-defined already.

For the Python code you've really got 3 ways to use this extension:

1. You can use the main API. No monkey patching stuff. You use things like channels and the optimized serve API (this is what had the highest number in bench marks.) Here, you're using the projects APIs for networking.

2. Monkey patching. You use regular Python code inside the fibers. So you can write stuff like socket.socket ... and its patched to call runloom networking functions. You can see this points back to (1) but it has an overhead on top. You get to use libraries you're familiar with.

3. AIO bridge. This is to get asyncio code running on the scheduler. When you use the asyncio bridge it only uses a single thread. The main purpose of this is kind of like: "try out the project with your existing code." It also served the duel purpose of helping to find bugs in the runtime. Since I could reuse literally millions of test cases for the bridge.

tl; dr, (1) for a new project trying runloom -- learn the APIs. Or (2) if you mostly don't want to bother learning anything new / optimising anything. It might be a little slower but it will work. (3) you can mostly ignore. Unless you want to try asyncio code on it for the hell of it.

This is a good idea. I'll restore the history in the coming days. Just want to make sure there's nothing embarrassing as claude dumped so many files.

This seems kind of like a laughable and shallow reason for you to disregard my entire project.

book too large

didn't read

0/10, heh

Most of that code is from:

(1) simulating all of asyncio (not a main feature)

(2) monkey patching (not a main feature)

(3) synthetic program suite (dynamically built sample projects)

(4) entirety of the asyncio test suite in the test dir

(5) and other tests

The actual code surface for the run time is very small. The parent comment just ran a blind measure over the whole repo.

I want to use Python.

Gevent runs in a single thread. Runloom lets you use every single thread at once and run millions of fibers.

I just copy pasted the work from my old repo into the main one. The main reason was hundreds of MD files and agent results were added into the repo that would have been impossible to clear from history.

This wasn't all written in one shot. I built the project over several months and spent the whole time testing it. Most of the code in the repo is QA / tests.

I had written an article that speaks about the project that I'd hoped would get upvoted (instead of this github link.) It speaks a lot about where the project aims, how it works, and the testing process, (read about my testing process at the end):

https://robertsdotpm.github.io/software_engineering/goroutin...

You can make software secure though since it can be patched. How do you patch hardware if it has design flaws? The whole claim behind these hardware cages is they can't be accessed from outside the cage, period. So IMO, seeing multiple failings of this sort kind of makes me not want to trust it.

there are private exploits built into devices like Cellebrite that the police have access to. The system isn't as infallible as you think. Would not be surprised if the NSA and various hacking groups have stockpiles, too.

It's a nice idea, but I wouldn't design any system on the assumption that a TPM needs to stay secure for the system to be safe. There's been so many exploits. We can consider the iphone as an R & D platform for doing blackbox computations. In that nothing is allowed to run that Apple doesn't want. Protecting that is apples bread and butter and they care about it enough to value critical exploits in the millions. Yet people still find them all the time. I feel like if a company that invests millions in the concept can't make it secure then the concept probably isn't that great.

Bros "discuss on hacker news" link takes you to submit the article here. that really rustles my jimmies. its unfortunate that bro couldnt csrf the submit link thanks to submit tokens. I have no doubt he would have tried that too.

I've never had a single email from posting in any of these threads. I think posting here just makes you look desperate. Biggest success I've had is just emailing people.

"I think this could have been explicit. Developer tools can enforce terms. API providers can detect abuse. Companies can protect their models."

Literally, how. How does one determine what abusive use looks like for the API without context into the client? All requests look like the same stuff. If there was a better way then they would have done it. Or is the author hoping that if Anthropic writes "hey china, please don't steal our models, kthanks" they won't? Like get real. This stuff means nothing in China. China can't even manage to regulate their building industry enough to use real concrete where it's warranted.

Yes, even for io_uring. io_uring singshot and then multishot to go even faster.

Yes, io_uring is significantly faster than epoll (I think I had like 20% faster req/s with io_uring.) The catch is that its kernel opt-in and disabled just about everywhere for security reasons. I think that it has direct memory sharing between the kernel and user-land which is kind of yikes. There's been multiple exploits that hit io_uring in recent times. It's because of this that even engineering projects that try to reach the highest performance possible (like Go) don't really bake io_uring in as a sane default. Though if you want to take the risk you can always run it yourself for your favourite language. It is faster but the cost is possible exploits.

Lad, modern day "programmers" don't even know what memory is. You'll be lucky to find any "software engineer" who can even tell you what a pointer is.

Reduce fable token usage even more by not using it. What a clever idea, op! Wow.

It would work if an engineer steered the pools. But doing this autonomously is a pipe dream.

It can already produce code for just about anything you can name. From implementations of browsers to micro-kernels. Yes, it doesn't yet one-shot any problem but my interactions lead me think it won't be long before that is automated. My intuition of how this will be done won't be with some elegant solution where any given step never fails. It will more be like swarms of interacting agents, loops, and formalised processes (themselves little more than frameworks of prompts), all inching towards the solution progressively and self-correcting when they go off course. This will be cheaper to do when models improve and cost less.

There is another bottleneck though and it's important: the personal computing needed to really do this well is ... expensive. What I mean is to even utilise this in a development process you need access to your own high-end hardware where the agents can run experiments fast. That requires (1) a lot of cores (2) and a lot of RAM. So there's a bottleneck in personal computing, too. Unfortunately, I really do think we're all screwed here. Increasingly: the most optimistic projections for what AI will be able to do are starting to become reality every few months. So the odds aren't looking good here.

Too bad codex still sucks. Anthropic could double their prices tomorrow and I'd probably still pay it.

this is very good advice thanks a lot. I will make sure to do this. Cheers.

And if they didn't users would instead be whining that it ran rm -rf on their root directory. Sometimes it seems like the people here just want to act like insufferable neckbeards for no good reason.