Pinned Tweet
Happy to announce Speck PBR, the spiritual successor to my original molecule visualizer, Speck. 🧵github.com/wwwtyro/speck-pbr
Rye Terrell retweeted
I see how some people can watch flashy robot demos on the timeline and think with a shiver that the robot apocalypse is around the corner, but reality check:
There is no robot in the world that can change the batteries in a jack-o-lantern.
If you have a robot friendly door handle it might be able to walk outside, pick it up, and carry it back inside. The robot could open the drawer with your batteries in it, but then things get tough.
Opening the package of AA batteries?
Extracting a precision screwdriver from its case?
Unscrewing four tiny screws that require a hard press and twist?
Popping batteries out of the case?
Yes, you could build and train a specialist robot to do that today, but there is a very long way to go to replace the full range of human capabilities. Near term doomer scenarios should stop at “secretly controlling humanity” instead of “wiping humanity out” 😀
Rye Terrell retweeted
My take on the easiest way to get started with software factories today github.com/mikolalysenko/ins…
Rye Terrell retweeted
i am starting a new subreddit for the future of gaming old.reddit.com/r/superintell…
Seems like roughly once a year I get the gamedev itch. I guess I need a break from the serious stuff. Anyway, here's this year's 😁 You can play it on itch here: wwwtyro.itch.io/rackfall
Rye Terrell retweeted
Replying to @molecularmusing
AI has this leveling effect, and many are excited because they never had the required time or skills to make stuff, but now are fully empowered and feeling the magic of creation for the first time. That is good.
But on the other hand, I think that building something new, still requires imagination, taste, stamina (all three trainable), and either lots of luck or being plugged in the right circles. That's a smaller subset of folks.
I imagine the empowerment will wear off eventually, and most will return to buying/consuming what a few create? We'll see.
Rye Terrell retweeted
🥁 𝐒𝐩𝐞𝐚𝐤𝐞𝐫 𝐀𝐧𝐧𝐨𝐮𝐧𝐜𝐞𝐦𝐞𝐧𝐭🎙️
Thrilled to have @MikolaLysenko on the #NodeConfEU 2026 stage! He'll tell us the story of "𝐃𝐞𝐥𝐞𝐭𝐞 𝐚𝐥𝐥 𝐂𝐕𝐄𝐬."
🎟️Don't miss it out; secure your tickets nodeconf.eu/
Rye Terrell retweeted
I recently went through a translation of Musashi’s Book of Five Rings.
The introduction chronicled the evolution of swordsmanship and martial arts in general from pragmatic battlefield necessities to sports, historical curiosities, and hobbies. It was interesting to hear how in the post-WW2 occupation when martial arts were banned, Judo was represented as equivalent to western wrestling, and Kendo later to western fencing.
The poignant undercurrent for me is that I can see many programming skills following that path.
There are probably dozens of people reading this that remember hand assembling opcodes to hex and still have some magic numbers burned into their memory, but even the small group of people still programming in assembly today (hey, @FFmpeg !) don’t work at that primitive level now.
AI is making many other programming skills much less critical. We aren’t there yet, but carefully writing code completely by hand is moving from a -jitsu to a -do. Code-do? Codo?
That’s ok! The retro computing scene is delightful, full of people building and exercising old skills for the love of it.
But don’t be the out of touch Kung Fu master, heir to lifetimes of tradition, that gets mauled by an amateur MMA fighter.
Musashi would probably have been pretty enthusiastic about assault rifles.
Rye Terrell retweeted
I'm still having fun playing with this. Radiance cascades + lots of physics objects is just awesome.
Check it out yourself! cmiller.tech/rc-pegboard/
Rye Terrell retweeted
Today, we launched our second-generation driverless fleet.
Without a person behind the wheel, these trucks are ready to help us serve growing customer demand.
Built for commercial deployment with next-generation hardware. Learn more: bit.ly/4hqBgiK
Rye Terrell retweeted
hello there the jacobian conjecture is false thanx to my close friend akhil for asking about it and my other close friend fable for working during the world cup final
((1+xy)^3 z + y^2 (1+xy) (4+3xy), y + 3 x (1+xy)^2 z + 3 x y^2 (4+3xy), 2 x - 3 x^2 y - x^3 z): \C^3\to \C^3, has jacobian determinant -2, and sends (0, 0, -1/4), (1, -3/2, 13/2), and (-1, 3/2, 13/2) to (-1/4, 0, 0)
In the same way Opus 4.6 got me to stop reading lines of code and start focusing entirely on architecture, Fable is getting me to ignore architecture and start focusing on what to build.
What a completely wild few years. And it's probably just gonna keep accelerating.
Yo @MeshyAI, your new smart topology generator is heckin' sweet. Faster, cheaper, and better? Y'all need to calm down over there.
Hey @grok, speculate on the inference performance of the popular open source models (of various sizes) using this approach. Include prompt processing and token generation tok/s.
Memory cost and capacity are significant issues for AI accelerators.
Unlike game rendering, model inference can have a deterministic memory access pattern. You don’t need “random access memory” at all for model weights, and you could tolerate cold-start latencies in the multiple milliseconds, as long as continuous reads were delivered at the necessary bandwidth.
NAND flash is over 100 times cheaper per GB than HBM, so there should be opportunity there, even after giving a flash controller a 1024 bit interface with HBM bandwidth.
You could make a specialized pin protocol that just supported pipelined transfer of full 16KB+ pages from the flash to program-managed accelerator scratchpad memory and improve per-pin performance over HBM, but it might be more convenient to make it still look like a true random access memory with very fragile performance characteristics, where anything but sequential reads falls off a 1000x+ performance cliff.
That has the advantage of automatically using existing cache hierarchies, and providing a natural path to update the flash memory with new model weights. With the stream-to-scratch interface, code has to be completely rewritten before it works at all, while the ram-emulation interface will start off just extremely slow, and you can incrementally sort out the changes for full performance.
There may be cases where there isn’t enough scratchpad SRAM to hold the weights for a layer, which might force you to deploy the old optical drive optimization technique of duplicating data in multiple places on a sequential read to avoid seeking, but there would be capacity to burn.
It might be possible to do something like cuda graph capture to record a memory access trace and have everything magically remapped to a linear sequence, but deploying programmer / agent elbow grease to manage transfers and access in a scratch ram ring buffer would be lower risk.
A split memory system consisting of some channels of flash and some channels of HBM will probably be suboptimal compared to a uniform memory, but it could be much cheaper, and allow much larger models to be run.
I think th case is strong for inference, but you have to stretch more for training. You can still linearize all the weight memory accesses, both reads and writes, but flash memory would quickly wear out from the writes, even if they were all perfectly page aligned. Replacing low-latency HBM with massively parallel cheap(er) DRAM at high latency might still be a worthwhile cost savings.











