Nonostante l’importante presenza di protocolli di comunicazione IM totalmente aperti ed alquanto interessanti (leggi Jabber), la stragrande maggioranza dei navigatori italiani preferisce sfruttar ancora programmi con alla base tecnologie proprietarie come MSN Messenger.
Nulla da dire sul software di casa Microsoft ma, come tutti gli utenti Linux avranno sicuramente notato, non esiste una versione ufficiale del programma in grado di girare sul sistema operativo del pinguino. Se aggiungiamo poi che le ultime release del programma non riescono ad andare neanche con WINE, la ricerca di programmi alternativi diventa quindi indispensabile.
Esistono molti progetti attivi in grado di sfruttare il protocollo, seppur non al 100%, di MSN Messenger (MSNP) che negli ultimi anni, grazie ad una sempre più veloce opera di reverse engineering, sono riusciti a costituire interessantissime alternative al programma originale.
Focalizzando la nostra attenzione su programmi mono-protocollo, il primo pensiero va sicuramente ad individuare aMSN come vera replica di MSN Messenger ma progetti come Pymsn e di conseguenza Emesene negli ultimi mesi stanno riscuotendo un incredibile successo.
La loro forza sta nel fatto che sono interamente programmati in Python e che quindi sono (relativamente) facili da modificare e da adattare. Il linguaggio di cui sopra ha molti punti di forza e pochi talloni d’Achille, il che è per molti sinonimo di sicurezza e stabilità.
Ovviamente una tale frammentazione delle forze alla ricerca del MSN Messenger perfetto per Linux non fa bene a nessuno dei progetti sopra citati; con un annuncio inaspettato però, i maggiori sviluppatori di aMSN, Pymsn ed Emesene hanno deciso di unire le proprie conoscenze per dar vita ad aMSN2.
Il programma sarà scritto interamente in Python e, udite udite, sfrutterà le enormi potenzialità delle librerie EFL (Enlightenment Foundation Libraries), le uniche in grado di garantire l’aspetto avveniristico poco incline a GTK e prestazioni di tutto rispetto impossibili da ottenere con QT.
aMSN2 è ancora un “disegno di progetto” e di conseguenza non esistono ancora snapshot funzionanti; da quanto si legge però sul comunicato presente sul forum di amsn-project.net, a breve verrà offerto il primo codice sorgente via SVN.
Che sia l’inizio di una piccola rivoluzione nel mondo dell’instant messaging?
Via | Digg
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, chi siamo
© 2004-2011 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
xerbia
17 giu 2008 - 07:09 - #1secondo me è una gran cosa!!!
anche perchè io ho installati sia aMSN che emesene il primo lo uso quando mi serve la webcam il secondo lo uso più volentieri perchè risulta più user-friendly più facile da usare ed è più reattivo.
Mettere insieme questi progetti può solo portare qualcosa di buono. EVVAI!!!!!!!!!!
Mastro Ciso
17 giu 2008 - 07:40 - #2Direi…. WOW!
John McCain
17 giu 2008 - 07:47 - #3Finalmente qualcuno che unisce gli sforzi… Si dovrebbero vedere più spesso annunci del genere. :)
Gianca77
17 giu 2008 - 07:47 - #4Ri-direi… WOWOW!!
Lybra
17 giu 2008 - 07:59 - #5VEdiamo cosa salterà fuori, personalmente odio aMSN perchè è pesantissimo e preferisco emesene per facilità d’uso e per i plugin già installati.
Manca ancora del tempo ma speriamo che riescano a far saltare fuori qualcosa di bello anche graficamente…l’unica cosa che manca a pidgin è un’interfaccia carina e guardabile
Aska
17 giu 2008 - 08:01 - #6bella news.
speriamo che la loro collaborazione funzioni. :D
sTeNo
17 giu 2008 - 08:17 - #7mi aggiungo ai WOWOWO :)
cga
17 giu 2008 - 08:17 - #8premetto che uso pidgin su gnome e kopete su kde perché ho vari account su vari servizi (fra cui jabber) e preferisco un unico client per gestire tutti gli im. (a parte irc, per il quale uso weechat su qualsiasi desktop).
ad ogni modo questa unione è IMHO qualcosa di estremamente positivo. trovo che sia un segno di maturità da parte dei tre progetti coinvolti e che possa portare al client “definitivo” per msn.
spero che altri progetti seguano l’esempio per ridurre la frammentazione e per implementare pochi programmi con un obbiettivo ben preciso e con feature che possano far dire alle utenze che provengono da altri sistemi: “wow, non rimpiango affatto $programma di $sistema_operativo”
è vero che esiste una positività nel darwinismo del software libero ma io sono convinto che sia giunta l’ora di concentrare le forze e di puntare a “un programma” per ciascheduna cosa e farlo bene. imho. e per dirla tutta credo che la proposta (benché utopica e imho non fattibile) di shuttleworth di cadenzare e sincronizzare le release di sw e distro sia lodevole e meritevole, quanto meno, di un analisi.
my tw cents
pikiweb
17 giu 2008 - 08:26 - #9ma sono notizie fantastiche! progetti finora concorrenti che, giustamente, uniscono le forze per creare un unico programma funzionante. spero e credo si vedrà quello che si aspettava chiunque usasse uno di questi programmi: il supporto alle varie features dell’MSN ufficiale che aveva aMSN, in un programma non eccessivamente pesante e graficamente integrato nel desktop come emesene
a proposito di integrazione col desktop, nel comunicato si legge che oltre a EFL, saranno presenti anche front-end in GTK, in cocoa, in ncurses (?) e forse anche in QT e XUL
un progetto da seguire fin dall’inizio :)
Ecas
17 giu 2008 - 08:27 - #10Finalmente un OTTIMA notizia!
Tiferò per loro, grandissimi hanno capito tutto!
Marcoba
17 giu 2008 - 08:27 - #11che non si riesce ad ottenere con qt… faccio fatica a crederci
timendum
17 giu 2008 - 08:28 - #12Chiaramente sono solo positivo e contento, quando si collabora c’è solo da guadagnarci.
Ma aMSN è scritto in Tcl / Tk , che fanno un porting di linguaggio?
Andrè
17 giu 2008 - 08:45 - #13ottima notizia, secondo me la cosa migliore sarebbe concentrare gli sforzi su un’unica libreria fatta bene, con vari binding. così non servirebbe ogni volta reiniziare da zero
Anubisg1
17 giu 2008 - 08:47 - #14si tratta di una totale riscrittura del linguaggio non un semplice porting.
ad ogni modo, ad oggi amsn è l’unico programma in grado di sfruttare a pieno o quasi il protocollo msn, nessun’altro programma supporta animoticons e diavolerie varie. emesene,pidgin e compagni personalmente mi stanno davvero stretti.
un solo difetto nella scelta delle librerie efl per amsn2… se non usi enlightnment devi scaricarti da SVN un sacco di librerie BETA per un solo programma… e la cosa non è buona…
per fortuna ci saranno gui anche in QT e GTK, ma al momento attuale quella in efl è davvero la migliore
slot
17 giu 2008 - 08:48 - #15Finalmente, una volta tanto anzichè dividersi si sono uniti. Ci si stava dimenticando che il sorgente aperto non è solo un modo facile per fare fork quando si ha voglia, ma anche un modo facile di confrontare i sorgenti e unire i prodotti.
NoWhereMan
17 giu 2008 - 08:54 - #16aggiungo una nota a margine: pare che emesene non cesserà lo sviluppo indipendente
inoltre, su svn il codice è già disponibile, la gui qt4 è quella che negli ultimi giorni ha ricevuto più commit, ma la gtk già consente l’autenticazione
ciao :)
s
17 giu 2008 - 08:56 - #17In realtà non è proprio così, gli sviluppatori di Emesene scriveranno solo la GUI in gtk per aMSN2, ma il loro progetto continuerà ad esistere e lavoreranno per Emesene2. Comunque, obbiettivamente, è positivo tutto ciò, alla fine l’orrendo aMSN avrà finalmente un interfaccia decente e soprattutto perderà peso, d’altro canto Emesene probabilmente sarà facilitato nell’introduzione di audio e video.
alc0r
17 giu 2008 - 09:05 - #18Secondo me la cosa piu’ importante non e’ l’interfaccia grafica, ma il pieno supporto dei protocolli… se si vuole msn su linux e altri os bisogna concentrarsi soprattutto con questo aspetto.
ekerazha
17 giu 2008 - 09:20 - #19“La loro forza sta nel fatto che sono interamente programmati in Python e che quindi sono (relativamente) facili da modificare e da adattare.”
No… la vera forza è che Emesene usa GTK come libreria e non le anacronistiche Tcl/Tk e che a differenza di Pidgin non ha sviluppatori ultra-conservatori. Sul design del codice di Emesene stendiamo un velo pietoso (Python a parte, ad esempio non utilizza minimamente l’approccio multithread, nemmeno per disassociare il thread della GUI dal resto).
fabio.80
17 giu 2008 - 09:27 - #20no no, diciamolo pure, è una vaccata pazzesca… pesante, invadente, rozzo, confusionario, cafone e con la pubblicità che ti lampeggia nella finestra dell’applicazione (!)
lepre
17 giu 2008 - 10:09 - #21aMsn è indecente, io su linux usavo mercury messenger. è in java e non è open source, però non c’è paragone.
gp42
17 giu 2008 - 11:45 - #22ottimo.
gp
drf
17 giu 2008 - 11:56 - #23Pymsn e di conseguenza Emesene è una boiata mai vista. Pymsn non è alla base di Emesene e gli stessi sviluppatori di MSN sono contrari a questa libreria.
Così come il giudizio relativo a GTK e QT… Le prestazioni dei toolkit sono ormai alla pari, e l’utilizzo di Python annulla i piccoli margini tra di essi…
Ad ogni modo, lo sviluppo delle frontend è iniziato e tutte bene o male permettono il login… tuttavia non ci sarà nulla di utilizzabile se non entro un bel po’ di tempo, visto che il core è ancora in stato molto embrionale
PauLoX
17 giu 2008 - 11:57 - #24Personalmente ammiro molto più l’approccio di Pidgin: un programma multiprotocollo che funziona senza problemi e facilita la vita dell’utente in linea con la filosofia KISS.
Il fatto di dover avere un programma dedicato ad un unico protocollo mi sembra imbarazzante e strettamente legato al modus operandi dei protocolli e programmi closed.
Penso che il fatto che un utente possa usare un solo programma per comunicare con tutti i suoi contatti a prescindere dal protocollo che essi usano sia prioritario rispetto al fatto di essere compatibile con le ultime features di un protocollo proprietario.
Unica nota positiva del progetto è la cooperazione ma forse farebbero meglio a cooperare sulle librerie di protocollo che su un ulteriore client.
drf
17 giu 2008 - 11:57 - #25Typo nel commento: gli stessi sviluppatori di emesene, non di MSN
NoWhereMan
17 giu 2008 - 12:09 - #26@drf: come mai?
slot
17 giu 2008 - 12:54 - #27@24: considera anche chi ha tutti i contatti connessi con un solo protocollo e fa volentieri a meno di opzioni per gli altri 8… pidgin o kopete o chi per loro hanno molto senso ma di un programma come amsn, che copi per filo e per segno le caratteristiche di live messenger, c’è bisogno.
Framp
17 giu 2008 - 13:24 - #28Mah, penso che continuerò a usare kopete (non mi interessano tutte quelle diavolerie…)
Sulle prestazioni di QT starei attento però. Non arriveranno ai livelli di quelle leggerissime di EFL però le QT4 sono davvero ottime (il mio pc ha 8 - e dico 8 - anni e fa girare perfettamente kde4 beta 1)
zidagar
17 giu 2008 - 13:58 - #29È un pò azzardato fare certe valutazioni sulle QT, anche se sicuramente le EFL sono fenomenali.
Ritengo comunque cosa buona e giusta l’unione di questi bei progetti.
Tra tutti i sw che ho provato, per ora, mi trovo bene sono con Mercury Messenger, scritto in Java e aimè…closed. Però, al contrario di quello che si può pensare, seppur scritto in Java, è estremamente veloce.
Aspetto comunque questo aMSN2, sperando di poter abbandonare Mercury per un sw Open ;)
anonymous
17 giu 2008 - 14:24 - #30Ma tutti gli oppositori di Mono, perché reimplementazione di “robaccia scritta da Microsoft”, dove sono?
Questi stanno addirittura unendo gli sforzi per migliorare il supporto al protocollo di messenger (altra “robaccia Microsoft”) e nessuno dice nulla?
E i motivi etici?
E la paura dei brevetti?
ma
17 giu 2008 - 15:46 - #31Ma secondo voi è questo amsn2 ?
http://it.youtube.com/watch?v=dKJlxk7jFw8&eurl=http://fedmor.netsons.org/2008/06/17/anteprima-di-amsn-2/
Stefanauss
17 giu 2008 - 16:39 - #32@ 30.
Allora cosa facciamo? Non supportiamo ActiveDirectory? Facciamo chiudere Samba?
Una cosa è un protocollo, un’altra il codice che lo implementa.
molok
17 giu 2008 - 17:05 - #33You can type ./amsn2.py –help for more info… and the front ends can be selected with -f :
./amsn2.py -f efl
./amsn2.py -f gtk
./amsn2.py -f qt4
pare quindi che supporti sia efl, che gtk che qt4; forse si sono uniti per fare un backend unico, e poi ogni gruppo lavora al frontend in maniera indipendente.
anonymous
17 giu 2008 - 17:07 - #34@Stefanauss
Bisognerebbe spiegarlo a quelli della tribù sudo apt-get remove –purge libmono*
Se il software proprietario serve per far girare compiz (vedi driver nvidia) allora è OK.
Se la reimplementazione di una tecnologia proprietaria permette di rimorchiare su msn allora è OK.
Ma guai a nominare Mono!!! Il cavallo di trojan della Microsoft!!!
Chissà perché……… anzi so il perché ma non lo dicoke.
NoWhereMan
17 giu 2008 - 17:09 - #35@ma : sì
@molok: più o meno
Raldo
17 giu 2008 - 18:24 - #36Al di la’ di tutte le boiate mono/microsoft, e’ oggettivo che mono sia tremendamente pesante, sia come dimensioni che prestazioni. Per quanto mi riguarda, dato che bene o male ci sarebbero al massimo 2 applicazioni fra quelle disponibili interessanti, lo evito come la peste. Stessa cosa coi driver proprietari. Il 3D non e’ propriamente necessario.
Raldo
17 giu 2008 - 18:28 - #37Che poi, a parte audio/video chiamate, chi pazzo sente l’esigenza di trentamila emoticon, cinque giochi in stile pinball, caratteri fluorescenti e pesci nel cranio?
Fox -ino
17 giu 2008 - 19:16 - #38@Anonymous
Una cosa è avere un programma (o 2,3…100) che implementano parti di codice o protocolli o formati proprietari (samba, msnp, .doc ecc…) un’altra è avere qualcosa su cui basare n-mila programmi per fare cose semplici di cui magari abbiamo già software esistente (vedi monolight/silverlight su falsh/ajax ecc… oppure banshee con i vari linsten,exaile,amarok,atunes ecc.. o il sostituto di brasero in mono o il diva-project o il sostituto di elisa)
Tutto questo dicendo che è più veloce da scrivere di c++, con più sviluppatori, più portabile.
Diciamo che attualmente accetterei mono solo perché sopra ci è stato sviluppato gbrainy …ma esclusivamente perché non conosco alternative a questo giochino.
.doc e le altre parti proprietarie potremo eliminarle pian pianino, se troveremo riusciremo a convincere la gente (vedi odt, o jabber/jingle). un framework difficilmente lo estirpi perché elimini tutto ciò che ci è stato costruito sopra.
Nessuno si ricorda i danni (che mica sono spariti) dell’avere standard riconosciuti ma non seguiti da microsoft? html 3/4 non vi dice niente?I vari gwbasic/qbasic/quickbasic?
Non tutto ciò che viene da Microsoft è male, ma non si può prenderlo come oro, soprattutto se si può farne a meno!
yemmi
17 giu 2008 - 19:20 - #39ma cambiare in massa protocllo e spostarsi su jabber no eh?
franz1789
17 giu 2008 - 20:47 - #40@anonymous, allora ci vediamo su jabber ok? se uso msn è solo perchè ci sono costretto, sennò io ho usato prima ICQ, poi Skype e poi infine Jabber, ma siamo in quattro, di cui solo uno connesso stabile. Mi spieghi un solo motivo per cui dovrei usare per forza mono? ma che sei uno sviluppatore te, che difendi la tua creatura? preferisco usare roba M$ solo quando non mi è permesso fare altrimenti (ati ad esempio ha dei driver sviluppati “apertamente”, anche se poi voglio vedere quanto è realmente così) e non quando è solo un “prurito” (chiurito nel mio dialetto) di programmatori che pensano usare C# possa fare fico, o possa essere comodo. Ci sono cose su cui si può discutere, e cose che invece non possono essere contestate.
bautz
17 giu 2008 - 22:21 - #41Ah, ecco perchè l’svn di emesene sembrava morto.
Comunque, Galaxium ne è rimasto tagliato fuori?
http://code.google.com/p/galaxium/
anonymous
17 giu 2008 - 23:29 - #42Se a qualcuno non piace qualcosa non c’è nulla da discutere.. sono gusti.
Però diciamo una volta per tutte che quando si tira in ballo l’etica, i brevetti software, etc si sta facendo solo del FUD.
La prova sono i commenti entusiasti a questo articolo e quelli meno entusiasti nel post in cui si discuteva su Mono.
(programmo in altri linguaggi e guardo il C# da lontano quindi non è una mia creatura da difendere).
Fox -ino
17 giu 2008 - 23:30 - #43ecco mi ero dimenticato di galaxium…un’altra applicazione mono di cui si poteva fare a meno. Identica a pidgin come idea (multiprotocollo+multipiattaforma) ma non mi sembra molto più sviluppatata delle altre varie applicazioni di messaggistica che sono fatte in python.
CronoX
18 giu 2008 - 01:57 - #44magnifico!!!uniamo le forze ragazzi!
FedeVecna
18 giu 2008 - 22:56 - #45Sono molto fiducioso nel progetto…speriam che venga su bene!!!
L’unica cosa che non mi piace è il nome…perchè aMsn2???
Suona male e sembra “privilegiare” solo un team di sviluppo…non si può cambiare? xD
ekerazha
19 giu 2008 - 17:07 - #46@Raldo
In un linguaggio/piattaforma non ci sono solo le prestazioni… e potresti accorgertene se verrà trovata una falla di buffer overflow nel tuo velocissimo instant messenger scritto in C. Ovviamente discorso diverso si fa per Python (con la sua principale implementazione), che è oggettivamente più lento di C#/Mono.
Markon
09 lug 2008 - 09:20 - #47“L’unione fa la forza”. E’ sempre stato così.
Diciamo che uso amsn per la cam, emesene perchè leggero.
Condividendo le conoscenze gli sviluppatori potranno dar vita a un ottimo client msn.
Bravi e continuate così!
olympicmew
21 lug 2008 - 21:03 - #48@ekerazha: Python più lento di Mono? Ma tu i programmi li usi? Prova ad usare Banshee, e poi Exaile. Dimmi qual’è il più veloce…