Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.
Thursday, June 08, 2006
iFolder: no tan bonito como lo pintan
Bueno, pues llevaba siguiéndole la pista, bastante entusiasmado, al proyecto iFolder de Novell porque parecía una herramienta muy interesante para sincronización de ficheros entre varios equipos (y así tener la última versión de todos tus ficheros replicada y actualizada en cualquier lugar que necesites), y además estaba desarrollada con Mono, y por tanto era multiplataforma.
Hace unos meses, sólo la versión de sincronización modo P2P estaba disponible bajo licencia libre, pero hace poco liberaron completamente el componente de servidor de este programa.
Así que me puse manos a la obra a leer guías, manuales, referencias... E instalé con éxito mi sistema de réplicas. El problema vino cuando empecé a ponerlo a prueba de verdad: con una carpeta home de 3GB.
Empecé a encontrar bugs de rendimiento de interfaz y extraños bugs relativos al uso interno de la base de datos embebida. También me di cuenta de que para estas cantidades tan grandes de datos, la comprobación de cambios era muy lenta (del orden de media hora) y además consumía mucho tiempo de procesador.
Quizás es que aún el software no es demasiado maduro y deben pulirlo. Porque también me llevé un buen susto cuando un día me encontré que me había borrado todos los archivos (dejando sólo los directorios) en uno de los peers, lo que me llevó a pensar que eso había ocurrido por culpa de una sincronización, es decir, que el servidor también se había quedado sin archivos (!!!!!), pero afortunadamente estaba equivocado. Esto me lleva a pensar, también, que aunque con un software de este tipo tengamos replicados los datos en n lugares, sigue necesitándose una solución de backup que haga snapshots cada cierto tiempo (dos semanas, por ejemplo), por lo que pudiera pasar.
El caso es que voy a dejar de usar iFolder de momento y voy a buscar alternativas. rsync parece muy maduro y eficiente, pero no sirve para un escenario en el que puedan propagarse los cambios bidireccionalmente entre más de dos equipos. Así que parece que voy a tener que lidiar con una topología en estrella de la mano de Unison, el cual parece un software también bastante maduro, de propósitos similares a iFolder, y multiplataforma. Aquí hay una guía de la cual estoy dando buena cuenta.
Actualización: Otro proyecto del que hay que estar al loro: Conduit. La pena es que está hecho en Python :(
Actualización 24-AGO-2006: Más malas noticias en la lista de correo de iFolder-devel, junto con otro mensaje en plan "que no cunda el pánico".
Actualización 29-NOV-2006: Parece que por fin están empezando a mover el culo.
Actualización 23-MAR-2009: Después de un aluvión de críticas a Novell y un bug en el que se exige el código fuente de una versión publicada como GPL (pero cuyos parches no han llegado al SVN oficial) al que estamos suscritos bastantes empleados, al parecer por fin se han decidido a mover ficha. ¡Enhorabuena y gracias (a todos mis compañeros que hayan estado envueltos en este tema)!
Hace unos meses, sólo la versión de sincronización modo P2P estaba disponible bajo licencia libre, pero hace poco liberaron completamente el componente de servidor de este programa.
Así que me puse manos a la obra a leer guías, manuales, referencias... E instalé con éxito mi sistema de réplicas. El problema vino cuando empecé a ponerlo a prueba de verdad: con una carpeta home de 3GB.
Empecé a encontrar bugs de rendimiento de interfaz y extraños bugs relativos al uso interno de la base de datos embebida. También me di cuenta de que para estas cantidades tan grandes de datos, la comprobación de cambios era muy lenta (del orden de media hora) y además consumía mucho tiempo de procesador.
Quizás es que aún el software no es demasiado maduro y deben pulirlo. Porque también me llevé un buen susto cuando un día me encontré que me había borrado todos los archivos (dejando sólo los directorios) en uno de los peers, lo que me llevó a pensar que eso había ocurrido por culpa de una sincronización, es decir, que el servidor también se había quedado sin archivos (!!!!!), pero afortunadamente estaba equivocado. Esto me lleva a pensar, también, que aunque con un software de este tipo tengamos replicados los datos en n lugares, sigue necesitándose una solución de backup que haga snapshots cada cierto tiempo (dos semanas, por ejemplo), por lo que pudiera pasar.
El caso es que voy a dejar de usar iFolder de momento y voy a buscar alternativas. rsync parece muy maduro y eficiente, pero no sirve para un escenario en el que puedan propagarse los cambios bidireccionalmente entre más de dos equipos. Así que parece que voy a tener que lidiar con una topología en estrella de la mano de Unison, el cual parece un software también bastante maduro, de propósitos similares a iFolder, y multiplataforma. Aquí hay una guía de la cual estoy dando buena cuenta.
Actualización: Otro proyecto del que hay que estar al loro: Conduit. La pena es que está hecho en Python :(
Actualización 24-AGO-2006: Más malas noticias en la lista de correo de iFolder-devel, junto con otro mensaje en plan "que no cunda el pánico".
Actualización 29-NOV-2006: Parece que por fin están empezando a mover el culo.
Actualización 23-MAR-2009: Después de un aluvión de críticas a Novell y un bug en el que se exige el código fuente de una versión publicada como GPL (pero cuyos parches no han llegado al SVN oficial) al que estamos suscritos bastantes empleados, al parecer por fin se han decidido a mover ficha. ¡Enhorabuena y gracias (a todos mis compañeros que hayan estado envueltos en este tema)!
Labels: General, Mono, SoftwareLibre
# posted by knocte @ 11:08 am 
