Come Google manipola il kernle Linux, alcuni numeri

Una delle aziende più potenti del web basa la propria forza su GNU/Linux, ecco alcuni dettagli sul suo utilizzo

Si può tranquillamente affermare con relativa certezza che al mondo non esiste azienda con il maggior numero di installazione GNU/Linux attive rispetto a Google.

Rispetto al suo enorme utilizzo all’interno dell’azienda poco o nulla si sa sui sistemi che Google implementa nelle sue macchine per adattare il nostro OS preferito alle sue esigenze, Mike Waychison, dipendente dell’azienda, cerca di far luce sui problemi e le soluzioni che a Mountain View incontrano sul loro cammino.

Al di la di quello che si possa pensare all’interno di Google il codice kernel viene gestito con un tool che ha ben poco di open ovvero Perforce, magari potrebbero rivolgersi a soluzioni aperte sicuramente più performanti.

Non esistono diversi rami del kernel Linux al quale i tecnici lavorano ma tutte le forse vengono impegnate nell’uni filone principale di codice; 30 sono gli ingegneri che ogni giorno lavorano a tempo pieno al kernel Linux.

Hanno iniziato con il kernel 2.4.18 al quale sono state applicate patch per un ammontare enorme, circa 2000 modifiche; successivamente, dopo aver aggiunto ben 492.000 linee di codice, la scelta di passare al 2.6.11 per via della necessità di avere del supporto SATA.

Alla versione 2.6.11 è seguita la 2.6.18 ed attualmente si sta lavorando sulla preparazione di un kernel base 2.6.26.

Se desiderate qualche numero per questa nuova versione in preparazione eccovi accontentati:

• 1208 patch
• 300.000 linee di codice aggiuntive
• 25% di patch corrisponde a backport di nuove funzionalità

Fortunatamente ci sono dei piani di sviluppo secondo i quali tutto questo lavoro non ha come obbiettivo quello di rimanere confinato all’interno degli uffici del colosso ma si sta cercando di collaborare con i tecnici che tutti i giorni creano il kernel.

Un primo passo è la volontà di passare a GIT per la gestione del codice creando simultaneamente tanti rami quanti sono gli ingegneri che lavorano sul codice stesso, ogni tre mesi i cambiamenti verranno valutati e rapportati alla linea di sviluppo principale.

L’attuale sistema di gestione è di difficile coordinazione con il resto dello sviluppo kernel che viene effettuato fuori dalle mura del GooglePlex, uno dei maggiori problemi è proprio l’allineamento di versione, visto che Google non riesce a mantenere il frenetico ritmo di sviluppo della comunità kernel si trova nella spiacevole condizione di sviluppare patch essenziali per l’azienda che però vanno totalmente riscritte o modificate se si cerca di passare ad un kernel più recente.

Questa rincorsa fa accumulare sempre più ritardo nello sviluppo come in loop che si ripete in continuazione, ad ogni kernel altro sviluppo altre modifiche ed altro tempo che inevitabilmente fa slittare la programmazione del kernel che è uscito nel frattempo.

Questo è il vero male che Google tenta di sconfiggere adottando nuove politiche di gestione del lavoro.

Il lavoro del colosso web è orientato soprattutto all’efficienza in termini di velocità di esecuzione delle richieste, requisito essenziale per l’azienda, successivamente i tecnici si scontrano spesso con le latenze ovvero il tallone di Achille per i sistemi server.

Maggiore collaborazione tra il gruppo di sviluppatori interno e la comunità sarebbe auspicabile fin da subito, sarebbe un modo per scambiare reciproche conoscenze le quali potrebbero migliorare rapidamente il prodotto rendendolo migliore di quanto non lo sia ora.

Speriamo in un futuro di collaborazione e di grandi successi d’altronde se Google è quello che è oggi lo deve in larga parte alla comunità Open…..don’t be evil.

Ciao a tutti.