
In questi ultimi giorni si sta parlando parecchio di Ubuntu, sopratutto ad appena 48 ore dalla chiusura del bi-annuale Ubuntu Developer Summit. Una delle notizie più calde tra le numerose sfornate è sicuramente il ritorno di Rhythmbox su Ubuntu 12.04 ai danni di Banshee.
La notizia, che ha creato vere e proprie liti sul web è davvero interessante e può essere utile a definire i pro e contro di questi due prodotti, mai come ora al centro dell’attenzione di una intera blogosfera. Le motivazioni che alimentano questa interessante discussioni sono molteplici: dal non supporto alle GTK+ 3 agli aggiornamenti poco frequenti, passando per le varie preferenze personali.
Quindi ho deciso di porre a voi lettori questo quesito tra Banshee e Rhytmbox quale preferite come riproduttore musicale? Mi farebbe piacere oltre che a ricevere una risposta nel sondaggio, conoscere le motivazioni per creare una (pacifica e civile) discussione al riguardo.
medeoTL
07 nov 2011 - 13:12 - #1Io adoro Rhythcoso (nome a parte), ha tutto quello che mi serve, solo che… cavolo, non c’e’ mai una volta che i plugin per le cover e per i testi funzionino! e se funzionano tempo 5 secondi si sono già “rotti”. E’ una cosa che mi manda in bestia e infatti sto cercando di sostituirlo (no, non con banshee, che ritengo pesante e troppo ricco per le mie modeste esigenze)
MedeoTL
roberto77ooo
07 nov 2011 - 13:28 - #2Rhythmbox, perchè presenta un’integrazione migliore con gnome3. Inoltre rispecchia la filosofia di gnome, la facilità di utilizzo (non che banshee sia difficile eh..) l’interfaccia minimale, l’estrema funzionalità che lo contraddistingue e l’imparagonabile scansione della cartella per nuove canzoni.
Tuttavia c’è un lettore che non è esteticamente gradevole - almeno personalmente parlando - ma che ha una funzionalità superba di cui è difficile farne a meno: Guayadeque e la sua smart playlist.. provare per credere, è semplicemente incredibile!
Gr3yFox
07 nov 2011 - 13:33 - #3Rythmbox, non è scritto con Mono… :D
23
07 nov 2011 - 13:39 - #4Totem per sempre. Se devi ascoltare solo qualche mp3 o vedere qualche filmate, va più che bene. Semplice e pulito
lollox85
07 nov 2011 - 14:36 - #5Leggere Totem come valida alternativa per i player mi fa davvero rabbrividire… ma davvero
da parte mia tra i due scelgo decisamente Banshee (che almeno somiglia ad un buon player e guardando in prospettiva migliorerà sempre di più), ma personalmente mi affido invece a Clementine che, almeno finora, straccia ancora la concorrenza
rsiff
07 nov 2011 - 15:12 - #6Rhythmbox sicuramente.
StéphaneB
07 nov 2011 - 15:18 - #7Nessuno dei due: sono molto affezionato a Clementine, nonostante io preferisca le Gtk installo anche Qt solo per questo player.
Tra i due, Rhythmbox per il solo fatto che non dipende da Mono…
warpmaster
07 nov 2011 - 16:18 - #8Clementine.Period.
IvanP
07 nov 2011 - 19:04 - #9Rhythmbox tutta la vita! Prima di tutto perché non è scritto in Mono, e di conseguenza più snello, integrato e performante di Banshee (e perché Mono = evil). In secondo luogo, perché amo il layout di Rhythmbox. I plugin che uso sono pochi e funzionano (quello dei testi non lo uso mai, btw), e questo mi basta.
P.S. Sul laptop dove ho installato 10.11 Banshee freeza senza nemmeno riprodurre una nota, sempre!
abral
07 nov 2011 - 20:14 - #10Mono = Evil mi sembra un pò un’esagerazione XD
Comunque io preferisco Banshee perché ha un’interfaccia grafica migliore.
Ricordatevi che non è il linguaggio a fare la velocità di un’applicazione, ma il suo programmatore!
masterro
08 nov 2011 - 13:45 - #11Clementine
;)
ekerazha
08 nov 2011 - 14:07 - #12Mono non è un linguaggio di programmazione, al massimo può essere scritto in C#. Stranamente, le opinioni di chi dimostra una competenza tecnica che rasenta lo zero pendono tutte da una parte.
floriano0
08 nov 2011 - 20:23 - #13mono implica la virtual machine e quindi la seccatura di ram aumentata, prestazioni minori e tempi d’avvio più lunghi…
abral
08 nov 2011 - 21:08 - #14@floriano0: come non mi stancherò mai di ripetere, la velocità di un’applicazione non dipende dal linguaggio usato (o dall’implementazione dello stesso) ma principalmente dalle capacità del suo programmatore.
Comunque ci sono molti casi in cui perfino il C risulta più lento di Python (PyPy), perché un linguaggio compilato a run-time possiede molte più informazioni per poter effettuare ottimizzazioni migliori (perché capisce come si comporta il programma).
boston
08 nov 2011 - 23:20 - #15Io uso Audacious…..leggero, integra LAST.fm, il plugin per la mia tastiera (logitech g15) e ha pochi fronzoli, a differenza di banshee o rythmbox
floriano0
09 nov 2011 - 01:02 - #16@abral
il programmatore non può fare i miracoli, basta vedere le prestazioni di angrybirds sia in versione html5 che per pc..
floriano0
09 nov 2011 - 01:06 - #17è la stessa teoria dei suv:
se vanno lenti ci mettono dei motori più potenti per farli andare (come velocità e accelerazione) alla pari delle autovetture sportive, quegli stessi motori su macchine “meglio pensate” le farebbero volare…
smilzoboboz
09 nov 2011 - 11:28 - #18strano che nessuno l’abbia menzionato… Io sono un maniaco dei tag (e un programmatore), ho trovato Quodlibet e me ne sono innamorato: mostra i tag che vuoi tu (tutti quelli che vuoi, senza limiti), incorpora uno dei migliori sistemi per ottenere/scrivere metadati sui file musicali (exfalso) e permette le ricerche REGEX sulla libreria…
abral
09 nov 2011 - 15:53 - #19@floriano0
Ti ripeto che in molti casi si possono effettuare migliori ottimizzazioni sul codice compilato run-time rispetto a quello compilato staticamente. Ad esempio sapere se un dato sistema ha determinate istruzioni. Se lo compili staticamente per una grande famiglia di processori, non puoi utilizzare alcune istruzioni. Invece a run-time sai precisamente qual è il processore e puoi effettuare queste ottimizzazioni. Ma soprattutto puoi conoscere come si comporta il programma e ottimizzare le parti più usate, cose che un compilatore statico può fare soltanto fino a un certo punto.
Esempi (con spiegazione dei risultati):
http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html
http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html