El nacimiento de Hermes Criollo: bronca, malestar y una laptop en mi cama

Imagen realizada por la IA de Google, Gemini.


Una recaída que me dio claridad.

Diez días en casa. Junio de 2026, frío húmedo, dolor y malestar que no achicaban, y una laptop apoyada en la cama, conmigo usándola boca abajo, porque no había otra posición que no doliera. Ahí, entre incomodidades varias y medicación fuerte, empecé a preguntarme qué hacer para pasar el tiempo, entre película y documental. Recordé que todo lo que probaba en IA local había sido una porquería, y me había quedado con la espina.

Probé de todo: varios modelos que se suponía que "en mi hardware reducido tenían que funcionar", varios modos de DeepSeek-Coder 16B, de Qwen2.5-Coder 14B, CodeLlama 34B, Dolphin-Mixtral 46B...
Nombres grandiosos, comparaciones impresionantes, pero en la realidad de mis prácticas, una tomada de pelo. Le preguntaba a otras IAs "web" y me decían "necesitás un hardware bastante más potente...

Comparto mi hardware según el "prompt" que le inyecté a mi terminal cada vez que arranca:


 RUNNING ON : VOID LINUX
 KERNEL     : 6.18.35_1
 CPU        : AMD RYZEN 7 5800XT 8-CORE PROCESSOR
 GPU        : ADVANCED MICRO DEVICES, INC. [AMD/ATI] NAVI 23 [RADEON RX 6600/6600 XT/6600M] (REV C1)
 RAM        : TOTAL 32, FREE 25.42

 REMEMBER TO THINK WITH UNIX, KISS AND POSIX HEAD.

 READY.
 █

Yo pensaba... Si con este software optimizado y este hardware, que son bastante prolijos, no me da para correr un modelo decente... y si el resultado de estos modelos es patético... ¿qué tan lejos estoy de poder correr un modelo que realmente sea útil?

Probé modelos que se olvidaban de lo que habías dicho minutos atrás, que se arrastraban sin dar un resultado correspondiente a la espera (2 a 6 caracteres por segundo cronometrados en tiempo real por mí mismo para dar un resultado pésimo en requerimientos simples de programación BASH), que requerían una GPU de 1500 dólares para arrancar, o que directamente no funcionaban por diversos motivos, ejemplo: solo optimizadas para Windows y en el mejor de los casos, para Ubuntu.

Probablemente tengas la misma bronca que yo. No sé si ya pasaste por lo mismo... Instalás algo que promete ser "el futuro de la IA abierta" y terminás "debuggeando" dependencias rotas, con un "prompt" que se cae a pedazos porque al modelo se le llenó la memoria y vos "precisás más de lo que ya tenés" como consejo y seudo base muy improbable que yo al menos no me animaría a seguir a la luz de mi experiencia con este tema.


2 excepciones en el desierto de la subnormalidad digital.

De todo ese basural desinteligente, solo 2 modelos me hicieron decir "acá hay algo"... solo "algo", en principio... "Nous Hermes 3 8B" y "DeepSeek R1 32B".

DeepSeek programando en BASH era solo más prometedor que los otros, sin llegar a ser realmente bueno. En mi hardware funciona, pero lo deja respirando con pulmones de viejo fumador. El Hermes, en cambio, era compacto, rápido y... sorprendentemente inteligente para ser un modelo pequeño en comparación con otros groseros y grotescos que ya había probado. Corría sumamente holgado, era realmente inteligente, no tenía esa corrección política ridícula que te meten los modelos de OpenAI, DeepSeek, Google... y que también te meten los locales muchas veces... una total ridiculez.

Pero tenía 2 problemas para mí.

Primero: se olvidaba. Su ventana de contexto nativa era tan pequeña (2048 tokens), que a las 5 o 6 preguntas, ya había perdido el hilo. ¿Cómo es posible mantener una conversación seria con alguien que tiene amnesia cada cinco minutos, por más que tenga el IQ de Einstein?

Segundo: estaba desconectado del presente. Su fecha de corte era 2024. Cualquier cosa posterior, no la sabía. Y en 2026 y contando, eso era un problema grave.

Así que empecé a pensar en voz alta, en la cama, lidiando con mi enfermedad.

 

La sinfonía criolla.

Yo no inventé el modelo, ni el motor. A eso lo hicieron Nous Research ( https://nousresearch.com/ ) y Ollama ( https://ollama.com/ ). Esa gente hizo todo el trabajo que de verdad debe ser laureado, si vamos al grano.

Lo que yo hice —y perdón si suena soberbio, pero es la verdad— fue orquestar todo. Construí un puente entre el modelo, el motor y el usuario. Y sí, me ayudaron 3 IAs "online": DeepSeek, Gemini y Claude. No fue fácil.

Un puente que...

    Expande la memoria del modelo. Le forcé una ventana de contexto de 16384 tokens. No es magia, es meterle en la cabeza TODO el historial de la conversación antes de cada respuesta. No confiar en su "memoria nativa" (que es realmente muy mala). Tomar el control. Inyectar.

    Le da acceso al presente. El comando /net raspa DuckDuckGo en tiempo real. El usuario pregunta algo, el script busca, inyecta los resultados frescos, y recién ahí el modelo responde. No adivinanzas, no delirios, no bucles estúpidos ni respuestas "según mi entrenamiento de 2024...". Datos reales, actualizados, de ahora.

    Hace que todo fuera automático: todo concentrado y controlado por 1 solo script BASH. Elegís dónde instalar esta IA, no toca el sistema, descarga todo, configura todo, limpia todo cuando te cansás. Sin documentación de 50 páginas, sin "compila esto", sin "dependencias que no se resuelven". ¡Sin sudo!


Por qué "del laburante".

Porque vos tenés una computadora común. Porque no podés gastar 5000 dólares en una GPU. Porque el futuro de la IA no puede ser solo para los que tienen guita, mientras los modelos fuertes son los que le dejan el culo al aire a tu privacidad y a tu bolsillo, porque por ahí viene la mano.
La mayoría de los proyectos de IA local son corporativos, con otro nombre. Te venden "open source", pero necesitás un clúster de GPUs para correrlo. O te venden "accesible", pero el modelo está tan castrado con filtros éticos que no puede decir una sola opinión fuerte.

"Hermes Criollo" no tiene eso. Corre en hardware común. No tiene censura. No le importa si hacés una pregunta incómoda, polémica, filosóficamente densa. Te va a responder con análisis, no con evasivas.
Y si se va a quedar sin contexto, el script se lo va a reinyectar. Y si no sabe algo actual, lo buscás con /net. Y si querés que se calle la boca con vómitos máquina al pedo, lo ponés en modo silencioso. Y si querés ver qué está pasando atrás, lo ponés en modo verborrágico y te bancás el vómito en la jeta.

Opciones. Control. Libertad.


Cómo funciona técnicamente.

El proyecto consta de 3 archivos:

    Hermes_criollo.sh: el orquestador. BASH puro. Maneja la instalación, el menú, los procesos, las rutas. No tiene magia, tiene lógica simple y confiable, a lo UNIX, POSIX, KISS. Es el verdadero laburante: instala, desinstala, enciende, apaga, copia, elimina, controla.

    hermes_net.py: el cerebro híbrido. Python (sí, me duele decirlo, pero es potente, más allá de ser un adefesio digital). Maneja el historial, las búsquedas web, la inyección de contexto, la comunicación con Ollama. No pude hacer esto con BASH. Ni solo ni con ayuda de IA. No sé si se puede, pero en Python fue sencillo lograrlo, de entrada.

    ayuda.txt: no hace falta aclarar mucho más, en este caso.


El bucle sencillo pero poderoso.

    El usuario escribe una pregunta.
    Si usa /net, el script busca en DuckDuckGo y acumula resultados.
    El script toma TODO el historial de la conversación (hasta 16384 tokens).
    Le agrega los resultados de internet si los hay.
    Le mete todo eso al modelo en el medio del marote y a la fuerza antes de que responda. Educación pre Vareliana: la letra con sangre entra.
    El modelo responde con memoria completa y datos frescos.
    El historial se actualiza.

No es IA aumentada. Es IA forzada a ser mejor de lo que es. Como un jugador de fútbol sin renombre pero con esteroides. O un laburante con frío, hambre y bronca: ojo.


Información adicional.

El proyecto ya está en Codeberg desde hace unos minutos ( https://codeberg.org/entropiabinaria/hermes_criollo ). Código libre, sin rastreos, sin servidores. Lo bajás, lo corrés, es tuyo.
Podés meterle más modelos, más opciones de búsqueda, más trucos de inyección. La base está ahí. El resto es imaginación.
Y si te preguntás por qué le puse "criollo"... porque es la viveza de hacer mucho con poco. Porque es la inteligencia del que se las arregla. Porque no necesitamos que nos vengan a salvar desde Silicon Valley.
Ya tenemos las herramientas. Solo faltaba atarlas con alambre grueso tensado a puro dedo, bronca y convicción.


Y eso hice. Andá y probala. Salú, hermano de clase trabajadora.

Hugo Napoli, junio de 2026


OCR, Tesseract y la evolución del reconocimiento de texto

En este artículo te voy a hablar de OCR, Tesseract, ocrmypdf, algo de hisotoria y algo de práctica con OCR. Vamos allá.
¿Qué es OCR?
OCR significa Optical Character Recognition (Reconocimiento Óptico de Caracteres). Es una tecnología que permite extraer texto desde imágenes, PDFs escaneados, fotografías y documentos impresos.

Tesseract: Un Breve Resumen
Tesseract es un motor de OCR de código abierto que fue desarrollado inicialmente por Hewlett-Packard en la década de 1980 y posteriormente mantenido por Google. Su capacidad para reconocer texto en imágenes ha hecho de Tesseract una herramienta fundamental en el campo del OCR. A lo largo de los años, ha evolucionado para incorporar técnicas avanzadas de aprendizaje automático, lo que lo ha convertido en un referente en la comunidad de OCR. El reconocimiento óptico de caracteres (OCR) ha avanzado significativamente en las últimas décadas, impulsado por innovaciones tecnológicas y el desarrollo de algoritmos más sofisticados. En este contexto, Tesseract se destaca como un hito histórico que ha influido profundamente en el ecosistema OCR. Aunque los sistemas OCR modernos no se basan directamente en Tesseract, su impacto es innegable.

Dominio del OCR Libre
Tesseract ha sido un pionero en el ámbito del OCR libre, permitiendo a los desarrolladores y empresas acceder a una herramienta poderosa sin costo alguno. Su licencia de código abierto ha fomentado la colaboración y la innovación, permitiendo a la comunidad contribuir a su desarrollo. Esto ha llevado a la creación de una amplia gama de aplicaciones y herramientas que utilizan Tesseract como motor de OCR, desde aplicaciones móviles hasta sistemas de gestión de documentos.

Influencia en Datasets y Herramientas
La popularidad de Tesseract ha influido en la creación de datasets y herramientas que son fundamentales para el desarrollo de modelos de OCR modernos. Muchos datasets de texto e imágenes han sido diseñados específicamente para ser utilizados con Tesseract, lo que ha facilitado la investigación y el desarrollo en este campo. Además, la comunidad ha creado herramientas complementarias que mejoran la funcionalidad de Tesseract, como bibliotecas para la preprocesamiento de imágenes y algoritmos de corrección de errores.

Integración con IA Moderna
Con el auge de la inteligencia artificial, Tesseract ha evolucionado para incorporar técnicas de aprendizaje profundo. Esto ha permitido mejorar su precisión y adaptabilidad en el reconocimiento de texto, especialmente en contextos complejos como la lectura de documentos manuscritos o textos en diferentes idiomas. La integración de modelos de IA ha ampliado las capacidades de Tesseract, permitiéndole competir con soluciones comerciales que antes dominaban el mercado.

Conclusiones
La influencia de Tesseract en el campo del OCR es innegable. Ha definido workflows, inspirado pipelines, dominado el OCR libre y ha influido en la creación de datasets y herramientas modernas. A medida que la tecnología avanza, Tesseract continúa siendo un pilar en el desarrollo de soluciones de OCR, adaptándose a las nuevas demandas y desafíos que presenta la inteligencia artificial moderna. Su legado perdura, y su impacto se siente en cada rincón del ecosistema de OCR actual.

Los OCR modernos no están construidos encima de Tesseract directamente. Pero Tesseract: fue una base histórica enorme, influyó muchísimo en el ecosistema OCR y luego él mismo adoptó IA parcialmente. Tesseract abrió muchísimo camino, fue una base histórica enorme e influyó profundamente en todo el ecosistema OCR. Tesseract es para OCR lo que Linux fue para servidores o Blender para el 3D libre: quizá no siempre el más avanzado, pero sí uno de los proyectos más influyentes e importantes.

Como usar Tesseract y ocrmypf en la terminal de Linux
Comandos con Tesseract
sudo apt install tesseract-ocr

Instalar Tesseract en debian y deribadas.

sudo apt install tesseract-ocr-spa

Así se instala un lenguaje para Tesseract en Debian, por ejemplo si el último parámetro fuera -eng sería el lenguaje inglés.

sudo pacman -S tesseract

Instalar Tesseract en Arch y deribadas.

sudo pacman -S tesseract-data-spa

Así se instala un lenguaje para Tesseract en Arch, igualmente si el último parámetro fuera -eng sería el lenguaje inglés.

tesseract imagen.png salida

Esto genera un .txt con texto detectado, imagen.png es el archivo imagen con texto y salida será el archivo.txt donde se copiará el texto.

tesseract imagen.png salida -l spa

Basicamente lo mismo que el comando anterior pero forzando la salida en español con el parámetro -l spa.

tesseract imagen.png salida -l spa

Basicamente lo mismo que el comando anterior pero forzando la salida en español con el parámetro -l spa.

tesseract imagen.png stdout

cCopia el texto de la imagen elegida y lo muestra en la terminal (no lo guarda en ningún tipo de archivo).

tesseract imagen.png salida -l spa --psm 6

El parámetro psm 6 proporciona una mayor precisión en el OCR.

tesseract imagen.png salida pdf

Este comando genera la salida de una imagen con texto seleccionable en un archivo .pdf

Comandos con ocrmypdf
sudo apt install ocrmypdf

Así se instala ocrmypdf en Debian y deribadas.

yay -S ocrmypdf

Así se instala ocrmypdf en Arch y deribadas (si solo está por AUR, pero si quieres instalarlo de otra forma te dejo un enlace con las indicaciones para hacerlo: enlace).

ocrmypdf archivo.pdf archivo-ocr.pdf

Esto convierte un archivo pdf a pdf seleccionable ahora en este nuevo archivo podemos buscar palabras, copiar texto, y hasta indexarlo.

ocrmypdf —deskew entrada.pdf salida.pdf

Esto mejora páginas torcidas.

ocrmypdf —clean entrada.pdf salida.pdf

Esto elimina el ruido, o distorsión en el texto, mostándolo más limpio.

ocrmypdf —force-ocr entrada.pdf salida.pdf

Esto fuerza a que el documento sobreponga el ocr aunque ya tenga texto encima.

Bueno, eso es todo por ahora, si alguien desea ver estos comandos en acción dejo un video sobre el tema en este enlace y ojalá este artículo ojalá sea de utilidad. Larga vida al software libre.

LVM: la gran mentira corporativa del almacenamiento (o por qué tus medios de almacenamiento no son piezas de Lego)


LVM: la gran mentira corporativa del almacenamiento (o por qué tus medios de almacenamiento no son piezas de Lego).

En Entropía binaria siempre defendimos a rajatabla la filosofía KISS (Keep It Simple, Stupid) y la soberanía sobre nuestros sistemas. Creemos en el software que hace una sola cosa y que la hace bien, y en mantener el control absoluto sobre los fierros. Pero de vez en cuando, la industria nos quiere vender espejitos de colores, empaquetando complejidad innecesaria bajo la promesa de la "comodidad". Hoy vamos a hablar de una de las peores basuras corporativas que se han estandarizado en el mundo Linux: el Logical Volume Manager, o LVM.

Te lo venden en todos los manuales y cursos genéricos como la solución definitiva. Te dicen que con LVM administrar discos es como jugar con piezas de Lego: podés poner y sacar unidades en caliente, expandir el espacio mágicamente y ser feliz.
Lo piden en "LinkedIn" y muchas veces puede llegar a ser bueno incluirlo en tu CV, solo para agarrar ese laburo.
Pero es una profunda y absoluta mentira.

El ADN de LVM.

Al código original de LVM lo escribió un alemán llamado Heinz Mauelshagen en 1998. El tipo trabajaba para una empresa llamada Sistina Software. ¿Y de dónde sacó la inspiración? Copió el diseño del administrador de volúmenes de HP-UX (el pesado UNIX propietario de Hewlett-Packard), que a su vez estaba basado en el sistema de Veritas. Desde su ADN, es tecnología pensada para armarios llenos de discos en datacenters de los años 90.
Como a Red Hat no solo produce este tipo de tecnologías basura sino que también le interesa adquirirlas cuando no las pueden crear en casa, la necesitaban para vender soporte caro a los bancos (que tenían servidores de base de datos gigantes), y en 2003 terminan comprando Sistina Software. A partir de ahí, Red Hat adoptó a LVM como su hijo pródigo, lo estandarizó (lo metieron por defecto en los instaladores de RHEL y Fedora) y financiaron el desarrollo de LVM2. Por eso, hoy en día, LVM es sinónimo del ecosistema Red Hat/SUSE y su filosofía de "venderte la cura para la enfermedad de complejidad que ellos mismos te encajaron de prepo", solo porque a ellos les sirve, no a vos, como siempre.

Mi experiencia en el barro: preso en mi propio sistema.

Hablo desde la experiencia cruda, porque cometí el error de probarlo en mi instalación diaria hace tiempo, cuando todavía usaba openSUSE, que lo ofrece en su instalador como "una opción más a considerar". El resultado fue catastrófico; quedé más preso y atado de manos que si hubiera comprado un producto de Apple. No podía zafar de ninguna manera de ese ecosistema sórdido.

El mito del "Lego" se me desmoronó en la cara el día que necesité desconectar físicamente un disco duro secundario. Era una unidad que solo contenía datos intrascendentes, archivos sueltos. Nada del sistema operativo estaba ahí. Tiré del cable SATA y, al encender la máquina, se me jodió (sí, no hay otra palabra posible, creeme) todo el sistema LVM entero. El núcleo entró en pánico y la máquina se negó a arrancar.
¿Por qué? Porque para esta tecnología de mierda (no hay otra palabra posible), vos no tenés discos independientes. Tenés una "bolsa negra", una volqueta con tapa. Si le sacás un bloque a esa bolsa, aunque sea de datos inútiles, el gestor asume que toda la estructura está corrupta. No opera en caliente un carajo; si no le avisás por terminal con comandos rebuscados que vas a retirar un volumen, te destruye el acceso al resto.

Y ni se te ocurra intentar formatear una de esas particiones lógicas por tu cuenta. Al hacerlo, le cambiás el UUID a la partición. La capa de LVM pierde el rastro, el fstab enloquece y, de nuevo, te cargás todo el arranque del sistema. Es una trampa mortal diseñada para alejarte del control real de tu máquina.
Humo corporativo: ¿quién usa realmente esto?
Nos repiten que es un "estándar de la industria". Pero hagámonos una pregunta seria: ¿Google, Netflix, Spotify o Anthropic usan LVM en sus servidores de producción masiva?
La respuesta es un rotundo "no".

Esos gigantes tecnológicos no pierden el tiempo con un administrador redimensionando volúmenes lógicos a las tres de la mañana. Operan con sistemas de archivos distribuidos y tratan a los servidores como tristemente se trata al ganado. Si un disco se llena o falla, el nodo se descarta, el tráfico se redirige y se levanta una máquina nueva. LVM ahí es puro ruido, una capa de abstracción inútil que solo agrega puntos de fallo.
LVM es, en esencia, tecnología heredada para infraestructuras corporativas monolíticas y dinosaurios informáticos. Está pensado para ese viejo servidor Red Hat en el sótano de un banco que corre una base de datos gigante que no se puede apagar nunca, o para tapar la pésima planificación de hardware de un administrador que necesita meter tres discos nuevos a un NAS departamental sin cortar el servicio. Para tu PC de escritorio, para tu notebook o para un servidor web limpio, es un estorbo. Es el ejemplo perfecto de una NTI (Nueva Tecnología Innecesaria).

Conociendo al enemigo: cómo funciona la trampa.

Yo fui librero durante 15 años. Llegué a odiar a autores como Osho y Paulo Coelho, y a muchos otros que ni siquiera operaban en ese nivel, lucrando con las miserias de la gente de a pie. Una vez, una clienta me dijo "si no lo leíste no podés criticarlo solo por la "pinta" o por las contratapas de sus libros". Más allá de que ese es un error bastante importante, porque vos podés informarte sobre esdta clase de fantasma literario por artículos y charlas que dan escritores de verdad, leí, muy a mi pesar y finalmente "El alquimista". ¿Te imaginás lo que pasó cuando la clienta volvió?

Para odiar algo con fundamentos técnicos, primero hay que entender cómo funciona.
El problema central de LVM es que destruye la relación directa entre el sistema operativo y el metal, inyectando tres pesadas capas de abstracción.

Vamos a desarmar esta arquitectura "de arriba hacia abajo".

1. PV (Physical Volume - Volumen físico).

Esta es la capa base, el metal real. Un PV puede ser un disco duro entero (/dev/sdb) o una partición de hardware clásica (/dev/sda2). En un sistema limpio, acá es en donde formateás y guardás tus datos. Pero en LVM, al hardware se lo "marca" y se lo vacía de identidad para entregárselo al gestor. El disco deja de ser un disco para convertirse en un simple ladrillo ciego.

2. VG (Volume Group - Grupo de volumen).

Acá es en donde ocurre el desastre lógico. LVM agarra todos esos "ladrillos" (los PVs) y los mete adentro de una gran "caja de fierro", fusionándolos. Este es el VG. Si metiste un disco de 500GB y otro de 1TB, el VG le dice al sistema: "hola, soy un gran tanque de 1.5TB".
El problema mortal reside en que los datos se esparcen por este tanque de forma abstracta. Por eso, cuando yo saqué mi disco de datos en openSUSE, el VG sintió que le habían arrancado un pedazo de su propia carne y bloqueó toda la estructura.

3. LV (Logical Volume - Volumen lógico).

Como el sistema operativo no puede instalarse en una "volqueta", LVM tiene que crear particiones virtuales para engañarlo. Esos son los LVs. Dentro de tu gran Grupo de Volumen, vos recortás pedazos de espacio virtual y les ponés nombre: un LV para la raíz (/), un LV para la swap, otro para el /home.
A los ojos de tu sistema Linux, estos LVs parecen particiones reales y recién a ellos se les da un formato (ext4, xfs). Pero es una ilusión; por debajo, están fragmentados y dependientes de esa gran "bolsa frágil" que es el VG.

Conclusión para administradores de verdad.

La soberanía digital empieza por entender exactamente dónde están guardados nuestros bits. Cada capa de abstracción que metemos entre el software y el hardware es un lugar oscuro donde los problemas se esconden y se multiplican.
Si querés un sistema robusto, rápido y del que tengas el control absoluto, mantenete alejado de LVM. Usá lsblk para mirar el mapa, cfdisk para esculpir el metal con precisión, dale un formato directo y montalo limpio en tu fstab mediante su UUID. Esa es la verdadera forma UNIX. Todo lo demás, es humo corporativo. O, por qué no, mierda corporativa.

Apéndice: cómo RedHat justifica esta basura.

Para poder comprender cómo esta corporación (la cual es la sombra corta de IBM) justifica esta tecnología excrementicia y por qué la implementan en el mundo real, tenés que posicionarte mentalmente en el sótano de un banco o en el datacenter de una multinacional tradicional en donde no importa la filosofía KISS, los principios POSIX, la elegancia del código ni la soberanía digital; ahí lo único que importa es que el servidor todopoderoso no se apague nunca, porque si el sistema de tarjetas de crédito se llega a caer tan solo por 5 minutos, las cabezas seguro empezarán a rodar (porque eso sí les importa, que el capitalismo de consumismo funcione "24-7" y que lo demás reviente tranquilamente porque "eso no es problema de ellos").
Red Hat implementa LVM (pienso que casi exclusivamente) para resolver 3 problemas corporativos de infraestructura pesada que el en el mundo de las particiones físicas no se puede solucionar a menos que se hable de "algunos reinicios de por medio".

Estos son 3 escenarios reales que vi que tienen validez, al menos para comprender este tema.

Escenario 1. Retiro de unidades de almacenamiento a punto de "sonar como arpa vieja": el comando "pvmove".

Imaginemos que en el 5° subsuelo de un Banco existe un servidor que tiene un "grupo de volúmenes" (la "bolsa negra" o "volqueta" de la que te hablé antes) conformado por cuatro "discos duros de gran tamaño". De repente, el sistema de monitoreo avisa que el disco número 3 está reportando errores mecánicos y dando avisos determinantes de que va a morir en cualquier momento.
Si fuera "metal puro", el administrador tendría que apagar el servidor, sacar el disco, poner uno nuevo, colocar el disco dañado en otro equipo, arrancar a ese equipo con un "LiveCD", extraer los datos, copiárselos a un servidor en marcha, en caliente y quién sabe haciendo no se sabe qué peripecias - porque el consumismo debe continuar vivo - y finalmente rezar, aunque sea ateo, para que no se hayan perdido datos ni hayan quedado configuraciones corruptas.
Con "LVM", el administrador conecta un disco nuevo al rack en caliente. Lo mete a la volqueta usando vgextend. Luego, ejecuta el comando mágico de esta tecnología: pvmove. Este comando agarra todos los bloques de datos del disco que está fallando y los muda físicamente al disco nuevo, en segundo plano, mientras el servidor y la base de datos siguen atendiendo clientes sin enterarse de nada. Cuando termina la mudanza, el administrador saca el disco roto de la volqueta con "vgreduce" y lo tira a la basura; todo dentro de un tiempo de inactividad récord en comparación a lo que sucedería sin LVM.

Escenario 2. El precongelamiento a la velocidad del rayo (los respaldos tipo "snapshot").

Esta es una gran carta bajo la manga para poder "vender" LVM a grandes empresas sin que siquiera sepan de qué se trata. En una base de datos de 10 Terabytes en la cual se están escribiendo transacciones todo el tiempo, no es posible "simplemente copiar los archivos a un disco externo para hacer un respaldo": como los datos cambian mientras se copian, el respaldo queda corrupto.
Acá LVM se usa a modo de "viveza criolla": el administrador ejecuta "lvcreate -s" y toma un snapshot (una instantánea). Esto no copia los 10 Terabytes en el acto a "velocidad imposible", sino que "congela" el estado de los bloques en ese milisegundo exacto. El administrador hace su copia de seguridad leyendo ese "fotograma congelado", mientras los de la "película" en la base de datos, siguen en movimiento.

Escenario 3. El pánico del espacio agotado: "lvextend".

Son las 4 y media de la tarde, el servidor de archivos principal de la empresa llega al 100% de capacidad y nadie puede guardar un documento más. Con particiones tradicionales, habría que migrar los datos a un disco más grande en la madrugada, tal como ya hemos hablado en el escenario 1: apagar el servidor, sacar el disco, poner uno nuevo, colocar el disco dañado en otro equipo...
Con "LVM", el administrador va corriendo al rack, le enchufa tres discos nuevos y los configura para que empiecen a formar parte de la volqueta, ejecutando "lvextend" para hacerle saber al "volumen lógico" que ahora es más grande, y luego utiliza una herramienta como "resize2fs" para estirar el sistema de archivos (el cual posiblemente no sea el legendario ext4 sino alguno estilo "NTI" como btrfs o xfs). En menos de 30 minutos, quizás, "el disco C del "Güíndor Server 2003 con Áti Dirétory", pasa de tener 10 Terabytes de capacidad a tener 26, mientras los empleados del Banco siguen dando préstamos y VISA sigue permitiendo que las personas retiren TVs de 40 pulgadas en cómodas cuotas expedidas en un supermercado barrial.

Quise explicar todo esto para terminar siendo justo con la herramienta pero implacable con su filosofía y advertirte fuertemente en cuanto a su uso. LVM, pese a "sonar interesante", es una herramienta de contingencia corporativa que perpetúa el descontrol y el desorden: es un parche complejo diseñado para que un sysadmin no tenga que apagar un servidor monolítico (así se le llama a los servidores poseedores de la tríada interfaz, lógica de negocio y base de datos) ni se detenga nunca a prever este tipo de problemática de antemano.
Por eso me arruinó la instalación en mi PC y por eso es una porquería para el 99% de los casos de uso normales. No está diseñado para un usuario normal ni para un administrador de servidores que planifica bien su almacenamiento y quiere tener soberanía total sobre sus discos; está diseñado para la desesperación empresarial de no poder apagar un equipo y quizás hasta para ahorrar costos en planificación y mantenimiento.
La regla de oro a esta escala es que el hardware se asume como descartable. Con LVM en servidores realmente imponentes, como podrían ser los de Google para Gemini, Netflix, Spotify, Anthropic, DeepSeek, etc, tendrías que estar manejando más de "100.000 discos duros". Cada día fallarían entre 0 y 50. Con LVM, tendrías que tener a cargo un verdadero ejército de administradores tipeando comandos de rescate las 24 horas. Para evitar eso, a esta escala se usa el Almacenamiento Definido por Software (SDS) y los Sistemas de Archivos Distribuidos, no este "barro en la joya" de LVM.
Red Hat te encaja LVM por defecto para el servidor monolítico de una PyME o de una oficina gubernamental. Pero cuando a Red Hat la contrata una empresa de telecomunicaciones para armar un datacenter realmente grande o un clúster con miles de nodos, Red Hat tampoco usa LVM.
Para la escala masiva, Red Hat compró otra empresa y te vende Ceph (Red Hat Ceph Storage), el cual es un sistema de almacenamiento distribuido por red que lee directamente el disco físico desnudo (BlueStore) saltándose a LVM por completo porque agrega latencia y puntos de falla innecesarios.

¿Viste ahora cómo es la cosa? ¡Saludos!

Aprendemos a usar grep en el aula: guía breve pero fundamental.



Aprendemos a usar grep en el aula: guía breve pero fundamental.



grep como legado UNIX puro.


Antes de entrar en opciones y ejemplos, nos vamos a detener tan solo un minuto en lo que representa grep dentro del ecosistema UNIX.
No es solo una herramienta para buscar texto, sino una pieza clave, un importante legado respecto a una idea mucho más grande que el comando en sí... Un concepto inherente a esta orden que debería estar recordándonos permanentemente cómo programar bien.
Dentro del ecosistema UNIX, los programas bien hechos no están pensados para hacerlo todo, sino para hacer una sola cosa bien (principio KISS) y para poder combinarse entre sí. Esta combinación se logra a través de las tuberías (pipes), en las cuales la salida de un comando (o programa), se convierte en la entrada de otro.
grep encarna ese principio de forma excelente, porque no necesita saber de dónde vienen los datos ni qué se hará con ellos después. Simplemente recibe texto, filtra según un criterio y devuelve el resultado. Esta simplicidad es lo que le permite integrarse en flujos más complejos: filtrar el "ruido innecesario" en la salida de otros comandos, analizar archivos de "logs" en tiempo real, procesar listados generados por otros comandos o inspeccionar grandes volúmenes de información sin necesidad de herramientas pesadas.
En este sentido, utilizar grep es empezar a pensar con cabeza UNIXera, en donde construir soluciones a partir de piezas pequeñas encadenadas con absoluta precisión, es... mandatory!
Es una forma de trabajar en la cual la verdadera potencia no radica en un comando o programa individual, sino en la manera en que estos se conectan entre sí.


Prefacio.

grep es una de esas herramientas que aplicada de manera directa en la terminal puede parecer simple, pero que rápidamente se va volviendo indispensable cuando se empieza a trabajar con archivos de "logs" o directamente con código. En esencia, hace algo muy concreto: buscar texto. Sin embargo, la forma en la cual lo hace (tanto como también las opciones que ofrece) son determinantes al utilizarlo como filtro básico o como potente herramienta de diagnóstico.


No me importa cómo esté escrito: grep -i

Una de las primeras dificultades que podemos encontrar, es que el texto no siempre aparece exactamente como lo esperamos... o como lo recordamos.
El mismo puede estar en mayúsculas, en minúsculas, o en una combinación de ambos casos.
Por ejemplo, yo mismo, ayer, creé una función llamada "obtener_noticias_openbsd" y la estaba invocando como "obtener_noticias_OpenBSD"... Resultado: error de ejecución en el flujo esperado del programa.
Es el eterno dilema de escribir las cosas como realmente se debe, por un lado, vs lo que se recomienda en programación, por otro (sumale a eso "año vs anio", "función_principal vs funcion_principal", y así).
Acá es donde entra en juego JuanI Vellozo, quien presentó este ejemplo: el de la opción "-i". Al utilizarla, grep deja de distinguir entre mayúsculas y minúsculas (deja de lado el "case sensitive"), lo cual permite encontrar coincidencias sin la preocupación de cómo fue escrito el texto. Esta es una mejora procedimental que evita muchos "falsos negativos" cuando se están buscando palabras clave o comandos problemáticos dentro del código.

Ejemplo.

Supongamos que existe un archivo llamado "log.txt" con un contenido como este:

[001] Error al iniciar módulo: no se encuentra el archivo o directorio.
[002] OK.
[003] OK.
[004] Conexión no establecida
[005] OK.
[006] OK.
[007] ERROR: módulo de conexión faltante.
[008] Usuario no conectado.
[009] OK.
[010] OK.
[011] Saliendo con código de error 1.

Al hacer

grep -i "error" log.txt

la terminal nos devuolverá tanto "Error", como "ERROR" y "error", resolviendo el problema de las mayúsculas sin tener que "debuguear" demasiado.


Pero... ¿en dónde está el error, exactamente? grep -n

Cuando el archivo crece o se empieza a volver "inmanejable", encontrar una coincidencia ya no es suficiente: también hay que ubicarla.
Gracias a Ramiro Bergara, vimos la demostración de que la opción -n descubre este contexto que en muchas ocasiones es fundamental, mostrando el número de línea junto a cada resultado.
Esto potencia a la utilidad de búsqueda de grep, porque permite saltar directamente al lugar exacto dentro del archivo en donde está el error o lo buscado. En tareas de depuración o edición, ese número deja de ser un simple detalle, pasando a ser una guía importante.

Ejemplo.

grep -n "error" log.txt

El resultado incluirá tanto las líneas como sus números reales, algo así como:

  1:[001] Error al iniciar módulo: no se encuentra el archivo o directorio.
  7:[007] ERROR: módulo de conexión faltante.
11:[011] Saliendo con código de error 1.

Esto permite ubicar rápidamente al problema.


¿Voy a tener que hacer esto en cada uno de mis programas? grep -r

Hay un gran salto que es posible dar cuando no estamos obligados a parametrar nuestras búsquedas dentro de un solo archivo. En el caso de un programador que posee una cantidad de programas en su haber, la información, lógicamente, está distribuida en múltiples archivos y directorios. Thiago González mostró que grep puede recorrer directorios y archivos enteros de manera recursiva, buscando en todo lo que a su paso encuentra. Esto hace que la necesidad de tener que saber de antemano en dónde está lo que buscamos, sea algo totalmente irrelevante, ya que en lugar de ir abriendo todos los archivos uno por uno y aplicando herramientas de búsqueda en cada uno de ellos, se delega la totalidad de dicha tarea a este comando, el cual lo hará de manera inmediata y efectiva.

Ejemplo.

Este es un volcado real de mi directorio de scripts local, el cual busca la ocurrencia "set -e" en "$PWD", s decir "en el lugar en donde esté 'parada' la terminal en ese momento".

grep -r "set -e" $PWD

/mnt/HDD_4TB/datos_linux/01_Entropía/CodeBerg/_GeneBerg/_respaldos/geneberg.sh:set -euo pipefail
/mnt/HDD_4TB/datos_linux/01_Entropía/CodeBerg/_GeneBerg/geneberg.sh:set -euo pipefail
/mnt/HDD_4TB/datos_linux/01_Entropía/CodeBerg/KDEnTux/KDEnTux.sh:set -e # Detención script inmediatamente si algún comando falla.
/mnt/HDD_4TB/datos_linux/01_Entropía/CodeBerg/KDEnTux/KDEnTux.sh:    # Se utiliza "vainfo" para listar puntos de entrada VA-API. Si falla, KDEnTux se detendrá gracias al "set -e" del inicio.
/mnt/HDD_4TB/datos_linux/01_Entropía/CodeBerg/GeneRead/generead.sh:set -euo pipefail 
/mnt/HDD_4TB/datos_linux/01_Entropía/CodeBerg/IA_local/instalador_ia_local.sh:set -euo pipefail


Pero... yo quiero ver "todo lo otro", no "eso"... grep -v

A este atributo de grep, creo que lo charlamos entre todos, y tiene que ver con otra situación frecuente, que es la de no siempre necesitar ver lo que coincide, sino lo inverso.
Me explico mejor: a veces lo que interesa es limpiar un archivo, eliminar líneas irrelevantes o quedarse con lo que no cumple con cierta condición.
Para eso existe "-v", que invierte el criterio de búsqueda: en lugar de mostrar coincidencias, muestra todo lo demás, es decir, todo lo que NO coincide con lo que le estemos indicando.
Esto es especialmente útil al ponernos a trabajar con archivos de configuración o de registros en donde el filtrado de "ruido" es imprescindible (comentarios, líneas repetitivas, etc).

Ejemplo.

Dado un archivo de configuración con comentarios:

# Configuración del sistema
usuario=admin
# Contraseña
password_SHA-256=p989e5ap9h7t6894d4topja34l5l69xq

Podemos quitar los comentarios con:

grep -v "^#" config.conf

El resultado será solo las líneas útiles, sin las que empiezan con #:

usuario=admin
password_SHA-256=p989e5ap9h7t6894d4topja34l5l69xq


Un dato "de color": grep --color=auto

Por último, está el aspecto visual, que muchas veces se subestima. Cuando se trabaja con grandes volúmenes de texto, encontrar rápidamente coincidencias dentro de cada línea puede ser más dificultoso de lo que parece, y más cuando llevamos mirando el mismo código durante horas.
La opción --color=auto resuelve esto resaltando las coincidencias directamente en la salida. No cambia el resultado en sí, pero sí la forma en que lo percibimos, haciendo que la lectura sea más inmediata y menos propensa a errores.

Ejemplo.

Volvamos al caso del ejemplo en grep -r.
Era este: grep -r "set -e" $PWD
Pero supongamos que queremos resaltar visualmente a las ocurrencias encontradas, no solamente volcarlas en pantalla.
En ese caso, podemos simplemente intercalar la opción correspondiente en la misma línea, de esta manera:

grep --color=auto -r "set -e" $PWD

El resultado, será el mismo que el mostrado en la imagen de este artículo.

P.D.: para que no te rompas la cabeza intentándolo... Porque te estoy leyendo el pensamiento y ya sé que vas a querer hacer lo mismo que yo intenté en algún momento ("color=1", "color1", etc...), y te quiero ahorrar tiempo y enseñarte algo más...

  • "--color" no acepta colores, solo acepta "auto", "always" y "never" (el cual ya viene por omisión y no es necesario, en principio).
  • "color=auto", colorea solo si detecta que la salida va a una terminal o pantalla, pero si detecta que la salida es redirigida a un archivo, deja de resaltar con color automáticamente.
  • "color=always" se comporta de manera literal: inserta comandos de color aunque eso pueda llegar a ensuciar su salida.
Este modo se vuelve útil en casos específicos, por ejemplo cuando querés forzar colorido a través de una tubería hacia otro comando o programa que sí sepa interpretar código ANSI, el cual es, en definitiva, el código generado por grep cuando está en modo "color=always".


Epílogo.

grep posee muchas opciones, y de hecho te invito a que las investigues por tu cuenta, pero éstas, utilizadas de manera combinada (tal como nos enseña UNIX), transforman a cualquier comando (en este caso, a grep) en algo más que una simple orden o un simple buscador de texto: permiten explorar archivos, localizar problemas y filtrar información con precisión. 
Esta guía fue escrita para mis estudiantes y para los lectores que la aprovechen, pero también para mí mismo, porque al bajar a tierra escribiendo lo que uno aprendió, lo "hace carne".
Para alguien que esté empezando a utilizar este comando, la moraleja es que no es tan importante tratar de memorizar todas las posibilidades como entender que cada una de estas variantes responde a una necesidad concreta que irá apareciendo naturalmente al trabajar con datos reales en BASH.


¿Cómo ejecutar con "sudo" cuando el usuario "is not in the sudoers file".

Hoy tuve que hacer un malabar en un sistema Mageia de la UTU que yo mismo administro.
Los sistemas Linux que pasan por mí, son endurecidos a un nivel bastante paranoico, y una de las primeras cosas que hago, es quitar a los usuarios del grupo "wheel" para que no puedan hacer "sudo"; o sos root, o no sos root: nada de filosofía Linux, acá lo que corre es filosofía UNIX.
Lo que esto significa, es que si no sabés la contraseña de root y hacés sudo, no podrás seguir adelante porque el sistema, lo que te pedirá, será tu contraseña (un contrasentido total heredado del mundo de fantasía en el que está viviendo Linux desde hace muchos años) y no la de root.
Observá los 2 ejemplos en las siguientes 2 imágenes. ¿Te ha sucedido algo así?


Pues bien, hay veces en las cuales hacer "su" y registrarse como root en la terminal (aunque poseas la contraseña de root) no es suficiente, ya que la ejecución de un programa o script puede necesitar "los privilegios de sudo pero en el contexto del usuario que inició sesión en el sistema". Por ejemplo, si el usuario es "estudiante" y el script tiene que correr para "estudiante", no podés hacer "su" en la terminal y "pasarte a sudo completamente", porque el contexto del usuario "estudiante" se perdería.
Tampoco podés hacer "sudo ALGO" siendo usuario "estudiante sin wheel" porque te pasaría lo que se muestra en las imágenes de arriba.

Pues, en Linux hay solución para casi todo, y esta no es la excepción.

Podés agregar a cualquier usuario al grupo wheel, o al archivo de sudoers.
Pero esto rompería la filosofía UNIX en donde "root es root" y "user es user"

Podés "pasarte a root", como dijimos antes, pero eso rompería el contexto del usuario que realmente necesita correr el script "para él y no para root".

Entonces... parecería que no hay solución... ¿o sí?

Estarás pensando... "Páh... Soy yo el administrador; soy yo el que prohíbe hacer "sudo". En mis equipos, si no sabés la contraseña root, no podés elevar privilegios usando tu contraseña... Tiene que haber manera. Soy el "admin", sé la contraseña de root, solo debo hacer que el sistema lo entienda sin reconfigurar nada, haciendo algo al vuelo... 

Esto es posible. La "línea salvadora" es esta:

su -c "SUDO_USER=<NOMBRE_USUARIO> bash /ruta_al_script" root

Esto no solamente soluciona el problema, sino que también ejecuta al script como root, pero con SUDO_USER configurado para el usuario real, procedimiento que será utilizado por el script para saber a quién pertenece el entorno: solo tenés que sustituir <NOMBRE_USUARIO> por el nombre del usuario real.

Ejemplo con el usuario "estudiante":
su -c "SUDO_USER=estudiante bash /ruta_al_script" root

Flag Counter Visitas previas a la existencia de este contador: 3433

Artículos aleatorios

    Páginas: