WinUI 3 al Desnudo: De los Handles de Windows al Renderizado Moderno

Explora la historia y arquitectura de WinUI 3. Desde los límites de handles en Win32 y el drama de WPF hasta el moderno renderizado con DirectX y async/await.

Este texto ha sido generado por Gemini 2.5/3.1 a partir del audio del autor. El contenido y las ideas son íntegramente del autor; la redacción ha sido asistida por IA.

¿Qué pasa, patáticas mías? Aquí vuestro reportero maricharachero para continuar con la serie sobre WinRT. Hoy nos sumergimos de lleno en WinUI 3, y os adelanto que todo lo que os conté sobre WinRT sigue siendo perfectamente válido, porque WinUI no es más que la aplicación práctica de toda esa tecnología para construir las interfaces gráficas de las aplicaciones modernas.

Un Viaje al Pasado: Win32, Handles y los Primeros Frameworks

Para entender WinUI, hay que retroceder. Frameworks como Windows Forms eran, en esencia, una capa relativamente fina que envolvía los componentes nativos de Windows: el botón, el cuadro de edición, el checkbox… todo. Nos abstraían del famoso «handle de ventana» o HWND.

Aquí viene la anécdota para los más jóvenes. En el viejo Win32, todo, absolutamente todo, era una ventana. Por eso se llama Windows. Un simple campo de texto era una ventana con su propio handle. Esto tenía una consecuencia brutal: Windows tenía un número limitado de handles gráficos, unos 65.536.

¿Qué significaba esto? Que si abrías una aplicación gráficamente intensa como el viejo Borland C++ Builder, con sus toolbars llenas de iconitos (cada uno una ventana), y luego abrías otra similar, podías agotar los handles. El resultado era que los gráficos no se veían, o peor, la aplicación reventaba. La única solución era cerrar programas o, en el peor de los casos, reiniciar Windows. ¡Ah, los maravillosos años 90!

La Guerra Civil de Microsoft: La Tumultuosa Llegada de WPF

Luego llegó WPF (Windows Presentation Foundation), que en sus primeras versiones seguía dependiendo de este sistema de handles. Aunque introdujo una capa muy potente encima, con XAML y un sistema de layout que nos ahorraba los cálculos manuales que sufríamos en MFC, su nacimiento fue… complicado.

Cuando Microsoft decidió que la interfaz de Visual Studio debía rehacerse en WPF, se topó con un muro. El equipo de Visual Studio, de los pocos sin pelos en la lengua, les dijo sin rodeos que aquello era «una puta mierda pinchada en un puto palo de mierda». Y tenían razón. Yo mismo, en media hora, reporté 7 u 8 bugs gravísimos en la primera versión. Esas demos espectaculares de Microsoft eran humo; en la práctica, nada funcionaba.

Tras una buena ración de «arrojo de boñigas de mierda» interno, Microsoft se puso las pilas y arregló WPF. La primera versión de Visual Studio con WPF fue lenta y tosca, pero las siguientes mejoraron hasta el punto de que, a partir de .NET Framework 4.7, funciona francamente bien.

El Problema de Estar Atado al Sistema Operativo

¿Cuál fue la solución mágica para arreglar WPF? Integrar su motor directamente en el núcleo de Windows. Las DLLs que antes venían con el instalador de .NET Framework ahora formaban parte del propio sistema operativo. Esto solucionó los problemas de rendimiento, pero creó uno nuevo y gigantesco.

Cada vez que necesitaban corregir un bug o añadir una mejora a WPF, tenían que lanzar una actualización completa de Windows. Esto era insostenible. ¿Recordáis esas actualizaciones de .NET Framework que tardaban una eternidad en instalarse? Probablemente se debían a esto. El sistema estaba recompilando y optimizando el código para tu máquina específica, un proceso lento y pesado.

Nace WinUI 3: La Independencia del Framework

La necesidad de agilidad, especialmente con la llegada de las apps de la tienda de Windows (UWP) y el problema de una ABI (Application Binary Interface) fija, obligó a Microsoft a cambiar de estrategia. Usando la misma tecnología de componentes COM que vimos en WinRT, decidieron sacar el motor de UI fuera del núcleo de Windows.

Así nació WinUI 3. Es, en esencia, la evolución de WPF desacoplada del sistema operativo. Este proceso, como era de esperar, no fue trivial y trajo nuevas ineficiencias. Al tener que comunicar entre el espacio de usuario (anillo 3) y el kernel (anillo 0), se introdujo una latencia que lo hizo más lento en ciertos aspectos.

El Motor de WinUI 3: Dos Hilos y Mucho DirectX

La arquitectura de WinUI 3 es un batiburrillo interesante de tecnologías: Win32, WinRT y, sobre todo, DirectX. Por ahí leí una descripción que sonaba a «método cuántico arquitectónico indispensable», pero en cristiano, se basa en un modelo de dos hilos para lograr su rendimiento.

Por un lado, está el hilo de la UI (UI-Thread), que se encarga de procesar la lógica, ejecutar el código XAML y componer el árbol visual de lo que se va a mostrar. Aquí entran en juego optimizaciones clásicas de Windows, como las áreas de recorte, que evitan redibujar lo que no es necesario.

Una vez compuesto el «qué» se va a pintar, se le pasa el trabajo al hilo del compositor (Compositor-Thread). Este segundo hilo se comunica directamente con el hardware a través de DirectX para renderizar la escena en la pantalla. Esta separación es la clave de su rendimiento en aplicaciones gráficamente intensas, ya que el dibujado no bloquea la lógica de la aplicación.

Adiós al Invoke: Async/Await al Rescate de la UI

Un principio sagrado en el desarrollo de UI es mantener el hilo principal lo más libre posible para que la aplicación siempre responda. Antiguamente, si estabas en un hilo secundario y querías actualizar un texto en la pantalla, tenías que usar Invoke o BeginInvoke para enviar esa orden de vuelta al hilo principal.

WinUI 3, junto con las versiones modernas de C#, simplifica esto drásticamente gracias a async/await. Ahora, desde un método asíncrono, puedes modificar un elemento de la interfaz directamente. El compilador y el framework se encargan por arte de magia de gestionar los hilos y las máquinas de estado para que todo funcione sin bloquear la UI. Se acabó el Invoke.

La Experiencia del Desarrollador: Sin Diseñador Visual pero con Hot Reload

Un cambio importante para los que venimos del mundo clásico es que en WinUI 3 no hay un diseñador visual de XAML en Visual Studio. Si abres un fichero y no ves la vista previa, ya sabes que estás en el mundo moderno.

El flujo de trabajo ahora se basa en ejecutar la aplicación y modificar el XAML en caliente usando la función Hot Reload. Le das a recargar y los cambios aparecen al instante en la ventana. Bueno, en teoría. A veces funciona y a veces no, sobre todo si tocas cosas del patrón MVVM, obligándote a volver al método clásico de cerrar, recompilar y ejecutar.

Conclusión

Y este ha sido nuestro viaje por las entrañas de WinUI 3. Como veis, es el resultado de décadas de evolución, dramas internos en Microsoft y una búsqueda constante por un framework de UI potente y desacoplado. Mucho de esto es historia que he vivido, y otra parte es conocimiento que le he sonsacado a Gemini para complementar mis batallitas.

Por cierto, no he querido dejarme fuera la caótica gestión de versiones de .NET Core, con sus múltiples ABIs incompatibles y esa manía de dejar instaladas 50 versiones en el sistema. Es otro de esos detalles que forman parte de la historia de esta tecnología. ¡Espero que esta explicación os haya aclarado el panorama y os haya entretenido! ¡Adiós, mis pataticas!

De COM a WinRT: La tortuosa evolución de la interoperabilidad en Windows

Analizamos la evolución desde los objetos COM y sus ficheros IDL hasta WinRT, pasando por las simplificaciones de C# y los desafíos de la interoperabilidad en C++.

Este texto ha sido generado por Gemini 2.5/3.1 a partir del audio del autor. El contenido y las ideas son íntegramente del autor; la redacción ha sido asistida por IA.

En el audio anterior os conté todo el paripé que había que hacer para acceder a un objeto COM (Common Object Model). Hoy vamos a profundizar en esa historia, viendo cómo hemos evolucionado desde un sistema engorroso hasta las promesas de WinRT.

El engorroso mundo del COM clásico

Cuando querías usar un objeto COM, el compilador de C# se enfrentaba a un proceso complejo. Curiosamente, en su día, Borland tenía esto bastante mejor resuelto, aunque también fallaba más. Cada objeto COM venía con un fichero IDL (Interface Definition Language) que describía qué hacía, cómo cargarlo y cómo traducir las llamadas desde tu código al código nativo del objeto, que generalmente estaba en C++.

El compilador procesaba este fichero IDL y generaba una serie de clases «envolventes» para facilitar el manejo de la interfaz. Sin embargo, mucho trabajo seguía siendo manual. Tenías que llamar a IUnknown, gestionar punteros y liberar memoria explícitamente. Era un sistema lento, basado en punteros a punteros, y si se te olvidaba liberar algo, los problemas eran horrorosos. Digamos que era una solución a medio hacer.

Una de las funcionalidades interesantes era la integración de menús. Si tu aplicación Win32 o MFC tenía un menú «Archivo», el menú «Archivo» de un componente Office, como Word, podía fusionarse con el tuyo, mostrando tus opciones y las de Office. Un detalle curioso que demuestra el nivel de integración que se buscaba.

C# llega al rescate (parcialmente)

Con la llegada de C# y el framework .NET, las cosas se simplificaron enormemente. Cualquier clase de C# (o Visual Basic .NET) puede marcarse como COMVisible, y automáticamente está disponible para ser usada por otras aplicaciones. De C# a C# la integración es transparente y casi instantánea. Al añadir la referencia a tu proyecto, el sistema de reflexión te permite ver y usar todas las clases y métodos públicos sin esfuerzo.

El lenguaje se encarga de toda la fontanería por debajo, gestionando los IUnknown y las referencias por ti. Esto es una capa de abstracción potentísima que permite que tu componente funcione sin importar si se ejecuta en un servidor remoto, en un procesador ARM o en un x86. En teoría, claro, porque en la práctica siempre surgen problemas.

El problema persistente con C++ nativo

Pero, ¿qué pasaba si querías acceder a ese objeto COM hecho en C# desde C++ nativo? Volvíamos al punto de partida. Había que generar un fichero (en este caso, WinMD) que, a través de una herramienta como MIDL.exe, creaba las clases de envoltorio para C++. Y aquí empezaban los dolores de cabeza.

MIDL.exe estaba lleno de bugs. A veces, si usabas un objeto en C# que la herramienta no conocía, generaba mal las clases. El código compilaba, el IntelliSense no daba pistas, pero en tiempo de ejecución, al llamar a esa parte mal definida, el programa reventaba. Era algo muy parecido a los clásicos «Runtime Error» de Visual Basic. Si además querías usarlo desde Pascal, un COBOL moderno o JavaScript, el proceso era el mismo: crear envoltorios y cruzar los dedos.

WinRT: ¿La solución definitiva?

Aquí es donde entra en juego WinRT. Es el siguiente paso evolutivo, una interfaz COM gestionada a través de ficheros WinMD que define lo que se conoce como una ABI (Application Binary Interface) estática y bien definida. Esto es fundamental en tecnologías como .NET Core. El IUnknown sigue existiendo, pero el sistema es mucho más moderno.

Para C++, WinRT se presenta como un conjunto de plantillas en ficheros de cabecera, lo que significa que no hay sobrecarga de código. Microsoft promete que es súper rápido, que la adaptación es automática y que la liberación de memoria también es automática. Se acabaron los punteros manuales. Es, en esencia, la siguiente generación de COM, diseñada para ser súper fácil de usar.

Un paréntesis técnico: El ‘Name Mangling’

Para entender por qué una ABI estática es tan importante, hay que hablar del name mangling en C++. C++ no es un lenguaje de objetos en su ejecución final; simula la orientación a objetos pasando un puntero oculto (this) a las funciones. Si tienes un método HazPityCoreDeVoyne en la clase A y otro con el mismo nombre en la clase B, ¿cómo sabe el compilador a cuál llamar?

Lo que hace es cambiar los nombres internamente a algo como HazPityCoreDeVoyneClaseA y HazPityCoreDeVoyneClaseB. Este proceso, el name mangling, varía con cada compilador e incluso con cada versión. Si creas una DLL con Visual Studio 2017, puede que no sea compatible con una compilada con Visual Studio 2019 o con el compilador de Intel. WinRT soluciona esto al establecer una ABI fija y universal, simplificando radicalmente la interoperabilidad.

El escepticismo de siempre: El historial de Microsoft

La idea de WinRT es absolutamente genial. El problema, para mí, es que me da mucho repelús. Es el siguiente paso en la saga de las APIs para la tienda de Windows. Primero tuvimos Silverlight, luego las apps de la tienda, después UWP… y ahora WinRT. Todas las anteriores llegaron llenas de bugs y problemas.

Microsoft es famosa por tener ideas maravillosas y luego tardar años en pulir la implementación. Justo cuando algo se vuelve estable, deciden cambiarlo. Prometieron una API estática con .NET Core y creo que ya van por la tercera versión de esa promesa «para siempre». Conociéndolos, aunque digan que van a mejorar WinUI y WinRT, me temo que será más de lo mismo.

Conclusión: Una idea brillante, una implementación incierta

WinRT está diseñado para funcionar con .NET y se puede usar desde C++ nativo simplemente incluyendo una cabecera. La sintaxis puede ser un poco barroca, pero es funcional. Es importante aclarar que WinRT no sustituye a Win32; es una capa de abstracción muy rápida que corre por encima y termina haciendo llamadas a Win32.

La idea es chula, pero la práctica ya la veremos. O mejor dicho, ya se verá, porque yo personalmente no creo que lo use. Por lo menos, ahora ya sé qué es y cómo funciona. Ya veremos si esta vez Microsoft consigue una implementación robusta desde el principio.

Y con esto cerramos el capítulo de WinRT. En el próximo audio hablaremos sobre WinUI, pero eso será otra historia. ¡No olvidéis sospechosos, habitualizaros! Adiós.

2006IIP – Qué es WinRT (I de II)

Descubre los orígenes de WinRT explorando su predecesor, el complejo y lento modelo COM de Microsoft. Una historia de desarrollo, errores y reinicios.

Este texto ha sido generado por Gemini 2.5/3.1 a partir del audio del autor. El contenido y las ideas son íntegramente del autor; la redacción ha sido asistida por IA.

¿Qué pasa, patáticas mías? Aquí vuestro reportero maricharachero de barrio, Sésamo. Sí, hoy toca un nuevo saludo, «patáticas», que no sé cuánto durará, quizás un par de programas o quizás este sea el único. Hoy nos adentramos en un tema técnico que surgió del audio anterior, donde hablaba de las promesas de Microsoft para mejorar su sistema operativo.

El plan es hablar de WinRT y WinUI 3, pero son dos bestias muy diferentes, así que iremos por partes. Empezaremos por la de más bajo nivel: WinRT. Como no lo tenía del todo claro, le pedí a Gemini que me preparara un informe en profundidad, y ahora que lo entiendo, os lo voy a explicar. Pero para entender qué es WinRT, primero tenemos que hacer un viaje en el tiempo.

Un viaje al pasado: Corva, DDE y el nacimiento de COM

Si sois desarrolladores con solera, de los viejos como yo, seguramente os suenen términos como Corva, DDE o las aplicaciones COM. Hubo una época en la que se pusieron de moda los sistemas de objetos, una idea adelantada a su tiempo que buscaba que las librerías y componentes de software se autodescribieran.

La teoría era fantástica: tener una «caja negra» universal que un programador pudiera usar sin importar la plataforma (Solaris, Windows, Linux), la arquitectura o cualquier otro detalle. La funcionalidad debía ser agnóstica. Sin embargo, en la práctica, era una chorrada, porque como programador, sigues necesitando saber qué hacen esas librerías para poder usarlas correctamente.

Microsoft contraatacó a estas tendencias primero con DDE y luego con su propio protocolo: COM (Common Object Model). La idea de COM también estaba adelantada a su tiempo, pero a diferencia de otras, esta sí que funcionaba, aunque con matices importantes que veremos más adelante.

Entendiendo COM con una metáfora: el portátil y el dock

Para que entendáis el concepto de COM, olvidemos el código por un momento y pensemos en una metáfora. Imagina que tu aplicación es un «dock» de escritorio y un objeto COM es un ordenador portátil. Cuando conectas el portátil al dock, de repente el sistema se expande: tienes más puertos USB, el cargador se conecta, quizás accedes a un disco duro externo SCSI o a un almacenamiento PCI Express.

El dock (la aplicación) ya sabe qué interfaces tiene el portátil (el objeto COM). Sabe que tiene un conector de carga, puertos USB y una salida de vídeo, y sabe cómo conectarse a ellos, alimentarlos y activarlos. A partir de una interfaz base llamada IUnknown (Interfaz Desconocida), la aplicación puede «preguntarle» al objeto qué es capaz de hacer y solicitar una instancia de sus funcionalidades.

Lo realmente potente de este modelo es la flexibilidad. Puedes tener cinco modelos de portátiles diferentes, pero si todos tienen los conectores en el mismo sitio, puedes intercambiarlos. Un día usas tu portátil con un procesador i3 para tareas sencillas. Al día siguiente, necesitas potencia bruta, así que sacas el i3 y conectas un i9 con 600 TB de RAM. Los periféricos del dock siguen siendo los mismos, pero el «objeto» que los alimenta ha cambiado por completo.

Esta idea, nacida en el mundo de los «objetos de negocio», tenía otra ventaja brutal: el objeto COM no tenía por qué estar en tu ordenador. Podía estar ejecutándose en un servidor remoto. Tu aplicación simplemente llamaba al objeto a través de su identificador y, según la configuración del sistema, este se cargaba en otro equipo de la red sin que tu programa se diera cuenta.

La dolorosa realidad: lentitud, memoria y el infierno de la conversión

Sobre el papel, COM era una maravilla. En la práctica, tenía un problema gigantesco: no era lento, era inmanejablemente lento. Además, consumía una cantidad de memoria increíble. ¿Por qué? Por el coste de los «acoples», las conversiones de datos entre el objeto y la aplicación.

Imagina que tu portátil tiene una salida de vídeo DisplayPort, pero tu monitor es un viejo VGA. Como no hay un conversor directo, tienes que encadenar adaptadores: de DisplayPort a DVI, de DVI a HDMI, y finalmente de HDMI a VGA. Cada adaptador en esa cadena es un paso intermedio que añade latencia y complejidad. Eso es exactamente lo que pasaba con COM.

Veámoslo con un ejemplo de programación. Supongamos que un objeto COM tiene una cadena de texto «Hola Mundo» en un formato propio: Unicode con un CRC de verificación y terminada en el carácter 67. La interfaz intermedia de COM usa otro formato, los Hstrings. Y tu aplicación, escrita en C++, usa el formato de la librería STL, que guarda primero el tamaño y luego el texto. Para leer esa simple cadena, el sistema tiene que hacer tres conversiones, pasando por un formato intermedio.

Ahora imagina que quieres modificarla. La cosa se pone todavía peor. Modificas la cadena en C++, lo que crea una nueva asignación de memoria. Luego, esa cadena modificada debe convertirse al formato intermedio, que a su vez realiza su propio proceso de memoria. Y finalmente, se convierte al formato del objeto original. Si, para colmo, el objeto COM no permite modificar cadenas, acabas de liarla pardísima.

Para gestionar todo esto, había que definir un «Lenguaje de Definición de Interfaces» (IDL), donde se especificaba con todo lujo de detalles qué podía hacer cada objeto, si sus datos eran mutables, qué formato tenían las estructuras de datos (como el registro de un cliente), etc. Era un sistema propenso a errores y terriblemente complejo.

Anécdotas desde las trincheras: cuando Word decidía explotar

En la práctica, usar esto era una aventura. Imagina que querías automatizar Microsoft Office desde tu aplicación. El proceso parecía fácil: importabas el objeto ActiveX de Word, lo instanciabas y le decías «abre este documento». Y de repente, todo reventaba. ¿Por qué?

¡Ah, amigo! Quizás una llamada anterior había dejado a Word en un estado inestable en la memoria, y al volver a llamarlo, el programa se rompía. De esto, mi amiga Penny tiene bastante experiencia. La solución clásica era reiniciar el ordenador, y entonces, el mismo código funcionaba mágicamente. Aquello era un batiburrillo de diferentes ABIs (Interfaces Binarias de Aplicación) y una complejidad estructural demencial, especialmente en la era de Windows 95, 98 y 2000.

Este era el mundo en el que vivíamos los desarrolladores. Un sistema potente pero frágil y complicadísimo. Entender este caos es fundamental para apreciar por qué nació WinRT como su sucesor. Pero los pasos exactos para instanciar y trabajar con estos objetos… eso os lo contaré en el siguiente audio.

Así que ya sabéis, no olvidéis supextros habitualizaros. ¡Hasta el siguiente audio!

La IA no te va a quitar el trabajo, tu miedo sí: Crónica de un ludita converso

La inteligencia artificial no es el fin de los oficios, sino una herramienta para potenciarlos. Una reflexión sobre el miedo al cambio y cómo adaptarnos.

Este texto ha sido generado por Gemini 2.5/3.1 a partir del audio del autor. El contenido y las ideas son íntegramente del autor; la redacción ha sido asistida por IA.

¡Qué pasa, gallinicas mías! Aquí vuestro reportero maricharachero, que parece que está lanzado. Pensaba abandonar el podcast, pero me he emocionado generando audios y he decidido darle una nueva vida al blog. De hecho, acabo de terminar el libro de David Pogue sobre los 50 años de Apple y he tomado una cantidad de notas impresionante. Mi plan es subirlas a Notebook LM y pedirle que genere un audio, pero no sobre el libro, sino sobre mis propios comentarios. Esa es la clave.

Los dos audios anteriores los hice así. No se trata de subir un libro y decirle a la IA «comenta lo que quieras». No, no. Se trata de que comente lo que yo quiero que comente, de guiarla con mis propias ideas. Para mí, este es el futuro del podcasting y de la creación de contenido en general: la IA como un colaborador al que diriges, no como un sustituto que actúa por su cuenta.

El debate de los luditas modernos

He estado escuchando a compañeros como Mosquetero Web y Tejedor decir que la inteligencia artificial va a acabar con Internet, con los oficios, con todo. Sinceramente, me parecéis unos putos luditas de manual. Un poco de historia: cuando llegó la máquina de vapor, todos temían por las diligencias. Con el coche, lo mismo. Cada vez que aparece una tecnología disruptiva, los poderes establecidos y los más obsoletos tiemblan de miedo.

La novedad ya ha llegado y no va a desaparecer, por mucho que protestéis. Hay que adaptarse. Tenía un conocido aquí en Holanda, un hombre 40 años mayor que yo que en paz descanse, que me decía: «Rafa, yo era tonelero. Cuando vi que el oficio se acababa, me hice carpintero metálico. Me hice herrero». Y punto. Pues eso es lo que toca hacer ahora: menear el culo.

La IA no va a matar a los podcasters. Al contrario, me está ayudando. ¿Han mejorado mis audios desde que elimino el ruido con machine learning? Por supuesto. ¿Le he devuelto la vida a mi blog convirtiendo mi voz en texto? También. Ahora, si no queréis escuchar mi aterciopelada voz, tenéis la entrada del blog, mejor ordenada de lo que yo hablo. No estoy matando al podcaster que hay en mí, me estoy subiendo a hombros de gigantes.

La IA como potenciador, no como sustituto

Mis reseñas de libros generadas con IA no son estúpidas ni carecen de sentido, porque soy yo quien dirige el proceso. Lo mismo ocurre con el desarrollo de software. Mi jefe llevaba tiempo pidiéndome que hiciera que las consolas de comandos de nuestra aplicación se pudieran minimizar. Era una de esas tareas que, entre que no me acordaba y no tenía tiempo, nunca hacía.

Le hice una pregunta a Gemini y en segundos tenía el código. Me ahorró buscar en las APIs, encontrar la función y probarla. ¿Me ha quitado el trabajo? No, me lo ha potenciado. Yo sé dónde y cómo poner ese código, y lo entiendo. Mi jefe no podría hacer eso. La IA no me reemplaza, me hace más eficiente.

De hecho, hace seis meses que no escribo una línea de código desde cero. Si escribo algo, se lo paso a la IA para que lo revise. El otro día, escribí un pequeño script para solucionar un problema con los archivos .ini y el BOM de Windows. Se lo pasé a la IA y me dijo: «¡Ojo! Aquí puedes tener una fuga de memoria. Este otro código es mejor». Y, efectivamente, lo era. Usé el suyo. La IA nos va a potenciar, no a eliminar.

El culebrón del Mac Studio y la verdadera razón de la venta

Hablando de herramientas, os conté que pensaba comprarme un Mac Studio con el futuro chip M5. Cada generación de Apple Silicon ha traído una mejora clave: el M1 fue el bombazo inicial, el M2 añadió instrucciones FLOP16, el M3 trajo el Ray Tracing y el M5 promete revolucionar la IA en local con núcleos dedicados en la GPU. Por eso me interesaba.

Pero, haciendo números, no sale a cuenta. Un Mac Studio M5 Max costará unos 2.500 €. ¿Mi gasto en APIs de IA hasta ahora? Unos 7 u 8 céntimos. Puse 5 dólares en Claude y me caducaron antes de gastarlos. La inversión en hardware no se justifica para mi uso actual. Así que os ofrecí mi equipo actual: el Mac Studio M1 Max, un Mac Mini M2 Pro con 32 GB de RAM y 2 TB de disco, y un MacBook Pro M1 Pro.

Al principio todos «¡quiero, quiero, quiero!», pero a la hora de la verdad, si te he visto no me acuerdo. Sois unos cabrones con patas. Pero bueno, he decidido venderlos igualmente. Ya no para comprar el pepinaco nuevo, sino para deshacerme de macOS, del que estoy un poco hasta los hueveres.

Adaptarse para sobrevivir en la nueva era

El miedo a la IA es el miedo a lo desconocido. Se dice que los profesores están acabados. ¡Al contrario! Si sabes que tus alumnos van a usar LLMs para hacer los trabajos, enséñales a usarlos bien. Hay que usar la azotea de una manera diferente, igual que la invención de la escritura o de los ordenadores cambió nuestra forma de pensar.

Me imagino a un cazador prehistórico harto de perseguir osos durante días, viendo cómo uno se cargó a su amigo Juanito, y pensando: «¿Y si meto dos osos en un corral?». En ese momento, transformó el mundo. Ahora estamos en un punto similar. No te quejes, busca la forma de aprovecharlo. Surgirán nuevos trabajos que hoy ni imaginamos.

Yo mismo no estoy a la última, no ando con 200 agentes de IA como veo en Twitter. Voy a mi ritmo, esperando a que la tecnología se estabilice, como hice con Gemini. Pero la estoy integrando. Si el día de mañana mi jefe cierra la empresa y tengo que buscar trabajo, podré decir: «Sí, uso la IA, y la uso así». Si me piden algo que no sé, como los agentes, diré lo mismo que cuando entré en mi antiguo trabajo sin tener ni idea de Windows Phone: «Dame dos semanas».

Una filosofía de supervivencia

Al final, todo se reduce a la supervivencia y la adaptación. Si reaccionas como un conductor de diligencias viendo llegar los coches, te quedarás atrás. Lo lógico es aprender a conducir o a reparar esos coches. Y si todo falla, si un día la IA nos deja a todos sin trabajo y sin un duro, yo tengo un plan.

Se lo decía a mi madre con veinte años: si no tengo para comer, me voy a un supermercado, como algo y espero tranquilamente a que venga la policía. Sin violencia, sin resistencia. Al juez le diría: «Señoría, tengo derecho a comer». Si me meten en la cárcel, tendré comida. Si me sueltan, volveré a hacerlo. Es una forma de resistencia pasiva. Quizás soy yo el rarito, pero hay miedos que no entiendo cuando la solución es moverse.

En fin, que me voy de vareta. Ya sabéis, no olvidéis sospechar habitualizaros, que no os la pique un pollo belga. ¡Ah, demonio!

Microsoft se sincera: Los problemas de Windows 11 y su plan para arreglarlos

Un correo de Microsoft Insider revela los problemas de rendimiento, fiabilidad y usabilidad de Windows 11. Analizo su plan de mejora y mis experiencias con la IA.

Este texto ha sido generado por Gemini 2.5/3.1 a partir del audio del autor. El contenido y las ideas son íntegramente del autor; la redacción ha sido asistida por IA.

¿Qué pasa gallinicas mías? Aquí vuestro reportero más dicharachero de Barrio Sésamo para comentar un correo que hemos recibido todos los Microsoft Insiders. Sí, soy un insider, un empotrador (chiste privado para los amigos de la pradera). El caso es que Microsoft ha enviado una comunicación, bastante larga y en castellano, donde reconoce abiertamente todas las pegas que arrastra Windows últimamente.

Es el típico comunicado de Microsoft, con mucha paja y balbuceos, muy a lo «mucho ruido y pocas nueces» de Shakespeare. Pero entre todo el relleno, hay contenido y aspectos técnicos interesantes. Por cierto, mientras leía, el brillo de mi iPhone se ha vuelto loco y ha subido al máximo sin motivo. ¡Tecnología, quién te entiende! Pero volvamos a lo nuestro, que me disperso como mantequilla fluida.

El reconocimiento: Windows 11 tiene serios problemas de calidad

Lo primero y más importante es que Microsoft admite que Windows 11 tiene serios problemas de calidad en tres áreas clave: rendimiento, fiabilidad y usabilidad. En mi opinión, muchos de estos problemas vienen de su obsesión con la inteligencia artificial. Están metiendo IA en todas partes, y aunque yo la uso muchísimo para el desarrollo, una cosa es usarla y otra dejar que la IA se encargue de tus builds y tus pruebas. ¡Las pruebas las hago yo!

Este enfoque ha derivado en otro gran problema: la calidad de Windows Update. No hay una sola actualización que no le rompa algo a alguien. Yo, de momento, toco madera en el trabajo, que es donde importa. Esta mañana, por ejemplo, el ordenador arrancó con un error que no pudo reparar, pero al darle a «continuar» funcionó sin más. Cositas raras a las que nos estamos acostumbrando.

Rendimiento: La eterna lucha por la agilidad

Microsoft promete mejoras concretas en el rendimiento. Quieren un menor uso de recursos, algo lógico si pensamos en la cantidad de aplicaciones tipo PWA o WebUI que son, básicamente, HTML embebido. Al principio yo denigraba estas apps, pero reconozco su utilidad multiplataforma. Sin embargo, ¿tiene sentido que el Bloc de Notas o el Paint sean una WebUI? Para mí, no.

Siempre he defendido que las aplicaciones del sistema deben estar escritas en el lenguaje nativo del sistema operativo. Apple lo hace de maravilla: antes Objective-C, ahora Swift. Microsoft usaba C y C++ con MFC, y funcionaba. Incluso acepté que usaran C#/.NET cuando se volvió casi nativo, pero ahora hasta han descontinuado WPF. Parece que su nuevo camino es WinUI 3, una interfaz que pretende ser la nueva capa nativa sobre Win32, construida con componentes COM y compatible con C++, C#, Javascript… Es un tema complejo que merece un análisis aparte en el futuro.

Además, prometen un inicio más rápido de aplicaciones y del explorador. Un programa nativo como Notepad++, escrito en C, es casi instantáneo. El explorador, en cambio, es un desastre. El proceso de copiar o mover archivos es un dolor: primero lee el origen, luego comprueba el destino, simula la copia, pregunta por conflictos y finalmente actúa. Es un proceso absurdo que espero que arreglen de una vez. También mencionan un mejor rendimiento de WSL (el subsistema de Linux), aunque en mi experiencia, ya es bastante aceptable.

Fiabilidad: Drivers, periféricos y un Windows Update predecible

En el apartado de fiabilidad, las promesas son ambiciosas: menos fallos del sistema, drivers más estables y mejor soporte para Bluetooth, USB, impresoras, audio y cámaras. Personalmente, no he tenido grandes problemas con los drivers, que considero que tienen un framework muy bueno en Windows, pero si lo mencionan, será por algo. El USB, eso sí, es lento, pero también me pasa en macOS.

La joya de la corona es la promesa de un Windows Update «más predecible y con menos interrupciones». Aquí mi escepticismo es máximo. Lo que deberían hacer es volver a certificar hardware específico, como hacían antes. Con la automatización actual, podrían probar cada actualización en miles de equipos certificados antes de lanzarla al público. Finalmente, prometen un Windows Hello más fiable, aunque a mí en la Surface me funciona de maravilla, reconociéndome incluso mientras me estoy sentando.

Usabilidad y el futuro de Copilot

En usabilidad, Microsoft quiere ofrecer más personalización en la barra de tareas, menos ruido visual y notificaciones, y widgets menos intrusivos. Pero lo más importante es que prometen una «búsqueda más coherente y clara en todo el sistema». ¡Ya era hora! Es increíble que a mediados del siglo XXI la búsqueda de Windows sea tan deficiente.

Y aquí viene lo interesante: anuncian una «reducción de la presencia de Copilot». Planean ponerlo solo donde realmente sea útil. A mí no me molesta que esté en el Paint, si no lo usas, no pasa nada. El problema real es que el motor de IA está siempre cargado, consumiendo una cantidad ingente de RAM. En la Surface Pro 11, de 16 GB, 8 están reservados para Copilot. Es cierto que libera memoria si la necesitas, pero el consumo inicial es brutal.

Mi experiencia con la IA: Copilot vs. Gemini

Hablando de IA, yo uso el Copilot de Edge principalmente para resumir noticias o artículos largos. Si le pido que me resuma un vídeo, es señal de que no me interesa lo suficiente como para verlo entero. Hay vídeos, como los de JerryRiggedEverything, que me los veo todos aunque siempre haga lo mismo: rayar, doblar y destrozar teléfonos.

Para tareas serias de desarrollo, Copilot se queda corto. Por eso pago por Gemini. Este fin de semana, por ejemplo, un cliente tenía un problema con TeamViewer: le saltaba publicidad constantemente, tapando nuestra aplicación que se supone que siempre debe estar en primer plano. Le pregunté a Gemini, me indicó dónde encontrar el log, se lo envié y me diagnosticó el problema al instante. Resulta que el servidor de TeamViewer pensaba que era una cuenta gratuita y lo bombardeaba con anuncios. La solución: reinstalar. Para este tipo de cosas, Gemini es una herramienta increíble.

Conclusión: ¿Confianza recuperada?

Veremos cuántas de estas promesas se cumplen y cuántas son solo palabrería para mantenernos tranquilos. Indirectamente, parece que Apple también planea un lanzamiento centrado en la estabilización de su sistema operativo, algo que ya le va haciendo falta. De Apple me creo poco, pero de Microsoft, todavía menos. Tienen que trabajar mucho para volver a ganarse mi confianza.

El tiempo dirá. Ya sabéis, no olvidéis sospechosos habitualizaros. Y como esto es un leña al mono, ¡que no os la pique un pollo belga!

IA a céntimos y el misterio del Mac Studio sin internet

Descubre cómo he revolucionado mi blog con IA por céntimos y resuelve conmigo el misterio que dejó mi Mac Studio sin conexión a la red por culpa de Tailscale.

Este texto ha sido generado por Gemini 2.5/3.1 a partir del audio del autor. El contenido y las ideas son íntegramente del autor; la redacción ha sido asistida por IA.

¿Qué pasa, gallinicas mías? Aquí vuestro reportero más dicharachero para contaros un par de batallas. Si habéis seguido las últimas entradas del blog, habréis notado un cambio de calidad más que absoluto en los textos generados a partir de los audios. Antes de desvelar el secreto detrás de esta mejora, permitidme que os cuente una de esas historias del abuelo Cebolleta que tanto nos gustan.

Una historia de terror en la red: Cuando el Mac Studio se negó a conectar

Desde hace varios días, mi Mac Studio sufría una conexión de red terriblemente lenta. No hablo de un pequeño lag, sino de una velocidad de entre 1 y 2 kilobytes por segundo. La situación llegó a un punto crítico este domingo por la tarde, cuando la red local dejó de funcionar por completo. Olvidaos de internet; ni siquiera podía comunicarme con mi Synology. El Synology Drive iba a paso de tortuga y compartir la pantalla con el Mac Mini en alta calidad era una misión imposible, a pesar de que todo está conectado por cable a través del router y switches.

Bastante mosqueado, empecé el ritual de solución de problemas: revisé las prioridades de red, desconecté y conecté el WiFi, cambié los cables de red entre el Mac Mini y el Mac Studio, conecté el equipo directamente al router… Nada. El rendimiento de la red del Mac Studio era, sencillamente, asqueroso. Me negaba en rotundo a reinstalar macOS otra vez, así que estaba a punto de tirar la toalla.

En un acto de desesperación, le pregunté a Gemini, que me dio una serie de pasos estructurados para encontrar la solución. Aunque ninguna de sus sugerencias directas funcionó, me pusieron en el camino correcto. Mientras investigaba, mi subconsciente me gritaba que mirara algo que tenía delante de las narices. Y de repente, lo vi: ¿qué demonios hacía la VPN de Tailscale activada sin ningún icono en la barra de menús?

Fue hacer clic en «desactivar» y, como por arte de magia, todo volvió a la vida. Las ventanas que cargaban con una lentitud exasperante hicieron «frrrr, roca» y la velocidad se disparó de nuevo a los 800 Mbps. El culpable era el maldito Tailscale. Según me confirmó Gemini, es un problema que puede ocurrir, sobre todo si se activa el «exit node». Parece que se enreda con las IPs locales (las del tipo 100.x.x.x) y no es capaz de resolver las DNS correctamente, colapsando toda la conexión.

La solución fue drástica pero necesaria. Desinstalé Tailscale del NAS, para lo cual tuve que activar momentáneamente el acceso SSH, ejecutar los comandos de borrado y volver a desactivarlo. Hice lo mismo en el Mac y en el iPhone, y para rematar, entré en la web de Tailscale y eliminé toda mi configuración. No quiero que dentro de una semana se reactive solo y me vuelva a dejar tirado. Así que, una y no más, Santo Tomás. Y si ahora sale el de siempre a decir «pues a mí me va bien», le diré: cojonudo para ti.

El dilema: ¿IA local o en la nube? Un análisis de costes

Ahora sí, vamos al meollo del asunto: el salto de calidad en las entradas del blog. Todo empezó con un profundo estudio económico. Estuve barajando la idea de comprar un nuevo Mac Studio con 128 GB de RAM y 4 TB de disco duro para ejecutar modelos de IA en local. El capricho, entregando mi equipo actual, se iba a unos 5.000 euros.

Haciendo números, si mi gasto actual en tokens de API es de unos 20 euros al mes, necesitaría 20 años para amortizar esos 5.000 euros. Como bien me dijo Gemini, «cuando pasen los 20 años, ese Mac Studio será un pisapapeles muy caro que fue muy caro en su momento». La lógica era aplastante, así que decidí optimizar mi flujo de trabajo usando APIs online.

Mi nuevo flujo de trabajo y el ridículo coste de la calidad

Mi proceso ahora es un híbrido. La eliminación de ruido del audio la hago con una red neuronal en local, que es prácticamente instantánea. La transcripción también la realizo en local, aunque curiosamente en el Mac Studio va superlenta, mientras que en mi viejo iMac Intel es siete veces más rápida. El paso final, la creación del texto del blog, es donde entra en juego la API de Gemini.

Para que os hagáis una idea, he procesado tres podcasts con este nuevo sistema, incluyendo la reescritura de la entrada sobre Roma y una nueva sobre otro libro. El consumo total fue de 19.000 tokens. ¿El coste? Preparaos: cuatro céntimos de euro. Por cuatro céntimos, estoy obteniendo una calidad de texto espectacular, y eso que podría usar un modelo más caro. Me he puesto un límite de 10 euros al mes para esto, y a este ritmo, me va a durar meses.

También exploré los costes de traducción. Una traducción decente para uso interno sale por un euro y medio cada 100.000 palabras, lo que equivale a un libro de 200-300 páginas. Gemini me calculó que traducir una obra como Guerra y Paz (que, de forma un poco inquietante, sabía que estaba leyendo en papel) costaría entre 8 y 10 euros. Luego caí en la cuenta de que lo sabía porque se lo mencioné en una de las transcripciones que le pasé para analizar. ¡Qué memoria tiene el bicho!

La IA, la traducción y una imitación fallida de Dune

Hablando de traducir, no creo que vaya a usar la API para traducir 200 libros al mes. Normalmente leo en inglés, pero hace poco traduje la novela El Imperio del Silencio porque su estilo de escritura me resultaba extraño y no lograba concentrarme. Más tarde descubrí que la comunidad de fans ya había traducido toda la saga.

Aunque dicen que es como Dune, mi opinión es muy distinta. Intenta imitar ese tono místico-mesiánico, pero no se le acerca ni a la suela de los zapatos. Me resulta aburrida y demasiado explicativa. El autor te cuenta la historia dos veces: primero narra la acción y luego te detalla el proceso interno de decisión del personaje. Es redundante y no termina de cuajarme.

En fin, el futuro pasa por seguir afinando este sistema. Quizás el próximo paso sea usar una voz sintética para limpiar las grabaciones de repeticiones y muletillas, pero eso ya será para otra reencarnación. Por ahora, el salto cualitativo y económico es innegable.

Así que ya sabéis, no olvidéis sospechosos habitualizaros, que no os la pique un pollo belga. ¡A demonio demoníaco!

Atrapados en el Código: El Mundo de Artefactos que Creamos

Un viaje desde la Revolución Agrícola hasta la IA, explorando cómo la humanidad ha sustituido la naturaleza por un mundo de artefactos que ahora nos define.

Este texto ha sido generado por Gemini 2.5/3.1 a partir del audio del autor. El contenido y las ideas son íntegramente del autor; la redacción ha sido asistida por IA.

Imaginemos una situación inquietante: la humanidad se encuentra atrapada dentro del código fuente de un videojuego hipercomplejo. Una simulación colosal que nosotros mismos hemos escrito a lo largo de milenios con nuestras ciudades, leyes y ecuaciones. El sistema se ha vuelto tan inmenso que ha tomado el control, y la humanidad es ahora una pieza más, una especie de silicio biológico.

Esta imagen captura a la perfección la esencia de nuestro análisis. La pregunta fundamental es, ¿en qué momento empezamos a teclear ese código? Para responderla, nos apoyaremos en la demoledora tesis de Javier de Lorenzo en su libro Un mundo de artefactos. Hoy desgranaremos cómo pasamos de ser primates nómadas a una fuerza geológica masiva, devorando el mundo natural —la physis— para sustituirlo por un ecosistema de artefactos.

El Pecado Original: La Revolución que Nos Hizo Arquitectos

Para rastrear el origen de esta transformación, debemos retroceder 12.000 años, a la Revolución Agrícola. Lejos de la visión bucólica que se nos ha transmitido, este periodo no fue una adaptación pasiva. Fue, en puridad, la primera agresión sistemática de nuestra especie para dominar, doblegar y someter a la naturaleza.

Al alterar su entorno de forma tan radical, la humanidad generó una memoria de especie: un conjunto de saberes y miedos heredados culturalmente. El simple acto de sembrar una semilla supuso la reprogramación cognitiva más importante de nuestra historia. Antes, el cerebro del cazador-recolector operaba en un presente perpetuo; con la siembra, se introduce una brecha temporal enorme. Nace la espera y, con ella, el futuro.

Esta capacidad de proyectarse hacia adelante desencadenó un efecto dominó. Una cosecha genera un excedente, y un excedente crítico para la supervivencia necesita ser defendido. Es aquí donde el mundo físico se fractura por primera vez. Se traza una frontera que divide el espacio en un «adentro» —la aldea, el orden— y un «afuera» —lo salvaje, el caos del que hay que protegerse.

La Geometría: Las Gafas de Realidad Aumentada de la Antigüedad

Para gestionar este «adentro», la mente humana tuvo que crear herramientas de control abstracto. Si guardas toneladas de grano, necesitas medir, contar y pesar. De esta angustia por el control nacen los tres grandes ámbitos que estructuran nuestra civilización: el técnico (herramientas, arquitectura), el simbólico (mitos, religiones para amortiguar el terror a lo incontrolable) y el conceptual (matemáticas, razonamiento).

El ámbito conceptual fue el verdadero motor de aceleración. La geometría euclidiana, con sus líneas rectas y ángulos perfectos, es un claro ejemplo. Nada de eso existe en la naturaleza, que es curva, fractal y orgánica. La geometría fue la primera versión de la realidad aumentada de la historia: unas gafas mentales que superponían una cuadrícula matemática sobre el paisaje salvaje para poder dominarlo.

La paradoja surge cuando la humanidad usa esa misma herramienta para escrutar el cielo nocturno. Al hacerlo, las matemáticas desentierran verdades tan incómodas que amenazan con demoler todo el ámbito simbólico que sostenía a la sociedad. Esto nos lleva directamente a la Antigua Grecia y a un escándalo que casi colapsa la realidad.

El Fallo en el Código: Cuando un Número Quebró el Universo

Los griegos, y en especial los pitagóricos, concebían un cosmos perfecto y armonioso, donde todo era conmensurable y expresable mediante fracciones equilibradas. Un universo que funcionaba como un acorde musical sin disonancias. Hasta que a un matemático se le ocurrió medir la diagonal de un cuadrado cuyo lado mide 1.

Al aplicar su propio teorema, el resultado fue la raíz cuadrada de 2, un número irracional con infinitos decimales sin patrón. ¡Un fallo catastrófico en el código fuente de la realidad! Si la geometría, base del universo, contenía abismos inconmensurables, significaba que el caos estaba incrustado en los cimientos de la creación. La reacción fue de pánico absoluto.

La secta pitagórica clasificó el descubrimiento como un secreto celosamente guardado. La leyenda de Hipaso de Metaponto, quien reveló el secreto al mundo, cuenta que murió ahogado poco después en un naufragio, un castigo divino por desvelar la falla fundamental del cosmos.

El Universo como Reloj y el Fantasma en la Máquina

Esta tensión entre la matemática y el mito no podía sostenerse. El siglo XVII trajo consigo la revolución científica y el triunfo del mecanicismo. El universo fue despojado de su magia y redefinido como una inmensa maquinaria de relojería: materia y movimiento. Isaac Newton asestó el golpe maestro al demostrar que la misma ley de la gravedad rige la caída de una manzana y la órbita de Júpiter.

A la vez, Blaise Pascal demostró físicamente que el aire pesa y que el vacío existe, un escándalo para la Iglesia, pues implicaba que el universo no estaba lleno de la gracia divina, sino que contenía la nada. Pero si todo es un reloj determinista, ¿qué espacio queda para el libre albedrío? Si somos engranajes, no somos libres.

René Descartes se enfrentó a este muro y propuso una incisión quirúrgica en la realidad: el dualismo. Dividió la existencia en la res extensa (la materia física, sujeta a las leyes del reloj cósmico) y la res cogitans (la mente o alma inmaterial). Básicamente, se inventó una laguna legal cósmica para salvar la excepcionalidad humana: pilotamos la máquina sin estar sujetos a sus engranajes.

La Flecha del Tiempo: La Tragedia de la Máquina de Vapor

La humanidad no se conformó con ser espectadora. Quiso tomar los mandos, y al intentar crear energía artificial, chocó con el lado más oscuro de la física. La máquina de vapor de James Watt rompió la dependencia milenaria de los ritmos naturales. Por primera vez, podíamos generar trabajo mecánico continuo quemando combustible fósil, emancipándonos de los caprichos del clima.

La búsqueda por optimizar estas máquinas abrió la caja de Pandora de la termodinámica. Científicos como Rudolf Clausius descubrieron la entropía: la medida del desorden en un sistema. La segunda ley de la termodinámica dicta una sentencia implacable: la entropía del universo siempre aumenta. Todo tiende a la degradación y al enfriamiento.

Esto introdujo lo que Arthur Eddington llamó la «flecha del tiempo». A diferencia de las ecuaciones de Newton, la termodinámica demuestra que el tiempo tiene una dirección irreversible. Un jarrón roto jamás se recompondrá solo. A escala cósmica, el pronóstico es desolador: una muerte térmica donde toda la energía se habrá dispersado y nada más podrá ocurrir.

La Paradoja del Siglo XX: El Poder de Crear y Destruir

Saber que el reloj cósmico tiene una cuenta atrás pareció inyectar una urgencia febril a nuestra civilización. El siglo XX fue un acelerón ciego hacia la era de la tecnociencia, donde la ciencia se fusiona con el capital y el Estado para crear infraestructuras colosales. La física cuántica nos arrancó del determinismo, y la astronomía nos reveló el Big Bang.

Mientras unos miraban al cosmos, otros buceaban en nuestro interior. En 1953, Watson y Crick desentrañaron la doble hélice del ADN. La vida, el misterio atribuido al soplo divino, quedó reducido a un código físico-químico. Casi en paralelo, Lise Meitner y Otto Hahn descubrieron la fisión nuclear, aprendiendo a replicar el fuego de las estrellas.

Aquí reside una ironía escalofriante. En la misma minúscula ventana temporal en que desciframos el manual de instrucciones de la biología y el origen del universo, la tecnociencia nos dio la herramienta para aniquilarlo todo en segundos: la bomba atómica. El artefacto había superado nuestra capacidad ética para controlarlo.

Bienvenidos al Antropoceno: Nuestra Huella Indeleble

Este poder nos ha convertido en la fuerza geológica dominante. Hemos entrado en el Antropoceno, una nueva era geológica que arranca en 1950, cuya firma indeleble en las rocas del futuro serán los isótopos radiactivos de los ensayos nucleares. Vivimos en un mundo de macrociudades voraces, océanos acidificados y una sexta extinción masiva en ciernes.

Si el presente es tenso, el futuro plantea abismos más profundos. Dos revoluciones titánicas convergen: la biotecnología y la inteligencia artificial. Con herramientas como CRISPR-Cas9, hemos pasado de leer el ADN a editarlo, abriendo la puerta a erradicar enfermedades, pero también al diseño de seres humanos a la carta.

Simultáneamente, la IA y la robótica automatizan procesos cognitivos, desdibujando las fronteras de la responsabilidad y planteando debates sobre la necesidad de otorgar estatus de «personas cibernéticas» a las IA avanzadas. ¿No estamos cerrando un círculo perturbador? ¿No nos estamos convirtiendo en los dioses que inventamos en la Revolución Agrícola para paliar nuestro terror?

El Relámpago lo es Todo: Una Reflexión Final

El ámbito conceptual que creamos para medir el grano ha fagocitado por completo a nuestro ámbito simbólico. Habitamos una fractura emocional, estirados entre dogmas que ya no explican la realidad y algoritmos que no comprendemos. Nos hemos convertido en un artefacto más, rodeados de artefactos.

Para poner todo en perspectiva, el matemático Henri Poincaré reflexionaba que la vida sensible es un brevísimo episodio entre dos eternidades de vacío. Sin embargo, concluía, «este relámpago lo es todo». En la gestión de ese relámpago reside nuestra responsabilidad. La tecnociencia nos ha dado un poder geológico, pero la termodinámica nos recuerda nuestra fragilidad.

La gran pregunta es si usaremos nuestros artefactos para prolongar este destello de consciencia o si, arrastrados por su inercia, estamos programando nuestra propia caducidad. Y aquí queda una última idea: la Tierra tiene fecha de caducidad. Si en un futuro remoto logramos saltar a las estrellas, ¿quienes hagan ese viaje seguirán siendo humanos?

O quizás la perspectiva más asombrosa sea que la humanidad nunca fue el final del camino. Quizás solo fuimos el primer artefacto biológico diseñado por la evolución con un único propósito: construir la tecnología para que el propio universo, a través de una conciencia de silicio, pudiera por fin tener una mente eterna con la que comprenderse a sí mismo.

Mi Flujo de Trabajo con IA: Un Gorila, un Mac y un Pajarito

Descubre mi nuevo flujo de trabajo para el podcast, desde la portada creada con IA hasta la automatización total y mis planes para un futuro Mac Studio.

Este texto ha sido generado por Gemini 2.5/3.1 a partir del audio del autor. El contenido y las ideas son íntegramente del autor; la redacción ha sido asistida por IA.

¡Qué pasa, gallinoleidos míos! Aquí vuestro reportero más dicharachero para contaros las novedades del podcast y las reflexiones tecnológicas que me acompañan. Veréis que hay cambios, experimentos y, como siempre, algún que otro desvarío.

Una nueva cara para el podcast

Lo primero es lo primero: quiero dar un agradecimiento enorme a Marcus Fernández (@MarcusFernandez en Twitter). Me preparó dos carátulas nuevas para el podcast y he de decir que son una pasada. Si habéis escuchado el último episodio, habréis visto la nueva portada: un gorila sosteniendo un libro que pone «Lo he leído, libros sin hilos».

Marcus me hizo una versión con texto y otra sin él, y he elegido la primera. La verdad es que está muy bien, mucho mejor de lo que yo podría haber hecho. Me comentó que la anterior, la de «Leña al Mono», la había hecho con inteligencia artificial. No sé si será diseñador o no, pero desde luego, tiene un talento increíble. ¡Gracias, Marcus!

La nomenclatura 2.0 y los fantasmas de iVoox

El primer capítulo con este nuevo formato ya está fuera y, como habréis notado, he cambiado la nomenclatura. Ahora los episodios seguirán un formato como 2001 LM, 2002 LM, etc. Esta genial idea me la recomendó un oyente en un comentario en iVoox, en el audio del «Notición Importantón de Leña al Mono».

El problema es que iVoox, que es una puta mierda pinchada en un puto palo de mierda, no me deja interactuar como usuario. Puedo subir contenido como podcaster, pero no puedo responder a los comentarios. Y para colmo, parece que el comentario ha desaparecido, así que no puedo dar el crédito a quien lo merece. Lo siento, tu mensaje se ha perdido en el éter, pero que sepas que tu idea ha sido genial. Me permite ordenar los audios procesados en secuencia en mi carpeta de macOS, algo de lo que no me fío si dependo solo de la fecha de creación.

El experimento: cuando la IA toma el micrófono

El último audio es un experimento generado con Notebook LM. Y ojo, no es tan simple como subir un libro y pedirle que lo narre. He ido reconstruyendo el guion, seleccionando los fragmentos que la IA me proporcionaba y, con un pequeño prompt, le he pedido que generara el audio final. El resultado es cojonudo, la verdad.

Esto nos va a eliminar a los podcasters, al menos en cierta medida. Yo no podría haber grabado algo tan completo, tan bien contado y con esas voces. Y recordad esto que digo sobre las voces, porque «todo se andará». El experimento sigue adelante, aunque las entradas de blog que acompañan a los audios sean bastante mierdosas, porque también las genera un LLM.

La filosofía del gandul tecnológico

Mi objetivo es no complicarme la vida. Soy como ese personaje gandul de Robert Heinlein en «Tiempo para Amar», que solucionaba problemas tecnológicos por pura pereza de no querer trabajar. Si tengo que procesar este audio, transcribirlo, reescribir el blog, subirlo a Gemini y darle un prompt… no lo hago. Ni tengo ganas, ni paciencia, ni nada.

Mi flujo de trabajo actual es la personificación de esa pereza. Hago clic en un acceso directo, se abre una ventana de comandos con el entorno de Python cargado, tecleo un único comando y le doy a Enter. Eso es todo. El script se encarga de eliminar el ruido, generar la transcripción, crear los resúmenes en DevonThink, redactar la entrada del blog y publicarla como borrador. Si no fuera así de simple, no habría ni blog, ni resúmenes, ni su puta madre.

El cuello de botella: la memoria y mi Mac actual

El problema es que, para procesar un audio, tengo que cerrarlo todo en el Mac. El modelo de IA que uso, Command R, consume toda la memoria. Si tengo DevonThink o cualquier otra cosa abierta, el Mac se bloquea por completo. Supongo que es un fallo de macOS con los Apple Silicon, que en lugar de lanzar una excepción cuando se queda sin memoria, simplemente se congela.

Esto me recuerda a mis tiempos de desarrollador en Windows. Allí, cuando pides memoria, el sistema te la reserva en el espacio de direcciones, pero solo la asigna físicamente cuando la usas. Si se agota, el sistema se vuelve lentísimo, pero no se congela. De hecho, yo programé un liberador de memoria en C++ con diez líneas de código que se basaba en este principio: asignaba y llenaba bloques de memoria hasta forzar al sistema a descartar cachés y liberar RAM.

El sueño: un Mac Studio para dominarlos a todos

Todo esto me lleva a mi plan futuro. Cuando salga el Mac Studio M5 Max, mi idea es comprarme un equipo con 128 GB de RAM y 4 TB de disco duro. Serán unos cinco mil y pico euros. Como dice el refrán, «nunca más» tendré problemas de memoria. Justo ahora que lo pienso, mi mujer, «Inconvenient», anda cerca… «¿Vas a comprar qué? ¿Qué me dijiste que no te dejará comprar?»… ¡Nada, mujer, que voy a ir al Lidl a comprar galletas!

Bromas aparte, con un equipo así podré tenerlo todo cargado a la vez: DevonThink lanzando su motor de IA para los resúmenes, el LLM Command R generando la entrada del blog… todo sin que el sistema se ahogue. Usar un LLM más pequeño no es una opción, porque el resultado es todavía peor que el que obtengo ahora.

4 TB de disco y un pajarito en la ventana

¿Y por qué cuatro terabytes de disco? Primero, porque Spotlight no busca bien en discos externos. Segundo, porque el disco interno se me llena periódicamente de cachés y temporales. Es una cuestión de comodidad y rendimiento. Mientras pensaba en esto, he visto un pajarito amarillo bañándose en la ventana del salón. ¡Qué guapín! Son las once y media de la mañana, así que supongo que se está dando una ducha antes de irse a dormir a su rama.

Volviendo al tema, contemplo una alternativa: si por el mismo precio de los 4 TB puedo conseguir 256 GB de RAM, quizás opte por eso y siga usando un disco duro externo. Con Thunderbolt 5, las velocidades son de casi 14 GB/s, casi como la memoria DDR2. Sería una opción a valorar.

¿Mac Studio o MacBook Pro? El dilema del sofá

También podría comprar un MacBook Pro con esas características, pero el precio sube a más de 6.500 euros. Además, sufriría de throttling (reducción de rendimiento por calor). La ventaja sería poder trabajar tirado en el sofá, pero el Mac Studio ofrece más potencia bruta y salvaje. En fin, son cosas que tendré que sopesar.

Por ahora no puedo comprar nada. Los equipos custom tardan semanas en llegar y dentro de poco tengo un evento especial del que ya os contaré más adelante. Se me va la pelota, así que voy terminando. No olvidéis lecturo-leñalmono-habitualizaros, y que no os la pique un pollo belga. Y de nuevo, Demonio, lo siento por no tener tu mensaje para darte el crédito que mereces. ¡Ha sido una idea genial!

Nuevos proyectos y cambios en los podcasts: ¡Conoce las novedades!

Anuncio de cambios en los podcasts: ¡Descubre la llegada de un nuevo integrante a la familia y cómo afectará a tus audios favoritos!

Este texto ha sido generado con un LLM a partir del audio del autor. El contenido y las ideas son del autor; la redaccion ha sido asistida por inteligencia artificial.

Un anuncio importante: ¡Llega un nuevo miembro a la familia!

¡Hola, gallinicas! Aquí vuestro reportero favorito listo para compartir una noticia emocionante. Resulta que vamos a tener un nuevo gato en casa, y todo gracias a nuestra querida Lina.

La historia comenzó con el cepillado de esta gatita de Angora, ya que al descubrir su denso pelaje, nos dimos cuenta de que necesitaba cuidados especiales. Y así fue como Inconvenient se enamoró de ella y decidió adoptar un nuevo compañero felino.

Nuestro nuevo gato, Solete, es un naranja y blanco de cuatro años, una elección tranquila y recomendada por la protectora de Villena. ¡Y yo quería llamarlo Satán! Pero Inconvenient no estuvo muy convencida con mi idea.

Cambios en los podcasts: ¡Un reset para empezar de cero!

Además del nuevo gato, también os traigo un anuncio sobre mis podcasts. He decidido cerrar algunos y hacer una reorganización para simplificar vuestra experiencia de escucha. Quiero dejar solo «Leña al Mono» y hacer un reinicio de contadores.

Así que a partir de ahora, encontraréis todo en el feed de «Leña al Mono», incluyendo los antiguos audios de «La Patata» y «Lo Leído». De esta manera, podréis seguir disfrutando de mi contenido sin perderse nada.

La magia de la inteligencia artificial: una nueva forma de aprender

Recientemente he descubierto la potencia de la IA para generar podcasts a partir de libros técnicos. Me interesaba un tema en concreto sobre las cloacas y el sistema de alcantarillado en Roma, pero no tenía tiempo ni ganas de leer un libro entero.

Así que usé Google Notebook LM para subir el libro y hacerle preguntas específicas. Luego, le pedí a la IA que generara un podcast con mis preguntas y sus respuestas. El resultado fue impresionante: un audio de 24 minutos que cubría todos los temas que me interesaban, contado de manera clara y amena.

Por eso he decidido incluir más contenido generado por inteligencia artificial en «Leña al Mono». Hay muchos libros interesantes que no tengo tiempo de leer, pero con la IA puedo extraer la información importante y compartirla con vosotros de una forma más dinámica.

Experimentos con el blog: parafraseando audios

También he estado experimentando con mi blog. He generado un script que automatiza el proceso de transcripción, resumen y publicación de entradas basadas en mis audios. La idea es ofreceros contenido escrito complementario a los podcasts.

Aunque las entradas aún no son perfectas, creo que es una buena forma de brindaros más opciones para disfrutar de mi contenido. Y lo mejor es que el proceso es automático, así que podréis esperar más publicaciones en el futuro cercano.

¡Nos vemos en «Leña al Mono» y en el blog! No olvidéis suscribiros a los feeds habituales.

La magia de la traducción literaria con LLM y Google Translator

Descubre cómo traducir literatura con inteligencia artificial. Comparte tu experiencia de lectura en ebooks y dispositivos.

Este texto ha sido generado con un LLM a partir del audio del autor. El contenido y las ideas son del autor; la redaccion ha sido asistida por inteligencia artificial.

La magia de la traducción literaria

¡Hola a todos, amantes de las letras! Hoy quiero compartir con vosotros un proyecto que me tiene muy emocionado: la traducción de literatura fantástica con ayuda de la inteligencia artificial. Sí, has oído bien.

He estado probando diferentes herramientas y técnicas para traducir obras literarias del inglés al español, y los resultados son asombrosos. Con un simple script en Python y un modelo LLM adecuado, puedes obtener traducciones de calidad profesional en cuestión de horas.

El proceso es sencillo: descompones el EPUB en XHTML internos, los procesas con la IA para traducirlos a español, y luego vuelves a generar un nuevo archivo EPUB. El resultado final incluye tanto el texto original como la traducción en español, y lo mejor de todo es que puedes leerlo cómodamente en tu dispositivo favorito.

Google Translator: una opción rápida y efectiva

Si no tienes acceso a un modelo LLM o prefieres una solución más rápida, Google Translator también ofrece una excelente alternativa. Simplemente subes el documento que deseas traducir, seleccionas los idiomas de origen y destino, y en cuestión de segundos tendrás tu traducción lista.

He probado esta técnica con revistas literarias en formato PDF y EPUB, y los resultados son sorprendentes. La calidad de la traducción es muy buena, y puedes leer el texto sin problemas en tu dispositivo favorito.

Dispositivos para una experiencia de lectura inmersiva

En cuanto a dispositivos de lectura, he estado probando varios modelos y formatos. Mi preferido para leer novelas es el formato EPUB, ya que ofrece una experiencia más cómoda y personalizable.

Para revistas literarias, recomiendo leerlas en PDF o facsímil, dependiendo del tamaño y la complejidad del texto. En mi caso, he estado leyendo las revistas Asimov y Analog en estos formatos, y la experiencia ha sido muy satisfactoria.

Kindle In: una joya para lectores exigentes

Recientemente he descubierto el Kindle In, un dispositivo de lectura que me ha dejado impresionado. Con su pantalla de tinta electrónica y su luz integrada, ofrece una experiencia de lectura cómoda y sin reflejos, incluso en condiciones de poca luz.

Lo mejor del Kindle In es su funcionalidad con el palito o stylus. Puedes usarlo como un dedo para pasar páginas o subrayar texto, o activar las funciones inteligentes para marcar y traducir con solo deslizarlo por la pantalla.

Conclusión: la magia de la lectura en tus manos

La tecnología nos ofrece herramientas increíbles para disfrutar de la literatura en cualquier formato. Ya sea con modelos LLM avanzados o con servicios como Google Translator, podemos acceder a una amplia variedad de obras literarias en nuestro idioma preferido.

¿Qué opináis vosotros? ¿Habéis probado alguna vez estas técnicas de traducción literaria? ¡Compartid vuestras experiencias y opiniones en los comentarios!