- Els blobs binaris són peces propietàries carregades al nucli; faciliten compatibilitat però resten llibertat i auditoria.
- Projectes i distros dissenteixen: OpenBSD i Libreboot els rebutgen; altres accepten per suportar maquinari complex.
- El microprogramari tancat incrementa riscos; Coreboot i Libreboot ofereixen camins més oberts en equips compatibles.

Si utilitzes GNU/Linux o t'interessa el programari lliure, tard o d'hora et topes amb el terme blob binari, també anomenat blob propietari. Parlem de peces de programari en format binari que es carreguen al kernel o als seus controladors sense proporcionar el seu codi font. En altres paraules: funcionalitats empaquetades que no es poden estudiar ni modificar, i que, tot i així, moltes vegades resulten indispensables perquè cert maquinari funcioni com hauria.
La polèmica ve de lluny i toca temes espinosos: des de la llibertat de lusuari fins a la seguretat del sistema. Hi ha comunitats que els toleren com a mal menor i altres que els rebutgen de pla. Per a més confusió, al món de les bases de dades i emmagatzematge al núvol, BLOB significa una altra cosa diferent: objecte binari gran, el típic contenidor de vídeos, còpies de seguretat o imatges. En aquest article deslliurarem tots dos sentits, explicar per què existeixen els blobs binaris en Linux, qui els impulsa, quins riscos suposen, quines alternatives hi ha i com encaixa tot això en la cultura del programari lliure.
Què són els blobs binaris a Linux i per què apareixen

Quan un fabricant no facilita documentació tècnica suficient sobre el dispositiu, els desenvolupadors del nucli no poden escriure un controlador lliure complet. Per sortir del pas, el mateix proveïdor lliura un fitxer precompilat que implementa el que falta: aquest és el blob binari. Succeeix amb força freqüència en targetes gràfiques, adaptadors wifi, controladores RAID i altres components que el mercat renova amb molta rapidesa.
A l'ecosistema dels sistemes operatius tipus Unix la resposta no és homogènia. NetBSD, FreeBSD i DragonFly BSD han admès blobs de vegades com a drecera per cobrir funcionalitats. En canvi, OpenBSD i LibertyBSD presumeixen de no acceptar-ne cap dins del seu arbre de codi, amb l'objectiu de minimitzar riscos no auditables i reafirmar-ne l'aposta per la transparència total.
Al món GNU/Linux també hi ha diversitat. Hi ha distribucions que es posicionen explícitament contra els blobs, com gNewSense, Trisquel i Parabola, alineades amb la Free Software Foundation. Arran d'aquesta postura van sorgir iniciatives com Linux-lliure, un conjunt de pegats que eliminen firmware i trossos propietaris del nucli. A l'extrem pràctic, hi ha distros generalistes que, per compatibilitat, permeten controladors tancats o firmware privatiu, sobretot en equips recents.
Quan els blobs estan escrits per a altres sistemes, alguns projectes opten per embolcalls o wrappers que fan de capa de compatibilitat, permetent que un controlador pensat per a un sistema X funcioni en un altre Y. És un truc útil en certes circumstàncies, però arrossega les mateixes limitacions: opacitat, dependència del proveïdor i manteniment fora del control de la comunitat.
Riscos i desavantatges de dependre de blobs
El llistat de problemes és ben conegut per administradors i desenvolupadors. No poder llegir ni tocar el codi implica renunciar a correccions, millores i auditories independents. A partir d'aquí, s'encadenen conseqüències gens trivials.
- Impossibilitat de modificar i redistribuir versions adaptades a les teves necessitats, cosa que frena la col·laboració i la millora col·lectiva.
- Portabilitat limitada: solen compilar-se per a poques arquitectures i no es poden portar amb facilitat a altres entorns.
- Qualitat inaccessible: no es pot verificar si el controlador fa el que diu o si arrossegueu errors subtils.
- Auditoria de seguretat nul·la: tercers no poden revisar el codi a la recerca de vulnerabilitats o portes del darrere.
- Confiança cega al proveïdor, amb el temor raonable a spyware o backdoors intencionats o accidentals.
- Impossibilitat de reparar ràpidament errors o incompatibilitats des del costat de la comunitat de sistemes.
- Final de suport arbitrari: el fabricant pot abandonar el producte quan vulgui, trencant compatibilitats futures.
- Restriccions de redistribució en alguns casos. Exemple clàssic: certes càmeres iSight a iMac 5,2, el driver propietari del qual no podia redistribuir-se; l'usuari havia d'extreure'l pel seu compte des del sistema original del fabricant.
Encara que de manera habitual es distingeix entre firmware i blobs, la frontera pràctica és borrosa. El microprogramari d'inicialització és el primer programari que arrenca en engegar l'equip, inicialitza dispositius i dóna pas al sistema operatiu. Si és privatiu, hereta gairebé tots els problemes esmentats, amb l'agreujant del seu poder enorme sobre la plataforma.
Firmware, BIOS, microcodi i el camp minat de la confiança
La Free Software Foundation impulsa des de fa anys campanyes perquè firmware, BIOS i plataformes de arrencada s'obrin i puguin auditar-se. La realitat, però, és tossuda: la majoria d'equips del mercat incorporen firmware tancat ple de blobs, amb suport que sovint es talla aviat i pegats que no arriben, o arriben tard. El cost d'enginyeria inversa per desxifrar i reemplaçar aquestes peces és altíssim, i gairebé sempre s'aplica a casos molt concrets de maquinari.
L'arrencada moderna utilitza xips SPI flash on s'emmagatzema tota la ROM de plataforma. Manipular aquest firmware exigeix eines i coneixements poc comuns: ajustaments de mida, farcits, flaixos externs i fins i tot la possibilitat teòrica d'incloure un sistema bàsic en aquesta memòria. Per a usuaris corrents resulta inviable, per això la importància de projectes comunitaris que simplifiquin el procés.
Més enllà de l'arrencada, el debat sobre microcodi i subsistemes de gestió remota en algunes arquitectures ha crescut. Es critica sovint l'opacitat de tecnologies com Intel Motor de gestió i les capacitats remotes de l'ecosistema vPro. En estar embegudes a molt baix nivell, el seu abast inquieta als que prioritzen privadesa, control i seguretat verificable.
En paral·lel, hi ha qui destaca que equips amb processadors ARM de baix consum ofereixen escenaris diferents: bona autonomia, menys requisits de refrigeració i, en certs models, components auxiliars més oberts, com ara controladors embeguts per a teclat i sensors. El mapa, en qualsevol cas, és ampli i heterogeni: cal avaluar cas per cas.
Coreboot, Libreboot i el cas dels Chromebook
Google ha donat suport a Coreboot en molts Chromebook, la qual cosa, sobre el paper, apropa aquests equips a una arrencada més transparent. Tot i així, no solen complir la certificació RYF de la FSF perquè encara arrosseguen blobs en diferents capes: des del mateix firmware fins al nucli, passant per perifèrics que exigeixen microcodi propietari, com algunes targetes wifi.
La connectivitat sense fils és el maldecap més gran. Els xipsets Atheros clàssics solen funcionar amb programari lliure sense necessitat de blobs, però la resta de famílies, sobretot les molt modernes o soldades a la placa, compliquen el reemplaçament. A portàtils amb ranura miniPCIe, substituir la targeta és senzill, encara que obrir equips nous pot afectar la garantia.
L'apartat gràfic també té molla. Amb conductors lliures com Nouveau per NVIDIA, les GPU Kepler rendeixen molt bé si es força manualment el reclock per assolir les freqüències de fàbrica; en canvi, en generacions Maxwell de segona fornada i posteriors, la cosa es complica i es queda en estats de repòs amb una potència limitada. A AMD/ATI, sense carregar el firmware propietari, les gràfiques es tornen gairebé inutilitzables, malgrat que els drivers oberts han millorat moltíssim. A Intel, els xips previs a Skylake eren l'exemple més amable per a 3D sense firmware privatiu addicional.
Per tot això, en equips amb suport gràfic lliure limitat, es recomanen escriptoris lleugers com LXDE o Xfce, que no depenen dacceleració 3D. El resultat no serà espectacular en efectes, però sí estable i perfectament utilitzable pel dia a dia.
Libreboot, una aposta sense concessions
Libreboot neix com a distribució estricta de Coreboot, amb una regla clara: no es permet integrar blobs propietaris. El seu objectiu és doble: maximitzar la llibertat de l'usuari i facilitar un procés d'instal·lació i actualització que qualsevol persona pugui completar seguint documentació acurada. Es va presentar com la branca estable, més orientada a l'usuari final, amb eines i fluxos automatitzats.
La primera plataforma emblemàtica van ser les ThinkPad X60, i amb el temps el projecte ha publicat imatges ROM preparades per a diferents mides de xip SPI, utilitats com flashrom i un payload GRUB llest per arrencar sistemes GNU/Linux amb opcions avançades, com verificar signatures amb GPG o carregar nuclis allotjats a la pròpia SPI.
- Només programari lliure: res de microcodi de CPU propietari ni blobs de vídeo o inicialització tancats. Quan alguna cosa no es pot fer sense programari privatiu, simplement no se suporta.
- Abast conscient: suporta menys maquinari que Coreboot, però allò que suporta ho fa sense concessions a la llibertat de l'usuari.
- Facilitat d'ús: compilació i instal·lació automatitzades, documentació orientada a no experts i canals d'ajuda (llistes i IRC) actius.
- Tot integrat: payload GRUB, flashrom i utilitats empaquetades per evitar passos delicats a l'usuari final.
- ROMs precompilades: DESCÀRREGUES llistes per flashejar sense necessitat de compilar, amb variants per a xips de mida no estàndard quan aplica.
- Seguretat i rapidesa: temps d'arrencada reduïts, possibilitat de protegir l'arrencada i elecció lliure de versions, sense cadenats ni DRM de fabricant.
- Hackejable i personalitzable: fons, tipografies, payloads i opcions, tot canvia a voluntat del propietari de l'equip.
- Actualitzable a voluntat: pujar o baixar de versió queda a les mans de l'usuari; si s'activa la protecció d'escriptura del xip, les actualitzacions posteriors requeriran un programador extern.
- Resposta àgil davant de fallades: quan hi ha un problema, la comunitat reacciona ràpid; contrast amb proveïdors propietaris que pegats tard, poques vegades i només en certes versions d'un únic sistema.
Aquest enfocament deixa fora plataformes modernes molt populars, és clar. Però evita l'obsolescència programada derivada de cicles de suport capritxosos i permet que equips veterans segueixin sent útils i segurs amb una arrencada lliure i documentada.
Què és un BLOB a bases de dades i emmagatzematge d'objectes
Al món de les TIC, BLOB significa Binary Large Object. Són dades grans guardades en binari, típicament multimèdia, imatges de disc o còpies de seguretat, que viuen en bases de dades o en emmagatzematge dobjectes. A diferència del bloc propietari del nucli, aquí no parlem de controladors ni firmware, sinó de contenidors d'informació.
Els fitxers purament de text de vegades es tracten com a CLOB, Character Large Object. La diferència és que el CLOB es maneja com a text i no com a binari, una cosa útil per a certs motors i operacions. A la pràctica, ambdós conceptes conviuen en bases de dades i plataformes cloud.
- Publicació de contingut multimèdia: imatges, vídeo i àudio servits a llocs web, aplicacions i serveis de transmissió.
- Data lakes i analítica: llacs de dades per a big data, entrenament de models d'aprenentatge automàtic i intel·ligència de negoci.
- Arxivat de logs: conservació de registres d'aplicacions i seguretat per a diagnòstic, auditoria i compliment.
- Gestió documental: PDFs, escanejats i historials corporatius a gran escala.
- Allotjament estàtic: servir HTML, CSS, JavaScript i imatges directament des d'emmagatzematge d'objectes.
- Distribució de programari: paquets, actualitzacions i instal·ladors amb alta disponibilitat.
- Dades sanitàries: imatges mèdiques, historials i genòmica amb garanties de seguretat i normativa.
- Investigació científica: datasets procedents d'experiments, simulacions i xarxes de sensors per a anàlisi i col·laboració.
Per evitar confusions, de vegades es parla de Binary BLOB davant de Basic Large Object. El més substancial és que parlem de contenidors de dades, peces opaques incrustades en el nucli del sistema. Són mons relacionats pel format binari, però amb implicacions i riscos totalment diferents.
La discussió sobre els blobs binaris a Linux no va només de maquinari que funcioni o deixi de funcionar: tracta de confiança, control i sostenibilitat a llarg termini. Hi ha espais on el compromís és inevitable i altres on apostar per camins lliures com Linux-lliure, Coreboot o Libreboot compensa de sobres. Coneixent els riscos i les alternatives, cadascú pot decidir fins on vol cedir, i en quines condicions, el timó del propi sistema.
Redactor apassionat del món dels bytes i la tecnologia en general. M'encanta compartir els meus coneixements a través de l'escriptura, i això és el que faré en aquest bloc, mostrar tot el més interessant sobre gadgets, programari, maquinari, tendències tecnològiques, i més. El meu objectiu és ajudar-te a navegar pel món digital de forma senzilla i entretinguda.
