From my perspective, in the long run authors and artists will be the actual survivors of it. Open weight models are getting harder and harder to run on consumer hardware, and pricing for cloud offerings are – and will keep – raising. Software will probably be the only worth use case at that point.

Next time invite me to the party 😝

Granian does :)

That works too.

"All rights reserved" means you keep all the rights. So nobody can reproduce, distribute or modify without explicit permission from the holder. That doesn't really play well with an OSS license 😅

If you intend to keep the same license, then yes, you can just change the name.
If you want to move to a different license (eg: MIT) you might need to check with all the contributions they're ok with.
Side note: the "all rights reserved" part feels a bit weird for a BSDv3 license.

This piece by @garymarcus.bsky.social is - as usual - spot on:

garymarcus.substack.com/p/gpt-5-over...

I'd say it really depends on what kind of programming you do.
Prototyping stuff? Sure
Boring things? Hell yeah
Building libraries and tools used by others? Meh
Existing 10k+ lines codebase? Definitely not
Also: how much productivity you trade now for later maintenance?
Open coffe/beer in vie ;)

How many threads? You mentioned long queries, but what's the expected concurrency on the database? To me 10 processes x N threads per container sounds a bit too much. I'd say all those threads will spend a bunch of time fighting each other for CPU time..

Yeah, I never got the point of a2wsgi. At the end of the day it is a wrapper, so you spend more CPU cycles in the translation layer with very few benefits – the network part of the request response is async, but everything is still blocking and running in a single thread.

Uvicorn does ASGI only, so that part feels strange too. The post seems to imply it also switched from WSGI (uwsgi) to ASGI (uvicorn). But given Django is not exactly designed for ASGI it feels weird.

Granian maintainer here.
Curious about how you configured Granian, feels strange to me that delivers worse perf than uwsgi.

You might want to check out Granian, usually the CPU usage is ~10-40% lower compared to uwsgi 😉

I'm not a CPython core dev 🤷‍♂️
But again, just 'cause that happens with gunicorn, doesn't necessarily mean the same for Granian. Sure if the leak is within the app, there's nothing I can do. But in Granian everything which is not your app is allocated in Rust, not Python.

To be clear: I don't think max-requests is always a bad idea. In fact, it might be added in future versions.
What I'm saying is that:
- restarting a worker (and thus a whole Python interpreter) every 2048 reqs is just a huge waste of CPU cycles
- it won't help you with scaling. Ever.