Malgrado io abbia fortissime convinzioni a riguardo, non voglio entrare nel merito della piccola guerra fredda tra i team di questi due progetti, che serpeggia all’interno di Planet GNOME, in cui è ormai consuetudine leggere frecciate velenose tra gli sviluppatori di entrambi i progetti.
Ieri c’è stata una specie di piccola crisi diplomatica, causata da fraintendimenti sorti in seguito a dichiarazioni non esattamente corrette e risposte ancora più discutibili…
Sapete già tutti dell’esistenza di qualche problema legato alla figura di Jamie McCracken, il project leader di Tracker, tanto versato nello scrivere codice quanto apparentemente bloccato nei rapporti interpersonali e “interprogettuali” (ho inventato una parola?). Nel post “Tracker della discordia… o no?” evidenziavo come Jamie non perda nessuna occasione per esternare il suo ardore in maniera spesso poco opportuna e a volte proprio molesta.
D’altra parte il project leader di Beagle, tale Joe Shaw, stipendiato da Novell per lavorare su Beagle e guidarne il team di sviluppo, non perde occasione per utilizzare questo lato un po’ pittoresco del carattere di Jamie a proprio vantaggio, proponendosi di volta in volta come consigliere, saggio, vittima, amicone, suggeritore, detentore di verità, eccetera, e per pubblicizzare la bontà di Beagle, che ricorderete tutti, fa le stesse cose di Tracker ma si basa su Mono…
L’ultima zuffa è avvenuta ieri, ricordate il post “Bigboard, Mugshot e “GNOME Online” (+ polemica)“, in cui si parlava di “individuo isolato contro grossa azienda multinazionale”? Bene, Jamie è piombato nella discussione tirando ovviamente in ballo Tracker :D e dicendo che lui da solo sta vincendo la guerra contro Beagle (Novell) perché la sua è una tecnologia disegnata in maniera migliore. Che si sappia: io condivido al 101% questa sua affermazione…
Ma forse era un po’ un andarsi a cercare la rissa, tant’è che la risposta di Joe non si è fatta attendere, ed è stata a base di offese, cronologia di eventi passati, vittimismo, accuse di insensatezza… non mi sento di condannare o assolvere neanche la sua reazione, ma sembrava certamente di stare a leggere le baruffe di una giovane coppia in crisi. Tanto che alla fine mi sono detto: “so’ ragaaazzi!“. Questo tipo di guerra è quasi un sintomo di salute della nostra comunità, ormai me ne sto convincendo.
Anche io ho imparato a smettere di preoccuparmi e amare la guerra fredda
Ma già, la guerra fredda e i vari flame fanno parte della nostra cultura, come ha di recente dichiarato Nat Friedman, che in quella stessa occasione, mentre faceva il grande saggio, non ha tralasciato di gettare fango su Tracker :D Per la cronaca, poi Jamie si è scusato con Joe per aver scritto frasi che potrebbero essere state fraintese, rivendicando il diritto umano di esagerare, a volte.
La mia posizione è quella dello spettatore che parteggia dichiaratamente per uno dei due contendenti (indovinate quale), ma mezzo divertito e mezzo annoiato, seduto in poltrona sgranocchiando coca cola e sorseggiando popcorn …o era al contrario? Boh, punti di vista, il gioco dei ruoli non è mai stato il mio forte :)
—
PS: Yeah Emmanuele, mando idealmente una stretta di mano ad entrambi ma… non ti permettere! La tua parola è troppo condizionante perché tu possa usarla così :D
Pecato si azzuffino, ma ammetto di essere clamorosamente di parte e sicuramente non per Novell. Questo mi porta a criticare tutti i loro progetti anche quando sono “buoni”.
“Beagle, che ricorderete tutti, fa le stesse cose di Tracker ma si basa su Mono”.
Mica vero. ;) Tracker dal punto di vista dei risultati di ricerca latita (sia in difetto che in eccesso) ancora rispetto a Beagle. Che poi “l’impianto generale” (leggi: integrazione totale) di Tracker sia migliore non è in discussione, ma direi che per quanto riguarda la qualità della ricerca Beagle rimane ancora migliore.
“bevo un cannone fumo un caffè…” cantavano tanti anni fa!
Per parteggiare per Tracker non ci vuole mica tanto…basta installarlo! :-)
Beagle succhia risorse in maniera esosa: lo scopo di un idicizzatore sarebbe quello di riuscire a stare in background a fare il lavoro “sporco” di estrazioni di informazioni dai file. Il resto le fanno lo fanno i client.
Quindi, per quanto mi rigurda: forza Tracker! (e QUESTA è SOLAMENTE UNA MIA OPINIONE, abbasso MONO!)
Non toccatemi mono!!! che colpa ne ha lui? :P
Ciauz
COCA COLA???? COCA COLA???? COCA COLA????!!?!?!?! cosa sentono le mie orecchie??? dietro la lavagna e per domani scrivere 100 volte il testo di http://it.wikipedia.org/wiki/OpenCola
;-)
Mi permetto io di citare Emmanuele stavolta:
http://www.emmanuelebassi.net/archives/2007/02/nuclear-war-on-the-dance-floor/
Tra Beagle e Tracker imho non c’è nemmeno paragone. al netto di Mono, Beagle è un progetto, Tracker è una crack.
E’ più di un anno che è in sviluppo, non offre una api e non ha backend per indicizzare praticamente nulla di utile, perchè tutto il tempo è stato sprecato a riscrivere N volte le varie parti del software, anzichè pensarle bene la prima volta.
@Artemis
Il tuo mi sembra un po’ un messaggio da flame, hai messo un collegamento di due mesi fa.
Nel frattempo un minimo di libreria di tracker è uscita (http://pollycoke.wordpress.com/2007/02/28/nasce-libtracker-gtk-per-integrare-tracker-in-gnome/).
Guarda le date e stupisci, 22 giorni dopo.
C’è da considerare anche il fattore temporale nelle opinioni personali. Col tempo possono pure cambiare le opinioni, non solo le circostanze (in questo caso sono cambiate solo quelle).
tracker è molto + veloce si! non lo trovo però così fatto bene, di utile indicizza solo i file (altri filtri sono ancora in uno stato “Planned support”), l’interfaccia ufficiale non è sta gran ficata, nella deskbar applet in feisty non funziona (dubito ci sia la 0.6 nella versione finale di feisty) e cmq io ho riscontrato molti problemi di sincronizzazione con il filesystem.
Per conto mio beagle non l’avrei fatto in mono (ma non capisco mono in se, visto che c’erano implementazione di java dello stesso livello qualitativo) è si molto + esoso di memoria ma almeno ha una gestione del progetto + oculata, un esempio: volevo correggere il problema della deskbar installando da sorgente la v0.6; compilo e che mi trovo? i sorgenti delle dipendenze all’interno dell’svn! non si dovrebbero mettere come dipendenza nel Makefile? sta di fatto che per non distruggere l’integrità del db dei pacchetti ho rinunciato all’aggiornamento.
Poi anche io ho beneficiato della velocità di tracker per un po’ di tempo ma da quì a dire che uno è merda è l’altro è oro, ce ne passa di acqua sotto i ponti! (vale anche il contrario). Lo so che ormai hai associato devil = ms & ms love novell => novell = devil ma odia novell non i suoi progetti (che oltretutto, a necessità possiamo forkare al volo)
@Roberto Mazzoleni
Si, un po’ di flamming nel mio messaggio c’è, ma è più dovuto al fatto che non riesco sinceramente a capire come si possa in così tanti andare dietro ad un progetto così poco “sano”.
Ho provato Tracker abbastanza, e non posso dire che sia *veramente* pessimo. Sarà utile tra 2 anni, temo, una giusta gestazione per un progetto di quella grandezza.
Le cose veramente pessime sono il metodo con cui è sviluppato e soprattutto come viene evangelizzato. Ha tanti fan mica per niente, solo che il progetto non vale un centesimo di quei fan.
Ho guardato anche libtracker, e sinceramente mi pare una cosa molto rozza. Quello che offre beagle per sviluppare applicazioni che lo usino è infinitamente superiore, ed è molto più documentato.
@Antonio
Io più che l’odio per Novell, che un po’ capisco, non capisco l’odio per Mono.
E’ una reimplementazione di un framework oggettivamente ben fatto e molto interessante (perchè se c’è una cosa che in M$ sanno fare bene sono proprio i linguaggi di programmazione…. ok, Visual Basic escluso. :)) ed è libero quanto basta per essere utilizzato senza problemi, e fino a quache mese fa era molto più libero di Java.
Forse è stato proprio Mono a convincere definitivamente Sun a rilasciare Java, dopo anni che parlava al vento, chi lo sa.
Certo è che se dovessimo rifiutare le cose che funzionano con Linux e che derivano da tecnologie Microsoft, come Mono, dovremmo rompere le scatole anche per Samba, per l’USB o per uPnP, ma nessuno avanza nessuna obiezione di tali tecnologie.
Io dico che tutti dicono che Mono = male perchè è di moda adesso.
Mono funziona benissimo, è molto comodo per sviluppare e abbastanza prestazione (sicuramente più prestazionale di Python). Per me tanto basta.
Tra i due litiganti, Strigi gode :P
quoto Artemis
@Artemis:
e quale altro linguaggio di programmazione avrebbe inventato la Microsoft escluso VB, prima dell’avvento dei vari #(sharp) di .NET ?
ci sono persone ben più esperte di me (tra cui Emmanuele, per dirne uno) che sapranno confutare adeguatamente questa affermazione. Comunque chi si autocelebra mi fa un po’ tristezza. Puoi dire “non mi piace com’è implementato Beagle e/o perché è basato su Mono” non che fa schifo.
Prova a dire ‘sta cosa su ICOD… :D
Non conosco i due codici, ma da quello che mi risulta il tipo è stato duramente criticato per la mancanza di un’idea chiara a proposito di tracker (cosa fa esattamente, sì, indicizza, ma come?).
Mi è più “simpatico” perché ho una repulsione per Mono (ma non mi piacerebbe nemmeno se fosse implementato in Java… si vede che mi stanno antipatici i bytecode), ma il fatto che sia sviluppato in C non gli dà il diritto sostenere che SOLO PER QUESTO il suo progetto sia migliore.
Le merde si possono scrivere in qualsiasi linguaggio :D
Beagle non è cattivo “per se” ma infatti perché é fatto in Mono. Bastano due dite di fronte per rendersi conto che un software del genere doveva essere implementato il più efficientemente possibile e invece, in una decisione ovviamente politica e non tecnica, hanno eletto il linguaggio “di casa”.
Finché non rifanno il Beagle in C, Pascal, o qualcosa del genere e un progetto senza futuro.
(PS: Erano anni che non scrivevo in Italiano, scusate)
@JPS
hai ragione forse era meglio il C, sta di fatto che la scelta forse era anche dettata dal fatto di usare Lucene (dotLucene) che è un indicizzatore di Apache di cui tutti dicono bene. E cmq ragazzi poche illusioni: non si può fare tutto in C; siamo nell’epoca dei linguaggi ad alto livello ed è ora di iniziare ad usarli!
@Artemis
Hai ragione!
La cosa che più mi fa arrabiare è quando sparlano di Java o C# per poi elogiare python! ma avete visto quanto occupa la deskbar-applet??
Io so solo che se nella comunità linux si iniziasse ad accettare maggiormente software in Java si avrebbero molti ma molti più sviluppatori di quelli che si hanno ora (Java è il linguaggio + usato al mondo: anche su sourceforge) ed invece no: si fanno i binding per i linguaggi di scripting più esoterici e non esiste un binding decente per Java, forse qualcosa ora si muove ora che Java è Open, ma le VM opensource sono sempre esistite quindi non è una scusa.
@Antonio
Sono con te!!!
Python succhia risorse come un matto… per non parlare della implemantazione dei threads che è penosa… due threads sono in grado di papparla la cpu!!!
IO AMO IL C!!! Ma forse in C beagle non avrebbe raggiunto tali risultati in così poco tempo!!! Le cose cambiano… la potenza di calcolo ormai è anche “troppa” rispetto a quello che con un pc si fa quotidianamente… quindi forse è meglio usarla per utilizzare linguaggi, frameworks e librerie che semplificano la scrittura di software, che facilitano il riuso del codice stesso e che permettano di non impazzire con bugs che da una parte si verificano e da un’altra no (salvo vm implementanti bugs!!! Insomma go mono & java!!!
Besos
I flame fanno parte della nostra vita “disposente” (termine dialettare per indicare i disgraziati e deficienti). I flame fanno comodo altrimenti ne faremmo davvero a meno!
(Cit.) Shurah :>
@JPS: Ma magari qualcosa che usi degli oggetti no? Sai, siamo nel 2007…. :)
@MonoGamo: Esattamente. I vantaggi offerti dalla esuberante potenza di calcolo dei nostri calcolatori è proprio che possiamo inventare ed usare linguaggi che sacrifichino le prestazioni e le dimensioni dell’eseguibile alla possibilità di avere codice più facilmente scrivibile, più manutenibile, più portatile, più riusabile.
Del resto l’unico grande ed enorme difetto di Gnome (e che i KDEisti ci (e mi) rinfacciano a ragione) è proprio quello di essere ancora scritto in C.
Un linguaggio non solo assolutamente inadatto ad una gui, ma ancora meno ad un ambiente integrato, alla comunicazione tra processi e ad usi intelligenti della memoria.
Infatti gnome pullula di binding esoterici, programmi che funzionano in linguaggi interpretati (su tutti python), wrapper assortiti (come gtkmm, per esempio)… tutto ciò che può facilitare il povero sviluppatore dal risparmiarsi nel scrivere 20 righe di codice per “simulare” un oggetto, o per far finta di avere delle librerie grafiche vere, quando invece ha solo un toolkit.
E ancora si va in giro a vantare il C come linguaggio ideale? Suvvia, siamo nel 2007, e perfino gli sviluppatori di Gnome l’hanno capito.
Se così non fosse Gnome sarebbe effettivamente tutto scritto in C, e non sarebbe invece un collage di C, C++, Python, Perl, Bash e Mono come è in realtà.
le macchine sono economiche, mentre il tempo dei programmatori é prezioso, la scelta di linguaggi di alto livello, piu comodi al programmatore, e meno legati alla macchina é quindi ragionevole. mono cmq non é un ottima scelta, é abbastanza libero, ma si alcune librerie comode che sono legate a implementazioni microsoft, e si rischia di rimanerci impantanati, e avere applicativi legati a windows (perche il programmaore prima o poi dirá se é semplice fare una cosa in windows, perche non sviluppare solo per quella piattaforma lí ).
un vecchio proverbio dice “timeo Danaos et dona ferentes”,
avvertendoci contro i regali dei nemici,
accettare un regalo da redmond suona un po come accettare una mela da una strega …
@bruno: Mono si configura come un “inseguitore” di .NET, non tanto come una reimplementazione completa. Siamo al 3° framework microsoft, e Mono supporta solo il primo e parti del secondo.
Non vedo dove sia il problema, specie che Microsoft continua a perseverare nell’iter per rendere .NET uno standard, come aveva fatto sembrare qualche mese fa.
Cosa che mi rienderebbe notevolmente felice, tra l’altro.
Imho sono ben altri i regalini di cui guardarsi dalla Microsoft: per esempio il fatto che siano riusciti a brevettare la fat. Mi sa che ci sono più rischi di rogne che arrivino da questa storia, piuttosto che da Mono.
il fatto che esistano linguaggi di alto livello non mi sembra una buona scusa. Scriviamo un sistema operativo in shell script, allora! Esistono applicazioni che scritte in un linguaggio di alto livello semplicemente NON sono efficienti.
Ora, io non voglio stare a discutere sull’efficienza di Mono perché non lo conosco a sufficienza; stando a quello che dicono Beagle porta la cpu spesso e volentieri a 100% ma è successo anche a tracker e persino a un altro daemon di indicizzazione (non-desktop search) di cui adesso non ricordo il nome.
Se il punto è che le cpu sono così potenti che possiamo permetterci di sprecare cicli di calcolo per astrarre… non so fino a quando posso essere d’accordo.
Un amico ieri, entusiasta di dotnet, scherzava anche lui sul fatto che il prossimo passo è Application.Videogame() che “crea da solo un gioco in treddì complicatissimo” :D
Pensieri sciolti… :)
ciao
Allora, non per attirarmi gli strali ed epiteti vari, ma un linguaggio “abbastanza libero”… non è libero.
Java ora è Open Source, ma ha grossi problemi: applet scritte per una versione della virtual machine a volte non funzionano con le altre (precedenti e successive)…
Ed i problemi con le “Microsoft Patents” derivano (anche) da Mono.
Io personalmente preferisco non installare applicazioni scritte in Mono (nella stessa maniera con cui evitavo il più possibile Java) e tenermi una distribuzione più FOSS possibile, ma questo è un mio modo personale di concepire il mio PC.
E anche la storia del brevetto su FAT mi preoccupa…
@Artemis
propio perche mono, non da tutte le features disponibili in windos andrebbe evitato, in altre parole se sviluppi in mono, con ambienti microsoft puoi fare delle cose che non puoi fare in linux, quindi prima o poi forkerai il progetto per andare in windos.
ci sono molti linguaggi comodi dal python al php … fino ad arrivare ad haskell …
la mia opinione é che mono e il visual basic andrebbero sempre evitati.
il brevetto sulla fat é un problema, ma é un fs penoso, che al piu dovrebbe essere tenuto per compatibilitá con i pendrive e le fotocamere (fino a quando non troveranno uno standard migliore)… non per leggere gli hd, visto che ci sono applicazioni windows che permettono di montare ext2…
Non vedo perchè qualcuno dovrebbe forkare per andare in windows, un progetto. Il sistema operativo è un target, non una conseguenza del linguaggio di programmazione che usi.
Beagle è andato in windows? Tomboy? Banshee? Non mi risulta.
Mono è un linguaggio comodo e dalle discrete performance, che permette di programmare bene concentrandosi sugli aspetti funzionali dell’applicativo.
Non fa tutto quello che fa .NET in Windows e non lo fa spesso come lui, quindi non vedo il problema delle Microsoft Patents, o almeno non lo vedo in modo pesante.
E’ come se si rompesse le scatole a Gambas, che reimplementa uno ambiente visual basic.
Al contrario Mono è imho un bel progetto per Linux. Qualsiasi programmatore fosse abituato a scrivere in C#, o più semplicemente in Visual Basic, potrà scrivere applicazioni per Linux senza doversi totalmente reinventare inparando il Python o il Perl, o trovandosi costretti a scrivere in C, che è una cosa che sinceramente ogni tanto fa anche girare le palle.
Inoltre definire Python un linguaggio comodo è un po’ un parolone, imho.
Quanto alla fat, il problema più grosso è il fatto che microsoft si potrebbe rivalere sul driver fat del kernel. Sarà penoso quanto vuoi, e sono pienamente d’accordo, ma è anche estremamente diffuso, e questo le da un grande potere.
@Artemis
hai visto la puntata dei simpson, in cui la societá di informatica di homer viene acuisita, e gli viene portato via tutto e gli spezzano le penne?
ognuno puo fare quello che vuole …
forse non mi sono spiegato bene, io parlavo di opportunitá mica volevo imporre qualcosa a qualcuno.
esprimevo la mia, se dovessi programmare in mono, preferirei .net, perche .net é piu comodo. non mi pare l’ambiente di sviluppo adatto sotto linux (anche solo perche non lo trovi su tutte le macchine).
il c non ti piace (a me si), ma sono d’accordo con te che non é oppportuno per sviluppare rapidamente una applicazione (se deve svolgere compiti onerosi é quasi una scelta obbligata cmq).
il perl é comodo, per cose di scripting é ottimo anche il php o ruby…
il python cmq é un linguaggio di programmazione … si compila anche se ti piacciono gli eseguibili … non vedo il motivo di questo astio (la sintassi non é c-like ma questo ha i suoi vantaggi)
@bruno: Se sembra che non mi piaccia il C, chiarisco l’equivoco. A me piace il C, ho imparato a programmare con quello e ci sono affezionato.
Però è un linguaggio nato per programmare sistemi operativi, e si vede. E’ assurdo, per un programmatore che deve realizzare un applicativo grafico, dover gestire cose come i puntatori, non ha senso.
Non ho nemmeno astio per il Python. Semplicemente, se stiamo parlando del fatto che il C non è adatto ad applicativi complessi, non vedo il motivo per cui il python debba essere considerato molto meglio.
Quanto a .net, mi viene in mente un esempio pratico: hai presente che il gruppo PSA (Peugeot-Citroen) ha passato migliaia di workstation da Windows a Linux grazie ad un accordo con Novell?
Ecco, devi sapere che PSA, come del resto Fiat, utilizzano un software per il controllo parallelo dello stato dei progetti che è qualcosa di mostruoso, ha almeno 4 moduli diversi di cui uno server, ed è estremamente complesso. Ecco, è realizzato in .NET.
Mi è giunta notizia certa (da ex-autoveicolista ho i miei agganci) che Novell, in collaborazione con l’azienda che ha realizzato tale software, l’applicativo da .NET a Mono bindato GTK, facendolo girare su Linux.
Tra l’altro con costi minimi. Lo sviluppo di un applicativo del genere da capo, sarebbe costato anni e diversi MILIONI di euro.
Ed ovviamente PSA difficilmente avrebbe passato tutte quelle workstation a Linux, se non fosse stato possibile portare tale applicativo con relativa semplicità e con un costo contenuto.
Anche Zucchetti, noto produttore di programmi gestionali, sta facendo ampio uso di .NET/Mono per offrire infrastruttre multipiattaforma che fossero disponibili per ambienti misti.
Possiamo stare qui a farci le seghe sul fatto che Mono sia più o meno libero e più o meno pericoloso da usare, ma è senza dubbio un grande business per Linux, soprattutto in ambito aziendale.
Un software fatto in Visual C++ è facilmente portatile in VisualStudio .NET, e da li è facilmente portatile in Mono.
Diversamente, per passare da Visual C++ a C++ in linux sarebbe stato necessario riscriverlo quasi completamente.
@Artemis
il python é un linguaggio di alto livello, e anche abbastanza comodo non capisco perché lo assimili al C
so d’accordo con te che mono é ottimo per portare sw gia scitto in linux.
negli esempi che hai fatto ci sono applicazioni windows, che hanno windows come piattaforma principale ma vogliono garantirsi la compatibilitá in linux.
il mio dubbio é iniziando un progetto da 0 in linux, perché usare mono?
@bruno: Si è vero il python è un linguaggio di alto livello, ma non è certo a livello di Java o di C#, nella facilità di realizzare applicazioni grafiche
Per quanto riguarda Mono, non ho mai detto che sia il migliore linguaggio qui e la, semplicemente dico per per Linux è una notevole opportunità business, ed esempi come quelli che ho portato lo dimostrano.
Software specifii per Windows possono essere portati su .NET in modo relativamente semplice, e da li su Mono, il che è un bel vantaggio :)
Perchè iniziare su Linux un progetto con Mono? Onestamente non saprei. Probabilmente perchè è comodo (questione di gusti comunque), o probabilmente perchè il programmatore che inizia il progetto su Linux ha esperienza su ambienti Windows.
Del resto software come Tomboy o Banshee sono programmi molto belli, pur essendo scritti in modo.
Exaile è fatto in python, Amarok in C++, ma alla fine sono venuti tutti fuori bei programmi :)
infatti!
e’ qua che si doveva arrivare… non e’ il linguaggio a fare il programma :D
mi piacerebbe sapere da chi dice che il design di tracker sia migliore di quello di beagle se può indicarmi dove, come e perché. io non conosco bene beagle, ma da quello che ho visto *dentro* tracker, non posso pensare neppure per un momento che ci sia stato un design alla base – a meno di non parlare di design per accrescimento.
quindi, se pensate che tracker sia migliore di beagle solo perché tracker è scritto in C siete liberissimi di farlo; io stesso ci campo, con il C. ma mi spiace: essere scritti in C non da automaticamente un design migliore.
Loro se la cantano e ce le cantiamo anche noi!
@Artemis!
Beh, mi aspetto da un giorno all’altro un bel cobol.NET così finalmente anche la mia banca potrà fare il porting dei suoi gestionali!
mi sa che passerò a beagle (nonostante io odi mono) xkè tracker non mi indicizza alcuni file, è veramente incredibile, tracker mi indicizza tutti i file in una cartella tranne due o tre che, ironia della sorte, sono quelli più importanti della cartella.
Beagle invece indicizza perfettamente tutti i file e la rcerca è molto più efficiente, occupera più risorse, sarà scritto in mono ma almeno funziona correttamente.