Saltar al contenido
Atareao con Linux
PodcastTecnologíaEspañol

Atareao con Linux

de atareao

NuevoATA 848 ArtCraft: haz que la IA trabaje por ti12 de noviembre de 2026 · 37 min
Episodios
848
Se publica
varias veces por semana
Último episodio
12 Nov 2026
Sitio webFeed RSS

Sobre el podcast

Disfruta conmigo de Linux y del Open Source. Aquí encontrarás como sacarle el máximo partido a tu entorno de escritorio Linux, hasta como montar un servidor web, un WordPress, un proxy inverso, una base de datos o cualquier otro servicio que puedas imaginar. Y todo ello, lo puedes montar en una Raspberry Pi, en un VPS, en tu propio ordenador o en cualquier servidor. Vamos, cualquier cosa que quieras hacer con Linux, seguro, seguro, que la encontrarás aquí.

Episodios 848

  1. ATA 848 ArtCraft: haz que la IA trabaje por ti

    37 minTemporada 9 · Episodio 848

    Llevamos meses hablando de lo que la inteligencia artificial está cambiando, y el escritorio de Linux no se ha quedado fuera. En este episodio te hablo de ArtCraft, pero no desde el enfoque de siempre: no vengo …

    Notas del episodio

    Llevamos meses hablando de lo que la inteligencia artificial está cambiando, y el escritorio de Linux no se ha quedado fuera. En este episodio te hablo de ArtCraft, pero no desde el enfoque de siempre: no vengo a decirte que estas herramientas van a acabar con Photoshop, con Word o con AutoCAD. Ya teníamos GIMP, Inkscape o LibreOffice y no acabaron con nada. La noticia es otra: son herramientas con las que la IA va a trabajar por ti.

    ArtCraft es una organización de GitHub, storytold, con decenas de repositorios. Dentro conviven dos mundos que no se mezclan: el estudio de creación con IA y la Craft App Suite, un conjunto de aplicaciones de escritorio escritas en Rust puro, sin Electron ni vistas web, con licencia dual MIT y Apache 2.0 y sin suscripción. Hay builds para Linux, macOS, Windows, FreeBSD, RISC-V y WebAssembly. Y lo verdaderamente importante: cada aplicación lleva dentro su propio servidor MCP. Eso significa que tu agente puede abrir el documento, escribirlo, darle formato, meter fórmulas, mover gráficos, exportarlo y guardarlo.

    En el episodio te enseño lo que he probado de verdad. Le pedí a OpenCode un documento sobre la desaparición de los dinosaurios y me lo devolvió en dos páginas, con sus encabezados y una línea temporal, sin abrir la aplicación. Con GridCraft salió un cuadro de mando con datos mensuales y gráficos por plataforma. Con FigCraft le dije que mirara atareao.es y me montó una maqueta en modo claro y oscuro. Con DeckCraft, una presentación entera de la que apenas corregí un par de cosas, y con EffectCraft un corto sencillo. También te cuento el detalle que casi nadie menciona: las aplicaciones suman 795 herramientas, y arrancarlas todas de golpe es un consumo de tokens brutal, así que conviene habilitarlas una a una según lo que vayas a hacer.

    Y hay que mirarlo con ojo crítico: todo está en alfa, muy alfa. PhotoCraft se llevó 78.700 estrellas y eso ha disparado el interés, pero a estas apps les falta recorrido, y con CADCraft no conseguí nada que mereciera la pena. Por eso yo sigo igual: mi documentación en Markdown y las presentaciones en Typst. Lo que me llevo es un software de escritorio que se está reescribiendo en lenguajes nativos, que es open source y que, sobre todo, le da manos a nuestros modelos de lenguaje.

    Lo que vas a aprender en este episodio:

    • Qué es ArtCraft y cómo se organiza entre el estudio de IA y la suite de apps nativas.
    • Qué es MCP y por qué tener un servidor dentro de cada aplicación cambia la forma de trabajar.
    • Cómo pedirle a tu agente un documento, una hoja de cálculo o una presentación y revisar el resultado.
    • Por qué conviene conectar las herramientas MCP una a una y no las 795 a la vez.
    • Cómo usar una app de diseño para generar la maqueta de tu web en claro y oscuro.
    • Dónde están los límites reales hoy: versiones alfa, funciones que faltan y tareas que aún se resisten.

    Más información y enlaces en las notas del episodio

  2. ATA 847 Integra tus notificaciones con tu IA

    21 minTemporada 9 · Episodio 844

    Durante los últimos años te he contado cómo gestionaba mis notificaciones: el correo, los avisos de cuándo se cae una web, los feeds RSS... Lo metía en Matrix, por canales. Funcionaba, pero tenía un problema de …

    Notas del episodio

    Durante los últimos años te he contado cómo gestionaba mis notificaciones: el correo, los avisos de cuándo se cae una web, los feeds RSS... Lo metía en Matrix, por canales. Funcionaba, pero tenía un problema de fondo: era impersonal. Y cuando te llegan 300 avisos de golpe, leerlos uno a uno es una tortura. En este episodio te cuento cómo lo he resuelto integrando todo con un asistente basado en modelos de lenguaje.

    La idea es sencilla: un modelo de lenguaje es fantástico resumiendo y agrupando información. Le pasas muchos avisos y te devuelve solo lo que de verdad importa. Por ejemplo, de 18 alertas de caídas me deja tres: un resumen crítico de sitios que cayeron y volvieron, y dos actualizaciones de contenedores. Lo mismo con el correo: de 12 mensajes me agrupa 5 y me dice si alguno huele a phishing sin abrirlo. Ese es el valor real: recibir mejor, no más.Para lograrlo he partido el trabajo en dos piezas. La primera pieza: tú preguntas al asistente cuando quieres: revisa el correo, mira Strava, resúmeme lo pendiente. La segunda pieza: los servicios le inyectan información solos. El corazón de esta segunda parte es un endpoint, la API Notification, donde cualquier servicio envía un JSON con el mensaje, el origen, el autor, un nivel y la metainformación. Y aquí llega un aprendizaje clave: no parsees nada. El modelo entiende el JSON y convertirlo en lenguaje natural es justo su trabajo.

    Esa API tiene un detalle de seguridad. El endpoint de ingesta no usa sesión, sino una clave de ingesta. El token se muestra una única vez al crearlo, el servidor solo guarda su prefijo y su hash, y se puede revocar cuando quieras. Cualquier intento fallido responde con un 401 idéntico, sin pistas sobre si la clave existe o está revocada. Hay endpoints con sesión para listar lo no leído y marcarlo como leído. Y otras integraciones —ApiMail para el correo, Miniflux para los RSS o Strava para los entrenamientos— siguen la misma filosofía.

    Al final, es un cambio de enfoque: pasar de que las notificaciones te asalten el móvil a un modelo proactivo, donde tú decides cuándo preguntar y el asistente te entrega todo agrupado y priorizado. Un episodio que cierra el arco de memoria, herramientas e integración.

    Capítulos
    0:00 - Introducción: gestionar las notificaciones con IA
    3:26 - El arco de episodios: memoria, herramientas e integración
    5:02 - Dos formas de uso: consultar al asistente e inyectar información
    6:10 - Resumen y agrupación de notificaciones y correos
    8:05 - La API Notification: ingesta con JSON sin parsear
    9:55 - Endpoints y clave de ingesta: sesión frente a integración
    10:29 - Claves de ingesta: token, seguridad y revocación
    13:53 - Estructura del mensaje y el buzón
    15:02 - Servicios integrados: ApiMail, Miniflux y Strava
    16:35 - Discriminar la información y el enfoque proactivo
    19:20 - Cierre y despedida

    Más información y enlaces en las notas del episodio

  3. ATA 846 Que tu IA te dibuje los diagramas

    24 minTemporada 9 · Episodio 846

    Hoy te cuento cómo he dejado de dibujar diagramas a mano. Porque el problema no es dibujar: el problema es que el diagrama envejece. Lo haces un martes con sus cajas de colores y sus flechas bien alineadas …

    Notas del episodio

    Hoy te cuento cómo he dejado de dibujar diagramas a mano. Porque el problema no es dibujar: el problema es que el diagrama envejece. Lo haces un martes con sus cajas de colores y sus flechas bien alineadas, tocas una línea de código el miércoles y el dibujo sigue contando la historia de antes. Una caja que ya no existe, un servicio que se partió en dos y una flecha que apunta a un sitio por el que ya no pasa nadie. Es un mentiroso de museo, impecable y falso.

    En el episodio 845 te hablé de cómo le di manos a mi asistente con 33 herramientas. Hoy le doy una más, pero distinta: un MCP de Excalidraw conectado a OpenCode. No para que genere una imagen bonita, sino para que controle un lienzo vivo, elemento a elemento. El agente dibuja, mira lo que ha dibujado y se corrige: alinea cajas solapadas, mueve etiquetas cortadas y repite hasta que está bien. Es un bucle cerrado en el que el que dibuja es el mismo que revisa.

    Mermaid ya prometió los diagramas como texto y lo cumplió: son reproducibles, diffeables y versionables. Pero tiene una grieta: no hay lienzo. El layout lo decide el motor y para mover una caja dos píxeles te toca editar sintaxis o pelearte con CSS. Excalidraw es lo contrario: arrastras, colocas y ajustas. Y ahora el que arrastra es el modelo de lenguaje, gracias al MCP.

    Hay dos MCP de Excalidraw: el oficial, con dos herramientas, y un toolkit con 26, lienzo con sincronización y exportación a PNG y SVG. Yo uso el toolkit. Lo instalo como skill en OpenCode con un npx, sin cuentas, sin API keys y sin clonar repos, y todo vive en mi equipo. En el episodio lo ves en directo: un cuadrado, un relleno, un triángulo, la evolución del hombre con sus ramas extintas y un diagrama funcional de oxidav, mi calendario CalDAV.

    Y lo importante: el fichero .excalidraw se commitea junto al código, así que cualquier cambio se refleja en el diagrama y se ve en el diff. El PNG se regenera en CI sin navegador y sin phantom diffs. También te cuento los límites sin dramatizar y te doy el criterio para elegir entre Mermaid y Excalidraw MCP.

    Capítulos
    0:00 - Intro: de la imagen muerta al diagrama editable
    2:33 - El diagrama que miente cuando el código evoluciona
    4:24 - Anuncios parroquiales: cambios en los repos
    4:51 - El diagrama no vive con tu código (y Mermaid tampoco lo arregla)
    6:22 - La propuesta: Excalidraw y un MCP con lienzo vivo
    9:12 - El bucle cerrado: dibuja, mira y corrige
    10:29 - Dos MCP y el toolkit de 26 herramientas
    10:58 - Instalarlo en OpenCode: un skill sin cuentas ni API keys
    11:52 - Demos: un cuadrado, la evolución del hombre y oxidav
    16:31 - Git y versionado: el diagrama como un fichero más
    20:43 - Límites y veredicto frente a Mermaid
    20:43 - Límites y veredicto frente a Mermaid
    22:06 - Cierre: dibuja una vez y actualízalo siempre

    Más información y enlaces en las notas del episodio

  4. ATA 845 ¿Cómo se le dan manos a una IA?

    26 minTemporada 9 · Episodio 845

    Hoy te cuento cómo le he dado manos a mi asistente. En el episodio 843 te hablé de la memoria; ahora toca lo otro, porque un asistente que solo habla es un loro. Igual que un chat al uso: parece entenderlo todo …

    Notas del episodio

    Hoy te cuento cómo le he dado manos a mi asistente. En el episodio 843 te hablé de la memoria; ahora toca lo otro, porque un asistente que solo habla es un loro. Igual que un chat al uso: parece entenderlo todo y no puede hacer nada. No lee tu correo, no te gestiona el calendario, no te apunta una idea.

    Un modelo de lenguaje no es el problema. Lo que le falta son herramientas: funciones que puede decidir invocar. En mi caso, 33 herramientas repartidas en 12 habilidades o skills: correo, calendario, tareas, diario, notas, RSS, meteorología, búsqueda de lugares, web, Strava, recordatorios y widgets. Cada bloque lleva su ficha y su criterio de activación.

    Pero dar manos tiene un peaje. Las definiciones de esas 33 herramientas suman unos 11.000 tokens que viajan al modelo en cada mensaje. Pedir «hola» cuesta lo mismo que pedir «busca una cafetería cerca». Así que metí un segundo modelo, un enrutador, que decide por intención qué habilidad anunciar en cada turno. Con eso bajé el gasto cerca de un 25 %, y una petición como la de la cafetería se resuelve con seis herramientas.

    Y cuando ya tienes manos aparece el segundo problema: la responsabilidad. No es lo mismo leer tu agenda que borrarla, ni resumir un correo que enviarlo en tu nombre. De ahí los tres niveles de permiso: sin preguntar, avisándote, y pidiendo tu sí explícito. La regla que resume todo: el silencio no es un permiso. Si te pide borrar y no contestas, en cinco minutos expira y se toma como un no.

    Cierro con las integraciones que están por llegar —Strava, notificaciones, noticias— y el avance del último episodio de la trilogía. Si quieres montar tu propio asistente, en el repositorio lo tienes en Docker.

    Capítulos
    0:00 - Introducción y repaso: de la memoria del 843 a las manos del asistente
    1:26 - Anuncios parroquiales: err-serve, valet, podtrack y el MCP de atareao.es
    6:03 - Del loro al asistente: por qué un chat sin manos no sirve
    7:26 - Las 33 herramientas repartidas en fichas y skills
    9:52 - El coste oculto: 11.000 tokens por un «hola»
    12:35 - El enrutador de herramientas: decidir qué enviar en cada mensaje
    14:32 - Agenda, tareas, recuerdos y las herramientas fijas de hora y ubicación
    18:13 - Ejemplo real: «busca una cafetería cerca» y el ahorro del 25 %
    19:40 - Permisos y responsabilidad: avisar, preguntar y el silencio que no es un permiso
    23:05 - Integraciones (Strava, notificaciones, noticias) y cierre del episodio

    Más información y enlaces en las notas del episodio

  5. ATA 844 Podman, IPs reales y La Liga

    25 minTemporada 9 · Episodio 844

    Hoy te cuento una historia que empieza bien y acaba dándote un susto. Llevo tiempo moviendo atareao.es a contenedores y ha ido por fases. En casa ya solo tengo Podman rootless, sin demonio y sin pedirle permiso …

    Notas del episodio

    Hoy te cuento una historia que empieza bien y acaba dándote un susto. Llevo tiempo moviendo atareao.es a contenedores y ha ido por fases. En casa ya solo tengo Podman rootless, sin demonio y sin pedirle permiso a root para nada. En el servidor donde vive atareao.es, en cambio, seguía con Docker en modo root y con demonio. Dos filosofías distintas.

    Cuanto menos permisos tenga un contenedor, mejor. Si algo se escapa de uno montado como root, el destrozo puede ser de aúpa. Así que me pasé a rootless, aunque tuviera que repensar medio montaje.

    Y aquí llega lo que me da rabia. Hace un par de años atareao.es se caía, se disparaba el consumo de CPU y se venía abajo. Sin mirar un log, sin una gráfica, sin una prueba desde fuera, decidí que el problema era del proveedor y me lo llevé a otro. Ya con los datos delante descubrí que el culpable estaba dentro: Redis, que hoy es Valkey.

    En el servidor monto un Traefik delante y detrás WordPress, MariaDB, Valkey, Umami y OpenGist. Uso Umami por una razón concreta: no pone cookies, no recoge datos personales y no sigue al visitante entre sitios. Que no necesite banner de consentimiento ya es bastante.

    Pero había un agujero que no veía. Fue Víctor quien me lo puso delante: con Podman rootless la visita llega al contenedor, sí, pero con la IP de origen cambiada por el camino. Sin IP real, Umami no sabe ni de qué país viene quien te lee. Lo apañé poniendo Cloudflare delante y fiándome de su cabecera. Fantástico, hasta que un sábado por la tarde dejó de funcionar.

    Perdí un par de horas hasta que lo entendí: no era rootless, ni Traefik, ni nada de mi montaje. Era un bloqueo por rangos enteros de IP, de los que dejan media internet sin servicio. Así que me quité el apaño y puse un HAProxy en bare metal en el 443 para mandar todo a Traefik rootless en un puerto alto. Ni puertos privilegiados, ni setcap, ni iptables: la IP real de vuelta y las redes aisladas.

    Si te toca, esto es lo que puedes hacer. Guarda el dominio, el operador, la hora y el error. Mide con dig, con mtr y con OONI Probe, publica lo que sale y denuncia. Solo así se da la vuelta. Y quédate con una idea: casi nunca falla lo que crees, falla lo que no mides.

    Capítulos
    00:00 - De Docker a Podman: el planteamiento
    02:34 - Dos mundos: Podman rootless en casa y Docker root en el servidor
    04:34 - atareao.es se caía y culpé a Contabo sin medir
    05:23 - El culpable estaba dentro: Redis y Valkey
    06:59 - Traefik, WordPress y Umami: cómo monto la infraestructura
    09:35 - Víctor me abre los ojos: las IPs reales no llegan
    11:56 - Rootless y la IP de origen: el parche de Cloudflare
    14:08 - La Liga bloquea rangos de IP: qué puedes hacer
    16:19 - HAProxy al 443 y Traefik bajando al 8443
    19:13 - Sin setcap ni iptables: por qué Traefik sigue en contenedor
    22:13 - Cierre: casi nunca falla lo que crees, falla lo que no mides

    Más información y enlaces en las notas del episodio

  6. ATA 843 ¿Cómo se le da memoria a una IA?

    27 minTemporada 9 · Episodio 843

    Hoy te cuento cómo le he dado memoria a mi asistente. No es un tutorial, son las ideas que he ido montando por si te sirven. La IA no recuerda nada: le pasas toda la conversación una y otra vez y cada sesión …

    Notas del episodio

    Hoy te cuento cómo le he dado memoria a mi asistente. No es un tutorial, son las ideas que he ido montando por si te sirven. La IA no recuerda nada: le pasas toda la conversación una y otra vez y cada sesión nueva empieza de cero.

    Hace unos episodios te hablé del asistente que monté para el viaje al sur de Italia. Allí me topé con dos paredes: la pieza que hacía de centro se quedaba corta y la memoria, que en cuanto me descuidaba ya no sabía qué había hecho un momento antes. Un asistente que no recuerda nada es un buscador con modales. Así que lo monté todo: herramientas y varias memorias, en Docker con Rust y React.

    Y una memoria no es un cajón: si metes datos y no decides qué hacer con ellos, no vale para nada. De ahí salen las cinco capas. La primera es lo que dije, la conversación en bruto en SQLite. La segunda es lo que pasó: cada 2.000 tokens genero una ficha del contexto y la convierto con un RAG para buscarla de forma semántica. Guardo toda la conversación, pero busco en las fichas.

    La tercera es cómo soy: otro proceso extrae lo que puede de mí y construye un retrato, quién eres, qué te gusta, cómo quieres que te traten. Cosas como que a mí no me gusta el cilantro. La cuarta son los hechos sueltos con fecha. Y la quinta, la que más me ha gustado, el diario que se escribe solo. Siempre he fallado el primer día, así que ahora lo escribe el asistente.

    Cuando busco traigo los 20 recuerdos relacionados con lo que hablo y los pondero por fecha: lo reciente pesa más. Solo las fichas, el retrato y algún detalle van en el system prompt, y eso son 15.000 tokens por llamada. Hay unas 20 herramientas y 11 skills, y se activan las que tocan.

    Y te lo confieso: no hay botón de olvidar. El asistente recuerda lo que tiene dentro y no puedo hacer que se le olvide nada, solo ponderar por tiempo. La herramienta se llama Valet y está en GitHub con licencia MIT. Las estadísticas: nueve millones de tokens por un euro, 0,16 dólares en siete días, 1.355 llamadas y 563 mensajes guardados. Quédate con la idea: usar el modelo para las tareas sistemáticas de cada día, como el diario 😊

    Capítulos
    0:00 - Presentación: dar memoria a una IA y decidir qué hacer con ella
    2:15 - El asistente POC del viaje al sur de Italia
    4:10 - Un asistente sin memoria es un buscador con modales
    5:20 - Un paso más: contenedor Docker con Rust y React
    6:25 - Corto plazo y largo plazo: las distintas memorias
    9:40 - Lo que dije, lo que pasó y cuándo: conversación en bruto en SQLite y fichas con búsqueda semántica
    12:12 - Hechos sueltos, el retrato y los procesos en paralelo
    15:00 - El diario que se escribe solo
    17:05 - El proceso completo y el peso del tiempo en los recuerdos
    19:15 - Valet: en GitHub con licencia MIT, modelos y consumo de tokens
    22:45 - Los prompts de cada memoria: archivista, colapsador, consolidador, timeline y diario
    24:26 - Cierre y despedida: la red de Sospechosos Habituales y el grupo de Telegram

    Más información y enlaces en las notas del episodio

  7. ATA 842 ffmpeg, afina el oído de tu IA

    21 minTemporada 9 · Episodio 842

    Arrancamos la serie de los sentidos de la IA por el más básico. Después de darle a tu modelo de lenguaje una memoria para buscar entre tus 6.000 o 7.000 documentos, toca darle sentidos, y el primero es el oído …

    Notas del episodio

    Arrancamos la serie de los sentidos de la IA por el más básico. Después de darle a tu modelo de lenguaje una memoria para buscar entre tus 6.000 o 7.000 documentos, toca darle sentidos, y el primero es el oído. Hoy te hablo de FFmpeg, la pieza que hace que lo demás funcione.

    FFmpeg es la navaja suiza del audio y el vídeo: está dentro de YouTube, VLC, Blender o del vídeo que ves en el navegador. Lo instalas con un apt install o un pacman y tienes un taller multimedia en un solo binario. Convertir de MP3 a WAV o a FLAC sin pérdida te cuesta una línea.

    El meollo es que Whisper no traga cualquier audio. Se entrenó con 680.000 horas de audio limpio a 16 kHz y en mono, así que espera PCM de 16 bits, un solo canal y 16 kHz, sin compresión. Si le das un MP3 a 44,1 kHz en estéreo y con silencios largos te lo puede transcribir, pero se arriesga a alucinar y a rellenar los silencios. Casi nunca el problema es el modelo, es cómo le das la entrada.

    Con un alias que convierta a ese formato ya tienes medio camino. Luego están loudnorm para normalizar el volumen y el filtro que quita los silencios de más de un segundo, la causa número uno del texto inventado, y una trampa con silenceremove que te cuento con detalle. También hablamos de cortar y unir con -ss, -t y concat.

    Y no solo sirve para preparar el audio que entra, también para postprocesar el que sale del TTS. Un motor local como Piper o Kokoro devuelve una voz plana, sin dinámica, que suena a robot con resaca. Con un paso alto, un compresor y un loudnorm final pasas de sonar a radio AM a sonar a FM, todo dentro de la pipeline de micrófono a altavoz con los scripts en Python.

    Para cuando el audio llega muy sucio hay tres filtros que salvan la grabación: afftdn contra el ruido constante del ventilador, adeclick para chasquidos y pops, y un equalizer que sube la banda de presencia de la voz. Una grabación en una cafetería queda usable para Whisper. Limpiar siempre antes de normalizar, porque si amplificas primero también amplificas el ruido.

    Sin FFmpeg, Whisper falla, el texto a voz suena a lata y la pipeline de voz no existe. Hoy hemos puesto los cimientos, y ahora llegan Whisper, el texto a voz, la visión artificial y un extra sobre OCR 😊

    Capítulos
    0:00 - De la memoria de tu IA a los sentidos: la nueva serie
    1:33 - La serie de los sentidos y el audio sucio que llega a tu IA
    3:14 - FFmpeg, la navaja suiza del audio y el vídeo
    5:57 - Instalar FFmpeg y convertir formatos en una línea
    7:27 - El meollo: cómo espera Whisper el audio (16 kHz, mono, 16 bits)
    10:01 - El alias whisperize, loudnorm a -23 LUFS y quitar silencios
    11:19 - Cortar y unir audio: -ss, -t, concat y fundidos
    13:14 - Postprocesar la voz del TTS: de radio AM a FM
    15:25 - La pipeline completa de voz y los scripts en Python
    17:05 - Audio muy sucio: afftdn, adeclick y equalizer
    18:29 - Conclusiones, despedida y comunidad

    Más información y enlaces en las notas del episodio

  8. ATA 841 GraphRAG, tus notas por fin responden (y sin inventarse nada)

    23 minTemporada 9 · Episodio 841

    Te tengo que confesar una cosa. En el episodio anterior, haciendo pruebas, me ventilé toda la información del GraphRAG y me tocó reindexarlo entero. Casi 6.300 notas otra vez, con el Slimbook echando humo. Me …

    Notas del episodio

    Te tengo que confesar una cosa. En el episodio anterior, haciendo pruebas, me ventilé toda la información del GraphRAG y me tocó reindexarlo entero. Casi 6.300 notas otra vez, con el Slimbook echando humo. Me ha costado lo suyo, pero ya está. Y ahora toca lo bueno, porque el grafo está montado y solo falta interrogarlo. Este es el cierre de la trilogía, donde el grafo deja de ser un mueble y por fin responde.

    Lo primero es por qué no basta con una sola técnica. El vector te dice qué se parece a tu pregunta, y el grafo te dice qué está conectado. Si buscas un servidor web seguro, el vector acierta de pleno con la nota de hardening. Pero la nota de Certbot no dice esas palabras, así que un RAG clásico la pierde. El grafo la rescata porque está conectada con Nginx y https. Ni grep ni ripgrep te habrían dado eso.

    También te doy las cifras reales del grafo, más de 20.000 nodos, unas 6.300 notas, 15.000 entidades y 46.000 trozos con embeddings. Y la arquitectura híbrida, en tres pasos, primero lo vectorial, después el re-ranking por peso y por último la expansión por grafo, que recupera vecinos a uno o dos saltos. Todo lo modula el parámetro alfa, por defecto en 0,7, donde el significado manda y la conexión complementa.

    Y lo probamos con comandos de verdad. Con graphrag search lanzas la búsqueda y ves cómo cambian los resultados al mover el alfa. Con la profundidad controlas los vecinos que recuperas, con 0 te quedas en lo vectorial y con 2 abres dos saltos de grafo. Te enseño a filtrar por peso mínimo, por metadatos y por tipo de elemento.

    Después viene lo que más me gusta, graphrag ask. No te devuelve notas sueltas, te devuelve una respuesta redactada con Ollama en local y con las fuentes citadas al pie. Le preguntas cómo configurar Traefik y te da los pasos apoyándose en tus notas. Y cuando no tiene información, no se la inventa. En el ejemplo con GIMP solo encontró una nota y te lo dice tal cual. Hablo también de las comunidades y del build incremental, que solo procesa lo que has tocado, ideal para un cron.

    Capítulos
    0:00 - Introducción: el cierre de la trilogía GraphRAG y el reindexado del grafo
    2:13 - Repaso de la trilogía: qué es un GraphRAG y para qué sirve
    4:14 - Vector frente a grafo: por qué necesitas las dos cosas
    6:53 - Las cifras del grafo: nodos, notas, entidades y comunidades
    7:52 - La arquitectura híbrida en tres pasos y el parámetro alfa
    9:17 - Primera búsqueda: cómo montar un proxy inverso y el efecto del alfa
    11:21 - Profundidad de vecinos, Ollama y cómo interpretar los resultados
    13:53 - Filtros: min-weight, metadatos y tipos de elemento
    14:52 - graphrag ask: preguntas con fuentes citadas (cómo configuro Traefik)
    16:54 - Comunidades: build incremental y automatización con cron
    17:42 - Ejemplo con GIMP: búsqueda, ask y la ventaja de no alucinar
    17:42 - Ejemplo con GIMP: búsqueda, ask y la ventaja de no alucinar
    20:28 - Flecos pendientes: integración MCP con Neovim, bot de Obsidian y despedida

    Más información y enlaces en las notas del episodio: https://atareao.es/podcast/841

    🌐 Todo en https://atareao.es · ✈️ Telegram https://t.me/atareao_con_linux · 🦣 Mastodon https://mastodon.social/@atareao · 🐦 Twitter https://twitter.com/atareao · 🐙 GitHub https://github.com/atareao

  9. ATA 840 sqlite-utils, tu navaja suiza para SQLite

    27 minTemporada 9 · Episodio 840

    Llevo varias semanas construyendo un grafo de conocimiento con GraphRAG sobre SQLite, y en ese día a día me he topado con sqlite-utils, una herramienta que se ha convertido en mi navaja suiza para trabajar con …

    Notas del episodio

    Llevo varias semanas construyendo un grafo de conocimiento con GraphRAG sobre SQLite, y en ese día a día me he topado con sqlite-utils, una herramienta que se ha convertido en mi navaja suiza para trabajar con bases de datos SQLite sin complicarme la vida. Es de esas utilidades que no sabías que necesitabas hasta que la pruebas.

    Te preguntarás por qué SQLite y no PostgreSQL o cualquier solución más seria. La respuesta es sencilla, porque necesito algo que quepa en mi equipo, que sea portátil y que pueda llevarme en un USB sin montar un servidor. Todo tu conocimiento, en un solo archivo que abres donde quieras.

    El problema de siempre ha sido inspeccionar esas bases. Abrir DBeaver o tirar de Python solo para mirar qué hay dentro da una pereza enorme, y al final acabas dejándolo. sqlite-utils, creada por Simon Willison, resuelve justo eso, y te permite consultar, filtrar, transformar y exportar sin escribir una línea de SQL ni de Python.

    Para que te hagas una idea, aquí hay dos cosas en una sola herramienta, una utilidad de línea de comandos y una librería de Python que no pretende ser un ORM. Nació dentro del ecosistema de Datasette, y busca que crear una base desde cero y poblarla con datos sea rápido y sin fricción. En mi caso ha acabado sustituyendo a los comandos sueltos de sqlite3 que tenía repartidos por las notas.

    Otro terreno donde se nota la mano es la ingesta. Con insert metes un JSON que llega por la tubería, un CSV de los que exportas de cualquier sitio, o la respuesta de una API con un curl delante. Con upsert y bulk actualizas registros que ya existían o metes miles de filas de golpe, y todo eso se encadena con jq en una sola tubería.

    Luego está la parte de cambiar las cosas sin dolor, renombrar una columna, borrar la que sobra o cambiar un tipo de dato. En SQL puro eso es un baile de create table, copiar los datos y borrar la tabla vieja, con el riesgo de liarla a mitad de camino. Aquí es un transform, se ejecuta dentro de una transacción y el esquema queda reescrito como si lo hubieras diseñado así desde el principio.

    En este episodio te cuento cómo instalarla con uv, cómo explorar tablas y esquemas, cómo navegar los datos con rows, cómo filtrar de forma segura con parámetros con nombre y cómo montar consultas complejas con joins. Además verás el combo que más me ha enganchado, sqlite-utils encadenado con jq y con llm para pasar el contexto de tu base directamente a un modelo de lenguaje. Y de propina, los detalles de mantenimiento que marcan la diferencia, como WAL, Vacuum, Optimize y la búsqueda full-text.

    Si tienes una base SQLite por ahí y nunca te has atrevido a mirar dentro, este es tu episodio 👍

    Capítulos
    0:00 - Presentación: sqlite-utils, la navaja suiza de SQLite
    2:20 - Por qué SQLite: GraphRAG, portabilidad y contexto de la serie
    4:20 - El problema de DBeaver y qué resuelve sqlite-utils
    6:00 - Instalación con UV y primeros pasos
    8:30 - Explorar tablas, columnas y esquemas
    11:30 - Navegar los datos con rows
    14:00 - Filtrar con where, ordenar y evitar inyección SQL
    16:30 - Consultas complejas, joins y selects a medida
    18:30 - El combo killer: sqlite-utils + jq + LLM
    20:30 - Escribir y transformar: insertar, crear, exportar y renombrar
    23:00 - El módulo Python y los consejos: WAL, Vacuum, Optimize y FTS
    25:20 - Conclusiones y lo que viene en el 841

    Más información y enlaces en las notas del episodio: https://atareao.es/podcast/840

    🌐 Todo en https://atareao.es · ✈️ Telegram https://t.me/atareao_con_linux · 🦣 Mastodon https://mastodon.social/@atareao · 🐦 Twitter https://twitter.com/atareao · 🐙 GitHub https://github.com/atareao

  10. ATA839 Convierte 6000 notas en un cerebro conectado

    29 minTemporada 9 · Episodio 839

    Llevo más de 6.000 notas en Markdown acumuladas desde 2008, y siempre he estado convencido de que ahí estaba todo lo que he aprendido. Hasta que busco y no encuentro. Busco particiones y no aparece nada sobre …

    Notas del episodio

    Llevo más de 6.000 notas en Markdown acumuladas desde 2008, y siempre he estado convencido de que ahí estaba todo lo que he aprendido. Hasta que busco y no encuentro. Busco particiones y no aparece nada sobre redimensionar un volumen. Busco monitorización de red y mis notas hablan de ntopng e iftop sin usar esas palabras. El conocimiento estaba ahí, pero yo no sabía que estaba.

    En el episodio 837 te conté la teoría del GraphRAG. En este 839 vamos a lo práctico, a convertir esas 6.000 notas en un grafo de conocimiento con IA 100 % local, sin nube, sin claves API y sin que ninguna nota salga de tu equipo.

    Lo primero es el chunking, trocear cada nota en ideas autónomas. Y no se trocea por número de caracteres, sino por estructura. Cada sección o subcapítulo es un fragmento, el frontmatter se separa como metadatos, los bloques de código viajan enteros y lo que baja de 50 caracteres se descarta. Trocear por caracteres solo rompe un bloque de código o una lista justo por la mitad.

    Después viene el NER (Named Entity Recognition), que convierte texto libre en entidades con etiqueta, tipo y confianza. Uso llama3.2:3b con Ollama y solo conservo lo que supera 0,5 de confianza. Prefiero perder una entidad dudosa antes que llenar el grafo de ruido, porque un grafo con ruido no te sirve.

    Con eso se construyen nodos y aristas. La nota es el documento entero, la entidad puede ser Nginx, Certbot o SSL, y las etiquetas salen de las carpetas y del frontmatter. Hay cuatro tipos de arista y cada una lleva su peso. La co-ocurrencia usa el mínimo de las dos confianzas, no la media.

    Para construir todo esto ejecutas graphrag build. No empieza de cero, cada nota guarda un hash SHA256 y solo reprocesa lo que ha cambiado. En mi caso encontró 6.333 archivos y le faltaban 81, unos seis minutos, con cuatro hilos y un único escritor sobre SQLite. Y luego están las comunidades, la visión global. El algoritmo Leiden agrupa los conceptos muy conectados entre sí, porque los amigos de mis amigos tienden a formar un grupo.

    Todo esto es graphrag-search, un único binario en Rust que instalas con cargo install graphrag-search. Ni Python, ni NPM, ni servidores. Con dos modelos pequeños de Ollama, bge-m3 para embeddings y llama3.2:3b para el NER, tienes tu propio cerebro conectado para encontrar episodios y conceptos relacionados.

    Capítulos del episodio:
    0:00 - Introducción: convertir 6.000 notas en un cerebro conectado
    2:45 - Qué veremos hoy y la trilogía GraphRAG
    4:20 - Chunking: trocear las notas en ideas autónomas
    7:50 - NER: extraer entidades con un modelo local
    7:50 - NER: extraer entidades con un modelo local
    11:20 - Etiqueta, tipo y confianza: qué guardamos de cada entidad
    13:50 - Nodos y aristas: conectar tus notas con semántica
    17:10 - Construir el grafo con graphrag build
    20:20 - SQLite e incrementalidad: el grafo que se actualiza solo
    24:10 - Comunidades con el algoritmo Leiden
    27:00 - Cierre y avance del siguiente episodio


    Más información y enlaces en las notas del episodio


  11. ATA 838 Deja de escribir Python, doma YAML y JSON con yq y jq

    26 minTemporada 8 · Episodio 838

    Los metadatos de tus notas son puro oro, y me da la sensación de que todavía no lo sabes. Tienes títulos, fechas de creación, etiquetas... toda esa información del front matter de cada Markdown que, la mayoría …

    Notas del episodio

    Los metadatos de tus notas son puro oro, y me da la sensación de que todavía no lo sabes. Tienes títulos, fechas de creación, etiquetas... toda esa información del front matter de cada Markdown que, la mayoría de las veces, se queda ahí muerta de risa sin que le saques partido. En los episodios 819 y 821 te conté cómo la extraía con Python para montar un grafo de conocimiento. Funcionaba, pero para cualquier consulta rápida tenías que abrir el script, tocar el código y volver a ejecutarlo. Eso no es ágil.

    En este episodio te presento al dúo dinámico: jq y yq. Dos herramientas que hacen una sola cosa y la hacen de maravilla, esa vieja filosofía UNIX que tanto nos gusta. jq es el procesador de JSON de referencia desde 2012, escrito en C y presente en casi todas las distribuciones. yq es el mismo concepto para YAML, XML, INI, TOML y CSV, escrito en Go por Mike Farah y distribuido como un binario único sin dependencias. Con las dos, y sin escribir ni una línea de Python, vas a extraer, filtrar y conectar los metadatos de tus notas.

    Arrancamos con lo básico de jq, sus filtros y sus cuatro funciones estrella, select, unique, map y group_by. Son las que vas a reutilizar una y otra vez. Después pasamos a yq y a su joya de la corona, el soporte nativo de front matter. Con una línea tipo yq --front-matter=extract '.tags' nota.md sacas las etiquetas de una nota, y con -i la editas in place, algo que jq no permite. Actualizar la fecha de modificación, añadir un tag nuevo o convertir de YAML a JSON y al revés sin salir de la terminal.

    Y luego llega la parte divertida, los pipelines. Encadenando fd, yq y jq consigues una lista limpia de los tags de tu vault, un informe con cuántos documentos usan cada etiqueta o el grafo de conocimiento completo en JSON, con nodos y aristas, sin Python y sin IA. También te enseño a detectar esas notas viudas que no tienen etiqueta y a cerrar el círculo pasando ese JSON a un modelo local con Ollama, para que te clasifique las notas y te diga qué conexiones hay entre ellas.

    Terminamos con los errores más habituales, que ya me he encontrado de todo. Que yq solo procesa el primer documento si le pasas varios ficheros, que un front matter sin los delimitadores --- no lo reconoce nadie, o que jq no tiene edición in place. Pequeños tropiezos que te ahorro para que no pierdas media tarde peleándote con la terminal.

    Si tienes un vault de notas, aunque sean solo diez archivos, este episodio te va a cambiar la forma de trabajar con ellos. Y si te gusta domar tus datos con herramientas pequeñas y afiladas, más todavía. Suscríbete al podcast, déjame una valoración y compártelo con quien todavía escriba un script de Python para leer un YAML. La semana que viene, en el 839, seguimos con el grafo de conocimiento y la IA local.

    Capítulos:
    0:00 - Introducción: yq y jq, el dúo dinámico
    3:15 - Filosofía UNIX: domar datos sin escribir Python
    5:45 - Qué es jq y qué es yq
    8:00 - Filtros básicos con jq
    10:45 - Funciones clave de jq: select, unique, map y group_by
    13:15 - yq y Front Matter: extraer metadatos
    16:00 - Edición in-place y conversión YAML ↔ JSON
    18:30 - Pipelines: fd + yq + jq para extraer tags
    21:00 - Del Front Matter al grafo de conocimiento
    22:45 - Notas viudas y pipeline con IA local
    24:30 - Errores comunes, conclusiones y despedida

    Encontrarás todos los comandos y las notas del episodio en atareao.es, y si quieres participar en la comunidad, tenemos el grupo de Telegram en t.me/atareao_con_linux, además de la red de podcast Sospechosos Habituales en feedpress.me/sospechososhabituales. Un saludo y nos escuchamos el próximo lunes 🐧

    Más información y enlaces en las notas del episodio

  12. ATA 837 Conecta tus notas con IA, el fin de las búsquedas que fallan

    32 minTemporada 9 · Episodio 837

    Hay algo que me pasa desde hace años y que seguro que a ti también te suena. Voy tomando notas en Markdown, las organizo por temas y por proyectos, les pongo etiquetas, y en mi cabeza todo tiene sentido. Hasta …

    Notas del episodio

    Hay algo que me pasa desde hace años y que seguro que a ti también te suena. Voy tomando notas en Markdown, las organizo por temas y por proyectos, les pongo etiquetas, y en mi cabeza todo tiene sentido. Hasta que un día busco algo con grep y no aparece. No es que la nota no exista, es que mi yo del pasado usó otras palabras y la búsqueda clásica no compara significados, compara letras. Tienes el conocimiento, pero no tienes el mapa.

    En este episodio te hablo de GraphRAG, esa evolución del RAG que une vectores y grafos de conocimiento para que tus notas dejen de ser ficheros aislados. Primero te cuento por qué la búsqueda literal falla justo cuando tu cerebro digital crece, con esos tres ejemplos de siempre. Buscas particiones y la nota se llama Redimensionar LVM. Buscas monitorización de red y tienes guardadas ntopng e iftop. Buscas alta disponibilidad y aparecen keepalived, Nginx y certificados sin que se vean como un mismo sistema.

    Después repasamos los tres límites del RAG clásico. El fragmento pierde el contexto, no entiende relaciones y no tiene visión global. Y ahí entran los grafos, con sus nodos, sus aristas y sus pesos, que no escribes a mano, sino que genera el sistema leyendo tus propios .md. Con la idea de fondo bien clara: los vectores te dicen a qué se parece algo, el grafo te dice cómo se conecta.

    Luego lo ves funcionar de verdad, con un único binario en Rust, SQLite embebido y Ollama para los embeddings y el reconocimiento de entidades. Todo local, sin Python ni contenedores, y lo puedes llevar en un pendrive. Te enseño cómo se crea el grafo, cómo se exploran las estadísticas, la diferencia entre la búsqueda semántica y la literal, cómo se trazan rutas entre dos conceptos que nunca aparecen juntos en una nota, el mapa en la terminal y la integración con Neovim para que te sugiera notas relacionadas mientras escribes.

    De fondo hay toda una familia de soluciones. Microsoft GraphRAG formalizó la idea con su pipeline de comunidades, LightRAG la hizo más ligera e incremental, y aquí tienes una versión utilitaria, personal y offline que cabe en un único binario. No es un clon de nada, es la misma idea llevada a mi terreno.

    Un aviso honesto, porque me gusta contar las cosas como son. Sin Ollama no hay magia, la búsqueda vectorial necesita el modelo vivo. Es el precio de tenerlo todo en casa y bajo tu control, que para mí vale la pena.

    Esto es solo la primera parte de una serie. Hoy entendemos qué es GraphRAG, en el episodio 839 construimos el grafo con tus notas y en el 841 aprendemos a interrogarle. Si llevas tiempo tomando notas y sientes que tu buscador te falla, este episodio es para ti.

    Capítulos:
    0:00 - Introducción: notas, Zettelkasten y el cerebro digital
    3:56 - Por qué la búsqueda clásica (grep) falla
    7:05 - Qué es GraphRAG: embeddings y vectores
    10:45 - Los tres límites del RAG clásico
    13:40 - Grafos de conocimiento: nodos, aristas y pesos
    17:50 - La herramienta en Rust con Ollama
    20:20 - Demo: crear el grafo y explorar estadísticas en SQLite
    23:00 - Búsqueda semántica (search) frente a búsqueda literal (FTS)
    25:40 - Rutas y relaciones: path y graph
    28:10 - El mapa en la terminal (TUI)
    29:40 - Conclusiones y cierre


    Más información y enlaces en las notas del episodio


  13. ATA 836 Adiós a los bots. Blinda tu VPS con un WAF casero

    24 minTemporada 9 · Episodio 836

    Si tienes un VPS con los puertos 80 y 443 abiertos, este episodio te interesa. Cada día, bots de todas partes del mundo escanean tu servidor buscando una rendija por la que colarse. La solución no es cerrar las …

    Notas del episodio

    Si tienes un VPS con los puertos 80 y 443 abiertos, este episodio te interesa. Cada día, bots de todas partes del mundo escanean tu servidor buscando una rendija por la que colarse. La solución no es cerrar las puertas, sino poner un portero que sepa quién entra y quién se queda fuera. Ese portero se llama Shuul, y es el WAF casero del que te hablo en este episodio.

    Las cifras hablan solas. En las últimas 24 horas, mi VPS recibió 921.000 peticiones. De ellas, bloqueé 650.000. Eso es un 70% de tráfico no deseado. Y no solo hablo de bots escaneando puertos, también de intentos de acceso a rutas de WordPress, phpMyAdmin y vulnerabilidades conocidas. Shuul se encarga de filtrar todo eso antes de que llegue a tus servicios.

    En el episodio te cuento cómo funciona Shuul por dentro. Tiene dos pipelines independientes. El primero es el WAF, que actúa como forward auth de Traefik: cuando llega una petición, Traefik le pregunta a Shuul si la deja pasar. Aquí se evalúan reglas por IP, país, user-agent, URI y método HTTP, con pesos para decidir si se permite o se deniega. El segundo pipeline es el Jail, un sistema de rate limiting que actúa después de que el backend responde: si alguien acumula demasiados 401, 403 o 404, se le banea la IP con ventanas deslizantes y tiempos de ban que escalan.

    La arquitectura es ligera. Backend en Rust con Axum, frontend en React con TypeScript y shadcn/ui, y un pequeño plugin en Go que hace de reportero para Traefik. Todo montado en Docker con un binario estático de unos 20 megas. La base de datos es SQLite — no necesitas PostgreSQL para esto. La autenticación del panel la hago con OIDC a través de PocketID, nada de usuario y contraseña tradicionales.

    También te explico por qué descarté fail2ban. No me gusta porque es un proceso en Python que parsea logs. Shuul obtiene los datos directamente de Traefik, sin escrituras a disco, y trabaja a nivel HTTP, no a nivel de firewall de red. Además puedes crear reglas muy granulares: desde permitir una URL concreta para todo el mundo mientras bloqueas por país en el resto, hasta templates preconfigurados para SQL injection, escáneres de directorios o protección contra vulnerabilidades web.

    Y todo esto acompañado de un dashboard con gráficos en tiempo real, rankings por países bloqueados y logs en directo. Vamos, que no le falta detalle.

    Si tienes un servidor en casa o un VPS y estás harto de los bots, este episodio te va a venir como anillo al dedo. Shuul es código abierto, está en GitHub, y lo puedes desplegar en minutos con Docker Compose.


    Capítulos del episodio:
    0:00 - Introducción: Shuul, el guardián de tus datos
    2:30 - El problema: bots de Rusia, China y Vietnam escaneando tu VPS
    3:50 - Cifras impactantes: 921.000 peticiones, 650.000 bloqueadas en 24h
    5:30 - Por qué Traefik no basta y cómo nace Shuul
    6:30 - Arquitectura: backend en Rust, frontend en React y un módulo en Go
    8:30 - Pipeline WAF: forward auth, geolocalización cacheada y reglas regex
    10:40 - Pipeline Jail: Shuul Reporter y bloqueo por intentos fallidos
    13:00 - Configuración, variables de entorno e integración con Traefik
    16:00 - Reglas, pesos, templates: Allow, Deny, ubicaciones y nodos Tor
    18:30 - Dashboard, logs en tiempo real y reflexión final


    Más información y enlaces en las notas del episodio


  14. ATA 835 Mi propio asistente de viaje con IA. Más allá de escribir código

    37 minTemporada 835 · Episodio 9

    Este episodio no va de escribir código. Va de lo que pasa cuando te construyes tu propio asistente con inteligencia artificial, te lo metes en la mochila y te vas de viaje 10 días al sur de Italia. Spoiler …

    Notas del episodio

    Este episodio no va de escribir código. Va de lo que pasa cuando te construyes tu propio asistente con inteligencia artificial, te lo metes en la mochila y te vas de viaje 10 días al sur de Italia. Spoiler: funciona, cuesta menos de 2€ en APIs, y tu pareja no técnica acaba preguntándole a tu bot dónde comer antes que a Google Maps.

    Te cuento la historia de Minerva, un asistente de viaje que escribí en Rust durante las dos semanas antes de irme a Puglia. La interface es Matrix — le escribes desde el móvil como si fuera un contacto más. Por detrás lleva OpenRouter con DeepSeek V4 Flash, Google Places para buscar restaurantes y monumentos, Brave Search para consultar horarios y precios, y SQLite para guardarlo todo. El binario pesa 12 megas, no necesita Docker, no necesita servidor. Solo un archivo de base de datos que cabe en un pendrive.

    Te cuento cómo planificó el viaje día a día, cómo nos buscaba sitios para comer (mención especial a la Osteria degli Spiriti en Lecce, el mejor restaurante del viaje), cómo consultábamos el tiempo cada mañana, y cómo cada noche escribía !diario y Minerva me generaba el resumen del día. Al final del viaje tenía los 10 días documentados sin haber abierto una sola pestaña del navegador.

    Y lo mejor: Ana, mi pareja, que no tiene perfil técnico, pasó de "¿esto qué es?" a "pregúntale a Minerva" en tres días. Ese fue el momento en que supe que no era un juguete.

    También te cuento lo que falló. Porque falló. Las alucinaciones del modelo (los Sassi de Matera no cuestan 15€ de entrada, son gratis). El tool calling de DeepSeek que a veces escribe XML en vez de invocar la función. La dependencia de internet en carreteras perdidas. El contexto que se satura después de varios días de uso. Y cómo solucioné cada problema — con retries, con resúmenes automáticos, con comandos directos tipo !gasto 45 Cena para cuando el lenguaje natural se vuelve ambiguo.

    Este episodio es para ti si alguna vez has pensado "me construyo una herramienta yo mismo" pero no te has lanzado. No necesitas un producto perfecto. Necesitas algo que funcione lo suficientemente bien para un caso de uso concreto. Minerva no era perfecta, pero era suficientemente buena. Y suficiente buena es mucho mejor que no existe.


    Capítulos del episodio:

    0:00 - Introducción: vuelta de vacaciones y la idea de Minerva
    2:30 - Feedback: el caos de organizar un viaje
    5:30 - La pila tecnológica de Minerva
    9:00 - Arquitectura: bot de Matrix en Rust
    12:30 - Herramientas: Google Places, Brave Search y Wikipedia
    16:00 - El prompt y la personalidad del asistente
    19:00 - Datos en bruto frente a datos parseados
    22:00 - Planificación de viajes con Minerva
    25:00 - Minerva en acción: ejemplos reales en Puglia
    28:30 - Alucinaciones, errores y lecciones aprendidas
    32:00 - Limitaciones de Matrix y el futuro del proyecto
    34:30 - Conclusiones: más allá de escribir código


    Más información y enlaces en las notas del episodio


  15. ATA 834 La alternativa a WatchTower para Docker

    20 minTemporada 9 · Episodio 834

    WatchTower lleva tiempo sin mantenimiento. Y si tienes 60 stacks de Docker Compose con casi 100 imágenes, actualizarlas una a una es un infierno. Así que me puse manos a la obra y creé Alloy, un dashboard …

    Notas del episodio

    WatchTower lleva tiempo sin mantenimiento. Y si tienes 60 stacks de Docker Compose con casi 100 imágenes, actualizarlas una a una es un infierno. Así que me puse manos a la obra y creé Alloy, un dashboard Docker escrito en Rust que me permite tenerlo todo controlado de un vistazo.

    En este episodio te cuento por qué dejé WatchTower y cómo Alloy resuelve los problemas que WatchTower nunca llegó a cubrir. Porque no solo se trata de actualizar imágenes: también necesitas saber qué ha pasado, cuándo, si ha ido bien, y enterarte si algo falla a las 3 de la mañana. Con Alloy eso cambia por completo.

    ¿Qué tiene Alloy que WatchTower no tenía? Historial completo de actualizaciones con la imagen anterior y la nueva, duración del proceso y estado final. Notificaciones integradas en Telegram y Matrix para enterarte de todo al instante. Políticas de actualización configurables por contenedor: puedes dejar que unos se actualicen solos, que otros solo descarguen la imagen sin reiniciar, o que ni siquiera se toquen. Logs en tiempo real con buscador integrado. Posibilidad de inspeccionar cada contenedor para ver puertos, volúmenes, redes, variables de entorno y etiquetas de Traefik. Y un dashboard adaptativo que funciona tanto en el ordenador como en el móvil.

    Y todo con autenticación OIDC a través de PocketID, sin necesidad de PostgreSQL, Redis ni bases de datos externas. Solo un binario con SQLite embebido. Nada de nada. Lo más sencillo posible.

    El backend está escrito en Rust con Axum y el crate Bollard para conectar con el socket de Docker. El frontend usa React con Mantine UI. Corre en una Raspberry Pi con 2 GB de RAM y consume un 0,5% de CPU y 60 MB de RAM. Vamos, un mecherito. Y lo mejor: soporta tanto Docker como Podman, de ahí el nombre Alloy, por la aleación entre los dos motores de contenedores.

    Te cuento también cómo gestiona los stacks de Docker Compose, agrupando los contenedores por proyecto. Cómo define políticas distintas para cada contenedor: no hacer nada, solo descargar la imagen, descargar y reiniciar el contenedor, o descargar y reiniciar el stack completo. Cómo hace rollback automático si algo falla, borrando la imagen nueva y restaurando la anterior. Y cómo se integra con Traefik para acceder directamente a cada servicio desde el dashboard con un solo clic.

    Y sí, lo reconozco: todavía lo estoy probando. Llevo como un mes y medio y algún ajuste fino necesita. De hecho, he encontrado que a veces, al reiniciar un contenedor, no termina de montarse bien con el resto del compose. Pero las ventajas respecto a WatchTower son tantas que ya no concibo volver atrás. Notificaciones, historial, logs, dashboard móvil... es otro nivel.

    Si estás harto de WatchTower o simplemente quieres tener más control sobre tus contenedores, este episodio te va a interesar. Y si además te mola Rust, pues ya ni te cuento.

    Capítulos del episodio:
    0:00 - Introducción: el problema de mantener 100 imágenes Docker actualizadas
    1:30 - ¿Por qué WatchTower ya no es suficiente?
    3:30 - Alloy: qué es y por qué está hecho en Rust
    5:30 - Arquitectura: Axum, Bollard, SQLite y React
    7:30 - Instalación y autenticación con OIDC y PocketID
    9:30 - El dashboard: contenedores, stacks y estado de un vistazo
    11:30 - Políticas de actualización por contenedor
    13:30 - Notificaciones vía Telegram y Matrix
    15:00 - Historial de actualizaciones (lo que WatchTower no tenía)
    16:30 - Logs en tiempo real e inspección de contenedores
    18:00 - Integración con Traefik
    19:00 - Interfaz adaptativa para móvil
    20:00 - Consumo de recursos: funciona en una Raspberry Pi
    23:00 - Conclusiones: ¿merece la pena el cambio?

    Más información y enlaces en las notas del episodio

  16. ATA 833 Workflows de IA, automatiza tu día con Ollama y Docker

    30 minTemporada 9 · Episodio 833

    Hoy en el episodio 833 te traigo algo que llevaba tiempo queriendo hacer: montar workflows de IA que funcionen de verdad en tu Linux, sin depender de servicios externos, sin GPUs, y sobre todo, sin malgastar …

    Notas del episodio

    Hoy en el episodio 833 te traigo algo que llevaba tiempo queriendo hacer: montar workflows de IA que funcionen de verdad en tu Linux, sin depender de servicios externos, sin GPUs, y sobre todo, sin malgastar tokens en tonterías.

    Hasta ahora hemos hablado de piezas sueltas: Ollama, skills, MCPs, agentes... pero todo eso suelto no te sirve para nada. La gracia está en combinarlo. En este episodio te enseño 4 workflows completos implementados en Rust que he puesto a funcionar en mi propio equipo, y que puedes adaptar al tuyo sin necesidad de ser un experto.

    La base del sistema es sencilla: Llama 3.2 3B para generación de texto (~2 GB, funciona en CPU), bge-m3 para embeddings multilingües (~1.2 GB), y binarios Rust compilados estáticamente que no necesitan ninguna dependencia del sistema. Con 8 GB de RAM tienes de sobra.

    Workflow 1 — noticias-bot: un bot que monitoriza feeds RSS, los filtra por palabras clave, los resume con Llama 3.2 local, y los publica automáticamente en Telegram. Funciona como servicio persistente 24/7, no como un script que ejecutas a mano. Cada feed tiene su propio intervalo de actualización y sus propias keywords. Lleva deduplicación con SHA256 y SQLite para no repetir artículos.

    Workflow 2 — tareas-bot: un gestor de tareas GTD vía Telegram. Le escribes un mensaje al bot, y la IA lo clasifica al instante: decide si es una tarea, le asigna prioridad y categoría, lo guarda en SQLite, y te confirma en el chat. Sin abrir ninguna app de tareas, sin salir de Telegram.

    Workflow 3 — monitor-bot: un monitor de sistema inteligente con 5 tipos de chequeo: disco, servicios, memoria, logs del sistema y contenedores Docker. Y aquí viene lo interesante: solo usa la IA cuando realmente hace falta, para analizar logs. Los checks normales son deterministas, sin LLM. Así no malgastas recursos ni tokens. Incluye rate limiting y remediación automática.

    Workflow 4 — investigador RAG: un asistente de investigación con RAG local. Le haces una pregunta, genera consultas de búsqueda, las lanza contra SearXNG, descarga las páginas en paralelo con tokio, las procesa con embeddings de bge-m3, y te da una respuesta con sus fuentes. Todo en un solo binario Rust, sin Python, sin dependencias del sistema.

    Todo esto desplegado con systemd o Docker, como servicios que arrancan solos y se mantienen funcionando. Y lo mejor: con modelos que caben en cualquier máquina con 8 GB de RAM y sin GPU.

    Capítulos del episodio:
    0:00 — Introducción: del caos de herramientas a los workflows IA
    2:30 — ¿Qué es un workflow de IA? Skills, MCPs y prompts combinados
    5:00 — Arquitectura: Rust, Ollama y Docker como base del sistema
    8:00 — Ejemplo 1: noticias-bot — RSS filtrado a Telegram
    11:30 — Demo del noticias-bot: publicación automática de noticias
    14:30 — Ejemplo 2: tareas-bot — clasificación GTD vía Telegram
    17:30 — Demo del tareas-bot: "hola" vs "comprar ciruelas"
    20:00 — Ejemplo 3: monitor-bot — alertas de sistema con IA
    22:30 — Ejemplo 4: investigación asistida con RAG local
    26:00 — Demo del investigador: consulta sobre Podman 6
    29:00 — Ventajas, conclusiones y despedida


    Más información y enlaces en las notas del episodio


  17. ATA 832 Watchbit, el monitor de uptime ultraligero hecho en Rust

    21 minTemporada 9 · Episodio 832

    ¿Cansado de que tu monitor de uptime consuma más recursos que los propios servicios que monitoriza? Llevaba años usando Uptime Kuma, una herramienta fantástica, potente y muy fácil de configurar. Pero cuando …

    Notas del episodio

    ¿Cansado de que tu monitor de uptime consuma más recursos que los propios servicios que monitoriza? Llevaba años usando Uptime Kuma, una herramienta fantástica, potente y muy fácil de configurar. Pero cuando miras el docker stats y ves 150 MB de RAM, 900 MB de disco y un 2% de CPU para monitorizar solo seis páginas, algo no cuadra. Sobre todo cuando lo único que quieres es que te llegue una notificación si algo falla, no tener un mini-Netflix corriendo en tu servidor.

    Por eso creé Watchbit: un monitor de uptime escrito en Rust con frontend en React, base de datos SQLite embebida y autenticación OIDC con Pocket ID. El resultado: 7 MB de RAM, 20 MB de disco y 0,2% de CPU. Sí, has leído bien. Estamos hablando de reducir el consumo de memoria a una vigésima parte, el de disco a una cuadragésima parte y el de CPU a una décima parte. Y todo esto sin perder funcionalidad: monitores HTTP, TCP, Ping, heartbeats, notificadores vía Telegram, Matrix, NTFY, Gotify, Discord, Email, y páginas de estado públicas.

    En este episodio te cuento cómo migré de Uptime Kuma a Watchbit, te enseño el dashboard por tarjetas, los heartbeats, los monitores, los notificadores y las 7 razones por las que no pienso volver atrás. También te explico el stack técnico: Rust con Axum y Tokio en el backend, React con TypeScript en el frontend, SQLite como base de datos embebida (adiós a PostgreSQL y MariaDB), y OIDC con Pocket ID para olvidarte de gestionar usuarios y contraseñas. Todo en un solo binario, sin dependencias externas, con una imagen Docker que apenas ocupa 20 MB.

    Además te muestro cómo configurar los monitores con intervalos personalizados, las plantillas de notificación para eventos de down, up, latencia y expiración de certificados, y el sistema de backup integrado que te permite exportar e importar toda la configuración en un solo clic. También te cuento el proceso de optimización que seguí: inicialmente hacía un bucle que recorría todos los monitores, pero después los separé en tareas independientes con Tokio para maximizar la eficiencia.

    Si tienes un VPS ajustado, una Raspberry Pi Zero, o simplemente quieres ser racional con los recursos de tu servidor, este episodio te interesa. Porque al final, de esto va el self-hosting: de tener herramientas que hagan su trabajo sin que el servidor se resienta. Como siempre, te dejo el docker-compose, las variables de entorno y las instrucciones en las notas del episodio para que puedas probarlo tú mismo en cinco minutos.

    Capítulos:
    0:00 - Introducción: la necesidad de monitorizar páginas web
    1:54 - Uptime Kuma: características y panel de control
    4:45 - Ventajas e inconvenientes de Uptime Kuma
    5:36 - El problema del consumo: CPU, RAM y disco
    7:05 - Watchbit: OIDC, dashboard y diseño por tarjetas
    8:43 - Comparativa de consumo: Watchbit vs Uptime Kuma
    10:53 - Heartbeats y monitores en Watchbit
    12:37 - Configuración de monitores, notificadores y plantillas
    14:31 - Ajustes, backup y stack técnico (Rust + React + SQLite)
    17:26 - 7 razones para migrar e instalación

    Más información y enlaces en las notas del episodio

  18. ATA 831 Esto es lo que le faltaba a tu IA para ser útil de verdad

    36 minTemporada 9 · Episodio 831

    Hoy te traigo un episodio que llevaba tiempo queriendo grabar. En el episodio 829 te hablé sobre skills, pero me quedé con la sensación de haberme enrollado sin mostrar nada concreto. Así que le he dado la …

    Notas del episodio

    Hoy te traigo un episodio que llevaba tiempo queriendo grabar. En el episodio 829 te hablé sobre skills, pero me quedé con la sensación de haberme enrollado sin mostrar nada concreto. Así que le he dado la vuelta a la tortilla y en esta ocasión te traigo siete MCPs que he seleccionado uno a uno para que veas de qué va esto del Model Context Protocol y, sobre todo, para que compruebes cómo transforman lo que puede hacer tu inteligencia artificial.

    Porque hay que decirlo claro: la IA es tonta. Literalmente. No sabe qué hora es, no sabe leer un archivo, no sabe si tienes issues abiertos en GitHub, no sabe cómo te llamas. Cada vez que empiezas una conversación con cualquier modelo de lenguaje, empiezas de cero. Y aquí es donde entran los MCPs, que no son ni más ni menos que herramientas: manos, ojos y oídos para que la IA pueda hacer cosas útiles de verdad.

    El Model Context Protocol es un estándar abierto creado por Anthropic que funciona como un *USB-C para la IA*. Un conector universal que permite que cualquier aplicación de IA se conecte con cualquier fuente de datos o herramienta externa. Y lo mejor es que no es propietario, al contrario que los plugins de ChatGPT. Cualquiera puede crear un MCP, y de hecho te cuento cómo hacerlo con Python o Rust.

    En este episodio repaso siete MCPs que uso en mi día a día. Empiezo por el Filesystem, que permite a la IA leer, escribir, buscar y editar archivos en tu sistema, con control de acceso para que no haga tonterías. Sigo con el SQLite, ideal para consultar bases de datos locales de agenda, finanzas o cualquier aplicación que uses. Después llega el GitHub, el servidor oficial de GitHub escrito en Go, que te permite gestionar issues, pull requests, repositorios y mucho más sin salir del chat.

    También te hablo del Web Fetch, que permite a la IA leer páginas web y convertirlas a Markdown ahorrando una barbaridad de tokens. Y del Time, que es una tontería pero imprescindible: la IA puede saber la hora en cualquier huso horario del mundo. Luego está el Memory, que construye un grafo de conocimiento persistente para que la IA recuerde quién eres, qué prefieres y qué proyectos tienes entre manos, incluso entre sesiones. Y por último, el Sequential Thinking, una herramienta de razonamiento paso a paso que obliga a la IA a pensar de forma estructurada cuando se enfrenta a problemas complejos.

    También hablo de cómo configurar estos MCPs en OpenCode, Claude Desktop y VS Code, y cuánto consumen de RAM y tokens. Porque no es lo mismo activar veinte servidores que tener solo los que necesitas. Y para rematar, comparo MCPs con skills: las skills le dicen a la IA cómo comportarse, los MCPs le dan capacidades para actuar.

    Y si te pica la curiosidad por crear tu propio MCP, también te cuento las diferencias entre usar el SDK de Python (súper rápido de prototipar) y el de Rust (más rendimiento, menos consumo de RAM).

    Capítulos del episodio:
    0:00 - Introducción: la IA necesita herramientas para ser útil
    2:30 - ¿Qué es MCP? Arquitectura host-cliente-servidor y JSON RPC 2.0
    5:30 - Cinco razones para adoptar MCPs
    8:00 - MCP Filesystem: leer, buscar y crear archivos
    11:00 - MCP SQLite: consultar bases de datos y el no-determinismo
    14:00 - MCP GitHub: issues, pull requests y repositorios
    17:00 - MCP Web Fetch: búsquedas en internet con ahorro de tokens
    19:30 - MCP Time: la hora en cualquier huso horario
    21:30 - MCP Memory: grafo de conocimiento persistente
    23:30 - MCP Sequential Thinking: razonamiento paso a paso
    25:30 - Configuración en OpenCode, consumo de tokens y RAM
    27:30 - Crear tu propio MCP: Python SDK vs Rust
    28:30 - Cierre y despedida


    Más información y enlaces en las notas del episodio


  19. ATA 830 Popuplatrs, publica en redes desde tu propio RSS

    18 minTemporada 9 · Episodio 829

    Este es el primer episodio de una serie de cuatro que voy a dedicar a herramientas que he implementado y que uso en mi día a día. Las cuatro comparten stack: Rust en el backend y React con TypeScript en el …

    Notas del episodio

    Este es el primer episodio de una serie de cuatro que voy a dedicar a herramientas que he implementado y que uso en mi día a día. Las cuatro comparten stack: Rust en el backend y React con TypeScript en el frontend. Y la primera es, sin duda, una de las que más me facilitan la vida: Popuplatrs.

    ¿Te suena el ritual de publicar un artículo y tener que abrir Telegram, luego Mastodon, luego X, luego LinkedIn, luego Bluesky, y encima personalizar el texto para cada plataforma? Pues eso es exactamente lo que Popuplatrs elimina de tu día a día. Le das uno o varios feeds RSS, Atom o YouTube, y él se encarga de leer las novedades y publicarlas automáticamente en las redes que le configures. Con plantillas personalizables, programación de horarios, reintentos automáticos y un panel web desde el que controlarlo todo.

    En este episodio te cuento por qué me decidí a crear esta herramienta, qué alternativas existen (Buffer, Hootsuite, IFTTT, Zapier) y por qué ninguna me convencía al ser SaaS o no estar pensadas para funcionar a partir de feeds. También te explico la arquitectura técnica: Rust con Axum, SQLite en modo WAL, autenticación OIDC con Pocket ID, y un sistema de plantillas con MiniJinja que te permite personalizar el mensaje para cada red social.

    Popuplatrs soporta hasta nueve publicadores diferentes: Telegram, X (Twitter), Mastodon, Bluesky, LinkedIn, Threads, Discord, Matrix y OpenObserve para logging. Cada uno con su propia configuración de autenticación y límites de caracteres. Por ejemplo, en Bluesky publica respetando el límite de 300 caracteres, en X primero lanza el título y luego un reply con el enlace para aprovechar mejor el espacio, y en Discord usa webhooks que se configuran en segundos.

    El sistema de plantillas es una de las partes que más me gustan. Usa MiniJinja, un motor compatible con Jinja2, y te permite definir plantillas distintas para cada plataforma. Puedes truncar el texto a un número de caracteres, limitar las palabras, eliminar HTML, y combinar el título con la descripción como más te convenga. Todo desde el panel web, sin tocar código.

    Y por supuesto, te cuento cómo tenerlo corriendo en tu servidor en cinco minutos con Docker. Porque si algo me gusta es que las herramientas sean fáciles de desplegar.

    Capítulos:
    0:00 - Introducción: el problema de publicar en redes sociales
    1:45 - Alternativas existentes y sus limitaciones
    3:00 - Qué es Popuplatrs: origen, nombre y características principales
    4:15 - Arquitectura técnica: Rust, Axum, SQLite y Pocket ID
    5:45 - Fuentes soportadas: RSS, Atom y YouTube
    7:00 - Publicadores: hasta nueve plataformas sociales
    8:30 - Panel web: dashboard, logs y republicación de errores
    10:30 - Programación, reintentos y control anti-spam
    12:00 - Motor de plantillas y personalización por plataforma
    13:30 - Despliegue con Docker Compose, Pocket ID y despedida

    Más información y enlaces en las notas del episodio

  20. ATA 829 Skills imprescindibles para tu agente IA

    21 minTemporada 9 · Episodio 825

    Hoy te traigo un episodio que llevaba tiempo queriendo grabar. Y es que muchos estáis usando agentes de IA, pero los tenéis desnudos. Sin skills. Y un agente sin skills es como un Linux sin comandos …

    Notas del episodio

    Hoy te traigo un episodio que llevaba tiempo queriendo grabar. Y es que muchos estáis usando agentes de IA, pero los tenéis desnudos. Sin skills. Y un agente sin skills es como un Linux sin comandos: técnicamente funciona, tienes el kernel, tienes la shell, pero sin ls, sin grep, sin systemctl, no puedes hacer nada útil. El mejor modelo del mundo sin herramientas solamente es texto bonito.

    En este episodio te cuento qué son exactamente las skills, por qué transforman un modelo de lenguaje en un asistente que hace cosas, y cuáles son las tres skills imprescindibles que todo agente debería tener. Una skill no es ni más ni menos que un prompt. Un conjunto de instrucciones que le dice a tu agente cómo tiene que hacer algo. No es un programa ni un script, es una receta de comportamiento. Y no necesitas ser programador para crearlas.

    Te hablo de skills del sistema: leer archivos, ejecutar comandos, navegar por tu equipo. Skills de búsqueda: búsqueda web con SearXNG (que tengo montado en un Slimbook One y devuelve resultados en JSON que es una maravilla), búsqueda local con RipGrep que es increíblemente rápida, y búsqueda semántica con SQLite. Y skills de automatización: tareas programadas, webhooks que responden a eventos como un git push, o scripts orquestados que pueden hacer casi cualquier cosa.

    Pero no me quedo ahí. Te doy las tres reglas de oro para crear tus propias skills. Porque los mejores skills son los que escribes para ti mismo. Primera regla: no digas "revisa el sistema", sino "ejecuta systemctl status --failed". Cuanto más específico, mejor. Segunda: define los límites. Qué puede hacer y qué no. Lo que no puede hacer es casi tan importante como lo que puede hacer. Tercera: ponle ejemplos. Cómo tiene que quedar el resultado, qué formato tiene que usar. Con estas tres cosas todo rueda mucho mejor.

    También te cuento cómo organizar tus skills. Cada agente guarda los skills donde le da la gana: OpenCode en .config/opencode/skills, Hermes en .hermes/skills. Yo cada vez los guardo más en .agents/skills porque la mayoría de los agentes ya saben encontrarlos ahí. Y te hablo de los hubs de skills, donde puedes instalar skills creados por la comunidad con un solo comando.

    Si usas OpenCode, Hermes Agent u Open Web y sientes que tu agente responde preguntas pero no hace cosas, este episodio te va a cambiar el día a día. Vamos directos al turrón.

    Capítulos del episodio:

    0:00 - Introducción: tu agente está desnudo

    1:45 - ¿Qué es una skill? De un prompt a un asistente que hace cosas

    4:15 - Skills del sistema: leer archivos, ejecutar comandos, navegar

    7:30 - Skills de búsqueda: web con SearXNG, local con RipGrep, semántica con SQLite

    11:00 - Skills de automatización: tareas programadas, webhooks, scripts orquestados

    13:45 - Las 3 reglas de oro para crear tus propias skills

    18:30 - El ecosistema de skills: dónde guardarlas y cómo organizarlas

    21:00 - Ejemplo práctico: la skill del tiempo meteorológico

    23:15 - Conclusión: un agente sin skills es Linux sin comandos

    Más información y enlaces en las notas del episodio

  21. ATA 828 De Docker a tu Cerebro Digital, el roadmap de IA para Linuxeros

    32 minTemporada 9 · Episodio 828

    Este episodio 828 es la carta de presentación de la Temporada 9 de atareao con Linux. Treinta y cuatro episodios ya guionizados, siete etapas, y un objetivo claro: construir tu cerebro digital sobre Linux con …

    Notas del episodio

    Este episodio 828 es la carta de presentación de la Temporada 9 de atareao con Linux. Treinta y cuatro episodios ya guionizados, siete etapas, y un objetivo claro: construir tu cerebro digital sobre Linux con herramientas locales, sin depender de nubes ni suscripciones.

    Pero antes de mirar adelante, toca hacer balance. La T08 empezó prometiendo Docker, selfhosting y Android, y sí, hablé de todo eso. Pero en abril de 2025 la IA local irrumpió con fuerza y la temporada viró hacia Ollama, modelos locales, RAG, MCP. Fue un giro desordenado, lo reconozco. Pero también fue el germen de todo lo que viene ahora.

    De eso va esta T09: de poner orden al caos. Siete etapas, de menos a más, para que sigas el hilo hagas el nivel que hagas.

    Etapa 1 — Recursos básicos: los cimientos de tu laboratorio de IA. Skills para tu agente, herramientas de publicación, el botiquín del explorador.

    Etapa 2 — Skills y MCPs: el pegamento. El Model Context Protocol ha madurado hasta ser un estándar abierto — lo soportan Claude, ChatGPT, VS Code, Cursor. Ya no es un experimento, es el USB-C de la IA. Y de paso, herramientas del ecosistema atareao como watchbeat (monitor de uptime en Rust) y alloy (dashboard Docker con OIDC).

    Etapa 3 — GraphRAG, el gran hito: de RAG vectorial a grafos de conocimiento. Mientras el RAG clásico devuelve fragmentos sueltos y tú unes los puntos, GraphRAG construye un grafo con entidades y relaciones. Preguntas como "qué contenedores están detrás de Traefik" pasan a ser una consulta directa a tu mapa de conocimiento. Usaremos LightRAG, que con 39.000 estrellas ya superó al Microsoft GraphRAG original. Esto ocupa tres episodios.

    Etapa 4 — Multimedia: Whisper para speech-to-text, TTS local, ffmpeg, visión artificial, y el pipeline de YouTube a conocimiento con yt-dlp. Rematamos con RAG multimodal.

    Etapa 5 — Orquestación: systemd timers, asyncio, just, y CrewAI para montar equipos de agentes.

    Etapa 6 — Proyecto final: dos episodios para construir El Asistente que te Conoce y ponerlo en producción con Quadlets.

    Etapa 7 — El futuro: mantenimiento de tu cerebro digital y hacia dónde va todo esto.

    Entre medias, herramientas Linux: shuul, sqlite-utils, yq + jq, Rust en el kernel, Wayland vs X11, la guerra de los filesystems.

    No necesitas una GPU de 3000 euros ni un doctorado. Con 16 GB de RAM y un CPU decente ejecutas modelos de 7B a 14B. Esto es IA local, en tu máquina, con tus datos.

    Capítulos del episodio:
    00:00 — Introducción y bienvenida a la Temporada 9
    01:47 — Balance T08: de Docker y Selfhosting al boom de la IA
    04:37 — El momento adecuado para cada tecnología
    06:46 — El gran objetivo: tu cerebro digital
    08:44 — Roadmap T09: 30 episodios ya guionizados
    11:28 — Skills y MCPs imprescindibles
    12:43 — GraphRAG: de RAG a grafos de conocimiento
    14:01 — RAG vs GraphRAG: el mapa de tu conocimiento
    17:28 — Herramientas del ecosistema: alloy, populater, watchbeat
    20:08 — ¿Para quién es esto? De veteranos a escépticos
    22:08 — No es hype: es un cambio de paradigma
    24:30 — El momento perfecto para el linuxero

    Toda la info y el roadmap completo en atareao.es/828.


    Más información y enlaces en las notas del episodio


  22. ATA 827 No Necesitas una GPU de 3000€ para IA Local

    23 minTemporada 8 · Episodio 827

    Cerramos la octava temporada con un episodio que me apetecía grabar desde hace meses. Igual te ha pasado como a mí: empecé hablando de un laboratorio de IA para cualquiera, y terminé recomendando GPUs de 3000 …

    Notas del episodio

    Cerramos la octava temporada con un episodio que me apetecía grabar desde hace meses. Igual te ha pasado como a mí: empecé hablando de un laboratorio de IA para cualquiera, y terminé recomendando GPUs de 3000 euros. Me fui creciendo, pero no hace falta. Te cuento cómo montar un laboratorio de IA local con el equipo que ya tienes. Da igual si tienes 8 GB de RAM o 16, CPU modesta o sin GPU. La clave está en elegir los modelos adecuados. Muchas veces nos perdemos buscando el modelo más grande, cuando con uno pequeño y bien cuantizado tenemos de sobra para el 80% de las tareas.

    Te hablo de Ollama, el gestor de modelos estándar para ejecutar modelos locales. Más de 180.000 estrellas en GitHub, API compatible con OpenAI, modelos para todos los presupuestos: desde Phi 3.5 con 3.8B parámetros hasta Qwen 1.5B que ocupa 1 GB. También la cuantización: reduces la precisión numérica de los pesos para que ocupen menos y vayan más rápido. El punto dulce es Q4_K_M, que reduce el tamaño a menos de un tercio. Para 8 GB de RAM, Q3_K_S puede ser tu salvación.

    También te hablo de Open WebUI, la interfaz que le da mil vueltas a ChatGPT. No solo chateas: tiene RAG local, Whisper integrado para transcribir voz (75 MB en CPU), TTS con Kokoro-82M para que el modelo te hable en tiempo real, búsqueda web, plugins y memoria persistente. Todo en un contenedor Docker que levantas con un solo comando.

    Y de SQLite Vec, extensión de SQLite sponsorizada por Mozilla para búsqueda semántica sin servidores vectoriales. Ni ChromaDB, ni Qdrant, ni Milvus. C puro que funciona hasta en Raspberry Pi. Creas tablas virtuales para vectores de 768 dimensiones, generas embeddings con nomic-embed-text, y buscas por similitud coseno en milisegundos. RAG local sin complicaciones.

    Y te explico cómo organizarlo todo con Docker o Podman. Un docker-compose.yml que levanta Ollama y Open WebUI en segundos, con healthchecks, redes separadas y volúmenes persistentes. También a limitar recursos con --memory y --cpus. He preparado scripts: inicialización que comprueba requisitos, crea directorios y descarga modelos; otro para descargar por niveles según tu hardware (nivel 1 para 8 GB, nivel 2 para 16 GB, nivel 3 para 32 GB); y uno de respaldo.

    Y la estrategia híbrida local + nube, que es lo que realmente tiene sentido. El enfoque Minions del Stanford Hazy Research Lab: el modelo local hace el trabajo pesado, y solo consulta al grande en la nube para tareas complejas. El 90% de las consultas se resuelven localmente. Ahorras dinero, mantienes privacidad de tus datos, y cuando necesitas potencia, la tienes.

    Con 16 GB de RAM y un SSD te sobra para el 80% de las tareas: traducciones, resúmenes, código, asistentes, RAG, transcripción de audio, texto a voz... Todo en tu máquina, sin enviar datos a servidores, sin suscripciones, sin depender de internet. Con 8 GB también puedes, con modelos más pequeños. Cerramos temporada, la novena arranca en el episodio 828.

    Capítulos del episodio:
    0:00 - Introducción — cierre de temporada 8 y replanteamiento
    2:30 - Hardware mínimo: 8-16 GB RAM + SSD obligatorio
    5:00 - Software base: instalar Ollama en tu distribución
    7:30 - Contenedores: Docker vs Podman para el laboratorio
    10:00 - Modelos pequeños: Phi 3.5, Qwen 1.5B y cuantización
    13:00 - Herramientas complementarias: SQLite Vec, Whisper, TTS
    16:00 - Organización del laboratorio: script y estructura de directorios
    19:00 - Demo: probando Ollama en local con modelos ligeros
    22:00 - Combinación local + nube: lo mejor de ambos mundos
    24:30 - Cierre, avance temporada 9 y despedida

    Más información y enlaces en las notas del episodio

  23. ATA 826 Nushell, la shell que entiende tus datos y tu IA

    31 minTemporada 8 · Episodio 826

    Si llevas años usando Bash, Zsh o Fish y piensas que los pipes de Unix son lo más parecido a la perfección, este episodio te va a hacer tambalear los cimientos. Porque existe un shell que no pasa texto entre …

    Notas del episodio

    Si llevas años usando Bash, Zsh o Fish y piensas que los pipes de Unix son lo más parecido a la perfección, este episodio te va a hacer tambalear los cimientos. Porque existe un shell que no pasa texto entre comandos: pasa estructuras de datos. Tablas, listas, registros, fechas, tamaños de archivo con tipo real. Y encima habla con Ollama sin que tengas que escribir ni una línea de Python.

    Ese shell es Nushell. Está escrito en Rust, tiene más de 40.000 estrellas en GitHub, y su filosofía es sencilla: los pipes deberían transportar datos con tipo, no texto que luego parseas con awk, sed o jq.

    En este episodio te cuento mi experiencia pasando de Fish a Nushell con ejemplos reales. Cuando escribes ls no obtienes texto: obtienes una tabla con columnas tipadas. Puedes hacer ls | where size > 1mb | sort-by size sin recurrir a awk ni números mágicos. El shell entiende qué es un filesize, qué es una fecha, qué es un número.

    Y luego está open, que entiende el formato por la extensión: JSON, YAML, TOML, CSV, SQLite... todo se convierte en datos estructurados. Abres un SQLite y ejecutas consultas con query db. Y todo combinable: http get a una API, filtrar con where y guardar con save — en un solo pipeline, sin archivos temporales.

    La guinda es la integración con IA. Como Nushell entiende JSON y Ollama habla JSON, se entienden a la perfección. Te enseño un pipeline que lista procesos, filtra los que consumen más de 100MB de RAM, se los manda a un modelo local, y mata el que más memoria usa. Todo en una línea. También te hablo de ai.nu, un módulo que envuelve Ollama, OpenAI y DeepSeek, con function calling desde el shell.

    También hago una comparativa: Bash, Zsh, Fish y Nushell cara a cara. Bash funciona en cualquier sitio pero el manejo de datos es arcaico. Zsh es Bash con esteroides pero los pipes siguen siendo texto. Fish es moderno pero no entiende de tipos. Nu es el único con estructuras de datos de verdad. PowerShell fue el primero en pasar objetos, pero Nu es lo que PowerShell debería haber sido.

    Capítulos del episodio:
    0:00 — Introducción: de Bash a Fish, la evolución de las shells
    2:30 — El problema del texto plano: por qué Nushell es diferente
    5:00 — La trifecta: ls, where y select, SQL en tu terminal
    7:30 — Tipos reales: la shell entiende fechas, tamaños y números
    10:00 — Open: abrir JSON, CSV, YAML y SQLite sin herramientas externas
    13:00 — Procesamiento avanzado: $in, save, append y par-each
    15:30 — HTTP GET: APIs de GitHub y meteorología desde la shell
    18:00 — Comparativa de shells: Bash vs ZSH vs Fish vs Nushell
    21:00 — Nushell e IA: integración nativa con Ollama sin Python
    24:00 — Instalación, casos de uso y conclusiones finales


    Más información y enlaces en las notas del episodio

  24. ATA 825 Qué hay en el motor de un agente de IA

    31 minTemporada 8 · Episodio 825

    Hoy te voy a contar una historia que empieza con una idea brillante y termina con una buena dosis de frustración. Resulta que se me ocurrió construir mi propio agente de inteligencia artificial. Lo llamé …

    Notas del episodio

    Hoy te voy a contar una historia que empieza con una idea brillante y termina con una buena dosis de frustración. Resulta que se me ocurrió construir mi propio agente de inteligencia artificial. Lo llamé Anacleto, está escrito en Rust, y la idea era tener un coordinador de agentes que delegara tareas según lo que le pidieras. El tiempo, el tiempo, y un puñado de bugs después, me he encontrado con que estoy aprendiendo mucho más de lo que pasa entre bambalinas que de lo que el agente realmente llega a hacer.

    Y es que cuando le das una instrucción a un agente de IA —ya sea OpenCode, Claude, Hermes o el que tú quieras— no hay magia. Lo que hay es una coreografía compleja de mensajes que van y vienen, eventos que se disparan, herramientas que se invocan y un modelo de lenguaje que procesa todo después de que el agente lo haya pretratado. En este episodio abro la caja negra y te cuento exactamente qué hay dentro.

    Te explico el viaje completo de un mensaje: desde que escribes el prompt hasta que obtienes la respuesta. Cómo funciona el streaming, cómo el modelo "piensa en voz alta" con los reasoning events, cómo decide qué herramientas usar con las tool calls, y cómo todo se monta en una batidora que reconstruye la información antes de enviarla al modelo. Y sí, el modelo no razona, simplemente predice. Pero la gracia está en que ahora no solo habla, también actúa. El modelo recibe una lista de herramientas disponibles y decide por sí mismo cuál usar según el contexto. No es programación tradicional de "si pasa A, usa la herramienta A". Es el modelo el que, basándose en su entrenamiento, predice qué herramienta le dará la mejor respuesta.

    Y luego está el problema. El bucle. El modelo devuelve tool calls, el agente ejecuta las herramientas, vuelve a llamar al modelo, y así una y otra vez hasta que se alcanza el máximo de pasos y todo se para. No sé si es un problema de cómo he definido las llamadas, del motor o de las skills. Llevo días toqueteando, probando, cambiando cosas, y todavía no tengo claro dónde está el fallo. Lo que sí tengo claro es que unas skills bien preparadas dan mejores resultados que un modelo más potente. Y esa lección, por sí sola, ya ha valido la pena. Porque al final, la calidad de las instrucciones que le das al agente importa más que el modelo que uses por debajo.

    Te cuento también por qué elegí Rust y Ratatui para la interfaz, en lugar de lo típico en Python o TypeScript. Spoiler: me lié más con el lenguaje que con el objetivo final, como suele pasar. Y te presento a los subagentes de Anacleto: uno para el tiempo, otro para noticias, otro para chistes, otro para investigar... cada uno con su propia personalidad y herramientas.

    Capítulos del episodio:

    Capítulos del episodio:

    0:00 - Introducción: abriendo la caja negra de los agentes de IA
    2:19 - El viaje de un mensaje: del prompt al modelo de lenguaje
    3:49 - Arquitectura de agentes: coordinador, subagentes y la TUI en Rust
    6:11 - El motor como director de orquesta: roles system, user, assistant y tool
    8:27 - System prompt y optimización: delegación en subagentes especializados
    11:13 - Streaming y server-sent events: cómo se construye la respuesta token a token
    14:20 - Razonamiento y tool calls: el modelo predice, no piensa, pero actúa
    17:59 - El bucle de herramientas: el problema de la delegación infinita en Anacleto
    20:56 - Skills, subagentes desechables y sistema de permisos
    25:16 - Demostración práctica de Anacleto: tiempo, chistes y noticias
    29:22 - Conclusiones, redes y despedida

    Más información y enlaces en las notas del episodio

  25. ATA 824 Busca como un rayo y alimenta a tu IA

    22 minTemporada 8 · Episodio 824

    ¿Sigues usando find y grep como en los 90? Hace unas semanas me puse a buscar un archivo en un repositorio con git, lancé el find de toda la vida, y cuando volví de tomarme un café —literalmente— todavía seguía …

    Notas del episodio

    ¿Sigues usando find y grep como en los 90? Hace unas semanas me puse a buscar un archivo en un repositorio con git, lancé el find de toda la vida, y cuando volví de tomarme un café —literalmente— todavía seguía buscando. El problema es que find se mete en el .git, en los binarios, en sitios donde no debería. Y grep, pues lo mismo, sobre todo si trabajas con Unicode o con repositorios grandes. Así que llevo un tiempo usando fd y ripgrep, dos herramientas escritas en Rust que son órdenes de magnitud más rápidas. Pero lo mejor no es solo la velocidad: es que puedes combinarlas para crear pipelines que alimenten directamente a tu IA local.

    fd (44.1k estrellas en GitHub) es un reemplazo directo de find. En los benchmarks oficiales, buscar archivos con fd -u tarda 0.8 segundos donde find necesita 11 segundos con -iname y casi 20 segundos con -iregex. 23 veces más rápido. Y no solo es velocidad: fd respeta .gitignore por defecto, soporta expresiones regulares directamente, y tiene placeholders como {}, {.}, {/} y {//} que te permiten ejecutar comandos sobre cada resultado con -x o pasarlos en lote con -X.

    ripgrep (67.4k estrellas) es lo mismo pero para buscar texto. En el kernel de Linux, rg tarda 0.08 segundos donde grep tarda 2.67 segundos. 32 veces más rápido. Y tiene superpoderes que grep ni sueña: salida en JSON con --json, búsqueda en archivos comprimidos con -z, soporte PCRE2 con -P para lookaheads, y un flag --passthru que te muestra también las líneas que no coinciden. Desde la versión 15 también soporta hyperlinks OSC 8 y respeta repositorios de Jujutsu.

    Pero lo que realmente me tiene enganchado es combinarlos. El patrón es sencillo: fd encuentra los archivos que te interesan, ripgrep extrae el contexto relevante, y todo eso se lo pasas a Ollama para que lo procese. Te enseño la función aresumen que me he montado en Bash, y su equivalente en Fish, para preguntarle a mi documentación local sin salir de la terminal. Cosas como "resume todo lo que he escrito sobre Ollama en el último mes" se resuelven con un pipeline de tres comandos. Sin RAG, sin bases de datos vectoriales, sin complicaciones. Solo con un pipe bien puesto y el modelo adecuado.

    También te cuento cómo usar jq para procesar la salida JSON de ripgrep, cómo montar un buscador interactivo con fzf y bat, y los errores más comunes al construir estos pipelines. Si alguna vez has pensado "ojalá pudiera preguntarle a mis propias notas desde la terminal", este episodio te va a gustar. Y si todavía usas find y grep, te aseguro que después de oír los benchmarks no vuelves atrás.

    Capítulos del episodio:
    0:00 — Introducción: fd y ripgrep para alimentar a tu IA
    2:30 — El problema con find y grep tradicionales
    5:00 — fd: el find que siempre quisiste tener
    8:00 — Placeholders y expresiones regulares en fd
    11:00 — ripgrep: el grep con superpoderes
    14:00 — Salidas estructuradas con JSON y jq
    16:30 — La combinación estrella: fd + ripgrep con -x
    19:00 — Pipelines avanzados para filtrar archivos
    21:30 — Integración con IA local: fd + rg + Ollama
    24:30 — Alias, funciones y trucos del día a día
    27:00 — Despedida y conclusiones

    Recursos mencionados:
    - fd (sharkdp/fd): https://github.com/sharkdp/fd
    - ripgrep (BurntSushi/ripgrep): https://github.com/BurntSushi/ripgrep
    - Ollama: https://ollama.com
    - jq: https://jqlang.github.io/jq/
    - fzf: https://github.com/junegunn/fzf
    - bat: https://github.com/sharkdp/bat

    Más información y enlaces en las notas del episodio


  26. ATA 823 OpenCode multi agente: cómo convertir la IA en tu equipo de redacción

    31 minTemporada 8 · Episodio 823

    Hoy toca dar un paso más. Hasta ahora usabas OpenCode como un asistente personal, le pedías algo y lo hacía. Pero, ¿y si necesitas algo más potente? ¿Alguien que investigue, alguien que escriba, alguien que lo …

    Notas del episodio

    Hoy toca dar un paso más. Hasta ahora usabas OpenCode como un asistente personal, le pedías algo y lo hacía. Pero, ¿y si necesitas algo más potente? ¿Alguien que investigue, alguien que escriba, alguien que lo optimice para SEO y alguien que lo revise todo? La respuesta no es un agente, es un equipo de agentes. En este episodio te cuento cómo he montado un sistema multi agente con OpenCode usando el patrón supervisor, y cómo coordino cinco agentes especializados sin que se pisen.

    Te explico el pipeline completo de cinco fases. Primero la planificación, donde el coordinador define la estructura y los pasos a seguir. Luego la investigación, que corre a cargo del bibliotecario, un agente que solo busca información, no escribe, no opina, solo trae datos con sus fuentes. Después viene el redactor, que coge esos datos y escribe el artículo en Markdown con el tono de la casa. La cuarta fase es el SEO, donde un agente especializado pone el título, la meta descripción y las etiquetas sin tocar el fondo del artículo. Y por último la revisión, donde el editor verifica que todo está correcto y, si algo falla, lo devuelve al coordinador para que repita la fase que haya fallado. Todo esto forma un bucle de retroalimentación que diferencia un sistema multi agente bien hecho de cualquier otro.

    Cada agente tiene su propio modelo, su propia temperatura y sus propios permisos. El investigador usa un modelo pequeño y barato porque solo necesita buscar. El redactor necesita un modelo más grande porque tiene que escribir con calidad. El revisor usa temperatura muy baja para ser lo más objetivo posible.

    También te cuento los errores que me he encontrado. El más común es que el coordinador no delega. Le pides algo y en lugar de llamar al investigador, investiga él. En lugar de llamar al redactor, escribe él. Y el resultado es lo peor, porque el coordinador no es especialista en nada. La solución pasa por describirlo muy claro, con exclusiones en mayúscula: NO PUEDES HACER NADA, SOLO PUEDES DELEGAR. Otro error es dar permisos de más. Si todos pueden invocar Task, el investigador llama al revisor, este al SEO y se monta un follón.

    Además hago una demo en vivo creando un artículo sobre FD, una herramienta en Rust que sustituye a find. Ves cómo el coordinador recibe la petición, planifica, lanza al investigador, luego al redactor, luego al SEO, luego al revisor, y en una sola iteración el artículo está aprobado. Con su título SEO, su meta descripción, sus etiquetas y su estructura en Markdown. Y todo esto no es programación. Es escribir artículos, preparar presentaciones o lo que se te ocurra. OpenCode no es solo un asistente para programar, es mucho más que eso. Y al final te cuento cuándo merece la pena usar multi agente y cuándo no. Porque para cambiar una bombilla no necesitas un equipo de cinco personas, necesitas un electricista.

    Capítulos del episodio:

    0:00 - Introducción: de ChatGPT a los agentes multi-propósito

    2:28 - De asistente personal a equipo de agentes especializados

    3:52 - Patrón supervisor: el jefe de obra que coordina sin ejecutar

    4:50 - Pipeline de 5 fases: planificación, investigación, redacción, SEO y revisión

    6:37 - La herramienta Task: delegación, contexto aislado y ventajas9:17 - Demo en vivo: creando un artículo sobre FD con subagentes

    13:07 - Agentes especializados: investigador, redactor y SEO

    18:56 - Control de calidad: el revisor y el bucle de retroalimentación

    23:22 - El coordinador: la no ejecución como clave del éxito

    24:58 - Errores comunes, cuándo usar multi-agente y despedida

    Más información y enlaces en las notas del episodio

  27. ATA 822 PowerPoint HA MUERTO! Genera presentaciones con IA en 15 segundos

    28 minTemporada 8 · Episodio 822

    Hace unos meses empecé a usar presentaciones para grabar el podcast, y enseguida me di cuenta de que el verdadero problema no es pensar el contenido, sino maquetarlo. Pasaba más tiempo ajustando fuentes …

    Notas del episodio

    Hace unos meses empecé a usar presentaciones para grabar el podcast, y enseguida me di cuenta de que el verdadero problema no es pensar el contenido, sino maquetarlo. Pasaba más tiempo ajustando fuentes, colores y transiciones que preparando lo que realmente quería contar. Así que me puse a buscar una solución, y lo que encontré me ha cambiado el flujo de trabajo por completo.

    En este episodio te cuento cómo he montado typst-ia, un script en Python que genera presentaciones completas en segundos. Le dices un tema, la inteligencia artificial se encarga del contenido, y Typst lo convierte en un PDF impecable. Todo desde la terminal, sin abrir PowerPoint ni Google Slides, sin suscripciones mensuales, y con un control total sobre el resultado.

    Typst es un sistema de composición moderno escrito en Rust que compila en milisegundos. Sí, has leído bien, milisegundos. Comparado con LaTeX Beamer, que tarda 5 o 10 segundos en compilar, Typst es un antes y un después. Además, su sintaxis es mucho más limpia y fácil de aprender. En el episodio lo comparo con LaTeX y con Markdown, y te cuento por qué creo que Typst se está convirtiendo en el estándar para presentaciones técnicas.

    La clave del proceso está en el system prompt. Incrusto el template real de la presentación dentro del prompt que le envío a OpenRouter, y la IA genera código Typst válido sin necesidad de retoques. Uso DeepSeek Chat por defecto —cuesta unos 14 céntimos por millón de tokens de entrada, que vienen a ser cientos de presentaciones por menos de un euro—, pero también puedes usar Claude Sonnet, Gemini Flash o Llama 3.3 si necesitas más calidad o prefieres un modelo concreto.

    El script completo son unas 200 líneas de Python sin frameworks, solo con la librería requests. Te explico paso a paso cómo funciona el pipeline: lee el template, construye el prompt, llama a OpenRouter, limpia la respuesta, escribe el archivo .typ, lo compila a PDF y lo abre en el visor. Y todo con flags para personalizar el número de diapositivas, el modelo, el nombre del archivo y hasta los reintentos si la compilación falla.

    Para rematar, hago una demo en vivo generando una presentación desde cero. Ves cómo en cuestión de segundos pasamos de una idea a un PDF listo para proyectar. Y lo mejor es que el resultado es texto plano, versionable con Git, editable con cualquier editor, y sin ningún tipo de lock-in. Si mañana quieres cambiar algo, abres el .typ y lo tocas.

    Si eres de los que hacen presentaciones técnicas, charlas, workshops, o simplemente quieres automatizar una tarea tediosa, este episodio te va a gustar. Y si nunca has oído hablar de Typst, te vas a llevar una sorpresa.

    Capítulos del episodio:
    0:00 - Introducción: presentaciones con Typst e IA
    2:52 - El problema de las presentaciones tradicionales
    5:20 - Typst: el sistema de composición moderno
    7:34 - Typst vs LaTeX vs Markdown
    8:31 - Instalación de Typst
    9:28 - Plantillas para presentaciones con Typst
    12:52 - OpenRouter y el prompt para la IA
    15:28 - El script Python: el pipeline completo
    17:41 - Demo en vivo: generando una presentación
    24:17 - Conclusiones y despedida



  28. ATA 821 Como buscar en tu cerebro digital con IA

    30 minTemporada 8 · Episodio 821

    ¿Alguna vez te has dado cuenta de que la búsqueda exacta se queda corta cuando tu base de conocimiento crece? Buscar por palabras exactas con grep o FTS5 es rápido y preciso, pero es literal y no entiende …

    Notas del episodio

    ¿Alguna vez te has dado cuenta de que la búsqueda exacta se queda corta cuando tu base de conocimiento crece? Buscar por palabras exactas con grep o FTS5 es rápido y preciso, pero es literal y no entiende contexto ni sinónimos. Por otro lado, la búsqueda semántica pura con embeddings a veces falla con términos muy específicos como rutas de archivos o comandos exactos.

    En este episodio te muestro cómo solucionar este problema combinando lo mejor de ambos mundos mediante tres técnicas avanzadas de RAG:

    • Búsqueda Híbrida (Hybrid Search): Cómo combinar FTS5 y embeddings semánticos utilizando un equilibrio ponderado (parámetro alpha).

    • Re-ranking con Cross-Encoder: Refinamiento de resultados pasando de un bi-encoder rápido a un cross-encoder preciso para priorizar la máxima relevancia.

    • HyDE (Hypothetical Document Embeddings): La técnica de generar un documento hipotético con un LLM local (Ollama) para encontrar notas mediante conceptos abstractos.

    Además, repasamos cómo integrar todo esto en tu flujo de trabajo diario mediante herramientas CLI creadas en Python y Rust, así como la integración en Neovim con sqlite.lua.

    Enlaces y recursos del episodio:

  29. ATA 820 Herramientas para Linuxeros Vagos

    24 minTemporada 8 · Episodio 820

    Este episodio va de ser vago. Pero vago en el buen sentido, eh. De esos que prefieren que una herramienta haga el trabajo pesado mientras tú te quedas con lo divertido. Resulta que hay todo un ecosistema de …

    Notas del episodio

    Este episodio va de ser vago. Pero vago en el buen sentido, eh. De esos que prefieren que una herramienta haga el trabajo pesado mientras tú te quedas con lo divertido. Resulta que hay todo un ecosistema de herramientas TUI con el prefijo "lazy" que te evitan tener que memorizar cientos de flags y opciones de comandos como git, docker, rsync o SQL. Y no, no es cutrez: son interfaces de terminal que funcionan a golpe de tecla, sin ratón, sin salir de la terminal, y encima molan.

    Te cuento cómo nació todo esto, quién es Jesse Duffield (el creador de lazygit y lazydocker, con más de 80K y 52K estrellas en GitHub respectivamente) y por qué esta filosofía de "una tecla, una acción" ha enganchado a tanto linuxero. Y lo mejor: te hago demo de las cuatro herramientas principales para que veas cómo funcionan en vivo y en directo, con sus paneles, sus atajos y sus trucos.

    Empezamos con lazygit, el rey indiscutible del ecosistema. 80.900 estrellas en GitHub, escrito en Go, y con una comunidad que no para de crecer. Desde stage línea a línea hasta rebase interactivo, pasando por undo/redo vía reflog. Te enseño cómo hacer commits, gestionar ramas, stash y hasta cherry-pick sin tener que acordarte de los flags raros de git.

    Seguimos con lazysql, el gestor de bases de datos en terminal de Jorge Rojas. Soporta MySQL, PostgreSQL, SQLite, MongoDB, MSSQL y Oracle. Navegación por teclado, autocompletado de queries, exportación a CSV y configuración por proyecto. Ideal para cuando no te apetece abrir DataGrip o DBeaver solo para hacer una consulta rápida.

    Luego viene lazyrsync, escrito en Rust con ratatui, y con una filosofía muy clara: que no se te olvide el flag ese que evita que borres todo. Perfiles reutilizables, dry-run con previsualización, protección contra --delete accidentales y paths dinámicos con variables. Perfecto para backups sin sustos.

    Y cerramos con lazydocker, también de Jesse Duffield. Cuatro paneles: contenedores, métricas, imágenes y logs en vivo. Con un vistazo ves qué contenedor consume más CPU, entras en el terminal de uno con una tecla, o ejecutas docker-compose sin acordarte del comando. Y sí, también funciona con Podman.

    Además te menciono otras herramientas del ecosistema: lazyssh, lazyjj para Jujutsu, lazykube, lazyprune para limpiar node_modules olvidados... Vamos, que hay lazy para todo.

    Capítulos del episodio:

    0:00 — Introducción: el problema de memorizar comandos

    2:05 — La filosofía lazy: scripts, TUIs y el ecosistema lazy

    4:30 — LazyGit: historia, filosofía "una tecla una acción" y +80K estrellas

    6:45 — LazyGit: demo de paneles, stage, commits, ramas y stash

    9:10 — LazySQL: Jorge Rojas, 4K estrellas y soporte multi-base de datos11:30 — LazySQL: demo con autocompletado, consultas y exportación CSV

    14:00 — LazyRsync: dry-run, perfiles y protección contra errores

    16:30 — LazyRsync: demo con columnas de estado y confirmación de borrado

    19:10 — LazyDocker: Jesse Duffield, 52K estrellas y soporte para Podman

    21:45 — Otras herramientas lazy: lazy-ssh, lazy-jj, lazy-kube, lazy-npm

    23:15 — Cierre: sé un vago inteligente, valoración y despedida

    Más información y enlaces en las notas del episodio

  30. ATA 819 RAG I con SQLite y Ollama, base de conocimiento desde cero

    27 minTemporada 8 · Episodio 819

    Llevo 15 años escribiendo notas, artículos y tutoriales. El resultado: unos 5000 archivos markdown repartidos por mi disco duro. Y, como te puedes imaginar, encontrar algo ahí dentro es como buscar una aguja en …

    Notas del episodio

    Llevo 15 años escribiendo notas, artículos y tutoriales. El resultado: unos 5000 archivos markdown repartidos por mi disco duro. Y, como te puedes imaginar, encontrar algo ahí dentro es como buscar una aguja en un pajar. Por eso en este episodio me he puesto manos a la obra para montar un sistema RAG (Retrieval-Augmented Generation) 100% local, sin depender de APIs externas, sin enviar tus datos a la nube, y con herramientas que ya conoces: SQLite, Ollama y Python.

    Este es el primero de dos episodios sobre RAG. Aquí nos centramos en construir la base de conocimiento: un pipeline que escanea tus documentos, los trocea en fragmentos manejables, extrae los metadatos del frontmatter YAML, genera embeddings con el modelo bge-m3 de Ollama, y lo guarda todo en una base de datos SQLite con búsqueda FTS5. Todo esto, además, con detección incremental de cambios: la primera ejecución tarda lo que tenga que tardar, pero las siguientes son cuestión de segundos porque solo reprocesa lo que ha cambiado.

    El stack es sencillo pero potente. SQLite con FTS5 para búsqueda textual, Ollama con bge-m3 para los embeddings, y seis scripts Python que suman unas 1300 líneas. Nada de LangChain, nada de frameworks pesados. Código limpio, comentado y que entiendes de un vistazo. El chunking respeta las cabeceras markdown, usa tiktoken para contar tokens con precisión, y los embeddings se almacenan como BLOBs en la propia SQLite. En el próximo episodio (el 821) usaremos esta base de conocimiento para hacer búsqueda semántica con similitud de coseno, búsqueda híbrida combinando FTS5 con embeddings, y hasta un plugin para Neovim.

    Puntos clave del episodio:
    - El problema: 15 años de notas, 5000 archivos, cero capacidad de búsqueda
    - La solución: RAG local con SQLite + FTS5 + Ollama, todo en tu máquina
    - Chunking híbrido que respeta cabeceras markdown y usa tiktoken
    - Pipeline incremental con detección de cambios mediante MD5
    - Embeddings con bge-m3 (568M parámetros, 1024 dimensiones)
    - Búsqueda FTS5 con snippet(), colores ANSI y sintaxis avanzada
    - Errores comunes y cómo solucionarlos

    Si te gusta el contenido, ya sabes: dale a seguir, compártelo con quien creas que le puede interesar, y déjame un comentario si tienes dudas o sugerencias. La semana que viene, en el episodio 821, montamos la búsqueda semántica y el plugin para Neovim. No te lo pierdas.

    Capítulos del episodio:
    0:00 - Introducción: RAG y base de conocimiento local
    2:12 - El problema: 15 años de notas sin buscar
    4:58 - La solución: SQLite + FTS5 + Ollama, 100% local
    7:00 - Escaneo de archivos y extracción de front matter
    10:20 - Preparación del entorno: Ollama, uv y dependencias
    12:00 - Chunking: cómo trocear los documentos
    15:45 - Estructura de la base de datos SQLite
    17:46 - Pipeline incremental con detección de cambios
    19:22 - Demo en vivo: consultas y resultados
    22:44 - Errores comunes y cómo solucionarlos
    24:10 - Resumen y adelanto del episodio 821
    25:15 - Despedida y cierre


    Más información y enlaces en las notas del episodio


Aquí están los 40 episodios más recientes de 848. Los anteriores están en el feed del podcast.

Podcasts similares

Más podcasts de Tecnología
¿Es tu podcast?

Confírmalo con una entrada en tu feed: aquí recibes un código, lo añades como podcast:txt en el canal de tu feed y nosotros lo comprobamos. Después tu podcast aparecerá como «verificado» en SoundNode.

Géneros populares

PopOldiesHip hopRockLos 80SchlagerNoticiasAlternativaDanceMetalTechnoLos años 90ElectroHouse

Ajustes

Visualización

Idioma

DeutschEnglishEspañolFrançaisPortuguês

Determina qué emisoras ves primero en la página de inicio.

Historial

Las emisoras y episodios escuchados recientemente y tus últimas búsquedas solo se guardan en este navegador.

Avisos

Un breve aviso cuando un pódcast que sigues tiene un episodio nuevo. Puedes desactivar pódcast concretos con la campana de su página.

Cuenta

Guarda tus favoritos: en la app y en la web.

App StoreGoogle PlayAmazon Fire TVSonos

Atajos de teclado

/
Abrir búsqueda
Espacio
Reproducir o pausar
← →
En el reproductor: 15 s atrás, 30 s adelante (episodios) · en una fila: siguiente tarjeta
↑ ↓
En una fila: destino dentro de la tarjeta
Inicio / Fin
En una fila: primera o última tarjeta
Esc
Cerrar ventana o menú
?
Este resumen
Reproduciendo ahora

Ir a la emisora

A continuación

    Añade episodios con «A continuación»: sonarán después del episodio actual.