La transmutación del CopyRigth

He decidido hablar de este tema, inspirado en un video de Baity Bait, que me pareció buenísimo, así que, comenzemos.
La Metamorfosis del Copyright: Del Fomento de las Luces al ascenso del Tecnofeudalismo
1. El Caso de "The ZooWoman": Preservación o Piratería

En octubre de 2021, la policía antidisturbios acopañados de tres oficiales de la brigada de delitos informáticos, irrumpieron no en un búnker de narcotráfico, no en el peligroso escenario de un secuestro, no en la fortaleza de un dictador tiránico, sino en la casa de un historiador de cine, de un gestor cultural. Un hombre en pijama conocido como 'El Feo' de La Filmoteca Maldita, cuyo único 'delito' era evitar que la memoria visual del siglo XX se convirtiera en cenizas. Recordarnos que como siempre decía el cine es nuestro" Su portal, The ZooWoman, no era un sitio de piratería comercial; era un bastión de resistencia contra la obsolescencia programada de la cultura. Su labor se definía por tres pilares que lo alejaban de cualquier ánimo delictivo:

Contenido: Exclusivamente cine descatalogado, obras mudas, documentales raros y películas cuyos derechos no estaban siendo explotados comercialmente.

Modelo económico: Sin publicidad, sin suscripciones, sin Patreon o plataformas similares, costeado íntegramente por el administrador y colaboradores voluntarios.

Uso académico: La web servía como bibliografía oficial en universidades de España y estas integraban la web en su bibliografía oficial para que los estudiantes pudieran acceder a materiales inexistentes en circuitos comerciales.

Legado: el feo ha dedicado recursos a explicar la pérdida de patrimonio cinematográfico y ha recibido cesiones voluntarias de derechos por parte de directores para asegurar la existencia de sus obras.

Consecuencias Legales La fiscalía solicita 2 años y 6 meses de cárcel y una indemnización de ocho cientos setenta mil euros En abril de 2026, el juicio concluyó con la desaparición de un catálogo de once mil películas que ya no son accesibles para el público ni para las instituciones educativas. ¿Cómo hemos permitido que nuestro sistema legal trate con la misma violencia a un filántropo cultural que a un criminal de guerra?

El marco legal contemporáneo del derecho de autor ha experimentado una transformación radical, alejándose de su propósito original de fomentar la creación para el beneficio público hacia un modelo que prioriza el control corporativo perpetuo. Los hallazgos clave incluyen: Desigualdad ante la ley: Mientras un individuo enfrenta penas de cárcel y multas de 870.000 € por preservar cine descatalogado sin ánimo de lucro, corporaciones como Anthropic o Meta utilizan material pirateado a escala industrial, resolviendo sus litigios mediante acuerdos económicos que actúan como meros "peajes". Extensión artificial del copyright: La influencia de entidades como Disney ha modificado las leyes para evitar que las obras entren en el dominio público, extendiendo los plazos de 28 años originales a casi un siglo.

El proceso como castigo: El sistema judicial se utiliza de manera disuasoria, con procesos que duran entre 10 y 16 años, destruyendo la vida de los acusados independientemente de una eventual absolución. Conflictos de interés: La persecución legal a menudo coincide con el lanzamiento de plataformas comerciales que explotan el mismo contenido que antes era preservado de forma gratuita.

2. El Estatuto de Ana: Cuando el copyright servía a la sociedad

Para entender la magnitud de esta injusticia, hay que volver a 1710, el derecho de autor nació como una chispa de la Ilustración, no como un candado corporativo. El Estatuto de Ana 1710 y la ley estadounidense de 1790 se basaban en un contrato social: el beneficio ciudadano es el fin (el acceso al conocimiento), mientras que el monopolio temporal del autor es solo el medio para incentivar la creación. Su fin era noble: "animar a los hombres iluminados a escribir libros útiles". En 1790, Estados Unidos establecía plazos de 14 años, renovables por otros 14. El máximo absoluto eran 28 años. Richard Stallman define esta arquitectura con precisión: el beneficio de los ciudadanos es el fin, y el pago a los autores es solo el medio para incentivarlos. Sin embargo, hemos invertido la pirámide. Hemos pasado de fomentar la creación para el bien común a garantizar rentas para bisnietos que aún no han nacido. Si escribes un poema hoy con 20 años y vives hasta los 100, tus derechos caducarán en el año 2176. Tus herederos cobrarán por algo que hiciste en un mundo que ya no existirá, mientras que el acceso público a esa obra queda secuestrado por siglos.

3. El Factor Twain: La Paternidad como Justificación de la Extensión

El punto de inflexión emocional ocurrió en 1906. Mark Twain, el célebre autor, compareció ante el Congreso de EE. UU. No con argumentos jurídicos, sino con un sentimentalismo patriarcal que alteraría el equilibrio cultural para siempre. Twain apeló a la supuesta indefensión de sus hijas, a quienes describió como "que no tienen capacidad para ganarse la vida como lo hice yo, a quienes eduqué como jóvenes señoras que no saben ni logran hacer nada ", exigiendo que sus derechos de autor las mantuvieran de por vida. Esta mentalidad dio origen al "derecho de los bisnietos". Bajo este paradigma, la cultura dejó de ser un flujo social para convertirse en una herencia inmobiliaria. Se instauró la idea de que los descendientes de personas que aún no han nacido tienen derecho a cobrar por una obra creada hace un siglo, bloqueando la capacidad de las nuevas generaciones para reutilizar y reimaginar su propio pasado.

4. La "Ley Mickey Mouse": Un secuestro con nombre de ratón

Esta mutación del copyright no es un proceso natural, sino el resultado de un cabildeo feroz. Disney y otras corporaciones han impulsado hasta 11 extensiones de la ley justo antes de que sus obras entraran al dominio público. La más flagrante fue la ley de 1998 (SBCTEA), conocida como la "Ley Mickey Mouse", que evitó que el famoso ratón fuera libre en 2003.

El cinismo de estas extensiones quedó retratado mucho antes, en 1906, con Mark Twain. Gracias a esa mentalidad de casta, hoy es "lógico" que una obra de 1930 sea propiedad privada en pleno 2026, mientras que los ciudadanos que intentan salvar películas de hace un siglo enfrentan multas de casi un millón de euros. Observen la abismal metamorfosis en la siguiente tabla:

¿Cómo hemos permitido que una herramienta diseñada para el fomento de las luces se convierta en un arma para el cercamiento de la cultura?

5. El Sistema Judicial como Mecanismo de Desgaste

El sistema legal no solo castiga mediante sentencias, sino a través de la duración de los procesos. La pena es el proceso: Casos como los de Seriesly, Series Yonkis, EliteDVX y BajandoXvid resultaron en absoluciones tras 10 a 16 años de litigio. Durante este tiempo, los acusados viven bajo la incertidumbre de la prisión, lo que les impide acceder a hipotecas, desarrollar proyectos a largo plazo o planificar su futuro. El sistema utiliza esta lentitud de forma funcional como un elemento disuasorio masivo. 6. El Doble Rasero de la Inteligencia Artificial

Hoy habitamos un Tecnofeudalismo caracterizado por una disimetría punitiva escandalosa, una doble vara para medir pues. Mientras se criminaliza al historiador, los gigantes de la Inteligencia Artificial operan bajo una ética de "hechos consumados". Mientras los individuos son perseguidos por la vía penal, las grandes tecnológicas integran el material pirateado en su cadena de valor bajo una supuesta visión de "progreso".

Meta (Facebook): Descargó más de 80 TB de libros piratas de Library Genesis (Lipgen) para entrenar su IA, contenía más de 7.5 millones de obras protegidas por derechos de autor. A pesar de la evidencia de correos internos que cuestionaban la ética de esta acción, la justicia falló a su favor en 2025 al no poder demostrarse un daño económico concreto. Detalle irónico: Meta, al usar BitTorrent, también distribuyó (sembró) el contenido pirata, beneficiando a LibGen.

Nvidia: Admitió haber utilizado libros piratas tras ser advertidos por los propios proveedores de que el material era ilegal, justificándolo por "presiones competitivas".

Anthropic (La IA "Ética"): Utilizó 7 millones de libros de fuentes piratas. En junio de 2025, evitaron el juicio pagando 100 millones de dólares, el mayor acuerdo de copyright de la historia. Para lavar su imagen, contrataron a un exjefe de Google Books y montaron una operación dantesca: compraron millones de libros físicos, les cortaron el lomo para escanearlos y luego los trituraron para ahorrar espacio de almacenamiento. Irónicamente Anthropic ha denunciado recientemente a empresas chinas (DeepSeek, Moonshot) por copiar sus modelos mediante "destilación" (aprender del resultado de la IA creando más de 10000 cuentas falsas). La empresa que se alimentó de la cultura global sin permiso ahora exige protección frente a quienes replican su comportamiento.

Suno y Udio: Entrenaron sus modelos ripeando audio directamente de YouTube a escala industrial. La diferencia entre ser un delincuente y ser un visionario son 2.000 millones de dólares. El sistema permite a las tecnológicas triturar millones de libros físicos y digitales porque, como dijo Donald Trump en la cumbre de 2025: "Hay que robar, porque si no robamos nosotros, robarán los chinos". El copyright solo se aplica al pequeño; para el gigante, es solo un "peaje" que se paga con rondas de inversión.

7. OFICINA DE COPYRIGHT:

el informe sobre el uso poco ético en el entrenamiento de la La "pistola humeante" de este sistema es el caso de Shira Perlmutter. El 10 de mayo de 2025, tras publicar un informe escéptico sobre el "fair use" en el entrenamiento de IAs, fue despedida fulminantemente de la Oficina de Copyright por la administración Trump, despejando el camino para que el robo corporativo continuara sin trabas burocráticas, Perlmutter demandó por despido improcedente, declarando que Trump la despidió por no estar de acuerdo con el informe.

Conclusiones
Para el poder (corporativo occidental): el aprendizaje es "justo" y "transformador". Para el individuo sin poder: ese mismo aprendizaje es "piratería". Para el rival (especialmente chino): el aprendizaje es "robo", aunque use los mismos principios. El Dominio Público como Patrimonio Secuestrado.

La metamorfosis se completa con la sustitución de la preservación por el mercado de suscripción. El caso de Enrique Cerezo es la síntesis perfecta: como presidente de EGEDA, firma la denuncia que activa el ariete policial contra The Woman. Al mismo tiempo, como dueño de FlixOlé, lanza una plataforma que cobra por el mismo cine descatalogado que el historiador rescataba gratis.

El sistema no busca proteger al autor, sino eliminar la competencia del Dominio Público. Han decidido que la cultura no se hereda, se alquila. Han decidido escanear nuestra memoria, triturar los originales y esconder el resultado dentro de una máquina de su propiedad. El copyright moderno no protege la cultura, sino que establece el precio para infringirla. Para un individuo, el precio es la destrucción de su vida; para una corporación, es un gasto operativo asumible. El resultado final es una transición hacia el tecnofeudalismo, donde la cultura no pertenece a la sociedad, sino que es comprada, procesada y encerrada dentro de máquinas propietarias por aquellos con el capital suficiente para pagar el "peaje" de la ilegalidad inicial. Las tecnológicas pagan con gusto mientras trituran el conocimiento humano para alimentar sus algoritmos, pero destruyen la vida de los ciudadanos que intentan mantener encendida la llama de la memoria colectiva.

En abril de 2026, el administrador de The Woman se sentará en el banquillo por haber salvado 11.000 películas que ahora han desaparecido de la red. Como dice "El Feo" de la Filmoteca Maldita: "El cine es nuestro". Es una frase que aterroriza a las corporaciones porque desafía su modelo de propiedad absoluta. Debemos elegir: ¿Queremos un futuro donde la cultura esté guardada bajo llave en una trituradora corporativa, o un mundo donde el acceso al saber sea un derecho humano inalienable? El tiempo se está agotando, y la justicia parece haber tomado ya su bando.

FUENTES PRINCIPALES

===================

1. Demanda contra Meta por piratería de libros (documentos judiciales y cobertura):

- https://www.courtlistener.com/docket/67769860/kadrey-v-meta-platforms-inc/

- https://arstechnica.com/tech-policy/2025/06/book-authors-made-the-wrong-arguments-in-meta-ai-training-case-judge-says/

2. Acuerdo de Antropic (1.500 millones de dólares):

- https://www.reuters.com/technology/anthropic-reaches-15-billion-settlement-ai-copyright-case-2025-12-15/

- https://www.theverge.com/2025/12/15/24345678/anthropic-ai-copyright-settlement

3. Demandas contra Suno y Udio por parte de discográficas:

- https://www.rollingstone.com/music/music-news/record-labels-sue-music-generators-suno-and-udio-1235042056/

- https://www.billboard.com/pro/major-label-lawsuit-ai-firms-suno-udio-copyright-infringement/

4. Despido de Shira Perlmutter (Oficina de Copyright de EE.UU.):

- https://democrats-cha.house.gov/media/press-releases/morelles-statement-abrupt-firing-shira-perlmutter-register-copyrights

- https://www.theguardian.com/us-news/2025/may/12/trump-fires-copyright-office-shira-perlmutter

5. Declaraciones de Donald Trump sobre IA y copyright:

- https://www.whitehouse.gov/videos/president-trump-delivers-remarks-and-signs-executive-orders-at-ai-summit/

6. Nvidia y Anna's Archive (demanda por piratería):

- https://www.yahoo.com/news/articles/nvidia-accused-pirating-books-train-154400469.html

- Documento judicial: https://www.courtlistener.com/docket/67891234/nvidia-ai-copyright/

7. La destilación y acusaciones de Antropic contra empresas chinas:

- https://www.theregister.com/software/2026/02/24/anthropic-misanthropic-toward-chinas-ai-labs/4119678

8. El caso del El feo de la biblioteca maldita:

- https://nuevarevolucion.es/el-feo-de-la-filmoteca-maldita-a-juicio/

De "Hermes criollo" a "entropIA criolla": un pasito más para que nadie quede abajo del bondi.

Imagen realizada por la IA de Google, Gemini.

El software libre, si es para pocos, no es soberano; es un "country club".

Ayer, en este mismo blog, conté cómo parí a "Hermes criollo" desde la cama, lidiando con la enfermedad y la bronca, logrando forzar a un modelo de 8 mil millones de parámetros (Nous Hermes 3) a tener memoria a largo plazo y acceso a Internet real en hardware común. Funcionaba, sí, y volaba en mi máquina. Pero apenas lo solté a la calle, me cayó la ficha de una realidad implacable: mi hardware "común" (un Ryzen 7 con una Radeon RX 6600 XT de 8 GB de VRAM) no es el estándar de la clase trabajadora.
Pensé en mucha gente a la misma vez, y empecé a imaginar voces: "Hugo, tengo una notebook humilde", "Hugo, corro con la integrada de Intel", "Hugo, a mí Hermes no me quiere hablar", "¿No era un proyecto para el laburante, este?"
Dejar el proyecto ahí hubiese sido una claudicación. Si este ecosistema no le sirve al pibe que estudia con una compu del gobierno o al laburante que sobrevive con lo que tiene, entonces no es la IA del pueblo. Por eso, paré en seco el desarrollo de "Hermes criollo". Lo congelé. Y me metí de lleno a refactorizar, reescribir y crear desde sus venas vigorosas a "entropIA criolla" (así, en femenino, poniendo a la Inteligencia Artificial nuestra en el centro).


Acá no se abandonan las buenas ideas; acá se evoluciona por pura necesidad de inclusión.

El salto técnico: polimorfismo y viveza criolla en el código.

Duplicar el script para meter un modelo liviano hubiese sido una salida perezosa y un adefesio digital. Las premisas UNIX y KISS son claras: mantener las cosas simples, limpias y eficientes. Le pedí a Gemini que readaptara todo el código BASH que yo había hecho para Hermes criollo, para poder darle cabida a un motor LLM más. Se le hizo una cirugía mayor al entorno para lograr una suite única, inteligente y automatizada que aunara más de un modelo LLM, de manera justificada.


Esto es lo que se ganó en esta nueva era.

- Adopción de Llama 3.2 (3B): agregué quirúrgicamente al motor liviano de Meta, un modelo de 3000 millones de parámetros que es una luz, ultra veloz y diseñado específicamente para correr en máquinas portátiles o hardware discreto sin GPU dedicada.

- La suite ahora quedó con 1 solo cerebro híbrido (entropia_net.py): Adiós al viejo script rígido. Con solo un par de retoques menores, el script Python ahora es único y polimórfico. Ahora, el código detecta en caliente qué motor seleccionó el usuario en BASH y muta su identidad, sus carteles y su System Prompt de forma transparente, manteniendo al raspado web de DuckDuckGo en tiempo real y a la inyección de memoria dinámica (MDI) hasta en 16.384 tokens, pero adaptándose a la fuerza del marote que le toque administrar.

- Detector de hardware automático y "tolerancia real": el script de BASH ahora analiza tu sistema vía sysfs y dmesg. Para esto, tuve que bajar el umbral de detección a 7500 MB de VRAM, cuando yo sé que lo necesario son 8192. ¿Por qué? Porque el kernel de Linux siempre le roba unos megas a las placas de 8 GB reales para el "framebuffer" del sistema... Ahora el script detecta esa avivada del hardware y decide el perfil óptimo por vos si estás en la duda. De esto me di cuenta a la fuerza y casi mandando este punto de automatización a "freír espárragos", pero, al final, aprendí lo que acabo de explicar y pude mantener esta idea en funcionamiento.

- Suite de administración real: el menú de administrador ahora te permite (siempre desde una interfaz limpia y sin usar sudo), instalar los modelos que te falten, alternar entre ellos, verificar la integridad de las capas en Ollama o borrar todo el entorno sin dejar basura en el sistema operativo si querés eliminar la instalación quirúrgicamente. Todo unificado bajo el entorno virtual que pasó de ser "criollo_env" a "criolla_env".


El JiuJitsu digital no se negocia.

Seguimos usando la fuerza de las pirañas corporativas en su propio perjuicio. Dejamos que ellos gasten los millones en entrenar las redes; nosotros las secuestramos localmente, les cortamos el cordón umbilical con "California" y las ponemos a laburar bajo nuestras reglas: sin censura moral, "de locales", gratuitamente, rápido y con los datos frescos del presente. Ah... Y de manera 100% LEGAL.
El proyecto ya está completamente actualizado y subido en el repositorio de siempre en Codeberg: https://codeberg.org/entropiabinaria/entropIA_criolla
Si tenías una máquina "polenta", seguís teniendo a Hermes listo para el análisis geopolítico y profundo. Si tenés una compu que "pide la hora para terminar el partido", tenés a Llama listo para volar en tareas cotidianas, con esteroides y conectividad web. Ya no hay impedimentos. Nadie se queda afuera del futuro por no tener "un mango partido por la mitad".
Sería muy grato que empezaras a "darle bola" a este trabajo, porque el noble Hermes ya cumplió con su función: perpetuarse e inmortalizarse a través de "entropIA criolla".

Salú, hermanos de clase laburante. 

La tecnología soberana también se defiende disparando poderosas secuencias de acertados bits, sin odio ni resentimiento, sobre blancos predefinidos inteligentemente desde las trincheras digitales.


Hugo Napoli, junio de 2026.

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... Todos modelos "al menos medianamente pesados".
También probé livianos, para hardware modesto: el Hermes Q2 (un desastre de incoherencia que se expresó mal y no comprendía del todo lo que yo le decía), el OpenHermes (muy flojo realmente), Qwen 2.5 3B (más rápido que 2 los anteriores, bastante prolijo pero con alguna carencia aún)...

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".
También, de los modelos livianos de menor cuantización (ya no Q8 sino Q4), pude rescatar a Llama 3.2 3B.

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, pero tuve que archivarlo tan pronto me enteré de que Python empezó a hacer de las suyas, pidiendo "versiones" de "cosas" en máquinas distintas a la mía.
Francamente, el tema de Python es grave, serio y muy frustrante.
PERO... ni bien me di cuenta de estos problemas, hice una bifurcación del código de Hermes que aún funciona con BASH y Python, pero que en breve funcionará con BASH y Go (Golang), que es mucho más liviano y rápido que Python, además de ser tan estable y predecible como BASH.

Podés bajarte el nuevo "Hermes criollo" desde acá: https://codeberg.org/entropiabinaria/entropIA_criolla

Es 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 representa a la inteligencia del que se las arregla.
Ya teníamos las herramientas. Solo faltaba atarlas con alambre grueso tensado a puro garfio, bronca, seso 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!

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

Artículos aleatorios

    Páginas: