Consequentia Mirabilis

Dal post di Arjan van de Ven traduzione e adattamento di uno scenario “possibile”.

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.

PS: Mi scuso per la traduzione che in alcuni punti può apparire un pò leziosa, non mi offenderò se vorrete correggermi, anzi, ma mi pareva una storiella significativa.

written by root