Nonostante le distribuzioni GNU/Linux acquistino sempre più consensi anche sui sistemi desktop, InfoWorld ci informa che il futuro del pinguino rimarrà legato ai server di fascia alta, a causa della dittatura di Torvalds e della dipartita di Con Kolivas.
Ignorando tutti gli aspetti estremamente tecnici che riguardano gli scheduler di processi, InfoWorld ci spiega come il pinguino sia sempre meno adatto ai desktop, non per colpa del supporto hardware ma per l’assenza dello SD scheduler di Kolivas (!!). La soluzione proposta da InfoWorld? Forkare il kernel e mantenere una versione desktop ed una server, come Microsoft insegna da anni.
Io sono senza parole, lascio a voi lettori ogni commento.
[ via Slashdot ]
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, chi siamo
© 2004-2011 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
@go
19 set 2007 - 08:12 - #1Linux sempre meno adatto ai Desktop??? A me sembra sia sempre PIU’ adatto ai desktop!!! Tant’è che sta prendendo sempre + piede. Secondo me va bene continuare come adesso.
mad_max
19 set 2007 - 08:26 - #2“non per colpa del supporto hardware ma per l’assenza dello SD scheduler di Kolivas”
Come si può dare rilevanza ad una affermazione del genere?
Albertoz
19 set 2007 - 08:35 - #3Al mio paese si dice: “La madre degli idioti è sempre incinta”…
noct
19 set 2007 - 08:51 - #4come se lo scheduler attuale avesse seri problemi di responsività del desktop..
Che sciocchezze cavolo..
ubuntista
19 set 2007 - 08:53 - #5Dimenticano che il prossimo kernel avra’ il nuovo scheduler CFS che e’ quantomeno comparabile a SD.
E ora Intel e IBM stanno contribuendo a CFS quindi…
telegraph.road
19 set 2007 - 08:54 - #6A me pare che lo scheduler che verrà inserito nella versione 2.6.23 sia asddirittura meglio di quello proposto nelle patch -ck… Mi sembra solo che si stia facendo disinformazione con queste notizie!
deveron
19 set 2007 - 08:55 - #7Sono d’accordo con voi che linux è sempre + adatto ai desktop ma in quanto a ottimizzazione degli sforzi secondo me non è male come idea… Il nostro kernel alla situazione attuale non è ke un ibrido… Facciamolo specializzare…
sirus
19 set 2007 - 08:58 - #8In realtà il nuovo scheduler CFS da del filo da torcere anche al SD di Kolivas in campo desktop quindi direi che l’adozione dello scheduler di Kolivas non è una priorità.
C’è da dire che forse sviluppando SD in team piuttosto che in solitaria si otterrebbero realmente risultati strabilianti.
ossmlcr
19 set 2007 - 09:02 - #9A me sembra che l’articolo ponga un’altro problema, non tanto la questione di kolivas, ma il fatto di come la “benevolent dictatorship” che guida la scelta dell’inclusione delle patch nel Linux è disinteressata ai problemi che non riguardano il segmento server.
Poi nello specifico porta l’esempio della low-latency e della gestione migliore della virtual memory, ma il problema che sottolinea l’articolo è più ampio.
NoWhereMan
19 set 2007 - 09:07 - #10Non vedo il problema, se i due progetti rimangono sotto la stessa ala. In fondo esistono interi patchset pesanti, la differenza è che così il kernel server e quello desktop farebbero a capo ad un unico macroprogetto…
Andy
19 set 2007 - 09:49 - #11Mi sembra nell’articolo di InfoWord, la dipartita di Kolivas ed il fork non abbiano nulla di tecnicamente comune se non il fatto che in entrambi i casi viene messa in discussa la linea guida del progetto kernel Linux in quanto questa da alcuni non è più condivisa.
Il fatto che Linux stia crescendo sempre più nell’ambito desktop semplicemente conferma che chi sviluppa il kernel dovrebbe tenerne sempre più conto. Ma significa anche che il progetto è già sufficientemente valido per questo tipo d’ambiente applicativo.
Se il kernel Linux può essere impiegato sia sui grandi server che sul desktop fino alle applicazioni embedded e di telefonia, non si fa altro che confermare la sua malleabilità e versatilità.
Ben venga il “fork” se riesce a creare un progetto vero e sostenibile, e, non sia una banale manifestazione di protesta verso una certa linea guida che - a mio avviso - non può e non deve essere messa in discussione.
=)
mad_max
19 set 2007 - 09:58 - #12ossmlcr: Infatti il problema fondamentale è un altro, non tanto lo scheduler.
C’è da chiedersi: Dobbiamo porci questo problema?
A me sembra che lo sviluppo di linux sia sostenuto. Ci sono cicli di vita dei componenti interni (gestiore memoria, scheduler, vari stack, ecc..) dove si alternano fasi di ottimizzazione e fasi in cui tutto viene messo in discussione (molto spesso per effetturare normalizzazioni del codice) e viene riscritto tutto.
Si cerca sempre di sfruttare gli algoritmi + promettenti (anzi direi i migliori!).
La scelta di includere un pezzo di codice dipende da diversi fattori: stabilità, prestazioni, facilità di manutenzione.
Ogni volta che 2 o + persone non la pensano nello stesso modo perchè si deve creare una situazione di allarmismo? (c’è da dire che l’allarmismo è causato dal riverbero della comunicazione globale).
In fase di configurazione del kernel è possibile fare centinaia di scelte. ( ma guarda un pò! è possibile scegliere tra diversi scheduler! perchè non inserire anche quello di colivans come alternativa? la risposta è che ce ne sono già abbastanza e ottimi).
Non è ancora entrato in funzione il CFS che già ci si chiede come creare uno scheduler che lavori con gruppi di processi.
Per me questo sistema di sviluppo è molto buono, non capisco come certi possano pensare ad un fork.
Per esempio nei sistemi bsd ognuno porta avanti lo sviluppo del proprio kernel, e molto spesso codice di un kernel finisce in un altro (questo può sembrare un bene ma è solo una perdita di tempo).
antgelofb
19 set 2007 - 10:18 - #13basta, passo ad hurd! :)
ossmlcr
19 set 2007 - 10:44 - #14C’è da chiedersi: Dobbiamo porci questo problema?
A me sembra che lo sviluppo di linux sia sostenuto.
Evidentemente chi ha scritto l’articolo la pensa diversamente, e non guarda al fatto che quantitativamente lo sviluppo è sostenuto, ma che l’attenzione ai singoli problemi non è equivalente.
Si cerca sempre di sfruttare gli algoritmi + promettenti
Questo è vero e falso allo stesso tempo, perchè gli algoritmi degli scheduler sono pressochè gli stessi da almeno vent’anni, e si è sempre saputo che il Linux ha uno scheduler che svantaggia i processi I/O bound, e di conseguenza le applicazioni multimediali/interattive ne risentono. I vari scheduler recenti (incluso CFS) risolvono il problema, ma hanno sollevato polemiche sulle policy di gestione del Linux.
Ogni volta che 2 o + persone non la pensano nello stesso modo perchè si deve creare una situazione di allarmismo?
A me non sembra un’articolo allarmista, il problema è stato sollevato proprio dagli sviluppatori del Linux. Poi ha subito il broadcasting globale (e conseguente apparente esagerazione), ma questo è un’altra cosa…
In fase di configurazione del kernel è possibile fare centinaia di scelte.
Questo è solo parzialmente rilevante, perchè oggi lo studio degli SO è molto avanzato e per la maggior parte dei problemi si conosce un’implementazione/strategia ottima che è migliore delle altre, perciò il ventaglio delle scelte è molto più piccolo, soprattutto se si pensa ad un sistema che ha un target specifico (server, desktop, embedded systems, etc).
Non è ancora entrato in funzione il CFS che già ci si chiede come creare uno scheduler che lavori con gruppi di processi.
Si, perchè il CFS ha un limite implementativo, e non divide i processi in run-queue, causando l’assenza della soft-affinity ed aumentando i contenziosi sui lock nei sistemi multi-core - il risultato è che all’aumentare dei core, il sistema degrada linearmente.
Per me questo sistema di sviluppo è molto buono, non capisco come certi possano pensare ad un fork.
Certo, il fork è un’esagerazione del giornalista che ha scritto l’articolo, è chiaro che non è una soluzione.
Cristiano Rosencreutz
19 set 2007 - 10:55 - #15beh, non mi pare abbiano detto niente di sbagliato: server e desktop hanno priorità diverse, non c’ è bisogno di un fork forse, ma di poter impostare lo scheduler in maniera appropriata al tipo di uso sì.
Cla
19 set 2007 - 21:07 - #16Ma chi ha scritto queste bestiate?
Concordo con tutti i ragazzi sopra niente fork!Ma siamo pazzi?
Trevi
20 set 2007 - 04:29 - #17Riguardo il funzionamento del nuovo scheduler, potete vedere che dal lato utente (e ludico in questo caso), ci sono stati solo vantaggi: http://distrogue.blogspot.com/2007/08/life-on-bleeding-edge-linux-kernel-2623.html
Non conosco i dettagli dei due scheduler, ma pare proprio che il CFS si stia muovendo bene…
freemanlab
20 set 2007 - 13:19 - #18Scusate mi spiegate una cosa? Premetto che windows non mi piace e preferisco l’open source…devo ammettere però ke almeno dal punto di vista energetico linux deve fare molto ancora, come mai il mio portatile scalda un bel po’ con linux e con windows sono riuscito anche a non far girare più la ventola? Queste sono carenze imho di un kernel non ottimizzato per il reparto desktop (o meglio laptop - notebook). Quindi chiamatelo fork, o chiamatelo come volete…ma a me sembra obbiettivo che qualcosa c’è ancora da fare in questo ambito (e non poco), e qualcuno se ne dovrà occupare più seriamente.
Clint
20 set 2007 - 15:59 - #19@freemanlab
Caro amico, i problemi che sollevi esistono, ma non dipendono da linux, o almeno non del tutto. Come tu saprai, molte aziende non vogliono rilasciare le specifiche dell’hardware che producono, e come conseguenza non e’ facile interagire con quei dispositivi. Solo recentemente grandi nomi come AMD, INTEL, SIS e altre, cominciano a rilasciare le specifiche.
Mi permetto di suggerirti una cosa: tempo fa ho avuto anche io lo stesso tuo problema, ma era solo una questione di configurazione iniziale. A quel punto, non sapendo che fare, cambiai distro e tutto funziono’ a meraviglia :-)
Aspetta quindi un mese ancora e prova l’ultima versione di ubuntu, la gusty, che dovrebbe uscire a fine ottobre.
Saluti.
ugasoft
20 set 2007 - 20:05 - #20concordo: forkare il kernel e… CAZZAROLA, GETTARE NEL CESSO IL C E PROGRAMMARE IN C++!!!
niubbo di un Torvalds!
emmebi
21 set 2007 - 02:28 - #21Mi sembra che uno dei grandi vantaggi di Linux dimostrato in questi ultimi anni sia la flessibilità, che gli permette di essere a proprio agio su hw diversi dai telefoni ai server e oltre.
Poi non è dalle prestazioni di una o l’altra componente del kernel che si giudica un SO adatto ai desktop.
Personalmente sto usando linux per insegnare l’uso del computer ai meno esperti, una volta installato non hanno mai avuto problemi.
Per molti (ok molti ma molti) utenti un sistema desktop serve così, affidabile. E lo giudicano soprattutto da quello.
Hornet2e
21 set 2007 - 14:11 - #22Se forkano il kernel, dovranno essere raddoppiati gli sforzi, il lavoro e soprattutto le energie. La domanda è: siamo pronti per un tale sforzo? Io dico di mantenere un solo kernel e permettere in fase di compilazione la scelta dello scheduler. Basterebbe poco come vedete.
Ciao!
John-Cena
22 set 2007 - 18:07 - #23perchè stare a sentire questi stupidi articoli…parlano i fatti…:)
Rododendro
23 set 2007 - 14:26 - #24@angelofb:
buona fortuna!
@ ugasoft:
Allora sì che sarebbe lento!
freemanlab
25 set 2007 - 12:20 - #25@ Clint
Amico anche tu hai ragione! Penso anch’io che quello che tu dica sia una delle cause… però trovo che almeno qualcosa si stia muovendo, vedi ad esempio http://www.lesswatts.org/. Spero solamente che il tempo per mettere in pratica le idee sia il più ristretto possibile ecco perchè dico che un reparto adatto allo sviluppo di driver e moduli specifici per desktop/notebook sia più proficuo.
xiaobu002
16 set 2010 - 04:07 - #26As we are Abercrombie Fitch Hoodies through winter division so aggregation is aggravating to present something advantageous for the barter and that’s why they formed actual harder on Abercrombie Fitch Hoodie adorable hoodie designs for beautiful people.