Acabo de lanzar una revisión de urgencia de Cronopete; se trata de la versión 1.3.0. Esta corrige un fallo que quedó bastante escondido: si intentamos usar un disco externo formateado en NTFS, Cronopete falla al detectarlo y se cierra. Esta nueva versión funciona correctamente, y muestra el cuadro de diálogo que permite formatear la unidad en ReiserFS o Ext4.
Como de costumbre, está disponible en la sección de programas de mi página web.
A disfrutarla.
Acabo de lanzar la versión 1.2.0 de Cronopete. Los cambios son pequeñitos; de hecho, sólo hay uno importante: ahora, en los backups, las carpetas conservan su fecha de modificación (los archivos ya lo conservaban).
No es un cambio radical, ni una supercorrección, pero sí será interesante de cara a la versión 2.0.0, que incorporará la interfaz de recuperación de archivos. En ese caso, será más cómodo para el usuario si las carpetas también conservan las fechas correctas.
Como de costumbre, está disponible en la página de Cronopete.
Acabo de lanzar una nueva versión de Cronopete con algunos cambios menores. El principal es que ahora permite cambiar cada cuanto se hace una copia. Por defecto sigue en una hora (que es lo recomendable), pero se puede subir hasta doce horas. Otros cambios son, por ejemplo, que ahora el menú aparece debajo de la barra del panel de Gnome (como debe ser), y no encima; además, corrige una pequeña deriva de cinco minutos en el instante en que debería hacer la copia (por su culpa, en la versión 1.0 las copias se hacían cada 65 minutos).
Como de costumbre, se puede bajar en la página de cronopete.
Hace unos años, Apple presentó Time Machine, un programa de copia de seguridad que, por fin, hacía no sólo sencillo, sino también divertido, hacer backups regulares de tus datos.
Pronto surgieron varios clones para Linux, tales como Flyback, Time Vault, o el cómodo Dejá Dup, pero ninguno me convencía, así que decidí hacer yo uno propio. Y ya puestos, decidí hacerlo lo más parecido posible al Time Machine original.
El resultado es Cronopete, un clon de Time Machine para Linux. El nombre lo tomé de El anacronópete, una novela de viajes en el tiempo escrita por Enrique Gaspar y Rimbaud ocho años antes de la célebre La máquina del tiempo, de H.G. Wells.
Al igual que el programa original, Cronopete hace una copia completa del disco cada hora, y conserva todas las copias que pueda para poder volver atrás si es necesario y recuperar un documento en cualquier momento de su historia.
Cada copia del árbol de directorios se conserva en una carpeta propia, cuyo nombre es la fecha y hora en que se realizó. También, al igual que el original, copia realmente sólo los archivos que han cambiado, y se limita a hacer un enlace a la copia anterior para aquellos archivos que no han cambiado, lo que permite acelerar el proceso y consumir muchísimo menos disco.
También para ahorrar espacio, las copias se guardan en una progresión exponencial: para las últimas 24 horas se guarda una por cada hora; para el último mes, una copia diaria; y después, una copia semanal hasta que se llena el disco.
También he copiado al milímetro la interfaz. Al lanzar Cronopete, éste aparece de esta manera en la barra de notificaciones, exactamente igual que Time Machine:
Y esta es la interfaz principal:
Todavía no tiene la interfaz para restaurar los ficheros de manera «bonita», por lo que para hacerlo hay que ir al disco externo y copiarlos «a mano», aunque dado que los archivos están guardados «tal cual», sin ningún tipo de empaquetado ni compresión, esto no supone ninguna dificultad. Sin embargo, ya estoy investigando la biblioteca clutter para implementarla también.
Las primeras pruebas de Cronopete las había escrito en C, con la intención de usar Python para la interfaz, pero no lo acababa de ver porque necesitaba mucha fiabilidad para un programa de este tipo, así que al final decidí probar Vala. Y, como comenté en su momento, me enamoré: la gestión automática de memoria como en Python es una delicia, y encima tengo el rendimiento y el bajo consumo de recursos de C, además de azúcar sintáctico como para abastecer una pastelería durante un año.
Enlace directo a la página de descargas: Cronopete.
Hace hoy justo un año que lancé la última versión de Devede, así que he decidido que ya era hora de sacar una revisión con los cambios que hice en estos meses. No han sido muchos, pero sí muy necesarios, a la vista de las peticiones en la lista de correos. Además, llevaban una temporada esperando en el repositorio GIT de Devede, así que ya tocaba.
Los cambios, básicamente, se resumen en:
Además, se ha creado una ventana de configuración (en Editar -> Configuracion) con parámetros más o menos «fijos», como donde meter los ficheros temporales y demás. De esta forma está todo más organizado.
Ahora, mi objetivo más inmediato es reemplazar Mencoder por FFmeg, para evitar de una vez por todas los cada vez mayores problemas que da este software.
Acabo de lanzar un nuevo programa, llamado, en un alarde de originalidad, EasyWall. Como su propio nombre indica, se trata de un firewall que intenta ser lo más sencillo de usar posible. Para ello trae «de fábrica» varias plantillas para multitud de programas, con sus puertos predefinidos. La idea es que si instalas un programa (el aMule, por ejemplo), sólo tienes que ir a EasyWall y activar la casilla «aMule»; y listo.
Por supuesto, si simplemente fuese ésto no sería muy útil, porque muchos programas permiten cambiar sus puertos, además de que si mostramos todos los programas posibles, sería una lista interminable. Por eso, EasyWall incorpora una serie de capacidades extra:
Las plantillas se definen con sencillos ficheros XML, por lo que es muy fácil añadir nuevos programas. Además, aunque el programa en en modo gráfico, incluye un par de funcionalidades en modo texto para permitir refrescar el firewall si se añaden o eliminan programas al sistema.
Por último, la funcionalidad se ha dividido en dos ficheros: easywall_core.py y easywall_gtk.py. El primero tiene toda la parte de bajo nivel, y el segundo es el front-end en GTK. Esta división se ha hecho así con vistas a que quien lo desee, pueda hacer fácilmente un front-end en Qt para KDE. Para ello sólo tiene que incluir el módulo easywall_core.py y utilizar sus clases y métodos para refrescar el firewall, añadir puertos, etc.
¡A disfrutarlo!
La nueva versión de FBZX ya está en la calle con dos opciones pedidas por un usuario. Para empezar, ahora se pueden meter POKEs, lo que nos dará esas maravillosas vidas infinitas que tanto necesitamos. Por otro lado, ahora podemos emular una televisión en blanco y negro, para los nostálgicos pobretones que no nos podíamos permitir una tele en color para el speecy. Por último, y de rebote, le añadí soporte para cargar y hacer snapshots de la pantalla en formato SCR.
¿Y qué es TTOS? Pues el proyecto en el que llevo embarcado desde hace siete meses. Se trata de un gestor de ventanas por composición para el navegador TomTom, que permite dotarlo de una serie de capacidades al estilo de Android o del iPhone.
La idea surgió el verano pasado, cuando, volviendo de vacaciones, tuve que hacer casi todo el viaje de vuelta en silencio porque me había olvidado los CDs de música, en la radio sólo se pillaba Radio Clásica y Radio María (nada que ver con la hierba), y casi no tenía batería en el móvil para reproducir mis MP3 desde él. Fue entonces cuando recordé que tenía un viejo TomTom que no utilizaba para casi nada, y dado que éste tiene un Linux embebido, se me ocurrió que podría hacer un pequeño reproductor de MP3 para él. Pero ya existía: TomPlayer.
Entonces me dije ¿por qué no intentar mejorarlo? Y entonces empecé a investigar sobre Android, pero era demasiado pesado para él. Así que decidí intentar hacer una versión ligera, con lo mínimo para poder hacer los efectos de scroll y demás que se ven en los móviles de hoy en día.
El resultado es TTOS, un pequeño entorno que permite desarrollar y ejecutar pequeñas aplicaciones sobre TomTom. El API es muy sencillo, y permite hacer mucho con pocas líneas.
En estos momentos TTOS trae una calculadora, un reloj calendario, un terminal, una aplicación de ejemplo y un reproductor de MP3/Vorbis, pero, cuando tenga algo más de tiempo, me estoy planteando portar Navit, un navegador libre que utiliza los mapas de OpenStreetMap.
Como muestra, una pequeña animación que muestra como es TTOS:
Acabo de lanzar la versión 8.0 de FPT_BT4LXMedia. La primera novedad es la nueva versión de Transmission, la 2.21. La segunda es que, por fin, los ejecutables utilizan enlazado dinámico.
Como recordareis, las versiones anteriores utilizaban enlazado estático porque no conseguía que arrancasen desde el disco, a pesar de utilizar LD_LIBRARY_PATH para apuntar al directorio con las nuevas bibliotecas. Para los que no sepan qué es eso, es una variable de entorno que permite añadir nuevas rutas en donde buscar bibliotecas de enlace dinámico, y éstas tienen prioridad sobre las «normales» del sistema. Así, si tengo un programa enlazado con una versión concreta de libc, diferente de la del sistema, puedo instalarla en otro directorio (por ejemplo, /tmp/libs) y lanzar el programa con:
LD_LIBRARY_PATH=/tmp/libs mi_programa
Por desgracia, esto no funcionaba en mi disco duro. Tras investigar mucho, descubrí que el problema estaba en el enlazador dinámico en tiempo de arranque. Resulta que el núcleo sólo es capaz de arrancar, por sí solo, binarios que estén enlazados estáticamente. Para los dinámicos lo que hace es delegar en /lib/ld-linux.so (o /lib/ld-uclibc en la biblioteca uClib). A pesar de llevar extensión .so, este fichero es realmente un programa (enlazado estáticamente, claro) diseñado para cargar en memoria el programa dinámico deseado, analizar qué bibliotecas necesita, cargarlas en memoria si aún no están, realizar toda la operación de enlazado y, finalmente, lanzar el código.
Por desgracia, la versión del enlazador dinámico de la gentoo que utilizo para desarrollar es más reciente que la de mi disco duro, lo que hacía que recibiese un error cada vez que intentaba ejecutar un programa compilado directamente. Para complicar aún más las cosas, la ruta del enlazador dinámico está especificada en cada ejecutable de manera inamovible, estableciéndose dicho valor durante la compilación. Y por si fuera poco, el enlazador de Busybox no permite su ejecución directa, por lo que tampoco podía hacer un simple /lib/ld-uclibc mi_programa.
Ante todo esto, la única solución que me quedó fue la de copiar el enlazador dinámico del entorno de desarrollo en una carpeta diferente y, al compilar bftpd, transmission y ctransmission, especificar la ruta deseada. Esto se hace en la etapa final de enlazado mediante la opción -Wl,–dynamic-linker=path/al/enlazador. De esta manera bastó con copiar el enlazador y el resto de bibliotecas a /tmp/hdd/root/libs y lanzar los programas con
LD_LIBRARY_PATH=/tmp/hdd/root/libs mi_programa
Con esto espero ahorrar algo de memoria. También haré algunas pruebas para ver si los programas funcionan bien con la versión de la uClib del propio disco duro, en cuyo caso podría ahorrar aún más.
Estos meses estoy trabajando como loco, así que poco tiempo he tenido para corregir cosas. Tengo una cola de mejoras pendientes para Devede que crece día a día, pero hasta que tenga lista la primera versión del nuevo proyecto no me quiero poner con otra cosa.
Pese a todo, he sacado un poco de tiempo para corregir un pequeño bug en el sistema de sonido de FBZX: al utilizar ALSA no definía el tamaño del buffer, sino que asumía que el asignado por defecto era adecuado. Hace unos años funcionaba porque ese valor era de unos 4Kbytes, pero algo han hecho (al menos en Ubuntu) y lo han aumentado mucho, por lo que el emulador iba a trompicones (utiliza el sistema de sonido para ajustar la velocidad). Con OSS o PulseAudio funciona bien, por eso el error pasó desapercibido. La nueva versión 2.4.2 lo corrige.