Noticias

Character.AI, la app para conversar con personajes creados con inteligencia artificial, se ha declarado en quiebra. Su empresa, Character Technologies, se acogió el lunes 12 de octubre al capítulo 11 de la ley de quiebras de Estados Unidos para vender la compañía bajo supervisión de un juez. Ya tiene una primera oferta: Disney pagaría $20 millones de USD por una licencia de parte de su tecnología. La app sigue funcionando, pero la propia empresa avisa de que cerrará si ningún comprador se compromete a mantenerla.

Character.AI fue una de las estrellas de la primera ola de la IA generativa. La fundaron a finales de 2021 Noam Shazeer y Daniel De Freitas, dos exingenieros de Google; Shazeer es coautor del artículo que presentó la arquitectura Transformer, la base de los modelos de lenguaje actuales. En 2022 ya valía más de mil millones de dólares, y en 2024 Google pagó, según se publicó entonces, unos $2,700 millones de USD por una licencia de sus modelos y se llevó de vuelta a los dos fundadores. Ese año la app llegó a unos 20 millones de usuarios al mes, según TechCrunch.

Desde entonces, la empresa ha acumulado problemas. Afronta varias demandas de familias que acusan a sus chatbots de dañar a adolescentes, entre ellas la de la madre de un chico de 14 años de Florida que se quitó la vida. También la investiga Texas por la protección de los menores. Character.AI llegó a acuerdos en algunos casos, añadió medidas de seguridad y acabó cerrando el chat abierto a los menores de edad. Mantener conversaciones tan largas con un modelo de IA, además, cuesta mucho dinero en servidores.

Claves de la quiebra

• Qué es el capítulo 11. Es la vía de la ley estadounidense que permite a una empresa seguir funcionando mientras reorganiza sus deudas o se vende bajo control judicial, sin que los acreedores puedan embargarla. La petición, el caso 26-11603 del Tribunal de Quiebras del Distrito de Delaware, la firma el director ejecutivo, Colin Adams. Según TechCrunch, la empresa calcula que tiene entre $50 y $100 millones de USD tanto en activos como en deudas.
• Qué compra Disney. No la empresa ni la app, sino una licencia no exclusiva y perpetua de cierta propiedad intelectual y de ciertos derechos de reclamación de Character.AI, por $20 millones de USD. Además, prestará servicios de transición con antiguos empleados de Character.AI que ya trabajan en Disney, para que la plataforma pueda seguir funcionando de forma segura durante un tiempo. Según TNW, Disney fichó en septiembre a Karandeep Anand, hasta entonces director ejecutivo de Character.AI, como su primer jefe de tecnología.
• Una oferta de salida, no la definitiva. Disney actúa como primer postor (en la jerga, stalking horse): su oferta marca el precio mínimo y cualquiera puede mejorarla. La empresa pidió al juez que apruebe las reglas de la subasta y espera cerrar la venta a finales de noviembre o principios de diciembre.
• A quién debe. En la lista de sus mayores acreedores sin garantía, el primero es Google, con $4,148,944.00 USD en facturas pendientes. Le siguen el bufete Hogan Lovells, con $2,125,026.00 USD; el proveedor de servidores DigitalOcean, con $1,953,100.00 USD, y Fireworks.ai, una plataforma para ejecutar modelos de IA, con $813,900.00 USD, una deuda que figura como disputada.
• Qué pasa con los usuarios. La app y la web siguen abiertas, y las suscripciones de pago se mantienen sin cambios por ahora; la empresa promete avisar antes de tocar las funciones de pago. Quien quiera guardar sus conversaciones puede exportar sus datos o borrar la cuenta desde la app o la web.

Por qué importa

Character.AI es una de las primeras estrellas de la IA de consumo que acaba en quiebra, y su caso resume los dos grandes riesgos de este negocio. El primero es el coste: cuanto más enganchan los usuarios, más gastan en servidores, y la lista de acreedores lo refleja con Google, DigitalOcean y Fireworks.ai entre los primeros. El segundo es la responsabilidad. Las demandas por el daño a menores pesaron tanto como las cuentas, y la empresa habla en su comunicado de «importantes dificultades legales, regulatorias y operativas».

También muestra cómo cambian de manos los activos de la IA. Ni Google en 2024 ni Disney ahora han comprado la empresa: se han quedado con licencias de su tecnología y con su gente, y han dejado atrás la app, los usuarios y los pleitos. Para millones de personas que han creado personajes y conversaciones en la plataforma, la pregunta ahora es si alguien querrá quedarse con lo que queda.

Datos contrastados con la petición de quiebra presentada en el tribunal y con el comunicado de la empresa; historia y contexto de TechCrunch y TNW. Portada: entrada de la sede de The Walt Disney Company en Burbank (California), foto de Coolcaesar, Wikimedia Commons, CC BY-SA 3.0 (recortada, con texto).

Fuente: Character.AI, «An Update on Character.ai»

Microsoft publicó el martes 13 de octubre su paquete mensual de seguridad, el Patch Tuesday, y bate récords: según BleepingComputer y SecurityWeek, nunca había corregido tantas. Son más de 1,400 vulnerabilidades en Windows, Office, .NET, Azure y el resto de sus productos. Una de ellas, la CVE-2026-96951, ya se estaba aprovechando en ataques reales antes del parche: permite que un archivo descargado de internet se salte Mark of the Web, la marca con la que Windows avisa de que un archivo viene de fuera. Este parche también es el último para Windows 11 24H2 Home y Pro.

Microsoft publica sus correcciones de seguridad el segundo martes de cada mes. El boletín oficial de octubre reúne unas 1,760 entradas, pero unas 350 se habían publicado antes durante el mes, sobre todo de servicios de Azure, Exchange Server y Dataverse. Por eso cada medio da un total algo distinto: BleepingComputer cuenta 1,411 fallos publicados el martes, 70 de ellos críticos; Tenable, 1,407, y SecurityWeek, 1,413.

Según el recuento de BleepingComputer, casi la mitad son elevaciones de privilegios (677), 317 permiten ejecutar código a distancia, 254 revelan información, 73 provocan denegaciones de servicio, 40 se saltan alguna función de seguridad y 28 son de suplantación. Entre los críticos hay fallos de ejecución remota de código en los Servicios de dominio de Active Directory y en Azure App Service.

Claves del parche de octubre

• El fallo que ya se aprovechaba. La CVE-2026-96951 es una inyección de órdenes en el shell de Windows con una puntuación CVSS de 8.8. Microsoft explica que el atacante tiene que conseguir que la víctima abra un archivo preparado o pulse un enlace, por ejemplo en un correo o un mensaje. Si lo consigue, el archivo esquiva Mark of the Web: Windows lo trata como si no viniera de internet, sin el aviso de seguridad ni las protecciones que dependen de esa marca. Afecta a todas las versiones con soporte, desde Windows 10 1607 hasta Windows 11 26H2, y desde Windows Server 2012 R2 hasta Server 2025.
• Quién lo encontró. Microsoft reconoce a cuatro informantes: el investigador conocido como yhw, Riku Bamba y Yuya Chudo, de Fujitsu, y Benoit Sevens, que según el boletín lo encontró «usando Claude con Anthropic». Microsoft no da detalles de los ataques ni de quién estaba detrás.
• Dos fallos más, ya públicos antes del parche. La CVE-2026-108398, en .NET Framework, también tiene un 8.8. Requiere acceso local y, según BleepingComputer, permite saltarse el control de aplicaciones de Windows (WDAC). La descubrió James Forshaw, de Google Project Zero. La CVE-2026-92707, en la librería MessagePack-CSharp de .NET, puede tumbar un servicio a distancia y es de gravedad moderada. Ninguna de las dos se ha visto en ataques.
• La CISA pone plazo. La agencia de ciberseguridad de Estados Unidos añadió la CVE-2026-96951 a su catálogo de vulnerabilidades explotadas el mismo día 13 y da a las agencias federales hasta el 16 de octubre para parchear.
• Fin de soporte. Windows 11 24H2 en sus ediciones Home y Pro deja de recibir actualizaciones con este parche: quien siga en esa versión tiene que pasar a la 25H2 o a la 26H2. Según BleepingComputer, también es el último para Windows 10 Enterprise LTSB 2016, y Windows 11 23H2 Enterprise y Education tendrán su último parche en noviembre.

Por qué importa

Mark of the Web es una de las defensas más silenciosas y útiles de Windows. Es lo que hace que un documento de Office descargado se abra en modo protegido, con las macros bloqueadas, o que Windows avise antes de ejecutar un programa bajado de internet. Saltársela es un paso clásico en las campañas de correo malicioso: no da el control del equipo por sí solo, pero quita el aviso que habría frenado a la víctima. Por eso Microsoft la marca como «Importante» y no como crítica, y aun así es la que conviene instalar primero.

El crédito del fallo explotado también dice algo: uno de los investigadores lo encontró con Claude, el modelo de Anthropic. La IA ya forma parte del trabajo diario de quienes buscan vulnerabilidades, y paquetes de más de 1,400 correcciones dejan a administradores y usuarios con menos margen para aplazar los parches.

Datos contrastados con el boletín de seguridad de octubre de Microsoft (MSRC), el catálogo de vulnerabilidades explotadas de la CISA y el ciclo de vida de Windows 11 Home y Pro; recuentos de BleepingComputer, Tenable y SecurityWeek. Portada: portátil con la instalación de Windows, foto de I G, Wikimedia Commons, CC BY 2.0 (recortada, con degradado).

Fuente: Microsoft Security Response Center, CVE-2026-96951

Anthropic, la empresa que desarrolla Claude, contó el 13 de octubre en su blog de ingeniería que ha dejado de usar Git en su repositorio principal. Lo ha sustituido por Scion, un sistema de control de versiones propio. El motivo: desde que Claude escribe buena parte del código, las fusiones de cambios en ese repositorio pasaron de unas 2,500 al día en mayo a más de 30,000 en septiembre, y la infraestructura montada sobre Git no daba abasto. Siete personas hicieron la migración en cinco meses, con Claude escribiendo la mayor parte del código.

Como muchas grandes empresas, Anthropic guarda casi todo su código en un único repositorio gigante, un monorepo. Su historial ya ronda los 100 GB y una copia de trabajo comprimida pasa de 25 GB. Cada día, los sistemas de integración continua descargan el código unos 25 millones de veces: si cada descarga fuera completa, serían más de 600 petabytes diarios. Para aguantarlo, el equipo recurrió a todos los trucos conocidos de Git, como los clones superficiales, dispersos y parciales o las instantáneas precargadas, y llegó a mantener varios cientos de espejos internos del repositorio. Con cada salto en el ritmo de fusiones, esos espejos eran más difíciles de operar.

El problema de fondo, según Anthropic, es de diseño. Git nació para trabajar de forma distribuida y sin conexión: cada desarrollador tiene una copia completa y sincroniza cuando quiere. En Anthropic casi todos los clientes son agentes o tareas automáticas que están siempre conectados, así que usaban Git como un sistema centralizado, justo para lo que no fue pensado.

Claves de Scion

• El servidor hace el trabajo pesado. Los clientes están siempre conectados y el servidor calcula el historial, quién cambió cada línea (blame), los commits, las fusiones y los rebases. El cliente, llamado scn, solo guarda una caché limitada y coloca los archivos en el disco. Como todo se consulta por API, muchas tareas ni siquiera necesitan una copia local del repositorio.
• Cambios en lugar de árboles. La unidad de trabajo es el changeset, una entrada en un registro de escritura anticipada. En vez de apuntar al árbol completo de archivos, como hace un commit de Git, lista solo los archivos que cambian respecto a su padre. Los commits se hacen en el servidor, así que no hay nada que subir con push, y mover una rama es una operación atómica sobre una sola fila de la base de datos Spanner de Google.
• Tres niveles de servicio. Un proceso en cada máquina (scion-daemon), una caché regional en memoria (scion-cache) y el servidor de referencia (scion-server). Las descargas se pueden reanudar y no hay grandes paquetes de objetos ni mantenimiento del repositorio.
• Los resultados. Según Anthropic, Scion consume unas 200 veces menos CPU y memoria que los espejos de Git a los que sustituye, las descargas de código para CI y para investigación tardan segundos en lugar de minutos, la integración continua ganó un 25 % de capacidad de CPU y cada nivel de caché acierta más del 99 % de las veces.
• No llegó solo. En los mismos cinco meses, el equipo construyó Antique, una herramienta de revisión de código cuyas reglas distinguen, por ejemplo, un cambio que solo toca comentarios de uno que toca lógica delicada. También hizo un buscador de código, permisos por carpeta y procesos automáticos para localizar y revertir el cambio que rompe algo.
• Claude como programador principal. Los ingenieros pusieron la arquitectura y los objetivos de escala, y Claude escribió la mayor parte del código. El equipo reconoce que a menudo tuvo que decirle «no» cuando complicaba de más una pieza o se saltaba una restricción del sistema. Claude reescribió la herramienta que importa el historial de Git a Scion, que ahora usa 20 veces menos memoria y es 4 veces más rápida.

Por qué importa

Git lleva más de veinte años como la herramienta común de todo el que programa, y rara vez se cuestiona. Que una empresa lo abandone no es nuevo: Google y Meta tienen sistemas propios desde hace tiempo. Lo llamativo es la causa. Aquí no fue el número de ingenieros, sino el volumen de código que producen los agentes de IA: multiplicar por doce las fusiones diarias en cuatro meses es algo que ningún equipo humano consigue contratando gente.

Es un adelanto de lo que puede pasarles a otros equipos a medida que los agentes escriben más código. Los cuellos de botella se desplazan a la revisión, a la integración continua y al propio control de versiones. Anthropic deja claro que su caso es extremo, con un presupuesto de uso de Claude muy por encima del de cualquier empresa normal. Aun así, la idea de un servidor que hace el trabajo y clientes ligeros siempre conectados puede acabar llegando a herramientas como GitHub o GitLab. Y el propio proyecto es un ejemplo de lo que ya pueden hacer equipos pequeños con agentes: siete personas reemplazaron una pieza central de su infraestructura en cinco meses.

Si quieres entender cómo funciona Scion por dentro y en qué se diferencia de Git, lo explicamos en Qué es Scion, el control de versiones de Anthropic.

Datos tomados del artículo de Anthropic. Cobertura: The Register y Slashdot. Portada: código en un monitor, foto de Markus Spiske, Wikimedia Commons, CC0 (recortada, con degradado).

Fuente: Anthropic, «Redesigning source control at Anthropic»

Meta presentó el 12 de octubre Muse Wonder y Muse Wonder Full, a los que llama sus «modelos más capaces hasta la fecha». Están pensados para tareas de agente, de las que exigen muchos pasos seguidos: programar, revisar documentos legales o financieros, o resolver un trámite. Muse Wonder ya se puede usar por la API de Meta a $4.00 USD por millón de tokens de entrada y $20.00 USD por millón de salida; la versión Full solo está en los planes altos de su herramienta de programación, Muse Code. Ninguno de los dos se puede descargar.

Meta fue durante años la gran defensora de los modelos abiertos: los pesos de Llama se podían descargar y ejecutar en cualquier servidor. Con la familia Muse ha cambiado de estrategia. En septiembre presentó Muse Spark y su asistente de programación, Muse Code, y ahora sube un escalón con Wonder, que se mide directamente con los modelos más avanzados de OpenAI y Anthropic. Ni la nota de prensa ni la ficha técnica mencionan pesos o licencia, y el modelo solo se ofrece como servicio.

Los dos modelos aceptan texto, imágenes, vídeo y audio, responden en texto y admiten un millón de tokens de contexto, suficiente para leer de una vez un repositorio mediano o cientos de páginas de documentos. Meta destaca dos capacidades: Active Memory, que recuerda lo importante de una conversación a otra, y Active Focus, que sigue intentando otros caminos cuando una tarea se atasca y pregunta antes de hacer algo importante.

Claves de Muse Wonder

• Dos modelos, dos formas de acceso. Muse Wonder, con el identificador muse-wonder-1.0, está en la Meta Model API y en Muse Code. Muse Wonder Full, el más potente, no tiene precio por API: solo se usa dentro de Muse Code, con los planes Power y Maximum, que dan 20 y 80 veces el uso del plan básico. Meta no publica sus precios en la documentación; según VentureBeat, cuestan $50.00 USD y $200.00 USD al mes.
• Precio de la API. $4.00 USD por millón de tokens de entrada, $0.20 USD si la entrada está en caché y $20.00 USD por millón de salida. La búsqueda web se cobra aparte, a $2.50 USD por cada 1,000 consultas, y el límite es de 3,000 peticiones y 4 millones de tokens por minuto para cada equipo.
• Datos. Según VentureBeat, lo que se envía por la API en modo estándar no se usa para entrenar, mientras que en Muse Code el modo por defecto sí permite a Meta usar las instrucciones, el código y los resultados para mejorar sus modelos.
• Gana en código largo, pierde en terminal. En la gráfica de Meta, Wonder Full supera a sus rivales en DeepSWE y SWE-Marathon, dos pruebas de ingeniería de software de larga duración, pero queda por detrás en Terminal-Bench y en HealthBench Pro. En el índice independiente de Artificial Analysis, Wonder Full saca un 56, por delante de GPT-6 Astra y por detrás de Claude Opus 5.5.
• Seguridad. La ficha técnica reconoce que, sin sus salvaguardas, Meta no descarta que el modelo alcance el umbral de riesgo alto en química y biología, por lo que añadió entrenamiento de seguridad y clasificadores. En una prueba de explotación de vulnerabilidades, ExploitGym, Wonder Full capturó 92 banderas, pero solo 21 por el fallo que se pretendía probar: las otras 71, por fallos que nadie había previsto. El informe completo de seguridad llegará «pronto».

Cifras de la gráfica publicada por Meta, todas con el máximo esfuerzo de razonamiento, tal como las recogen VentureBeat y MarkTechPost. La ficha técnica advierte que mezclan resultados propios y de terceros: en SWE-Marathon los rivales usaron Codex y Claude Code, así que no es una comparación controlada, y Wonder Full se midió con un esfuerzo aún mayor.

Por qué importa

Con Wonder, Meta entra de lleno en la gama alta de la IA, y lo hace con las reglas de sus rivales: modelo cerrado, cobro por token y una versión superior reservada a suscriptores. Para quien construía sobre Llama porque podía alojarlo en sus servidores, el mensaje es claro: lo más potente de Meta ya no se descarga.

El precio también la coloca de lleno en la competencia, y las cifras recuerdan que «el mejor modelo» depende de la tarea: Wonder destaca en proyectos largos de programación y en trabajo legal, pero no lidera ni en el índice general de Artificial Analysis ni en las tareas de terminal. Como casi todas las comparaciones las ha elegido y presentado Meta, lo prudente es esperar a evaluaciones independientes antes de cambiar de proveedor.

Datos contrastados con el blog de Meta Research, la ficha técnica del modelo, la página de precios y límites y la de planes de Muse Code, además de VentureBeat y Artificial Analysis. Portada: entrada de la sede de Meta en Menlo Park, foto de LPS.1, Wikimedia Commons, CC0 (recortada y teñida).

Fuente: Meta, «Introducing Muse Wonder»

GitLab publicó el lunes 12 de octubre una versión de emergencia para todas las instalaciones propias: 19.4.2, 19.3.5 y 19.2.8, con 24 correcciones de seguridad. La más grave, la CVE-2026-97229, tiene la nota máxima del sistema CVSS, un 10.0. Es un desbordamiento de entero en el compilador de expresiones regulares del CI/CD que, según el aviso, podía permitir a un usuario sin cuenta ni sesión iniciada ejecutar código en el servidor con una expresión regular manipulada en la configuración de CI/CD. GitLab.com ya tiene la corrección; quien tenga su propio servidor tiene que actualizar.

GitLab es una de las plataformas más usadas para alojar código y automatizar su compilación y despliegue, y muchas empresas la instalan en sus propios servidores para no sacar el código de casa. Esa versión instalada, llamada self-managed, es la que recibe estas correcciones. La compañía publica parches de seguridad programados el segundo y el cuarto miércoles de cada mes, y versiones extraordinarias cuando aparece un fallo grave: la de este lunes es de las segundas.

No es la primera de este otoño. El 10 de septiembre GitLab corrigió otro fallo con un CVSS de 10.0, la CVE-2026-85706, un recorrido de rutas en la API de commits que permitía leer archivos del servidor sin autenticarse. Ese fallo acabó en el catálogo de vulnerabilidades explotadas de la CISA, la agencia de ciberseguridad de Estados Unidos, y GitLab tuvo que llevar la corrección también a las versiones 19.0 y 18.11, ya fuera de su política de mantenimiento.

Claves de la actualización

• Qué falla. Según GitLab, es un desbordamiento de entero en el compilador de expresiones regulares del CI/CD, causado por una validación insuficiente de las expresiones que recibe, y podía acabar en la ejecución de código arbitrario. Las expresiones regulares aparecen en la configuración de CI/CD, por ejemplo en las condiciones rules:if con =~, aunque GitLab no detalla por dónde entra la expresión del ataque. Lo descubrió el investigador joaxcar y lo comunicó por el programa de recompensas de HackerOne.
• Por qué un 10.0. El vector CVSS lo explica pieza a pieza: se ataca por la red, con poca complejidad, sin privilegios y sin que nadie haga nada; el daño va más allá del componente vulnerable (alcance «cambiado») y el impacto es alto en confidencialidad, integridad y disponibilidad. No se puede puntuar peor.
• Versiones afectadas. Todas las de la 19.2 anteriores a la 19.2.8, las de la 19.3 anteriores a la 19.3.5 y las de la 19.4 anteriores a la 19.4.2, tanto Community Edition como Enterprise Edition. En la rama 19.3 hay que ir a la 19.3.5: la 19.3.4 tenía un error en las páginas de merge requests con la integración de Ona activada.
• Hay otras 23 correcciones. Cinco son de gravedad alta: un XSS en el resaltado de sintaxis (8.7), un fallo de autorización que dejaba a un desarrollador lanzar pipelines en ramas protegidas (8.5), un envenenamiento de caché de archivos del repositorio que podía exponer variables protegidas de CI/CD (8.2), otro de autorización en las políticas de ejecución de pipelines (7.7) y una inyección de instrucciones en el agente de IA de GitLab Duo (7.3). Las otras 18 son de gravedad media o baja.
• Una pista en las notas. Las tres versiones incluyen dos parches para el motor de expresiones regulares de Ruby 3.3 y 3.4, el lenguaje en que está escrita la mayor parte de GitLab: uno sobre el tamaño del programa compilado de una expresión regular y otro sobre una doble liberación de memoria en las repeticiones. GitLab no los relaciona con la CVE, y el detalle de cada fallo no se publicará hasta 90 días después.
• La actualización tiene coste. Incluye migraciones de base de datos: en una instalación de un solo servidor habrá una parada mientras terminan, y en las de varios nodos se puede aplicar sin cortar el servicio siguiendo el procedimiento de actualización sin parada. GitLab Dedicated no necesita hacer nada.

Por qué importa

Un servidor de GitLab guarda mucho más que código: las variables secretas de los pipelines, las claves para desplegar en producción, los tokens de acceso a la nube y los registros de contenedores. Quien ejecuta código en ese servidor tiene, en la práctica, las llaves de toda la cadena de entrega de software. Por eso un fallo que no exige ni siquiera una cuenta es de lo peor que le puede pasar a una instancia expuesta a internet.

El precedente de septiembre es el motivo para no esperar. GitLab no ha dicho que este fallo se esté aprovechando, pero el anterior de nota 10.0 acabó en la lista de vulnerabilidades explotadas de la CISA, y GitLab tuvo que publicar reglas para detectar los intentos de ataque. Dos fallos de gravedad máxima en poco más de un mes, uno de ellos en algo tan básico como validar una expresión regular, recuerdan que alojar tu propio GitLab también significa encargarte de parchearlo el mismo día.

Datos contrastados con el aviso de la versión 19.4.2 y con los avisos anteriores de GitLab: el de la 19.3.2 (10 de septiembre), donde se corrigió la CVE-2026-85706, y el de la 19.0.9 (23 de septiembre), que la llevó a las ramas antiguas. Portada: técnico trabajando en un rack del NERSC, foto de Derrick Coetzee, Wikimedia Commons, CC0 (recortada y teñida).

Fuente: GitLab, «GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8»

Apple presentó este martes HomeView, su primera pantalla pensada para quedarse en casa: un dispositivo de 7 pulgadas con chip A18 que se coloca en la cocina o en la mesilla, o se cuelga en la pared, para escuchar música, hacer videollamadas y controlar las luces, las cerraduras y las cámaras. Reconoce por la cara a cada persona de la casa y es el gran escaparate de Siri AI, la nueva versión de su asistente. Cuesta $299.00 USD, se puede reservar desde hoy y llega el 13 de noviembre.

Las pantallas inteligentes para el hogar llevan casi una década en el mercado, con el Echo Show de Amazon y el Nest Hub de Google como referentes, y Apple era el único de los tres grandes asistentes que no tenía una. Hasta ahora, en su ecosistema, el centro de la casa era un HomePod o un Apple TV, sin pantalla propia para ver las cámaras o tocar un interruptor. HomeView llega junto a un HomePod mini nuevo, un Apple TV 4K de cuarta generación y una línea de accesorios propios, Apple Home Collection, en lo que Apple llamó su evento «Welcome home».

El equipo tiene una pantalla cuadrada de 1088 × 1088 píxeles unida por una bisagra de acero a una base con altavoces, y una versión para la pared con la misma pantalla. Su interfaz cambia con la distancia: desde el otro lado de la habitación muestra información simple y grande, y de cerca, más detalle. Cada miembro de la casa tiene su propia pantalla de inicio, y los mensajes o el calendario de cada uno solo aparecen cuando HomeView reconoce su cara y su iPhone está cerca y desbloqueado hace poco.

Claves de HomeView

• Pantalla y diseño. Liquid Retina de 6,98 pulgadas en diagonal, 220 píxeles por pulgada y brillo automático de 500 a solo 0,3 nits para que no moleste de noche. Cuerpo de aluminio en plata, blanco estelar, rosa y gris espacial, y 952 gramos en el modelo de mesa. El de pared viene en gris espacial y plata.
• Chip, cámara y sensores. Chip A18, cámara de 12 MP con Center Stage para FaceTime, cuatro micrófonos para hablarle desde lejos y sensores de luz, temperatura y humedad. Se conecta por Wi-Fi 6E, Bluetooth 6.0 y Thread.
• Sonido. Dos altavoces de rango completo en la pantalla, con audio espacial, y un woofer orientado hacia abajo con dos radiadores pasivos en la base. Funciona como un altavoz más junto a los HomePod y los equipos AirPlay de la casa.
• Siri AI. La nueva Siri, más conversacional, responde sobre casi cualquier tema y entiende lo que hay en pantalla. Con un iPhone o iPad compatible con Apple Intelligence también usa el contexto personal de cada usuario, como sus mensajes, su calendario o sus listas de Apple Music. Las peticiones se resuelven en el propio equipo o en los servidores Private Cloud Compute de Apple, que según la empresa no guardan los datos. En HomeView llega en beta.
• Hasta seis personas. Reconoce a seis usuarios por la cara, y cada uno tiene sus aplicaciones, widgets y contenido privado. Las fotos y la música compartidas las ve todo el mundo, invitados incluidos.
• Centro de la casa. Controla luces, termostatos, cerraduras, persianas y cámaras compatibles con Matter o con «Works with Apple Home», por voz o con el dedo. La esfera Home Camera muestra hasta nueve cámaras a la vez, y el equipo avisa al iPhone si oye una alarma de humo o de monóxido de carbono.
• Privacidad. La imagen de la cámara y el sonido de los micrófonos se procesan en Secure Exclaves, una zona aislada del chip A18. Según Apple, ni el sistema de HomeView ni las aplicaciones, el usuario o la propia Apple pueden acceder a esos datos.

Por qué importa

HomeView es la apuesta más clara de Apple por llevar su inteligencia artificial a la casa. Amazon y Google llevan años vendiendo pantallas baratas para tener su asistente en la cocina; Apple entra tarde y más cara, pero con algo que ellos no tienen tan integrado: el iPhone de cada persona. Al reconocer la cara de quien tiene delante y usar el contexto de su teléfono, la misma pantalla sirve para toda la familia sin mezclar los mensajes ni el calendario de nadie, uno de los problemas que estos aparatos nunca habían resuelto bien.

También es una prueba para Siri AI. El asistente ha sido durante años el punto débil de Apple frente a Alexa y Google Assistant, y la nueva versión llega aquí en beta, en un solo idioma y en ocho países. Un equipo pensado para hablarle desde el otro lado de la cocina depende por completo de que el asistente funcione, así que la acogida de HomeView dirá mucho de si la nueva Siri está lista.

Y confirma la apuesta por Matter, el estándar común de la domótica que impulsan Apple, Google, Amazon y Samsung: HomeView y Apple Home Collection funcionan con los accesorios de cualquier marca certificada. Para quien ya tiene la casa llena de dispositivos de otros fabricantes, esa es la mejor noticia del día. Para el público hispanohablante, sin embargo, HomeView tendrá que esperar hasta que Siri AI hable español.

Datos contrastados con la ficha técnica de HomeView y las notas de prensa de Apple sobre el HomePod mini 2, el Apple TV 4K y Apple Home Collection. Precios oficiales en EE. UU., sin impuestos. Fotos de HomeView: Apple.

Fuente: Apple Newsroom: Meet Apple HomeView

Este martes se abrió en el repositorio de Rust una incidencia que en pocas horas se convirtió en lo más comentado de Hacker News. Con un truco tan simple como crear un struct vacío y asignar después uno de sus campos, el compilador deja pasar una referencia que no cumple las reglas de vida del tipo. El resultado es un programa sin una sola línea unsafe que lee memoria ya liberada. El fallo está en el Rust actual, y en Compiler Explorer el mismo código compila desde Rust 1.4, publicado el 29 de octubre de 2015.

La promesa central de Rust es que el código seguro, el que no usa unsafe, no puede provocar errores de memoria: ni accesos a memoria liberada ni carreras de datos. Quien lo vigila es el borrow checker, la parte del compilador que comprueba que ninguna referencia viva más que el valor al que apunta. Cuando alguien encuentra una forma de engañarlo, el equipo lo llama un fallo de soundness y lo marca con la etiqueta I-unsound. No es la primera vez que ocurre: hay 140 incidencias abiertas con esa etiqueta, y la más famosa, la #25860, lleva abierta desde mayo de 2015.

La nueva, la #164250, la publicó un usuario a las 08:45 (hora UTC) con un ejemplo que guarda una referencia a un texto, lo libera y después imprime otro texto distinto que acabó en la misma memoria. En menos de una hora varios colaboradores habituales del compilador habían publicado variantes más cortas, una de ellas sin variables globales, y tras discutirlo en el chat del proyecto recibió prioridad alta. A las 13:41, los moderadores bloquearon los comentarios para evitar el spam. Todavía no hay ninguna corrección propuesta.

Claves del fallo

• Una restricción que se comprueba al crear, pero no al asignar. Un struct puede exigir que lo que guarda viva el tiempo suficiente; por ejemplo, struct Guarda<'a: 'static> solo debería admitir referencias que vivan durante todo el programa. Si se crea con el valor dentro, Guarda(Some(&x)), el compilador lo rechaza. Si se crea vacío y el campo se asigna después, g.0 = Some(&x), la vida de la referencia se deduce de esa asignación y la restricción del struct ya no se vuelve a comprobar.
• El daño lo hace un Drop. En todos los ejemplos publicados, el struct implementa Drop, el código que se ejecuta al destruir el valor. Ese código confía en la restricción del tipo, por ejemplo guardando la referencia en una lista global como si fuera eterna, y cuando se ejecuta la referencia ya apunta a algo que no existe.
• Desde 2015. El autor lo comprobó en las versiones estables hasta la 1.85, como mínimo; un colaborador encontró una variante que compila desde la 1.18, de 2017, y otro llevó la suya hasta la 1.4. En Compiler Explorer, esa última la rechaza Rust 1.3 y la acepta Rust 1.4, la 1.18 y las actuales.
• No depende de la asignación de campos. Otra variante llega al mismo sitio mezclando en un array dos valores del mismo struct y luego intercambiando sus campos, lo que apunta a un problema más general en cómo el compilador unifica tipos con restricciones de vida. Un colaborador lo relaciona con otra incidencia abierta desde julio de 2024.
• Sigue en las versiones actuales. Lo hemos reproducido en Rust 1.99, la versión estable publicada el 1 de octubre, y en las ramas beta y nightly.

Este es el fallo reducido a lo esencial, con nombres en español. La lista global solo admite referencias 'static, y el Drop de Guarda mete en ella la suya porque su tipo promete que lo es:

use std::sync::Mutex;

// Una lista global: solo admite referencias que vivan para siempre ('static)
static GUARDADAS: Mutex<Vec<&'static String>> = Mutex::new(Vec::new());

struct Guarda<'a: 'static>(Option<&'a String>);

impl<'a: 'static> Drop for Guarda<'a> {
    fn drop(&mut self) {
        if let Some(r) = self.0 {
            GUARDADAS.lock().unwrap().push(r); // el compilador cree que r es 'static
        }
    }
}

fn main() {
    {
        let nombre = String::from("Ana García");
        let mut g = Guarda(None);
        g.0 = Some(&nombre); // &nombre vive solo hasta la llave: debería ser un error
    } // aquí se libera `nombre`... y su referencia sigue en GUARDADAS
    let otra = String::from("¡memoria reutilizada!");
    println!("{}", GUARDADAS.lock().unwrap()[0]);
    drop(otra);
}

rustc --edition 2021 guarda.rs && ./guarda¡memoria r

Compila sin un solo aviso. Al ejecutarlo, en lugar de «Ana García», imprime el principio de otro texto. El texto de nombre ya se había liberado, el programa reutilizó esa memoria para otra, y la referencia guardada lee los 11 bytes que medía «Ana García». Es un comportamiento indefinido: según el sistema y el asignador de memoria podría imprimir basura o hacer que el programa falle, que es lo que pasó en otra de las variantes. Basta con cambiar una línea para que el compilador haga su trabajo:

let g = Guarda(Some(&nombre)); // error[E0597]: `nombre` does not live long enough

Por qué importa

Rust ha ganado su sitio en el núcleo de Linux, en Android, en Windows y en buena parte de la infraestructura de la nube gracias a esa garantía. Cada fallo de soundness no suele ser peligroso en la práctica, pero sí demuestra que la garantía depende de que el compilador no tenga errores, y un error que ha pasado casi once años sin que nadie lo viera recuerda que el borrow checker también es software.

Además, los ejemplos de hoy no son rebuscados. A diferencia de la #25860, que requiere combinar varias reglas avanzadas del sistema de tipos, este se reproduce con unas pocas líneas y una asignación que cualquier programador escribiría. Eso lo hace más fácil de aprovechar a propósito, por ejemplo en una dependencia maliciosa que quisiera parecer segura.

La corrección tampoco será trivial. Exigir que el compilador vuelva a comprobar las restricciones de vida cada vez que se asigna un campo o se unifican dos tipos puede hacer que deje de compilar código correcto que ya existe, así que el equipo de tipos tendrá que medir el efecto en el ecosistema, normalmente con una pasada de crater sobre todos los paquetes publicados, antes de cambiar nada. Hasta entonces, la incidencia #164250 se queda como la última prueba de que ningún compilador es perfecto.

Datos contrastados con la propia incidencia y su historial en la API de GitHub, la incidencia #25860, las notas de versión de Rust y Compiler Explorer, donde probamos el código en Rust 1.3, 1.4, 1.18 y 1.99, beta y nightly. Portada: módulos de memoria DDR, foto de Mixabest, Wikimedia Commons, dominio público (recortada y teñida).

Fuente: Incidencia #164250 del repositorio de Rust (GitHub)

El 21 de septiembre alguien subió seis commits maliciosos a la rama principal de Zod, la biblioteca de validación de datos más usada de TypeScript, con una credencial de git robada. Su mantenedor los revirtió ese mismo día y ninguna versión publicada en npm los llegó a incluir. El incidente se hizo público el 11 de octubre en las notas de la versión 4.6.6 y desde entonces circula por redes y medios de desarrolladores como un posible compromiso de Zod.

Zod permite describir la forma que deben tener unos datos, por ejemplo el cuerpo de una petición o la respuesta de un modelo de IA, y comprobar en tiempo de ejecución que la cumplen, con los tipos de TypeScript deducidos a partir de esa descripción. Lo usan frameworks, SDK de IA y miles de proyectos, y en npm se descargó más de 346 millones de veces solo la semana pasada. Esa popularidad lo convierte en un objetivo perfecto para un ataque a la cadena de suministro: quien consiga meter código en una versión de Zod lo ejecuta en millones de máquinas de desarrolladores y de servidores de integración continua.

Eso es exactamente lo que se intentó. Los commits aparecieron entre las 11:56 y las 15:16 (hora UTC) a nombre de «colinhacks», la cuenta de Colin McDonnell, creador de Zod, aunque sin firma verificada. A las 21:33, McDonnell fusionó la PR #6620, «Cleanup bad commits», que deshacía los seis, y más tarde reescribió el historial de la rama para eliminarlos. Las notas de la 4.6.6 lo cuentan en un párrafo y explican que la procedencia de esa versión apunta a una copia del commit anterior a esa reescritura, con el mismo contenido.

Claves del incidente

• Un script que se instalaba solo. El primer commit, titulado «Fix bugs and improve performance», añadía un archivo meta.test.mjs a los paquetes zod y @zod/mini, lo incluía en lo que se sube a npm y lo declaraba como preinstall, la orden que se ejecuta al instalar un paquete. Además, subía el número de versión a 4.6.6.
• Un servidor escondido en la cadena de bloques. El script no llevaba ninguna dirección de servidor. Consultaba un contrato de Ethereum a través de tres nodos públicos, sacaba de él una lista de dominios, pedía a cada uno un archivo y ejecutaba el código que recibía, para después borrar el rastro. Así, el atacante podía cambiar de servidor sin tocar el paquete y sin dejar un dominio fácil de bloquear.
• El objetivo era publicar sin pedir permiso. Los otros commits iban a por el proceso de publicación: uno quitaba la aprobación manual que exigía el entorno de npm en GitHub Actions, otro añadía un flujo que publicaba con un token en cada push a la rama principal y dos más subían la versión a 4.6.7 y 4.6.8.
• Nada llegó a npm. En el registro, después de la 4.6.5 del 13 de septiembre, la siguiente versión es la 4.6.6 del 11 de octubre. Esa versión y la 4.6.7, publicada hoy, se generaron en GitHub Actions con certificado de procedencia SLSA y no tienen ningún script de instalación.
• Publicar ahora necesita a una persona. Tres días después del ataque, la PR #6622 hizo que la integración continua ya no pudiera publicar: solo deja cada versión en una cola de espera de npm, donde no se puede instalar, hasta que un mantenedor la aprueba con doble factor. En palabras de la propia PR, una credencial robada que llegue a ese flujo «puede llenar una cola y nada más». La PR #6638, del 30 de septiembre, deja la ejecución en pausa en un entorno de aprobación durante un máximo de 30 días.
• La alarma vino del historial. El 11 de octubre, un usuario abrió la incidencia #6658 porque una auditoría de seguridad le marcó el commit malicioso dentro del historial de la 4.6.6. Otros usuarios señalaron enseguida que el código no está en el paquete de npm. A la hora de escribir esta nota, la incidencia sigue abierta y sin respuesta de los mantenedores.

Por qué importa

Los ataques a npm de los últimos años se han apoyado casi siempre en lo mismo: un token o una cuenta robados que permiten publicar una versión maliciosa en minutos, antes de que nadie lo note. En este caso la credencial robada solo daba acceso al repositorio, y la publicación todavía exigía una aprobación manual que el atacante intentó quitar en el propio repositorio. Esa capa de más bastó para que el ataque se quedara en el historial de git.

La respuesta de Zod va más allá: ya no hay ningún camino para que una máquina publique sola. La función de publicación en espera de npm convierte cada versión en una propuesta que un humano tiene que aprobar con su segundo factor, y eso cuesta poco cuando se publica unas pocas veces al mes. Es un modelo fácil de copiar para cualquier proyecto con muchos usuarios, que hasta ahora confiaba sobre todo en tokens y en la procedencia de la versión.

También deja una lección sobre cómo se comunican estos incidentes. Las notas de la 4.6.6 lo contaron en pocas líneas, tres semanas después, y sin aviso de seguridad. Las herramientas de auditoría, que miran el historial y no solo el paquete, lo encontraron por su cuenta, y lo que empezó como una buena noticia, un ataque detenido a tiempo, se difundió como un posible compromiso. Mientras los mantenedores no respondan a la incidencia #6658, la mejor forma de saber qué pasó es leer las notas de la versión y el propio registro de npm.

Datos contrastados con la PR #6620, las PR #6622 y #6638, la incidencia #6658 y el registro de npm. Portada: candado y cadena, foto de Dori, Wikimedia Commons, CC BY 2.5 (recortada y teñida).

Fuente: Notas de la versión 4.6.6 de Zod (GitHub)

Por primera vez hay relojes que miden el tiempo con el núcleo de un átomo y no con sus electrones. Dos equipos, uno de la Universidad Técnica de Viena con el instituto de metrología alemán PTB y otro de la Universidad Tsinghua de Pekín, publicaron el 7 de octubre en Nature sendos relojes basados en el torio-229. El de Viena funcionó más de 24 horas seguidas sin que nadie lo tocara; el de Pekín resultó unas seis veces más estable.

Un reloj, en el fondo, es algo que oscila a un ritmo constante y un mecanismo que cuenta esas oscilaciones. En los relojes atómicos lo que oscila es la luz o la radiación que hace saltar a los electrones de un átomo entre dos niveles de energía. Desde 1967 el segundo se define así, con átomos de cesio, y los relojes ópticos más modernos, que usan luz visible o ultravioleta, ya se equivocan menos de un segundo en toda la edad del universo. Pero los electrones están en la parte exterior del átomo y notan cualquier perturbación: campos eléctricos y magnéticos, cambios de temperatura.

El núcleo está mucho mejor protegido. Es más de diez mil veces más pequeño que el átomo y apenas reacciona a lo que pasa fuera. El problema es que sus saltos de energía suelen ser enormes, propios de los rayos gamma, y ningún láser puede provocarlos. El torio-229 es la excepción: tiene dos estados de energía tan próximos que basta un láser ultravioleta de unos 148 nanómetros para pasar de uno a otro. Llevaba décadas señalado como candidato a reloj nuclear, pero hasta abril de 2024 nadie había conseguido excitarlo con un láser. Lo lograron precisamente los grupos de Viena y del PTB, y en otoño de ese mismo año, junto con el JILA de Colorado, lo conectaron por primera vez a un reloj atómico óptico.

Faltaba el paso decisivo: que el núcleo de torio no fuera solo algo que se mide, sino lo que marca el ritmo del reloj. Es lo que publican ahora los dos equipos.

Claves de los dos relojes

• El corazón es un cristal. Ambos relojes usan un cristal de fluoruro de calcio con núcleos de torio-229 incrustados. En el de Viena mide un milímetro y funciona a temperatura ambiente, sin necesidad de enfriarlo ni de atrapar átomos uno a uno, como en los relojes ópticos.
• Un bucle que se corrige solo. Los núcleos solo absorben la luz del láser si su frecuencia es exactamente la correcta. Si el láser se desvía, aunque sea un poco por un cambio de temperatura, la absorción baja; el sistema lo detecta y reajusta la frecuencia. Así, el reloj de Viena no depende de un reloj atómico convencional para funcionar. La idea, explica Thorsten Schumm, que dirige el equipo de la TU Wien, es que sean los propios núcleos de torio los que estabilicen la frecuencia del láser.
• Más de 24 horas sin intervención. El reloj de Viena funcionó un día entero de forma continua. Para medir su calidad, su frecuencia se comparó todo ese tiempo con un reloj atómico de ion de iterbio. Tras un día de promedio, su inestabilidad se acercó a 10⁻¹⁵, que equivale a equivocarse en un segundo cada 30 millones de años.
• El de Pekín, seis veces más estable. El equipo de Tsinghua, dirigido por Ding Shiqian, genera su luz ultravioleta haciendo pasar láseres por vapor de cadmio y lee la absorción con un método rápido y con mucha señal frente al ruido. Con un segundo de promedio, su inestabilidad es de 5 × 10⁻¹³, frente a 3 × 10⁻¹² del de Viena: seis veces menor.
• Dos cristales, la misma hora. Pekín probó su reloj con dos cristales fabricados por separado, y sus frecuencias coincidieron con una diferencia de una parte en 10 billones (10⁻¹³). También encajan con medidas anteriores en otros cristales. Es una prueba de que el reloj no depende de un cristal concreto, algo imprescindible si algún día se fabrican en serie.
• Una primera búsqueda de materia oscura. El equipo de Viena aprovechó el reloj para buscar materia oscura ultraligera, que haría variar levemente la energía del salto del torio en plazos de entre 20 segundos y un día. No encontró señal, pero los límites que fija compiten con los de los mejores relojes atómicos y mejoran los anteriores en algunos tipos de interacción.

Por qué importa

Los relojes atómicos son una infraestructura invisible: el GPS calcula tu posición a partir de diferencias de tiempo de millonésimas de segundo, las redes de telecomunicaciones y los mercados financieros se sincronizan con ellos, y los mejores relojes de laboratorio sirven para comprobar las leyes de la física. Un reloj que funciona con un cristal a temperatura ambiente, sin trampas de átomos ni vacío extremo, apunta a algo que hoy no existe: relojes de altísima precisión compactos y robustos, que se puedan sacar del laboratorio.

El torio-229 tiene además una sensibilidad especial. Su salto de energía depende del equilibrio entre la fuerza nuclear fuerte y la electromagnética, así que, si alguna constante de la naturaleza variara mínimamente, o si la materia oscura interactuara con la materia normal, este reloj lo notaría mucho antes que uno atómico. La primera búsqueda ya da límites competitivos con un prototipo de un día de funcionamiento.

Que el mismo hallazgo llegue a la vez desde Europa y desde China, con dos técnicas distintas, también dice algo: la carrera por el reloj nuclear ha empezado en serio. El equipo de Viena ya trabaja en láseres más potentes y mejores cristales, y el de Pekín ha demostrado que el resultado se puede reproducir. El siguiente hito será que un reloj nuclear iguale, y después supere, a los mejores relojes atómicos.

Datos contrastados con los resúmenes de los dos artículos en arXiv: «A thorium-229 optical nuclear clock with feedback loop» (TU Wien y PTB) y «A nuclear clock synchronized to ²²⁹Th» (Universidad Tsinghua), ambos publicados en Nature. Portada: láseres alrededor de la cámara de vacío del reloj atómico de estroncio en tres dimensiones del JILA, foto del NIST, Wikimedia Commons, dominio público (recortada).

Fuente: TU Wien, «Die erste selbststabilisierende Atomkernuhr tickt in Wien» (idw)

Todo el equipo de Deno, empezando por su creador, Ryan Dahl, pasa a trabajar en Cloudflare. El anuncio, del 9 de octubre, viene con fecha de caducidad para casi todo lo que la empresa había construido: el runtime de Deno recibirá correcciones durante un año más y después dejará de desarrollarse, y el servicio de alojamiento Deno Deploy cerrará dentro de seis meses.

Deno nació de un arrepentimiento. En 2018, en la conferencia JSConf EU, Ryan Dahl, que años antes había creado Node.js, dio una charla sobre las decisiones de diseño de Node que ya no volvería a tomar, y presentó un runtime nuevo para corregirlas: escrito en Rust sobre el motor V8, seguro por defecto, sin acceso a la red ni a los archivos salvo permiso explícito, y con TypeScript de serie. Deno 1.0 llegó en 2020 y Deno 2.0, en 2024, con compatibilidad con los paquetes de npm. Alrededor del runtime, la empresa montó Deno Deploy para ejecutar código en la nube y el registro de paquetes JSR.

Cloudflare jugaba en el mismo terreno con Workers, su plataforma para ejecutar JavaScript en sus centros de datos repartidos por todo el mundo. En 2022 publicó como código abierto workerd, el runtime de Workers, después de que clientes grandes como Shopify le dijeran que no podían construir sobre una plataforma de la que no tuvieran salida. Y en agosto de este año el equipo de Deno publicó celld, su propia implementación del modelo de Workers pensada para ejecutarlo en servidores propios.

Ese es el punto de encuentro. Según el comunicado que firman juntos Ryan Dahl y Kenton Varda, de Cloudflare, el objetivo es fusionar celld con workerd para que montar aplicaciones distribuidas en infraestructura propia sea, en sus palabras, «radicalmente fácil». Ninguno de los dos anuncios habla de importe ni de condiciones de la operación.

Claves del anuncio

• El runtime, un año más. Deno seguirá recibiendo una versión al mes con correcciones de errores y de seguridad durante un año. Pasado ese plazo, Cloudflare dejará de desarrollarlo. El código seguirá siendo abierto, y Dahl invita a quien quiera a continuar su desarrollo.
• Deno Deploy cierra en seis meses. El servicio de alojamiento seguirá funcionando medio año y después se apagará. Los clientes de pago tendrán ayuda para migrar a Cloudflare Workers.
• JSR sigue. El registro de paquetes continuará funcionando y su infraestructura pasará a Cloudflare.
• celld se funde con workerd. celld es un único programa escrito en Rust cuya única dependencia externa es un almacenamiento de objetos. Para usarlo basta con levantar varias instancias y un bucket. Cloudflare llevará su código y sus ideas a workerd.
• Durable Objects en servidores propios. Es lo que le faltaba a workerd. Un Durable Object es, como lo define Dahl, un «singleton distribuido con una base de datos SQLite»: un objeto que existe una sola vez en todo el sistema, por ejemplo uno por cada canal de un chat, con su propio estado y sus conexiones WebSocket. Cloudflare lo usa por debajo de servicios como sus colas o su almacén KV, pero en workerd solo funcionaba con una instancia, suficiente para pruebas en local y no para producción. Varda reconoce que un intento de resolverlo la primavera pasada no salió bien.
• Quién lo dirige. Ryan Dahl y Bert Belder, cofundador de Deno, encabezarán el trabajo para que el autoalojamiento de workerd sea una forma de primera clase, con soporte, de ejecutar aplicaciones con el modelo de Workers. Cloudflare también seguirá manteniendo rusty_v8, la capa que une V8 con Rust, y la integrará en workerd.

Por qué importa

Es el final de una de las alternativas a Node.js más conocidas. Durante ocho años Deno empujó ideas que acabaron en el resto del ecosistema: permisos explícitos, TypeScript sin configuración, APIs web estándar como fetch en el servidor. Ahora su equipo deja de competir por el runtime y se pone a construir sobre el de Cloudflare. Quien haya apostado por Deno en producción tiene un año para decidir si sigue con un proyecto mantenido por la comunidad o si migra.

Para Cloudflare la jugada va en otra dirección. Su gran argumento de venta es su red, y aun así su mayor esfuerzo aquí es que su modelo de programación funcione fuera de ella. Varda lo explica sin rodeos: algunos de sus clientes más grandes no habrían firmado sin una salida de emergencia. Un Workers que se pueda instalar en servidores propios, con Durable Objects de verdad, hace que construir sobre Workers deje de ser una apuesta por un único proveedor. Y Dahl lo presenta pensando en los agentes de IA, que necesitan ejecución barata, estado persistente y conexiones abiertas, justo lo que ofrecen los Durable Objects.

Quedan preguntas sin respuesta: qué pasará con el framework Fresh, la biblioteca estándar o Deno KV, que ninguno de los dos comunicados menciona, y si alguien recogerá el desarrollo del runtime cuando Cloudflare lo suelte. Ambas empresas prometen más anuncios en los próximos meses.

Datos contrastados con el comunicado de Ryan Dahl en el blog de Deno, del 9 de octubre de 2026. Portada: sala de servidores de BalticServers, foto de BalticServers.com, Wikimedia Commons, CC BY-SA 3.0 (recortada y teñida).

Fuente: Cloudflare Blog, «Deno is joining Cloudflare»