View Full Version : Kernel vanilla vs Kernel patchato
mcardini
22-12-2007, 20:02
Preferite il kernel puro e crudo di Linus oppure quello patchato delle distro?
Preferite lasciare tutto come la distro ha fatto, oppure preferite ricompilare secondo le vostre esigenze?
Votate.
SalgerKlesk
22-12-2007, 20:11
con debian ricompilo sempre, con arch non ne ho mai sentito l'esigenza
Mi sono sempre trovato bene con i kernel ufficiali Debian, anche se ultimamente ho provato con soddisfazione il kernel con le patch zen.
di solito mi ricompilo il kernel vanilla alla debian-way....ultimamente l'ho anche patchato con il supporto CFS che sarà presente sul 2.6.24
mcardini
22-12-2007, 21:34
Io metto al 99% solo vanilla su qualunque distro, quello che Linus crea io non lo oso toccare :)
Sarei curioso di provare pero' quando sara' disponibile il nuovo fs di sun zfs, ne dicono in giro un gran bene di questo fs.
Io metto al 99% solo vanilla su qualunque distro, quello che Linus crea io non lo oso toccare :)
Sarei curioso di provare pero' quando sara' disponibile il nuovo fs di sun zfs, ne dicono in giro un gran bene di questo fs.
Anche ext4 mi interessa molto.
mcardini
23-12-2007, 11:09
Anche ext4 mi interessa molto.
Ext4 dovrebbe essere disponibile da fedora 9 e se non sbaglio gia' disponibile in sabayon linux.
Si, ma a quanto ne so per ora è poco più che un ext3, non sono ancora sfruttabili quelli che dovrebbero essere i vantaggi veri dell'ext4.
Ext4 dovrebbe essere disponibile da fedora 9 e se non sbaglio gia' disponibile in sabayon linux.
Non credo sia questione di distro ma di kernel.
Si, ma a quanto ne so per ora è poco più che un ext3, non sono ancora sfruttabili quelli che dovrebbero essere i vantaggi veri dell'ext4.
Al momento all'interno del kernel è presente l'ext4 ma in experimental e se ne sconsiglia ancora l'uso, se non per testarlo ovviamente...si il lavoro da fare su ext4 è ancora lungo, ma sembra promettere bene.
eclissi83
23-12-2007, 13:49
io solitamente uso una via di mezzo (ovviamente dipende dai contesti):
- server: usando centOS (che e' una red hat senza loghi) lascio il kernel cosi' com'e', considerando che e' una distro molto rimaneggiata.
- desktop: vanilla + le patch che mi servono (vedi le ck fino a poco fa, o le nitro2 od ancora le beyond)
in linea di massima, pero', preferisco i kernel vanilla (molte patch -> un bel po' di immondizia :P )
Sul desktop (Ubuntu) kernel di default, sui server (Gentoo e Debian) rigorosamente vanilla... quoto sul immondizia :D :p
darkbasic
23-12-2007, 14:25
Dipende dalla distro... su debian ad esempio è da un sacco di tempo che non uso un kernel ufficiale.
La patch per tuxONice qualcuno l'ha provata?
Che vantaggi ha rispetto l'hybernate di default del kernel vanilla (che uso e funziona bene)?
mcardini
23-12-2007, 22:00
Una cosa che non ho ancora capito....
Compilando il kernel spicificatamente per la propia cpu si guadagna oppure no?
Sulla carta non ci dovrebbe essere una gran differenza, specie con cpu moderne.
darkbasic
24-12-2007, 00:40
Cambia ben poco...
zephyr83
24-12-2007, 01:17
Una cosa che non ho ancora capito....
Compilando il kernel spicificatamente per la propia cpu si guadagna oppure no?
Sulla carta non ci dovrebbe essere una gran differenza, specie con cpu moderne.
compilare il kernel per il proprio procio no.....ma per il proprio hardware si! se selezioni solo quello che ti serve veramente e ottini un kernel più leggero e pulito sicuramente in avvio del sistema guadagni abbastanza!
Una cosa che non ho ancora capito....
Compilando il kernel spicificatamente per la propia cpu si guadagna oppure no?
Sulla carta non ci dovrebbe essere una gran differenza, specie con cpu moderne.
Direi che è più utile per far riconoscere il maggior quantitativo hardware presente nella propria macchina ed eliminare tutto ciò che non serve.
L'aumento di prestazioni rispetto al kernel "standard" è abbastanza minima.
I kernel debian secondo me funzionano benissimo così come sono, però io ho sempre ricompilato (anche ora che non ci sono più le patch ck :( ).
Vantaggi? Boot un po' più veloce eliminando l'initrd, si carica solo quello che serve, ottimizzazione per la propria CPU (margini impercettibili).
Svantaggi? Oltre al tempo, si perde qualcosa in compatibilità, e si deve ricompilare ogni volta che si aggiunge/sostituisce hardware.
bhà...
imho non vale la pena per uso desktop sbattersi per cambiare kernel ...
si, è vero si potrebbe avere un avvio leggermente più veloce... ma bhà ... non ne vale la pena.
a parte certi kernel ubuntu che son patchati in modo inverecondo in genere chi
distribuisce le distro fa un buon lavoro.
imho encomiabili i kernel mandriva: son sempre più stabili degli altri, ancHe se han il supporto ad una marea di hardware... un vero piccolo miracolo imho.
bhà...
imho non vale la pena per uso desktop sbattersi per cambiare kernel ...
si, è vero si potrebbe avere un avvio leggermente più veloce... ma bhà ... non ne vale la pena.
a parte certi kernel ubuntu che son patchati in modo inverecondo in genere chi
distribuisce le distro fa un buon lavoro.
imho encomiabili i kernel mandriva: son sempre più stabili degli altri, anceh se han il supoporto ad una marea di hardware... un vero piccolo miracolo imho.
Si forse sul desktop non serve, anche se personalmente lo faccio comunque, però magari su un portatile invece potrebbe essere utile.
E invece secondo me la ricompilazione del kernel ha senso (per quanto poco) solo su desktop.
Su un server critico nessuno si sognerebbe di modificare il kernel.
E invece secondo me la ricompilazione del kernel ha senso (per quanto poco) solo su desktop.
Su un server critico nessuno si sognerebbe di modificare il kernel.
no no su un server il kernel meglio non toccarlo, parlavo di portatile (anche se anche un portatile è un desktop).
E invece secondo me la ricompilazione del kernel ha senso (per quanto poco) solo su desktop.
Su un server critico nessuno si sognerebbe di modificare il kernel.
Personalmente non sono d'accordo, innanzitutto perchè ci sono alcune opzioni che possono essere variate per privilegiare l'interattività o la stabilità del codice, inoltre come diceva Henry Ford "Tutto quello che non c'è non si rompe!" (meno codice sta girando meno bug possono esserci), e in fine la ricompilazione spesso è l'unica via per adattarlo al meglio all'hardware, anche perchè alla fine se non non si mira a usare patch o impostazioni strambe, fare un kernel stabile e su misura per l'hardware che si possiede non è affatto difficile.
Personalmente non sono d'accordo, innanzitutto perchè ci sono alcune opzioni che possono essere variate per privilegiare l'interattività o la stabilità del codice, inoltre come diceva Henry Ford "Tutto quello che non c'è non si rompe!" (meno codice sta girando meno bug possono esserci), e in fine la ricompilazione spesso è l'unica via per adattarlo al meglio all'hardware, anche perchè alla fine se non non si mira a usare patch o impostazioni strambe, fare un kernel stabile e su misura per l'hardware che si possiede non è affatto difficile.
quoto, in alcuni casi un bel kernel monolitico è l'ideale.
Personalmente non sono d'accordo, innanzitutto perchè ci sono alcune opzioni che possono essere variate per privilegiare l'interattività o la stabilità del codice, inoltre come diceva Henry Ford "Tutto quello che non c'è non si rompe!" (meno codice sta girando meno bug possono esserci), e in fine la ricompilazione spesso è l'unica via per adattarlo al meglio all'hardware, anche perchè alla fine se non non si mira a usare patch o impostazioni strambe, fare un kernel stabile e su misura per l'hardware che si possiede non è affatto difficile.
Ma in realtà non è così per il kernel, mentre il tuo discorso è valido per i pacchetti non indispensabili (es: server Xorg e DM).
Debian Etch stable viene testata con quel kernel, e le applicazioni nei repo ufficiali girano con quel kernel ufficiale. Modificarlo, anche solo marginalmente, potrebbe portare a dei malfunzionamenti di alcune applicazioni.
zephyr83
24-12-2007, 12:56
Ma in realtà non è così per il kernel, mentre il tuo discorso è valido per i pacchetti non indispensabili (es: server Xorg e DM).
Debian Etch stable viene testata con quel kernel, e le applicazioni nei repo ufficiali girano con quel kernel ufficiale. Modificarlo, anche solo marginalmente, potrebbe portare a dei malfunzionamenti di alcune applicazioni.
ma modificarlo in che senso? patcharlo no ma ricompilarlo togliendo praticamente tutti i moduli e mettondo solo quello che serve davvero è sicuramente meglio anche in ambito server.
Ma in realtà non è così per il kernel, mentre il tuo discorso è valido per i pacchetti non indispensabili (es: server Xorg e DM).
Debian Etch stable viene testata con quel kernel, e le applicazioni nei repo ufficiali girano con quel kernel ufficiale. Modificarlo, anche solo marginalmente, potrebbe portare a dei malfunzionamenti di alcune applicazioni.
Ma valà? O_o
Guarda che le uniche "applicazioni" influenzate direttamente dal kernel sono i driver delle periferiche, che vengono ricompilati col Kernel, quindi a meno di errori che causino problemi di stabilità in generale, non vi è alcuna applicazione che possa avere problemi in seguito alla modifica e ricompilazione del kernel.
Piccolo esempio
Col kernel debian 2.6.22-2 il controller USB funziona perfettamente in Virtualbox.
Ho ricompilato il kernel 2.6.23-9, senza modificare le voci fondamentali relative al controller USB, e per far funzionare il controller USB in virtualbox ho dovuto aggiungere a fstab questa riga:
none /proc/bus/usb usbfs devgid=46,devmode=664 0 0
Ora in questo caso parliamo di debian testing e di un programma non presente nei repo ufficiali, però IMHO in un server che deve far girare dei servizi 24h al giorno, ricompilare un kernel è un rischio inutile.
Non è solo un discorso di driver delle periferiche. Abilitare alcune funzionalità disabilitate di default (es: Tickless) può portare a dei malfunzionamenti.
Piccolo esempio
Col kernel debian 2.6.22-2 il controller USB funziona perfettamente in Virtualbox.
Ho ricompilato il kernel 2.6.23-9, senza modificare le voci fondamentali relative al controller USB, e per far funzionare il controller USB in virtualbox ho dovuto aggiungere a fstab questa riga:
none /proc/bus/usb usbfs devgid=46,devmode=664 0 0
Ora in questo caso parliamo di debian testing e di un programma non presente nei repo ufficiali, però IMHO in un server che deve far girare dei servizi 24h al giorno, ricompilare un kernel è un rischio inutile.
Non è solo un discorso di driver delle periferiche. Abilitare alcune funzionalità disabilitate di default (es: Tickless) può portare a dei malfunzionamenti.
Ma stai proprio facendo un esempio sbagliato di principio: virtualbox usa proprio dei moduli per il kernel che quindi vanno ricompilati sul kernel stesso, tra l'altro in un server vero non usi virtualbox che è solo un giocattolino alla fine.
E comunque è ovvio che se ricompili il kernel devi sapere quello che fai, e può darsi che sia necessario fare qualche piccola modifica, ma dal momento in cui decidi di ricompilare ti informi prima e ti prepari a quello!
eclissi83
24-12-2007, 13:25
IMHO in un server che deve far girare dei servizi 24h al giorno, ricompilare un kernel è un rischio inutile.
non proprio: infatti e' buona norma fare un kernel totalmente monolitico sui server, in quanto in questo modo elimini qualsiasi tipo di rootkit di tipo lkm (codice malevolo che utilizza la modularita' del kernel per essere eseguito); inoltre con un kernel ricompilato ad hoc per una macchina server, puoi eliminare tutte cose superflue (e che quindi non utilizzererai mai su un server) che possono essere fonte di malfunzionamenti.
su un desktop la ragione per ricompilare il kernel puo' essere quella di avere un sistema piu' snello avendo solo quello che ti serve; se ti manca qualche driver, puoi anche compilarti il supporto come modulo e non dover nemmeno riavviare...
my 2 cents
Ma stai proprio facendo un esempio sbagliato di principio: virtualbox usa proprio dei moduli per il kernel che quindi vanno ricompilati sul kernel stesso, tra l'altro in un server vero non usi virtualbox che è solo un giocattolino alla fine.
E comunque è ovvio che se ricompili il kernel devi sapere quello che fai, e può darsi che sia necessario fare qualche piccola modifica, ma dal momento in cui decidi di ricompilare ti informi prima e ti prepari a quello!
Sì, hai ragione, il discorso si applica ai moduli ricompilati.
Comunque l'esempio che ti facevo sopra vale anche per Vmware.
Sì, hai ragione, il discorso si applica ai moduli ricompilati.
Comunque l'esempio che ti facevo sopra vale anche per Vmware.
Ma ricompilare il kernel non significa per forza usare l'ultimissima versione con chissà quali patch, su un server puoi banalmente ricompilare un kernel sul tuo hardware e i tuoi utilizzi partendo dai sorgenti ufficiali della distro, in questo caso tutto ciò che va sul kernel pacchettizzato va anche su quello che hai fatto tu, a meno di errori; problemi di compatibilità con in moduli vmware/vistualbox si hanno se metti su una versione diversa del kernel, che magari non è supporata da quei software :P
La patch per tuxONice qualcuno l'ha provata?
Che vantaggi ha rispetto l'hybernate di default del kernel vanilla (che uso e funziona bene)?
Nessuno ne sa nulla?
Nessuno ne sa nulla?
Che usa la compressione lzf, migliorando la velocità di ibernazione/risveglio, e permette di usare un'utility userspace per gestire lo splash screen, fermare il processo di ibernazione, scegliere se creare un file o usare lo swap :P
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.