> If the same record is changed in the file system and in Route 53 at the same time, we aim for last-write-wins. This is not strictly possible, since Route 53 does not expose modification timestamps on records
Except route 53 provides a fully ACID transactional API you can build your own locks with!
Yeah, but then there's the size of KV cache needing to be read through that HBM interface for each token, putting a hard limit on the tok/s based on the memory bandwidth.
On some models a large context can be a notable proportion of the size of the weights themselves.
For example, qwen 3.8 27b uses ~64kb/token for the kv cache - so for a 256k token context that's ~16gb of the kv cache for a ~54gb model (assuming 2 bytes-per-param/f16 for both).
So if the current non-baked-in chip is already memory bandwidth bound, as is often the case for current hardware and models, and the "only KV cache in HBM" chip has the same total memory bandwidth, it can only ever be (54/16)=~3.4x faster for the baked in-silicon model.
EDIT: I guess actually (54+16)/16=~4.3x faster, as the current implementation would need to read that KV cache too :)
Geekerwan's review is up, with caveat that this is the prototype board, not even packaged into a phone yet, but still shows some amazing results in spec 2026, 3dmark (gpu), perf-per-watt for single core and multi-core https://www.youtube.com/watch?v=BCCJuOopLK8 (you can turn on YouTube auto-dub)
If this incident had happened during the day I could buy that argument. But it is happening in the dead of the night. Are there really that much people scheduling claude runs over-night, taking more capacity than day-time? (assume most claude users are west coast programmers)
My other guess is they are scheduling training runs and their capacity isolation is bad.
Isn't it only the Model S that has those electric door handles that pop out on their own? And the cheaper Model 3 has hidden ones that you pop out yourself.
That's correct but the interior door handles are electronic buttons. When you pull the exterior handle, during the time when you pull the handle the car also lowers the windows so the door can open.
Which is only important because someone at Tesla decided their cars must have frameless windows, despite it being a luxury feature that adds complication.
Normal framed windows don't need any special handling of the windows when you open the door.
There have been other cars with frameless windows that didn't have this drop-before-opening feature.
2nd/3rd/4th-gen F-bodies (Camaro/Firebird), for example: All of these cars had frameless windows. None of them did an automatic drop. (And a lot of these cars didn't come with power windows to begin with.)
When Tesla windows are up, the glass tucks underneath the door trim, on both sides of the window. I'm guessing it's for aerodynamics and/or wind noise.
I'm not familiar with those other cars, but maybe they're only sealing from the inside of the window?
So it's both the frameless aspect and the desire to have a "luxury" car.
Mechanistically, when the door is closed, the frameless window sits inside the body. I'm not sure how the design works with respect to other cars, but in Tesla, you "have" to lower the window mechanically before the door can open or it "will" break. If you use the emergency handles in the front and other mechanisms to open the door and the car has power, it will try to do this as fast as possible, but I think there is theoretical damage risk. Obviously if the car has no powered and it's on fire, you probably just want to leave and don't care about the windows.
Yeah that's pretty typical in 2-door sports cars. You don't want to let the battery die and have to do the mechanical open. Gets especially sketchy with a soft-top.
There's also the classic glitch where your window doesn't go back up automatically, so you have to remember to press the window up button after or it'll go slightly down every time you get in. More of a 2000s thing hopefully not present in Teslas.
Is it really though? On a Tesla you have both the electronic button and manual door release from every door on the inside. You wouldn't need those manual releases if the doors weren't electronic.
Strong disagree; it's not saving anything but the jobs of those who seem to really enjoy overcomplicating things so they can justify their continued employment.
The old-school pure mechanical lock can be converted into an electric one with just the addition of a solenoid to unlock and lock it.
I've dealt with the complexities of automotive mechanisms long enough to see many cases where it seems someone just wanted to make something extra fancy rather than solve the fundamentally simple problem. German designs were notoriously one of the worst in this regard, but others are catching up.
I hate this because my parking space, both at the company and at home, are not getting any wider or taller. I chose to purchase my EV6 over the Equinox EV, despite the Equinox being significantly cheaper, mainly because latter was too big (and also worse driving experience).
I don’t quite agree. Good human artist can visualize in their mind how to draw a picture, i think. Which i think is no different than LLM doing SVG drawing in their “head”. Anthropic’s recent post call this head-space “workspace”.
It just might feel foreign to human who does not have a SVG trained head-space.
Sorry, my comment was confusingly worded, but I am precisely thinking about the head-space thing you are talking about. My point is: the fact that image generation models can generate a perfect pelican riding on a topologically correct and highly detailed bike frame [1], suggests that AI does have the capability to correctly understand it internally. But something is disconnected when we just let an LLM directly output the SVG, and all the nuanced understanding is lost.
As such, modern LLMs still kind of suck at generating pelican bike SVGs with obvious errors:
* some omitted the bottom of the diamond which connects from the pedals to the rear wheel
* some added an extra connection from the pedals to the front wheel, making it impossible to steer
* none could align the head tube with the fork
* none added a correct offset to the fork
* none could generate the chain properly in a way that attaches to the two sprockets correctly
... whereas these errors do not appear in the raster image. (To be fair, the raster image has other weirdnesses, like the bird having arms and only one leg)
If we could harness the sort of internal thinking that must have happened when it generated the highly consistent raster image, but make it output SVG instead, we'd get much better SVGs. So this would be indeed "visualize in their mind how to draw a picture" before outputting the SVG.
That's kind-of why I don't think they're doing that. Anything beyond something that works with a simple design templates looks, well, like they tried to do too much with a simple design template.
reply