- Los blobs binarios son piezas propietarias cargadas en el kernel; facilitan compatibilidad pero restan libertad y auditoría.
- Proyectos y distros disienten: OpenBSD y Libreboot los rechazan; otras aceptan para soportar hardware complejo.
- El firmware cerrado incrementa riesgos; Coreboot y Libreboot ofrecen caminos más abiertos en equipos compatibles.
Si usas GNU/Linux o te interesa el software libre, tarde o temprano te topas con el término blob binario, también llamado blob propietario. Hablamos de piezas de software en formato binario que se cargan en el kernel o en sus controladores sin proporcionar su código fuente. En otras palabras: funcionalidades empaquetadas que no se pueden estudiar ni modificar, y que, aun así, muchas veces resultan indispensables para que cierto hardware funcione como debería.
La polémica viene de lejos y toca temas espinosos: desde la libertad del usuario hasta la seguridad del sistema. Hay comunidades que los toleran como mal menor y otras que los rechazan de plano. Para más confusión, en el mundo de las bases de datos y el almacenamiento en la nube, BLOB significa otra cosa distinta: objeto binario grande, el típico contenedor de vídeos, copias de seguridad o imágenes. En este artículo vamos a desliar ambos sentidos, explicar por qué existen los blobs binarios en Linux, quién los impulsa, qué riesgos suponen, qué alternativas hay y cómo encaja todo esto en la cultura del software libre.
Qué son los blobs binarios en Linux y por qué aparecen
Cuando un fabricante no facilita documentación técnica suficiente sobre su dispositivo, los desarrolladores del kernel no pueden escribir un controlador libre completo. Para salir del paso, el propio proveedor entrega un archivo precompilado que implementa lo que falta: ese es el blob binario. Sucede con bastante frecuencia en tarjetas gráficas, adaptadores wifi, controladoras RAID y otros componentes que el mercado renueva con mucha rapidez.
En el ecosistema de los sistemas operativos tipo Unix la respuesta no es homogénea. NetBSD, FreeBSD y DragonFly BSD han admitido blobs en ocasiones como atajo para cubrir funcionalidades. En cambio, OpenBSD y LibertyBSD presumen de no aceptar ninguno dentro de su árbol de código, con el objetivo de minimizar riesgos no auditables y reafirmar su apuesta por la transparencia total.
En el mundo GNU/Linux también hay diversidad. Existen distribuciones que se posicionan explícitamente contra los blobs, como gNewSense, Trisquel y Parabola, alineadas con la Free Software Foundation. A raíz de esta postura surgieron iniciativas como Linux-libre, un conjunto de parches que eliminan firmware y trozos propietarios del núcleo. En el extremo práctico, hay distros generalistas que, por compatibilidad, permiten controladores cerrados o firmware privativo, sobre todo en equipos recientes.
Cuando los blobs están escritos para otros sistemas, algunos proyectos optan por envoltorios o wrappers que hacen de capa de compatibilidad, permitiendo que un controlador pensado para un sistema X funcione en otro Y. Es un truco útil en ciertas circunstancias, pero arrastra las mismas limitaciones: opacidad, dependencia del proveedor y mantenimiento fuera del control de la comunidad.
Riesgos y desventajas de depender de blobs
El listado de problemas es bien conocido por administradores y desarrolladores. No poder leer ni tocar el código implica renunciar a correcciones, mejoras y auditorías independientes. A partir de ahí, se encadenan consecuencias nada triviales.
- Imposibilidad de modificar y redistribuir versiones adaptadas a tus necesidades, lo que frena la colaboración y la mejora colectiva.
- Portabilidad limitada: suelen compilarse para pocas arquitecturas y no se pueden llevar con facilidad a otros entornos.
- Calidad inaccesible: no es posible verificar si el controlador hace lo que dice o si arrastra errores sutiles.
- Auditoría de seguridad nula: terceros no pueden revisar el código en busca de vulnerabilidades o puertas traseras.
- Confianza ciega en el proveedor, con el temor razonable a spyware o backdoors intencionados o accidentales.
- Imposibilidad de reparar rápidamente fallos o incompatibilidades desde el lado de la comunidad de sistemas.
- Fin de soporte arbitrario: el fabricante puede abandonar el producto cuando quiera, rompiendo compatibilidades futuras.
- Restricciones de redistribución en algunos casos. Ejemplo clásico: ciertas cámaras iSight en iMac 5,2, cuyo driver propietario no podía redistribuirse; el usuario debía extraerlo por su cuenta desde el sistema original del fabricante.
Aunque de forma habitual se distingue entre firmware y blobs, la frontera práctica es borrosa. El firmware de inicialización es el primer software que arranca al encender el equipo, inicializa dispositivos y da paso al sistema operativo. Si es privativo, hereda casi todos los problemas mencionados, con el agravante de su enorme poder sobre la plataforma.
Firmware, BIOS, microcódigo y el campo minado de la confianza
La Free Software Foundation impulsa desde hace años campañas para que firmware, BIOS y plataformas de arranque se abran y puedan auditarse. La realidad, sin embargo, es tozuda: la mayoría de equipos del mercado incorporan firmware cerrado repleto de blobs, con soporte que a menudo se corta pronto y parches que no llegan, o llegan tarde. El coste de ingeniería inversa para descifrar y reemplazar estas piezas es altísimo, y casi siempre aplica a casos muy concretos de hardware.
El arranque moderno usa chips SPI flash donde se almacena toda la ROM de plataforma. Manipular este firmware exige herramientas y conocimientos poco comunes: ajustes de tamaño, rellenos, flasheos externos e incluso la posibilidad teórica de incluir un sistema básico en esa memoria. Para usuarios corrientes resulta inviable, de ahí la importancia de proyectos comunitarios que simplifiquen el proceso.
Más allá del arranque, el debate sobre microcódigo y subsistemas de gestión remota en algunas arquitecturas ha crecido. Se critica con frecuencia la opacidad de tecnologías como Intel Management Engine y las capacidades remotas del ecosistema vPro. Al estar embebidas a muy bajo nivel, su alcance inquieta a quienes priorizan privacidad, control y seguridad verificable.
En paralelo, hay quien destaca que equipos con procesadores ARM de bajo consumo ofrecen escenarios diferentes: buena autonomía, menos requisitos de refrigeración y, en ciertos modelos, componentes auxiliares más abiertos, como controladores embebidos para teclado y sensores. El mapa, en cualquier caso, es amplio y heterogéneo: conviene evaluar caso por caso.
Coreboot, Libreboot y el caso de los Chromebook
Google ha apoyado Coreboot en muchos Chromebook, lo cual, sobre el papel, acerca a estos equipos a un arranque más transparente. Aun así, no suelen cumplir la certificación RYF de la FSF porque todavía arrastran blobs en distintas capas: desde el propio firmware hasta el kernel, pasando por periféricos que exigen microcódigo propietario, como algunas tarjetas wifi.
La conectividad inalámbrica es el mayor quebradero de cabeza. Los chipsets Atheros clásicos suelen funcionar con software libre sin necesidad de blobs, pero el resto de familias, sobre todo las muy modernas o soldadas a la placa, complican el reemplazo. En portátiles con ranura miniPCIe, sustituir la tarjeta es sencillo, aunque abrir equipos nuevos puede afectar a la garantía.
El apartado gráfico también tiene miga. Con drivers libres como Nouveau para NVIDIA, las GPU Kepler rinden muy bien si se fuerza manualmente el reclock para alcanzar las frecuencias de fábrica; en cambio, en generaciones Maxwell de segunda hornada y posteriores, la cosa se complica y se queda en estados de reposo con potencia limitada. En AMD/ATI, sin cargar el firmware propietario, las gráficas se vuelven casi inutilizables, pese a que los drivers abiertos han mejorado muchísimo. En Intel, los chips previos a Skylake eran el ejemplo más amable para 3D sin firmware privativo adicional.
Por todo ello, en equipos con soporte gráfico libre limitado, se recomiendan escritorios ligeros como LXDE o Xfce, que no dependen de aceleración 3D. El resultado no será espectacular en efectos, pero sí estable y perfectamente utilizable para el día a día.
Libreboot, una apuesta sin concesiones
Libreboot nace como distribución estricta de Coreboot, con una regla clara: no se permite integrar blobs propietarios. Su meta es doble: maximizar la libertad del usuario y facilitar un proceso de instalación y actualización que cualquier persona pueda completar siguiendo documentación cuidada. Se presentó como la rama estable, más orientada al usuario final, con herramientas y flujos automatizados.
La primera plataforma emblemática fueron las ThinkPad X60, y con el tiempo el proyecto ha publicado imágenes ROM preparadas para distintos tamaños de chip SPI, utilidades como flashrom y un payload GRUB listo para arrancar sistemas GNU/Linux con opciones avanzadas, como verificar firmas con GPG o cargar núcleos alojados en la propia SPI.
- Solo software libre: nada de microcódigo de CPU propietario ni blobs de vídeo o inicialización cerrados. Cuando algo no puede hacerse sin software privativo, simplemente no se soporta.
- Alcance consciente: soporta menos hardware que Coreboot, pero lo que soporta lo hace sin concesiones a la libertad del usuario.
- Facilidad de uso: compilación e instalación automatizadas, documentación orientada a no expertos y canales de ayuda (listas e IRC) activos.
- Todo integrado: payload GRUB, flashrom y utilidades empaquetadas para evitar pasos delicados al usuario final.
- ROMs precompiladas: descargas listas para flashear sin necesidad de compilar, con variantes para chips de tamaño no estándar cuando aplica.
- Seguridad y rapidez: tiempos de arranque reducidos, posibilidad de proteger el arranque y elección libre de versiones, sin candados ni DRM de fabricante.
- Hackeable y personalizable: fondos, tipografías, payloads y opciones, todo cambia a voluntad del propietario del equipo.
- Actualizable a voluntad: subir o bajar de versión queda en manos del usuario; si se activa la protección de escritura del chip, las actualizaciones posteriores requerirán programador externo.
- Respuesta ágil ante fallos: cuando hay un problema, la comunidad reacciona rápido; contraste con proveedores propietarios que parchean tarde, rara vez y solo en ciertas versiones de un único sistema.
Este enfoque deja fuera plataformas modernas muy populares, claro. Pero evita la obsolescencia programada derivada de ciclos de soporte caprichosos y permite que equipos veteranos sigan siendo útiles y seguros con un arranque libre y documentado.
Qué es un BLOB en bases de datos y almacenamiento de objetos
En el mundo de las TIC, BLOB significa Binary Large Object. Son datos grandes guardados en binario, típicamente multimedia, imágenes de disco o copias de seguridad, que viven en bases de datos o en almacenamiento de objetos. A diferencia del blob propietario del kernel, aquí no hablamos de controladores ni firmware, sino de contenedores de información.
Los archivos puramente de texto a veces se tratan como CLOB, Character Large Object. La diferencia es que el CLOB se maneja como texto y no como binario, algo útil para ciertos motores y operaciones. En la práctica, ambos conceptos conviven en bases de datos y plataformas cloud.
- Publicación de contenido multimedia: imágenes, vídeo y audio servidos a sitios web, apps y servicios de streaming.
- Data lakes y analítica: lagos de datos para big data, entrenamiento de modelos de aprendizaje automático e inteligencia de negocio.
- Archivado de logs: conservación de registros de aplicaciones y seguridad para diagnóstico, auditoría y cumplimiento.
- Gestión documental: PDFs, escaneos e historiales corporativos a gran escala.
- Alojamiento estático: servir HTML, CSS, JavaScript e imágenes directamente desde almacenamiento de objetos.
- Distribución de software: paquetes, actualizaciones e instaladores con alta disponibilidad.
- Datos sanitarios: imágenes médicas, historiales y genómica con garantías de seguridad y normativa.
- Investigación científica: datasets procedentes de experimentos, simulaciones y redes de sensores para análisis y colaboración.
Para evitar confusiones, a veces se habla de Binary BLOB frente a Basic Large Object. Lo sustancial es que hablamos de contenedores de datos, no de piezas opacas incrustadas en el núcleo del sistema. Son mundos relacionados por el formato binario, pero con implicaciones y riesgos totalmente distintos.
La discusión sobre los blobs binarios en Linux no va solo de hardware que funcione o deje de funcionar: trata de confianza, control y sostenibilidad a largo plazo. Hay espacios donde el compromiso es inevitable y otros en los que apostar por caminos libres como Linux-libre, Coreboot o Libreboot compensa de sobra. Conociendo los riesgos y las alternativas, cada cual puede decidir hasta dónde quiere ceder, y en qué condiciones, el timón de su propio sistema.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.