Publicidad en podcasts en: Atareao con Linux

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 🌐 Aquí lo puedes encontrar todo 👉 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

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ítulos0:00 - Introducción: gestionar las notificaciones con IA3:26 - El arco de episodios: memoria, herramientas e integración5:02 - Dos formas de uso: consultar al asistente e inyectar información6:10 - Resumen y agrupación de notificaciones y correos8:05 - La API Notification: ingesta con JSON sin parsear9:55 - Endpoints y clave de ingesta: sesión frente a integración10:29 - Claves de ingesta: token, seguridad y revocación13:53 - Estructura del mensaje y el buzón15:02 - Servicios integrados: ApiMail, Miniflux y Strava16:35 - Discriminar la información y el enfoque proactivo19:20 - Cierre y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 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

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ítulos0:00 - Intro: de la imagen muerta al diagrama editable2:33 - El diagrama que miente cuando el código evoluciona4:24 - Anuncios parroquiales: cambios en los repos4:51 - El diagrama no vive con tu código (y Mermaid tampoco lo arregla)6:22 - La propuesta: Excalidraw y un MCP con lienzo vivo9:12 - El bucle cerrado: dibuja, mira y corrige10:29 - Dos MCP y el toolkit de 26 herramientas10:58 - Instalarlo en OpenCode: un skill sin cuentas ni API keys11:52 - Demos: un cuadrado, la evolución del hombre y oxidav16:31 - Git y versionado: el diagrama como un fichero más20:43 - Límites y veredicto frente a Mermaid20:43 - Límites y veredicto frente a Mermaid22:06 - Cierre: dibuja una vez y actualízalo siempre Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 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

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ítulos0:00 - Introducción y repaso: de la memoria del 843 a las manos del asistente1:26 - Anuncios parroquiales: err-serve, valet, podtrack y el MCP de atareao.es6:03 - Del loro al asistente: por qué un chat sin manos no sirve7:26 - Las 33 herramientas repartidas en fichas y skills9:52 - El coste oculto: 11.000 tokens por un «hola»12:35 - El enrutador de herramientas: decidir qué enviar en cada mensaje14:32 - Agenda, tareas, recuerdos y las herramientas fijas de hora y ubicación18: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 permiso23:05 - Integraciones (Strava, notificaciones, noticias) y cierre del episodio Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 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

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ítulos00:00 - De Docker a Podman: el planteamiento02:34 - Dos mundos: Podman rootless en casa y Docker root en el servidor04:34 - atareao.es se caía y culpé a Contabo sin medir05:23 - El culpable estaba dentro: Redis y Valkey06:59 - Traefik, WordPress y Umami: cómo monto la infraestructura09:35 - Víctor me abre los ojos: las IPs reales no llegan11:56 - Rootless y la IP de origen: el parche de Cloudflare14:08 - La Liga bloquea rangos de IP: qué puedes hacer16:19 - HAProxy al 443 y Traefik bajando al 844319:13 - Sin setcap ni iptables: por qué Traefik sigue en contenedor22:13 - Cierre: casi nunca falla lo que crees, falla lo que no mides Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 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

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ítulos0:00 - Presentación: dar memoria a una IA y decidir qué hacer con ella2:15 - El asistente POC del viaje al sur de Italia4:10 - Un asistente sin memoria es un buscador con modales5:20 - Un paso más: contenedor Docker con Rust y React6:25 - Corto plazo y largo plazo: las distintas memorias9:40 - Lo que dije, lo que pasó y cuándo: conversación en bruto en SQLite y fichas con búsqueda semántica12:12 - Hechos sueltos, el retrato y los procesos en paralelo15:00 - El diario que se escribe solo17:05 - El proceso completo y el peso del tiempo en los recuerdos19:15 - Valet: en GitHub con licencia MIT, modelos y consumo de tokens22:45 - Los prompts de cada memoria: archivista, colapsador, consolidador, timeline y diario24: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 🌐 Aquí lo puedes encontrar todo 👉 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

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ítulos0:00 - De la memoria de tu IA a los sentidos: la nueva serie1:33 - La serie de los sentidos y el audio sucio que llega a tu IA3:14 - FFmpeg, la navaja suiza del audio y el vídeo5:57 - Instalar FFmpeg y convertir formatos en una línea7: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 silencios11:19 - Cortar y unir audio: -ss, -t, concat y fundidos13:14 - Postprocesar la voz del TTS: de radio AM a FM15:25 - La pipeline completa de voz y los scripts en Python17:05 - Audio muy sucio: afftdn, adeclick y equalizer18:29 - Conclusiones, despedida y comunidad Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 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

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ítulos0:00 - Introducción: el cierre de la trilogía GraphRAG y el reindexado del grafo2:13 - Repaso de la trilogía: qué es un GraphRAG y para qué sirve4:14 - Vector frente a grafo: por qué necesitas las dos cosas6:53 - Las cifras del grafo: nodos, notas, entidades y comunidades7:52 - La arquitectura híbrida en tres pasos y el parámetro alfa9:17 - Primera búsqueda: cómo montar un proxy inverso y el efecto del alfa11:21 - Profundidad de vecinos, Ollama y cómo interpretar los resultados13:53 - Filtros: min-weight, metadatos y tipos de elemento14:52 - graphrag ask: preguntas con fuentes citadas (cómo configuro Traefik)16:54 - Comunidades: build incremental y automatización con cron17:42 - Ejemplo con GIMP: búsqueda, ask y la ventaja de no alucinar17:42 - Ejemplo con GIMP: búsqueda, ask y la ventaja de no alucinar20: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

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ítulos0:00 - Presentación: sqlite-utils, la navaja suiza de SQLite2:20 - Por qué SQLite: GraphRAG, portabilidad y contexto de la serie4:20 - El problema de DBeaver y qué resuelve sqlite-utils6:00 - Instalación con UV y primeros pasos8:30 - Explorar tablas, columnas y esquemas11:30 - Navegar los datos con rows14:00 - Filtrar con where, ordenar y evitar inyección SQL16:30 - Consultas complejas, joins y selects a medida18:30 - El combo killer: sqlite-utils + jq + LLM20:30 - Escribir y transformar: insertar, crear, exportar y renombrar23:00 - El módulo Python y los consejos: WAL, Vacuum, Optimize y FTS25: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

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 conectado2:45 - Qué veremos hoy y la trilogía GraphRAG4:20 - Chunking: trocear las notas en ideas autónomas7:50 - NER: extraer entidades con un modelo local7:50 - NER: extraer entidades con un modelo local11:20 - Etiqueta, tipo y confianza: qué guardamos de cada entidad13:50 - Nodos y aristas: conectar tus notas con semántica17:10 - Construir el grafo con graphrag build20:20 - SQLite e incrementalidad: el grafo que se actualiza solo24:10 - Comunidades con el algoritmo Leiden27:00 - Cierre y avance del siguiente episodio Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux✈️ Telegram (el canal) 👉 https://t.me/canal_atareao🦣 Mastodon 👉 https://mastodon.social/@atareao🐦 Twitter 👉 https://twitter.com/atareao🐙 GitHub 👉 https://github.com/atareao

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ámico3:15 - Filosofía UNIX: domar datos sin escribir Python5:45 - Qué es jq y qué es yq8:00 - Filtros básicos con jq10:45 - Funciones clave de jq: select, unique, map y group_by13:15 - yq y Front Matter: extraer metadatos16:00 - Edición in-place y conversión YAML ↔ JSON18:30 - Pipelines: fd + yq + jq para extraer tags21:00 - Del Front Matter al grafo de conocimiento22:45 - Notas viudas y pipeline con IA local24: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 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux✈️ Telegram (el canal) 👉 https://t.me/canal_atareao🦣 Mastodon 👉 https://mastodon.social/@atareao🐦 Twitter 👉 https://twitter.com/atareao🐙 GitHub 👉 https://github.com/atareao

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 digital3:56 - Por qué la búsqueda clásica (grep) falla7:05 - Qué es GraphRAG: embeddings y vectores10:45 - Los tres límites del RAG clásico13:40 - Grafos de conocimiento: nodos, aristas y pesos17:50 - La herramienta en Rust con Ollama20:20 - Demo: crear el grafo y explorar estadísticas en SQLite23:00 - Búsqueda semántica (search) frente a búsqueda literal (FTS)25:40 - Rutas y relaciones: path y graph28:10 - El mapa en la terminal (TUI)29:40 - Conclusiones y cierre Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux✈️ Telegram (el canal) 👉 https://t.me/canal_atareao🦣 Mastodon 👉 https://mastodon.social/@atareao🐦 Twitter 👉 https://twitter.com/atareao🐙 GitHub 👉 https://github.com/atareao

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 datos2:30 - El problema: bots de Rusia, China y Vietnam escaneando tu VPS3:50 - Cifras impactantes: 921.000 peticiones, 650.000 bloqueadas en 24h5:30 - Por qué Traefik no basta y cómo nace Shuul6:30 - Arquitectura: backend en Rust, frontend en React y un módulo en Go8:30 - Pipeline WAF: forward auth, geolocalización cacheada y reglas regex10:40 - Pipeline Jail: Shuul Reporter y bloqueo por intentos fallidos13:00 - Configuración, variables de entorno e integración con Traefik16:00 - Reglas, pesos, templates: Allow, Deny, ubicaciones y nodos Tor18:30 - Dashboard, logs en tiempo real y reflexión finalMás información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux✈️ Telegram (el canal) 👉 https://t.me/canal_atareao🦣 Mastodon 👉 https://mastodon.social/@atareao🐦 Twitter 👉 https://twitter.com/atareao🐙 GitHub 👉 https://github.com/atareao

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 Minerva2:30 - Feedback: el caos de organizar un viaje5:30 - La pila tecnológica de Minerva9:00 - Arquitectura: bot de Matrix en Rust12:30 - Herramientas: Google Places, Brave Search y Wikipedia16:00 - El prompt y la personalidad del asistente19:00 - Datos en bruto frente a datos parseados22:00 - Planificación de viajes con Minerva25:00 - Minerva en acción: ejemplos reales en Puglia28:30 - Alucinaciones, errores y lecciones aprendidas32:00 - Limitaciones de Matrix y el futuro del proyecto34:30 - Conclusiones: más allá de escribir códigoMás información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux✈️ Telegram (el canal) 👉 https://t.me/canal_atareao🦣 Mastodon 👉 https://mastodon.social/@atareao🐦 Twitter 👉 https://twitter.com/atareao🐙 GitHub 👉 https://github.com/atareao

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 actualizadas1:30 - ¿Por qué WatchTower ya no es suficiente?3:30 - Alloy: qué es y por qué está hecho en Rust5:30 - Arquitectura: Axum, Bollard, SQLite y React7:30 - Instalación y autenticación con OIDC y PocketID9:30 - El dashboard: contenedores, stacks y estado de un vistazo11:30 - Políticas de actualización por contenedor13:30 - Notificaciones vía Telegram y Matrix15:00 - Historial de actualizaciones (lo que WatchTower no tenía)16:30 - Logs en tiempo real e inspección de contenedores18:00 - Integración con Traefik19:00 - Interfaz adaptativa para móvil20:00 - Consumo de recursos: funciona en una Raspberry Pi23:00 - Conclusiones: ¿merece la pena el cambio? Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux✈️ Telegram (el canal) 👉 https://t.me/canal_atareao🦣 Mastodon 👉 https://mastodon.social/@atareao🐦 Twitter 👉 https://twitter.com/atareao🐙 GitHub 👉 https://github.com/atareao