Che ne dite dei BLOB nel kernel?

Pubblicità

davethecipo

Utente Èlite
Messaggi
3,332
Reazioni
1,163
Punteggio
138
Ho letto qualche paginetta sull'argomento. Ho capito i problemi che ne possono derivare in teoria, però non ho trovato niente sulla pratica, cioè quanti e quali sono i blob inclusi, e inoltre se ci sono problemi di stabilità o sicurezza evidenti. Non intendendomene, vorrei chiedere: anche i driver closed di ATi e Nvidia ne fanno parte?

Ho letto che OpenBSD esplicitamente rifiuta i blobs, sapevo che solo gnewsense e qualche altra distro Gnu/Linux adottasse questa filosofia - direi in primis Debian; anche se niente vieta di installare i "restricted-extras" che, pur non essendo parti del kernel, rimangono nell'ambito di binari senza sorgenti-.

Non mi dispiacerebbe instaurare una discussione.

Il mio punto di vista è che non avere le specifiche dell'hardware in modo da avere almeno la possibilità di scriverne i drivers è una pratica che seppur legale si presenta come decisamente scorretta nei confronti del FOSS. Poi scusate la mia miopia, ma un'azienda come Nvidia o Ati (tanto per parlare di aziende ultra-note) cosa ci dovrebbe perdere? L'azienda continua a sfornare la propria versione del driver, dandone però la possibilità anche alla comunità.

Il lato "pragmatico" di Torvalds mi sta bene, però fino ad un certo punto; sinceramente preferisco l'integralismo di Stallman...uno che ha le proprie idee e le sostiene fino in fondo, cercando di guardare oltre le momentanee leggi positive. (Anche se non necessariamente preferisco l'impostazione filosofica della licenza GPL alla BSD, ma questo è un altro discorso...interessantissimo fra l'altro)

Riassumendo: posso accettare nel breve termine blob e software closed che si inculca in software libero, però a lungo termine è decisamente da evitare.
 
ti appoggio , mi viene difficile capire perche una casa non possa fornire le specifiche del suo prodotto alla comunità .

provo a motivarlo con una questione di marketing legata alla non-copiabilità del prodotto, ma il discorso crolla quando si pensa ad un produttore "grande" e con buone possibilità economiche, ricavare le specifiche simulando /smontando ed analizzando il prodotto del concorrente risulta facile "sgamare" le spefiche .

tolto questo discorso davvero, non ved perchè non sia possibile semplificare la vita alla comunità open ( e magari "rendere" cio che l'open ha fatto per tutti )
 
Ti linko l'articolo di en.wikipedia.org, è forse ridotto nel contenuto ma tanto basta. Per farla breve si parla di BLOB nel kernel quando c'è del codice oggetto senza files sorgenti disponibili. Un esempio che calza a pennello è per i driver di periferiche.

Si stanno moltiplicando i casi - per fortuna nostra, e questo plurale maiestatis vuole indicare chi usa software libero - di produttori hardware che rilasciano i sorgenti dei driver, oppure le specifiche dell'hardware: queste ultime sono la base imprescindibile per scrivere software. Anche se c'è gente che ci sa fare e riesce ad ottenere risultati anche col reverse engineering - tecnica che comunque AFAIK molte volte è al limite del legale ed è una sorta di placebo, perché non risolve il problema di fondo, cioè appunto la mancanza delle specifiche-.

L'articolo su wikipedia cita la possibilità di malfunzionamenti, falle di sicurezza. Insomma bugs che con software di cui sono disponibili sorgenti possono essere risolti dalla comunità, cosa che non può succedere se sono solo i dipendenti dell'azienda X ad avere accesso al codice.

Insomma i BLOBS nel kernel piuttosto che software closed in generale, pongono due problemi strettamente legati fra loro:

  • di natura "filosofica", cioè la mancanza delle libertà caratteristiche del software GPL o BSD (che poi uno sia d'accordo nel definirle libertà essenziali o meno è un altro paio di maniche)
  • di natura pratica, perché se sorge un problema bisogna affidarsi al produttore (che non necessariamente è impermeabile alle richieste della comunità, ma nessuno lo obbliga per legge...)
 
Non ho paura per la sicurezza del sistema, in Windows si utilizzano praticamente solo driver proprietari, quindi non penso sia così grave integrarli. IMHO.

In linea di massima sono d'accordo con voi, specifiche aperte per tutti i dispositivi, anche se, nel caso dei driver video, difficilmente gli sviluppatori open riusciranno a sfornare dei prodotti decenti, per ora i driver open vanno bene solo per un'utilizzo d'ufficio, le applicazioni 3D spesso non partono nemmeno.
 
capito, beh allora a questo punto sono assolutamente contrario. mi viene un'altra domanda in mente...visto che in questo modo i sorgenti non sono accessibili e quindi gli utenti più bravi non possono fixare bug, una persona particolarmente capace non potrebbe avere i mezzi di "estrarre" dal sistema operativo i file dei driver proprietari installati e da questi lavorare sul codice? scusate le tante domande, per me il top è la programmazione in c, di più non so fare, amo linux (non tutte le distro) perchè la installi e vai, senza perdite di tempo.
 
Pubblicità
Pubblicità
Indietro
Top