0824 | Qwen 3.8 27B Reverse-Engineers in 30min, JIT 5μs, Android Malware, Wi-Fi 8 No Speed Focus

||Download

Show notes

A round-up of this week's tech and internet stories. A 27-billion-parameter Qwen model nails a reverse-engineering job in about half an hour, sparking a thread about harness details and real-world token throughput on consumer GPUs. A developer behind pgrust claims JIT compiling in five microseconds, but commenters split over whether the project can ever be upstreamed and whether the work is genuine engineering or vibe-coding. Kaspersky finds Android malware inside automotive head unit firmware,

Timeline

  • 00:00:00 Opening
  • 00:00:31 A local Qwen model reverse-engineers code in 30 minutes
  • 00:01:34 JIT compiling in five microseconds and pgrust's upstream question
  • 00:03:10 Malware targets Android car head unit firmware
  • 00:04:32 Wi-Fi 8 stops chasing speed and bets on reliability
  • 00:07:00 The end of an Athlon: a CPU that can't be repaired
  • 00:08:05 Sydney Marathon medal shows Munich's Allianz Stadium

Related links

This episode is produced by Bri. Bri uses advanced AI technology to turn the feeds you care about into podcasts made for listening. Contact us at hi@bri.so.

Transcript

Mia: Welcome to HackerNews Daily on Bri Radio. I'm Mia, and alongside me is Milo.

Milo: Hey everyone. Today we're looking at how an AI model took on a reverse-engineering job and finished in thirty minutes, plus compiling code in five microseconds.

Mia: Also on the slate: malware hiding inside Android automotive head unit firmware, Wi-Fi 8 and where it's heading, the end of an Athlon era, and a Sydney Marathon medal that shows the wrong stadium.

Mia: A developer going by the handle Qwen 3.8 handed a 27 billion parameter model a reverse-engineering job, and the model finished it in roughly thirty minutes.

Milo: The write-up landed on XDA Developers and made the Hacker News front page, where the standout comment came from someone running a dual Intel Arc Pro B70 setup. They wanted to know which tools the model reached for and how the harness was configured, and they also shared their own throughput: across those two Arc Pro B70 cards they're seeing around twenty-two tokens per second, which they call not great but not terrible, partly because the model runs at a lighter quantization.

Mia: So the useful thread buried in that discussion is less that a strong local model knocked out a reverse-engineering task quickly, and more the practical angle of how it handled that kind of job on comparable consumer hardware at a measured real-world speed.

Milo: There's a new post making the rounds on Hacker News about compiling code in five microseconds, and the author is the same person behind the pgrust project. The piece sits on a conversation about whether that kind of speed-up actually amounts to something durable, and the interesting friction is right there in the comments.

Mia: Yeah, and the sharpest exchange comes down to a real question about pgrust's path forward. One commenter notes that the deep changes mean there's no viable route to push it upstream, and asks whether the end goal is to get it robust enough for wide adoption.

Milo: That's the crux. If pgrust can't be upstreamed, it lives as a fork or an external project, and wide adoption means convincing a lot of users to run their Postgres against something that sits outside the core software path. So the whole value of that five-microsecond compile depends on how that question gets answered.

Mia: And not everyone in the thread even grants the premise. A second commenter pushes back and asks whether it's really interesting at all, describing the work as essentially vibe-coded by people. That undercuts the curiosity angle the original post is leaning on.

Milo: So you've got two different lines of doubt stacked on the same story. One is practical, about whether this ever becomes something people can adopt broadly, and the other is about the craft, whether the speed is a real technical achievement or the product of loose, vibe-driven engineering. Neither side settles it, but together they frame the whole discussion.

Mia: Security researchers at Kaspersky have found Android malware that targets the firmware of automotive head units, meaning the built-in infotainment systems in cars. One of the more likely attack scenarios, according to the coverage, is that classic Android malware infects the device to recruit it into a botnet, since a head unit typically holds nothing of value to an attacker on its own.

Milo: But that reasoning gets complicated by the way people actually use these systems. As one commenter on the Hacker News thread points out, drivers do pair their phones with head units all the time. So they're raising the possibility that future malware of this kind could propagate laterally, moving from the car's head unit to the phone that connects to it.

Mia: Right, and that's the part that shifts the threat model. A head unit sitting alone in a car may seem like a low-value target, but it becomes a stepping stone the moment it talks to a phone carrying contacts, banking apps, and credentials. That lateral movement path remains hypothetical for now, though, since the comment frames it as a conceivable future version rather than something this particular malware already does. The confirmed development is the malicious firmware infection itself, tracked in Kaspersky's analysis.

Mia: From a vulnerable car head unit over to the router in your living room — XDA's João Carrasqueira reports that Wi-Fi 8 is still in development and is shaping up as the first Wi-Fi generation in years that isn't chasing raw speed. The IEEE has actually dubbed it Ultra High Reliability, which tells you where the priorities have shifted.

Milo: That's a real departure. Since Wi-Fi 4, built on the 802.11n standard back in 2009, every generation pushed maximum theoretical data rates higher — Wi-Fi 5 alone multiplied the ceiling by more than ten times. Wi-Fi 7 tops out around 23 gigabits per band, which the article points out is already more than enough for the internet speeds most people actually have.

Mia: Right, so Wi-Fi 8 deliberately steps off that treadmill. It keeps roughly the same maximum data rate as Wi-Fi 7, along with the same spatial streams, the same 4096-QAM modulation, the same bands, and the same 320-megahertz channel bandwidth. Instead of raw speed, its stated goals target reliability under load: a 25 percent boost in throughput at different signal-to-interference-and-noise levels, a 25 percent cut in 95th-percentile latency, and a 25 percent reduction in MAC protocol data unit loss.

Milo: Mm, and the motivation points to crowded airtime. Since cellular networks are famous for juggling many connected devices at once, the Wi-Fi 8 effort focuses specifically on improving the experience when lots of Wi-Fi devices gather in the same area. It's an efficiency play over a speed play — and a new cited feature shows the mechanism, distributed-tone resource units, which let devices spread their transmissions across a wider range of bandwidth instead of crowding onto narrow slices.

Mia: The timing is interesting too. The article expects Wi-Fi 8 to be finalized in 2028, while 6G should arrive in the early 2030s. The official positioning actually pits Wi-Fi 8 directly against cellular, framing 6G as the likely competitor for much of Wi-Fi 8's life.

Mia: There's a story making the rounds on Hacker News about one of the early AMD Athlon processors and a failure that, from the discussion, doesn't look repairable. The write-up comes from the OS/2 Museum, and it's titled "The End of an Athlon."

Mia: In the thread, someone asks whether the thing could ever be fixed, assuming you had unlimited money and wanted to repair it rather than just buy a replacement. The reply is blunt about the odds: you'd need unlimited money and hyperadvanced future technology. The reasoning is that there's just no way to get things lined up again and no way to reconnect any of it, which pretty much closes the door on any practical repair.

Milo: So even a blank-check budget wouldn't buy a fix. That's a failure mode where the physical structures themselves are gone, not just a part you could source and swap in — and the discussion treats that as a dead end rather than an engineering problem worth chasing.

Mia: The Sydney Marathon handed out finisher medals with the wrong stadium on them — the design shows a venue that isn't Sydney's. The mix-up gets easier to understand once you learn there are seven Allianz Stadiums in the world, so the medal's architects had plenty of identical branding to pull from.

Milo: And it was probably an eighth Allianz venue back when the medal was being drafted. That one was Palmeiras' home ground in Brazil, which held the Allianz Paris name until Palmeiras didn't extend the naming rights contract and it became Nubank Parque. So the design likely happened at a moment when even more stadiums wore that same branding.

Mia: That broadens the pool of lookalike stadiums, though it doesn't fix the medal. After people flagged the error, the marathon organizers had to acknowledge the mix-up and decide how to handle the wrong designs that had already been produced.

Mia: Qwen 3.8 27B wrapped up that reverse-engineering job in thirty minutes, and the comments are clearly hungry for the full harness details.

Milo: And with JIT compiling down to five microseconds, the real open question stays whether pgrust can ever make it upstream.

Mia: Thanks for listening — we'll pick this back up next time. Take care out there.