0824 | Qwen 3.8: ingeniería inversa 30 min; JIT 5μs; malware en autos; Wi-Fi 8 sin velocidad

||Download

Show notes

En este episodio repasamos seis historias que circulan por la comunidad tecnológica. Empezamos con un Qwen 3.8 de 27 mil millones de parámetros que resolvió un trabajo de ingeniería inversa en unos treinta minutos, aunque los comentarios echan en falta el detalle del banco de pruebas y las herramientas usadas. Seguimos con el proyecto de compilar código just-in-time en unos cinco microsegundos, que abre el debate sobre si pgrust, la pieza más interesante, puede integrarse en el proyecto original

Línea de tiempo

  • 00:00:00 Apertura
  • 00:00:31 Un Qwen 3.8 27B termina una ingeniería inversa en 30 minutos
  • 00:01:39 Compilar JIT en 5 microsegundos y el futuro de pgrust
  • 00:03:06 Malware en el firmware de las unidades Android del automóvil
  • 00:04:28 Wi-Fi 8 deja de perseguir la velocidad
  • 00:05:29 El fin de un Athlon y un silicio desprendido
  • 00:07:07 La medalla de la maratón de Sídney muestra Múnich

Enlaces relacionados

Este episodio es producido por Bri. Bri usa tecnología avanzada de IA para convertir los feeds que te importan en podcasts pensados para escuchar. Puedes escribirnos a hi@bri.so.

Transcript

Clara Vega: Hola y bienvenidos a Hacker News diario, un programa de Bri Radio. Soy Clara Vega.

Mateo Ruiz: Y yo soy Mateo Ruiz. Hoy hablamos del modelo Qwen que resolvió un trabajo de ingeniería inversa en treinta minutos, de la compilación de código Java en cinco microsegundos y de un malware que infecta el firmware de los sistemas de infoentretenimiento de autos con Android.

Clara Vega: También repasamos el Wi-Fi 8, que no persigue la velocidad, el fin de una era del procesador Athlon según el OS/2 Museum, y la curiosa medalla del maratón de Sídney.

Mateo Ruiz: A Qwen 3.8, un modelo de veintisiete mil millones de parámetros, alguien le encargó un trabajo de ingeniería inversa y lo resolvió en unos treinta minutos, según circula en Hacker News. Lo que más llama la atención no es el resultado, sino la pregunta que dejó abierta.

Clara Vega: La plantea un comentarista con su propia configuración de hardware: tiene dos tarjetas Arc Pro B70 y hoy consigue unos veintidós tokens por segundo, que no es brillante pero tampoco terrible, en parte porque corre con menos cuantización. Le gustaría saber qué herramientas usó o quiso usar el modelo y cómo estaba montado el banco de pruebas.

Mateo Ruiz: Pero eso no está documentado en la discusión: ni el inventario de herramientas que invocó el modelo ni el armado del sistema aparecen en lo que circula. Así que lo único reproducido es la afirmación del autor sobre los treinta minutos junto con el interés de ese lector por replicar el entorno.

Clara Vega: Y ese es justamente el límite que separa una anécdota interesante de un dato reproducible. Con sus veintidós tokens por segundo sobre dos Arc Pro B70, el comentarista capta el punto: ese resultado depende de cuánta memoria, qué cuantización y qué herramienta le dejas tocar al modelo. Hasta que alguien publique el armado completo, lo que hay es una demostración puntual.

Mateo Ruiz: Hay una entrada reciente de Hacker News que vale la pena seguir: el autor Mališ para su proyecto de compilar código just-in-time en unos cinco microsegundos. Hasta ahí llega lo concreto, porque la conversación en la comunidad no termina en el rendimiento, sino en el propio enfoque técnico detrás del proyecto.

Clara Vega: Y esa discusión se calienta rápido. Un usuario destacado, glenjamin, llamó la atención sobre una pieza llamada pgrust, que se describe como muy interesante, pero apunta que los cambios son tan profundos que no hay un camino viable para integrarla río arriba en el proyecto original. La pregunta que le queda abierta es si pgrust se volverá lo bastante robusta como para lograr una adopción amplia.

Mateo Ruiz: Ahí está el pulso del hilo: por un lado el interés real en la pieza y por otro esa barrera estructural de no poder subirla al tronco oficial. Y luego aparece la otra voz, más escéptica. Un comentarista llamado FiberBundle responde directamente a ese entusiasmo y pregunta si de verdad es tan interesante, porque a su juicio el proyecto está, en esencia, hecho por gente con la técnica de vibe-coding, es decir, generando código guiado por modelos en lugar de un desarrollo escrito a mano y verificado.

Clara Vega: O sea que el hilo termina dividido entre quien ve mérito técnico real y quien lo descarta como código generado por modelo. Lo que no queda resuelto en la discusión es si esa impresión de vibe-coding está justificada por el código en sí, ni hacia dónde va pgrust.

Mateo Ruiz: Y es justo esa incertidumbre lo que deja el tema abierto: sin un camino de integración claro, la medida del éxito pasa a ser cuánta gente la adopta por su cuenta, y eso todavía no tiene respuesta.

Clara Vega: La firma de seguridad Kaspersky ha detectado un malware que infecta el firmware de las unidades de entretenimiento del automóvil, esas pantallas centrales que llevan Android integrado en el vehículo. La amenaza se esconde en el firmware de la propia unidad de cabecera, es decir, no se instala en el móvil, sino en el sistema del coche.

Clara Vega: Ahora bien, el análisis técnico de una unidad concreta deja claro que este tipo de dispositivo, en sí mismo, suele guardar pocos datos valiosos para un atacante. Por eso, uno de los escenarios de ataque más probables con un malware Android clásico pasa por reclutar esa unidad infectada para que pase a formar parte de una botnet, una red de dispositivos comprometidos que pueden usarse para lanzar ataques.

Mateo Ruiz: Pero hay un matiz importante que apunta a un riesgo mayor. En los comentarios de la discusión en Hacker News, un usuario señala que mucha gente empareja su teléfono con la unidad de cabecera del coche. Eso abre la puerta a que, en un futuro, una versión de este malware pudiera propagarse de forma lateral: saltar de la unidad del coche al teléfono emparejado. Es un escenario que todavía no se ha visto, pero que la práctica de emparejar dispositivos hace plausible.

Clara Vega: Y esa conexión con el móvil es justo lo que convierte a un sistema aparentemente sin valor en un punto de entrada interesante. El caso recogido por Kaspersky documenta la infección en el firmware; el salto lateral al teléfono sigue siendo una hipótesis, una dirección de evolución que los analistas anticipan a partir de ese vínculo habitual entre el vehículo y el móvil de la persona.

Clara Vega: El Wi-Fi 8 ya está tomando forma como el primer gran cambio inalámbrico en años que no va detrás de la velocidad pura. Y el punto, según el análisis que circula, es justo ese: en lugar de sumar más gigabytes por segundo, está pensado para atender lo que muchas redes domésticas realmente necesitan.

Mateo Ruiz: Mmm y eso se nota en la discusión cuando un usuario cuenta su caso: en su zona el máximo de velocidad ronda los 150 megabytes por segundo, así que un tope de 5 o 6 gigabytes por segundo le sobra de largo. Lo que en cambio sí le ha dolido es el alcance y la congestión en la red.

Clara Vega: Exacto, esa es la señal de hacia dónde apunta el cambio. Si la velocidad ya no es el cuello de botella para la mayoría, entonces la mejora que importa está en otra parte: que la señal llegue más lejos y que la red no se sature cuando hay varios dispositivos conectados al mismo tiempo.

Mateo Ruiz: Y eso es lo que convierte a esta generación en algo distinto. Claro que el Wi-Fi 8 sigue siendo una plataforma inalámbrica nueva con sus propios números, pero la lógica de diseño cambió el rumbo frente a los lanzamientos anteriores, que competían por marcar récords de transferencia.

Clara Vega: Cambiando de tema, Michal Necasek firmó en OS/2 Museum un artículo titulado “The End of an Athlon”, publicado el diez de agosto de 2026, con una historia peculiar: mientras investigaba bits CPUID extraños y mal documentados en procesadores Athlon MP y Athlon XP, tuvo que intercambiar muchos procesadores, hasta que uno le regaló una sorpresa. Al retirar el disipador de uno de esos Athlon XP, el procesador apareció con un trozo de silicio arrancado, y el fragmento quedó pegado al disipador.

Mateo Ruiz: Lo llamativo es que el procesador siguió funcionando bien hasta que se le desprendió una buena parte, y además retirar el disipador no requirió una fuerza especialmente excesiva, aunque algunos disipadores tienden a quedarse pegados. Su hipótesis es que existía una microgrieta larga y relativamente recta en el silicio que no afectó de forma perceptible al funcionamiento; cuando se aplicó fuerza, la grieta cedió y se desprendió todo un trozo grande. En la fotografía del daño, el lado derecho de la mella es muy recto, mientras que el izquierdo muestra marcas típicas de fractura.

Clara Vega: La explicación encaja con la época de esos procesadores: hacia el año 2000, tanto Intel como AMD usaron empaquetado flip-chip PGA para mejorar la refrigeración, en un momento en que el TDP superó rápidamente los 50 vatios y se acercó a los 70 u 80 vatios. Ese empaquetado dejaba el silicio expuesto, sin tapa protectora.

Mateo Ruiz: Y las dos compañías, especialmente Intel, abandonaron relativamente pronto ese tipo de empaquetado. Intel solo lo usó en algunos modelos de Pentium III y pasó a procesadores con tapa para la línea Pentium 4, así como para los PIII-S. AMD usó empaquetado flip-chip en los Athlon PGA, pero no en los Opteron.

Mateo Ruiz: La medalla de la maratón de Sídney salió con un error curioso: en lugar del estadio local, muestra el estadio Allianz de Múnich.

Clara Vega: Hoy existen siete estadios Allianz en el mundo, y quizá fueron ocho cuando se diseñó la pieza. Palmeiras no renovó el contrato de naming rights de su estadio, que pasó a llamarse Nubank Parque, así que probablemente ese octavo Allianz, el brasileño, seguía en la lista en ese momento. Un fallo fácil de cometer cuando el nombre se repite tanto.

Clara Vega: En resumen, Qwen 3.8 27B completó la ingeniería inversa en treinta minutos, y la compilación JIT corre en cinco microsegundos, aunque la pregunta abierta sigue siendo si pgrust podrá llegar alguna vez al repositorio oficial.

Mateo Ruiz: Sin duda. Gracias por acompañarnos hasta aquí, y nos escuchamos en la próxima.