Il kernel ha messo su chili

[Mario Vanoni]

Il kernel Linux e` molto ottimizzabile,
fregate sono le distro per tutte le macchine esistenti!

faremo la mvware, ok?
installa gentoo allora se la pensi così, non trovi?
tanto nelle altre, compresa Slackware, anche il software sotto è compilato per tutte le macchine, tanto che è ottimizzato per 486

La differenza i486 o i686 non pesa sul kernel,
e` il numero di voci che si mettono.

Sai che chip ethernet, sensors ecc. ecc. usi,
compila unicamente quelli, [ ] per gli altri.
Lo so, lavoro, ma ne vale la pena, poi .config si copia ...

Se non hai chip "experimental" togli i moduli, quindi statico.

Se sai che i prossimi 12 mesi non aggiungi HW,
o non vai ad esperimentare con FS mai usati. stai sicuro.

Il vecchio "network" dopo il boot/login di Slackware e` un pregio!

[conraid]

Il kernel Linux e` molto ottimizzabile,
fregate sono le distro per tutte le macchine esistenti!

faremo la mvware, ok?
installa gentoo allora se la pensi così, non trovi?
tanto nelle altre, compresa Slackware, anche il software sotto è compilato per tutte le macchine, tanto che è ottimizzato per 486

La differenza i486 o i686 non pesa sul kernel,
e` il numero di voci che si mettono.

Sai che chip ethernet, sensors ecc. ecc. usi,
compila unicamente quelli, [ ] per gli altri.
Lo so, lavoro, ma ne vale la pena, poi .config si copia ...

Se non hai chip "experimental" togli i moduli, quindi statico.

Se sai che i prossimi 12 mesi non aggiungi HW,
o non vai ad esperimentare con FS mai usati. stai sicuro.

Il vecchio "network" dopo il boot/login di Slackware e` un pregio!

come sempre si parla di una cosa e tu parli di altro.
Come fa una distribuzione a fare un kernel così?
e ripeto "perché compilare staticamente cose (filesystem, periferiche, etc..) che so che mi possono servire ma una tantum"?
rispondi a questo senza usare le solite frasi fatte per favore

[Mario Vanoni]

come sempre si parla di una cosa e tu parli di altro.
Come fa una distribuzione a fare un kernel così?
e ripeto "perché compilare staticamente cose (filesystem, periferiche, etc..) che so che mi possono servire ma una tantum"?
rispondi a questo senza usare le solite frasi fatte per favore

Distro != systema in una azienda pensato che duri 5 anni invariato.

Quindi per te come utente privato va bene cosi` come sono le distro.

Ma se metto una macchina in ditta per i prossimi anni,
non permetto di caricare moduli,
e se nel tempo una HW cambia ricompilo il kernel.

[conraid]

come sempre si parla di una cosa e tu parli di altro.
Come fa una distribuzione a fare un kernel così?
e ripeto "perché compilare staticamente cose (filesystem, periferiche, etc..) che so che mi possono servire ma una tantum"?
rispondi a questo senza usare le solite frasi fatte per favore

Distro != systema in una azienda pensato che duri 5 anni invariato.

Quindi per te come utente privato va bene cosi` come sono le distro.

Ma se metto una macchina in ditta per i prossimi anni,
non permetto di caricare moduli,
e se nel tempo una HW cambia ricompilo il kernel.

Avevo detto senza le solite frasi fatte

Ma anche se fosse così, cosa c'entra con tutto il discorso?
Linus dovrebbe fare il kernel solo per quella macchina?
No, dovrà supportare tutte le possibili macchine, e tutte le possibili periferiche, e così via. Che tu compili staticamente, modularmente, ottimizzi o non ottimizzi. E di questo si lamentava Linus. Del fatto che forse, vista la crescita del codice, una organizzazione diversa al giorno d'oggi sarebbe meglio, ma è impossibile visto il punto a cui è arrivato il kernel.

Se poi vogliamo andare fuori tema e tornare al discorso dell'utente con un singolo server in una ditta, permetterai che la situazione da te descritta è marginale vero? Un consulente per una ditta con un server? Un consulente solitamente gestisce varie ditte, una ditta che si permette know-how interno ha molti più server.
ma siamo tremendamente off-topic

[Blallo]

boh, un kernel generic è quasi tutto modulare, appesantisce al massimo un poco il boot (cosa risolvibilissima con l'avvio parallelizzato ove possibile)...il vero rallentamento lo fanno i programmi inutili all'avvio e le "migliaia" di patch che aggiungono gli sviluppatori...
probabilmente il vero danno di cui risente linus ora è la difficoltà nel gestire questa enorme mole di codice, ma penso finisca lì...
OPPURE unica soluzione: [joke mode]riscrivere tutto impostandolo come microkernel[/joke mode]

[raffaele181188]

Ma il punto è che non c'è una soluzione perchè non c'è un problema. Suvvia, stiamo parlando di una frasetta di Linus
Pure riscrivendolo da capo si arriverà di certo ad un punto in cui si superano di nuovo le mille righe di codice, o no? Dov'è il problema? Piuttosto, magari una bella documentazione un filino più moderna non guasterebbe...
Programmi inutili all'avvio non mi pare che ce ne siano nemmeno nelle distro più popolari
E le patch evidentemente servono, altrimenti non verrebbero sviluppate, non credi?
Anzi, pur volendo considerare solo il tempo di boot delle varie distribuzioni, installati [Arch|Mandriva|Ubuntu|SuSE|Fedora|Gentoo|...] e Slackware e poi, cronometro alla mano, vedi quanto ci mettono. Scommetto che la tua espressione sarà tipo

[Blallo]

potrei confrontare solo distro con pari sistema di boot...
Slack usa gli script BSD-like per il boot, quindi al massimo la confronto con un BSD (che ha il kernel meglio scritto e organizzato a detta di molti)
Ubuntu posso confrontarla con altri perchè si basa su sysv-init, e ovviamente potremmo anche avere tempi inferiori di Slack (a parità di servizi avviati però)

[shark1500]

Tornando al punto iniziale, ho trovato il link del video della conferenza.

Purtroppo non sono riuscito a trovare i vari video ti tutto il linuxcon, se magari qualuno li trova per favore li posti (altri argomenti sono molto interessanti)

[shark1500]

Ok, il punto di questa domanda e` al minuto 29.40 (piu` o meno).
Innanzitutto mi sembrava di ricordare di aver letto Novell, invece e` l'intel che ha fatto il test, e ha fatto un test su un database, quindi il problema potrebbe stare o nello scheduler del disco o nel fs o in qualcosa del genere.

Non hanno fatto comunque il nome del test (non so perche`).

[anycolouryoulike]

C'è da segnalare comunque il fatto che gli ultimi kernel hanno introdotto delle novità piuttosto importanti in termini di prestazioni. Il 2.6.30 introduce il "fast boot" della Intel per velocizzare notevolmente il boot attraverso l'inizializzazione in parallelo delle periferiche (e tutti sappiamo che, effettivamente, il boot sta diventando sempre più veloce).

Qualcuno mi sa dire dove si trova questa opzione?
Grazie