driver proprietari su Ubuntu "Feisty Fawn”

[ilsensine]

Comunque, guisto per fare UN SOLO ESEMPIO di come funzionano le cose sotto linux (e soprattutto del PERCHE' funzionano), ricordo ai più giovani la storia del driver pwc, per alcune webcam usb Philips. E' una storia di due/tre anni fa, ma molto istruttiva.

Le webcam Philips in questione possono utilizzare, per alte dimensioni e frame rate, dei formati compressi per le immagini. Questi formati, proprietari - diciamo quindi "per definizione migliori di tutti gli altri?" - non erano stati divulgati dalla Philips.
L'autore originario del driver era un tizio che si firmava come Nemosoft. Aveva sottoscritto un NDA restrittivo con Philips, che gli vietava la scrittura di driver liberi contenenti quei formati di compressione. Aveva deciso di strutturare il driver in due parti:
- un core GPL, il driver pwc, contenente supporto per il protocollo USB delle webcam; era anche in grado di gestire le immagini non compresse, disponibili solo a dimensioni ridotte (tipo 128x96, qualche sciocchezza simile).
- un driver proprietario, pwcx, con le routine di decompressione.
Aveva inserito nel driver pwc degli "hook", punti di accesso, tramite i quali il driver (proprietario) pwcx era in grado di integrarsi nel driver (GPL) pwc. Questi hook non solo sono di dubbia legalità, vista la GPL, ma sono chiaramente banditi da Linux.

Fatto sta, il driver pwc entrò nel kernel molto tempo fa, e non si prestò attenzione al fatto che quegli hook erano ad esclusivo uso e consumo di un driver proprietario. Unendo il driver pwc e pwcx, sembrava possibile gestire tutte le webcam Philips e i loro dannati formati di compressione.
Probabilmente alcuni di voi potrebbero giudicare "buono" il - diciamo - "compromesso" ottenuto con i pwc/pwcx. Peccato che gli utenti di architetture x86 erano "esclusi" dal pwcx; proprietario, binary only, disponibile solo per l'architettura per cui è compilato. L'esatto opposto di quello che fa linux, rendere disponibili _tutti_ i driver a _tutte_ le architetture. Appunto perché ha driver _liberi_

Tempo dopo, una modifica tecnica al kernel costrinse Nemosoft a modificare gli hook, in quanto erano diventati incompatibili con il pwcx. Nel frattempo il processo di inclusione nel kernel era diventato più controllato, e la presenza di questi hook fu smascherata. Immediata fu la loro rimozione dal kernel.
Nemosoft non la prese bene. Sbattè la porta in faccia a tutti, smise di mantenere il driver, e ne chiese la rimozione dal kernel.

Risultato: SORPRESA! oggi abbiamo un driver pwc _completamente libero_, compresi i decompressori (facilmente decifrati tramite "reverse engeenering" -- alla faccia dello "straordinario" algoritmo inventato da Philips), disponibile su _tutte_ le architetture, da ARM a PPC passando per Sparc.

Tutto questo non sarebbe stato possibile senza il _rifiuto completo_ dei driver proprietari, tipico di Linux.

A voi le conclusioni.

[Artemisyu]

Originariamente inviato da ilsensine

Non farlo

Vedi? Ti devo ringraziare
Ho evitato di alimentare il flame, e tu hai proseguito la discussione al posto mio

[MrAsd]

Originariamente inviato da ilsensine

Appunto, e parte integrante di questo modello di sviluppo - che ha attirato tanti sviluppatori e prodotto tanti driver - è accettare solo codice libero. Che piaccia o meno.

modello di sviluppo != licenza di rilascio
La facilità con cui puoi contribuire e far accettare le tue proposte non mi sembra che abbia la minima rilevanza con la gpl.

Anche linux ha la sua "cupola"; non auguro neanche a Totò Riina di trovarsi casualmente in disaccordo con Linus Torvalds o (peggio) Christoph Hellwig

Evidentemente non hai mai avuto a che fare con de Raadt... benché abbia visto diverse volte Torvalds prendere decisioni piuttosto ferme devo anche dire che di fronte ad un buon numero di sviluppatori con una proposta (ragionata ovviamente non certo buttata per caso) non l'ho mai visto dire veramente di no, come pure non l'ho mai visto rifiutare un driver utile. Questo ad esempio ed uno dei motivi per cui linux ha 4 fs journalled "from scratch" e freebsd 1, per cui in Linux ci sono due api diverse per fare l'hibernate e su *BSD 0...

è la stessa differenza che c'e' tra l'essere comdomini di un condominio e ospiti di un appartamento dello stesso: in entrambi i casi c'è un amministratore con la differenza però che nel primo caso un buon numero di condomini puo' far passare la propria mozione, nel secondo caso puoi sbraitare finche' vuoi ma nessuno ti dara' probabilmente corda e questo le società commerciali l'hanno capito al volo. Poi ovviamente il fatto che la gpl permetta di contribuire sicuri che la MS di turno non scopiazzi tutto a proprio vantaggio economico è importante, ma viene soltanto in seconda battuta; se proponi di aggiungere un driver per il tuo oscuro cluster fs e (facciamo un esempio ) quelli di netbsd ti rispondono picche, puoi anche essere sotto licenza bsd ma non rimane granché da copiare...

Poi vabbe' un purista di BSD ti direbbe che Linux ha 10.000 driver diversi di cui 8000 frutti di hack maldestri, mentre il proprio flavour di bsd magari ne ha soli 200 ma che funzionano bene oppure che Linux non ha una roadmap precisa e che in viaggia in funzione dei capricci di Redhat, Ibm... ma questo è un altro discorso...

Anche sui sistemi *BSD è possibile, volendo...

Si certo (pcbsd è di fatto una distribuzione di freebsd) ma resta il fatto che è comunque un modello più limitato in cui al massimo tu puoi abbellire un po' quello che c'e' gia', ma tutto il S/O, volente o nolente, te lo trovi gia' cosi' e se non ti va bene il kernel, o la disposizione del file system o vattelapesca sei praticamente costretto a fare un fork. è quello che è successo con DragonFly/Freebsd e OpenBsd/Netbsd e alla luce dei fatti non mi è sembrata una strategia vincente eppure questo non ha nulla a che fare con la licenza.

[zephyr83]

Originariamente inviato da AntonioBO

Proprio non capisco lo "snobismo" di alcuni utenti Linux. Mi ricorda l'atteggiamento - aggiungo fastidioso - supponente degli utenti Apple che guardano dall'alto in basso gli utenti del PC.

Stra quoto, penso anche io la stessa cosa da tempo e nn sono il solo. C'è un articolo interessanti su linux e C di dicembre/gennaio (numero 56/57) riguardo Novell, Microsoft e FSF. Lo riporterei tutto (magari se ho tempo scansiono, sn due paginette) ma mi limito solo alle parti di critica alla FSF (in questo numero di Linux&C ci sn più articoli che trattano l'accordo fra Novell e Microsoft e ne analizzano tutti i vari aspetti, positivi e negativi, intervistando anche esponenti novell, microsft e samba team, FSF Italia).

Infine, va riconosciuta - con molto dispiacere, ma con molta chiarezza - che la Free SOftware Foundation è ormai rovinosamente precipitata in una sclerosi ideologica che la ha trasformata da anima di una rivoluzione, in un vero e proprio culto monoteistico e integralista. Questo implica che il suo obiettivo è, oramai, diventato solo quello di proteggere l'ortodossia, scomunicando indiscriminatamente chi propone visioni diverse o alternative alla "verità rivelata" (vedi la polemica su GPLv3).

.........

Sarebbe stato possibile prevedere (o quantomeno anticipare) le mosse dell'avversario? Forse si, se la comunità del software libero si fosse accorta per tempo che il mondo, là fuori, stava cambiando velocemente. Ma era troppo occupata a crogiolarsi nello snobbismo elistico di chi "lotta per la causa". Mette(va) all'indice le tesi sgradite (ricordate le polemiche provocate dalla nascita della Open Source Initiative di Bruce Perens?), convinta che nessuno potesse sfidarla sul proprio terreno. E invece, è proprio quello che è successo: le grandi corporation hanno sfondato i confini con i territori del free software, approfittando dell'endemica incapacità del software libero di fare il salto di qualità in termini commerciali.
A questo punto ci si sarebbe aspettati, dallo "zoccolo duro" del free software, una pragmatica presa d'atto dell'accaduto e l'adozione di una strategia per trarre vantaggio da un cambio di scenario così netto. E invece la comunità ha reagito in un modo (apparentemente) incomprensibile, gridando allo scandalo e minacciando una vera e propria guerra santa all'insegna della violazione della GPL.

....

Ancora una volta, dunque, riemerge l'approccio integralista che Linus Tovald ha criticato aspramente, in occasione dell'apertura del dibattito su GPL3 che considera uno strumento da agitatore, buono soltanto per le policy estremiste della FSF: http//www.vnunet.com/vnunet/news2161274/revised-gpl3-keeps-drawinf-free


Questo mio intervento nn riguarda propriamente la presenza o meno di driver proprietari nel kernel ma è una considerazione su questo atteggiamento "integralista" che noto anche in questo e altri forum. Per me è MOLTO controproducente e se lo critica lo stesso Tovald è abbastanza "grave".

[Artemisyu]

Originariamente inviato da zephyr83

Questo mio intervento nn riguarda propriamente la presenza o meno di driver proprietari nel kernel ma è una considerazione su questo atteggiamento "integralista" che noto anche in questo e altri forum. Per me è MOLTO controproducente e se lo critica lo stesso Tovald è abbastanza "grave".

Non capisco il senso di questo intervento.
Nessuno qui (credo) dice che su Linux non debbano girare applicativi closed source o che grandi aziende non possano investire sul software libero.

Qui si critica il fatto che dei driver binari non debbano girare nel kernel. E' una cosa pericolosa, sia per l'integrità di Linux che per motivi essezialmente tecnici, e non vale la candela di avere gli effetti sbarluccicosi appena installato un sistema.

Dire che è meglio un Linux libero che un Linux semplice non è essere integralisti, ma è volere il bene di Linux. Che è una caratteristica che fa anche TANTO comodo alle suddette aziende.
Torvalds, che qui viene citato per aver visioni possibiliste, è uno dei più fermi oppositori dei driver binari nel kernel.
E ci mancherebbe anche.

[MrAsd]

Originariamente inviato da Artemisyu

Torvalds, che qui viene citato per aver visioni possibiliste, è uno dei più fermi oppositori dei driver binari nel kernel.
E ci mancherebbe anche.

Ti risulta male. http://arstechnica.com/news.ars/post/20061215-8428.html

[Artemisyu]

Originariamente inviato da MrAsd

Ti risulta male. http://arstechnica.com/news.ars/post/20061215-8428.html

Che culo.
Io ero rimasto ad alcuni suoi interventi di giugno/luglio.

Come mai ha cambiato idea?

[darkbasic]

Non ho letto il link, ma dal titolo penso di aver capito di che si tratta...

"Linus won't ban binary kernel modules"

Se non erro, dovrebbe essere la risposta di Torvalds all'affermazione da parte di alcuni developers di voler patchare il kernel in modo da impedire l'installazione di driver proprietari.
Il che è ben diverso dall'inserire driver binari nella mainline del kernel...

[MrAsd]

Originariamente inviato da Artemisyu

Come mai ha cambiato idea?

Sostanzialmente perché e' uno dei pochi ad aver capito che impedire l'uso di moduli binari (quali quelli di nvidia, tanto per citare i più famosi) non avrebbe risolto in toto il problema in quanto gli autori di tali "schifezze" avrebbero probabilmente aggirato il problema spostando i loro "blob" in user space. Cio'avrebbe probabilmente risolto la questione "gpl vs moduli closed source" ma in compenso avrebbe rotto le scatole a tutte le distribuzioni in circolazione e agli utenti (che nella migliore delle ipotesi si sarebbero trovati per mesi senza supporto per questa o per quell'altra periferica....)

[MrAsd]

Originariamente inviato da darkbasic

Il che è ben diverso dall'inserire driver binari nella mainline del kernel...

Infatti si disquisiva del problema Ubuntu ossia se e' giusto dare la possibilita' di installare driver closed source durante l'installazione della distribuzione (magari comodamente dal cd di installazione) oppure no. Poi qualcuno ha sviato il discorso...

[ilsensine]

Originariamente inviato da MrAsd

Ti risulta male. http://arstechnica.com/news.ars/post/20061215-8428.html

Non conosci il contesto in cui l'ha detto (e da quell'articolo in effetti manca un pezzo di qualche tempo fa, per capire l'intera storia).

A causa del proliferare di driver proprietari (in particolare per le schede video), gli sviluppatori decisero di iniziare a porre dei paletti chiari. Uno di questi era l'identificazione di alcuni simboli del kernel come "gpl only" (disponibili solo ai moduli gpl).

Qui è intervenuto Linus, chiarendo che il tag "gpl only" poteva essere applicato solo alle interfacce e funzionalità future, e che non avrebbe ammesso dei "gpl only" solo per il gusto di spazzare via alcuni moduli proprietari ben noti. Ripulire il kernel dai driver proprietari è una cosa che richiede tempo e pazienzam e forse non sarà mai completata al 100%; Linus lo sa bene e per questo in qualche modo li tollera, e impedisce dei ban non giustificati. Ma non gradisce i moduli proprietari, come tutti; semplicemente, ragiona più da "dirigente" (quale deve essere) che da "sviluppatore".

Una differenza però c'è tra Linus ed altri sviluppatori: Linus ha più volte dichiarato di non voler porre limiti a cosa l'utente fa del kernel, indipendetmenete dal fatto che approvi o meno l'utilizzo che l'utente ne fa. Se l'utente si scarica un driver proprietario e lo installa, fatti suoi. Deve però fare i conti anche con gli altri sviluppatori (il kernel non è tutto suo!), che - altrettanto legittimamente - dicono: "questa parte di codice l'ho scritta io, ma per il beneficio di altri driver liberi, non per uso e consumo di nvidia & co, ed è mio diritto veder rispettata la mia volontà come autore del codice". Il compromesso, come dicevo, è la nascita dei tag "gpl only" e l'assicurazione che i driver proprietari potranno funzionare anche in futuro, con le interfacce odierne.

Ma ti assicuro che i driver proprietari non sono affatto i benvenuti. E più passa il tempo, più stanno creando problemi.

Dispiace che alcuni utenti non siano sensibili al problema e si accontentino della scorciatoia del driver proprietario. Se "basta che funziona", ci sono tanti altri sistemi operativi e kernel in cui questo è possibile.

[AntonioBO]

Originariamente inviato da MrAsd

Infatti si disquisiva del problema Ubuntu ossia se e' giusto dare la possibilita' di installare driver closed source durante l'installazione della distribuzione (magari comodamente dal cd di installazione) oppure no. Poi qualcuno ha sviato il discorso...

Io dico che è giusto. Come è possibile pensare un sistema senza codec mp3 o divx? D'accordo che c'è il formato ogg.... ma chi lo supporta? Quale lettore di files musicali portatile lo legge? Da quello che so nessuno... E a proposito di drivers.. qualcuno mi sa spiegare perchè non riesco a far funzionare la mia stampante dell 720?? Non c'è pezza.... quindi c'è qualcosa da migliorare.... sulal questione drivers si gioca una battaglia risolutiva.

[ilsensine]

Originariamente inviato da MrAsd

gli autori di tali "schifezze" avrebbero probabilmente aggirato il problema spostando i loro "blob" in user space.)

Non disprezziamo tanto lo user space.

Guarda quanto è grosso il driver nvidia; i geni hanno pensato bene di mettere intere logiche OpenGL nel kernel. Follia pura.

Guarda invece come funzionano i winmodem di Intel.

[ilsensine]

Originariamente inviato da AntonioBO

qualcuno mi sa spiegare perchè non riesco a far funzionare la mia stampante dell 720?? Non c'è pezza.... quindi c'è qualcosa da migliorare....

Hai perfettamente ragione, ma ti stai rivolgendo alle persone sbagliate.

Più di arrivare ad offrire la scrittura gratuita dei driver gli sviluppatori non possono altro.

[AntonioBO]

Dispiace che alcuni utenti non siano sensibili al problema e si accontentino della scorciatoia del driver proprietario. Se "basta che funziona", ci sono tanti altri sistemi operativi e kernel in cui questo è possibile.[/quote]

Scusami tanto se insisto. Pensiamo un attimo alle persone che usano un computer: perchè lo usano? Non dimentichiamoci che il PC è un mezzo per raggiungere risultati in svariati campi. Si usa il PC per lavorare, per giocare, per navigare, insomma per fare cose pratiche e non effetti occulti e pirotecnici. Capisco la filosofia open source e l'apppoggio in toto come sistema per sottrarsi a logiche puramente lucrative che non permettono l'accesso a tutti della tecnologia. Però bisogna prendere ciò che c'è di buono senza snaturare lo scopo principe e, sinceramente, se un sistema operativo" funziona" e funziona bene.... bè sta facendo il suo dovere

[ilsensine]

Originariamente inviato da AntonioBO

qualcuno mi sa spiegare perchè non riesco a far funzionare la mia stampante dell 720??

Mi spieghi che diavolo c'entra il kernel con quella stampante?

[AntonioBO]

Originariamente inviato da ilsensine

Mi spieghi che diavolo c'entra il kernel con quella stampante?

Non si parla di drivers??

[ilsensine]

Originariamente inviato da AntonioBO

Capisco la filosofia open source e l'apppoggio in toto

Non hai capito bene invece quello che sto cercando di dire. Rileggiti l'esempio che ho fatto sul driver pwc, e il link sulla "provocazione" di Arjan van de Ven

[ilsensine]

Originariamente inviato da AntonioBO

Non si parla di drivers??

Cosa c'entra il kernel con il driver di una stampante usb, il cui produttore ha sagacemente scelto di ignorare il protocollo standard usb-lp per farne uno proprio? Una fesseria del genere si può fare in userspace.

Anzi pare che sia stato fatto, visto che quella stampante è un paperweight Lexmark rimarcato:
http://www.thorubio.org/cms/space/Li...to+Printer+720
nb rifletti sul significato della riga "bad news" già che ci sei.

[MrAsd]

Originariamente inviato da ilsensine

Ma non gradisce i moduli proprietari, come tutti; semplicemente, ragiona più da "dirigente" (quale deve essere) che da "sviluppatore".

Ma guarda che abbiamo detto la stessa cosa: a nessuno piacciono i moduli binari/closed source/proprietari ma nella diatriba blocchiamoli/non blocchiamoli Torvalds si e' comunque espresso per il "non blocchiamoli".

Comunque per chi e' interessato il post incriminato e' il seguente http://lkml.org/lkml/2006/12/13/370

Non disprezziamo tanto lo user space.

Nono disprezziamolo
Spostare la blobbaggine in user space risolve la presunta l'incompatibilità con la gpl ma non risolve il problema di fondo, ossia la mancanza di driver free.

Guarda quanto è grosso il driver nvidia; i geni hanno pensato bene di mettere intere logiche OpenGL nel kernel. Follia pura.

Il famoso "shim"...un'accrocchio orrendo ma che permette ad Nvidia di portare parti del driver di windows a Linux e Freebsd senza dover cambiare una virgola del codice e addirittura riciclando parti binarie dello stesso. Dal loro punto di vista un risparmio di tempo e danaro dal nostro una mostruosità

Originariamente inviato da AntonioBo

Io dico che è giusto. Come è possibile pensare un sistema senza codec mp3 o divx? D'accordo che c'è il formato ogg.... ma chi lo supporta? Quale lettore di files musicali portatile lo legge? Da quello che so nessuno...

Non mi addentro sulla questione mp3 perché è un discorso diverso (ossia un problema di brevetti) ma per quanto riguarda i driver binari sono d'accordo: alla fine il 99,99% degli utenti desktop finisce per installarli comunque da Adept/Synaptic quindi non vedo perché non proporne l'installazione direttamente durante l'install della distro, soprattutto se conderiamo il target a cui si rivolge Ubuntu. Piuttosto sono contrario a renderli la scelta di default ed ad installarli senza i dovuti warning: per la serie se proprio ti vuoi tirare martellate sugli zebedei sii almeno conscio di quello che stai facendo.