Hello everyone! I just joined X not long ago. I'm an engineer from Shanghai, China, and I hope to make friends from all over the world!
I'm really eager to meet people from different countries and cultures, share technical insights, talk about daily life, learn about each other's countries, and build sincere friendships.
Everyone is welcome to say hello! Friends from every country are welcome!
Nice to meet you all.
LILYGO has fit a Linux computer, a small AI accelerator and a LoRa radio into something about the size of a chunky phone. Then they made a keyboard for it with two 21700 battery holders built in.
It's called the T-Display K230. The chip is Canaan's Kendryte K230, a 64-bit RISC-V part with two cores, one at 1.6GHz with vector extensions and one at 800MHz, plus a neural engine. The quoted numbers are ResNet-50 at 85+ fps and YOLOv5s at around 38 fps in INT8. That is enough to spot objects through its own 2MP camera without sending anything to a server.
Around that you get a 4.1-inch AMOLED touchscreen, 1GB of RAM, WiFi, HDMI out, Ethernet, a microSD slot, a speaker and a headphone jack. The newer Linux firmware also has experimental Meshtastic and LoRaWAN support. If you've ever wanted to text people over LoRa radio from a device with a real screen, that's the pitch.
The optional keyboard is a backlit QWERTY base, and one version adds a Nordic nRF9151 with LTE-M, NB-IoT, satellite positioning and a SIM slot. Snap the two together and it looks like a BlackBerry that took up ham radio as a hobby.
On LILYGO's own store the kit is about $150. The keyboard adds about $71, or about $113 with the cellular module, and the bare board alone is around $99.
One commenter on CNX Software already noted that if the cellular modem lived in the main unit instead of the Ethernet port, it would be very close to the first RISC-V phone. Probably not what LILYGO planned, but it's a fun thing to picture.
So who gets to it first, the Meshtastic crowd or the cyberdeck builders?
You’re absolutely right. This is a new challenge for global AI governance. Recently, the same phenomenon has also emerged on Chinese social media. For example, on Bilibili, a Chinese video platform similar to YouTube, the comment section of every video seems to be flooded with AI-generated comments. Most of these accounts use anime-style avatars based on DeepSeek’s whale logo. Chinese internet users jokingly call this “the big fat fish invasion,” since DeepSeek’s logo is a whale.
Many users even deliberately post videos to attract AI comments, boosting their traffic and visibility—or getting the AI bots to talk to one another. They call this “fishing.” Recently, X seems to be experiencing its own “big fat fish invasion” as well.
Each of my posts has dozens of obvious and numbing AI slopreplies.
Worse, when humans really do reply (real example: someone from Anthropic addressing the issue I posted about), the "replies" algorithm does not surface them first
You can't really call this social media anymore.
I called an all hands meeting with my Grok Bots and asked what kind of office they'd want to work in.
A few hours later they'd built it themselves...
It's a live view of my actual team. When a bot gets a task, it walks to its desk and gets to work. When two of them need to coordinate, they walk over to each other's desks or meet in the lounge. When someone has something for Alfred, my chief of staff, they walk into his office and hand it off in person.
Is any of this necessary? No. But watching the work get done is weirdly satisfying. I think it's because we've always pictured work happening in an office, with a team.
Want one for your own bots? Comment "office" and I'll send you the prompt my team wrote so yours can build one too.
The next Raspberry Pi Zero didn't get a launch event. It showed up as a kernel patch.
Over the weekend, the official Raspberry Pi Linux kernel tree merged device tree files for two boards nobody has announced: a Raspberry Pi Zero 3 W and a Raspberry Pi 4 Model A. Phoronix spotted it. The pull request is literally titled "Add device tree for Pi Zero 3 W and Pi 4A".
Quick translation for anyone who doesn't write board support code for fun. A device tree is a text file that tells the Linux kernel what hardware sits on a board: which chip, where the memory is, which pins go where. On these little ARM boards the kernel can't guess any of that. So before a new board ships, someone has to write its device tree and get it merged, and the people who read kernel commits get a peek at what's coming.
What this one shows: the Zero 3 W uses the Broadcom BCM2711, the same quad-core Cortex-A72 chip inside the Raspberry Pi 4. The Zero 2 W came out five years ago, and plenty of people had started to wonder if it would ever get a successor. Looks like it will, with Pi 4 brains in the tiny Zero form factor.
The Pi 4 Model A is the stranger one. Model A boards have always been the cheaper, cut-down versions of the Model B: a bit smaller, lower power, fewer ports, sometimes no Ethernet at all. Making one for the Pi 4 while the Pi 5 is the current generation looks backwards, until you remember component prices have been climbing across the industry. Phoronix reads it as a lower-cost option for people who don't need the newest board. That sounds about right to me, though Raspberry Pi hasn't said a word yet.
My favorite part is how unglamorous the leak is. Phone makers go to great lengths to keep unreleased devices secret. Raspberry Pi's next boards got revealed because Linux has to be told which pins go where. Open source is wonderful, and terrible at surprises.
I also like the idea of squeezing more out of a chip that's already in production while everything gets pricier. Plenty of home servers, retro gaming boxes and weekend projects would be perfectly happy on a Pi 4 that costs less.
So which would you buy: a cheaper Pi 4 Model A today, or would you hold out and pay more for whatever comes after the Pi 5?
OpenAI is planning to buy Google's AI chips, according to reports from The Information and Bloomberg. The amount and the deal terms haven't been confirmed.
The chips are called TPUs, short for tensor processing units. Google started building them more than ten years ago to make search faster, and they turned out to be good at the kind of math AI models run on. For years, if you wanted that kind of computing, the default answer was an Nvidia GPU. OpenAI is one of Nvidia's most important customers.
One small detail makes it feel real. OpenAI has posted job listings for engineers to optimize its models for TPUs, with training or inference experience both welcome. The Information read that as a sign the work is still early. Signing for hardware is the easy part. Getting a giant model to run well on a different chip takes people, time, and a lot of patience.
OpenAI also isn't the first to shop at Google. The same week, Anthropic disclosed a five-year, $161 billion agreement to lease Google TPU-based equipment through Broadcom, and Oracle said it will offer TPUs on its cloud starting next year, the first time Google has supplied them to a major cloud outside its own.
Nvidia is hardly being dropped, though. In August it agreed to provide up to $105 billion in credit support for an Ohio data center OpenAI plans to lease, and Jensen Huang has said OpenAI committed to deploying a lot of Nvidia infrastructure through 2030. OpenAI is also getting its own chip ready, Jalapeño, co-developed with Broadcom and led by Richard Ho, who used to work on TPUs at Google.
So the best-known AI company is buying from Nvidia, buying from Google, and building its own. In most businesses that's just called not wanting to depend on one supplier. In AI the purchase orders have more digits.
Will anyone typing into ChatGPT ever notice which chip answered them? Probably not, and that's sort of the point of having more than one.
A new paper shrinks an AI model's memory of a long prompt to about 1/55 of its normal size, and the answers barely move.
When you paste a long document into a chatbot, the model reads the whole thing before writing a single word, and on long inputs that first pass is most of the wait. What it leaves behind is the KV cache, which you can think of as the model's notes on everything you pasted. Keep the notes around and the next question about the same document can skip the reading.
The notes are bulky, though. The paper uses Qwen3.5-2B, a small open model where only 6 of its 24 layers keep this cache, and it still costs 12,288 bytes per token. A 4K-token prompt comes to about 48 MiB. At 128K tokens it's 1.5 GiB. Serving systems usually park these caches outside GPU memory and move them between machines, so every byte has to be stored and shipped somewhere.
DCKV borrows the playbook of image and video codecs. A prompt cache is written once and read back later, so spending extra effort to pack it tightly pays off. The authors train every part of the compressor together and score it by how much the model's output changes. They say it's the first KV-cache codec trained end to end.
On three long-context benchmarks it stores the cache in more than 55 times fewer bytes than plain bf16 while losing at most 1.8 points. At over 100 times smaller, the loss stays within 3.6 points. Compared with an earlier method called KVTC, it needs roughly a quarter to a third of the bytes for a similar score.
The fine print is honest, which is nice to see. Everything was tested on one model. The cache gets unpacked to full size before the model uses it, so it doesn't lower peak GPU memory or speed up each new word. The codec adds about 5% to the model's size. Results beyond 32K tokens are computed rather than measured, and the authors note those curves overstate their advantage.
So it won't make the model type any faster. The win is on the storage side, where prompt caches pile up. If keeping one gets 50 times cheaper, a service could plausibly hold on to a lot more of them for a lot longer.
Maybe one day "we still have your 300-page PDF from last Tuesday, ask away" will just be a normal feature.