Stiamo esagerando?

[superbubba]

Anche se già linkato all'inizio del thread, vorrei riproporre (in italiano) il post di Arjan van de Ven, Linux in un mondo di binari.

Cosa succederebbe.. se gli sviluppatori del kernel un giorno decidessero di accettare i moduli binari e farli diventare essenziali per il progresso di Linux?
.. un ipotetico scenario da giorno del giudizio, by Arjan van de Ven.

Ia prima cosa da puntualizzare è che lo scenario è improbabile, ma in un modo o nell’altro tutti gli assunti che seguiranno possono essere veri.

Il 6 Dicembre 2005 gli sviluppatori del kernel decidono in massa sulla legalità e preferibilità dei moduli binari nel kernel. In un primo momento il processo di sviluppo del kernel non cambia molto tranne una manciata di simboli in più e la rimozione di EXPORT_symbol_gpl.

Nelle 3 settimane successive le distribuzioni Red Hat Enterprise Linux, SuSE Sles cominciano ad includere una grande verietà di moduli binari sui loro cd di installazione. Debian ci rinuncia per seguire i propri principi, come fanno altre distribuzioni (Fedora Core, Open Suse..)

Le distribuzioni enterprise includono non solo i driver Ati e Nvidia ma anche i driver OEM per il raid, moduli per wireless, winmodem, windsl e TCP-offloading. Comunque, a differenza dei driver Nvidia e Ati, la maggior parte dei vendor che usano driver binari non forniscono i loro diver di uno “strato collante” in forma sorgente ma binario puro.

Acuni hardware vendor che sono stati in passato favorevoli all’open source, vedendo i loro competitor rilasciare solo driver binari, sentono pressioni all’interno per passare ad una struttura closed, riendendosi conto che spesso non hanno potuto implementare alcune features in open source per mantenere all’interno alcune Proprietà Intellettuali. Come risultato c’è la percezione che i competitor binari abbiano un vantaggio in partenza, o quanto meno il pensiero che si potrebbe avere più possibilità nel binario a spingere su tutte le caratteristiche dell’hw senza avere problemi di IP.

1 Febbraio 2006 la maggior parte dei produttori oltre ai driver open ha un piano di lavoro per rilasciare i propri driver binari. Alcuni non sviluppano più i driver open perchè non hanno risorse per fare entrambi.

1 Marzo. Le nuove linee di server di fascia alta sono equipaggiate da storage e network hardware di nuova generazione. Naturalmente sono disponibili i driver binari per le 2 ultime distribuzioni di RHEL e SLES, già integrati nelle versioni di febbraio delle suddette distribuzioni.
Un solo vendor produce anche .o insieme al binario. Due produttori di schede di rete riducono al minimo il supporto per i driver open su nuove periferiche, tutti gli altri li eliminano.
Per l’hardware consumer non cambia nulla; molti chipset si standardizzando su AHCI per SATA e ereditano le feature di networking chipset dalla linea server.

1 Aprile. Un paio di chipset sono aggiornati per includere una nuova ed eccitante feature audio per abilitare la visione avanzata di DVD. Sfortunatamente ciò devia dallo standard per le interfacce audio i810. Uno dei due produttori rilascia ul driver binario per linux, l’altro non considera il s.o. rilevante per il mercato desktop e non ha mai pensato di supportarlo.

1 Maggio. La maggior parte dell’hardware sui server richiede almeno 2 o 3 moduli binari per essere operativo.Mentre alcuni di questi sono disponibili nella forma “blob+glue”, la maggior parte sono solo binari per RHEL3, RHEL4 e SLES9 e alcuni solo per la nuova SLES10.
I sistemisti Linux hanno la possibilità di scegliere tra 4 kernel diversi per i loro server, ma nessuna speranza di usarne uno vanilla da kernel.org. Gli utenti Ubuntu sono attivi e lavorano duro per far funzionare alcuni driver sulla loro distribuzione. Grazie al loro successo circa il 50% dei server riesce a lavorare anche con un kernel Ubuntu.

1 Giugno - Flame aguerrito, il quarto con questo oggetto da gennaio, sulla mailing-list del kernel linux. Utenti e sviluppatori chiedono di adottare l’ABI (Application Binary Interface) usata in RHEL o SLES. L’analisi mostra come ciò non sia possibile e il thread diventa una discussione sul designa di una nuova ABI o la revisione di quella esistente. Molti sviluppatori sentono che la corrente struttura non è all’altezza e che nuove API/ABI più stabili sarebbero la strada più semplice. Altri ribattono che non solo sarebbe una perdita di tempo ma sarebbe anche necessario un freeze per supportare RHEL5. Gli amministratori sui server di produzione usano RHEL o SLES, o cloni come CENTOS che usano kernel binary compatibili.

1 Luglio. E’ diventata un impresa usare linux sui normali pc senza driver binari. Mentre un anno prima agli utenti servivano solo per l’accelerazione 3D, ora anche il 2D non va senza moduli binari, stesso dicasi per il networking (cable o wireless) e suono. Per metà delle macchine il supporto alle periferiche non c’è e il 20% usa ndiswrapper come “translation layer” per suono e networking. Debian ha perso la maggior parte degli utenti, perchè quasi impossibile da usare su tutte le macchine, così come Ubuntu e le distrubuzioni Ubuntu-like.
Debian-legal e gli altri progetti simili sono impossibili da leggere per chi non fosse interessato a flame continui. Ormai gli ultimi vendor che mantenevano una versione opensource dei driver non lo fanno più.

14 Luglio. Linus annuncia la stabilità della dell’ ABI nel kernel 2.7 e annuncia il fork alla versione 2.8 dovve si svilupperà un ABI differente. In pratica, solo le persone che resteranno con le loro vecchie macchine potranno aiutare nello sviluppo.

21 Agosto. Viene scoperto un baco nella serie 2.6 che evidenzia un errore di design in una funzionalità chiave delle API di sysfs. Fixarlo significa rompere l’ABI dei moduli e il che coinvolgerebbe il funzionamento tutti i moduli binari esistenti, ma non fixarlo significherebbe lasciare una vulnerabilità per scalare privilegi di root. Una fix veloce è disponibile come opzione CONFIG_, ma chi ha bisogno di driver binari non ha altra chance che lasciare i sistemi vulnerabili.
E’ subito flame in ikml, Linus avrebbe sbagliato a “freezare” l’ABI, piuttosto si sarebbe dovuto crearne una nuova destinata al freeze?! Lo sviluppo del 2.7 si ferma ed è proposta una patch per avere di nuovo l’ ABI del 2.6, annullando i progressi in VM e le patches realtime di Ingo Molnar.

26 Agosto. Viene reso noto su bugtraq un exploit per il baco, usato in uno svariato numero di rootkit. Uno script php lo usa per raggiungere i privilegi di root! Gli utenti fanno pressioni perchè i moduli vengano riscritti per il nuovo ABI, alcuni lo faranno nelle prossime 3 settimane. Altri, specie nel mercato consumer, dicono che i driver in questione sono per hardware non più in vendita quindi non si curano di rilasciare nuovi driver binari.


Questo scenario può sembrare improbabile. E per fortuna il presupposto (l’evento del 6 Dicembre) è improbabile.

Comunque, e sfortunantamente, alcuni di questi “salti” non sono affatto improbabili. Potrebbero accadere tranquillamente, come i flame sulla discontinuità API/ABI. Pensiamo poi all’effetto ndiswrapper con fornitori che dicono “supportiamo linux, il ndiswrapper può usare il nostro driver di windows”. Spero che ciò non accada. Alcune di queste speranze sono speranze vane, ma credo che il vantaggio della liberà alla fine è forte abbastanza da soverchiare le opinioni di chi non è daccordo.

[ilsensine]

Originariamente inviato da javaboy

Capisco bene che i kernel developer non amino i driver closed, anche io preferirei che i driver fossero il più possibile open.
Però come dici tu stesso i kernel developer "tollerano" tali driver, la FSF non tollera un bel niente, questo atteggiamento secondo me non fa bene a linux.

La fsf c'entra con linux meno di quanto pensi, puoi stare tranquillo.

Si stanno pian piano scocciando? Non mi sembra che siano in condizione di imporre niente.

Sono nelle condizioni di imporre la GPL nello stesso modo in cui la Microsoft impone la sua EULA.

A me non piace la EULA Microsoft, ma non per questo vado a dire cose simili. Semplicemente, la rispetto e uso altro software.

[ilsensine]

Originariamente inviato da Cobra78

Posto che la mia posizione non è rilevante vista la mia poca esperienza in campo linux, la mia non conoscenza della programmazione e il mio utilizzo unicamente desktop, allora ti chiedo: secondo te cosa dovrebbero fare le case produttrici di hardware? pito questo aseptto del tuo (vostro?) pensiero.

Ne riparliamo l'anno prossimo, quando succederà un certo casino.
Per adesso non voglio affrontare questo argomento.

E ancora: ok, i kernel developer si rompono dei driver closed, non li rendono più utilizzabili, e poi che si fa? Non si usa più linux in rpesenza di hardware di un certo tipo?

Tu (e Javaboy) potete stare tranquilli, i kernel developer non faranno nulla per impedire il funzionamento ai driver closed source che esistono adesso.

[k0nt3]

Originariamente inviato da ilsensine

Ne riparliamo l'anno prossimo, quando succederà un certo casino.
Per adesso non voglio affrontare questo argomento.

casino? non puoi lasciarci con il fiato sospeso fino all'anno prossimo ! alludi al fatto che nel futuro al posto del bios ci sarà EFI e quindi i drivers non dipenderanno dalla piattaforma?

ps. però voglio un EFI opensource

[javaboy]

Originariamente inviato da Mezzelfo

javaboy sei libero di criticare la Free Software Foundation ma probabilmente non sai nemmeno cosa sia, come sia nata e quali sono i suoi obiettivi.

Dal sito della FsF
"The Free Software Foundation (FSF), established in 1985, is dedicated to promoting computer users' rights to use, study, copy, modify, and redistribute computer programs. The FSF promotes the development and use of free software, particularly the GNU operating system, used widely in its GNU/Linux variant."

Ho messo in evidanza i 2 punti fondamentali che un modulo closed non rispetta. Non rispetta il tuo diritto di studiare come funziona e di modificarlo anche se può essere usato e distribuito.
Ora visto che la parte filosifica ed etica non sembra interessarti minimamente e quindi non sei chiaramente un sostenitore del Free Software (dove: "free'' as in "free speech", not as in "free beer".) tu sei libero come chiunque altro di usare, studiare, copiare, modificare e ridistribuire software open source.

La Free Software Foundation e la Licenza GNU sono state fondamentali per lo sviluppo e la diffusione del software open source. Pensi che se la GNU fosse stata diversa oggi Linux e il Software Open source sarebbero a questi livelli?

Le aziende, come ad esempio IBM, invece di investire nello sviluppo di codice aperto di cui tutti avrebbero goduto i benefici, avrebbero fatto sviluppare i moduli proprietari che gli interessavano e basta. Il Kernel Linux esisterebbe come è ora?

La licenza GNU garantisce le 4 libertà fondamentali del Free Software:
* The freedom to run the program, for any purpose (freedom 0).
* The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
* The freedom to redistribute copies so you can help your neighbor (freedom 2).
* The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

L'unica ""restrizione"" è che ti dice che anche TU devi garantire queste stesse libertà agli altri quando realizzi altro software o lo distribuisci. Se pensi che questo sia così fanatico, che sia così fanatico se ti dico "guarda, ho costruito una tagliaerbe, prendila pure se ti serve, puoi usarla per fare quello che vuoi, puoi capire come funziona smontadola e guardandoci dentro; ah, puoi anche migliorarla se vuoi e ne puoi costruire una uguale, basta che poi la presti anche agli altri che te la chiedono e gli permetti, proprio come ho fatto io con te, di fare le stesse cose, cioè usarla come vogliono, di vedere come è fatta, di costruirne altre e di modificarle e di prestarla ad altri ancora" allora io sono Futtutissimo Fanatico e ne vado fiero.

Però non permetteresti di montare sul tagliaerbe un pezzo indispensabile solo perchè questo a sua volta non può essere smontato.
Questo secondo me non conviene a nessuno.

[eclissi83]

Originariamente inviato da javaboy

Però non permetteresti di montare sul tagliaerbe un pezzo indispensabile solo perchè questo a sua volta non può essere smontato.
Questo secondo me non conviene a nessuno.

perche' non conviene?

[LukeHack]

Originariamente inviato da eclissi83

perche' non conviene?

esatto, perchè non conviene? calcola che a parte i driver nvidia, tutto il resto O funziona su codice open, OPPURE funziona MALE (vedi ati)..

[ilsensine]

Originariamente inviato da k0nt3

casino? non puoi lasciarci con il fiato sospeso fino all'anno prossimo ! alludi al fatto che nel futuro al posto del bios ci sarà EFI e quindi i drivers non dipenderanno dalla piattaforma?

ps. però voglio un EFI opensource

E' bello vedere come la gente vive nel mondo dei sogni

Ne riparliamo tra un pò di mesi, ora è prematuro.

[javaboy]

Originariamente inviato da eclissi83

perche' non conviene?

Devo dedurre che tu i driver nvidia non li usi.

[javaboy]

Perchè non vietare anche gli eseguibili closed source a questo punto?

[LukeHack]

Originariamente inviato da javaboy

Devo dedurre che tu i driver nvidia non li usi.

infatti sono un' eccezione xchè in effetti sono gli unici driver closed che funzionano BENE (13200 fps con la mia vga al glxgears)..

[LukeHack]

Originariamente inviato da javaboy

Perchè non vietare anche gli eseguibili closed source a questo punto?

xche non VIOLANO LA GPL, non andando ad attaccarsi al kernel

[javaboy]

Originariamente inviato da LukeHack

xche non VIOLANO LA GPL, non andando ad attaccarsi al kernel

Si infatti sto proponendo una modifica alla gpl.

[eclissi83]

Originariamente inviato da javaboy

Devo dedurre che tu i driver nvidia non li usi.

dici bene, non li uso... e fino a qualche mese fa (prima che si rompesse, dopo 7 anni di onorato servizio) avevo una tnt2. ora ho una ati prestata da un amico, ma a parte un primo periodo, non ho usato i driver nvidia, cosi' come ora non uso i driver ati.

[ilsensine]

Originariamente inviato da javaboy

Si infatti sto proponendo una modifica alla gpl.

Non c'entra la gpl qui.

I kernel developer hanno messo nero su bianco che il semplice utilizzo delle syscall di linux non è sufficiente affinché un programma possa essere considerato opera derivata dal kernel linux. Le syscall possono essere utilizzate da chiunque.

[Cobra78]

Originariamente inviato da ilsensine

Tu (e Javaboy) potete stare tranquilli, i kernel developer non faranno nulla per impedire il funzionamento ai driver closed source che esistono adesso.

Chiaramente non hai capito buona aprte di quello che ho scritto se mi accosti a Javaboy come idee, meglio che chiuda qui il discorso va, come ho detto in qeusto topic si sta passando il segno quanto ad atteggiamenti.

Lasciamo perdere che è meglio...

@LukeHack

Semplicemente ha detto mi ha risposto una cosa che non c'entra una beneamata fava con quello che ho chiesto, ma frutto di una secondo me colpevole maleinterpretazione

Ho scritto che volgio suare i driver closed a tutti i costi? No..

Ho fatto domande aspettandomi risposte (e questo l'avevo già detto a K0nt3), invece di spiegarmi dove stia il problema, cosa io abbia detto di sbalgiato, ha scritto qualcosa che suona molto come "tranquilli bimbi che io giochino tanto non vi viene tolto, non sforzatevi a capire".

[LukeHack]

Originariamente inviato da Cobra78

Chiaramente non hai capito buona aprte di quello che hos cirtto se mi accosti a Javaboy come idee, meglioc he chiuda qui il discorso va, come ho detto inq eusto topic si sta passando il segno quanto ad atteggiamenti.

a me sembra che ilsensine non ti abbia attaccato (neanche a javaboy)

[ilsensine]

Originariamente inviato da LukeHack

a me sembra che ilsensine non ti abbia attaccato (neanche a javaboy)

Infatti; volevo solo rispondere alla domanda. Non è possibile che i "kernel developer si rompano dei driver closed" e da un giorno all'altro li proibiscano.
Stanno solo mettendo sempre più paletti a ciò che i driver closed (futuri) non possono assolutamente toccare.

[Cobra78]

Originariamente inviato da ilsensine

Infatti; volevo solo rispondere alla domanda. Non è possibile che i "kernel developer si rompano dei driver closed" e da un giorno all'altro li proibiscano.
Stanno solo mettendo sempre più paletti a ciò che i driver closed (futuri) non possono assolutamente toccare.

E dirlo così subito costava tanto?

Una risposta chaira, non ho pretese assurde, poi sarò anche io paranoico a volte...

[k0nt3]

Originariamente inviato da ilsensine

E' bello vedere come la gente vive nel mondo dei sogni

Ne riparliamo tra un pò di mesi, ora è prematuro.

maledizione lo volevo sapere... ma google lo sa?