Atareao con Linux

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

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

• 🌐 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á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

• 🌐 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 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

• 🌐 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.

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

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.

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

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

• 🌐 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

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

• 🌐 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

¿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

• 🌐 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

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

• 🌐 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