Olimpo Informatico

[Zeus News]

Commenti all'articolo Torvalds: "Linux è troppo grosso"
Aggiungendo funzioni via via, è diventato "gonfio ed enorme", perdendo efficienza. Il guaio è che non c'è rimedio.

[zeross]

Purtroppo il gigantismo è il prblema di utti i kernel monolitici che sono costretti nel corso del tempo a dover supportare sempre nuovi dispositivi, protocoli e funzioni mantenndeo però quelli precedenti per non predere la compatibilità.

Un pò come uno che compre una serie di pentole per cucinare la pasta, poi compra quelle per cucinare la carne, poi quelle per il pesce, mantenndo sempr eperò le precedenti pentole.

Alla fine la cucina è invasa dal pentolame.

All'inizio il kernel di linux contava ventimila righe di codice, dieci anni dopo era arrivata a venti milioni ( un valore che il kernel di Windows NT aveva superato già da alcuni anni) di righe di codice.

Questo volume di infomrazioni rende materilamente impossibile ad un gruppo ristretto di persone di poter far fronte al mantenimento di un sistema siffatto.
Per questo si arriva alla segmentazione del lavoro tra più squadre con gruppi di coordinamento.
Nel caso di LINUX il coordinamento è abbastanza efficiente è riesce a tenere unito il progetto.
Nel caos di Microosft sono riusciti a farlo solo con il progetto di Windows 2000 poi si sono persi e di parecchio.

Per questo Linus Torvalds si preoccupa molto visto i problemi di mantenimento di una aziend acome quella di Redmond, cosa garantisce che nel futuro anche Linux non possa incorrere nello stesso tipo di inconvenienti.
Ne si può porre rimedio visto che la struttura monolitica lo rende praticamente impossibile.

Una struttura come quella del defunto Be Os ch einvece era ad alta modularità avrebbe potuto assolvere a questo compito ma purtroppo quella è una strada oramai senza via di uscita (Haiku e solo un sogno).

Il grande limite di Linux dovuto alla sua struttura interna ed al bisogno di dover supportare utto lo scibile ed anche di più provoca un fenmeno inarrestabile, che anche con gli stratagemmi più astuti come creare un insieme di serve che si occuapano di varie funzioni da richiamare dinamicamente non potranno che ritardare l'inevitabile implosione di sitemi troppo elefantiaci.

In Microsoft hanno pianificato di abbandonare il vecchio kernel NT (ibrido tra OS/2 e OpenVMS) nel 2014 quando secondo i loro calcoli il sistema non potrà più essere sviluppato avendo raggiunto i limiti tecnologici e si vedrà la luce di un nuovo sistema modulare basato sulle esperienze maturate con windows CE.

Anche in ambito LINUX occorre fin da ora pensare a qualcosa di nuovo e diverso da implementare che abbi alla base il concetto di modularità estrema in modo da dover erichiamar ein memoria pe ril solo tempo strettamente necessario i soli moduli indispensabili a fare i compiti richiesti.

L'eopca del sistema operativo che carica in meoria tutto l'immaginabile ed anche qual cosa in pù e definitivamente tramontata.

Bast apensare ad un sistema operativo come QNX che in un floppy da 1.44 contiene un sistema operativo x86 funzionante con browser internet per capire l'errore macroscopico nell'inseguire l'onnicomprensività.

[carlonove]

Finalmente ci si accorge che per raggiungere un livello medio-basso di potenzialità multimediale (cosa che gli altri pc forniscono in modalità più avanzata grazie a programmi adatti) non occorrono solo parole.

[mda]

[{paolo del bene}]

Linus Torvalds Benedict era già al corrente del problema, dunque non vedo di cosa si debba meravigliare.

Iniziamo ad allegerire le distribuzioni GNU/linux e far si che vengano installate le cose fondamentali, il resto lo si può installare da riga di comando.

Intanto caricare centinaia di drivers inutili non serve proprio a nulla, avere i giochi, il supporto ActiveX e DirectX può esser eliminato tranquillissimamente dato che c'è OpenGL, un ambiente grafico, leggero, senza fronzoli alla mac os x.

In pratica compilarsi il kernel ed i packages a seconda delle reali necessità, solo in questo modo si può risparmiare spazio sull'hdd e quantità di ram.

[{utente anonimo}]

Parecchi anni fa, si lavorava con un sistema operativo chiamato RSX-11. Era stato scritto da genta capace di "inchiodare i byte con il martello". Permetteva di compilare COBOL da quattro terminali su macchine (PDP11) con 256 KB di RAM. Per quel che ricordo, una delle caratteristiche migliori era l' efficienza con cui il codice residente sfruttava le caratteristiche di un loader efficientissimo per caricare, di volta in volta, i moduli necessari. Un modulo "Loader" da affiancare ai kernel monolitici per caricare di volta in volta altri moduli.... chi crede che sia possibile ? (P.S. l' RSX è stato il precursore del VMS)

[{Victor von Doom}]

...che proprio lui ha litigato con Tanenbaum sostenendo la superiorità di un kernel monolitico in contrapposizione alla posizione di Tanenbaum sui microkernels??
E adesso si lamenta? Farà anche lui colazione con la grappa? :)

[seahawk]

da utonto normale di ubuntu non mi accorgo di questo calo di prestazioni (lo uso da un paio di anni)... all'avvio ci mette 30 secondi a essere utilizzabile (vs 1minuto abbondante di xp, sul mio pc)...sul resto non saprei.

Si potrebbe però installare il sistema operativo e poi togliere tutto cioò che non serve... quando ne hai bisogno lo scarichi dai repository...

non so, io non sono un informatico quindi non posso avanzare altre proposte

[nino.dago]

Quando si vuole trasformare Linux in qualcosa che non è, è normale che la direzione sia questa...
Bisogna essere obiettivi: il vertiginoso aumento delle potenzialità hardware ha portato, non solo dal lato Microsoft, a fregarsene delle prestazioni.
Inoltre, molti cercano, in varie distro Linux, di potenziare la user friendliness, ma ciò non può che appesantire il tutto.
D'altra parte, se non esistesse ad esempio una distro chiara e semplice come Ubuntu, quanti utenti a bassa alfabetizzazione informatica lo userebbero?

Capisco che non è facile ammetterlo, ma il discorso di Torvalds è molto chiaro: non possiamo fare il verso ai S.O. commerciali e poi evitare di affrontare le conseguenze delle nostre azioni..

[ercole69]

...Linux è solo il kernel del sistema quindi l'elefantismo delle distribuzioni in questo caso non centra nulla. Io posso avere anche 200GB di programmi installati ma la memoria e la CPU vengono usati solo per i programmi in esecuzione in quel momento.
Invece parte il problema maggiore del Kernel è proprio nel suo punto di forza: Linux supporta praticamente tutto l'hardware esistente quindi deve avere moduli per qualsiasi cosa, dalla scheda grafica VESA fino ai microcontrollori industriali e deve essere in grado di girare dai processori embebbed fino ai supercomputer...
Gli "altri" sistemi risolvono il problema girando o su hardware personalizzato (qualcuno sta parlano di mele ) oppure non supportano praticamente nulla (provate a installare un Windows qualsiasi senza driver aggiuntivi su un PC e vedrete cosa capita...)

[{Nedanfor}]

Se si ha bisogno di prestazioni ottimali si ricompila il kernel... Preferisco un kernel che inglobi tutti i driver che un kernel vuoto, onestamente. A quanti servono prestazioni ottimali? A pochi. Se devo aiutare qualcuno senza la minima conoscenza informatica, per non perdere tempo inutilmente, preferisco installargli il kernel completo... E v'assicuro, questo 'calo' delle prestazioni si sente molto poco... È molto peggio l'aumento del peso dei DE.

[mda]

[bandreabis]

Domanda da ignorante: non è sufficiente compilare il kernel eliminando tutto ciò che non serve?

[mda]

[Ramon]

Continuo a leggere questo tormentone sui kernel monolitici, microkernel, etc; si tratta di discorsi che lasciano il tempo che trovano.

Né Windows, né MacOSX, né Linux, sono microkernel.
Né Windows, né MacOSX, né Linux, sono monolitici.

Tutti i principali kernel ormai sono ibridi; anche Linux ha una miriade di driver, ciascuno dei quali ha una porzione in kernel space e una in user space.

Minix è microkernel ma ha solo una finalità didattica.

[mda]

[{paolo del bene}]

secondo quale tua convinzioneil kernel linux non è monolitico ? secondo quale tua convinzione mach 4.0 non è un microkernel ? scommettiamo che ho ragione io ?

Il Microkernel Mach è frutto di un fork di BSD, originariamente BSD era un sistema operativo sviluppato dalla University Of Califronia, Berkeley. successivamente fu sviluppato il microkernel Mach da Richard Rashid vendutosi alla microsoft molti anni dopo.

Come avevo già supposto il microkernel Mach sviluppato da Richard Rashid & Co, ebbe fortuna grazie all'introduzione dei processi servers derivanti dalla Free Software Foundation grazie a GNU ed HURD, ma soprattuto HURD

Tenendo presente che Richard Rashid si laureò alla University of Rochester Il destino volle che il microkernel Mach alla Carnegie Mellon University si fermo al 3.0, mentre alla University of Utah fu portato avanti fino alla 4.0.

Steve Jobs era il Co-fondatore della Apple Computer Cupertino.Inc insieme a Steve Wozniak, Steve Jobs mise il Capitale, Wozniak il cervello per lo svilluppo hardware, che la prima volta si verificò essere un flop gigantesco, quando il computer davanti alla stampa andò in fumo. :-)

Tornando alla questione Apple Computer Cupertino.Inc, Steve Jobs lasciò la Apple Computer Cupertino.Inc perchè era in pessimi rapporti con John Sculley, l'allora presidente di Apple Computer Cupertino.Inc e decise di andare a fondare la Next.

Indovinate su quale sistema operativo iniziarono a lavorare alla Next ?

Non lo sapete, o non lo avete indovinato ?

Sull'evoluzione del microkernel Mach 4.0, sapete chi altro entrò a far parte del team di sviluppo alla Next ?

Avadis Tevanian, un altro che alla Carnegie Mellon University

Ebbene, non fecero altro che metterci sopra un pò di grafica e spacciarlo per un nuovo sistema operativo, che fu chiamato NextStep, piacque così tanto che anche la sun microsystems lo volle provare ed ancora oggi i sistemisti staranno li ad imprecare per non avere più alcuna fomra di supporto, si perchè Steve Jobs, non vendette NextStep, ma fece fare OpenStep, appositamente per la sun microsystems e siccome verso la fine degli anni 90 la Apple iniziava ad andar male, Steve Jobs, vendette la Next alla Apple Computer Cupertino.Inc permettendo così alla Apple Computer Cupertino.Inc di beneficiare del lavoro svolto fino al 1996-1997, quando Steve Jobs, disse che i rami secchi dovevano essere tagliati perchè non produttivi, iniziò a licenziare in Apple Computer Cupertino.Inc, nel 1997 iniziò in velocità a far implementare NextStep insieme a Mac Os, per lo sviluppo del Mac Os x, portandosi dietro come vice presidente Avadis Tevanian in Apple Computer Cupertino.Inc e da li a breve iniziarono a spacciare un kernel monolitico come BSD fuso insieme al microkernel Mach 4.0 (ibrido) per l'evoluzione di un sistema operativo inventato da Apple Computer Cupertino.Inc.

Se uno vuole GNU/HURD si prende l'orginale ma non c'è alcun motivo per regalare migliaia di euro ad un capitalista, quando invece si possono fare delle spontanee e libere donazioni agli sviluppatori di FreeBSD.

[Ramon]

Ovviamente mi riferivo ai kernel principali impiegati nel mondo dei PC.

Minix non sarà più didattico, ma il suo utilizzo è prossimo allo zero.

X paolo del bene. Linux è strutturato come kernel monolitico, ma da un bel po di tempo ha subito delle modifiche che lo hanno fatto diventare via via sempre più "pseudo-ibrido" (nel senso che, tecnicamente, non si può parlare di un vero kernel ibrido).

C'è anche da ricordare che, come sanno bene gli esperti, i kernel monolitici sono quelli più efficienti in assoluto, anche se presentano una serie di svantaggi.

[mda]

[freemind]

Gli esokernel sono una bella idea!

Però parlando di linux io non ho capito una cosa sulla critica di suo papà.
Quando è nato, supportava poca roba, oggi linux fa di tutto; si attacca a moltissimi dispositivi, ci sono versioni realtime e bla bla bla.

Ovviamente più roba ci metti, più peso ha. Quindi questo appesantimento io non credo che sia così un dramma anche perchè come kernel resta molto veloce (in quanto i kernel monolitici [lasciamo perdere l'appunto di ramon, che è giustissimo però di fatto il linux è monolitico] sono più veloci).

Io piuttosto mi preoccuperei di un problema che affligge le moderne distro basate su linux e anche gli altri OS commerciali.
Troppe stratificazioni, troppi wrapper per tener insieme cose aggiunte successivamente e non previste (e neppure previsti i giusti "agganci").
Però qui sto uscendo dal topic quindi chiudo questa postilla.

Poi, come già è stato fatto notare, il kernel può essere ricompilato e reso piccolissimo quindi si tornerebbe ad avere il kernel minimale giusto giusto per la macchina su cui gira.