Link alla notizia: http://www.hwupgrade.it/news/business/ibm-interessata-ad-acquisire-sun_28407.html

Alla ricerca di un acquirente da tempo, Sun potrebbe entrare nella famiglia di IBM con un'azione che rafforzerà IBM nel segmento delle soluzioni server

Click sul link per visualizzare la notizia.

IBM è stata già accusata per il presunto monopolio del mercato mainframe:
http://news.zdnet.com/2100-9595_22-262970.html

Adesso attacca quello server, e non è di poco conto, perchè vale ben più di quello mainframe.

E' un vero dispiacere vedere SUN chiudere la sua gloriosa storia in questo modo :(

IBM è stata già accusata per il presunto monopolio del mercato mainframe:
http://news.zdnet.com/2100-9595_22-262970.html

Adesso attacca quello server, e non è di poco conto, perchè vale ben più di quello mainframe.

E' un vero dispiacere vedere SUN chiudere la sua gloriosa storia in questo modo :(

ma.. io non la vedo una fine così ingloriosa... dopotutto IBM è un ottimo partner... Sarebbe stat peggio vederla chiudere del tutto visto che Sun è veramente una nicchia per pochi accoliti... Rifluendo in IBM ed incrementandone il Know-how, non morirà, magari verrà implementato e/o migliorato...
IMHO, visto che di server alto livello non ci chiappo una mazza, la mia è solo un'intuizione "aziendale".
ciao

Questa per me è un'amara notizia.
Come si collocherà il Sun System Application Server nei confronti di WebSphere?
Come si collecherà Netbeans nei confronti di Eclipse?
Come si collocheranno tutte le tecnologie Java presenti e future in generale?
Come si collocherà MySQL in relazione a DB2?
Come si collocherà Solaris rispetto a AIX?
Che ne sarà del JCP? Verrà stravolto? Reso meno aperto di quello che è?
Sun è la società open source piu' grande del mondo. Che ne sarà di tutto il ben di Dio che hanno creato?
Come può la linea di server SPARC e SunFire coesistere con la linea Blade server di IBM?

A me questa piu' che una manovra dai lauti benefici mi sembra solo una manovra ammazza-concorrenza.

ma.. io non la vedo una fine così ingloriosa... dopotutto IBM è un ottimo partner... Sarebbe stat peggio vederla chiudere del tutto visto che Sun è veramente una nicchia per pochi accoliti... Rifluendo in IBM ed incrementandone il Know-how, non morirà, magari verrà implementato e/o migliorato...
IMHO, visto che di server alto livello non ci chiappo una mazza, la mia è solo un'intuizione "aziendale".
ciao

Sun una nicchia per pochi accoliti? Hai presente il market share di Java nei sistemi enterprise e delle relative divisioni mobility? Puoi acquistare per caso un lettore blu-ray senza avere una licenza allegata di JME-BD? No...
Altro che pochi accoliti. Tutti nel loro piccolo, anche inconsapevolmente, usano tecnologie Sun. Tu stesso lo stai facendo postando su questo forum. Non diciamo eresie per favore. Sun ha creato tecnologie davvero rilevanti che fanno parte della vita di tutti i giorni di tutti, anche coloro che non sanno di utilizzarle. E' forse una delle aziende piu' importanti in questo campo, se non la piu' importante, a prescidendere dai valori di mercato e dai market share delle varie divisioni.

Questa per me è un'amara notizia.
Come si collocherà il Sun System Application Server nei confronti di WebSphere?
Come si collecherà Netbeans nei confronti di Eclipse?
Come si collocheranno tutte le tecnologie Java presenti e future in generale?
Come si collocherà MySQL in relazione a DB2?
Come si collocherà Solaris rispetto a AIX?
Che ne sarà del JCP? Verrà stravolto? Reso meno aperto di quello che è?
Sun è la società open source piu' grande del mondo. Che ne sarà di tutto il ben di Dio che hanno creato?
Come può la linea di server SPARC e SunFire coesistere con la linea Blade server di IBM?

minchia! che lingua è? tra le altre cose non sapevo che Sun fosse open-source ... allora temo saranno Ca**i...

Non pensavo che sun navigasse in cattive acque, è un vero peccato e un duro colpo per il mondo open source

bah, solaris magari aveva senso un tempo, ora le nuove generazioni di amministratori di sistema si sono spostati verso linux.

Questa per me è un'amara notizia.
Come si collocherà il Sun System Application Server nei confronti di WebSphere?
Come si collecherà Netbeans nei confronti di Eclipse?
Come si collocheranno tutte le tecnologie Java presenti e future in generale?
Come si collocherà MySQL in relazione a DB2?
Come si collocherà Solaris rispetto a AIX?
Che ne sarà del JCP? Verrà stravolto? Reso meno aperto di quello che è?
Sun è la società open source piu' grande del mondo. Che ne sarà di tutto il ben di Dio che hanno creato?
Come può la linea di server SPARC e SunFire coesistere con la linea Blade server di IBM?

A me questa piu' che una manovra dai lauti benefici mi sembra solo una manovra ammazza-concorrenza.
infatti...oltre all'hardware che ne sarebbe di tutte queste tecnologie software sviluppate e mantenute da Sun?
Che tristezza..:(

Dico solo: VirtualBox e Openoffice, che fine faranno?
Questa non è "roba da server", ma per l'utente comune.

Ma per le ripercussioni per il mercato, spero che IBM non faccia con SUN, come Compaq nel 1998 quando compro Digital: smembrata e ridotta ai minimi termini, vendendo i pezzi a destra e manca.

Solaris aveva senso un tempo? Non scherziamo! :D

Questa per me è un'amara notizia.
Come si collocherà il Sun System Application Server nei confronti di WebSphere?
Come si collecherà Netbeans nei confronti di Eclipse?
Come si collocheranno tutte le tecnologie Java presenti e future in generale?
Come si collocherà MySQL in relazione a DB2?
Come si collocherà Solaris rispetto a AIX?
Che ne sarà del JCP? Verrà stravolto? Reso meno aperto di quello che è?
Sun è la società open source piu' grande del mondo. Che ne sarà di tutto il ben di Dio che hanno creato?
Come può la linea di server SPARC e SunFire coesistere con la linea Blade server di IBM?

A me questa piu' che una manovra dai lauti benefici mi sembra solo una manovra ammazza-concorrenza.

Websphere spero muoia tra atroci sofferenze in favore di BEA o persino di JBOSS
Su Netbeans e Eclipse non mi pronuncio non essendo ferrato in materia
Java direi che non corre alcun rischio
MySQL e DB2 non li ritengo nemmeno lontanamente paragonabili come caratteristiche e target.
Solaris anche ha il suo parco clienti che rimarranno per anni e anni fermi su quella piattaforma, ci vorrebbero decenni per spostare harwdare, applicazioni, customizzazioni, da un OS all'altro. Fermo restando che tra i *nix più diffusi è quello che meno mi ha dato senso di sicurezza e stabilità, vista anche la scarsa affidabilità dei server Sun. Sempre opinione personale e dettata da quei pochi anni di esperienza, ovviamente. Lungi da me voler essere verità assoluta. :)

Websphere spero muoia tra atroci sofferenze in favore di BEA o persino di JBOSS
Su Netbeans e Eclipse non mi pronuncio non essendo ferrato in materia
Java direi che non corre alcun rischio
MySQL e DB2 non li ritengo nemmeno lontanamente paragonabili come caratteristiche e target.
Solaris anche ha il suo parco clienti che rimarranno per anni e anni fermi su quella piattaforma, ci vorrebbero decenni per spostare harwdare, applicazioni, customizzazioni, da un OS all'altro. Fermo restando che tra i *nix più diffusi è quello che meno mi ha dato senso di sicurezza e stabilità, vista anche la scarsa affidabilità dei server Sun. Sempre opinione personale e dettata da quei pochi anni di esperienza, ovviamente. Lungi da me voler essere verità assoluta. :)

Come puoi essere sicuro che non corre alcun rischio Java? Io non parlo di Java "come prodotto". Io parlo di Java "come community" che sta alla base di tutto ciò che viene ratificato per la produzione. Ormai dietro a queste cose ci sono comunità spaventose, con un'organizzazione davvero complessa e articolata. Prendi per esempio OpenJDK, Glassfish, il Mobile & Embedded group, OpenJavaFX, i SwingLabs, ecc. Non solo "Java" in se, ma anche per tutto il resto.
Non basta aprire i sorgenti per rendere un software di successo un progetto open source di successo. C'è anche la gestione delle comunità, che forse è una delle parti piu' complesse.
Sun forse è l'unica società software ad aver reso open source tutto il suo parco software. Dall'utente comune con OpenOffice all'utente enterprise con SJSAP, passando appunto per Solaris. Soprattutto questo poveraccio di Solaris, vedremo mai Nevada finale e pronto una volta per tutte?
Sono d'accordo per JBoss, ma quello è di proprietà RedHat e comunque le specifiche JEE sugli application server sono comunque definite dal progetto Glassfish, di cui JBoss è un'implementazione.

EDIT: Quanto a MySQL vs DB2, non mi riferivo alle "carattestiche e target", quanto al fatto che MySQL AB è già stata acquisita a sua volta da Sun. Ora che la Sun potrebbe passare in mano a IBM, potrebbero esserci altri stravolgimenti non proprio sani per il progetto. Già il creatore originale di MySQL aveva lasciato la società perchè non era piu' interessato. Chissà che altri casini faranno. E comunque di DB2 esiste una versione "light" che va proprio a intersecarsi con il target di MySQL.

Come puoi essere sicuro che non corre alcun rischio Java? Io non parlo di Java "come prodotto". Io parlo di Java "come community" che sta alla base di tutto ciò che viene ratificato per la produzione. Ormai dietro a queste cose ci sono comunità spaventose, con un'organizzazione davvero complessa e articolata. Prendi per esempio OpenJDK, Glassfish, il Mobile & Embedded group, OpenJavaFX, ecc. Non solo "Java" in se, ma anche per tutto il resto.

Sun forse è l'unica società software ad aver reso open source tutto il suo parco software. Dall'utente comune con OpenOffice all'utente enterprise con SJSAP, passando appunto per Solaris. Soprattutto questo poveraccio di Solaris, vedremo mai Nevada finale e pronto una volta per tutte?

Hai ragione, ma viste le notevoli difficoltà finanziare di Sun, chi potrebbe garantire la continuità di quella community?

MySQL e DB2 non li ritengo nemmeno lontanamente paragonabili come caratteristiche e target.
:)

mi hai anticipato, stavo per scrivere la stessa cosa; professionalmente sono 10 anni che sviluppo software in ambienti mainframe e server ibm e ho avuto a che fare con MySQL per altri scopi personali...sono db che hanno destinazioni d'uso e quindi caratteristiche diverse, totalmente diverse

Che ne sarebbe poi dei processori Niagara? (tra i migliori come rapporto performance/w)

Se l'Unione Europea accetterà questa acquisizione, sarà l'ennesima dimostrazione che è solo anti-Microsoft.

E la accetterà.

Non è poi che IBM sia così tanto contro l'open source...anzi. Già molte tecnologie di IBM si basano su Java: i già citati WebSpere (e tutto quello che gli gira intorno) ed Eclipse, SWT, la JVM J9...ad esempio. La maggior parte di queste tecnologie è già ora open source.
La mossa di comprare Sun sarebbe più che naturale, anche solo per Java. Senza contare poi il mercato server, che per loro sarebbe la ciliegina sulla torta.
IBM è da anni che contribuisce allo sviluppo di Linux. Ricordiamoci anche che IBM, in piena bufera Novell, dichiarò di non voler far valere i propri diritti su possibili infrazioni ai propri brevetti ad opera del mondo Linux.
Non dimentichiamoci anche un recente acquisto di Sun, cioè VirtualBox. E' un software di virtualizzazione moderno e funzionale, potrebbe tornare molto utile ad IBM.
Riguardo a MySQL: dalle ultime modifiche alla licenza per me è morto :O Chissà che magari non ci faccia un bel regalo portando MySQL all'open source, quello vero.
Anche OpenOffice passerebbe ad IBM.

ragazzi
l'offerta di 7 miliardi di dollari è relativamente bassa, segno che Sun alla fin fine poi sto colosso enorme non lo era...

ragazzi
l'offerta di 7 miliardi di dollari è relativamente bassa, segno che Sun alla fin fine poi sto colosso enorme non lo era...

Un colosso lo è. 40.000 dipendenti non sono certo la società a conduzione familiare con sede operativa in garage, a prescindere dalle quote che ha raggiunto. E' sicuramnte una società da annoverare fra i "colossi" e come importanza dei prodotti e le innovazioni apportate non è seconda a nessuno, in determinati ambiti. Che poi la divisione server (hardware) se la passi male ok, ma ci sono settori in cui Sun è imperiale.

Non è poi che IBM sia così tanto contro l'open source...anzi. Già molte tecnologie di IBM si basano su Java: i già citati WebSpere (e tutto quello che gli gira intorno) ed Eclipse, SWT, la JVM J9...ad esempio. La maggior parte di queste tecnologie è già ora open source.
La mossa di comprare Sun sarebbe più che naturale, anche solo per Java. Senza contare poi il mercato server, che per loro sarebbe la ciliegina sulla torta.
IBM è da anni che contribuisce allo sviluppo di Linux. Ricordiamoci anche che IBM, in piena bufera Novell, dichiarò di non voler far valere i propri diritti su possibili infrazioni ai propri brevetti ad opera del mondo Linux.
Non dimentichiamoci anche un recente acquisto di Sun, cioè VirtualBox. E' un software di virtualizzazione moderno e funzionale, potrebbe tornare molto utile ad IBM.
Riguardo a MySQL: dalle ultime modifiche alla licenza per me è morto :O Chissà che magari non ci faccia un bel regalo portando MySQL all'open source, quello vero.
Anche OpenOffice passerebbe ad IBM.

Sicuramente, però io non vedo in IBM lo stesso potenziale di gestione a livello di community che aveva Sun. Poi nulla si può dire, perchè non sappiamo se Sun rimarrà come "una sussidiaria" di IBM o sradicheranno proprio il marchio.
Tra l'altro le mie conoscenze in materia di tipologie di acquisizioni è prossima allo zero assoluto.
Certo è che fondere due aziende come IBM e Sun dev'essere un casino madornale. Già sto pensando alle posizioni duplicate che si verificheranno. E quà parliamo di aziendoni, quindi probabilmente a casa se ne andrà un sacco di gente (che magari a livello di competenza in determinati settori era pure piu' appropriata del corrispettivo personale IBM).

Un colosso lo è. 40.000 dipendenti non sono certo la società a conduzione familiare con sede operativa in garage, a prescindere dalle quote che ha raggiunto. E' sicuramnte una società da annoverare fra i "colossi" e come importanza dei prodotti e le innovazioni apportate non è seconda a nessuno, in determinati ambiti. Che poi la divisione server (hardware) se la passi male ok, ma ci sono settori in cui Sun è imperiale.

fammi però dire che a questo punto il rapporto numero di dipendenti / valore della società non è dei migliori...

_________________________________
Notizia di maggio 2008:
Sun-MySQL in rosso, partono i primi licenziamenti
pubblicato: venerdì 09 maggio 2008 da Hispanico in: Sun Varie MySQL

Era nell’aria ormai da tempo e, nonostante gli analisti avessero previsto il contrario, Sun Microsystem ha in questi giorni confermato quanto emerso dalla prime indiscrezioni. A causa dell’acquisizione di MySQL, il colosso californiano ha accusato nel terzo periodo fiscale, conclusosi il 30 marzo scorso, una perdita di 34 milioni di dollari ed il fatturato è passato da 3,28 a 3,27 miliardi di dollari.

Le spiegazioni di questo dissesto sarebbero da ricercarsi nella crisi nera che sta affliggendo i mercati americani che, dopo l’enorme sborso di denaro per l’acquisto di MySQL, ha provocato in Sun un vero e proprio effetto domino.

Per correre ai ripari, la società ha deciso di intervenire con una riduzione del personale ed a farne le spese saranno proprio i dipendenti della neo-acquisita MySQL; nessuna cifra ufficiale è stata ancora annunciata ma secondo voci molto vicine all’azienda, verrà tagliato circa il 7% dell’attuale forza lavoro, il che tradotto significa mandare a casa 2000-2500 persone.

_______________________________________

Ora vista oltrettutto la crisi che c'è...
La mia azienda ha circa 30000 dipendenti e fattura circa 12 miliardi di dollari l'anno...

fammi però dire che a questo punto il rapporto numero di dipendenti / valore della società non è dei migliori...

_________________________________
Notizia di maggio 2008:
Sun-MySQL in rosso, partono i primi licenziamenti
pubblicato: venerdì 09 maggio 2008 da Hispanico in: Sun Varie MySQL

Era nell’aria ormai da tempo e, nonostante gli analisti avessero previsto il contrario, Sun Microsystem ha in questi giorni confermato quanto emerso dalla prime indiscrezioni. A causa dell’acquisizione di MySQL, il colosso californiano ha accusato nel terzo periodo fiscale, conclusosi il 30 marzo scorso, una perdita di 34 milioni di dollari ed il fatturato è passato da 3,28 a 3,27 miliardi di dollari.

Le spiegazioni di questo dissesto sarebbero da ricercarsi nella crisi nera che sta affliggendo i mercati americani che, dopo l’enorme sborso di denaro per l’acquisto di MySQL, ha provocato in Sun un vero e proprio effetto domino.

Per correre ai ripari, la società ha deciso di intervenire con una riduzione del personale ed a farne le spese saranno proprio i dipendenti della neo-acquisita MySQL; nessuna cifra ufficiale è stata ancora annunciata ma secondo voci molto vicine all’azienda, verrà tagliato circa il 7% dell’attuale forza lavoro, il che tradotto significa mandare a casa 2000-2500 persone.

_______________________________________

Ora vista oltrettutto la crisi che c'è...
La mia azienda ha circa 30000 dipendenti e fattura circa 12 miliardi di dollari l'anno...

Io non ho affatto messo in relazione dipendenti / valore della società. Ho solo risposto a chi diceva che Sun "non è poi sto colosso", infatti il valore della società è proprio l'ultima cosa che intendevo prendere in causa. Sarà un colosso in crisi, non ci piove, ma sempre un colosso è.
EDIT: poi gli economisti sentirmi parlare si scandalizzeranno sicuramente, ma il concetto mi sembrava chiaro. In questo ragiono "da comune mortale" con competenze economiche nulle. :D Nella mia definizione di "colosso" prendo solo in considerazione il fatto che è comunque è un'azienda che dava da mangiare a 40.000 persone, nulla piu'. :p

ragazzi
l'offerta di 7 miliardi di dollari è relativamente bassa, segno che Sun alla fin fine poi sto colosso enorme non lo era...

Beh le borse vanno così di merda che la cifra proposta è il doppio del valore di mercato delle azioni....

CMQ non sarei così tragico.

IBM ha il 39% del mercato dei server, non il 90%. Se è l'unica azienda a proporre mainframe è colpa degli altri che hanno abbandonato un mercato che credevano morto (e probabilmente a ragione visto che i numeri che fa attualmente IBM non penso che giustificherebbero investimenti da altri competitor).

Diavolo parlate poi di IBM come se fosse il diavolo. Naturalemente da questa eventuale acquisizione ci saranno delle epurazioni.

Non ha infatti senso x ibm investire su netbeans e eclipse nello stesso tempo. Morirà uno (penso netbeans) o meglio si fonderanno in un unico programma (netclipse?)

Java potrà solo trarre giovamenti da tutto questo. Come detto da altri SWT (che ho scoperto solo pochi giorni fa) sono di ibm e potrebbero finire di serie in java.

Openoffice resterebbe e anzi potrebbe portare qualche vera novità come l'interfaccia di Lotus (IMHO ottima).

Unire le capacità IBM e SUN nella costruzione di CPU farebbe nascere mostri :D

Mysql potrebbe trarre giocamento da DB2 e soprattutto dalla capacità organizzativa di IBM. Troppe lamentele negli ultimi periodi per colpa di bug, divergenze di opinioni ecc.

E SOPRATTUTTO:
Spero che le tecnologie sun attualmente sviluppate per solaris (che tra l'altro IMHO è destinato a morire) vengano distribuite con licenze che ne consentano l'integrazione con linux (VOGLIO ZFS SU LINUX!), cosa probabile con l'acquisizione.

Beh le borse vanno così di merda che la cifra proposta è il doppio del valore di mercato delle azioni....

CMQ non sarei così tragico.

IBM ha il 39% del mercato dei server, non il 90%. Se è l'unica azienda a proporre mainframe è colpa degli altri che hanno abbandonato un mercato che credevano morto (e probabilmente a ragione visto che i numeri che fa attualmente IBM non penso che giustificherebbero investimenti da altri competitor).

Diavolo parlate poi di IBM come se fosse il diavolo. Naturalemente da questa eventuale acquisizione ci saranno delle epurazioni.

Non ha infatti senso x ibm investire su netbeans e eclipse nello stesso tempo. Morirà uno (penso netbeans) o meglio si fonderanno in un unico programma (netclipse?)

Java potrà solo trarre giovamenti da tutto questo. Come detto da altri SWT (che ho scoperto solo pochi giorni fa) sono di ibm e potrebbero finire di serie in java.

Openoffice resterebbe e anzi potrebbe portare qualche vera novità come l'interfaccia di Lotus (IMHO ottima).

Unire le capacità IBM e SUN nella costruzione di CPU farebbe nascere mostri :D

Mysql potrebbe trarre giocamento da DB2 e soprattutto dalla capacità organizzativa di IBM. Troppe lamentele negli ultimi periodi per colpa di bug, divergenze di opinioni ecc.

E SOPRATTUTTO:
Spero che le tecnologie sun attualmente sviluppate per solaris (che tra l'altro IMHO è destinato a morire) vengano distribuite con licenze che ne consentano l'integrazione con linux (VOGLIO ZFS SU LINUX!), cosa probabile con l'acquisizione.

ciao
ci tengo a dire da ignorante del settore che vedo favorevolmente tale acquisizione, non sono contrario!

EDIT- doppio

These open source platforms generate, alongside the services attached to them, over a billion dollars a year, making Sun by far and away the world's largest open source software company. (For those that continue to ask if we make money with Java, the answer is yes, it's on a ramp to hit about $250m this year - one of our best businesses - and that's just Java on consumer devices, excluding servers).
http://blogs.sun.com/jonathan/
:)

Non ha infatti senso x ibm investire su netbeans e eclipse nello stesso tempo. Morirà uno (penso netbeans) o meglio si fonderanno in un unico programma (netclipse?)


Eresia. In primis in Netbeans ci sono tecnologie che in Eclipse non ci sono (molte nuove novità di Java passano prima per Netbeans, per esempio, vedi l'ultimo JavaFX oppure ai tempi il Mobile Design Assistant o il Matisse GUI Builder).
Tra l'altro non è sicuro nemmeno questo: quando Autodesk acquisì la Alias|Wavefront e la Discreet, non fece mica morire Maya e 3D Studio Max, seppur prodotti largamente sovrapponibili. :mbe:
Tra l'altro Netbeans costituisce una grossa fetta dello sviluppato Sun negli ultimi anni, con grandi investimenti. Non è che si prende un prodotto e lo si butta nel WC dall'oggi al domani.


Java potrà solo trarre giovamenti da tutto questo. Come detto da altri SWT (che ho scoperto solo pochi giorni fa) sono di ibm e potrebbero finire di serie in java.


Si potrebbe discutere eoni di anni sul perchè SWT non è affatto una buona mossa in Java. Basti sapere che non lo è affatto.


Spero che le tecnologie sun attualmente sviluppate per solaris (che tra l'altro IMHO è destinato a morire) vengano distribuite con licenze che ne consentano l'integrazione con linux (VOGLIO ZFS SU LINUX!), cosa probabile con l'acquisizione.

Che Solaris sia destinato a morire è tutto da vedere. Attualmente Linux detiene le maggiori quote per le società di web-hosting ma Solaris è usato in applicazioni mission critical e grosse corporation per applicazioni "business critical". Di fatto, un life-cycle di 10 anni Linux non lo garantisce, nemmeno scegliendo la piu' prestigiosa delle offerte di classe enterprise. Mentre su Linux non mi gira nemmeno il binario di Prey uscito 3 mesi fa. Linux è un'ottimo Unix general purpose, ma ha un'anima troppo improntata all'innovazione e al cambiamento per essere considerato in determinati ambiti. Parliamo sempre di nicchie, ma per determinate nicchie ci vogliono determinati prodotti. Come se non bastasse, oggigiorno Linux sembra piu' correre dietro all'utenza desktop che non a quella enterprise, che invece sembra essere diventata un mero side-effect.

sinceramente non vedo tutto questo male...
dopotutto non è che ibm sia ANTI-opensource... anzi ancora oggi, ci investe parecchio... e finanzia molto dell'opensource....
inoltre nel giro non c'è solo ibm, se ibm iniziasse a fare qualche caxxata altri grandi nomi dell'opensource, o cmq partecipanti nel mondo opensource, potrebbe farsi sentire (intel,hp,redhat,novell)...

suppongo, che le applicazioni concorrenti, possano magari tendere ad unificarsi, e a correggere l'una i difetti dell'altra e viceversa... come veniva detto prima, magari una fusione neteclipse, o progetti del genere...

dopotutto è questo il bello dell'opensource, se sei molto dentro, è difficile fare "troppo male", hai molti occhi che ti guardano (e non parlo degli utenti privati), hai molto rischio di perdite se fai una mossa azzardata etc... basti pensare a novell, che per l'accordo microsoft, ha perso un sacco di utenti, anche se alla fine l'accordo, DA UN CERTO PUNTO DI VISTA ha portato qualche vantaggio al mondo open (per chi gli interessa, il mono, puo' essere un vantaggio)
e cosi' via tante cose...
cioe' SECONDO ME, finchè si comprano e si fondono tra loro... è difficile che facciano errori molto grossolani... inoltre ibm penso sappia quanto vale un eclipse, un java e tutto cio' che lo circonda... e sarebbe stupido andare contro se stessa in caso di acquisizione....



arrows...
90% microsoft
40% ibm + sun
inoltre parliamo di un 40% di soluzioni hardware, su cui buona parte del software che ci gira è a CODICE APERTO, quindi se permetti bisogna fare DUE PESI PER DUE MISURE
vedi qui: http://www.top500.org/system/9707
http://www.top500.org/system/8968
come vedi ibm usa quasi sempre linux, in varie versioni (nel secondo esempio suse insieme a cnlinux)
per la serie
se linux avesse il 99% dello share, non si potrebbe chiamare monopolio. non puo' esserci un monopolio di un qualcosa di libero e modificabile da chiunque...
p.s. che poi non tutto il software usato da ibm, sia opensource, è un altro discorso....
ma ricordiamolo ibm è interessata soprattutto nel vendere servizi... vendere idee etc...
gli interessa poco fare un software e venderlo stile microsoft... ed è molto piu' difficile essere considerati monopolisti in questo ambito...


p.s.
solaris è usato molto nelle tlc, nella gestione delle reti, lo so per sicuro perchè un amico che lavora per l'alcatel, che programma e gestisce le reti fisse in europa, e usano sia linux, ma la maggior parte delle macchine "pesanti" sono solaris, linux piu' che altro funge da client a quanto ho capito... poi magari mi faccio spiegare meglio

imb ne trarrà sicuro giovamento se va in porto l'aquisizione..
peccato vedere sun messa così male..

senza entrare nei dettagli... mi spiace dirlo ma la Sun se lo è meritato.
E' sempre stata 20 anni avanti sia nei progetti che nelle idee e non ha sfruttato un c...o!!!

Alla sun è venuto in mente la possiblità del cloud computing prima che lo zio bill trovasse il dos (è per dire!) e molto altro...

tante idee, tante potenzialità, poche finalizzazioni...

peccato.


ps: io brucerei la ibm. :D

Per la parte inerente le tecnologie software spero che l'acquisizione comporti le sinergie necessarie per togliere di mezzo duplicati di prodotti sul mercato facendo restare il meglio delle due aziende con un unico supporto. Mentre per la parte hardware spero IBM spazzi via tutta la linea custom SUN motorizzata SPARC mettendo la parola fine a tutto questo. Non bisogna infatti trascurare che ultimamante SUN costruiva workstation e server basati su architetture X86 in quanto la tecnologia SPARC era ed è da considerarsi una "mosca bianca" a livello market share. Se andrà in questo modo credo che il risultato dell'acquisizione sarà positivo.

senza entrare nei dettagli... mi spiace dirlo ma la Sun se lo è meritato.
E' sempre stata 20 anni avanti sia nei progetti che nelle idee e non ha sfruttato un c...o!!!

Alla sun è venuto in mente la possiblità del cloud computing prima che lo zio bill trovasse il dos (è per dire!) e molto altro...

tante idee, tante potenzialità, poche finalizzazioni...

peccato.


ps: io brucerei la ibm. :D


per la serie
se la ibm non fosse esistita l'olocausto non sarebbe stato possibile... ;) http://www.itisap.com/progetti/Shoah%20e%20Nazismo_file/Page3420.htm

C'è tanta bella robetta che potrebbe morire per sovrapposizioni, molto pericoloso...
Oppure potrebbero fare una fusione delle cose migliori dei vari prodotti ;)

E farle diventare tutte a pagamento, magari... ...molto pericoloso...
non di certo per l'utente finale ;)
fino ad ora di riflesso noi utenti finali da ibm abbiamo preso tantissimo e gratuitamente ;)

se si parla di pagamento per le aziende, beh le aziende lo mettono sempre in conto ;) se ibm sgarra, sono fatti suoi tra le aziende, è lei la prima a rimetterci se sbaglia politica ;)
c'è sempre hp dietro l'angolo ;)
e intel che non aspetta che mosse sbagliate di ibm per convertire quelle cpu cell del roadrunner in altri x86 :asd:

un po' tipo corvi della discordia ;)

Tra l'altro HP con Sun può competere al massimo con l'hardware server o al massimo con HP-UX, ma per tutto il resto Sun non ha concorrenza.
Sun è anche una grossa software house, HP no.

EDIT: Neanche a farlo apposta è di pochi minuti la notizia che è stato appena rilasciato Sun Studio Express 3/09 :D
http://developers.sun.com/sunstudio/downloads/ssx/express_March2009.html

per la serie
se la ibm non fosse esistita l'olocausto non sarebbe stato possibile... ;) http://www.itisap.com/progetti/Shoah%20e%20Nazismo_file/Page3420.htm

:D

Oppure potrebbero fare una fusione delle cose migliori dei vari prodotti ;)

Esatto.

Cionci.. non sapevo e non immaginavo ti piacessero i Death ;) Chuck 4Ever!

Eresia. In primis in Netbeans ci sono tecnologie che in Eclipse non ci sono (molte nuove novità di Java passano prima per Netbeans, per esempio, vedi l'ultimo JavaFX oppure ai tempi il Mobile Design Assistant o il Matisse GUI Builder).
Tra l'altro non è sicuro nemmeno questo: quando Autodesk acquisì la Alias|Wavefront e la Discreet, non fece mica morire Maya e 3D Studio Max, seppur prodotti largamente sovrapponibili. :mbe:
Tra l'altro Netbeans costituisce una grossa fetta dello sviluppato Sun negli ultimi anni, con grandi investimenti. Non è che si prende un prodotto e lo si butta nel WC dall'oggi al domani.Beh infatti parlavo di fusione in un unico tools. Se conosci maya e 3dstudio max saprai che cmq hanno caratteristiche ben diverse, metodi di lavoro e target molto molto diversi (accentuati dall'acquisizione).

Si potrebbe discutere eoni di anni sul perchè SWT non è affatto una buona mossa in Java. Basti sapere che non lo è affatto.Da altre parti mi hanno consigliato: lascia perdere mono e buttati su java e swt (non so una mazza di programmazione, solo un pò di scripting php e qualcosa di javascript).

Che Solaris sia destinato a morire è tutto da vedere.fatto sta che solaris è una rimessa non da poco per SUN, tanti investimenti per un ritorno economico scarso.


Qual'è la differenza tra IBM e Sun? Le capacità commerciali. IBM ha venduto prodotti basati su tecnologie Sun e fa soldi, Sun fa fatica a guadagnare dalla vendita delle sue tecnologie, figuriamoci i prodotti di altri.

quanto ha investito in Java? che ritorno economico ha ottenuto? Con Openoffice? Probabilmente ha guadagnato + IBM con Lotus Symphony in 1 anno di Sun con oOo/staroffice.

Beh infatti parlavo di fusione in un unico tools. Se conosci maya e 3dstudio max saprai che cmq hanno caratteristiche ben diverse, metodi di lavoro e target molto molto diversi (accentuati dall'acquisizione).


Sono semplicemente due programmi di DCC. I target di mercato li hanno voluti creare loro dopo l'acquisizione, facendo credere alla gente che 3D Studio Max è adatto per la creazione di contenuti per i videogiochi mentre Maya è adatto per l'industria della cinematografia. In realtà, puoi fare entrambe le cose con entrambi i programmi. Poi ovvio che hanno cose differenti, sono pur sempre due programmi differenti.


Da altre parti mi hanno consigliato: lascia perdere mono e buttati su java e swt (non so una mazza di programmazione, solo un pò di scripting php e qualcosa di javascript).


SWT non è il male. E' sicuramente un prodotto valido e per certi compiti risulta sicuramente migliore di Swing. Questo però non lo rende un'eletto idoneo per essere incluso nel JDK affiancando Swing o addirittura sostituendolo. Un'ottimo package, fin quando rimane un jar da linkare a parte.


Qual'è la differenza tra IBM e Sun? Le capacità commerciali. IBM ha venduto prodotti basati su tecnologie Sun e fa soldi, Sun fa fatica a guadagnare dalla vendita delle sue tecnologie, figuriamoci i prodotti di altri.

quanto ha investito in Java? che ritorno economico ha ottenuto? Con Openoffice? Probabilmente ha guadagnato + IBM con Lotus Symphony in 1 anno di Sun con oOo/staroffice.

Sun è nota per fare pochissimo marketing. Rispetto alle campagne di IBM che ha piazzato i banner dei blade server pure sui siti porno. :asd: Se non sbaglio, tempo fa molti si lamentarono proprio qui che il banner IBM prendeva possesso del sito... :D

Sun una nicchia per pochi accoliti? Hai presente il market share di Java nei sistemi enterprise e delle relative divisioni mobility? Puoi acquistare per caso un lettore blu-ray senza avere una licenza allegata di JME-BD? No...
Altro che pochi accoliti. Tutti nel loro piccolo, anche inconsapevolmente, usano tecnologie Sun. Tu stesso lo stai facendo postando su questo forum. Non diciamo eresie per favore. Sun ha creato tecnologie davvero rilevanti che fanno parte della vita di tutti i giorni di tutti, anche coloro che non sanno di utilizzarle. E' forse una delle aziende piu' importanti in questo campo, se non la piu' importante, a prescidendere dai valori di mercato e dai market share delle varie divisioni.
*

cmq non so perché, pur non sapendo nulla della situazione finanziaria di sun e/o della sua volontà di farsi acquisire, neglki ultimi anni ogni tanto mi veniva la sensazione che sun sarebbe finita in pancia a qualche pesce grosso, e di solito mi veniva in mente ibm :sofico: (sarà che avrò sentito/letto qualcosa senza memorizzare)

... ti immagini che casino di polemiche se, per assurdo, la comprasse ms, con probabilmente la divisione hw/s.o. che andrebbe a finire alle ortiche ed il resto +/- in "java .net" e dintorni ? :asd:

IBM è un rullo compressore. :eek:

... ti immagini che casino di polemiche se, per assurdo, la comprasse ms, con probabilmente la divisione hw/s.o. che andrebbe a finire alle ortiche ed il resto +/- in "java .net" e dintorni ? :asd:

Non ci voglio nemmeno pensare, questa notte potrei avere gli incubi... :asd:

beh comunque alla fine anche se preferirei tenere due grandi aziende invece che una grandissima meglio IBM che altri

Sono semplicemente due programmi di DCC. I target di mercato li hanno voluti creare loro dopo l'acquisizione, facendo credere alla gente che 3D Studio Max è adatto per la creazione di contenuti per i videogiochi mentre Maya è adatto per l'industria della cinematografia. In realtà, puoi fare entrambe le cose con entrambi i programmi. Poi ovvio che hanno cose differenti, sono pur sempre due programmi differenti. Sai cos'è Moodle? un cms specializzato nella gestione di ambienti scolastici. Cosa fa in + di joomla? nulla. Però hanno senso di esistere entrambi. Posso fare un sito x una scuola con joomla, farebbe le stesse cose ma sarebbe meno pratico per loro e molto più complessa l'amministrazione per me. Questa è la differeza tra maya e 3dstudio max. Una verticalizzazione ottimizza il lavoro a uno e lo complica ad altri. Chi spende milioni di dollari per fare film vuole strumenti ottimizzati al massimo. Stessa cosa per il mondo dei videogiochi.

SWT non è il male..... Mah alla fine penso che mi butterò su mono. Vedere come Banshee e Gnome-do si evolvono rapidamente mi fa pensare che sia più potente, flessibile e semplice di java. La portabilità è più o meno la stessa, certo non posso portare un applicativo su android ma per ora non mi interessa.


Sun è nota per fare pochissimo marketing. Rispetto alle campagne di IBM che ha piazzato i banner dei blade server pure sui siti porno. :asd: Se non sbaglio, tempo fa molti si lamentarono proprio qui che il banner IBM prendeva possesso del sito... :DSono sempre stato favorevole alla pubblicità nei siti e non ho mai installato in FF strumenti per la loro rimozione. Tranne quando in alcuni siti sono comparsi quegli odiosi banner di IBM. Il fatto è però quello cavolo, tanti pensano che java sia robbbba IBM e nessuno da a sun un minimo di merito per oOo.

beh comunque alla fine anche se preferirei tenere due grandi aziende invece che una grandissima meglio IBM che altri

Io avrei preferito HP. Meno sovrapposizioni... :stordita:

Se l'Unione Europea accetterà questa acquisizione, sarà l'ennesima dimostrazione che è solo anti-Microsoft.

E la accetterà.

E che centra l'antitrust europea, sono due aziende americane (IBM è di Armonk - New York e Sun di Santa Clara - California) :D

L'antitrust europea può solo star a guardare. Piuttosto è l'antitrust americana a decidere

Sai cos'è Moodle? un cms specializzato nella gestione di ambienti scolastici. Cosa fa in + di joomla? nulla. Però hanno senso di esistere entrambi. Posso fare un sito x una scuola con joomla, farebbe le stesse cose ma sarebbe meno pratico per loro e molto più complessa l'amministrazione per me. Questa è la differeza tra maya e 3dstudio max. Una verticalizzazione ottimizza il lavoro a uno e lo complica ad altri. Chi spende milioni di dollari per fare film vuole strumenti ottimizzati al massimo. Stessa cosa per il mondo dei videogiochi.


Scusa ma non capisco se hai capito il senso di quello che volevo dire. Io sto dicendo proprio questo ed è quello che auspico per Netbeans ed Eclipse (ritornando al discorso originale). Ovvero che in un certo senso possano co-esistere dopo l'acquisizione.


Mah alla fine penso che mi butterò su mono. Vedere come Banshee e Gnome-do si evolvono rapidamente mi fa pensare che sia più potente, flessibile e semplice di java. La portabilità è più o meno la stessa, certo non posso portare un applicativo su android ma per ora non mi interessa.


Mono è solo un'implementazione del .net framework. E come tale la portabilità non è affatto la stessa. A dir la verità, Mono è anche parecchio incompleto rispetto al .net framework (e sempre lo sarà). Java invece è unico su tutte le piattaforme supportate e il suo sviluppo è centralizzato. Nemmeno con Java, sul lato pratico, puoi portare un'applicativo su Android. Android non è Java, al contrario di quello che si pensi. Re-implementa da capo molti concetti standard. Nemmeno le API per i canvas sono le stesse e, dulcis in fundo, un programma Android non è affatto compatibile con il bytecode Java. Non basta avere una sintassi equivalente per potersi chiamare "Java". Per quanto riguarda flessibilità e semplicità, Gnome-Do è scritto in C# che è un linguaggio derivato da Java. Se credi di trovare un linguaggio estremamente piu potente e flessibile in realtà stai parlando di un "dialetto" di Java. Per quanto rigurda la "potenza", invece, utilizza API che non sono standard del framework ma si basa su classi wrapper di GTK+ (GTK#). Anche con Java puoi utilizzare GTK+:
http://java-gnome.sourceforge.net/

EDIT:
Dovesse cambiare il logo:
http://java-gnome.sourceforge.net/images/cross-product.png
... divento un terrorista. :mad:

dai che sparisce java e mi si alleggerisce internet :-D

peccato per sun.. ricordo ancore le sunsparc con nostalgia..

Mah alla fine penso che mi butterò su mono.
Ma anche no...se SWT non è il male lo è sicuramente Mono :stordita:
Non ha senso impararsi Mono, ha senso impararsi C# e poi se * saltuariamente * c'è il bisogno di sfruttare la portabilità usarlo con mono.
Non capisco perché Java + SWT o semplicemente Java con Swing non ti vada bene.

Non penso che possa essere economicamente conveniente per IBM mantenere aperti 2 diversi progetti. Magari per ora ne può valere la pena ma sul lungo termine sarebbe più logico fondere le 2 soluzioni o al massimo regalarne uno dei 2 alla comunità.

Il tuo discorso su mono e java è forse un pò di parte. Mono non è .net, è nato per portare .net su linux ma ora è certamente qualcosa in meno e qualcosa di +. Esistono porting x linux, windows, Mac. Java esiste anche per le macchine del caffè lavazza ma mi interessa principalmente provare a sviluppare x linux, eventuali porting win e mac potrebbero interessarmi.

Android è cmq molto vicino a Java e immagino che un porting a da java a (non ricordo cosa/android) sia più semplice che da mono.

Wikipedia parla di c# in questi termini: Il C# (si pronuncia "c sharp") è un linguaggio di programmazione object-oriented sviluppato da Microsoft all'interno dell'iniziativa .NET, e successivamente approvato come standard ECMA. La sintassi del C# prende spunto da quella del Delphi (hanno il medesimo autore, ovvero Anders Hejlsberg), del C++, da quella di Java ed a Visual Basic per gli strumenti di programmazione visuale e per la sua semplicità (meno simbolismo rispetto a C++, meno elementi decorativi rispetto a Java).
Non è la stessa proprio come dici tu...

Java non è usato un granchè in ambiente desktop, tolto eclipse non esistono grandi esempi di applicativi java di successo (e validi). azureus (penso, non ho voglia di controllare) fa schifo, lento e pesante rispetto alle alternative.
Banshee è un bel pezzo di software, gnome do è forse il più bel pezzo di software sviluppato nel 2008. E sono progetti di questo tipo che mi fanno venire voglia di provare a sviluppare qualcosa. Penso che il merito sia anche di Mono.

Websphere spero muoia tra atroci sofferenze in favore di BEA o persino di JBOSSNon mi pronuncio su BEA dato che è un prodotto che non conosco, riguardo al paragone tra WAS e JBOSS spero che tu stia scherzando...
Jboss è carino, ma rispetto a WAS è un giocattolino... bello finchè si vuole ma è un giochino, meno capriccioso rispetto a tomcat ma ciò non toglie che non sia minimamente paragonabile a un mostro come WebSphere.

Senza tirare in ballo aspetti apparentemente marginali (es interfaccia di amministrazione, tool di monitoraggio e problem solving), dove la mettiamo la scalabilità di WAS? Il suo clustering spinto, orizzontale, verticale, obliquo, carpiato etc etc?
Per non parlare del supporto, io di ticket su redhat network ne ho aperti un sacco negli ultimi anni, per carità supporto carino e che tutto sommato funziona... ma quando sei nelle "canne" con SLA folli che ti pressano, penali da capogiro che ti pendono sulla testa, aprire una chiamata (PMR per gli aficionados) di livello critico, con i laboratori che pendono dalle tue labbra e ti dicono "tieniti pronto perchè facciamo notte e non ci stacchiamo finchè il problema non è risolto", beh quella è una cosa che IBM e pochi altri possono offrire, e questo vale molto di più di tante feature pseudotecniche, imho eh :)

Il tuo discorso su mono e java è forse un pò di parte. Mono non è .net, è nato per portare .net su linux ma ora è certamente qualcosa in meno e qualcosa di +. Esistono porting x linux, windows, Mac. Java esiste anche per le macchine del caffè lavazza ma mi interessa principalmente provare a sviluppare x linux, eventuali porting win e mac potrebbero interessarmi.

Android è cmq molto vicino a Java e immagino che un porting a da java a (non ricordo cosa/android) sia più semplice che da mono.

Wikipedia parla di c# in questi termini: Il C# (si pronuncia "c sharp") è un linguaggio di programmazione object-oriented sviluppato da Microsoft all'interno dell'iniziativa .NET, e successivamente approvato come standard ECMA. La sintassi del C# prende spunto da quella del Delphi (hanno il medesimo autore, ovvero Anders Hejlsberg), del C++, da quella di Java ed a Visual Basic per gli strumenti di programmazione visuale e per la sua semplicità (meno simbolismo rispetto a C++, meno elementi decorativi rispetto a Java).
Non è la stessa proprio come dici tu...

Java non è usato un granchè in ambiente desktop, tolto eclipse non esistono grandi esempi di applicativi java di successo (e validi). azureus (penso, non ho voglia di controllare) fa schifo, lento e pesante rispetto alle alternative.
Banshee è un bel pezzo di software, gnome do è forse il più bel pezzo di software sviluppato nel 2008. E sono progetti di questo tipo che mi fanno venire voglia di provare a sviluppare qualcosa. Penso che il merito sia anche di Mono.
Evidentemente non sei molto vicino alla comunità Linux...Mono è visto tutt'altro che bene. Pensa che ci sono alcune persone che conosco che disinstallano qualsiasi traccia di Mono non appena hanno installato la propria distro.

Imho non ha senso imparare a sviluppare per Mono. Ha senso sviluppare applicazioni C# per .Net su Windows. Ovviamente il codice C# .Net non è portabile su Mono non appena si va oltre la semplice applicazione console.

Non so quali programmi ti serva fare, ma se ti limita la velocità di Swing c'è sempre SWT.

@cionci

Mono sarà visto male da UNA PARTE DELLA COMUNITA', non certo da tutta, è facile prevedere il porting di molta roba 'gnome' e il futuro gnome3 su mono visto che Michael De Icaza è a capo di entrambi i progetti.
Non ha senso imparare a sviluppare iin .Net visto che l'idea è sviluppare qualcosa che possa essere un minimo multipiattaforma e quindi .net è un discorso chiuso (tieni conto che non ho + windows su nessuna delle mie macchine).
Il problema non è swing ma penso java in generale. Sono pochi gli applicativi basati su java in ambiente desktop e quei pochi sono decisamente lenti (azureus appunto è un buon esempio). Uso un software che si chiama hudlite per sistemi voip, anch'esso in java, un software banalissimo che però pesa 70+MB su windows e circa altrettanti. Eclipse è un altro bel mattone (java + swt). L'utilizzo di memoria e le prestaioni di software come banshee e gnomedo sono allineati ai rispettivi concorrenti.


Poi per ogni persona che trovi che ti parla bene di una cosa ne trovi 3 che ne parlano male. SWT poco sopra mi è stato sconsigliato, altri ne parlano benissimo.

NON ESISTONO QUESTIONI TECNICHE per lasciar perdere mono, almeno stando a discussioni a cui ho partecipato (molto interessante una di 10gg fa circa su pollycoke cui ha preso parte anche Andrea Cimitan che mi ha chiarito molte cose).

Poi chiariamo, ho voglia di avvicinarmi allo sviluppo software e nulla +, magari provo e tra 1 mese mi passa la voglia (devo anche trovare il tempo x incastrare tutto, lavoro, donna, i suoi gatti ecc). Come ho già detto sono applicativi come banshee e gnome do che mi fanno venire voglia di provare a sviluppare perchè mi affascina l'estrema rapidità del loro sviluppo.

Sono semplicemente due programmi di DCC. I target di mercato li hanno voluti creare loro dopo l'acquisizione, facendo credere alla gente che 3D Studio Max è adatto per la creazione di contenuti per i videogiochi mentre Maya è adatto per l'industria della cinematografia. In realtà, puoi fare entrambe le cose con entrambi i programmi. Poi ovvio che hanno cose differenti, sono pur sempre due programmi differenti.


Non è assolutamente vero che i target li hanno voluti creare dopo l'acquisizione.
Tra l'altro uno dei problemi principali per l'utilizzo di 3D Studio Max in ambiente cinematografico serio è che li utilizzano linux. 3D Studio Max su linux non gira in modo nativo e ormai è arrivato ad un livello di complessità così alto che sarebbe troppo oneroso fare il porting.
Senza contare gli investimenti che hanno fatto su Maya tutti le case cinematografiche.

Mono sarà visto male da UNA PARTE DELLA COMUNITA', non certo da tutta, è facile prevedere il porting di molta roba 'gnome' e il futuro gnome3 su mono visto che Michael De Icaza è a capo di entrambi i progetti.
Allora diciamo così...una buona parte. Così come la maggior parte delle persone richiede a gran voce un framework ad oggetti per Gnome, invece delle solite vetuste gtk+. Se vuoi ti predico il futuro (e te lo dice uno che preferisce Gnome): gran parte dello sviluppo si trasferirà su applicazioni QT, non solo per KDE, ma anche per la nuova linfa portata dalle QT LGPL al mondo open source.
Poi, se vuoi dipendere da un prodotto sostenuto da pochi, che è un porting di un linguaggio Microsoft (Mono diffondendo C# non fa altro che fare un piacere a Microsoft), che dipende a sua volta da un wrapper su librerie grafiche che non sono assolutamente allo stato dell'arte...allora fai pure.
Gli IDE per Mono sono, chiaramente, eoni indietro a quelli di Java. Ripeto: mi piacerebbe sapere che applicazioni vuoi sviluppare che portano al limite l'interfaccia Swing. Riguardo ad SWT io facevo un discorso diverso: se ti lamenti delle prestazioni di Swing, hai sempre l'opportunità di passare ad SWT che è molto più veloce.
Se cerchi un linguaggio semplice da imparare, che abbia un framework degno di tale nome, che sia fondato su basi open source, con tempi di sviluppo molto bassi (anche grazie alla bontà degli IDE), allora la risposta non è certo Mono, ma sicuramente Java.
Se poi guardi all'uso di memoria: stai confrontando un'applicazione come Vuze, che ha una complessità di interfaccia veramente notevole (posto che lo preferivo prima), con Banshee che ha una complessità veramente minimale. Nota che Banshee pur senza fare niente e con la libreria vuota, appena lanciato occupa comunque poco meno della metà di quanto occupa Vuze (48 MB contro 105). E nel conteggio di Vuze ci sono comprese anche tutte le librerie, mentre in quello di Banshee no, visto che usa librerie condivise presenti nel sistema per la maggior parte dei compiti.

Java al giorno d'oggi è sicuramente la scelta migliore per sviluppare software portabile senza troppo problemi, sicuramente non lo è Mono. Io sarò anche un signor nessuno, ma non ho interessi in gioco per fare affermazioni del genere. Poi è chiaro e plausibile che ciascuno porti acqua al suo mulino.
Sono sicuro anche che i soldi di IBM non possano che far bene all'intera comunità di sviluppatori Java (mi ero scordato che la comunità di sviluppatori Java è spropositata rispetto a quella di Mono, con le chiare conseguenze).

Java al giorno d'oggi è sicuramente la scelta migliore per sviluppare software portabile senza troppo problemi, sicuramente non lo è Mono.

Ma c'è ancora qualcuno che vuole applicazioni multipiattaforma?
Le applicazioni multipiattaforma saranno sempre una seconda scelta, dovendo necessariamente essere un minimo comune denominatore delle caratteristiche presenti sulle piattaforme supportate.

Insomma possono andare bene per le applicazioni di nicchia dove l'interfaccia viene dopo, ma non per quelle consumer o comunque di larga portata (dove c'è concorrenza e si può scegliere cosa usare).

A me certo tutte le applicazioni non Cocoa su Mac OS X fanno vomitare. Perfino quelle "Classic" ormai sotto certi aspetti, come Photoshop o Word.
Bene ha fatto Apple a vietarle su iPhone, visto che partiva da zero.

E bene ha fatto Google con Chrome a prendere un framework come webkit (quello sì) multipiattaforma ma a fare versioni apposite e native del programma per le singole piattaforme. Anche se questo comporta che per le versioni Mac e Linux bisognerà aspettare ancora un po'.

Ma c'è ancora qualcuno che vuole applicazioni multipiattaforma?
Non è la necessità degli utenti a richiederle, ma la necessità degli sviluppatori.

Edit: Eclipse, basato su SWT, su OS X:
http://developer.apple.com/tools/images/BuildPath.jpg
http://telscenter.org/confluence/download/attachments/8349/awtmac.png

Ma c'è ancora qualcuno che vuole applicazioni multipiattaforma?
Le applicazioni multipiattaforma saranno sempre una seconda scelta, dovendo necessariamente essere un minimo comune denominatore delle caratteristiche presenti sulle piattaforme supportate.

Insomma possono andare bene per le applicazioni di nicchia dove l'interfaccia viene dopo, ma non per quelle consumer o comunque di larga portata (dove c'è concorrenza e si può scegliere cosa usare).

A me certo tutte le applicazioni non Cocoa su Mac OS X fanno vomitare. Perfino quelle "Classic" ormai sotto certi aspetti, come Photoshop o Word.
Bene ha fatto Apple a vietarle su iPhone, visto che partiva da zero.

E bene ha fatto Google con Chrome a prendere un framework come webkit (quello sì) multipiattaforma ma a fare versioni apposite e native del programma per le singole piattaforme. Anche se questo comporta che per le versioni Mac e Linux bisognerà aspettare ancora un po'.

La richiesta di applicazioni multipiattaforma è in crescita. Utilizzando un buon framework multipiattaforma si riescono a produrre applicazioni multipiattaforma con gui native dello stesso livello di applicazioni realizzate per uno specifico sistema. Vedi per esempio wx.

Non è la necessità degli utenti a richiederle, ma la necessità degli sviluppatori.

Beh, se gli utenti non comprano gli sviluppatori non mangiano ;)
Prendiamo il programma da te citato: Vuze (ex Azureus).

Programma sicuramente potente, tantissime funzioni, anche efficiente in quello che deve fare (scaricare torrent). L'ho usato anche io per un certo periodo... Ma... era un programma JAVA :Puke: . Non si poteva guardare!! Ci metteva mezz'ora a partire!! Occupava più Ram lui dell'OS!!

Appena uscito un concorrente appena credibile (Transmission) su Mac non l'ha usato più nessuno. Su Windows uguale quando è uscito µTorrent.

Sono programmi "migliori" rispetto a Vuze? Probabilmente no. Ma il DIFETTO di Vuze è quello di essere scritto in Java. Essere multipiattaforma. Con un sistema a macchina virtuale, per giunta (lo considero un difetto, sì. Ho già il mio OS, grazie. Non me ne serve un altro sopra).

La richiesta di applicazioni multipiattaforma è in crescita. Utilizzando un buon framework multipiattaforma si riescono a produrre applicazioni multipiattaforma con gui native dello stesso livello di applicazioni realizzate per uno specifico sistema. Vedi per esempio wx.

Assolutamente FALSO. Soprattutto con il framework da te citato. Va bene il "si riescono a produrre applicazioni multipiattaforma", ma poi mettiamoci un PUNTO.

Vedi per esempio wx.
Imho troppo buggate le wxWidgets.
SWT (Java), wxWidgets e QT (queste due per molti linguaggi) hanno look & feel nativo su Mac.

Beh, se gli utenti non comprano gli sviluppatori non mangiano ;)
Prendiamo il programma da te citato: Vuze (ex Azureus).

Programma sicuramente potente, tantissime funzioni, anche efficiente in quello che deve fare (scaricare torrent). L'ho usato anche io per un certo periodo... Ma... era un programma JAVA :Puke: . Non si poteva guardare!! Ci metteva mezz'ora a partire!! Occupava più Ram lui dell'OS!!

Appena uscito un concorrente appena credibile (Transmission) su Mac non l'ha usato più nessuno. Su Windows uguale quando è uscito µTorrent.

Sono programmi "migliori" rispetto a Vuze? Probabilmente no. Ma il DIFETTO di Vuze è quello di essere scritto in Java. Essere multipiattaforma. Con un sistema a macchina virtuale, per giunta (lo considero un difetto, sì. Ho già il mio OS, grazie. Non me ne serve un altro sopra).

Ma questo dipende da come è scritto il programma.
Ci sono programmi java enormi (es. eclipse, netbeans, ecc.) che hanno un ottimo aspetto e sono usati anche se ci sono programmi "nativi".
Comunque guarda che il multipiattaforma:
1) Lo puoi fare anche con il look-and-feel nativo (vedi wswidgets per esempio).
2) Lo puoi fare anche con linguaggi compilati C/C++
3) Lo puoi fare anche con linguaggi interpretati, che comunque rimangono molto efficienti, es. python

Appena uscito un concorrente appena credibile (Transmission) su Mac non l'ha usato più nessuno. Su Windows uguale quando è uscito µTorrent.
Transmission è un programma multipiattaforma ;)
Sono programmi "migliori" rispetto a Vuze? Probabilmente no. Ma il DIFETTO di Vuze è quello di essere scritto in Java. Essere multipiattaforma. Con un sistema a macchina virtuale, per giunta (lo considero un difetto, sì. Ho già il mio OS, grazie. Non me ne serve un altro sopra).
Il difetto di Vuze è semplicemente quello di essere troppo complesso ;)

Assolutamente FALSO. Soprattutto con il framework da te citato. Va bene il "si riescono a produrre applicazioni multipiattaforma", ma poi mettiamoci un PUNTO.

Perchè assolutamente falso?

Sinceramente temo un pò la strada intrapresa da nokia. Temo che QT possano diventare una cosa troppo orientata allo sviluppo di sistemi mobile.

Poi a che pro sviluppare su linux con QT? KDE non sfonda e anzi forse sono + quelli che scappano visti i problemi e i ritardi. Gnome3 si sta avvicinando e quello che si può provare non è affatto male (il nuovo metacity integrato con clutter, la nuova gnomeshell). Le nuove gtk stanno nascendo con l'obiettivo di accontentare gli sviluppatori e se integrano l'idee come questa (http://www.cimitan.com/blog/2009/01/31/do-ifying-gtk-30/) sarà un bel passo in avanti, anche rispetto a QT.

Come ho già detto prima voglio avvicinarmi alla programmazione poi inizierò a pensare cosa programmare. Principalmente però essendo utente gnome e non usando windows penso che la soluzione più pratica sia phyton (che però mi ispira poco, penso che sia difficile sviluppare applicativi un pò complessi con questo linguaggio) o appunto mono. Java è quasi inutilizzato in ambienti desktop, Vuze non so come vada ora ma Azureus non era un bell'esempio di software snello e semplice (per dire: mirò è decisamente meglio). Dire che ATTALMENTE gli applicativi java non siano lenti e meno performanti delle alternative basate su altro mi sembra impossibile.

? Banshee un applicativo semplice? + di Vuze? Perchè allora Amarok altrettanto pesante per il sistema, songbird e + o meno agli stessi livelli?

@macfanboy
Per il multipiattaforma intendevo la possibilità di fare un eventuale porting da un sistema a un'altro. Poi mi sembra che mono abbia binding x Cocoa così come x i windows.model (e dovrebbe essere lo stesso x l'accoppiata java SWT) rendendo l'applicativo uniforme con il resto del sistema.

Questa per me è un'amara notizia.
Come si collocherà il Sun System Application Server nei confronti di WebSphere?
Come si collecherà Netbeans nei confronti di Eclipse?
Come si collocheranno tutte le tecnologie Java presenti e future in generale?
Come si collocherà MySQL in relazione a DB2?
Come si collocherà Solaris rispetto a AIX?
Che ne sarà del JCP? Verrà stravolto? Reso meno aperto di quello che è?
Sun è la società open source piu' grande del mondo. Che ne sarà di tutto il ben di Dio che hanno creato?
Come può la linea di server SPARC e SunFire coesistere con la linea Blade server di IBM?

A me questa piu' che una manovra dai lauti benefici mi sembra solo una manovra ammazza-concorrenza.

Ottime domande Jordan. Faccio una premessa, vediamo se la condividi: se IBM acquista Sun, Java verrà relegato principalmente al mercato Enterprise.

Eclipse e NetBeans potrebbero ricoprire due diverse fasce di mercato. NetBeans sarà sempre un buon modo per pubblicizzare Java su desktop. Oppure uno dei due, a tendere, morirà.

Per MySQL e DB2 non vedo questo problema, perché DB2 è un prodotto pesante destinato ad enormi moli di dati, MySQL sarà riservato a piccole e medie aziende. Oppure, a grandi aziende che non hanno l'esigenza di gestire quantità di dati enormi con un alto livello di affidabilità.

Prima o poi, qualcuno tra Solaris e AIX farà una finaccia :D

Sinceramente temo un pò la strada intrapresa da nokia. Temo che QT possano diventare una cosa troppo orientata allo sviluppo di sistemi mobile.

Poi a che pro sviluppare su linux con QT? KDE non sfonda e anzi forse sono + quelli che scappano visti i problemi e i ritardi. Gnome3 si sta avvicinando e quello che si può provare non è affatto male (il nuovo metacity integrato con clutter, la nuova gnomeshell). Le nuove gtk stanno nascendo con l'obiettivo di accontentare gli sviluppatori e se integrano l'idee come questa (http://www.cimitan.com/blog/2009/01/31/do-ifying-gtk-30/) sarà un bel passo in avanti, anche rispetto a QT.

Come ho già detto prima voglio avvicinarmi alla programmazione poi inizierò a pensare cosa programmare. Principalmente però essendo utente gnome e non usando windows penso che la soluzione più pratica sia phyton (che però mi ispira poco, penso che sia difficile sviluppare applicativi un pò complessi con questo linguaggio) o appunto mono. Java è quasi inutilizzato in ambienti desktop, Vuze non so come vada ora ma Azureus non era un bell'esempio di software snello e semplice (per dire: mirò è decisamente meglio). Dire che ATTALMENTE gli applicativi java non siano lenti e meno performanti delle alternative basate su altro mi sembra impossibile.

? Banshee un applicativo semplice? + di Vuze? Perchè allora Amarok altrettanto pesante per il sistema, songbird e + o meno agli stessi livelli?

@macfanboy
Per il multipiattaforma intendevo la possibilità di fare un eventuale porting da un sistema a un'altro. Poi mi sembra che mono abbia binding x Cocoa così come x i windows.model (e dovrebbe essere lo stesso x l'accoppiata java SWT) rendendo l'applicativo uniforme con il resto del sistema.

Python è un ottimo linguaggio.
Non ci sono problemi a scrivere applicazioni molto complesse. Il linguaggio è tra i più potenti e dipone di librerie e framework molto professionali un po per tutto.
Ci sono tantissime applicazione complesse scritte in python (vedi per esempio alcuni casi di studio sul sito ufficiale) senza contare l'utilizzo sempre crescente anche come sistema di sviluppo interno di molte società (grossi sistemi bancari, sistemi server, catene di rendering e calcolo distribuito)

Imho troppo buggate le wxWidgets.
SWT (Java), wxWidgets e QT (queste due per molti linguaggi) hanno look & feel nativo su Mac.

Il difetto di queste librerie multipiattaforma è che pur utilizzando ALCUNI widget nativi, non utilizzano le CONVENZIONI native della piattaforma.
Menu, comandi, box di dialogo, FONT, ecc.

Sono sempre un po' "sbagliate"... e il problema forse è ancora più grave dove c'è questo miscuglio di cose native e di cose estranee.

Se prendo un'applicazione Flash (per dire) so che è diversa e non mi aspetto che sia un applicazione Mac. Se me ne capita una fatta con wxWidgets (es. aMule) sembra nativa, ma poi la barra dei menu c'è ma è vuota: i comandi sono sparsi con dei bottoni, le scritte sono troncate o troppo piccole/grandi, le finestre sono "strane" le preferenze non sono dove dovrebbero essere, ecc... ecc... insomma ci sono delle inconsistenze FASTIDIOSE.

Non che non si possa usare, ma potendo scegliere quella "multipiattaforma" perde sempre.

(grossi sistemi bancari, sistemi server, catene di rendering e calcolo distribuito)
Magari come frontend ;) Potrei dire tante di quelle cose su Python da riempire una discussione, soprattutto sulla presunta professionalità delle librerie esterne al framework principale (in particolare per quanto riguarda la documentazione), ma qui siamo OT :D

insomma ci sono delle inconsistenze FASTIDIOSE.

Solo per difetti di porting di chi scrive l'applicazione, non perché non si possa realizzare. aMule ha difetti su qualsiasi piatttaforma :muro:

Ma questo dipende da come è scritto il programma.
Ci sono programmi java enormi (es. eclipse, netbeans, ecc.) che hanno un ottimo aspetto e sono usati anche se ci sono programmi "nativi".

Eclipse sarà anche evoluto e avrà funzioni bellissime (non lo so, mai usato) ma sicuramente non può competere dal punto di vista dell'integrazione con l'OS con XCode su Mac. E scommetto neanche con VisualStudio su Windows. E' un compromesso anche lui per realizzare software che sono compromessi (o multipiattaforma, come li vuoi chiamare).

Comunque guarda che il multipiattaforma:
1) Lo puoi fare anche con il look-and-feel nativo (vedi wswidgets per esempio).
2) Lo puoi fare anche con linguaggi compilati C/C++
3) Lo puoi fare anche con linguaggi interpretati, che comunque rimangono molto efficienti, es. python

Sì, sì. Il 2) e 3) mi sta benissimo. E' l'1) che non sopporto!! :ciapet:
Quindi Java nel caso particolare.

Transmission è un programma multipiattaforma ;)


Sì ma fatto in modo corretto. Cioè, low-level (frameworks) multipiattaforma, user-level nativo (Cocoa su Mac).
Come vuole fare giustamente Google con Chrome.

Il difetto di queste librerie multipiattaforma è che pur utilizzando ALCUNI widget nativi, non utilizzano le CONVENZIONI native della piattaforma.
Menu, comandi, box di dialogo, FONT, ecc.

Sono sempre un po' "sbagliate"... e il problema forse è ancora più grave dove c'è questo miscuglio di cose native e di cose estranee.

Se prendo un'applicazione Flash (per dire) so che è diversa e non mi aspetto che sia un applicazione Mac. Se me ne capita una fatta con wxWidgets (es. aMule) sembra nativa, ma poi la barra dei menu c'è ma è vuota: i comandi sono sparsi con dei bottoni, le scritte sono troncate o troppo piccole/grandi, le finestre sono "strane" le preferenze non sono dove dovrebbero essere, ecc... ecc... insomma ci sono delle inconsistenze FASTIDIOSE.

Non che non si possa usare, ma potendo scegliere quella "multipiattaforma" perde sempre.

Ma questo dipende da come è scritta l'applicazione. Anche in MFC se faccio una barra dei menu vuota, spargo i comandi in bottoni, uso font troppo grossi ottengo gli stessi effetti.
Scrivi un applicativo wxwidgets bene e non hai questi effetti (ci sono molti applicativi ben scritti con interfacce perfettamente integrate e coerenti con quelle native)

Eclipse sarà anche evoluto e avrà funzioni bellissime (non lo so, mai usato) ma sicuramente non può competere dal punto di vista dell'integrazione con l'OS con XCode su Mac. E scommetto neanche con VisualStudio su Windows. E' un compromesso anche lui per realizzare software che sono compromessi (o multipiattaforma, come li vuoi chiamare).
Usare Eclipse per programmare in C o C++ non ha senso, esistono altri tool più semplici ed altrettanto funzionali, sempre multipiattaforma. Vedi Code::Blocks e QTCreator.
Escludendo l'editor di GUI, Eclipse è sicuramente ide migliore, in senso assoluto, su cui mi sia trovato a lavorare. NetBeans è valido (soprattutto per la GUI), ma non offre tutti gli automatismi che offre Eclipse.

Magari come frontend ;) Potrei dire tante di quelle cose su Python da riempire una discussione, soprattutto sulla presunta professionalità delle librerie esterne al framework principale (in particolare per quanto riguarda la documentazione), ma qui siamo OT :D

Che ci siano librerie / framework esterni non professionali ok, ma ce ne sono alcune che sono tra le migliori disponibili (es. django, twister, wxwidgets, cheetah ....). Ma questo capita in tutti i linguaggi.
Ciò non toglie che rimane uno dei linguaggi migliori disponibili

Usare Eclipse per programmare in C o C++ non ha senso, esistono altri tool più semplici ed altrettanto funzionali, sempre multipiattaforma. Vedi Code::Blocks e QTCreator.
Escludendo l'editor di GUI, Eclipse è sicuramente ide migliore, in senso assoluto, su cui mi sia trovato a lavorare. NetBeans è valido (soprattutto per la GUI), ma non offre tutti gli automatismi che offre Eclipse.

Prova a dire ad un programmatore embedded per esempio, e non è un settore di nicchia, che programmare in C o C++ non ha senso e che esistono altri tool più semplici ed altrettanto funzionali. Poi vedrai cosa ti rispondono.

Ma questo dipende da come è scritta l'applicazione. Anche in MFC se faccio una barra dei menu vuota, spargo i comandi in bottoni, uso font troppo grossi ottengo gli stessi effetti.
Scrivi un applicativo wxwidgets bene e non hai questi effetti (ci sono molti applicativi ben scritti con interfacce perfettamente integrate e coerenti con quelle native)

Per farlo bene dovresti scrivere una versione per Mac, una per Windows e una per Linux. E non è detto che comunque riusciresti essendo queste librerie solo un subset di quelle native (per motivi di compatibilità). A questo punto perchè usare una libreria limitante e non usare direttamente quella nativa?!!

Che ci siano librerie / framework esterni non professionali ok, ma ce ne sono alcune che sono tra le migliori disponibili (es. django, twister, wxwidgets, cheetah ....). Ma questo capita in tutti i linguaggi.
wxWidgets io sinceramente lo trovo molto buggato, preferisco di gran lunga QT. Comunque ciò non succede quando la maggior parte delle librerie è inclusa nel framework del linguaggio. Vedi Java: documentazione uniforme, garanzia di aggiornamenti di pari passo, garanzia di retrocompatibilità. Cose che, con la miriade di librerie indipendenti che costituiscono l'universo Python, non sono assolutamente garantite.
Ciò non toglie che rimane uno dei linguaggi migliori disponibili
Questo lo dici te. Sicuramente un ottimo linguaggio per imparare a programmare.

Mi rendo conto che ho portato l'argomento della discussione molto OT...

Prova a dire ad un programmatore embedded per esempio, e non è un settore di nicchia, che programmare in C o C++ non ha senso e che esistono altri tool più semplici ed altrettanto funzionali. Poi vedrai cosa ti rispondono.
Non capisco cosa c'entra con il mio discorso :boh: Spiegati meglio.

Per farlo bene dovresti scrivere una versione per Mac, una per Windows e una per Linux. E non è detto che comunque riusciresti essendo queste librerie solo un subset di quelle native (per motivi di compatibilità). A questo punto perchè usare una libreria limitante e non usare direttamente quella nativa?!!

Forse perchè scrivo il codice solo una volta.
Guarda che se creo un menu in wx, il menu viene creato in modo nativo sui sistemi in cui viene compilato. Essendo il menu wx un interfaccia astratta per il menu nativo il risultato è identico a quello creato nativamente. Io uso wx tutti i giorni (come moltissimi altri sviluppatori) e se non incomincia a pasticciare con le opzioni, ottieni un risultato uguale all'utilizzo delle librerie native.
Inoltre wx/qt non è affatto limitato rispetto per esempio a MFC (anzi ci sono cose che in wx/qt sono già presenti e in mfc devi implementartele a mano.)

Per farlo bene dovresti scrivere una versione per Mac, una per Windows e una per Linux. E non è detto che comunque riusciresti essendo queste librerie solo un subset di quelle native (per motivi di compatibilità). A questo punto perchè usare una libreria limitante e non usare direttamente quella nativa?!!
Perché i costi di sviluppo, di manutenzione, di supporto post vendita triplicherebbero :D

Non capisco cosa c'entra con il mio discorso :boh: Spiegati meglio.

Hai detto:
...
Usare Eclipse per programmare in C o C++ non ha senso, esistono altri tool più semplici ed altrettanto funzionali, sempre multipiattaforma. Vedi Code::Blocks e QTCreator.
...

Io ti ho fatto un esempio in cui lavorare in eclipse in c++ è la scelta ideale.

Hai detto:
...
Usare Eclipse per programmare in C o C++ non ha senso, esistono altri tool più semplici ed altrettanto funzionali, sempre multipiattaforma. Vedi Code::Blocks e QTCreator.
...

Io ti ho fatto un esempio in cui lavorare in eclipse in c++ è la scelta ideale.
E cosa mi dovrebbe far preferire Eclipse a Code::Blocks per programmare su sistemi embedded in C++ ? Forse non sono aggiornato.

wxWidgets io sinceramente lo trovo molto buggato, preferisco di gran lunga QT. Comunque ciò non succede quando la maggior parte delle librerie è inclusa nel framework del linguaggio. Vedi Java: documentazione uniforme, garanzia di aggiornamenti di pari passo, garanzia di retrocompatibilità. Cose che, con la miriade di librerie indipendenti che costituiscono l'universo Python, non sono assolutamente garantite.

Questo lo dici te. Sicuramente un ottimo linguaggio per imparare a programmare.

Su python puoi usare anche qt.
La maggior parte delle librerie è inclusa nel framework principale, anche se poi ci sono tantissime librerie esterne in aggiunta. Il framework pricipale di python ti permette di scrivere applicazioni complesse senza necessità di librerie esterne (ad eccezione di una librerie per interfacce grafice). Comunque la situazione librerie è più o meno quella di java. Le librerie standard di java sono più o meno quelle standard di python. Se necessiti di librerie esterne in python più o meno necessiti di librerie esterne in java.

Forse perchè scrivo il codice solo una volta.
Guarda che se creo un menu in wx, il menu viene creato in modo nativo sui sistemi in cui viene compilato. Essendo il menu wx un interfaccia astratta per il menu nativo il risultato è identico a quello creato nativamente. Io uso wx tutti i giorni (come moltissimi altri sviluppatori) e se non incomincia a pasticciare con le opzioni, ottieni un risultato uguale all'utilizzo delle librerie native.
Inoltre wx/qt non è affatto limitato rispetto per esempio a MFC (anzi ci sono cose che in wx/qt sono già presenti e in mfc devi implementartele a mano.)

Non capisci, mi spiace.
Forse non in tutte le piattaforma c'è l'attenzione dei dettagli che c'è sui Mac.
Un programma non nativo si riconosce subito. Ed è veramente FASTIDIOSO.
Non ci sono automatismi che tengono.

Le preferenze devono essere una file XML di tipo .plist salvate nel posto giusto; nella barra dei menu il 70% dei comandi sono standardizzati; le preferenze sono fatte in un certo modo (a modello delle preferenze di sistema, di solito); il layout delle applicazioni ha un certo aspetto (molto influenzato dalle applicazioni Apple più importanti, ed: iTunes; che si applica al contesto); l'applicazione deve essere distribuita in un unico bundle (icona) non ci devono essere files sparpagliati in giro!; i pulsanti (da Tiger in poi) stanno bene direttamente nella barra della finestra; le finestre di dialogo devono essere fatte con certi criteri; i VERBI dei comandi devono essere scritti in un certo modo (diversi da quelli di Windows!!); il copia & incolla deve supportare i formati grafici nativi (stili dei testo e PDF su tutti!!!).... e potrei continuare ancora.

Insomma ci sono diversi aspetti che fanno un'applicazione "nativa" da un compromesso multipiattaforma.

Magari come frontend ;) Potrei dire tante di quelle cose su Python da riempire una discussione, soprattutto sulla presunta professionalità delle librerie esterne al framework principale (in particolare per quanto riguarda la documentazione), ma qui siamo OT :D
E sull'enorme produttività di Python hai qualcosa da dire? :O :D

Ovviamente Google, Yahoo, Microsoft, IBM, Telco, ecc. amano affidarsi a strumenti "poco professionali". ;)

E cosa mi dovrebbe far preferire Eclipse a Code::Blocks per programmare su sistemi embedded in C++ ? Forse non sono aggiornato.

Per esempio perchè esistono plugin per eclipse per sviluppare ed integrarsi sui vari sistemi nativi embedded.
Perchè le società che forniscono sistemi per sviluppare in embedded producono quasi sempre plugin per interfacciarsi con eclipse.
Perchè il sistema di remote debugging / target / architecture con eclipse è tra i più versatili a disposizione.
Ma poi ci sono molti altri motivi.
Ovviamente questo non vuol dire che lavorare con Code::Blocks non sia possibile, ma solamente che non è vero che usare Eclipse per C/C++ non abbia senso.

Non capisci, mi spiace.
Forse non in tutte le piattaforma c'è l'attenzione dei dettagli che c'è sui Mac.
Un programma non nativo si riconosce subito. Ed è veramente FASTIDIOSO.
Non ci sono automatismi che tengono.

Le preferenze devono essere una file XML di tipo .plist salvate nel posto giusto; nella barra dei menu il 70% dei comandi sono standardizzati; le preferenze sono fatte in un certo modo (a modello delle preferenze di sistema, di solito); il layout delle applicazioni ha un certo aspetto (molto influenzato dalle applicazioni Apple più importanti, ed: iTunes; che si applica al contesto); l'applicazione deve essere distribuita in un unico bundle (icona) non ci devono essere files sparpagliati in giro!; i pulsanti (da Tiger in poi) stanno bene direttamente nella barra della finestra; le finestre di dialogo devono essere fatte con certi criteri; i VERBI dei comandi devono essere scritti in un certo modo (diversi da quelli di Windows!!); il copia & incolla deve supportare i formati grafici nativi (stili dei testo e PDF su tutti!!!).... e potrei continuare ancora.

Insomma ci sono diversi aspetti che fanno un'applicazione "nativa" da un compromesso multipiattaforma.

Ho capito quello che vuoi dire ma credo che sia tu a non capire il punto.
Facciamo l'esempio delle finestre di dialogo:
Io scrivo una finestra di dialogo in wxwidgets usando un wxDialog. Questa classe utilizza la classe nativa del sistema per cui è compilato. Quindi se non cambi nulla è "come se chiamassi direttamente la classe nativa". In altre parole la finestra di dialogo non viene ridisegnata da wx in modo simile al sistema target ma utilizza direttamente le librerie del sistema target.

E sull'enorme produttività di Python hai qualcosa da dire? :O :D

Ovviamente Google, Yahoo, Microsoft, IBM, Telco, ecc. amano affidarsi a strumenti "poco professionali". ;)
No, Python è molto produttivo. Senza ombra di dubbio.
Cesare, non fraintendere (volutamente ?) le mie parole: non ho detto che Python non è professionale, ho detto che a volte non sono a livello professionali (come documentazione e supporto) librerie che chi programma in Python è costretto ad usare perché il framework è più limitato di quello di Java.
Per esempio perchè esistono plugin per eclipse per sviluppare ed integrarsi sui vari sistemi nativi embedded.
Perchè le società che forniscono sistemi per sviluppare in embedded producono quasi sempre plugin per interfacciarsi con eclipse.
Perchè il sistema di remote debugging / target / architecture con eclipse è tra i più versatili a disposizione.
Ma poi ci sono molti altri motivi.
Ovviamente questo non vuol dire che lavorare con Code::Blocks non sia possibile, ma solamente che non è vero che usare Eclipse per C/C++ non abbia senso.
Non sono molto aggiornato in campo embedded, comunque la motivazione è semplice: perché Eclipse è un ottimo programma e scrivere un plugin è sicuramente più facile che modificare uno qualsiasi degli editor già esistenti.
Comunque ribadisco che usare CDT per scrivere codice C e C++ è come usare un elefante per farmi grattare la schiena.

Se necessiti di librerie esterne in python più o meno necessiti di librerie esterne in java.
Io non direi che la cosa stia in questi termini. Solo il fatto che ti serva un framework per la GUI è castrante (c'è il framework per la GUI nella libreria Python, ma è l'interfaccia con l'obsolescente Tk).
Solo per accedere ai vari DBMS hai bisogno per ognuno di una libreria diversa (tranne i pochi supportati nel framwork ufficiale). Il che vuol dire avere per ognuno una documentazione diversa.
Ovviamente le differenze non si fermano qui, ma mi sembra che siano un buon esempio.
Dire che il framework ufficiale di Python è altrettanto ampio di quello di Java imho è negare l'evidenza ;)

No, Python è molto produttivo. Senza ombra di dubbio.
Cesare, non fraintendere (volutamente ?) le mie parole: non ho detto che Python non è professionale, ho detto che a volte non sono a livello professionali (come documentazione e supporto) librerie che chi programma in Python è costretto ad usare perché il framework è più limitato di quello di Java.

Non sono molto aggiornato in campo embedded, comunque la motivazione è semplice: perché Eclipse è un ottimo programma e scrivere un plugin è sicuramente più facile che modificare uno qualsiasi degli editor già esistenti.
Comunque ribadisco che usare CDT per scrivere codice C e C++ è come usare un elefante per farmi grattare la schiena.

Il framework python più limitato di quello java avrei da ridire. Per esempio ?
La maggior parte delle librerie python sono librerie specifiche che pure in java non trovi nel framework di base.
Per quanto riguarda la scrittura di plugin in eclipse sono d'accordo con te, comunque come ambiente di sviluppo per il c++ rimane comunque molto valido e alcune volte avere un elefante può avere i suoi vantaggi. Sono disposto ad avere una applicazione più pesante, ma che mi permetta i vantaggi di eclipse.

No, Python è molto produttivo. Senza ombra di dubbio.
Cesare, non fraintendere (volutamente ?) le mie parole:
Ho messo molte faccine proprio perché non voglio polemizzare. ;)
non ho detto che Python non è professionale, ho detto che a volte non sono a livello professionali (come documentazione e supporto) librerie che chi programma in Python è costretto ad usare perché il framework è più limitato di quello di Java.
Sì, ne abbiamo già parlato. Il fatto di avere un framework enorme è un vantaggio per Java, ma anche la sua croce, perché lo rende un ambiente enorme e pesante.

Ad esempio per realizzare un "Hello, world!" con AWT vengono caricate circa 600 classi, e circa 800 con SWT. Questo ovviamente senza smanettare con class loader & affini, che sono argomenti più avanzati.

E il tutto perché? Perché Java si porta dietro il pallino della retrocompatibilità a tutti i costi.

Quando si arriva a un certo livello di saturazione trovo molto più sensato fermarsi un attimo, riprendere il progetto, e rimodellarlo, anziché continuare ad aggiungere pezze su pezze facendolo diventare mastodontico e difficile sia da manutenere che da utilizzare.

Anche Python ha molte librerie, ma in numero decisamente inferiore e per due motivi: perché gli sviluppatori non vogliono farlo diventare un mostro come Java, e perché per le librerie dev'esserci nel team almeno una persona che se ne prende cura.

Se non c'è nessuno che se ne occupa e nessuno che se ne prende carico, nel giro di qualche release viene fatta fuori senza se e senza ma.

E questo avviene anche per librerie ritenute ormai obsolete.

Indubbiamente viene meno la retrocompatibilità (anche se, in questi casi, esiste un iter preciso prima che una libreria esca da quella standard) e c'è molta meno roba, ma è un modello che finora s'è rivelato vincente e abbastanza reattivo ai cambiamenti nel mercato del software.

Tra parentesi, anche Python ha una libreria per lo sviluppo di GUI integrata in quella standard. E' la Tk, ma personalmente non mi piace. E già qualcuno nella mailing list che ha già messo sul piatto l'idea di farla fuori.

Anche per piacerebbe una bella libreria integrata in quella standard per realizzare GUI, ma se il costo è quello di generare mostri, meglio lasciare il fardello agli sviluppatori esterni. Tra l'altro ci sono tanti progetti molto interessanti e versatili, che sono pure retrocompatibili.

Casualmente, oggi mi hanno passato un link: http://arstechnica.com/open-source/guides/2009/03/how-to-deploying-pyqt-applications-on-windows-and-mac-os-x.ars che può essere utile. ;)

Io non direi che la cosa stia in questi termini. Solo il fatto che ti serva un framework per la GUI è castrante (c'è il framework per la GUI nella libreria Python, ma è l'interfaccia con l'obsolescente Tk).
Solo per accedere ai vari DBMS hai bisogno per ognuno di una libreria diversa (tranne i pochi supportati nel framwork ufficiale). Il che vuol dire avere per ognuno una documentazione diversa.
Ovviamente le differenze non si fermano qui, ma mi sembra che siano un buon esempio.
Dire che il framework ufficiale di Python è altrettanto ampio di quello di Java imho è negare l'evidenza ;)

Non credo sia castrante utilizzare un framework esterno che comunque è ben integrato nel framework principale.
Per i db ci sono comunque librerie di astrazione (es. sqlAlchemy) anchesse ben integrate nel framework principale.
Ma l'origine del discorso era che comunque ci sono ottime librerie, ben integrate e mantenute (senza problemi di compatibilità ed altro) e con valida documentazione.
E' ovvio che poi assieme ad esse ce ne siano altre buggate, poco mantenute, con documentazione scarsa, ecc. Ma questo capita in tutti i linguaggi.
E comunque le librerie esterne che di solito possono servire sono comunque tutte librerie di ottima qualità.

Facciamo l'esempio delle finestre di dialogo:
Io scrivo una finestra di dialogo in wxwidgets usando un wxDialog. Questa classe utilizza la classe nativa del sistema per cui è compilato. Quindi se non cambi nulla è "come se chiamassi direttamente la classe nativa". In altre parole la finestra di dialogo non viene ridisegnata da wx in modo simile al sistema target ma utilizza direttamente le librerie del sistema target.

Il fatto è che su Mac le finestre di dialogo si creano con Interface Builder che gli da un aspetto tipico (disposizione comandi, aree), per chiuderle ed applicare i cambiamenti ci sono convenzioni differenti (es. NON si usa un pulsante "applica", i cambiamenti sono in real-time e basta), per dismettere il dialogo si usano approcci differenti (di solito con il pulsante di chiusura finestra, senza OK o Cancel), tra i diversi "panes" la finestra si ridimensiona automaticamente in base al contenuto con un'animazione; le finestre possono essere modali o meno a seconda del contesto... Insomma in una piccola cosa come una finestra di dialogo un'applicazione non nativa fa tipicamente DECINE di sbagli.

E quello è solo un esempio.

Il fatto è che su Mac le finestre di dialogo si creano con Interface Builder che gli da un aspetto tipico (disposizione comandi, aree), per chiuderle ed applicare i cambiamenti ci sono convenzioni differenti (es. NON si usa un pulsante "applica", i cambiamenti sono in real-time e basta), per dismettere il dialogo si usano approcci differenti (di solito con il pulsante di chiusura finestra, senza OK o Cancel), tra i diversi "panes" la finestra si ridimensiona automaticamente in base al contenuto con un'animazione; le finestre possono essere modali o meno a seconda del contesto... Insomma in una piccola cosa come una finestra di dialogo un'applicazione non nativa fa tipicamente DECINE di sbagli.

E quello è solo un esempio.

Forse non ho capito il tuo discorso, comunque il tuo esempio mi pare un insieme di regole di programmazione, non di librerie, per esempio:
NON si usa un pulsante "applica", i cambiamenti sono in real-time e basta: ok, associo il cambiamento all'evento edit dei componenti.
per dismettere il dialogo si usano approcci differenti (di solito con il pulsante di chiusura finestra, senza OK o Cancel): intercetto l'enevento di close di una finestra.
Le finestre possono essere modali o meno a seconda del contesto: questa cosa non la conosco, comunque visto che nel nostro esempio un dialog ws si basa su un dialog Cocoa, se la modalità è gestita direttamente dal componente dialog di Cocoa, allora lo stesso comportamento lo avrai anche con un dialog wx che gira su Mac, altrimenti è il programmatore che lo deve gestire.

Ottime domande Jordan. Faccio una premessa, vediamo se la condividi: se IBM acquista Sun, Java verrà relegato principalmente al mercato Enterprise.


Il fatto è che pure adesso la Sun sul desktop con Java non è che ci ha investito gran che. :fagiano:
Quando parliamo di JEE, mi viene da fare l'inchino. :ave:
Quando parliamo di JME, mi viene da fare l'inchino. :ave: (i profili CDC e il prossimo MIDP 3.0 sono sensazionali)
Se però parliamo delle features desktop di JSE, bisogna riconoscere che c'è molto potenziale non ancora sfruttato. I SwingLabs hanno progetti molto interessanti in questa direzione, peccato che molti di essi sono ancora embrionali. Alcuni di quei progetti verranno inclusi nativamente nel JDK 7.

Quando le GTK+ furono sufficientemente mature, Miguel De Icaza iniziò il progetto Gnome.
Quando le QT mostrarono il loro potenziale, Aaron Seigo iniziò il progetto KDE.

Io ho sempre sognato che arrivasse qualcuno e iniziasse un progetto desktop completamente basato su Java/Swing. Spero che prima o poi questo sogno si avveri.

A me piu' che altro preoccupa il modo di come proseguirà lo sviluppo di Java SE 7 dopo l'acquisizione. Spero solo che non ci siano grossi stravolgimenti e che la Sun continui a fare la Sun anche se porteranno l'etichetta IBM.

Comunque a chi citava Gnome-Do come bell'esempio di applicazione C#/Mono io propongo Aerith:
https://aerith.dev.java.net/
https://aerith.dev.java.net/images/aerith8.png

Scritto da Sua Santità in capo Joshua Marinacci.

Spattacolo :eek:
Per fare una cosa del genere in Java, non saprei nemmeno da che parte iniziare.

Il fatto è che pure adesso la Sun sul desktop con Java non è che ci ha investito gran che. :fagiano:
Quando parliamo di JEE, mi viene da fare l'inchino. :ave:
Quando parliamo di JME, mi viene da fare l'inchino. :ave: (i profili CDC e il prossimo MIDP 3.0 sono sensazionali)
Se però parliamo delle features desktop di JSE, bisogna riconoscere che c'è molto potenziale non ancora sfruttato.
....
A me piu' che altro preoccupa il modo di come proseguirà lo sviluppo di Java SE 7 dopo l'acquisizione. Spero solo che non ci siano grossi stravolgimenti e che la Sun continui a fare la Sun anche se porteranno l'etichetta IBM.

Ma quante caspita di implementazioni/versioni di Java esistono?!? :eek:

Ma quante caspita di implementazioni/versioni di Java esistono?!? :eek:

Di fatto una sola :D
La EE sono librerie aggiuntive, le ME sono librerie aggiuntive più la JVM "ridotta". La SE è la somma di JVM + SDK, la base di tutto.
Java 6 ha cercato di fare un salto in avanti con Swing e un motore DBMS integrato (basato su derby). Il progetto Matisse è stato incluso nell'SDK per permettere la creazione visuale delle interfacce, ma siamo ben lontani dai livelli di Visual Studio o Interface Builder.

Vediamo cosa saprà fare Java 7.

Ma quante caspita di implementazioni/versioni di Java esistono?!? :eek:
Principalmente tre:
- JEE per i server e applicazioni enterprise
- JME cellulari e MID
- JSE desktop

ma a proposito di java, non ho seguito più molto ultimamente, questa versione 1.7 a che punto è ? si vede all'orizzonte ? forse ricordo male ma sembra ci stiano mettendo una vita rispetto ai major update precedenti :stordita:

si prevedono novità importanti a livello di linguaggio o è tutto tranquillo sul quel fronte ?

una curiosità poi, il codice della jvm della nuova versione sarà 100% open o hanno rimandato a release ancora successiva la reimplementazioni di quelle (piccole) parti che non avevano potuto aprire ? (perché era codice preso in licenza da terze parti nella "notte dei tempi" e sempre rimasto nelle implementazioni della jvm)