Side note, if you're a lazygit fan, consider using gitui as an alternative. Feature wise they're pretty similar but gitui is much faster and I find it easier to use.
tmux! That was today's project. I'm using Claude Code Opus 4 to translate a K&R C computer algebra system (Macaulay) from the 1980's into C23. Finally getting to the "compiles but crashes" (64 bit issues) I found us living inside the lldb debugger. While I vastly prefer a true terminal to the periscope AI agent view in Cursor, it was still painful having at best a partial view of Claude's shell use, interleaved with our chat. What I wanted was a separate terminal session AI and I could share as equal partners.
tmux is the quickest way to implement such an idea.
> The neighborhood cafe where locals can stop by at any time and see other locals
This is still the norm in some places. When I was cycling through the Balkans, I was surprised how many people sit in public spaces, usually close to a kiosk, and play cards, throw dice, or just chatter
Whole southern Europe is like that (sitting now in a small trattorria in Liguria province in Italy, I see this everywhere, and ie Spain, Portugal or Greece is same).
The problem mostly arises in big cities where a lot of young move for work, I'd call those socially sterile places.
In the US homeless people might sit on park benches and be seen so benches are sloped to be uncomfortable for more than short periods. Benches are intended as a temporary rest for those that need it as they walk, not a place to just sit and chill.
My area's solution is we don't have parks, we have public land trusts that are actually private property and can ban people. They're pretty nice for those of us allowed.
In the USA people would graffiti the benches pee on the seats and a homeless person would move in. Almost no protection exists to prevent destruction of public property. I think that’s intentional to discourage people from embracing socialism.
Modern benches and even parks have anti-homeless features. iirc some park in Minneapolis removed their basketball courts because black people would congregate there (also there was drug-dealing). In USA its spend money or get out.
The only way we'll be seeing that trend go away is if they're banned. Those shoes improve race times so much they stretch the definition of what should be legal in racing. Nobody's going to revert to barefoot running for racing unless they don't care about their times.
Yeah, they may look goofy but they work, similar to how lycra makes one look like a power ranger but you won't see anyone in the TDF wearing a hoodie and jeans.
I know a guy who has been no shoes for almost 20 years now. I think he does use the shoes with the toes when running, but in everyday life, he's just no shoes, no socks. The exception is situations where he's in a formal wear, in those cases he does put on shoes.
Most others who didn't the barefoot running have all quit.
Ultra-endurance cycling like the race you mentioned is fascinating. I once met a few contestants in a European bike race and drove alongside one. He said the best in the field sleep around 4 hours per night and do 500+ km per day.
Depends on how long you're doing it. For a Divide length race, you're going to need more than 4 hours a night. 5 would be sustainable. 4 would work for events 3-5 days long I think.
Either way, the sustained output is ridiculous. These racers go harder than me on my gravel bike, fully self supported, often on rough tracks, for 20ish hours a day, day after day.
Then at the other end of the spectrum there are lots of people who go quite slow, but for months. I'm not sure which is more impressive; both show tremendous grit but in different ways.
Both those ways of approaching bike travel require a particular mindset. I've been at 6 hours of sleep in 72 hours, been soaked through my layers in torrential summer rain, woken up with my feet in 2" of water in my tent, and loved it all.
The only thing that truly sucks is when you can't continue. Like getting two irreparable flats 20 miles away from town in rural New Mexico, or getting an injury that ends your journey.
Hard to explain to people that don't experience it like that, but even if it doesn't feel good all the time, it's basically always still somehow fun.
The explanation is in the article. Tldr is for sync functions, the CPU is blocked, with async functions, once the await statement is reached, other stuff can be handled in between
Indeed it says "It enhances performance in areas where tasks are waiting for IO to complete by allowing the CPU to handle other tasks in the meantime".
To restate my comment: I argued (1) this CPU cost would be very marginal compared to the LLM API compute cost, and (2) the CPU blocking claim doesn't really hold, due to the wonders of threads and processes.
There are two ways to call out to an externally hosted LLM via an HTTP API:
1. A blocking call, which can take 3-10 seconds.
2. A streaming call, which can also take 3-10 seconds but where the content is streaming directly to you as it is generated (and you may be proxying it through to your user).
In both cases you risk blocking a thread or process for several seconds. That's the problem asyncio solves for you - it means you could have hundreds (or even thousands) of users all waiting for the response to that LLM call without needing hundreds or thousands of blocked threads/processes.
Reading this my first reaction was that my questions still holds. Unless the slowness of the LLMs is of such a magnitude that having a thread or process waiting on the API call would substantially increase its cost, which I guess would mean the LLM server endpoint would be doing very heavy queuing and/or multitasking instead utilizing a powerful compute element for 90% of the call duration.
Or maybe the disconnect is where I'm taking for granted that "cost of parked thread" is the same as worrying about the nr of parked threads? Maybe everyone uses Django setups where it's nontrivial to add memory, increase serverless platform limits, etc if you get the happy problem of 10k concurrent users? Or maybe people don't know that the nr of threads/processes you can have on Linux is much more than hundreds or thousands. Or maybe there's some Python or Django specific limits to this.
Maybe I need to update my mental model of how many threads is too many on Linux (and benchmark the impact on the GIL here, which should at least be released for I/O network waits).
On my Linux desktop the default cap seems[1] to be ~32k.
See eg https://www.baeldung.com/linux/max-threads-per-process for some runtime sysctl knobs if you want to go higher than the default limits. (Though the section 6 there seems out of date and written with the 32-bit OS in mind)