Atareao con Linux

atareao
  • 5.0 (2)
  • Technology
  • Updated Semiweekly

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í.

  1. 2d ago

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

    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

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

  2. 5d ago

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

    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

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

  3. Sep 24

    ATA 834 La alternativa a WatchTower para Docker

    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

    ATA 834 La alternativa a WatchTower para Docker

  4. Sep 21

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

    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 IA2:30 — ¿Qué es un workflow de IA? Skills, MCPs y prompts combinados5:00 — Arquitectura: Rust, Ollama y Docker como base del sistema8:00 — Ejemplo 1: noticias-bot — RSS filtrado a Telegram11:30 — Demo del noticias-bot: publicación automática de noticias14:30 — Ejemplo 2: tareas-bot — clasificación GTD vía Telegram17:30 — Demo del tareas-bot: "hola" vs "comprar ciruelas"20:00 — Ejemplo 3: monitor-bot — alertas de sistema con IA22:30 — Ejemplo 4: investigación asistida con RAG local26:00 — Demo del investigador: consulta sobre Podman 629: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

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

  5. Sep 17

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

    ¿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 web1:54 - Uptime Kuma: características y panel de control4:45 - Ventajas e inconvenientes de Uptime Kuma5:36 - El problema del consumo: CPU, RAM y disco7:05 - Watchbit: OIDC, dashboard y diseño por tarjetas8:43 - Comparativa de consumo: Watchbit vs Uptime Kuma10:53 - Heartbeats y monitores en Watchbit12:37 - Configuración de monitores, notificadores y plantillas14: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

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

  6. Sep 14

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

    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 útil2:30 - ¿Qué es MCP? Arquitectura host-cliente-servidor y JSON RPC 2.05:30 - Cinco razones para adoptar MCPs8:00 - MCP Filesystem: leer, buscar y crear archivos11:00 - MCP SQLite: consultar bases de datos y el no-determinismo14:00 - MCP GitHub: issues, pull requests y repositorios17:00 - MCP Web Fetch: búsquedas en internet con ahorro de tokens19:30 - MCP Time: la hora en cualquier huso horario21:30 - MCP Memory: grafo de conocimiento persistente23:30 - MCP Sequential Thinking: razonamiento paso a paso25:30 - Configuración en OpenCode, consumo de tokens y RAM27:30 - Crear tu propio MCP: Python SDK vs Rust28: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

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

  7. Sep 10

    ATA 830 Popuplatrs, publica en redes desde tu propio RSS

    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 sociales1:45 - Alternativas existentes y sus limitaciones3:00 - Qué es Popuplatrs: origen, nombre y características principales4:15 - Arquitectura técnica: Rust, Axum, SQLite y Pocket ID5:45 - Fuentes soportadas: RSS, Atom y YouTube7:00 - Publicadores: hasta nueve plataformas sociales8:30 - Panel web: dashboard, logs y republicación de errores10:30 - Programación, reintentos y control anti-spam12:00 - Motor de plantillas y personalización por plataforma13:30 - Despliegue con Docker Compose, Pocket ID 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

    ATA 830 Popuplatrs, publica en redes desde tu propio RSS

  8. Sep 7

    ATA 829 Skills imprescindibles para tu agente IA

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

    ATA 829 Skills imprescindibles para tu agente IA
See All (836)

Ratings & Reviews

5
out of 5
2 Ratings

About

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í.

Information

  • Creator
    atareao
  • Years Active
    2018 - 2026
  • Episodes
    836
  • Rating
    Clean
  • Copyright
    © atareao
  • Show Website
    Atareao con Linux

You Might Also Like