Link all'Articolo: http://www.hwupgrade.it/articoli/telefonia/4901/nuovi-dettagli-su-google-fuchsia-sara-il-successore-di-android_index.html

Emergono interessanti novità sul sistema operativo Google Fuchsia, la cui gestazione era già stata annunciata l'anno scorso pur con enormi dubbi e perplessità. Oggi si sa qualcosa in più e ci prendiamo la libertà di fare qualche ipotesi a fronte delle nuove rivelazioni

Click sul link per visualizzare l'articolo.

Secondo problema: Android è nato prima di iOS (5 novembre 2007 il primo, 9 gennaio 2007 il secondo).

Articolo scritto da Benjamin Button :D

ragionando da profano un'idea potrebbe essere questa: avere un "cuore" del sistema operativo uguale per tutti, non personalizzabile da Samsung e co., affiancato da una interfaccia grafica liberamente modificabile. Un cosa interessante sarebbe se l'interfaccia fosse poi liberamente sostituibile con quella standard google, in modo che nel momento che quella del brand del telefono non viene più aggiornata si può comunque aggiornare il telefono (kernel + GUI) con le ROM ufficiali google

dico boiate?

ragionando da profano un'idea potrebbe essere questa: avere un "cuore" del sistema operativo uguale per tutti, non personalizzabile da Samsung e co., affiancato da una interfaccia grafica liberamente modificabile. Un cosa interessante sarebbe se l'interfaccia fosse poi liberamente sostituibile con quella standard google, in modo che nel momento che quella del brand del telefono non viene più aggiornata si può comunque aggiornare il telefono (kernel + GUI) con le ROM ufficiali google

dico boiate?

Più o meno, perchè si può fare gia adesso con Android quello che dici. Il problema è che molti driver di hardware incluso in alcuni telefoni non sono open source o comunque non disponibili al pubblico. Molte volte bisogna ricorrere a blob estratti as-is. In altri casi i produttori non prevedono o rendono difficile il flash di rom fuori dalle ufficiali (bisogna passare da recovery non ufficiali quando è possibile).

Secondo problema: Android è nato prima di iOS (5 novembre 2007 il primo, 9 gennaio 2007 il secondo).

Articolo scritto da Benjamin Button :D

No, l'ho scritto io ma il secondo doveva essere 2009, è partito un 2007 :D
Grazie della segnalazione, ho corretto. :)

Più o meno, perchè si può fare gia adesso con Android quello che dici. Il problema è che molti driver di hardware incluso in alcuni telefoni non sono open source o comunque non disponibili al pubblico. Molte volte bisogna ricorrere a blob estratti as-is. In altri casi i produttori non prevedono o rendono difficile il flash di rom fuori dalle ufficiali (bisogna passare da recovery non ufficiali quando è possibile).

Vero, ma passare a un kernel con licenza diversa dalla GPL non risolverebbe questo problema.
Ovvero AOSP è la sola versione open source di android che richiede i componenti closed source binari esterni per funzionare (http://www.techrepublic.com/blog/linux-and-open-source/solving-the-open-source-vs-proprietary-driver-debate-in-the-linux-kernel/).
Le versioni "reali" (quelle fornite dai produttori) di android sono comunque closed source e non presentano questo problema.
Passando a un kernel come fuchsia i componenti closed source binari sarebbero comunque necessari e non verrebbero integrati nel kernel (a meno che i produttori non rilasciassero il sorgente).
Dal punto di vista delle licenze, non tecnico, il vantaggio di abbandonare linux a favore di fuchsia è solo di google.

Vero, ma passare a un kernel con licenza diversa dalla GPL non risolverebbe questo problema.


Potrebbe o non potrebbe. Quello che rende e' possibile, e' utilizzare un modello di sviluppo che mantenga la retrocompatibilita' delle api in-kernel o, nel caso in questione, un microkernel con un'interfaccia per i driver retrocompatibile.

In questo caso puoi usare lo stesso driver con diverse versioni del kernel. Come avviene con Windows in pratica, che puoi usare driver per 7 con 10.


Le versioni "reali" (quelle fornite dai produttori) di android sono comunque closed source e non presentano questo problema.


Beh no, il kernel e' sempre GPL e non puoi utilizzarlo senza rispettarne la licenza. Questo non e' un problema per chi realizza applicazione user, ma lo e' per chi realizza i driver. Infatti il driver puo' essere fornito come blob binario, collegato al kernel tramite un pezzo di codice staticamente linkato al kernel ( Nvidia fa cosi' ad esempio ).

Nel caso di Android viene fornito in gpl ( spesso ma non sempre ) la parte kernel di un driver, mentre la parte specifica per Android e' solo binaria. Ad esempio i driver grafici sono fatti cosi'. Certo la domanda che sorge e' oltretutto semplice, ovvero perche' diavolo non forniscono driver opensource, che tanto non e' che dentro ci sono i segreti di Atlantide.



Passando a un kernel come fuchsia i componenti closed source binari sarebbero comunque necessari e non verrebbero integrati nel kernel (a meno che i produttori non rilasciassero il sorgente).


Ma il modello di sviluppo cambierebbe totalmente, grazie al fatto che e' un microkernel. E cambiando la licenza, si potrebbero aggiungere componenti senza dover rilasciare il tutto come opensource.


Dal punto di vista delle licenze, non tecnico, il vantaggio di abbandonare linux a favore di fuchsia è solo di google.

A me viene il dubbio che Google ci possa guadagnare qualcosa. Google ha aggiunto poco e niente al kernel, mentre si e' avvalso di una valanga di tecnologie implementate per Linux da altri.

Se ci guadagnano qualcosa, e' in termini di non dover avere a che fare con la comunita' Linux e poter avere il totale controllo sull'evoluzione del progetto. Pero' il problema e' nato principalmente da loro. Se seguissero le regole e manutenessero il codice come si deve, invece di lasciare in giro solo schifezza, magari la loro roba verrebbe accettata per l'inclusione nel main line.

Potrebbe o non potrebbe. Quello che rende e' possibile, e' utilizzare un modello di sviluppo che mantenga la retrocompatibilita' delle api in-kernel o, nel caso in questione, un microkernel con un'interfaccia per i driver retrocompatibile.

In questo caso puoi usare lo stesso driver con diverse versioni del kernel. Come avviene con Windows in pratica, che puoi usare driver per 7 con 10.

Il problema di avere driver aggiornati per una diversa versione del kernel, soprattutto se questi sono closed source, non è un problema degli sviluppatori del kernel, ma degli sviluppatori dei driver stessi.

Wikipedia (https://en.wikipedia.org/wiki/Linux_kernel_interfaces)
Defining a useful ABI and keeping it stable is less the responsibility of the Linux kernel developers or of the developers of the GNU C Library, and more the task for Linux distributions and Independent software vendor (ISVs) who wish to sell and provide support for their proprietary software as binaries only for such a single Linux ABI, as opposed to supporting multiple Linux ABIs.



Beh no, il kernel e' sempre GPL e non puoi utilizzarlo senza rispettarne la licenza. Questo non e' un problema per chi realizza applicazione user, ma lo e' per chi realizza i driver. Infatti il driver puo' essere fornito come blob binario, collegato al kernel tramite un pezzo di codice staticamente linkato al kernel ( Nvidia fa cosi' ad esempio ).


Mi sono perso forse qualche novità? Ovvero, non ho mai visto i produttori di dispositivi con android a bordo rilasciare il codice sorgente dei loro SO.
Quindi tutti i produttori di dispositivi android (samsung, LG, htc, etc.) violano (https://www.gnu.org/licenses/gpl-faq.en.html#NonfreeDriverKernelLinux) la licenza GPL e i moduli closed source collegati al kernel linux sono illegali (http://www.kroah.com/log/linux/ols_2006_keynote.html).
Lo stesso per nvidia come hai fatto notare tu.


Nel caso di Android viene fornito in gpl ( spesso ma non sempre ) la parte kernel di un driver, mentre la parte specifica per Android e' solo binaria. Ad esempio i driver grafici sono fatti cosi'. Certo la domanda che sorge e' oltretutto semplice, ovvero perche' diavolo non forniscono driver opensource, che tanto non e' che dentro ci sono i segreti di Atlantide.

Sono d'accordo. Mi potresti fornire dei riferimenti per driver GPL lato kernel?


Ma il modello di sviluppo cambierebbe totalmente, grazie al fatto che e' un microkernel. E cambiando la licenza, si potrebbero aggiungere componenti senza dover rilasciare il tutto come opensource.


Essendo microkernel cambierebbe lo sviluppo dei servizi rispetto ai moduli di un kernel monolitico, senza dubbio (https://stackoverflow.com/questions/1806585/why-is-linux-called-a-monolithic-kernel).
La licenza MIT (fuchsia) consente di inglobare i driver binary e non rilasciare il codice sorgente. Cosa cambia rispetto ad adesso? Anche per linux ci sono i driver binary e non viene rilasciato il codice sorgente (violando la licenza GPL).


A me viene il dubbio che Google ci possa guadagnare qualcosa. Google ha aggiunto poco e niente al kernel, mentre si e' avvalso di una valanga di tecnologie implementate per Linux da altri.

Se ci guadagnano qualcosa, e' in termini di non dover avere a che fare con la comunita' Linux e poter avere il totale controllo sull'evoluzione del progetto. Pero' il problema e' nato principalmente da loro. Se seguissero le regole e manutenessero il codice come si deve, invece di lasciare in giro solo schifezza, magari la loro roba verrebbe accettata per l'inclusione nel main line.

Esatto questo è il guadagno. Aver sfruttato linux e la sua comunità per diffondere android (con la violazione della licenza GPL da parte dei produttori di dispositivi) e adesso passare a un progetto fatto in casa.

A me viene il dubbio che Google ci possa guadagnare qualcosa. Google ha aggiunto poco e niente al kernel, mentre si e' avvalso di una valanga di tecnologie implementate per Linux da altri.
Non è proprio così, Google è una delle aziende più attive sul kernel Linux, addirittura Linus T. ha elogiato Google per la qualità delle sue patch.

Non è proprio così, Google è una delle aziende più attive sul kernel Linux, addirittura Linus T. ha elogiato Google per la qualità delle sue patch.

Mi potresti riportare le fonti della tua affermazione?

Linux foundation report 2016-2015 (kernel 3.19 a 4.7) google non è nelle prime 10 posizioni fonte1 (https://www.linuxfoundation.org/announcements/linux-foundation-releases-development-report-highlighting-contributions-to-linux) fonte2 (https://www.linux.com/blog/top-10-developers-and-companies-contributing-linux-kernel-2015-2016).
Linux foundation report 2015-2014 (kernel 3.11 a 3.18) google non è nelle prime 10 posizioni fonte1 (https://www.linuxfoundation.org/news-media/announcements/2015/03/2015-linux-jobs-report-linux-professionals-high-demand).
Linux foundation report 2013-2012 (kernel 3.3 a 3.10) google è in decima posizione con circa 2.5% di contributo fonte1 (https://www.linuxfoundation.org/news-media/announcements/2013/09/linux-foundation-releases-annual-linux-development-report) fonte2 (https://arstechnica.com/information-technology/2013/09/google-and-samsung-soar-into-list-of-top-10-linux-contributors/).


Addirittura un elogio a google, fonte?

Io un piccolo sospetto per questo "eventuale" (quanto ipotetico) cambio di piattaforma ce l'avrei. Le ragioni possono essere tante, e alcune di queste sono state anche citate sia nell'articolo che nei commenti qui sopra; ma io dico, tutto ciò non ha impedito a questo os di imporsi ad un livello tale che nemmeno Google stessa avrebbe inizialmente osato immaginare. E allora quale sarebbe la vera motivazione che potrebbe spingere Mountain View a questo cambio di piattaforma? Secondo me, Google sta temendo la concorrenza. Non quella riconosciuta e conclamata (Apple e Microsoft, per intenderci; con questi sapeva sin dall'inizio di doverci fare i conti), ma quella emergente e con reali possibilità di successo. Sto parlando di Tizen, con alle spalle il colosso coreano Samsung (che guardacaso è anche il campione in casa Android). Perchè Tizen dovrebbe rappresentare un pericolo? Innanzitutto è su base Linux (come e forse più di Android) e poi perchè in ambito IoT e soprattutto Wereables, sta già facendo le scarpe ad Android (nella sua variante Wear). Basti vedere questo grafico:

http://i63.tinypic.com/v8ph7t.png

Senza contare che a livello smartphone sono già alla terza o quarta generazione ma che però restano volutamente confinati nei mercati emergenti, India in primis, per non fare concorrenza ai vari Galaxy & co. Ma che in qualsiasi momento potrebbero far switchare i loro top gamma con Tizen.
Questo pericolo Google l'ha ben presente e in tal caso, contribuire ad una piattaforma che è in comune con la concorrenza non gli va sicuramente giù. Aggiungo che però questo salto potrebbe avere più pericoli che vantaggi. Vedremo come si svilupperà la cosa...

Non è proprio così, Google è una delle aziende più attive sul kernel Linux, addirittura Linus T. ha elogiato Google per la qualità delle sue patch.

Sara', ma a giudicare dalle mazzate che volano tra gli ingegneri di Google e i mantainer del kernel sulla mailing list, direi che la situazione e' ben diversa.

E infatti le prime patch di Google sono state accettate dopo anni, quando Google si e' finalmente degnata di seguire un pochino le linee guida per lo sviluppo del kernel.

se google tira fuori fuchsia lo fa solo per sbarcare su altre piattaforme e non certo perché si sente stretta nelle regole open source di android.
Si parla di un anuovo OS da due anni che possa essere un merge tra il market di android e il dna desktop di chrome os, probabilmente per entrare ufficialmente nel mercato enterprise e fare un po di concorrenza a microsoft.
A google di rilasciare un OS su licenza gpl o closed source o di implementare un kernel linux piuttosto che altro fotte nulla, i soldi continueranno a farli coi servizi e con l'advertising, non mi pare che fino ad oggi abbiano voluto vendere licenze software.

Usare licenza MIT non vuol dire non è essere più Open Source significa solo non essere completamente schierati solo da una parte! Cosa me ne frega a me utente finale[1] se NVIDIA o AMD rilasciano driver Open Source o no? L'importante è che riesca a vedere delle immagini sullo schermo e non uno schermo nero...

Il fatto di usare Micro Kernel permetterebbe appunto una cosa importantissima poter separare i driver dal kernel (su Linux te lo scordi essendo un kernel monolico!) così da poter avere il meglio dei 2 mondi:

1. Google rilascia tutte le versioni di Fuchsia che preferisce
2. Samsumg / Sony / Hawey si fanno i loro driver belli paciarotti sicuri che funzioneranno su ogni versione presente e futura di Fuchsia SENZA dover essere ricompilati / paciottati tutte le volte :D

Cosa succede quando Google crea la nuova versione di Fuchsia chiamandola con un nome di un dolciume? Nulla di "esotico" tutti e terminali anche vecchi si possono aggiornare senza problemi: i driver continueranno a funzionare come accade da 15 anni su Windows e Mac OSX tra l'altro :D

[1] a "me" come sviluppatore di un SO open source un po' interesserebbero pure, ma tanto il codice di quei driver è incomprensibile e anche se lo capissi NON posso copiare il codice: GPL è veleno per Cosmos ;)

Fico:
https://fuchsia.googlesource.com/docs/+/master/book.md

Ma perché iOS è nato nel 2009? Il primo iPhone è stato presentato nel 2007

Dai hanno già ammesso che si sono emozionati quando hanno scritto l'articolo!

Comunque ritornando a Fuchsia c'è molta roba pubblicata su GitHub interessante vedere un'altra implementazione di un Microkernel speriamo questa diventi mainstream ho sempre pensato che fosse la cosa giusta: un OS "object based"!

Peccato che poi il kernel sia scritto in C che fa tanto anni '50... almeno fosse scritto in C++ come BeOS / Haiku (1990), ma il C non si può proprio vedere.

Anche Dart come linguaggio per il livello utente non mi convince granché devo dire spero che permettano di usare anche Java e C#.
(Google è membro della .Net Foundation quindi di per sé non ha nulla contro .Net)

Ma perché iOS è nato nel 2009? Il primo iPhone è stato presentato nel 2007Non che mi interessi molto, ma stando alla Wiki (vedete voi se darle credito o meno) la prima versione di iOS è del 29 Giugno 2007, la prima di Android del 23 Settembre 2008.

Per completezza, cito:
Il sistema operativo è stato presentato il 9 gennaio 2007 al Macworld Conference & Expo di San Francisco e la versione 1.0, ancora priva di nome, è entrata in commercio con il primo iPhone il 29 giugno dello stesso anno[2]. Il 6 marzo 2008, in concomitanza con la pubblicazione della prima beta del SDK, il sistema operativo è stato denominato ufficialmente come "iPhone OS" (che sta per "iPhone Operating System")[3].

L'11 luglio 2008 viene pubblicato, in concomitanza della vendita di iPhone 3G, l'aggiornamento a iPhone OS 2 che aggiunge, tra le altre funzioni, il molto atteso App Store e la possibilità di installare applicazioni di terze parti tramite quest'ultimo.

iPhone OS 3, pubblicato con l'iPhone 3GS il 17 giugno 2009, ha aggiunto molte funzioni che furono richieste dagli utenti, alcuni dei quali il copia e incolla e gli MMS. Tutti i dispositivi erano aggiornabili a iPhone OS 3, ma con delle limitazioni per la prima generazione di iPhone e iPod touch. Il primo iPad, entrato in commercio nell'aprile 2010, ha avuto inizialmente un "ramo" separato di iPhone OS 3[4], fino all'unificazione con gli altri dispositivi con la versione 4.2.1 del software[5].

Cosa me ne frega a me utente finale[1] se NVIDIA o AMD rilasciano driver Open Source o no? L'importante è che riesca a vedere delle immagini sullo schermo e non uno schermo nero...

Magari fosse cosi' semplice. Datagate, backdoor, vulnerabilita' intenzionali o meno, i computer non sono piu' meri strumenti tecnici ma veri e propri hub interfacciati con le nostre vite.

Il problema andrebbe affrontato e risolto per via legislativa ovviamente, c'e' ben poco che possa fare una licenza, come poi dimostrato da 26 anni di kernel Linux infarcito di blob binari.


Il fatto di usare Micro Kernel permetterebbe appunto una cosa importantissima poter separare i driver dal kernel (su Linux te lo scordi essendo un kernel monolico!)

In verita' si puo' benissimo fare con un kernel monolitico modulare ( quale Linux e' ), basta mantenere l'ABI stabile. Il punto e' che cio' non si vuole fare, proprio per forzare chi scrive driver a rilasciarli come opensource.

L'essere microkernel ha invece il vantaggio di portare i driver in user-space, cosa che aumenta oggettivamente la stabilita' del sistema, ma penalizza le prestazioni. Di quanto? E' questione di dibattito da decenni. Ed e' questione di preferenze quale modello di kernel implementare.


1. Google rilascia tutte le versioni di Fuchsia che preferisce
2. Samsumg / Sony / Hawey si fanno i loro driver belli paciarotti sicuri che funzioneranno su ogni versione presente e futura di Fuchsia SENZA dover essere ricompilati / paciottati tutte le volte :D

E qui casca l'asino purtroppo. Un commento su Osnews e' decisamente illuminante a riguardo http://www.osnews.com/comments/29802

"Hardware vendors are very happy with the Linux breaking their closed source drivers all the time. This means the OEM vendor has to pay the hardware vendor every time they want top update.

If Fuchsia has a stable driver ABI with stable drivers this means hardware vendors make less cash.

You are aware of difficulties caused with proprietary drivers you are not aware that the ones that release their drivers open source Fuchsia will have not trouble getting the ones that keep there drivers closed source are not interested in a stable driver ABI as this will mean less income for them.

So Fuchsia design equals head to head with hardware vendors.

Microsoft end up with Windows phone being restricted to a single hardware vendor and Fuchsia could face the same problem.

Having the Fuchsia kernel MIT license I see it only a matter of time until a hardware vendor makes a customised version so creating unstable driver ABI all over again because that is a feature they want."

L'eventuale vantaggio per l'utente diventa uno svantaggio per chi produce hardware. E diventa uno svantaggio per gli OEM che non possono piu' forzare l'obsolescenza programmata. Essendo Fuchsia opensource, potrebbero essere tentati di produrre fork incompatibili con l'originale, per mantenere il controllo sul periodo di obsolescenza.


[1] a "me" come sviluppatore di un SO open source un po' interesserebbero pure, ma tanto il codice di quei driver è incomprensibile e anche se lo capissi NON posso copiare il codice: GPL è veleno per Cosmos ;)


La stragrande maggioranza dei driver Linux sono BSD e MIT. Cosmos e' BSD ed e' pure microkernel. E se FreeBSD ( che pure e' BSD ma monolitico ) ha potuto portato moltissimi driver Linux, non vedo perche' per Cosmos dovrebbe essere un problema. Dal punto di vista delle licenze ovviamente...

Forse la lunga assenza della possibilità di aggiornare android sta per terminare.
Il nuovo progetto treble (https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html?m=1) incluso in android O (8) consentirà di eliminare il problema fondamentale dei driver...

Non capisco come questo "Treble" potrebbe funzionare usando Android il kernel Linux... forse fanno una sorta di interfaccia Message Passing? La vedo dura adattare un kernel monolitico a fare il lavoro di un microkernel :D
Sinceramente mi pare che gli convenga non cercare soluzioni accrocchiate, ma fare un nuovo Android con il loro kernel... se fanno le cose per bene le app manco devono essere toccate (basta creare una nuova versione di DVM, no?).

Riguardo i driver per X ero convinto che tutto quello fosse dentro il tree di Linux dovesse essere GPL... questo mi rassicura che almeno quel codice "posso guardarlo" serenamente!
Certo poi non è Cosmos possa usarlo direttamente è scritto in C e il codice C non può girare su Cosmos ovviamente...

Non capisco come questo "Treble" potrebbe funzionare usando Android il kernel Linux... forse fanno una sorta di interfaccia Message Passing? La vedo dura adattare un kernel monolitico a fare il lavoro di un microkernel :D
Sinceramente mi pare che gli convenga non cercare soluzioni accrocchiate, ma fare un nuovo Android con il loro kernel... se fanno le cose per bene le app manco devono essere toccate (basta creare una nuova versione di DVM, no?).

Direttamente dal link che ho fornito nel commento precedente:
This is achieved by the introduction of a new vendor interface between the Android OS framework and the vendor implementation. The new vendor interface is validated by a Vendor Test Suite (VTS), analogous to the CTS, to ensure forward compatibility of the vendor implementation.

Per i dettagli occorre solo aspettare:
We plan to publish the full documentation for Project Treble on source.android.com with the launch of O later this summer.

Non credo sia una scelta saggia abbandonare il kernel linux, ma questo lo potremo scoprire solo in futuro.


Riguardo i driver per X ero convinto che tutto quello fosse dentro il tree di Linux dovesse essere GPL... questo mi rassicura che almeno quel codice "posso guardarlo" serenamente!
Certo poi non è Cosmos possa usarlo direttamente è scritto in C e il codice C non può girare su Cosmos ovviamente...

Non ho ben capito questa affermazione.

Dentro Cosmos possono girare solo linguaggi .Net (e assembler, ma solo nel ring Core quello di più basso livello) quindi si deve fare prima un porting in C# del driver in ogni caso.

Se il codice del drvier fosse stato GPL io credo che anche il porting avrebbe dovuto essere licenziato GPL cosa questa per noi inaccettabile è per questo che dicevo "non posso nemmeno guardarlo" :D

Dentro Cosmos possono girare solo linguaggi .Net (e assembler, ma solo nel ring Core quello di più basso livello) quindi si deve fare prima un porting in C# del driver in ogni caso.

Se il codice del drvier fosse stato GPL io credo che anche il porting avrebbe dovuto essere licenziato GPL cosa questa per noi inaccettabile è per questo che dicevo "non posso nemmeno guardarlo" :D

Ma con Visual Studio Community 2017 si può lavorare a CosmOS, vero?

Se il codice del drvier fosse stato GPL io credo che anche il porting avrebbe dovuto essere licenziato GPL cosa questa per noi inaccettabile è per questo che dicevo "non posso nemmeno guardarlo" :D

La GPL riguarda l'utilizzo di codice licenziato sotto GPL, non il porting. Se io prendo Linux e lo riscrivo da zero in Rust, senza usare una riga di codice dell'originale, non possono certo venirmi a dire che devo licenziarlo sotto GPL.

Ma e' un non problema, perche' driver GPL sono una rarita' in Linux.

La GPL riguarda l'utilizzo di codice licenziato sotto GPL, non il porting. Se io prendo Linux e lo riscrivo da zero in Rust, senza usare una riga di codice dell'originale, non possono certo venirmi a dire che devo licenziarlo sotto GPL.

Ma e' un non problema, perche' driver GPL sono una rarita' in Linux.

Esatto.

Ma con Visual Studio Community 2017 si può lavorare a CosmOS, vero?

Ancora no, ma non tanto per il "porting" a VS2017, ma perché useremo Net Core invece di Net Framework che essendo pensato per essere "portabile" dovrebbe semplificarci la vita... per ora ce la sta incasinando visto che è cambiato il sistema di compilazione e ci stiamo lavorando da 3 - 4 mesi ormai :eek:

Stavolta però dovremo essere vicini per davvero... quando sarà il momento aggiornerò prontamente il thread su Cosmos in firma :D

Ancora no, ma non tanto per il "porting" a VS2017, ma perché useremo Net Core invece di Net Framework che essendo pensato per essere "portabile" dovrebbe semplificarci la vita... per ora ce la sta incasinando visto che è cambiato il sistema di compilazione e ci stiamo lavorando da 3 - 4 mesi ormai :eek:

Stavolta però dovremo essere vicini per davvero... quando sarà il momento aggiornerò prontamente il thread su Cosmos in firma :D

Quindi, ad oggi, come si può iniziare a contribuire? Io ho solo VS Community 2017 a portata di mano :-\

Beh puoi testare il branch Net Core e trovare bug... il "collega" ha committato una nuova versione stanotte dal titolo "Build Fixes" quindi ora potrebbe essere utilizzabile...