Archive for marzo, 2010

Bftpd 2.7 para el LX Multimedia

domingo, marzo 28th, 2010

Nueva versión del paquete ftp_bt4lxmedia, esta vez la 4.2, con la versión 2.7 de BFTPd. Las versiones anteriores enviaban un mensaje de error incorrecto al intentar borrar una carpeta con el comando de borrar archivos, lo que confundía al cliente FTP de Nautilus (el escritorio de Gnome) e impedía, por tanto, borrar carpetas desde él. La nueva versión ya permite borrarlas casi sin problemas.

Y digo casi porque, haciendo pruebas, surgió otro problema, y es que el comando ls -la no devuelve los ficheros ocultos, lo que hace que, si en una carpeta hay alguno, de un error al intentar borrarla. Voy a echar un vistazo al código a ver si puedo enviar al autor otro parche que corrija este detalle.

El paquete se puede encontrar en mi web, en un nuevo apartado que hice en la sección Programas.

Transmission 1.92

lunes, marzo 22nd, 2010

Acabo de lanzar una revisión del paquete de mejoras para el disco duro multimedia MemUp LX media. El cambio es la actualización del cliente BitTorrent Transmission a la versión 1.92.

AVISO: a partir de aquí empiezo a tocar en el sistema operativo del disco duro multimedia, lo que significa que estas acciones sólo las deben realizar aquellos que sepan muy bien lo que hacen. Si alguien se carga su disco, será el único responsable.

Avisados estáis.

La instalación es igual que en versiones anteriores: basta con bajarse el fichero ftp_bt4lxmedia_4.1.tar.bz2 y actualizar los ficheros indicados.

Al igual que en versiones anteriores, los binarios contenidos en este paquete están enlazados estáticamente, por lo que funcionarán en cualquier sistema con procesador MIPSel.

Si ya habías instalado una versión igual o anterior a la 3.0 de ftp_bt4lxmedia, debes borrar el fichero /tmp/hdd/volumes/HDD1/BT/transmission_tmp/settings.json o editarlo para modificar el parámetro rpc-whitelist.

Como ya avisé en un mensaje anterior, aquellos que se decidan a probarlo deben limitar el cliente BitTorrent (sea el que sea) a no más de 300 o 400 KBytes/seg de bajada, porque si se recibe a más velocidad, el disco multimedia se satura y acaba colgándose.

Entradas anteriores:

Nos la meten doblada

domingo, marzo 21st, 2010

Aprovechando el puente (como ya viene siendo habitual), el Gobierno ha aprobado sin cambios la Ley de Economía Sostenible, que incluye la infame “Ley Sinde” de cierre de páginas web. Ahora dicha ley pasará al Congreso, donde se deberían presentar enmiendas y se votaría. Recordemos que el PSOE, de quien surge la ley, tiene mayoría relativa con 169 escaños. Si se aprueba (por mayoría absoluta), pasaría al Senado, donde se propondrían nuevas enmiendas y se votaría de nuevo. Para ser aprobada necesitaría también mayoría absoluta. En estos momentos, en el Senado tiene mayoría relativa el PP, aunque hay gente que sospecha que no están por la labor de oponerse a esto.

Devede 3.16.6

viernes, marzo 19th, 2010

Una nueva revisión con leves cambios. No corrige fallos graves, sino pequeños bug publicados en el bugzilla de Ubuntu, en concreto los bugs 371229 (la descripción del menú del lanzador no sigue las normas de Gnome), 371369 (la entrada de menú del lanzador no está traducida a italiano), 484420 (los botones de debajo de las listas de ficheros y de títulos no mantienen la misma apariencia que el resto de botones) y 496740 (al pulsar ENTER en las propiedades de un título, debería actuar igual que al pulsar el botón Aceptar; lo he extendido al diálogo de comenzar la conversión).

FBZX para 32 y 64 bits

lunes, marzo 15th, 2010

Lo prometido es deuda, por eso acabo de subir la versión 2.4.1 de FBZX que corrige un pequeño detalle que podría hacer que en arquitecturas de 64 bits Big-Endian no funcione correctamente. Además, he subido paquetes .DEB tanto para arquitecturas de 32 como de 64 bits, con lo que confío en que en breve esté disponible en Ubuntu64 (a día de hoy no lo está).

Devede 3.16.5

miércoles, marzo 10th, 2010

Dos diminutos cambios: por una parte, ya no renderiza los subtítulos al convertir un MKV, y por otro, las dependencias ya no dan problemas en Debian.

Vuelve DVDAuthor

domingo, marzo 7th, 2010

La herramienta DVDAuthor, que Devede utiliza para generar los DVDs, lleva casi tres años sin mantenimiento. Sin embargo, hoy me llegó un mail de Lawrence D’Oliveiro en la que me comenta que ha iniciado un fork de DVDAuthor, en el que ya ha aplicado varios parches. Aprovechando la coyuntura le he comentado los dos problemas que encontré hasta ahora: Spumux no soporta textos en UTF-16, y no se puede cambiar el color de los subtítulos. Con suerte en la próxima versión de DVDAuthor estos dos detalles están corregidos y Devede puede sacar provecho de ellos.

Transmission 1.91

domingo, marzo 7th, 2010

Acabo de actualizar el cliente de BitTorrent Transmission para mi disco duro multimedia MemUp LX a la versión 1.91.

AVISO: a partir de aquí empiezo a tocar en el sistema operativo del disco duro multimedia, lo que significa que estas acciones sólo las deben realizar aquellos que sepan muy bien lo que hacen. Si alguien se carga su disco, será el único responsable.

Avisados estáis.

Al igual que en versiones anteriores, basta con bajarse el fichero ftp_bt4lxmedia_4.0.tar.bz2 y actualizar los ficheros indicados.

Un detalle importante es que en el fichero de configuración de Transmission he modificado la configuración para que se pueda conectar a la web de configuración desde cualquier equipo con direcciones del rango 192.168.*.*. En versiones anteriores sólo se podía hacer desde direcciones 192.168.1.*, lo que es posible que de problemas a alguna gente.

Si ya habías instalado una versión anterior de ftp_bt4lxmedia, debes borrar el fichero /tmp/hdd/volumes/HDD1/BT/transmission_tmp/settings.json o editarlo para modificar el parámetro rpc-whitelist.

Como ya avisé en un mensaje anterior, aquellos que se decidan a probarlo deben limitar el cliente BitTorrent (sea el que sea) a no más de 300 o 400 KBytes/seg de bajada, porque si se recibe a más velocidad, el disco multimedia se satura y acaba colgándose.

Entradas anteriores:

Migrando a 64 bits

jueves, marzo 4th, 2010

Hace unos días decidí cambiar el sistema operativo a Ubuntu de 64 bits. A fin de cuentas es el futuro, y cualquier día lo necesitaré por cuestiones de memoria, así que mejor ir comenzando ahora. Al principio pensaba que iba a tener problemas con algún programa en concreto, pero la verdad es que hasta ahora todo está funcionando como la seda:

  • MPlayer y Mencoder funcionan perfectamente y reproducen todos los formatos que necesito (entre ellos H.264, DivX, WMV y RealMedia); y ni siquiera he necesitado instalar los plugins privativos para que me funcionen incluso los vídeos en formato WMV9 (que utiliza VC-1).
  • Eclipse funciona perfectamente con la máquina virtual de Java de 64 bits, aunque tuve que borrar la carpeta .eclipse de mi directorio personal y reinstalar los plugins para lenguaje C y Python.
  • Y tampoco tengo problema alguno con Flash de 64 bits, aunque sea aún una prerelease y no una versión estable.

Un detalle que me preocupaba mucho es ¿cuan problemático es portar código C a 64 bits? En general debería funcionar, salvo si el tamaño de algún tipo fundamental cambia a 64 bits y en el código asumimos que es de 32 bits. Y de hecho había algunas posibilidades de que ocurriese, pues hay tres posibles modelos para C en 64 bits: LP64, ILP64 y LLP64. En el primero, que es el que utiliza Linux/GCC o MacOS X, int es de 32 bits, mientras que long int es de 64 bits. En el segundo, en cambio, los dos tipos miden 64 bits. En el último caso, el más compatible (y además utilizado por el compilador VirtualC++ de Microsoft), miden todos 32 bits, siendo long long int la única manera de conseguir un tipo de 64 bits. ¿Cual es mejor? Bajo mi punto de vista, LP64, porque permite fácilmente mantener total compatibilidad hacia atrás si se escribe el código con una pizca de cuidado, además de permitir, con el mismo código, acceder a toda la memoria disponible mediante aritmética de punteros, tanto en 32 como en 64 bits. Para conseguir todo esto, en concreto, hay que asegurarse de utilizar long int para aquellas variables que se utilicen en aritmética de punteros (porque, de esa forma, siempre tendrán el mismo tamaño que un puntero y se podrá direccionar toda la memoria sin problemas), así como para aquellas que no importe si son de 32 o 64 bits, utilizar int para aquellas que tengan que ser forzosamente de 32 bits, o cuando se quiera ahorrar en tamaño, y long long int para aquellas que tengan que ser necesariamente de 64 bits.

Mi miedo venía por FBZX. Sin embargo, tras probarlo, funcionó correctamente… aunque hay que decir que de milagro, porque hay un punto en que sí utilicé un long int en lugar de int a secas: justo en la función que pinta cada pixel, cuando estamos en un modo de 24 o 32 bits por pixel. Pese a todo, gracias a que la arquitectura Intel es little endian, el código funciona (cosa que no haría si fuese big endian). Es un detalle que corregiré en la siguiente versión, para la que sacaré paquete .deb tanto en 32 como en 64 bits.


Utilizamos cookies para garantizar que tenga la mejor experiencia en nuestro sitio web.