Il kernel ha messo su chili

[luka64]

perchè non provare questi kernels?
http://www.fsfla.org/svnwiki/selibre/linux-libre/

[Dragon]

mah? secondo me andrebbe pensato un nuovo modello x la progettazine del kernel linux...
secondo voi come dovrebbe essere in futuro? ibrido? microkernel? e soprattutto scritto come? modulare a oggetti o con qualche altra nuova tecnica?

[metrofox]

Basta ricompilarsi il kernel e i problemi spariscono, ovviamente come compilare il kernel è scritto, bisogna solamente leggere... Riscrivere linux da capo(e riscriverlo significa che magari cambierà anche nome è impossibile), in caso dovesse essere riscritto verrà riscritto sempre in C(o almeno, spero).

[shark1500]

Non voglio entrare troppo nell'argomento, ma gli ultimi due kernel hanno fatto un passo in avanti non da poco riguardo la velocita` di varie cose.

Nel 2.6.32 ci sara` anche un miglioramento nello scheduler (che forse e` gia` in git) per i processi, che anche quello calava di prestazioni ogni release.

Ovvio che un kernel diventa piu` "ciccioso", ma bisogna capire cos'e` a far calare le prestazioni. Ovvio che se uno scrive un driver per l'ssd con i piedi allora le prestazioni per forza sono scarse, ma non e` colpa della cicciosita` del kernel.

Bisogna quindi vedere come sono stati fatti i controlli e capire cosa c'e` da migliorare e da sistemare. Il kernel per forza diventa piu` ciccioso, dato che vengono aggiunte sempre delle nuove cose.

Per farvi un esempio, ad ora per andare dal 2.6.31 alla versione in git ci sono ... 1648978 linee di diff (quindi di patch). Non ho scritto male: unmilioneseicentoquarant'ottoenovecentosettant'otto righe.

[Mario Vanoni]

Non voglio entrare troppo nell'argomento, ma gli ultimi due kernel hanno fatto un passo in avanti non da poco riguardo la velocita` di varie cose.

Nel 2.6.32 ci sara` anche un miglioramento nello scheduler (che forse e` gia` in git) per i processi, che anche quello calava di prestazioni ogni release.

Ovvio che un kernel diventa piu` "ciccioso", ma bisogna capire cos'e` a far calare le prestazioni. Ovvio che se uno scrive un driver per l'ssd con i piedi allora le prestazioni per forza sono scarse, ma non e` colpa della cicciosita` del kernel.

Bisogna quindi vedere come sono stati fatti i controlli e capire cosa c'e` da migliorare e da sistemare. Il kernel per forza diventa piu` ciccioso, dato che vengono aggiunte sempre delle nuove cose.

Per farvi un esempio, ad ora per andare dal 2.6.31 alla versione in git ci sono ... 1648978 linee di diff (quindi di patch). Non ho scritto male: unmilioneseicentoquarant'ottoenovecentosettant'otto righe.

Delle quali moltissime one-line corrections, semplici correzioni di stampa (typo in inglese).
Molte coinvolgono FS che nessuno usa e/o probabilmente mai usera`.
Altre HW nuove, che nessuno usa e/o probabilmente mai usera`.

Per esperienza mia, con HW anche modernizzata di brutto,
p.e. da P4/HT a Core 2 Dual, il kernel (statico) non cambia molto.
Il punto cruciale rimangono gli HD, sempre lumache.

[navajo]

Il punto cruciale rimangono gli HD, sempre lumache.

Purtroppo credo che ce li porteremo avanti ancora per un bel po di tempo.... ci vorranno alcuni anni prima di poter buttare via gli harddisk cosi come li conosciamo.
ps
spero di sbagliarmi.

[shark1500]

Delle quali moltissime one-line corrections, semplici correzioni di stampa (typo in inglese).

Non molte.

Molte coinvolgono FS che nessuno usa e/o probabilmente mai usera`.

Vero fino ad un certo punto. btrfs continua a svilupparsi, e anche nilfs2 promette molto bene (per memorie solide)

Altre HW nuove, che nessuno usa e/o probabilmente mai usera`.

Come sempre , pensare che nel 2.6.31 c'e` il supporto per l'usb3 che non e` ancora uscito.

Per esperienza mia, con HW anche modernizzata di brutto,
p.e. da P4/HT a Core 2 Dual, il kernel (statico) non cambia molto.

In che senso?

Il punto cruciale rimangono gli HD, sempre lumache.

Eh oh, io non ce ne ho cosi` tanto di soldi da permettermi un'ssd degna di nome (e che poi ha una vita finita)

[Vic Steele]

un'ssd degna di nome

Al giorno d'oggi neanche esistono, a mio avviso.

È difficile non concordare con navajo.
Comunque, se devo dire la mia, è un allarmismo che non vedo. Per quanto sia sicuro che le cose (e non è solo questione di scheduling) possano ancora essere gestite meglio, sono convinto che in futuro vedremo molte cose belle, e non perché già accertate sul piano hardware (per l'appunto, ssd capiente e duratura, e usb3 in primis).
Piccola parentesi: non sarà bello dormire sugli allori, ma potremmo ricordare che in generale il kernel Linux potrebbe essere ancora il più agile in circolazione, non sono sicuro al 100% sulla snellezza, ma tant'è...

[raffaele181188]

Ma posso sapere cosa c'entrano le prestazioni con i milioni di righe del kernel???
E posso sapere come hanno misurato questo 12%???
E posso sapere cosa ce ne importa visto che non è mai esistito nessun benchmark che abbia quantificato il guadagno di prestazioni dovuto alla ricompilazione del kernel??? I software che andrebbero velocizzati sono ben altri. Avete presente quello che fa il kernel, no?
E' assurdo sentire gente che parla di sistemi "più reattivi e scattanti" con kernel statici/modulari o con scheduler diversi senza uno straccio di numero, o che crede che disinstallando un programma la macchina sia più performante [-o<
Questo articolo riguarda solo gli sviluppatori del kernel, ovvero i programmatori, per i quali è sempre più difficile mettere le mani in un sorgente sempre più vasto. Ma è assolutamente normale che col passare del tempo le linee di codice aumentino, no? Facile fare gli hacker su mille righe e vantarsi di avere un prodotto superiore sotto tutti i profili... Escono nuovi dispositivi (quindi servono altri driver) o si scelgono nuove implementazioni e si lasciano le vecchie per retrocompatibilità: il sorgente cresce, ovvio. Qui sento parlare di reingegnerizzazione del kernel ma a che pro??? Quello che sta succedendo è normale, Linus si lamenta della "cicciosità" perchè è uno sviluppatore, a noi se pure i sorgenti del kernel fossero 1000 mila Gigabyte non ce ne fregherebbe un tubo! Tanto non si compila mica tutto Questo thread non ha senso

[johnpad]

Come al solito su questo pianeta quando qualcuno dice una cosa intelligente la capiscono in tre su quaranta!
Non mi voglio riferire assolutamente a questo forum...anzi, mi riferisco alle opinioni che sono state scritte a livello mondiale su quanto ha detto Torvalds.
A mio modo di vedere e' come se avesse detto che il kernel cresce ma servono nuove idee per renderlo anche snello, e' una persona onesta, non nasconde una realta' che prima o poi dovra' essere affrontata...e molto probabilmete ha parlato di una cosa che si vociferava gia' da tempo tra di loro. Tutto qua! E' gente che lavora, guarda in prospettiva, non e' ipocrita. Poi magari mi sbaglio....ma cerco di vedere le cose in modo semplice e con i piedi per terra!

[Toni]

E' assurdo sentire gente che parla di sistemi "più reattivi e scattanti" con kernel statici/modulari o con scheduler diversi senza uno straccio di numero

http://ck.kolivas.org/patches/bfs/inter ... fs-cfs.txt

[raffaele181188]

Ma hai letto quello che ho scritto e quello che hai linkato?

[Mario Vanoni]

Per esperienza mia, con HW anche modernizzata di brutto,
p.e. da P4/HT a Core 2 Dual, il kernel (statico) non cambia molto.

In che senso?

Sul P4/HT kernel statico sui 2.5MB, se ricordo bene.

Core 2 Dual:
2808394 bytes 2.6.30.4
2997216 bytes 2.6.20.5
3249920 bytes 2.6.31 (originale)
3258528 bytes 2.6.31-bfs211 (variante di Con Kolivas)
3260064 bytes 2.6.31-bfs232 (variante di Con Kolivas)

se lo confronti con Slackware 12.2 originale
4727664 bytes huge-smp-2.6.27.7-smp di PJV,
che impiega anche 65MB in /lib/modules/2.6.27.7...

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

PS
Se durante l'installazione facessero un check della HW,
come Slackware, anche presente nel 13.0, con network,
potrebbero ottimizzare ... vale la pena con la HW moderna?

[Toni]

con scheduler diversi senza uno straccio di numero

http://ck.kolivas.org/patches/bfs/inter ... fs-cfs.txt

[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