Nel nuovo kernel Linux 400 mila righe di codice in più

pubblicato: mercoledì 10 marzo 2010 da Silvio Gulizia

tux 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

(nessun voto)

8 commenti

Gallerie Correlate

Commenti dei lettori

(Inserisci un commento - Nascondi commenti anonimi)

devurandom
10 mar 2010 - 18:05 - #1

0 punti

c’e’ un commento interessante che spiega le “poche settimane”…

It is amazing to see so many contributers, but it isn’t really fair to say that much code was written in a few weeks.

People develop code outside of mainline, in staging, or other outside branches. There is a brief merge window where many of these branches are initially brought in (usually the -rc1) window. Then all the new code is tested and refined before the stable release.

From the moment the 2.6.33-rc1 release (mid December) until now, people have been working on new features they couldn’t merge until 2.6.34.
fedmor
11 mar 2010 - 01:14 - #2

0 punti

Secondo me i problemi di “obesità” del kernel sono sostanzialmente 2:

1) Il primo riguarda il supporto hardware… e c’è ben poco da fare. Voglio dire, rimuovere del tutto il supporto a componenti e periferiche obsolete sarebbe controproducente e non aggiungere codice per supportare quelle nuove è fuori discussione. La soluzione? Compilarlo da sé, ovviamente. Poco pratico per i newbie, ma mi domando se questi ultimi possano notare differenze prestazionali con un kernel ottimizzato.

2) Il secondo riguarda cifratura, compressione, filesystem, sicurezza e tutto il resto: forse qualcosa si potrebbe rimuovere davvero in quest’ambito… ad esempio riducendo i filesystem supportati (a volte scorrendone la lista mi domando se qualcuno utilizzi davvero certe funzioni), eliminando qualche algoritmo di cifratura meno performante e trovando una soluzione definitiva per la sicurezza. AppArmor (che non c’è, non ancora almeno)? SELinux? Altro? Ma tutti… no. Poi c’è la questione accounting.

Insomma, dibattiti se ne potrebbero aprire a josa e non è certo questa la sede più opportuna. Ma se coi driver c’è poco da fare, il margine su “tutto il resto” è ampio. I sostenitori di questo o, quel progetto però potrebbero restarci male. Uhm. Questione annosa, soluzione difficile. Per fortuna impegnando un po’ del proprio tempo si può rimuovere tutto ciò che non serve: non è mica Windows, per fortuna!
newbie
11 mar 2010 - 10:50 - #3

1 punto

Non sarebbe possibile fare in modo che durante l’installazione (in automatico) il kernel venga compilato includendo solo i driver realmete utilizzati?
L’utente “newbie” non dovrebbe fare altro che collegare/accendere tutte le periferiche…
s4
11 mar 2010 - 11:07 - #4

1 punto

@3 certo che si può si chiamano moduli i driver vengono caricati solo se richiesti dalla presenza di una periferica è il vantaggio d un kernel modulare
aska
11 mar 2010 - 14:10 - #5

0 punti

#3: ho pensato alla stessa cosa :D
newbie
11 mar 2010 - 14:24 - #6

0 punti

Ma se già è così dove sta il problema della pesantezza?
Qualche MB in piu’ si disco rigido?
mah...
11 mar 2010 - 15:06 - #7

0 punti

Che ignoranza desolante.

1. Cosa c’entra il numero dei driver o dei filesystem con le perplessità di Torvalds?
“Bloated and huge” non significa che il kernel ha troppo supporto hardware. Sapete leggere?
Il fatto è che tutti citano la frase generica senza includere il vero argomento tecnico (semplicemente perché nessuno sembra sapere cosa significhi), ovvero “icache footprint is scary”.

2. L’argomento del post è esilarante: TUTTE le merge window durano 2 settimane, quale sarebbe la novità? L’autore avrebbe paura che il codice incluso abbia 2 settimane di età? Il codice incluso può avere mesi o anni di età, è solo stato reputato sufficientemente stabile per l’inclusione ora.
Per questo la merge window dura così poco: ha senso solo per avere il tempo di raccogliere tutte le richieste di inclusione in mainline. L’autore del post originale e del post su ossblog farebbero meglio a informarsi sugli argomenti di cui intendono scrivere: queste cose le sa anche qualsiasi ragazzino che bazzica po’ su Linux.
Mickmouse
11 mar 2010 - 17:02 - #8

0 punti

#7: sottoscrivo ogni parola. Purtroppo non sembra ci sia verso di far capire all’autore del post che prima di esprimersi su qualsiasi cosa riguardi linux, si tratti di aspetti tecnici o legati alle fasi di rilascio, dovrebbe cercare di colmare la sua evidente e imbarazzante ignoranza in materia,. D’altra parte, basta davvero poco per per farsi un’idea basilare del modo in cui il kernel funziona e viene sviluppato. Fra i vari concetti dei quali si potrebbe venire a conoscenza, c’è anche quello di «modularità» già citato in qualche commento, o roba esoterica come «merge window»…
MAH…