Il valore di alcuni progetti open source è rappresentato, più che dalla loro utilità, dall’innovazione che essi apportano e SharpOS è proprio uno di questi: il progetto è infatti volto alla realizzazione di un kernel scritto completamente in C#, in modo analogo a quanto viene fatto da Microsoft per il suo Singularity.
Nonostante la scelta di questo linguaggio abbia comportato numerosi problemi ( C# è un linguaggio managed e per sua natura non è adatto a svolgere compiti così bassi come quelli svolti dal kernel di un sistema operativo ) gli sviluppatori sono riusciti a creare un’infrastruttura che consente la creazione di kernel scritti, oltre che in C#, in qualsiasi linguaggio in grado di generare bytecode compatibile con il Common Intermediate Language e di esportare puntatori indicatori / unsafe code.
Chi volesse provare SharpOS avrà bisogno solamente di un compilatore ( Microsoft Visual Studio o Mono ) e di un bootloader come GRUB. SharpOS è rilasciato con licenza GPLv3 con ClassPath exception.
via | OSNews
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
Bigshot
03 gen 2008 - 18:38 - #1a mio papere è quanto di più folgorato ci sia in giro…
a sto punto diamo corda anche ad un kernel fatto in java -,- (se mai è possibile, tra l’altro)…
va beh tutto, c# sarà anche facilissimo ma per fare un kernel io ho sempre sentito e imparato che si debba usare un linguaggio a basso livello…
poi magari no e mi cade il mondo sotto i piedi :D
ekerazha
03 gen 2008 - 19:06 - #2Dipende da cosa intendi per “basso livello”, in C# puoi utilizzare benissimo codice “unsafe”.
jimme
03 gen 2008 - 19:18 - #3@BigSot: JNode è un OS scritto in Java per esempio ;)
I sistemi operativi scritti in un linguaggio managed sicuramente diventeranno sempre più usati in futuro non troppo lontano.
Vantaggi: aumenta la portabilità, si riduce di molto la possibilità di scrivere errori, è possibile dedicare molto più tempo alle funzionalità e alla sicurezza.
Il codice, pur essendo managed, può essere comunque compilato staticamente in codice nativo durante l’installazione senza impattare perciò sulle prestazioni, inoltre è dimostrato da alcuni studi che l’uso di particolari VM che fanno un leggero profiling a runtime può migliorare le prestazioni rispetto a un programma compilato staticamente in codice macchina, che quindi non può usufruire dei dati raccolti per modificare e ottimizzare la sua esecuzione.
Bigshot
03 gen 2008 - 20:03 - #4per ora mi sembrano soluzioni abbondantemente “tirate” per i capelli…
poi certo si può tutto, vedremo
jimme
03 gen 2008 - 20:17 - #5beh si, per adesso sono tutti progetti sperimentali…
albertino80
03 gen 2008 - 21:50 - #6io penso che questa tenenza di rendere tutto portabile, nel 90% dei casi si tramuta in appiattimento. Ciascun sistema operativo ha i propri Pro e Contro, e noi scegliamo uno piuttosto che un altro proprio per beneficiare degli aspetti positivi che quel sistema ci offre. Se rendiamo tutto portabile, introducendo una macchina virtuale di fatto, stiamo solo perdendo i pregi di ciascun sistema per uniformarci in un unico ennesimo sistema con poca “personalità”.
Per quanto riguarda le prestazioni, è dimostrato e stra dimostrato che quei vantaggi di cui parla jimme funzionano solo per benchmark “di laboratorio”, nella realtà una applicazione in una virtual machine non eguaglia mai e poi mai il compilato.
Io ricordo quante critiche (inizio anni 90) si dovette subire il buon vecchio qbasic da parte dei nuovi linguaggi compilati, ora mi pare che stiamo tornando indietro.
kernel_panic
04 gen 2008 - 05:22 - #7albertino hai scritto una discreta quantita’ di sciocchezze ;-)
jimme
04 gen 2008 - 13:00 - #8@albertino: java, .net, python e compagnia non sono più veloci di c++ perche non sono stati progettati per quello, ma per offrire una piattaforma sicura e con più funzionalità.
Le VM a cui accennavo sono una cosa differente, e non sono ancora usate in nessun progetto per ora.
Non si tratta di fare un vero e proprio profiling, ma di raccogliere alcuni preziosi dati durante l’esecuzione e usarli per ottimizzare l’esecuzione del flusso di istruzioni, e il piccolo overhead della VM viene recuperato dal guadagno di prestazioni che permette di ottenere.
albertino80
04 gen 2008 - 18:48 - #9@jimme: pensavo che ti riferissi alle VM “classiche” java e .NET
Hai qualche link in merito alle tecnologie a cui ti riferisci, c’è qualche dimostrazione del guadagno di prestazioni di cui parli o è ancora solo marketing? Non fraintendere il mio tono, sono davvero curioso.
Per quanto riguarda le VM tradizionali, mi riferivo a dimostrazioni tipo questa:
http://www.jelovic.com/articles/why_java_is_slow.htm
Come avrai capito, io sono uno di quelli che crede ancora che java o .net siano solo un c++ con delle funzionalità in meno e qualche obbligo che in c++ è una scelta. Certo, se puoi scegliere, puoi anche sbagliare, ma se non sbagli vinci sempre… in pratica la differenza la fà il programmatore e non il linguaggio. Riguardo alle funzionalità penso che il c++ non habbia nulla ma proprio nulla da invidiare a nessunaltro linguaggio, in c++ si trova di tutto, l’unica differenza è che con sti linguaggi “pseudomoderni” si ha l’illusione di risolvere i problemi e di scrivere codice sicuro, ma se poi guardiamo i fatti, il discorso è ben diverso. Giusto per portare un esempio di codice unmanaged sicuro per eccellenza, mi riferisco alla famiglia unix/linux…
Vi consiglio di leggere cosa pensa colui che il c++ l’ha inventato:
http://www.research.att.com/~bs/bs_faq.html#Java
- Is Java the language you would have designed if you didn’t have to be compatible with C?
- What do you think of C#?
comunque sto andando un po’ OT…
Scusate
@kernel_panic: cosa c’è che non ti piace? il tuo parere soggettivo non aiuta nessuno.
ossmlcr
04 gen 2008 - 21:15 - #10[Per albertino:]
Hai in parte ragione, ma ti spiego dove sta il problema: la VM java di Sun non è pensata per eseguire tutte le ottimizzazioni possibili per il linguaggio, in particolare:
- non può fare l’espansione inline dei metodi
- poichè java, a differenza di c++ o di c#, prevede le chiamate virtual di default, che di fatto sono usate massicciamente in tutti i software, e di conseguenza non è possibile ottimizzare le chiamate di metodo.
C# invece supporta meglio queste due classi di ottimizzazione, per questo il codice compilato di C# si avvicina più strettamente alla performance del c++, mentre java rimane 1,5/2 volte più lento.
Per quel che riguarda il miglioramento addizionale di performance dei linguaggi basati su bytecode rispetto al c++, guarda ad esempio le tecniche di process sealing, che peraltro sono state proposte proprio per il kernel Singularity in C#.
…penso che il c++ non abbia nulla ma proprio nulla da invidiare a nessunaltro linguaggio, in c++ si trova di tutto…
esatto, ha troppo, ha anche le tecniche unsafe, che permettono le violazioni di memoria e quant’altro, oltre a problemi come le classi base fragili - lo sviluppo dei linguaggi su VM ha proprio come obiettivo l’eliminazione di questi problemi.
jimme
04 gen 2008 - 21:21 - #11Quello a cui mi riferivo per esempio è HP Dynamo, un prototipo di un ottimizzatore dinamico che accelera in modo trasparente il codice nativo a run time, con aumenti significativi anche del 20% rispetto al codice eseguito nativamente:
arstechnica.com/reviews/1q00/dynamo/dynamo-1.html
Non è il caso di Java per ora, ma in futuro le piattaforme managed hanno moltissimo margine di miglioramento per quanto riguarda le prestazioni, che comunque già adesso, pur essendo minori di c++, sono più che sufficienti in moltissimi ambiti.
System Crasher
06 gen 2008 - 22:12 - #12Interessante questo SharpOS, ma sbaglio o non ha una vera utilità pratica? Mi chiedo se sarà mai possibile vedere un sistema operativo completo scritto interamente in codice gestito. Mi sembra incredibile… :-D
baluba
07 gen 2008 - 14:38 - #13“Giusto per portare un esempio di codice unmanaged sicuro per eccellenza, mi riferisco alla famiglia unix/linux…”
oggi le comiche! LOL
XMaverick
04 nov 2008 - 17:02 - #14“Giusto per portare un esempio di codice unmanaged sicuro per eccellenza, mi riferisco alla famiglia unix/linux…”
Quoto. Io sviluppo a basso livello in Unix e a basso livello in Windows, usando il C. Ma sono anche programmatore .NET. Beh, sinceramente, comprendendo ovviamente le problematiche prestazionali del Framework .NET, è evidente che il C sotto Unix ha una quantità infinita di problemi, in quando sotto Windows e .NET vengono fatti girare (pesanti) tools di debug JIT che permettono l’individuazione di quasi qualsiasi problema delle chiamate .NET e C, mentre sotto Unix ti puoi affidare solo al core dump e al GDB, che non sempre sono così accurati. Significa giocare di printf in continuazione, sperando che l’applicazione non si blocchi prima che venga scritto lo stdout. .NET è pensato per accelerare lo sviluppo delle applicazioni business, ed ha i suoi colli di bottiglia solo e unicamente nelle applicazioni realtime, premesso che nessuno vieta il fatto di scrivere codice unsafe in C#. Ma sinceramente nelle applicazioni realtime anche il tanto acclamato da osslmcr C++ cede il passo, in quanto genera parecchio codice di overhead per la gestione degli oggetti. Più vai in cerca di prestazioni estreme, più di avvicini all’assembly. Ecco perchè parti di singularity sono scritte proprio in questo linguaggio. Se poi ci aggiungiamo che l’efficienza di un codice non è solo data dal livello in cui stiamo scrivendo, ma anche da come viene formulato l’algoritmo, possiamo verificare facilmente che in C++ spesso viene scritto codice estremamente schifoso, visto che non ha grosse librerie predefinite, mentre nei linguaggi interpretati hai librerie predefinite ottimizzate come da manuale. Se continuiamo a mettere carne al fuoco, potremo trovarci in situazioni dove, come succede già con molti dispositivi mobile, le VM sono implementate a livello hardware e quindi le differenze prestazionali sono nulle.