"That said, Japan isn't the only country pursuing lithium recovery. In the US, Redwood Materials – the recycling company founded by former Tesla CTO JB Straubel – says it's already recovering 95% of lithium from the equivalent of about 250,000 EVs per year."

EV batteries are too large and valuable to wind up in landfills, although I'm sure it has happened somewhere. I do like that Japan is is making it harder to just throw out smaller lithium batteries. That strikes me as a more probable source of waste.

(No, no, I take this stuff seriously too, but it had to be said)

In my early tests tonight, Sonnet 5 is a LOT better out of the box. It's one-shotting complex instructions. It also recovered independently from bad instructions that led to an uninformative 400 error by using its schema-fetching tool to figure out there were was too much input.

If I have to gripe about something: it interpreted another impossible instruction by quietly discarding the input in question. But, the way it did it is... kinda exactly what anybody else would do, if they weren't in a position to change the implementation.

This is, obviously, early days but I'm impressed.

https://github.com/noonghunna/qwen36-27b-single-3090

Flies though (50-70tps is impressive for a model this smart)

I went through roughly the same process to get it working on my M2 Macbook Pro... at awful speeds of course, since models like this one are mostly bound by memory bandwidth.

I actually nuked my music library off my Mac to mitigate this problem, but it's still a nuisance when the app launches.

Thank you for sharing this!

Although I no way suspect this particular individual of anything untoward, of course it's always possible it could be part of one of the long-term goodwill-generation campaigns mentioned by the Ladybird team. Generating credibility by making seemingly difficult genuine contributions over a long period, then abusing that credibility. But in our particular project we're not in the habit of delegating approval authority, so I'm less concerned about that.

I think the answer is that there's a tradeoff here where additional throughput for a single person can be achieved only by tying up more resources than a normal request would, even when you take into account the fact that the normal request takes longer to finish. I'm not an expert, but some of the optimizations they describe, particularly the parallel prediction stuff, sound like they could take up extra resources.

One day I was encouraged to write a Windows Sockets emulation layer for ordinary dial-up shell accounts like those offered by netcom. The idea was to allow the use of the recently released Mosaic browser without an actual internet connection. I figured sure, no problem. I'll use curl or some other tool in the shell account to do the actual fetching of URLs, transfer styles over zmodem, and simulate all the tcp/ip calls in the DLL.

I couldn't even get started. The reason is that I couldn't understand how the different Windows applications could all share memory allocated at runtime in the winsock.dll.

I asked a highly experienced ex Microsoft person, and he just said what are you talking about. There's no API to allocate shared memory.

So I gave up. 6 months later someone else did it.

Around then I realized the truth: Windows 3.1 had no memory protection at all. Specifically all global variables in DLLs were shared by default. The hard part wasn't sharing memory among users of a DLL. If anything, the hard part was having good discipline to avoid sharing it.

Since I'd only used multiuser Unix in school, and I knew Windows supported multitasking (even if only the cooperative kind), I just couldn't wrap my head around the idea that I'm multitasking operating system could exist without memory protection.