Newsgroup: it.comp.os.linux.sys
Titolo: meditazione zen: ha ancora senso compilarsi i kernel ad hoc

ciao a tutti, parlando con altri amici sistemisti che conosco da 10 anni 
se non di + e che erano smanettoni come me ho scoperto che sono rimasto 
l'unico che si scarica i kernel da 
kernel.org
 e se li compila a manina 
mettendo solo quello che serve. sono rimasto io matusa? non ha + senso? 
sono pazzo?

 sono pazzo?
IMVHO, c'e' di meglio da fare nella vita che ricompilare il kernel da
sorgenti ogni tot tempo. Magari quando il kernel non era modulare poteva
anche avere senso.
Ovviamente questo e' un discorso generico, dipende sempre da quello che
devi fare.
$ du -sh /lib/modules/2.6.11-1-686/
41M     /lib/modules/2.6.11-1-686/
Ad esempio...
ciao
Luca
-- 
Luca Corti
PGP Key ID 1F38C091
BOFH excuse of the moment:
..disk or the processor is on fire.


siamo almeno in 2
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
New York!  Grande citta'!  Venite a visitarla: vi arresteranno!
		-- Michael Keaton

 
No, almeno in 3 :)


io lo faccio solo:
1) per il mio server al lavoro
2) per i terminali diskless
3) per i server dei clienti
4) per le mie macchine @home
per le macchine client dei clienti, il kernel standard andrà più che
bene.
tutto ovviamente sempre in combinazione con libc6-i686
ciao
gl :)

ecco io per esempio compilo solo i moduli che mi servono!

la cosa mi conforta!
io se devo essere super sincero uso ancora kerenl 2.4
sono ancora + pazzo?



Io sono passato al 2.6 solo nella speranza che qualcosa migliori e per
prepararmi al futuro, avendone avuto l'occasione (spostamento di farm e ne
ho approfittato per aggiornare tutto).
Il 2.4 a livello di prestazioni per i database è NETTAMENTE superiore al
2.6.
Tra l'altro, fighissimo, esistono dei bench comparativi (i link si trovano
su LKML) che dimostrano come il 2.6, con l'aumentare del numero di release,
diminuisca le prestazioni...
Max
(comunque anche io me lo compilo tutti a manina)

 (comunque anche io me lo compilo tutti a manina)
Tanto per rendere giustizia al 2.6 ci sono anche dei bench che comparano 
le prestazioni di rete e sono capovolti come risultati; cosě come puoi 
usare le libc con i thread posix solo col 2.6 (e qualche 2.4 patchato se 
non ricordo male)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Ustica, 27 giugno 1980.
- Oh, un aereo che cade...
- Comandante, esprima un desiderio.
		-- Ziche & Minoggio

se devo essere sincero, anche leggendo vari post sulle mailing list del 
kernel (tipo le sfuriate di alan cox sullo stack ide mi pare di ritorno 
dal suo anno sabbatico) a sensazione mi sembra che il 2.6 sia 
pasticciato e che il rigore solito dei vecchi kernel dove il codice era 
pulito e non incasinato sia stato almeno in parte abbandonato...
mi sbaglio?

 sono pazzo?
Anch'io lo faccio, per pura libidine :-)
-- 
Massimo Bacilieri AKA Crononauta 
ICQ:4005815

 sono pazzo?
Io, sui server, ricompilo SEMPRE il kernel, con solo i driver necessari
e i moduli completamente disabilitati (tranne dove assolutamente
necessario, solitamente a causa di qualche scheda coi driver esterni).
Sui client, ormai mi fido dei kernel pacchettizzati e
iper-modularizzati, che in effetti rendono molto piu' semplice la vita
con tutte le robe plug'n'play che ci sono oggi. :)
	facilitatamente,
	   Cthulhu
-- 
http://www.rlyeh.it/

 ecco io per esempio compilo solo i moduli che mi servono!
Intendevo che in casi in cui lo spazio occupato e' effettivamente un
problema un kernel modulare come quello di cui sopra e' impensabile.
In fondo la comodita' dei moduli e' quella di realizzare kernel generici
che supportino un vasto parco hardware (vedi distribuzioni desktop).
Se questo non ti interessa probabilmente non conviene nemmeno compilare
in modo modulare, ma includere direttamente nell'immagine del kernel.
Installare un kernel modulare e pacchettizzato non e' una questione di
pigrizia o "luserness", ma di comodita' di gestione. Quando cominci a
dover gestire un certo numero di macchine, mettersi a customizzare e poi
supportare un kernel ad hoc per ognuna diventa un lavoro lungo e
tedioso.
Personalmente mi sono sempre divertito a ricompilare i kernel, e ne
comprendo i vantaggi. Ma non per tutti gli usi.
ciao
-- 
Luca Corti
PGP Key ID 1F38C091
BOFH excuse of the moment:
cellular telephone interference

 processore non troppo recente.
ovviamente non compilo quello che non serve; per i terminali compilo
ottimizzato per il processore in questione (generalmente un transmeta
crusoe) e per avere il bootsplash; per le macchine a casa solo per
masochismo.
per quanto riguarda i server, avevo iniziato ad usare il kernel standard
di debian, ma dopo un po' di difficoltà in due-tre casi (non ricordo
nemmeno perché) son dovuto tornare al kernel ricompilato.
forse il kernel usato in sarge è ottimale, chi lo sa.
per ora continuo così.
ciao
gl :)

Davide Corrado wrote:

nel mio piccolo, oggettivamente non ho più ricompilato un kernel da 
anni... se quello che trovo pronto mi funziona a modo, mi accontento. 
Grazie al cielo non è più necessario risicare via qualche mega di ram di 
spazio disco al giorno d'oggi, e l'HW è supportato decentemente.
E' anche vero che ultimamente ho messo su soprattutto server abbastanza 
tranquilli, (niente roba da 50000 pageview al secondo, insomma ;-)) 
altrimenti forse ne avrei avuto bisogno ;-)
-- 
Fabrizio "Hermooz" Ermini

Davide Corrado ha scritto:

Beh guarda, io mi unisco in parte al coro, ho la tendenza ad usare 
kernel precompilati, specie da quando sul desktop sono passato da 
slackware a ubuntu
Per i server invece il discorso è differente, di solito customizzo per 
macchine che hanno bisogno di moduli particolari, e magari in posti 
delicati (tipo controller dei dischi) o per macchine che hanno bisogno 
di maggiori attenzioni, per il resto mi affido anche io a kernel già 
pronti....pigrizia? probabilmente, ma anche una discreta comodità di 
gestione.
Ciao
Ps
Cmq non ti reputo pazzo :-D se puoi fai bene

 Max

-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Filippo
Più che tenersi aggiornati io dire che bisogna imparare a quotare...
Detto questo l'aggiornamento a tutti i costi sui server in produzione 
non è cosa facile e nemmeno utile.

 sei e domani chissà.
Mi pare la parafrasi di una canzone dei Cure:
It won't take you long
To learn the new smile
You'll have to adapt
Or you'll be out of style
It's always the same
You're jumping someone else's train
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 sei e domani chissà.
Il 2.6 ha ancora diversi problemi con alcuni driver.
Io ogni tanto lo provo su un muletto per vedere se vale la pena metterlo
sui server, ma finora non mi ha mai convinto.
Sara` che ogni 3-4 versioni cambiano completamente qualcosa (l'ACPI,
l'IDE, la VM, gli scheduler, ...), ma ad oggi, su un server, il 2.4 e`
perfetto, del 2.6 non mi fido completamente.
Se puo' consolarti, ho messo il 2.4 sui server solo quando e` arrivato
alla 2.4.13 circa. Prima tenevo il 2.2.
Bye.

 Sui client, ormai mi fido dei kernel pacchettizzati e
Idem al 100%. :)


 sono pazzo?
io ho 2 tipi di clienti , quelli che montano debian e quelli che vogliono
rhel , ai primi ricompilo , ai secondi no per non andare fuori supporto.
questo x i server , sul mio portatile ricompilo per puro piacere
personale ;-)
-- 
- Pierino, dove vivevano gli antichi Galli?
- Negli antichi pollai!

 sono pazzo?
Non lo sei, ma dipende da "dove".
Se il target e` "server", un kernel statico no modules compilato by
hand, e` ancora una scelta da tenere fortemente in considerazione.
Per tutti gli altri usi, e in assenza di esigenze specifiche (tipo patch
per hw esoterico)... e` piu` la fatica che il gusto.
My 0.2 cents.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Christ died for our sins, so let's not disappoint him.

 sono pazzo?
Ti diro', io limito le compilazioni sulle macchine sperimentali in classe 
386/486/pentiumMmx e con poca ram/poche caratteristiche/poche periferiche 
perche' strizzare quel kb li' e quell'altro kb di ram la' fa comodo, ma 
altrimenti penso di aver di meglio da fare che mangiare km di menuconfig.
-- 
     Shalom, Grizzly - 
http://g-weblog.blogspot.com/
Linux user since 1994 - Teddybears collector since 1997
        Mnemonic Phone: ++39-[0 or 3]-931 702 385
Una mano lava se stessa
  - Asbesto

 ciao, f.
CINQUE!
-- 
La Mandriva, o Mandragola, serve a depietrificare gli utenti
che sono stati pietrificati da Windows.
Tuttavia, il suo uso prolungato può portare il PC a rallentamenti.
Si consiglia in questi casi un'ottima cura a base di Slackware.



beh... sembra quasi una caso ma proprio adesso siamo alla 2.6.13-rc1 ;)
--
Massimiliano
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Il fatto che non ci sia ancora un ramo 2.7 ti suggerisce nulla?
Che hanno cambiato lo schema di numerazione? :)
(vedi la serie 2.6.x.y)
Ciao
Teo

 beh... sembra quasi una caso ma proprio adesso siamo alla 2.6.13-rc1 ;)
Già, ma non c'è il ramo 2.7.


 (vedi la serie 2.6.x.y)
Non è la stessa cosa.
prima si aveva un ramo stabile, con le feature di quel ramo "frozen"
(oddio, anche nella 2.4 qualche trasgressione era stata fatta) ed uno
di sviluppo.
Adesso...boh.


 Adesso...boh.
Adesso siamo nelle mani di Cristo.
Vogliono levare devfs...
Sto seriamente prendendo in considerazione
questo 
http://www.debian.org/ports/kfreebsd-gnu/
e se funziona bene come server (come desktop me ne F8) ci migrerò sopra.
Max

 Vogliono levare devfs...
Mi sembra la cosa giusta da fare. Perché, tu usi devfs?
Ciao,
-- 
Daniele Orlandi

 e se funziona bene come server (come desktop me ne F8) ci migrerò sopra.
Beh, FreeBSD non è affatto male.
Il debian porting non l'ho mai provato, francamente.


 Mi sembra la cosa giusta da fare. Perché, tu usi devfs?
Tu device statici o udev? 


 Tu device statici o udev?
Uso udev
Ciao,
-- 
Daniele Orlandi

 Il fatto che non ci sia ancora un ramo 2.7 ti suggerisce nulla?
ho controllato.
la 2.5 e uscita quando e' uscita la 2.4.17
stessa situazione.
--
Massimiliano.


 Giร, ma non c'รจ il ramo 2.7.
mmhhh....
eheh:
ChangeLog-2.5.1 16-Dec-2001 16:01
ChangeLog-2.4.13 23-Oct-2001 22:28
non c'era nemmeno la 2.5.


 Mi sembra la cosa giusta da fare. Perché, tu usi devfs?
Io uso devfs su alcune applicazioni embedded.
Ma a parte il fatto che io lo usi o meno, è il fatto che in mezzo ad una
release teoricamente stable questi vanno a levare funzionalità.
Mi pare assolutamente nonsense.
E' cosa buona e giusta levarlo nel 2.7 o 2.8 se mai esisteranno.
Max

 E' cosa buona e giusta levarlo nel 2.7 o 2.8 se mai esisteranno.
Appunto, probabilmente non esisteranno col senso per cui sono esistiti in
precedenza.
Ciao,
-- 
Daniele Orlandi

 release teoricamente stable questi vanno a levare funzionalità.
Guarda che devfs e` deprecato,e da *parecchio* (dalla uscita del 2.6.0)

 Guarda che devfs e` deprecato,e da *parecchio* (dalla uscita del 2.6.0)
No.
Non ci siamo capiti.
Lo so benissimo che è deprecato da parecchio, ma il fatto che sia deprecato
non vuol dire che lo si può "eliminare" da una versione stabile del kernel
quando si vuole.
Rispondo anche a Daniele orlandi.
Lo so benissimo che hanno variato qualcosina nella numerazione.
Hanno inserito la 2.6.x.Y perchè, con tutti i troiai che facevano, era
necessaria una (o più) release in mezzo tra due, per risolvere,
nell'ordine:
1) le regression che sbucavano fuori DOPO la release (che già è male)
2) i problemi di sicurezza che sbucano fuori come funghi, nell'ultimo anno.
Sebbene il 2) sia causato soprattutto da nuovi toolZ per scovare sti buchi,
non tutti i problemi di sicurezza facevano parte del 2.4;
Per quanto riguarda l'1), il 2.6 è funestato di regression.
Non roba che non andava e che continua a non andare, bensì roba che andava
che poi smette di andare.
A prescindere da questo, ci sono stati diversi flames in merito
all'argomento su LKML, comprensivi anche di offese pesanti, per cui non
credo che sia questo il luogo dove continuare questi flames.
Riassumendo, c'è chi crede che il kernel devva svilupparsi velocemente per
stare dietro all'HW e a tutta la roba nuova, soprattutto per fare
concorrenza a windows.
C'è chi crede che debba essere prima di tutto stabile, un pò com'era una
volta.
Si capisce che un utente di desktop può essere felice (pure se il mio
synaptic del portatile non va bene come una volta).
Ma uno che manutiene tonnellate di server non credo che ne sia felice.
Col 2.4 li upgradavo da remoto, i kernel; col 2.6 ho paura.
Potrei anche collegarmi, visto che sono in tema, alle critiche di
$nonmiricordoilnome che ha fondato OpenBSD che dice che Linus è un
programmatore che fa schifo.
E' vero. Lui come programmatore fa cagare. 
E' un buon team leader, come ce ne sono tanti, che sa far andare avanti un
progetto come piace a lui (dopotutto l'ha creato lui).
Ma la qualità di un kernel linux VANILLA non è altrettanto SOLIDA di un
BSD, tutto questo IMHO.
Quello che io critico è che non esiste più un ciclo di release affidabile
come esisteva una volta.
Purtroppo per me il 2.4 è in feature freeze, ovvero "no more drivers".
Siccome non voglio trovarmi con server misti fra 2 anni, quando il 2.4 non
supporterà il nuovo HW, ho migrato tutto al 2.6. Ci ho rimesso in
prestazioni, ci sto perdendo in salute, ma spero che la situazione cambi.
debian GNU/kfreebsd è alle porte...
(debian non la mollerò MAI !!)
Max

 come esisteva una volta.
Come ho già avuto modo di dire su quel cesso di it.comp.os.dibattiti, è una
scelta nella quale io vedo buone possibilità di essere migliore, a patto
che non ci si aspetti di scaricare un vanilla e di trovare la stessa
stabilità del kernel di una distribuzione.
Poi, posso capire che tu, lavorando nell'embedded, sei tu che fai la
"distribuzione" e queste cose possono rivelarsi un PITA. Allora, magari,
attaccati ad un 2.6.x.y e non cambiare y se non strettamente
indispensabile, sapendo che ci *possono* essere dei cambiamenti e, meno
probabilmente, delle regressioni.
Ciao,
-- 
Daniele Orlandi

 debian GNU/kfreebsd č alle porte...
beh si .. .tieni comunque presente che, sempre debian, da una vita promette
un sistema con il kernel Mach. cmq ... stiamo a vedere
--
Massimiliano.


 del kernel quando si vuole.
Se sei un programmatore dovresti sapere cosa vuol dire deprecato.
Se non lo sei o non lo sai vuol dire molto semplicemente: "usalo a tuo
rischio e pericolo,c'e` $ANTANI che lo sostituisce,da un giorno all'altro
rischi di trovarti per culo per terra"
Quel giorno e` venuto con l'uscita del 2.6.0 && export ANTANI=udev
http://en.wikipedia.org/wiki/Deprecation

 Quel giorno e` venuto con l'uscita del 2.6.0 && export ANTANI=udev
Non si leva qualcosa pure se "deprecated" da un ramo in produzione.
Mi pare lineare, almeno secondo la mia filosofia quando uso linux.
Ma mi sa che stiamo scadendo in un flame, quindi magari è bene finirla qui!
Max

 qui!
Nessun flame da parte mia.
Solo non lamentarti se una parte *deprecata* dall'uscita della 2.6.0 viene
tolta...dovrebbero aspettare il 2.8?

 tolta...dovrebbero aspettare il 2.8?
Sul deprecato siamo daccordo.
Ma sia chiaro che il problema non è il "deprecato".
I problemi sono molti altri, il sistema di sviluppo che ha valenza di
"stabile" quando parli di 2.6.x.y con X fissa.
Il problema è presto detto.... Ragioniamo con esempi.
Io uso debian, nella woody il 2.4 di default era il 2.4.18 (che andava da
dio) e tutte le patch di aggiornamento le hanno applicate.
Detto questo, il kernel andava bene, ma è da oltre un anno e mezzo che non
era utilizzabile... mancava il supporto per un sacco di Hardware (leggasi,
ad esempio, il SATA) e altre patch in costante aggiornamento non erano
applicabili al 2.4.18 se non con "grossi" mastruzzamenti.
Questo per smentire chi dice di affidarsi al kernel di una distribuzione.
Ritengo che sia bene avere un bel vanilla, bello patchato, senza alcun
problema, aggiornato, senza buchi di sicurezza.
Ora... quando nel bel mezzo di un ramo stabile levi funzionalità, il danno
che rischi di fare è notevole.
E' pur vero che su un desktop il problema è minimale.
Ma su un server il problema è sentito.
Con la woody io non mi sarei mai permesso di avere un 2.4.18 seppur
patchato, perchè tutte le cose che ci aggiungo normalmente sarebbero state
vecchie (esempio: grsecurity).
Se linux (che non è unix) ha sempre funzionato bene sui server e da questi
ha tratto la sua fama, non vedo quale sia la necessità di sconvolgere
questa filosofia.
Ok, è proprio una filosofia, e proprio per definizione dovrebbe essere
intangibile. Peccato che in questo caso lo sia (leggevo oggi di
aggiornamenti del kernel che su alcuni server, se non gli passi acpi=off,
non bootano mentre con la versione precedente andavano lisci come l'olio).
A me questa cosa mette non poca paura.
Max

 Non concordiamo su cosa sia il significato di "stabile".
Credo che l'unica incomprensione è sul fatto che la stabilità è stata
spostata al quarto numero della versione.
Provo a mettermi nei panni di Torvalds. Lui ha più volte dichiarato di voler
avere dei cicli di release MOLTO più ravvicinati. Il problema è che
all'apertura del developement tree, si riversavano dentro montagne di patch
e poi ci volevano anni per riavere qualcosa di stabile.
Il trucchetto psicologico è stato quello di usare il quarto numero anche se
avrebbe potuto tranquillamente usare i primi due (ma senza il concetto di
developement tree).
Quindi, se non sbaglio ad interpretare, direi che ogni 2.6.x è da
considerare stable, e la stabilità è mantenuta tra un 2.6.x.y e un
2.6.x.y+1
Probabilmente un 2.7 nascerà quando ci sarà da implementare una feature
invasiva come lo stato, per esempio, il nuovo driver model.
Ciao,
-- 
Daniele Orlandi

 Questo per smentire chi dice di affidarsi al kernel di una distribuzione.
Continuo a dirlo. Se non vuoi fare lo smanettone è meglio che ti affidi al
kernel della tua distribuzione. Se Debian ha latitato nel fornire una
versione nuova della sua distribuzione per non so quanto tempo è un
problema di Debian (o comunque tuo che l'hai scelta).
Il bello dell'OSS è che comunque puoi decidere di metterci il vanilla e non
rimanere nella cacca ma devi mettere in conto che i problemi potranno
esserci e ci saranno e che stai usando un workaround.
Saranno probabilmente più contenuti rispetto al passaggio 2.4 => 2.6,
saranno semplicemente distribuiti su più versioni.
Ciao,
-- 
Daniele Orlandi

 kernel della tua distribuzione. Se Debian ha latitato nel fornire una
Ok.
Non siamo allineati (io di solito non faccio lo smanettone).
Tronchiamo qui tanto i metodi di sviluppo del kernel non dobbiamo deciderli
noi.

 come esisteva una volta.
A me pare che tu ti contraddica.
Il problema non è certo nelle capacità di coding di Torvalds.
Il problema è proprio nel coordinamento di tutti i kernel hacker.


 Il problema è proprio nel coordinamento di tutti i kernel hacker.
Per carità.
prima di tutto tendo a specificare che linus è un gran programmatore, non
oserei mai confrontarmi con lui.
Il riferimento era relativo ad altri developer di altri S.O. openSorc.
Linus ha scelto di fare il project manager, visto che il numero di hacker è
enorme e che probabilmente in ogni singolo settore hanno più conoscenze di
lui. Capisco le difficoltà nel gestire queste persone.
Ma la bontà di un "manager" si vede nelle scelte.
Mentre alcuni kernel di sapore BSD sono molto più lenti e molto più stabili
(forse anche troppo lenti) linux si è sempre contraddistinto per essere una
ottima via di mezzo tra le nuove features e la stabilità.
Quello che io non condivido è la filosofia che ora stanno seguendo (dettata
da linux) che vuole cicli di release molto rapidi, ovviamente a discapito
della stabilità.
Per il resto, credo che siamo abbastanza allineati come idee.
Max

 Per il resto, credo che siamo abbastanza allineati come idee.
]zac[
A parte il fatto che, dopo un anno che è stato dichiarata deprecata una
cosa, considero un regalo ogni giorno in cui quella cosa esiste ancora.