Novacut, il nuovo editor non–lineare per i video, aveva scelto di legare il proprio destino a Ubuntu già alla fine di settembre. Qualche settimana più tardi Canonical ha avviato il processo di rimozione dei segnalibri da Ubuntu One: i due progetti hanno in comune esclusivamente CouchDB. Il database sarà rimosso dalla distribuzione.
Fortunatamente, gli sviluppatori di Novacut avevano già previsto la sostituzione di CouchDB con un’alternativa: la scelta dell’ultimo Ubuntu Developer Summit (UDS) è stata provvidenziale nella circostanza. Ubuntu One adotterà U1DB, un nuovo database che rimpiazzerà CouchDB. Novacut partecipa alla transizione e allo sviluppo di U1DB.
Tuttavia, gli sviluppatori di Novacut non considerano U1DB una soluzione ideale per il proprio editor: è preferibile a CouchDB soltanto per il player. Da questo punto di vista, Novacut cercherà di rendere più “duttile” U1DB. Il vantaggio per entrambe le parti è nell’eliminazione di Erlang, richiesto soltanto per CouchDB, da Ubuntu.
La puntualizzazione di Novacut rivela una strategia condivisibile di Canonical: rimuovendo Desktop CouchDB da Ubuntu One, la distribuzione elimina un linguaggio pressoché inutile nell’utilizzo quotidiano degli utenti come Erlang. La scelta di costruire un proprio database è encomiabile perché evita i problemi subentrati di recente.
Personalmente, proprio per questo motivo continuo a non capire il perché della traduzione di Zeitgeist in Vala. Dovendo garantire la portabilità su Mac OS X e Windows, U1DB è scritto in Python: il database potrebbe essere sfruttato con Zeitgeist, che al momento utilizza SQLite — corrotto dal passaggio a Vala per la Full Text Search.
Insomma, Canonical rimuove da una parte per aggiungere dall’altra: nel contesto, Novacut è l’unico progetto ad avvantaggiarsi della rimozione di CouchDB. Ubuntu One ha già rimosso xul-ext-bindwood per la sincronizzazione dei preferiti con Firefox e Zeitgeist continuerà a interagire con un database a sé. Qual è la visione d’insieme?
Via | Novacut
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
james-pond
22 nov 2011 - 13:36 - #1ci credete che non ho capito un’acca di questo articolo? Eppure ci ho provato
barra
22 nov 2011 - 14:22 - #2quoto,
tante idee poco chiare e ben confuse…..
Che c’entrano Zeitgeist e simili? Canonical si fa il suo DB, ad uso esclusivo per i progetti “interni”, quelli di Novacut aiuteranno (visto che comunque hanno sono interessati ad usare ubuntu e nulla più) e quelli di zeitgeist restano su una soluzione più compatibile con il resto del mondo linux.
Quando u1db sarà maturo sarà possibile valutare bindings e simili.
Tieni comunque conto che stiamo parlando di un DB che dovrà interfacciarsi/sincronizzarsi con Ubuntu one, cosa che richiede il passaggio tramite una connessione internet. Le prestazioni saranno sempre e comunque castrate dalla connessione quindi python va più che bene!
Kim Allamandola
22 nov 2011 - 14:33 - #3Il rapporto di Novacut con CouchDB ed Ubuntu mi è ignoto come mi è ignoto U1DB,
per quel che posso dirti CouchDB è stato uno dei primi e apparentemente più
completi DB NoSQL, oggi in “declino”…
Dalla sua ha sopratutto l’accettare “allegati” (file/blob binari) che poi
risiedono direttamente su filesystem senza bisogno di essere codificati in
base64 o similari e di permettere l’accesso ai dati via json.
Se non conosci base64 bé è semplicemente un modo di convertire in testo dei
file binari per poterli maneggiare in sistemi che solo il testo san gestire,
un esempio classico è la posta elettronica, i gruppi di usenet ecc. il brutto
della codifica è che richiede tempo e occupa spazio disco.
Oggi come oggi c’è un *enorme* interesse per una famiglia non proprio ben
definita di tecnologie le cui keyword sono:
* NoSQL
* Serializzazione
* Persistenza
* Accesso veloce/parallelo/caching
Nei “vecchi” sistemi quando maneggi taaanti dati “piccoli” usi un database
a cui accedi tramite un’applicazione che parla il linguaggio SQL. Questo
approccio è stra-rodato ma anche pesante, lontano dal linguaggio con cui
scrivi l’applicazione (usi un altro linguaggio, l’SQL) e sopratutto lontano
dal modo in cui elabori i dati: in un programma hai delle strutture dati
proprie del linguaggio e dell’implementazione che scegli, se usi un DB SQL
classico devi “convertire” tali strutture dati in un’altra forma, inviarli
via SQL e via SQL recuperarli importandoli nuovamente nelle tue strutture
dati.
Le soluzioni che sono già in uso a macchia di leopardo e stanno emergendo
sempre più permettono di “gestire” i dati in maniera più diretta e con
strutture dati familiari/vicine al linguaggio di programmazione che usi.
La serializzazione (vedi ad es. yaml, json, pickle) permette di salvare
strutture dati in una forma molto vicina all’originale, ad esempio ti
permette di “salvare” l’istanza di una classe con tutte le sue variabili
e recuperartela un domani. Yaml è il formato di serializzazione testuale
più comodo e compatto, solo che in un uso normale dati serializzati in
yaml non sono passabili da un linguaggio ad un altro: se salvi una classe
python non puoi leggerla da js o lua o vala; json è un “sottoinsieme” di
yaml che invece pur limitando molto ciò che puoi salvare permette di
essere multilinguaggio, pickle è molto più veloce dei primi due ma è o
binario o “praticamente binario” cosa che rende molto scomodo leggersi i
file a mano…
La persistenza è il concetto di “salvare” qualcosa che hai in ram per un
domani ricaricartela di nuovo, la serializzazione è uno degli step solitamente
necessari per la persistenza.
L’accesso veloce/parallelo ecc è che in molte applicazioni hai bisogno di
tempi di risposta rapidi, pensa solo a google, quante richieste contemporanee
ha… I DB classici, SQL based, sono “lenti” richiedono troppi accessi disco
per ogni risposta, il dover passare da una query per ogni richiesta richiede
tempo, è difficile distribuire il carico di richieste su più macchine ecc.
soluzioni per questo sono ad es. redis (un DB NoSQL molto comodo e leggero)
memcached, membase ecc, questi permettono di salvare dati in ram, di dividere
i dati su varie macchine (e gestirsi loro tale processo) ecc.
I DB NoSQL sono sostanzialmente dei DB che non passando dall’SQL permettono
un accesso più diretto e comodo ai dati, in alcuni casi come redis possono
essere anche usati come cache per questioni di performance.
CouchDB è ottimo per la gestione di file binari ma ha un certo peso, è scritto
in erlang, linguaggio molto scomodo da usare, nato per il calcolo distribuito
ma con scelte come le variabili “read-only” assai fastidiosi. Per questo penso
sia stato scelto per Novacut, avendo poi desktopcouch un client desktop molto
comodo è stato usato anche per varie app tra cui un client di microblogging da
twitter in giù che non ricordo come si chiama, UbuntuOne ecc.
Io punterei su Redis per la sua leggerezza, l’assenza di dipendenze, la
velocità stratosferica, la comodità d’accesso via python o ruby; di negativo
c’è solo una serie di strutture dati ed operazioni sulle stesse non proprio
immediate e la mancanza di una soluzione distribuita completa/stabile (è un
progetto molto giovane ed in pieno sviluppo) vedremo questo U1DB che vuol
fare… Altri DB sono MongoDB, Riak, Cassandra, Tyrant ecc se vuoi un benchmark
un po’ discusso ma significativo: http://is.gd/O0FvYd
barra
22 nov 2011 - 18:43 - #4Grazie per i chiarimenti, preciso come sempre :D
Conoscevo già qualcosa dei db Nosql ma qualche chiarimento in più non fa mai male!
Vedremo che strada sceglierà Canonical con il suo U1db e se riuscirà a farne un suo “progetto upstream”, ultimamente Canonical ha affrontato a più riprese (e in questo Federico ha ragione) problemi legati all’inconsistenza di alcuni progetti opensource: gnome3/GTK3 con i suoi ritardi, casini e mancanza di idee (prima dell’annuncio di unity gnomeshell è rimasta ferma così per mesi: http://www.gnukhole.com/wp-content/uploads/2009/05/gnome-shell2.png ), banshee/mono (gtk3 si, no, forse. il casino u1music store ecc) e ci sarebbero molti altri esempi.
Se, come credo, Canonical inizia ad essere “abbastanza grande” da svilupparsi internamente le cose più importanti avere un DB “suo”, predisposto per fare quello che più le serve ed evolversi per soddisfare le sue esigenze è la scelta IMHO migliore (lo stesso vale per i principali applicativi desktop, attendo con impazienza music e video player, file manager e magari browser e client di posta basati su unity!)
Kim Allamandola
22 nov 2011 - 19:00 - #5@barra #4
figurati :-)
Io sono però meno favorevole almeno nel caso dei DB NoSQL più che altro per
una semplice ragione: ce ne sono già troppi sulla piazza. Redis è una cosa
fantastica per velocità, è il più veloce sia come “DB” che come “cache”, ma
ha il problema che manca ancora un supporto a istanze distribuite completo,
redis-cluster c’è ma è ancora in fase primordiale di sviluppo (per quanto
progredisca in fretta), e che non ha una comoda gestione della memoria
virtuale. Perché non aiutare lui? Ad esempio aggiungendo un modulo a parte
per la gestione dei file su filesystem come ha couchdb? (la chiave è in ram
normalmente, il valore punta ad un file che passa come una normale open in
locale o via webdav/nfs/* se da remoto magari basandosi su Twisted).
È giusto scrivere la cosa che ti serve esattamente come la vuoi ma se siamo
in un settore “giovane” dove non vi sono ancora soluzioni consolidate ma
ancora n concorrenti che sgomitano per affermarsi dare una mano aggiungendo
ciò che si vuole al più adatto/promettente di questi non sarebbe IMVHO una
cattiva idea…
Circa Unity, bé per ora il grosso del lavoro direi che sia su Unity stessa,
ad ogni modo qualche piccolissima cosa spunta, ad es. hanno iniziato a
scrivere una “calcolatrice” nel search della dash, se al posto di un nome
di applicazione scrivi un’espressione matematica semplice te la risolve un
po’ come Google http://is.gd/8aYJ6N è ben poca cosa ma è pur sempre un piccolo
inizio :-) aspetto la conversione delle valute via Google (es: 10 USD in EUR)
dove scrivi l’ammontare da convertire, il codice iso della valuta maiuscolo,
in minuscolo ed hai il cambio corrente e qualche altra chicca!
barra
22 nov 2011 - 21:11 - #6Ho provato ieri la calcolatrice ed è IMHO l’esempio perfetto di cosa potrebbe (e dovrebbe) diventare unity…..
X U1DB leggendo qui https://lists.launchpad.net/u1db-discuss/msg00037.html si parla più di API che di database:
on the one hand, we’re not writing a database; we’re writing an API
anybody can implement ontop of existing databases to make them
syncable. On the other hand, the hard part is the sync protocol, not the
store itself :)
romfladef
02 dic 2011 - 08:37 - #7Il discorso, per quanto mi riguarda, ha molto senso. Il problema subentra quando non si è capaci d’avere una visione d’insieme: CouchDB serviva a Canonical per un solo progetto… ovvero Ubuntu One. U1DB sarà utilizzato al suo posto e probabilmente subentrerà a SQLite su Zeitgeist, perché traducendo quest’ultimo in Vala hanno corrotto la Full Text Search (FTS) che funzionava benissimo con Python. Per fortuna, Apache sostiene la mia stessa tesi…
barra
02 dic 2011 - 11:28 - #8Federico stai scrivendo castronerie….
https://live.gnome.org/Vala/SqliteSample
un DB è QUASI SEMPRE scritto con un linguaggio differente da quello usato per l’applicativo (guarda ad esempio CMS e applicativi WEB).
X ZT la situazione è chiara e descritta qui: http://seilo.geekyogre.com/2011/11/zeitgeist-from-python-to-vala/:
The only thing not ported yet is the FTS extension but we managed to make it a stand-alone process that reads from the DB directly. We will have a nice awesome port soon so don’t worry. We are also working on an alternative extension with the Tracker guys for the FTS.
romfladef
02 dic 2011 - 11:45 - #9È esattamente quanto ho detto anch’io, soltanto che tu la vedi in positivo: io non sono affatto soddisfatto delle prestazioni di Ubuntu, ecc. e non ritengo che scrivere U1DB in Python quando Zeitgeist è in Vala sia un’idea geniale. Lo sarebbe stato se avessero mantenuto Zeitgeist in Python. Non è un problema di linguaggi diversi per database e applicazioni: Vala ha dei binding per C, come Python. Quindi sono già due linguaggi al prezzo di uno e per come la vedo è un’inutile aggiunta. Non ho mai detto che non esista la possibilità di usare la FTS con Vala: ho riportato quanto è stato affermato dagli sviluppatori di Zeitgeist, ovvero che non l’hanno tradotta in Vala perché nel processo di traduzione risultava corrotta (non c’è soltanto Seift Lotfy a parlare della questione). E non significa neppure che non potranno sistemarla: mi sono riferito alla release disponibile, in cui lo stato dell’arte è esattamente quello che ho descritto e tra i vari problemi ha l’incompatibilità con versioni inferiori all’ultima stabile di Ubuntu. Peraltro, controllando il materiale dell’ultimo articolo, mi sono accorto che U1DB (inteso come le API, senza la mia “interpretazione” sul database derivato da CouchDB) si collega proprio a SQLite. Quindi Vala e Zeitgeist non c’entrano? Ho dei dubbi, perché non penso riscriveranno Ubuntu One per SQLite dopo averlo creato per un database NoSQL. Come vogliano chiamare quel database, riguardo alla polemica sul fatto che U1DB non è un database, lo ignoro: l’unico a dargli un nome è lo sviluppatore di Novacut e afferma lui stesso che la scelta non ricadrà sul suo. Insomma, è lecito avere una propria opinione e che questa sia diversa dalla mia. Ma se s’interpreta a proprio uso e consumo ciò che scrivo è un altro discorso.
vad
12 dic 2011 - 20:37 - #10ennesima reinvenzione della ruota