23 settembre 2009 Visualizzazioni: 1691 Business

Linus Torvalds: Linux è diventato obeso

Durante un suo intervento al LinuxCon 2009, l’ideatore e attuale maintainer del Kernel, ha sparato a zero circa l’attuale peso-forma del suo progetto.

Forse c’è veramente qualcosa che non va nelle dimensioni del Kernel Linux se a criticarlo è lo stesso Linus Torvalds. In realtà il grande capo ha definito il pinguino gonfio e grosso. Talmente gonfio che è ormai impossibile prevedere qualsiasi intervento di recovery. La situazione, poi, diventa più preoccupante quando vengono mostrati alcuni dati statistici sulle performance del Kernel. Ebbene, forse non tutti sanno che ad ogni nuova versione calano del 2 per cento, con una riduzione complessiva di circa il 12 per cento nelle ultime 10 release. Tuttavia c’è qualcosa di cui andarne fieri, precisa Torvalds, ossia che gli sviluppatori trovano i bug con la stessa velocità con cui li implementano. “Sono un triste perché mi ritrovo difronte ad un kernel tutt’altro che piccolo, leggero e super-efficiente come lo avevo immaginato quindici anni fa”. Ed ora?

FONTE: Cnet

» Business » Linus Torvalds: Linux è diventato obeso

wonderland

avesse dato retta a Thanenmbaum … invece di fare il nerd tutto fare che tutto sa
- Jack
  
  « Io continuo a ritenere che progettare un kernel monolitico nel 1991 sia un errore fondamentale. Ringrazi che non è mio studente. Non avrebbe preso un voto alto per tale progetto »
  
  fonte: Wikipedia
- T3ch
  
  …non ci sarebbe stato Linux!
- Old
  
  considerando dove si trova oggi linux e dove minix, direi che non ci siano dubbi su chi avesse ragione, anche perche’, ne windows, ne macos sono microkernel puri, quindi, non e’ che il microkernel abbia fattto chissa’ quanta strada…
  quello che dice torvalds e’ una fase normale a cui arrivano prima o poi tutti i software, in cui bisogna smettere per un momento di limitarsi ad implementare nuove funzioni e pensare se sia il caso di fare un po’ d’ordine
  - asdert
    
    smettiamola di confrontare mele con zebetei!
    
    Linux è stato sviluppato per essere utilizzato.
    Minix è satto sviluppato per la didattica.
    Entrammbi hanno traggiunto il loro scopo. punto.
    (Approposito: Minix dalla versione 3 ha deciso finalmente di diventare “usabile”… e mi sembra che stia crescendo bene!)
    
    Inoltre il fatto che non ci siano sistemi microkernel non va in contraddizione col fatto che “… progettare un kernel monolitico nel 1991 sia un errore …”. Infondo significa semplicemente che Windows è un errore, OSX è un errore, Linux è un errore. Ovviamente, imho, Linux suck less :)
    
    Ah… mi dimenticavo… l4 riesce a far girare linux con la perdita del 10% delle performance. Non mi sembra che i microkernel facciano tanto skifo in fatto di performance (che è L’UNICA caratteristica che gli sviluppatori di macrokernel potrebbero accampare!)
    - Old
      
      prima di tutto, a me risulta che minix era un kernel commerciale, quindi, non capisco bene cosa vuoi intendere con “sviluppato per la didattica”.
      inoltre la mia era una critica, non ai microkernel, ma alle parole di tennenbaum, dato che i fatti, a distanza di 18 anni, lo hanno ampiamente smentito. se ti da fastidio che parli di minix, prendine un altro! mi sembra che l’unico che possa vantare un certo successo sia qnx in ambiti mission critical.
      che tutti i kernel che non siano micro, facciano schifo e’ una tua opinione a cui il mondo risponde indifferente dato che ne fa tranquillamente a meno, con buona pace per tennenbaum. del resto, anche apple torno’ sui suoi passi da mach…
      i microkernel, oltre ad essere piu’ lenti (non di molto, per carita’) sono piu’ complessi da progettare e sviluppare e quindi piu’ problematici da far evolvere.
      quindi, ribadisco, io non ho nulla contro i microkernel (tra l’altro mi piace molto beos), ma che linux nel 1991 fosse obsoleto, e’ una cazzata e tennenbaum aveva torto
      - Lorenzo
        
        Tu si che la sai lunga eh…
      - Old
        
        @Lorenzo
        
        Tu si che sai argomentare, eh…
      - asdert
        
        no minix non era commerciale, era un os sviluppato per insegnare agli studenti come era fatto un os:
        http://en.wikipedia.org/wiki/MINIX
        
        scusa se per la storia “windows e un errore…” etc; mi sono lasciato prendere un po la mano :)
        
        non capisco perche dici che un microkernel è più dificile da sviluppare: innanzitutto c’e’ meno roba da sviluppare! Se poi ti riferisci al resto dell’os (diciamo i server che dovrebbero sostituire le varie parti di un kernel monolitico)… bhe non penso sia molto diverso che sviluppare un modulo del kernel, con l’ENORME differenza che è possibile usare un debugger per vedere cosa cacchio non va!
        
        Ripeto, che io sappia, l’unico vantaggio che hanno sembre sbandierato i sostenitori di un kernel monolitico, è la velocità!
baldo

giustissimo… si accorge solo ora che l’architettura di un moderno OS dovrebbe essere a microkernel? nonostante io sia un amante dei sistemi GNU/Linux questa è una dura realtà che conviene sia accettata al più presto…
- Old
  
  perche’? non vedo molti os a microkernel puro, in giro…
  se ci sara’ bisogno di implementare alcuni aspetti dei microkernel, non preoccuparti che verra’ fatto senza troppi drammi
  - baldo
    
    il fatto che non ci siano molti os a microkernel non significa che non sia l’approccio giusto! come al solito la ricerca arriva almeno 30 anni prima (con tanti errori, ovviamente!) alle conclusioni… basti pensare alla programmazione ad oggetti (che imho sarebbe da pensionare da anni) diventata di uso comune non meno di 20 anni dopo la sua introduzione… non dico che nel ’91 fosse sbagliato partire con una soluzione monolitica (anzi probabilmente è il contrario) ma che giunti a questo punto se ne sentono fortemente i limiti (come osserva lo stesso linus)…
    - Paul
      
      perchè come programmare se non a oggetti oggi come oggi? quale sarebbe il futuro della programmazione?
      - /dev/null
        
        Infatti, anche io sarei molto curioso di sentire quali sarebbero le alternative alla programmazione a oggetti.
      - baldo
        
        per il mainstream si rimarrà ad oggetti per ancora almeno 10 anni, per chi ha sperimentato i limiti di tale paradigma consiglio di dare un’occhiata alla programmazione ad agenti (o ad attori tanto condividono molto sulla base teorica)… un buon esempio al riguardo può essere jason o jade… ovviamente stiamo ancora parlando di progetti a livello puramente accademico e non così consolidati per l’uso nel mercato globale ma se dovessi scomettere su quale sarà la direzione futura è, imho, questa…
http://emanuele.itoscano.com ToX

viste le passate esperienze… non escluderei un fork mirato al raggiungimento del peso forma :D
- Paul
  
  Si tratta del modello che raggiunge dei limiti, (sul mio pc li ha raggiunti da tempo in quanto non riesco più a ricompilare in tempi accettabili.
  Vediamo se mi migrerà a una struttura ibrida prima di passare al microkernel… gli sviluppatori ci sono e non penso ci mettano poi molto.
bLax

ah ecco! allora non era solo una mia impressione! ad ogni aggiornamento del kernel vedo un utilizzo piu intenso di cpu….

vai Linus! dai una bella sistemata al tutto!
http://www.mte90.net Mte90

Un kernel che si aggiorna così spesso ha dalla sua una buona frequenza di aggiornamenti e di implemtenazioni ma non vedo l’ora ch venga rilasciata una versione nuova ottimizzata!
asd

il problema è che ogni distro vuole reinventare una cosa gia creata da altre distro piuttosto che reimplementarla e renderla standard,vedi i packet manager ad esempio:
è veramente necessaria questa grande differenza?
non ci si potrebbe mettere daccordo sul fare un’unico sforzo per un packet manager generico?

si elogia sempre opensource ma poi alla fine si preferisce il proprio codice customizzato rispetto a uno standard dove ci lavorano tutti.
- Davide
  
  Quoto!! La penso come te.
- Jepessen
  
  Caspita c’entrano i pacchetti con il kernel… Linus parla delle dimensioni dei kernel, mica del software che ci gira sopra…
  - asd
    
    io parlo in generale sul fatto che si elogi l’open source ma alla fine si produce solo per la propria distro scartando il lavoro altrie ed evitando standard comuni,il packet manager è servito come esempio perchè è un oggetto quasi fondamentale per la scelta di una distro(il numero di software facilmente reperibili è un’ottimo punto di forza soprattutto per chi è meno esperto con le installazioni),torvald non penso parli solo di kernel ma piu in generale sul fatto appunto che si riscriva codice per nulla,non credo che le linee di codice a cui lui si riferisce siano solo di kernel è impensabile!
- asdert
  
  bhe a dire la verità qui si parlava del kernel non di cose tipo pkg manager.
  
  Comunque, secondo me, la varietà è una buona cosa. La vedo un po’ darwinianamente e un po economicamente (la storia della concorrenza…).
  
  Certo se avessimo 2000 tipologie di pacchetti sarebbe tragico, ma 2-3 principali (tipo rpm o deb) più qualcuno di “Nicchia” (tipo quello usato da arch) non mi sembra tutta sta confusione.
  
  In fondo stanno comunque facendo sforzi per renderne l’utilizzo “Uniforme” tramite packagekit.
Grande Capo

Che dire, speriamo nella nuova revisione del core Toppens, che integra 1 mega di owerflow-flare-up con 2Gb/ms di bandwith verso il south-kernel. Lo so, forse é un pò azzardato, ma d’altronde, con un flow buffer di 3 chip in SLI, ditemi voi come fa a decompilare il buffer? Non so, ditemi voi cosa ne pensate.
Alb3rt0

Beh non mi pasre abbia detto nulla di strano…

con tutto l’hardware supportato, con tutte le tecnologie che sono supportate dalla piattaforma, è normale che le performance cadano progressivamente con l’aumentare della complessità del mondo circostante.

Prima o poi verrà il momento di riscrivere tutto, secondo nuovi assunti, decidendo cosa deve essere lasciato fuori, difficile parlare di miglioramenti fino a quel momento.