Link alla notizia: http://www.hwupgrade.it/news/software/cosmos-un-nuovo-microkernel-e-nato_24170.html

Alcuni sviluppatori hanno dato vita ad un nuovo progetto di sistema operativo basato interamente su managed code

Click sul link per visualizzare la notizia.

Cosa cambia tra licenza BSD e GPL?

Cosa cambia tra licenza BSD e GPL?


La BSD è più permissiva permettendo a chiunque di usare il codice sorgente come meglio crede, anche per inserirlo in progetti proprietari, cosa che la GPL vieta obbligando l'utilizzatore a rilasciare il codice nel quale è stato usato codice precedentemente sotto licenza GPL in una licenza GPL compatibile.

Ciao

la licenza BSD è liberale, nel senso che è permesso qualunque uso del SW e del codice sorgente da cui è prodotto, senza imporre restrizioni di nessun tipo, nemmeno sui cosiddetti lavori derivati realizzati a partire da quel SW o traendo spunto da quel SW
( a patto ovviamente di non attribuersene la paternità, eventualmente -c'è una clausola che fa la differenza tra varianti appunto a 4 e a 3 clausole della licenza "bsd" - menzionando espressamente l' autore del codice sorgente impiegato nella propria soluzione finale )

EDIT - ops, preceduto di poco :D


Cosmos comunque è interessante, perchè si pone come sistema operativo completamente virtualizzato, nel senso di impiegare una VM come runtime di più basso livello - al di sotto del kernel ( ma, dettaglio importante menzionato esplicitamente dagli autori nel whitepaper, non si tratterebbe di esecuzione sotto JIT, perchè il kernel verrebbe comunque compilato in codice nativo )

delegando in questo modo alla VM i meccanismi di protezione tra processi il sistema ( o meglio, la sua "immagine" di runtime) potrebbe girare in un' unico spazio di indirizzamento concreto, in questo modo eliminando quello che finora è stato il più grosso "drawback" dei sistemi a microkernel, cioè l' impatto prestazionale di un gran numero di context switch

Ma per "portare" un OS che, in quanto scritto in C#, dovrebbe esistere nel framework .net, devo "portare" anche il framework stesso (vedi mono ?).

Mi sfugge questa piccolezza ! :D


P.S.
E comunque su wii e iphone ci credo solo se lo vedo :cool:

TheMac

Certamente ha molto in comune con Singularity. Ma a differenza di quest'ultimo, Cosmos è completamente pubblico ed è disponibile il 100% del suo codice sorgente.

...con questo molto in comune vuol dire che c'è del codice sorgente uguale da entrambe le parti?

...con questo molto in comune vuol dire che c'è del codice sorgente uguale da entrambe le parti?

lo penso anche io però c' è sotto qualcosa non penso che Microsoft permetta qualcosa del genere loro dicono che M$ non c' entra ma se è imparentato con singularity hanno portato del codice fuori da Redmond mooolto strano !! M$ avrà cmq le mani in pasta

>> Io sono un dipendente a tempo pieno e sono tuttora estremamente coinvolto nelle attività di Microsoft

questo per chi diceva che gli sviluppatori MS non fossero capaci...

sperimentare Cosmos su diversi dispositivi: Wii
Cosmos gira solo su sistemi con architettura x86

Ma il Wii non ha un'architettura PowerPC? :wtf:

Simpatica la cosa!

Piccola nota: il codice è BSD, ma gira su piattaforma .NET
MS ha brevetti su .NET?

decisamente l'ambiguità codice opensource - brevetti prima o poi bisognerà affrontarla.

Wow, un intero kernel tutto scritto in C# , e Microsoft non ha neanche
dovuto pagare per farselo programmare (fortunelli...)

a quando un bel kernel tutto scritto in csh ? o uno tutto in vba (il visual
basic di office, per i profani....)

Ma per "portare" un OS che, in quanto scritto in C#, dovrebbe esistere nel framework .net, devo "portare" anche il framework stesso (vedi mono ?).

Mi sfugge questa piccolezza ! :D


P.S.
E comunque su wii e iphone ci credo solo se lo vedo :cool:

TheMac

pare che l'output sia codice macchina, non gira sotto il framework .net

pare che l'output sia codice macchina, non gira sotto il framework .net
Dicono che è Managed proprio nella definizione :confused:
C# Open Source Managed Operating System

Wow, un intero kernel tutto scritto in C# , e Microsoft non ha neanche
dovuto pagare per farselo programmare (fortunelli...)

a quando un bel kernel tutto scritto in csh ? o uno tutto in vba (il visual
basic di office, per i profani....)

lol...che lavoracci in vba, ai tempi delle superiori ^^
far girare la partita doppia su Excel non era proprio la cosa più facile da fare in 4-5o superiore O_O'

Piccola nota: il codice è BSD, ma gira su piattaforma .NET
MS ha brevetti su .NET?

decisamente l'ambiguità codice opensource - brevetti prima o poi bisognerà affrontarla.
Quale ambiguità ? .Net ha la sua licenza. Il software un'altra.

Dicono che è Managed proprio nella definizione :confused:
C# Open Source Managed Operating System

ho visto che c'è un sottoprogetto (IL2CPU) che serve proprio a generare codice macchina a partire dal sorgente .NET
il suo autore lo descrive così:

IL2CPU is a project to convert IL directly to native machine code. Useful mostly for smaller applications so software can still be written in .NET, but output shipped without the need for the .NET framework to be installed.

forse non è tutto gestito tramite questo tool :boh:

anche me puzza molto questa storia...

A voler pensare male, la licenza BSD permetterà a M$ di inglobare nei suoi prodotti qualsiasi contributo venga fatto a questo Cosmos da parte di terze parti... mica fessi :D :D :D

Infatti l'implementazione dello stack TCP/IP è "rubato" direttamente da uno dei sistemi BSD (non ricordo quale) :D

Volevo dire lo stack TCP/IP di Windows ovviamente...

Quale ambiguità ? .Net ha la sua licenza. Il software un'altra.


L'ambiguita' c'e' eccome: se domani MS decide di cambiare le licenze di
.net in teoria puo' obbligarti a smettere di usare/modificare quel codice.
Se per motivi di studio/lavoro tu decidessi di dedicare delle ore a questo
progetto, nulla poi tutela il tuo lavoro....

Questo progetto mi entusiasma. Adesso scarico lo User Kit e vedo come procedere. Di buono c'è certamente l'integrazione con VisualStudio, che anche solo per il debug è una manna. :D

Spero che lo sviluppo continui, perchè potrebbero aprirsi scenari molto interessanti in futuro per idee come questa.

Ottimo lavoro!
Davvero lodevole!
Stasera proverò a buildarlo, così ci gioco un po' :D

questo IL2CPU mi attizza non poco!
vado subito a cercarlo!!!
:D

comunque la parola "Managed" suona ambigua.
Dal momento che il kernel non può appoggiarsi
e non si appoggia sul framework,
secondo me "Managed" indica
solo il fatto che la memoria è gestita
da un garbage collector
(correggetemi se sbaglio)

Si ma allora, PERCHE' C# ?????

E cmq i vantaggi di un framework sono sotto gli occhi di tutti (vabbe' anche gli svantaggi ma e' un'altra storia). Ma se io "compilo" e' come se tornassi indietro a 10 anni fa quando "includevo le librerie" e poi il "compilatore" produceva codice macchina (piu' o meno).


Mi sfugge il perche', l'ho gia' detto ? :)

TheMac

comunque la parola "Managed" suona ambigua.
Dal momento che il kernel non può appoggiarsi
e non si appoggia sul framework,
secondo me "Managed" indica
solo il fatto che la memoria è gestita
da un garbage collector
(correggetemi se sbaglio)

Infatti, appoggiarsi ad un framework sarebbe un controsenso. Leggendo sul sito, peraltro, si parla di GC, ma non è ancora attivo, e verrà inserito solo nella Milestone 3.

(Milestone 3)
http://gocosmos.org/Milestones/index.aspx

A voler pensare male, la licenza BSD permetterà a M$ di inglobare nei suoi prodotti qualsiasi contributo venga fatto a questo Cosmos da parte di terze parti... mica fessi :D :D :D
Ma che c'entra questo. Ci sono miliardi di linee di codice rilasciate con licenza BSD al mondo. Se è per questo Microsoft ne ha fatto già ampiamente uso in passato.
Cosmos non ha alcun rapporto con Microsoft e per integrare codice BSD non bisogna avere licenza BSD, ma qualsiasi tipo di licenza va bene.

Si ma allora, PERCHE' C# ?????

E cmq i vantaggi di un framework sono sotto gli occhi di tutti (vabbe' anche gli svantaggi ma e' un'altra storia). Ma se io "compilo" e' come se tornassi indietro a 10 anni fa quando "includevo le librerie" e poi il "compilatore" produceva codice macchina (piu' o meno).


Mi sfugge il perche', l'ho gia' detto ? :)

TheMac

Secondo il mio punto di vista, perché C# offre una sintassi e alcune funzionalità che C o C++ non hanno. Tanto per fare alcuni esempi:

- Stringhe come tipo nativo ed unificato.
- Paradigma ad oggetti (meno complesso rispetto a C++, a mio avviso)
- Property (né C né C++ le hanno), Generics (C è fuori causa)

Ce ne sono certamente altre, ma queste sono le prime differenze che mi sovvengono. Ovvio che C# non è certamente migliore di C/C++ (giusto per evitare flame)

Non sono d'accordo con il discorso "compilazione = -10 anni": per un kernel il codice macchina è d'obbligo, sia per performance sia perché si creerebbe un controsenso se fosse richiesto un framework. Il problema vero è che il deployment è stato trascurato per anni, senza che ci si accorgesse che bisognava trovare un sistema efficiente per gestire funzionalità comuni e librerie di terze parti.

Una precisazione: qui stiamo parlando di Cosmos, di kernel, e di sistemi embeded. Su sistemi desktop sono invece più propenso verso il .NET Framework (che uso moltissimo).

L'ambiguita' c'e' eccome: se domani MS decide di cambiare le licenze di
.net in teoria puo' obbligarti a smettere di usare/modificare quel codice.
Se per motivi di studio/lavoro tu decidessi di dedicare delle ore a questo
progetto, nulla poi tutela il tuo lavoro....
Assolutamente no. Chi ha creato il progetto Cosmos distribuisce il sorgente, di cui è titolare dei diritti, come gli torna più comodo ;)

Il fatto che degli sviluppatori Microsoft sviluppino e rilascino software libero dovrebbe convincere anche il più scettico e bigotto della forza di questo modello di sviluppo... O no?

L'ambiguita' c'e' eccome: se domani MS decide di cambiare le licenze di
.net
Che sono standard ISO ed ECMA e quindi disponibili in termini ragionevoli e non discriminatori (RAND (http://en.wikipedia.org/wiki/Reasonable_and_Non_Discriminatory_Licensing)).

Inutili poi farse queste pippe mentali quando progetti come LAME riescono lo stesso a sopravvivere in un ambiente in cui ci sono più e più brevetti ad impedire la creazione di implementazioni davvero libere.

Il fatto che degli sviluppatori Microsoft sviluppino e rilascino software libero dovrebbe convincere anche il più scettico e bigotto della forza di questo modello di sviluppo... O no?
O allo stesso modo potrebbe dimostrare che con con il software libero non si mangia e c'è bisogno di un vero lavoro, magari su software closed source.
Io mi terrei alla larga da entrambi i (semplicistici) punti di vista comunque.

Assolutamente no. Chi ha creato il progetto Cosmos distribuisce il sorgente, di cui è titolare dei diritti, come gli torna più comodo ;)

forse DevilsAdvocate intendeva uno scenario tipo un giorno ms rilascia il framwork 4.0 con una licenza che dice tra l'altro "vietato usarlo per far girare codice rilasciato con licenza bsd"

cosa che cmq scalfirebbe ben poco un progetto come cosmos, per vari motivi, (a meno, per es, di volerlo eseguire su emulatore di cpu x86 che a sua volta gira sul framework nuovo :asd:), tra cui:

- se cosmos è un kernel, non penso proprio giri sopra l'implepmentazione std del framework per win (e ovviamente con l'esempio pessiomistico di cui sopra mi riferivo ad un nuova vers. dell'implementazione by ms di .net)

- in generale, anche in uno scenario di quel tipo, se hai lavorato su codice che potevi far girare liberamente sul framework by ms, è lapalissiano che esiste almeno una versione su cui puoi far girare il tuo lavoro e puoi cmq continuare ad usare quella anche nel caso di una nuova vers. con licenza assurdamente proibitiva

- esistono implementazioni delle specifiche .net non by ms (sebbene ad ora incomplete) e magari un giorno ne esisteranno di migliori/ più complete delle attuali (ergo se un girno cambia in maniera sgradita la licenza del framework di ms, potrebbero esserci altrenative)

problemi di tipo legale più rognosi potrebbero sorgere se una nuova versione delle specifiche fosse accompaganta da pesanti limitazioni alla libertà di implementarla (tipo royalties, divieti percepiti come assurdi, etc.), ma anche in tale caso si uò sempre continuare ad usare l'implementazione della specifica precedente non vessata dai nuovi vincoli (ed eventualmente, se necassario, migrare col tempo il prorio sw su altre piatatforme)

il tutto sottolineando come delle ipotesi pessimistiche menzionate al momento non si scorge alcun "segno" e l'impronta un po' "paranoica" di tali considerazioni allo stato attuale :D

Per un software che si configuri come un layer basilare e necessario per un certo tipo di applicazioni non c'è motivo alcuno di imporre limitazioni sulla licenza d'uso degli applicativi che dovranno interfacciarsi con esso. Tutt'al più potrebbero nascere questioni legate a royalty per l'uso/la distribuzione dello stesso, ma non certo per la licenza di un'applicazione di terze parti. In particolare, questo non ha senso per una licenza closed, a meno di una virata "integralista" che però sarebbe un suicidio commerciale (come il voler imporre all'improvviso delle royalty su un software in precedenza liberamente redistribuibile e soprattutto basato su delle specifiche standard e aperte). Problemi del tipo "non puoi interfacciarti al framework con un programma coperto dalla licenza xyz" potrebbero emergere, casomai (e sempre se consentito dallo standard), con un'implementazione delle specifiche alla base di .net coperta interamente da gpl (perchè fondamentalmente appoggiarsi al framework significa linkare le sue librerie, e se queste sono coperte da gpl allora anche il software che ne fa uso dovrà essere gpl).

L'ambiguita' c'e' eccome: se domani MS decide di cambiare le licenze di
.net in teoria puo' obbligarti a smettere di usare/modificare quel codice.
Se per motivi di studio/lavoro tu decidessi di dedicare delle ore a questo
progetto, nulla poi tutela il tuo lavoro....

Se decide di cambiare la licenza di .NET (in realta' ti riferisci al CLR), chi distribuisce un'applicazione .NET con licenza BSD puo' usare l'implementazione .NET di Mono (open source).

Se decide di cambiare la licenza di .NET (in realta' ti riferisci al CLR), chi distribuisce Cosmos puo' usare l'implementazione .NET di Mono (open source).uhm, non esattamente ...
in questa intervista (http://lab.obsethryl.eu/content/cosmos-one-opensource-csharp-c-based-kernels) ( che suggerisco di leggere comunque) agli sviluppatori del progetto Cosmos, Mono è menzionato esplicitamente insieme alle ragioni per cui è stato scartato ( il licensing, GPL con ecezione claspath ma sempre gpl, la mancanza di alcune funzioni necessarie e presenti nel .Net 3.5, il fatto che il runtime Mono non interagisca direttamente con l' HW ma con l' OS )
How do you guys implement your runtime and do you have something special reserved for it?
Scott Balmos : <...>
IL2CPU is also implemented fully in C#, and currently outputs translated x86 assembly to files, which are then processed by the NAsm assembler utility. IL2CPU will very soon have its own ability to write out native machine code, without NAsm as an intermediary. Basically with IL2CPU, each IL opcode is mapped to a class, which in a standard method for each opcode class, a set of C# calls that basically emit x86 opcodes. e.g. we have new X86.Mov("eax', AddressOf(ourVariable)); Maybe not that exact line, but that's the general idea. Then the Mov x86 opcode class has a standard emitting method which outputs to a stream the appropriate text (or soon, binary machine code).

<...>

Why The BSD License?
Scott Balmos : The BSD license is a compromise recognizing the pragmatism of the current software industry. As a developer, I welcome the freedom and cooperation that the open source world provides. I like the community project-type setup, and have participated in it many times over. However, for a project such as an operating system to be truly viable and accepted down the road, one must recognize the pragmatic nature of closed-source businesses. There is no point denying the existence, and no point denying the potential developer mindset.

While GPL with classpath exceptions makes a good compromise in these situations, one cannot get over the fact that some fanatic components of the Linux movement and the Free Software Foundation have given the GPL a bad name in the eyes of business over the past decade. It doesn't matter that the classpath exception exists, as people are still battling over the definition of linking in a VM situation (such as the JVM & CLR). The base license is still the GPL, which brings too many negative perceptions to a business. The quiet success of the BSD family of operating systems has shown that a pragmatic balance of open source community ideology, and closed source business interests, can coexist successfully.

<....>

Will it be possible to bring your work into a compatible mode with what the Mono project implements as a runtime? Or for technical reasons that may be unfeasible?
Chad Hower : In fact Cosmos uses .NET libraries and just compiles them. One can certainly use the Mono libraries instead, or the Microsoft FCL libraries. But these libraries implement mostly high level functions. The lowest level functions they implement are memory and process management, and of course we have our own libraries for that.

Il problema della relazione tra open e brevetti può essere più complessa. Chiarito che non può riguardare in alcun modo il software che gira su .net nè tantomeno le sue licenze (cioè le licenze di terzi), la questione si riconduce a eventuali componenti/infrastrutture software/modelli (o meta-modelli) che siano solo parzialmente open, specialmente se intesi ad essere uno standard: in questo caso, una prima soluzione accettabile può essere l'imposizione che una simile realtà non possa essere accettata come standard de iure, ovvero che un qualsiasi standard iso o similare, o almeno uno standard che richieda, per la sua efficacia, della massima diffusione possibile e/o sia destinato ad usi in cui sia critica l'indipendenza da un produttore di software, debba essere interamente open spec e royalty free. Altro caso potenzialmente spinoso è quello in cui la componente open sia solo un "involucro" esterno che debba necessariamente (o anche solo possa) interfacciarsi con dei componenti chiusi ed eventualmente coperti da brevetto: in questo caso si potrebbe imporre l'esistenza di alternative aperte alle componenti chiuse contemplate e che l'implementazione di default dello standard preveda l'uso ti tali alternative. Tutto, rigorosamente, IMHO.

Uhm, il riferimento alla gpl credo sia legato alla scelta di usare la bsd license. La GPL prevede la possibilità di introdurre delle eccezioni (non vorrei sbagliare, ma credo che l'exceptions classpath sia il raggruppamento delle eccezioni), come la possibilità di includere il codice coperto da gpl in un software con diversa licenza, cioè di escludere la viralità della gpl in alcuni casi; però, a causa della sua viralità (e, diciamo, delle sue origini) è associata molto spesso all'ideologia per così dire integralista di almeno una parte del movimento open source che fa capo alla free software foundation, e dato che gli sviluppatori di cosmos non vogliono abbracciare nessuna ideologia, ma piuttosto creare una comunità di sviluppatori attorno al progetto senza limitarne le "interazioni" con altri software, nè sviluppi particolari, hanno preferito usare la BSD, che spesso è apprezzata proprio come licenza open source finalizzata alla massima diffusione del codice, piuttosto che una GPL con opportune eccezioni.

Ho dato una controllatina al sito di Mono, e ho visto che usa 3 diverse licenze: gpl per il compilatore C#, Lgpl per il runtime e la Mit per le classi di libreria (così è possibile derivarle - per intenderci, come si fa con i JFrame in Java per costruire la gui di un'applicazione - senza incappare nei vincoli che anche la Lgpl presenta sulle opere derivate). Quindi, non ci sono problemi per quanto riguarda la licenza; le incompatibilità (superabili in futuro) riguardano l'uso di caratteristiche proprie di .Net non ancora supportate in mono e lo stretto legame con visual studio e gli strumenti di building di MS; per il resto, mi pare di leggere delle limitazioni valevoli tanto per Mono quanto per .Net, relative al fatto che Cosmos è pensato per appoggiarsi direttamente all'hardware (per farlo girare, se non ho frainteso, serve qemu), ma si pensa a dei meccanismi per poter usare anche un framework che si appoggi al sistema operativo ospite, come appunto mono e .net, almeno per finalità di debug e similari (oltre alla possibilità di usare le librerie di mono al posto di quelle di .net nella versione compilata, che comunque non dovrebbe produrre problemi, nè per la licenza, nè per l'interazione con l'hardware, visto che, per quanto ho capito, Cosmos usa una sua implementazione delle funzionalità di più basso livello).

Casomai, problemi di licenza, con Mono, potrebbero nascere in relazione agli usi e/o a certe versioni: il runtime di mono (e quindi, certe librerie da compilare e portarsi dietro) è coperto da lgpl, quindi dev'essere possibile, per l'utente finale, aggiornarlo ad una versione successiva, e questo potrebbe non essere (facilmente) possibile nel caso di prodotti embedded (oltre a poter richiedere una ricompilazione). In questi casi servirebbe una licenza commerciale di mono (ottenibile, mi pare, a pagamento).

Secondo il mio punto di vista, perché C# offre una sintassi e alcune funzionalità che C o C++ non hanno. Tanto per fare alcuni esempi:

- Stringhe come tipo nativo ed unificato.
- Paradigma ad oggetti (meno complesso rispetto a C++, a mio avviso)
- Property (né C né C++ le hanno), Generics (C è fuori causa)

Ce ne sono certamente altre, ma queste sono le prime differenze che mi sovvengono. Ovvio che C# non è certamente migliore di C/C++ (giusto per evitare flame)


anche io la vedo così, hanno preferito usare il C# per il linguaggio in se, poi di fatto generano assembly quindi non necessitano di framework
sembra interessante sto progetto :)

Anche se adesso come adesso si potrà fare pochissimo... (il boot e poco altro), qualcuno ha provato a farlo girare su vm?