Dopo alcune regressioni inaspettate e un discreto numero di release candidate, Linus Torvalds ha effettuato il commit che sancisce il rilascio della nuova versione del kernel Linux. Il ramo 3.x è stato oggetto di molte polemiche e critiche, probabilmente anche per il carico di novità che porta con sé. Di sicuro è stato fatto molto lavoro e soprattutto molto lavoro “sporco”.
Buona parte degli interventi per questa versione occupano l’area dei driver per chip grafici. Importanti miglioramenti sono stati fatti per Intel Ivy Bridge, Cedrar Tail e la generazione di microcodice FUC nel driver Nouveau. Sul fronte delle architetture, Linux 3.1 dà il benvenuto alla nuova arrivata OpenRISC. Inoltre anche il settore wireless registra l’introduzione del supporto per Near Field Communication: un protocollo per trasmissioni wireless a corte distanze.
Novità di media entità per quanto riguarda i file system: EXT3 avrà l’opzione barrier attivata di default, quindi più affidabilità e meno prestazioni. Andando più a fondo è possibile trovare ottimizzazioni anche per lo SLAB Allocator al fine di migliorarne la velocità. Per i più attenti al lato ludico c’è il supporto al controller Wii. L’elenco completo è disponibile qui.
Sta aumentando il carico di lavoro riguardante gli aspetti multimediali per gli sviluppatori del kernel. Linus Torvalds ha espresso le sue preoccupazioni per l’allungamento del ciclo di sviluppo per rilasci stabili. L’enorme lavoro fatto per il supporto delle GPU è solo l’inizio e molti interventi sono già schedulati per la prossima versione. Che, come indicato da Torvalds, potrebbe essere più voluminosa della 3.1.
Via | Phoronix
Ultimamente lo sviluppo del Kernel Linux, almeno per gli utenti dei dispositivi portatili, non sembra proprio andare per il verso giusto. Nonostante gli sforzi profusi a partire dalla versione 2.6.38, detta anche versione delle meraviglie poichè integrava una patch in grado di incrementare sensibilmente la reattività del sistema, il progresso sembra essersi trasformato in una parziale ma costante involuzione per quanto riguarda i consumi di potenza.
Già dalla versione 2.6.38-39 e 3.0 i segnali erano chiari: il fabbisogno di potenza è cresciuto del 24% fino a raggiungere punte del 76% con Notebook che montano Intel Sandy Bridge. Secondo il test svolto da Phoronix il kernel 2.6.38 aveva un consumo medio di 13.2 Watt mentre già con la 2.6.39 il consumo ammontava a 13.9 Watt, non paghi del risultato, si raggiungono i 22.8 Watt con Linux 3.1.
Il problema è piuttosto controverso in quanto molti utenti Ubuntu 11.04 e Fedora 15 e di altre distribuzioni recenti ne sono affetti. Un altro test invece, dimostra che utilizzando un processore più obsoleto rispetto all’Intel Sandy Bridge come Intel Core i7 720Q, nelle versioni 3.0 e 3.1 non si riscontra la cosiddetta regressione di potenza.
Personalmente sono rimasto sorpreso da questa tendenza, il kernel Linux è ovviamente un progetto ad elevata complessità, ma dopo la patch delle meraviglie creata dallo sviluppatore Mike Galbraithnella 2.6.38, era sufficiente disabilitare ASPM per tornare ai consumi di potenza precedenti, ora sembra che il bug sia più insidioso e persistente.
Via | Phoronix
Recentemente è stata scoperta e corretta una vulnerabilità che sfruttando la modalità per la compatibilità con gli eseguibili a 32bit permetteva di elevarsi a root.
Per esempio, un attaccante dopo aver avuto accesso utente attraverso un qualsiasi altro bug poteva facilmente diventare root sul sistema attaccato. Un problema nel codice di emulazione delle chiamate a 32bit.
La nota dolente è che questo bug era già stato corretto nel lontano 2007, ma nel corso del 2008 la patch per qualche motivo era stata inavvertitamente rimossa reintroducendo la vulnerabilità. Una brutta figura che può capitare in progetti così grossi com’è anche successo due anni fa con la vicenda SSH/Debian.
Se avete un sistema che non ha bisogno dell’emulazione 32bit potete disabilitarla con il seguente comando:
echo ':32bits:M:0:x7fELFx01::/bin/echo:' > /proc/sys/fs/binfmt_misc/register
Via | HOnline
Android potrebbe tornare nel kernel a patto che Google rispetti 3 condizioni. È quanto ha sostenuto Jeremy Bottomley, maintainer del sotto-sistema SCSI di Linux, all’OSCON 2010. L’ultima parola spetta dunque a Mountain View, ma le parti stanno già dialogando da mesi. L’Odissea di Android nel kernel non finirà molto facilmente, nonostante Google abbia tutto l’interesse in un ritorno all’inclusione su Linux.
La querelle verte anzitutto sulle modifiche apportate a PMQoS, necessarie all’Open Handset Alliance per migliorare il supporto ai dispositivi mobili. Chris Di Bona sostiene che Google sia tuttora «in attesa» del responso dei maintainer del kernel per un ritorno di Android già da Linux 2.6.34. Il fatto che le modifiche al codice non siano entrate nella prima release candidate fa presagire uno slittamento.
Lo sviluppo del kernel successivo, cioè il 2.6.35, è già arrivato alla RC6 e non c’è alcuna traccia di Android. La nota positiva è che rappresentanti d’ambo le parti hanno confermato l’esistenza di un fitto dialogo all’OSCON 2010, ma possiamo escludere novità rilevanti prima di Linux 2.6.36. Oltre a PMQoS, Google è chiamata a rispettare il ciclo di sviluppo del kernel e a rivedere il codice del suspend lock.
Via | The Register
Google, attraverso Chris DiBona, ha annunciato durante il Linux Collaboration Summit che assumerà degli sviluppatori Android per portare le patch di nuovo nel kernel Linux.
Al momento le persone non sono ancora state trovate, ma si tratta di un ottimo atteggiamento da parte dell’azienda dopo la cancellazione di Android dall’albero del kernel.
DiBona ha anche affermato che l’azienda non ha brillato e che si poteva fare di più, ma anche che il team di sviluppo è sottoposto a molte pressioni per migliorare i prodotti commerciali.
Continua a leggere: Google assumerà nuovi sviluppatori per Android
Gli sviluppatori del kernel linux stanno diventando troppo vecchi?
È questa la domanda che si stano ponendo qualcuno. Andrew Morton vede che alcuni sviluppatori di vecchia data non hanno più l’energia e lo spirito di un tempo e qualche volta cercano di scansare alcuni compiti su cui si sarebbero buttati a capofitto una decina di anni fa.
Gli sviluppatori principali diventando più esperti ed altamente specializzati riescono ad integrare codice più complesso all’interno del kernel e questo tiene lontano le giovani leve che fanno molta più fatica di un tempo per capire come funziona un determinato sottosistema.
La soluzione secondo Morton sta in una migliore documentazione del codice. Una buona integrazione fra chi conoscere meglio il kernel e le nuove reclute è fondamentale per il futuro del progetto.
Via | LinuxPlanet
Dopo il poco successo riscontrato dall’ultimo kernel (il 2.6.33), che come abbiamo scritto secondo alcuni test sarebbe per diversi aspetti molto meno performante dei due precedenti, Linus Torvalds ha annunciato la prima release candidate di quello nuovo, che contiene già 400 mila righe di codice in più.
Una tonnellata di cambi, annuncia Linus, con circa la metà relativa ai driver. Un 5% riguarda la nuova subdirectory sound e un 10% i firmware. Il resto è diviso fra update e altre cose, fra cui il supporto al nuovo filesystem logfs. In termini di numeri, sono 6.500 i file cambiati e 175 mila le linee di codice cancellate.
Sean Michael Kerner ha però notato che gli 850 developers che hanno contribuito a questa release sono decisamente meno dei 1.150 che finirono il kernel 2.6.30. E nel post che ha pubblicato sottolinea come di strano ci sia anche il fatto che il kernel 2.6.33 è stato rilasciato solo poche settimane fa, con non poche novità.
Foto | Pleeker

Quasi due anni fa il famoso hacker Con Kolivas smetteva di sviluppare le sue patch per lo scheduler di Linux.
Lo scorso anno aveva fatto ritorno con il nuovo scheduler BFS, Brain Fuck Scheduler, che ha delle buone prestazioni nonostante un design piuttosto semplice rispetto agli altri disponibili. Non ha intenzione di spingere per l’inclusione nel kernel, ma ha aggiornato il suo set di patch.
Patch che modifica alcune parti del kernel e che potete testare applicandola ad un kernel 2.6.33. Kolivas non riesce a stare lontano dal kernel programming? Lo scopriremo nei prossimi mesi.
Via | Phoronix
Una volta chi sviluppava sul kernel linux lo faceva per passione e solo nei ritagli del tempo libero.
Nel corso degli anni i principali sviluppatori sono stati tutti assunti da aziende per portare avanti a tempo pieno quello che già facevano. È grazie a queste persone che lo sviluppo negli ultimi anni ha continuato ad accelerare a ritmi impressionanti.
Durante il Linux.conf.au 2010, Jonathan Corbet, fondatore di LWN, ha mostrato un’analisi del codice entrato nel kernel linux fra il 24 dicembre 2008 ed il 10 gennaio 2010. Il risultato? Impressionante.
Continua a leggere: 75% del kernel Linux è scritto da programmatori stipendiati
Gli sviluppatori del kernel Linux hanno scoperto e corretto un bug di sicurezza che era presente da circa 8 anni.
La vulnerabilità era nascosta all’interno di una macro non corretta e consentiva di seguire codice all’indirizzo NULL. Il problema è presente in tutti i kernel 2.4.x e 2.6.x rilasciati dal 2001 ad oggi.
Fortunatamente la correzione del problema è già disponibile e non resta altro che aggiornare tutto il parco macchine, partendo da quelle in cui ci sono utenti che potrebbero essere maliziosi.
Via | OsNews
L’ultimo kernel ufficiale è il 2.6.29, ma il prossimo 2.6.30, giunto alla rc2, ha già preso la sua forma con le nuove patch.
Oltre all’aggiunta nel 2.6.29 di Btrfs e SquashFS, sono stati aggiunti due nuovi filesystem NILFS2 e Exofs a cui abbiamo già dedicato due articoli. Sono stati aggiornati i driver Alsa e di molte chipset WiFi.
Lo stack Wlan avrà un miglior supporto alle funzionalità di risparmio energetico. Il framework per la sicurezza TOMOYO è stato integrato, così come alcune patch per velocizzare la fase di boot del sistema.