Il kernel ha messo su chili

[birg81]

Anch'io avevo letto la notizia qualche giorno fa... Ma sinceramente non me n'è fregato nulla. Vorrei sapere
1) come hanno misurato il 12%
2) quanto influisce sui programmi che uso

Credo che la metrica usata sia ancora un mistero

[Mario Vanoni]

Quindi come secondo voi si può snellire un pò il Kernel?!
Forse non implementando più supporti obsoleti e compromettendo l'alta usabilità del kernel?!.
Non vorrei interpretare male le cifre ma indubbiamente un rischio che tutto ciò possa inevitabilmente portare ad un collo di bottiglia c'è, voi non credete?!

Scaricati i sorgenti, disattiva tutto ciò che non ti serve e ricompila in modo da ottenere un kernel piccolo, snello ed efficiente.

Solo Linux e pochi altri kernel ti offrono questa eccezionale possibilità; perché non sfruttarla?

Esempio pratico, riproducibile!

Slackware 12.2 originale PJV:
/boot/vmlinuz-huge-smp-2.6.27.7-smp 4727664 bytes
du -bs /lib/modules/2.6.27.7-smp 62277104 bytes

Slackware 12.2 mio, aggioranto,
kernel minimalista, statico, quindi 0 (ZERO) moduli,
l'ultima versione, patchata con Con Kolivas, nome 2.6.31-bfs211,
mi da un /boot/bzImage di --------------> 3258528 bytes

[Blallo]

mario mi hai tolto le parole di bocca
da ciò dovrebbe imparare chi impacchetta i kernel generici, cercando di rendere meno pesante la loro immagine
è una visione forse un po' utopistica, ma perdere qualche secondo di boot per caricare qualche modulo in più al fine di non piazzare molta roba in un vmlinuz enorme e (ancora peggio) in un initrd, fa guadagnare un po in prestazioni credo
ovviamente parlo di kernel generici, chi se lo ricompila si piazza tutto statico ("tutto", solo ciò che serve) e finisce là

[conraid]

mario mi hai tolto le parole di bocca
da ciò dovrebbe imparare chi impacchetta i kernel generici, cercando di rendere meno pesante la loro immagine
è una visione forse un po' utopistica, ma perdere qualche secondo di boot per caricare qualche modulo in più al fine di non piazzare molta roba in un vmlinuz enorme e (ancora peggio) in un initrd, fa guadagnare un po in prestazioni credo
ovviamente parlo di kernel generici, chi se lo ricompila si piazza tutto statico ("tutto", solo ciò che serve) e finisce là

non torniamo in polemiche di una vita, ma perché dovrei compilarmi tutto statico? se voglio compilare i moduli per possibili filesystem che userò raramente (fat, iso, udf, etc..), moduli di periferiche usb che uso raramente (webcam, joystick, e tante altre), se voglio compilare ipv6 per fare prove ogni tanto, e potrei continuare con molte cose, perché diavolo dovrei includerli staticamente nel kernel?

[Blallo]

Lo statico era solo un esempio, ovviamente ognuno del suo kernel ricompilato fa ciò che vuole...
io pure tengo a moduli webcam & affini vari

[conraid]

Lo statico era solo un esempio, ovviamente ognuno del suo kernel ricompilato fa ciò che vuole...
io pure tengo a moduli webcam & affini vari

ancora "peggio" per una distribuzione, molto meglio molti moduli da caricare random che un kernel enorme, considerando che deve girare nel maggior numero di macchine possibile, poi boh...

[matzu]

Even so, it begs a question: will Linux become more like Windows as it becomes even more successful?

Slackware 13 ha quattro kernel precompilati disponibili, dove huge-smp pesa quasi il doppio di generic-smp, ed è consigliato solo per installazione/emergenza (è scritto anche nel wiki di slacky). Se ne hai voglia puoi ricompilarlo, e la velocità sarà proporzionale alla complessità del sistema che vuoi far funzionare.

Linux è cicciotto nei sorgenti perché è come un'auto nuova offerta con tre o quattro differenti set di gomme e cerchi in lega. Ma non andrai in giro con tutte le combinazioni insieme, contemporaneamente.

Nell'installare Windows (ma sono fermo a XP SP0) non mi è mai capitato di poter scegliere un kernel, e meno ancora di poter ricompilarlo (dovrebbe rilasciare i sorgenti). Windows è schiavo del suo timore che tu possa impadronirtene, e la sua struttura è conseguenza dei suoi incubi. Nasce ciccione e ciccione rimane, mentre invece non c'è nessuno che usa Linux con tutte le opzioni disponibili compilate staticamente.

[Mario Vanoni]

Lo statico era solo un esempio, ovviamente ognuno del suo kernel ricompilato fa ciò che vuole...
io pure tengo a moduli webcam & affini vari

ancora "peggio" per una distribuzione, molto meglio molti moduli da caricare random che un kernel enorme, considerando che deve girare nel maggior numero di macchine possibile, poi boh...

Corrado guarda il titolo della thread, leggi l'articolo tradotto in PI o l'originale inglese.

Io dimostro che l'ultimo kernel Linux mantiene la sua linea snella ed elegante.
2.6.31-bfs11 statico aumenta di 8608 bytes in confronto al 2.6.31 statico originale.

Che per ragioni varie distro/utenti lo ingrassino non e` un problema di Linus.

[Blallo]

ancora "peggio" per una distribuzione, molto meglio molti moduli da caricare random che un kernel enorme, considerando che deve girare nel maggior numero di macchine possibile, poi boh...

era esattamente quello che volevo dire (scusate se a volte sono poco chiaro ma sono una ciofeca deambulante quanto a declamatore di spiegazioni)

[conraid]

Lo statico era solo un esempio, ovviamente ognuno del suo kernel ricompilato fa ciò che vuole...
io pure tengo a moduli webcam & affini vari

ancora "peggio" per una distribuzione, molto meglio molti moduli da caricare random che un kernel enorme, considerando che deve girare nel maggior numero di macchine possibile, poi boh...

Corrado guarda il titolo della thread, leggi l'articolo tradotto in PI o l'originale inglese.

Io dimostro che l'ultimo kernel Linux mantiene la sua linea snella ed elegante.
2.6.31-bfs11 statico aumenta di 8608 bytes in confronto al 2.6.31 statico originale.

Che per ragioni varie distro/utenti lo ingrassino non e` un problema di Linus.

Guarda che secondo me l'articolo dice esattamente il contrario. Cioè che il kernel ormai è un progetto grande indipendentemente da come viene compilato.
Tu una distribuzione come la faresti? con un kernel in cui funziona solo l'essenziale, senza moduli e che va solo nella tua macchina?
boh... mi sembra di venire da un altro pianeta

[birg81]

Quello che forse voleva essere lo scopo del post (o almeno quelle che erano le miei intenzioni) era non di aver un kernel snello ma il sorgente del kernel più snello...
Permettetemi un esempio:

E' come un ufficio che deve svolgere una certo numero di commissioni per mandar avanti l'azienda.
Lo svolgere le commissioni rappresenta il compilare il kernel.
Ma a monte ci sono i fogli di carta sulle quali vengono scritte le commissioni che l'ufficio deve svolgere (i sorgenti del kernel) che vengono lasciati in maniera caotica nell'ufficio.
Si tenga presente che se l'impiegato dell'ufficio non capisce la specifica della richiesta della commissione da svolgere quel foglio di carta rappresenta solo un inutile cartaccia che aumenta il caos nell'ufficio.
Ma se il ritmo con le quali arrivano commissioni è maggiore del tempo che impiega l'anziano impiegato a smaltire le commissioni si accumuleranno cartaccie e cartaccie; si finirà che non sarà possibile entrare nemmeno nell'ufficio di conseguenza non si saprà più quale commissioni svolgere.

Questa visione catastrofica sta a sottolineare che c'è il rischio, (reale e forse nemmeno troppo lontano) che l'aumento delle linee di codice porti ad un sorgente di un kernel poco sinergico tra le sue parti...
L'entropia del codice aumentando caoticamente di relase in relase porterà a breve ad un kernel che fa male il suo lavoro.
Quindi ristabilendo un attimo le linee guida del post, che non vogliono risollevare vecchie polemiche su kernel modulari o statici ma semplicemente su quello che possa diventare il kernel se i suoi sorgenti procedono con il ritmo di crescita senza un ordine / un organizzazione interna più adeguata / più sinergica.
Tutto ciò è un inevitabile conseguenza che segue quando progetti di grande portata si espandono.

[Toni]

scusate , ma se si è arrivati al punto di contare i byte credo non si sia capito nulla della questione.

Quello che forse voleva essere lo scopo del post (o almeno quelle che erano le miei intenzioni) era non di aver un kernel snello ma il sorgente del kernel più snello...
E' come un ufficio che deve svolgere una certo numero di commissioni per mandar avanti l'azienda.
Lo svolgere le commissioni rappresenta il compilare il kernel.
Ma a monte ci sono i fogli di carta sulle quali vengono scritte le commissioni che l'ufficio deve svolgere (i sorgenti del kernel) che vengono lasciati in maniera caotica nell'ufficio.
Si tenga presente che se l'impiegato dell'ufficio non capisce la specifica della richiesta della commissione da svolgere quel foglio di carta rappresenta solo un inutile cartaccia che aumenta il caos nell'ufficio.
Ma se il ritmo con le quali arrivano commissioni è maggiore del tempo che impiega l'anziano impiegato a smaltire le commissioni si accumuleranno cartaccie e cartaccie; si finirà che non sarà possibile entrare nemmeno nell'ufficio di conseguenza non si saprà più quale commissioni svolgere.
Questa visione catastrofica sta a sottolineare che c'è il rischio, (reale e forse nemmeno troppo lontano) che l'aumento delle linee di codice porti ad un sorgente di un kernel poco sinergico tra le sue parti...
L'entropia del codice aumentando caoticamente di relase in relase porterà a breve ad un kernel che fa male il suo lavoro.
Quindi ristabilendo un attimo le linee guida del post, che non vogliono risollevare vecchie polemiche su kernel modulari o statici ma semplicemente su quello che possa diventare il kernel se i suoi sorgenti procedono con il ritmo di crescita senza un ordine / un organizzazione interna più adeguata / più sinergica.

ma tu cosa ti fumi???

UPDATE:

ci sei o ci fai ? questo si è un dilemma

[neongen]

il punto non credo sia quali moduli compilare o meno, nè se compilarli staticamente o no;
il problema è che linux è fatto da tanto codice, e questo codice, proprio per la dimensione raggiunta, ha ormai bisogno di un pò d'ordine e un po di pulizia generale poiché è piuttosto probabile che moduli diversi si ritrovino blocchi di codice che facciano le stesse cose, che non facciano niente o peggio ancora che abbiano gli stessi bug nascosti.

[Mario Vanoni]

Che per ragioni varie distro/utenti lo ingrassino non e` un problema di Linus.

Guarda che secondo me l'articolo dice esattamente il contrario. Cioè che il kernel ormai è un progetto grande indipendentemente da come viene compilato.
Tu una distribuzione come la faresti? con un kernel in cui funziona solo l'essenziale, senza moduli e che va solo nella tua macchina?
boh... mi sembra di venire da un altro pianeta

Corrado vedi anche il punto di vista non distro,
esperienza mia di decenni, si compra una macchina nuova,
da ammortizzare mettiamo in 5 anni,
molto improbabile che la HW campi se non per difetto.

In questo caso mi prendo il tempo e compilo un kernel specifico,
statico, quindi senza moduli, con unicamente la HW presente.

- kernel molto piccolo e veloce
- nessuno puo` caricare un module abusivo

[birg81]

il punto non credo sia quali moduli compilare o meno, nè se compilarli staticamente o no;
il problema è che linux è fatto da tanto codice, e questo codice, proprio per la dimensione raggiunta, ha ormai bisogno di un pò d'ordine e un po di pulizia generale poiché è piuttosto probabile che moduli diversi si ritrovino blocchi di codice che facciano le stesse cose, che non facciano niente o peggio ancora che abbiano gli stessi bug nascosti.

Esattamente quello che ho detto pure io ma con milioni di parole in più