- Scritto da: collione
> farò una prova con quello script
>
> avendo archlinux, penso che i blob binari siano
> decisamente meno e comunque limitati ai
> firmware
>

Io l'ho fatto su una gentoo col kernel vanilla

> voglio capire anche come fa a distinguere un blob
> binario da un pezzo
> opensource
>

Penso dalla informazione della licenza che DEVE essere inserita se si vuole che sia poi messo nel kernel ufficiale

> citavo ad esempio broadcom, che l'anno scorso ha
> deciso di passare ai driver
> open
>
> non è che deblob conta ancora i driver broadcom
> come
> closed?
>

Dipende dalla loro licenza: Ad esempio il meccanismo che carica le patch microcodice delle CPU AMD è libero e non viene deblobbato, ma il microcodice non è libero e infatti non c'è nel kernel.
Idem per le schede wireless Intel.
Broadcom non lo so.

> per esempio vedo in /lib/firmware un mare di
> file, ma molti sono il risultato della
> compilazione di codice che è
> open

Sinceramente, io le levo perché non ce ne è UNO che usi, visto che ho scelto l'hardware in maniera accorta e infatti il kernel che sto usando non è tainted.

Ribadisco, il mio problema non è quanta roba closed c'è su ubuntu o arch o lamiadistrox... Quello che mi chiedo è se non sia il caso di tenerli almeno fuori dal kernel, prevedendo un metodo per "interfacciarli" come coi driver Ati closed di ualche anno fa o coi driver delle wireless intel.

Per due motivi: Per prima cosa chi vuole li mette su comunque ma si ha la base tutta opensource, e secondo si evitano kernel sempre più ciccioni.

Tra l'altro con i driver delle VGA e Gallium e i mdoesettings si hanno già i driver delle VGA fatti così: una parte nel kernel libera che parla con una parte nel driver esterno (nel mio caso nouveu libero).

Poi io la penso così, e spero che ci si ponga il problema anche ai livelli alti. Non è detto che la mia idea sia quella migliore.