Gli sviluppatori del kernel Linux non fanno eccezioni. Dopo aver “bacchettato” Microsoft per non contribuire affatto all’implementazione di Hyper-V nei sorgenti del kernel creato da Linus Torvalds, Greg Kroah-Hartman ha colpito ancora, questa volta “scagliandosi” contro gli sviluppatori di Android.
Dopo l’inclusione in Linux, il supporto e il mantenimento attivo del codice da parte degli sviluppatori di Google è andato scemando e per questo il codice di Android è stato “espluso” dai sorgenti del kernel. Dunque niente driver di Android nel prossimo kernel 2.6.33.
Kroah-Hartman ha spiegato, senza giri di parole, che:
In breve, nessuno si è occupato del codice, per questo è stato rimosso. Come ho detto in precedenza, il codice che risiede nello staging tree ha bisogno che qualcuno ci lavori affinché si possa effettuare un merge con il main kernel tree, altrimenti verrà cancellato
Ma i problemi a detta dello sviluppatore sono molto più profondi. Sembrerebbe infatti che Google abbia apportato tali e tante modifiche ai sorgenti del kernel Linux da creare un vero e proprio “branch” separato:
Questo significa che qualsiasi driver scritto per l’hardware su cui deve girare Android non può essere unito (merged) al main kernel tree perché dipende da codice che risiede soltanto nel kernel tree di Google, generando errori quando si cerca di compilarlo nell’albero dei sorgenti di kernel.org.
A causa di questo, Google ha impedito a moltissimi driver e codice della piattaforma di essere uniti (merged) al main kernel tree. Di fatto questo ha generato un kernel branch su cui fanno affidamento un gran numero di differenti vendor.
Tutto questo ha come ricaduta che le aziende che contribuiscono al codice di Android con driver e codice non aggiunguno nulla di utile alla crescita del kernel Linux, apportando benefici soltanto al branch di Android.
La situazione è davvero delicata e, a quanto sembra di capire, Google non ha mostrato alcun segno di voler rendere il proprio codice integrabile con il main kernel tree.
Google sta diventando il “Male”? Presto per dirlo ma di certo gli utenti Linux avrebbero gradito un approccio decisamente diverso da una società che tanto ha contribuito e contribuisce alla comunità open source.
Google deve fare soldi con i suoi prodotti; che poi questo aiuti anche Linux sembra secondario.
di abba - 3 febbraio 2010 - 17:34
credo che prima o poi toccherà anche ad intel ed ibm, secondo me linux sta deragliando.
se una società migliora il proprio software per battere l’avversario diventa problematico scontrarsi con la cupola che gestisce gli aggiornamenti del kernel.
credo che vedremo molti fork in futuro, l’open source non è in discussione, la cupola pero’ perderà potere.
di aste - 3 febbraio 2010 - 18:06
Tutto questo per tornare a quel discorso su quanto linux venga programmato da sviluppatori pagati da questi colossi informatici… il bello è che molte persone “guru” di linux lo giudicavano un fatto positivo.
di Andrea - 3 febbraio 2010 - 20:40
aste ma cosa dici, IBM ed Intel oltre a contribuire nello sviluppo del Kernel Linux, mettono anche i soldini.
di Paguro - 3 febbraio 2010 - 21:31
@Andrea
Io non ho mai aperto un sorgente di Linux ne penso lo farò mai anche se potrei avere gli strumenti per farlo e credo che quelli che fanno “veramente” sviluppo su Linux DEVONO essere pagati…per tutto il tempo e le conoscenze che richiede. Il software libero non sarebbe quello che è, se non fosse per loro. Gli smanettoni della domenica cosa possono fare? trovare i bug, scrivere qualche riga di codice e poi?
Le professionalità devono essere remunerate…anche se poi vanno a lavorare per Google.
di max - 4 febbraio 2010 - 08:50
da sviluppatore Linux (lavoro su sistemi embedded, mi occupo di sw dal bootloader fino agli applicativi, passando ovviamente per kernel/driver) vi posso assicurare che e’ un bello sforzo (per realta’ medio-piccole) essere all’interno del kernel ufficiale.
Ci vuole un certo coding style (e vorrei vedere il contrario!) e, soprattutto, bisogna continuamente lavorarci dietro per allinearsi alle nuove release. Cosa quest’ultima che, se viene fatta con una certa costanza e con delle risorse dedicate (per una piattaforma basterebbe una mezza persona), non comporta uno sforzo troppo grande ma riporta molti benefici (vedi tutti i fix e nuove funzionalita’ degli strati indipendenti dall’architettura)
Il problema e’ il tempo e le risorse. Avere pero’ le risorse (non credo che google non si possa permettere 2-3 sviluppatori che si preoccupino solo del merge!) e non restare nel kernel mainstream vuol dire 2 cose:
1) o si e’ completamente folli e non si e’ interessati ai benefici di avere un kernel sempre aggiornato
2) o si fa’ una scelta politica: “io sono grande e grosso e non voglio sottostare alle leggi di nessuno/nessuno mi deve dire cosa fare e come scrivere il mio codice”
Ripeto: alcune volte con le nostre piattaforme abbiamo avuto una collaborazione “esterna” (un’azienda che e’ piu’ incentrata sul sw di noi e quindi puo’ dedicare risorse a questo scopo) e la piattaforma e’ stata inserita e mantenuta (con sforzo relativamente basso, se sai quello che stai facendo) nel mainstream. Il che vuol dire che faccio un “git pull” e mi trovo il kernel ultima release che compila e funziona con uno sforzo nullo (o quasi.. se non vado a beccare un tag stabile
)
Almeno, io la vedo cosi’
di Amon - 4 febbraio 2010 - 09:38
Ma stiamo scherzando? Tiriamo fuori ancora il discorso delle persone pagate per sviluppare il software? Vuoi sapere perche’ la gente viene pagata da queste aziende per lo sviluppo di linux? Perche’ loro USANO linux in primis, senza doverti stare a spiegare il perche’
E io non sono un fanboy, uso sia linux che win 
Fosse per me, butterei una fetta del PIL dentro a linux e farei una bella migrazione da windows a linux di tutto il reparto statale.
di Emanuele Ricci - 4 febbraio 2010 - 11:16
Sto google sta mettendo le zampe un po da per tutto!!! E non va x niente bene!!!! mitico Greg
di Kefran - 4 febbraio 2010 - 16:16
Fosse per me, butterei una fetta del PIL dentro a linux e farei una bella migrazione da windows a linux di tutto il reparto statale.
Giusto, è ora e non ci sono più scuse!
di rizlo - 5 febbraio 2010 - 09:58
@9 Certo che ci sono scuse….
L’ignoranza di molti dirigenti e dei loro collaboratori, a qualunque livello e in qualunque incarico….
Per taluni dirigenti, Microsoft è una manna. Il capro espiatorio ideale per i guai che combinano in quei rari momenti in cui si occupano delle mansioni a loro affidate. Senza alcuna responsabilità, naturalmente da parte loro.
Chia ha fatto l’errore presente nel documeto X? Il computer (naturalmente….); chi è il responsabile? La Microsoft (ovvio, mai loro e neppure i loro collaboratori…. Troppo incompetenti persino per fare quegli errori).
di Ratamusa - 5 febbraio 2010 - 11:39