martedì 7 ottobre 2008

Mono 2.0 guadagna metri su MS.NET

Il celebre progetto open source capeggiato da Miguel de Icaza ha ulteriormente ridotto il gap con il corrispettivo proprietario: tra ottimizzazioni e migliorie, implementa diverse caratteristiche della versione 3.5 di MS.NET Framework

Roma - Con una rincorsa iniziata sette anni fa, il progetto Mono ha ridotto ulteriormente la distanza che lo separa dal MS.NET Framework di Microsoft. Lo ha fatto rilasciando Mono 2.0, una major release capace di implementare alcune caratteristiche chiave del MS.NET Framework 3.x, tra cui il pieno supporto al linguaggio C# 3.0 e alle rispettive estensioni Language Integrated Query (LINQ), che permettono di interrogare i database con una sintassi simile a quella SQL.

Mono 2.0 introduce inoltre il supporto alle API ADO.NET 2.0, ASP.NET 2.0 e Windows Forms 2.0, estendendo così significativamente il numero di applicazioni MS.NET che possono essere fatte girare sul framework open source. Tra queste ci sarà presto anche il noto programma gratuito di fotoritocco Paint.NET, che potrà così affiancarsi, anche su Linux, al classico GIMP.

Secondo gli sviluppatori, il 45% delle applicazioni MS.NET è oggi in grado di girare su Mono senza modifiche, ed il 18% richiede solo modifiche lievi, che richiedono generalmente pochi giorni di lavoro. Un altro 20% di applicazioni può girare su Mono in seguito a importanti modifiche al codice, che potrebbero richiedere settimane o mesi di lavoro. I programmi del tutto incompatibili sarebbero dunque meno del 20%.La nuova versione di Mono promette poi miglioramenti in vari comparti, tra i quali performance e gestione della memoria, e fornisce alcuni nuovi tool di analisi, tra i quali MoMA (Mono Migration Analyzer): questo programma è stato pensato per semplificare la migrazione di applicazioni MS.NET su ambienti Linux.

Per un elenco completo delle nuove caratteristiche si vedano le note di rilascio.

"Con questa release, spero che Mono possa attrarre un bel po' di nuovi sviluppatori e di aziende che dipendono da MS.NET e desiderano migrare i loro sistemi verso Linux", ha commentato Pedro Martinez, uno degli sviluppatori di Mono.

Sebbene la versione 2.0 sia quella che più si avvicina al MS.NET Framework 3.5, Mono manca ancora di diverse cose rispetto alla controparte proprietaria: tra le più importanti vi sono le estensioni Workflow Foundation (WF) e Presentation Foundation (WPF) introdotte da Microsoft con il MS.NET Framework 3.0. Quest'ultima non sembra interessare particolarmente Miguel de Icaza, il fondatore di Mono, mentre la prima potrebbe presto entrare nella roadmap del progetto open source.

Mono 2.0 può essere scaricato da qui per vari ambienti, tra i quali Linux, Mac OS X e Windows. Disponibile anche come macchina virtuale VMware, Mono 2.0 verrà integrato anche su buona parte delle nuove distribuzioni di Linux, probabilmente anche su Ubuntu 8.10.

Nelle prossime settimane il team guidato da de Icaza dovrebbe completare anche la prima versione stabile di Moonlight, implementazione open source del plug-in Silverlight di Microsoft. A livello di funzionalità, questa release sarà allineata a Silverlight 1.0, rilasciato da Microsoft circa un anno fa.

Anche se tra poche settimane debutterà Silverlight 2.0, gli sviluppatori di Moonlight non si sono fatti cogliere del tutto impreparati: già da diversi mesi, infatti, è possibile scaricare versioni preliminari di Moonlight 2.0, una release che implementerà le stesse caratteristiche dell'equivalente versione di Silverlight.

Lo scorso anno gli sviluppatori di Mono hanno aggiunto il supporto a Moonlight in MonoDevelop, un ambiente di sviluppo open source che permette la creazione di applicazioni MS.NET e Silverlight senza ricorrere a Microsoft Visual Studio.

Le versioni di test di Moonlight, compatibili solo con Firefox, possono essere scaricate da qui.
131 Commenti alla Notizia Mono 2.0 guadagna metri su MS.NET
Ordina
  • Ho dei dubbi sinceri sulle percentuali di compatibilità tra le applicazioni esistenti .NET e Mono: credo che quelle compatibili al 100% siano di molto inferiori al 45%.

    Da dove viene questo dato, e in base a quale statistica i programmatori affermano che sia questa la situazione attuale ?
    non+autenticato
  • Ora che mono emula parti di dot net 3.5 sarà possibile far girare con Wine autocad??

    dopo posso saperne di piu'??
    grazie..
    non+autenticato
  • come si vede da questo thread

    https://answers.launchpad.net/ubuntu/+source/mono/...

    non verra' messo in ubuntu 8.10 come si dice nell'articolo.
  • è però inclusa la versione 1.9.1 che è praticamente la beta della 2.0
    ai conti fatti è quasi identica
    tuba
    342
  • Come da oggetto.

    Non è meglio usare Python con interfaccia grafica Qt4, invece di Mono e .NET? Funziona come Java (non è compilato né interpretato, è a bytecode), è facilissimo, potentissimo, ha una bella IDE e un bel designer in stile Visual Studio, e il programma lo scrivi dove vuoi che poi gira su qualsiasi piattaforma. E non ci sono problemi di interpretazioni varie su brevetti e roba legale.

    Lo chiedo a qualche esperto, non è una mia opinione, è solo un'impressione di un profano, quindi potrei tranquillamente sbagliarmi.
  • no Python è libero ed è un linguaggio molto più espressivo di C#

    gli manco solo una virtual machine ma ci stanno lavorando con l'aiuto di Google
    non+autenticato
  • Anche C# è a bytecode...
    E' vero che python è molto semplice ma su applicazioni grosse non rende. Come qualsiasi linguaggio di scripting è almeno 20 volte più lento di un programma compilato scritto in C++ per esempio.
    Se si vuole usare Qt4, e lo dico per esperienza personale, il C++ (con il compilatore GNU in testa) è l'ambiente migliore per sfruttare al massimo tutte le caratteristiche di Qt4, che tra l'altro mette a disposizione un sacco di aggiunte al C++ classico per eliminare quei problemi che lo rendono più ostico di altri.
    non+autenticato
  • no aspè, quando si parla di vm e bytecode allora stiamo implicando già l'uscita da un linguaggio compilato

    e infatti quello che si vuole fare è creare un compilatore per Python

    in quel caso Python finirebbe per rendere quanto C#, Java, Visual Basic e Pascal

    stesso discorso valeva per PHP ad esempio, fino a che non c'erano i vari APC, eAccelerator, Zend optimizer era lentissimo, oggi di fatto è alla pari dei linguaggi compilati
    non+autenticato
  • - Scritto da: pabloski

    > e infatti quello che si vuole fare è creare un
    > compilatore per
    > Python
    >
    > in quel caso Python finirebbe per rendere quanto
    > C#, Java, Visual Basic e
    > Pascal

    Purtroppo no.Sorride

    Per come e` fatto Python (altamente dinamico) un compilatore non migliorerebbe di molto le prestazioni, ma al massimo raddoppierebbe o triplicherebbe la velocita` degli eseguibili.

    E` il prezzo da pagare per avere dizionari che contengono qualsiasi cosa, per esempio, o per passare funzioni in giro come fossero oggetti.

    Croce e delizia del linguaggio.Sorride

    > stesso discorso valeva per PHP ad esempio, fino a
    > che non c'erano i vari APC, eAccelerator, Zend
    > optimizer era lentissimo, oggi di fatto è alla
    > pari dei linguaggi
    > compilati

    Quello di PHP è un problema diverso. APC e eAccelerator fanno quello che Python fa già di suo (i file .pyc): tengono una cache dei precompilati in bytecode.
    In pratica evitano che ad ogni pagina richiesta dal browser sia necessario ricompilare lo script.
    Accelerano di molto (anche 20-30 volte) proprio perché il bytecode PHP è già abbastanza veloce, ma è la fase di compilazione quella lenta.

    Bye.
    Shu
    1150
  • Se ho capito bene si sta parlando di compilazione JIT?

    Il codice C# è prestante perchè il suo bytecode è macinato già da un interprete JIT, e quindi convertendo direttamente il bytecode su istruzioni cpu dirette, le prestazioni sono molto più elevate (anche se inizialmente c'è una fase di "preparazione").

    Su Python esistono alcune soluzioni per JIT (es. Psycho se non erro) ma non sono di default.
  • a compile-time l'ottimizzazione si può fare, perchè i tipi dati sono noti

    nel caso di una compilazione AOT si crea il problema che dici tu, problema che non si presenta invece nemmeno in caso di compilazione JIT

    quello che fanno APC e eAccelerator per PHP si può con Python a patto di mettere in cache un certo numero di versioni dell'eseguibile
    non+autenticato
  • Sinceramente, C++ con le QT non mi piace per niente. Avevo dato un'occhiata tempo fa, (quindi non ne so molto sull'argomento QT), ma quando ho visto che richiede un C- preprocessor specifico solo per lo sviluppo di interfaccie GUI, me ne sono stato molto alla larga. Non e' una soluzione elegante, per niente.

    Sono dell' avviso che se uno sceglie C++ per fare sviluppo GUI, o impara a digerirsi le osticita' del linguaggio ( e non c'e' niente di male ), o forse fa bene a scegliere un'altro linguaggio.

    C++, non e' il linguaggio piu' adatto per 'fregnacce' gui. per quest'ultime non sono richieste neppure prestazioni.

    Utilizzare C++ per sviluppare GUI e' come andare a far la spesa con una testarossa.

    Just my two cents.
  • Il c++ avrà diverse peculiarità e certamente è rapido.

    Ma a livello di sintassi, è orrenda in confronto alle soluzioni moderne di oggi. A sto punto preferisco avere una soluzione Python + C per le parti critiche.

    Secondo me il C++ tiene testa per il codice legacy che gira ancora, e per le conoscenze acquisite in molte ditte.

    Ma per nuovi progetti meglio vedere altro...
    -----------------------------------------------------------
    Modificato dall' autore il 07 ottobre 2008 16.52
    -----------------------------------------------------------
  • - Scritto da: 200 OK
    > Il c++ avrà diverse peculiarità e certamente è
    > rapido.
    >

    La rapidita' nelle applicazioni Gui non e' il fattore determinante.

    > Ma a livello di sintassi, è orrenda in confronto
    > alle soluzioni moderne di oggi. A sto punto
    > preferisco avere una soluzione Python + C per le
    > parti
    > critiche.
    >

    C++ da' al programmatore la potenza ( e lo spago per impiccarsi ) che necessita. Sta a te' usarlo in modo da scrivere cose leggibili o illeggibili.
    La sua sintassi, non e' sotto questo profilo ne' megliore ne' peggiore di quella di un Java o C# del caso.

    Sta al programmatore.

    > Secondo me il C++ tiene testa per il codice
    > legacy che gira ancora, e per le conoscenze
    > acquisite in molte
    > ditte.
    >

    Ci sono campi applicativi dove altri linguaggi per dimensioni del codice prodotto ed efficienza non possono avvicinarsi a quelli ottenibili in C. Pensa a parti 'intimamente' legate al sistema operativo, come device drivers, kernel objects, e ai dispositivi embeeded.

    Non e' pensabile infilare in un dispositivo che ha 32 Mb di RAM un framework come .NET o JAVA, troppo pesanti e lenti.


    > Ma per nuovi progetti meglio vedere altro...
    > --------------------------------------------------
    > Modificato dall' autore il 07 ottobre 2008 16.52
    > --------------------------------------------------

    Se gli ambiti applicativi sono differenti da quelli da me elencati, sicuramente non vale la pena di sviluppare in C++.
    Questo intendevo quando ho scritto 'e' come andare a fare la spesa con una testarossa'.

    Semplicemente non e' l'auto adatta per andare a fare la spesa. Fara' anche i 300 all'ora, ma per fare la spesa mi serve solo un vano bagagli capiente. Occhiolino
  • Uff mi aspettavo una risposta come: hai ragione, esiste un nuovo linguaggio che in 5 min ti fa tutto Rotola dal ridere (scherzo ovviamente) Ficoso

    Però in effetti ho scritto senza conoscere veramente la situazione generale, ma prendendo spunto da alcune riflessioni che avevo fatto ai tempi (avevo usato per diversi anni c++, ma poi abbandonato per vari motivi).
    -----------------------------------------------------------
    Modificato dall' autore il 07 ottobre 2008 23.21
    -----------------------------------------------------------
  • All'epoca Mono rappresentò un'implementazione libera di runtime, linguaggi e librerie portabili. Ora però, con OpenJDK GPL, perché si dovrebbe scegliere quello che è un'implementazione più povera, meno aggiornata, quindi incompatibile, di .NET? Mi chiedo non conviene di più investire tempo, ed anche denaro, su una piattaforma più matura e più supportata? Cioè, secondo me se ci fosse stato OpenJDK all'epoca, Mono manco sarebbe nato.
    FDG
    7105
  • > Mi chiedo non
    > conviene di più investire tempo, ed anche denaro,
    > su una piattaforma più matura e più supportata?
    > Cioè, secondo me se ci fosse stato OpenJDK
    > all'epoca, Mono manco sarebbe
    > nato.


    Probabilmente.
    Ma, una cosa non capisco del tuo discorso: ritieni che .NET/Mono e Java/OpenJDK siano mutualmente escludentisi? Perché?
    non+autenticato
  • - Scritto da: Olmo

    > Probabilmente.
    > Ma, una cosa non capisco del tuo discorso:
    > ritieni che .NET/Mono e Java/OpenJDK siano
    > mutualmente escludentisi?
    > Perché?

    Non so. Vorrei appunto capire per quali ragioni si dovrebbe preferire Mono al posto di OpenJDK.
    FDG
    7105
  • in se le tecnologie sono equivalenti (al di la della stabilità dovuta alla diversa anzianità dei prodotti).

    sono i tools di sviluppo a fare la differenza

    lo sviluppo di un applicazione desktop in windows con visual studio è anni luce avanti qualsiasi altro RAD (questione di tempo e soldi, non di qualità delle persone dell'open source)

    quindi se mono mantenesse le sue promesse, non ci fossero gabole legati etc etc, se sviluppo di app desktop in .NET su windows avrei un vantaggio competitivo (in costi) rispetto lo sviluppo in java a quasi parità di piattaforme supportate.

    perchè è vero che java va tu tantissime piattaforme. ma è anche vero che la maggiorparte degli app desktop va su client ad archittura intel. rimane fuori mac, ma è un problema di tempo anche per quello visto che l'architettura hw è ora la stessa.

    questo in teoria.

    in pratica - a oggi - lo sviluppo di app desktop ha senso solo se potessi raggiungere le piattaforme windows e mac in colpo solo. in quel caso il vantaggio competitivo sarebbe significativo. ma questo lo vedo difficile.
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
1 | 2 | 3 | Successiva
(pagina 1/3 - 15 discussioni)
 

La soluzione ideale per Security and Video Managed: le innovazioni Cisco.

Java & Database

Java & Database

Questo libro cerca di introdurre il lettore in diverse tecnologie che possono essere utilizzate con Java per gestire un database. Saranno quindi trattate tematiche come JDBC, per instaurare [...]