miércoles, 29 de febrero de 2012

Software libre: R

Hoy he completado un artículo cuya estadística se ha realizado completamente en R. Esto me acerca más a un uso completo de software libre, ya que me libera de la necesidad de usar SPSS, que en mi caso suponía una máquina virtual de Windows. Solo me quedan dos barreras; un escáner incompatible -por ahora- a sane y la firma digital de las actas de las materias en las que soy profesor. La primera es sencilla -sustituirlo por otro, como hice con la impresora- y la segunda avanza (ver aquí, aquí y este último). Ahora solo queda que el artículo pase los referees correspondientes y se publique, que es lo que importa desde un punto de vista profesional; el software solo es una herramienta.

lunes, 27 de febrero de 2012

Cheese, fotos en ráfaga y conversión a vídeo

He logrado, o mejor debemos decir hemos logrado, por que he tenido ayuda "experta", superar algunas de las dificultades del uso de cheese que decíamos aquí. En primer lugar, el apagado del monitor ha sido bastante simple, ejecutando estas ordenes:
xset s off # Disable X windows screen saver
xset -dpms # Disable display power management system
tomadas de aquí.
Sin embargo, han aperecido otras dificultades. Cheese, además de limitarse a 10.000 imágenes, ha presentado otra dificultad; guarda los ficheros con unos nombres que dificultan la conversión a vídeo. Los ficheros, para poner un ejemplo, tienen unos nombres que muestran un cuerpo inicial común formado de la fecha de inicio y la hora, minutos y segundos de comienzo:
- Primero: 2012-02-17-173235_1.jpg
- Último: 2012-02-17-173235_10000.jpg
Luego se numeran desde el 1 en adelante, pero sin mantener un número común de caracteres. Esa falta de ceros a la izquierda de los números hace que el ordenador, y los programas que generan el vídeo desde las imágenes, los ordenen de manera equivocada, siendo por ejemplo el último el 2012-02-17-173235_9.jpg. Así, cada determinado número de frames hay una imágen equivocada que genera bastantes molestias.
Por suerte mi amigo hckorootx generó unos scripts para cambiar en masa el nombre de los ficheros, como podemos ver en los comentarios de esta entrada. En concreto, este script funcionó perfectamente (muchas gracias, hckorootx):

#!/bin/bash
for archivo in *.jpg; do
long_total=`expr length $archivo`
long_util=`expr $long_total - 18`
nombre_inutil=`expr substr $archivo 1 18`
nombre_util=`expr substr $archivo 19 $long_util`
if [ $long_util -eq 5 ]; then
ceros="0000"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 6 ]; then
ceros="000"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 7 ]; then
ceros="00"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 8 ]; then
ceros="0"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
fi
done

Además, como se ve es muy explicativa por si misma. Menos mal, por que yo de script en bash no tengo ni idea, y eran casi 40.000 ficheros en 6 tandadas los que había que renombrar.
Una vez convertidos adecuadamente desde el primero 2012-02-17-173235_00001.jpg hasta el último 2012-02-17-173235_10000.jpg, ya solo quedaba dar una orden de conversión. Después de haber pensado en usar openshot, decidí usar directamente mencoder, por que el terminal es siempre más rápido.
Con esta orden,

$ mencoder "mf://*.jpg" -mf fps=25 -o output.avi -ovc lavc -lavcopts vcodec=mpeg4

que tendré que pulir leyendo más profundamente las guías modernas de mencoder, me salió un conjunto de vídeos de los que cortando trozos y pegando con VirtualDubMod a través de wine logré un total de 4minutos y 12 segundos bastante buenos (me ha felicitado mucha gente), a partir de algo más de 6300 imágenes del total de 40.000.
No, no enseñaremos aquí el vídeo, por que es un objeto científico, y hasta que sea publicado los científicos no compartimos nada de nada. Después de publicarlos los derechos dejan de ser nuestros y ya no podemos disponer de nuestros hallazgos para difundirlos y hay que pedírselos a editoriales como Elsevier, Springer y otras similares. Si me dejan ponerlo en Youtube, según el uso al que esté destinado, lo pondré también aquí, pero no prometo nada.
El siguiente paso sería aprender lo suficiente de motion para poder evitar esa limitación de 10.000 imágenes de cheese... pero esa será otra historia

jueves, 23 de febrero de 2012

Nuestro comportamiento en la naturaleza

Este álbum de fotos es simplemente la colección de cosas que la gente tira alrededor de los 2 kilómetros de un camino de monte. Era simplemente un paseo, pero a veces es mejor no fijarse demasiado, para mantener el ánimo. Si uno se fija un poco, se ve la impunidad con la que maltratamos a la naturaleza. Tomémoslo como la segunda parte de este otro álbum que ya había mostrado aquí.

sábado, 18 de febrero de 2012

Ubuntu 10.04.4

Gracias a Ubuntutips he visto que Ubuntu ha publicado la última actualización de su LTS 10.04, una versión muy estable y que puede servir de escape para aquellos que no les gusta Unity ni gnome-Shell. Voy a conservar una copia por si alguien me pide pasarse a Linux. De primeras, veo difícil un cambio tan drástico, de windows XP a gnome-Shell.

viernes, 17 de febrero de 2012

Cheese y fotos en ráfaga. Problemas al apagarse el monitor

Estoy experimentando la mejor forma de sacar tandadas de fotos con una cámara para luego hacer un vídeo. El modelo es una larva en desarrollo y la intención es seguir algunas de las fases de transformación. La primera prueba fue "casi" exitosa. Y digo casi por que mi cámara cutre Logitech C200 sacaba una resolución 640x480 decente con cheese, hasta que descubrimos varios defectos. Primero, no se puede pedir más de 10.000 fotos (lo intenté con 30.000 y 15.000, y siempre marca 10.000). Segundo, y mucho más importante, al llegar horas después para comprobar como ha salido todo, descubro que cheese para de fotografiar cuando el monitor se apaga. Además, en gnome 3 no hay una opción gráfica para negar el apagado de la pantalla. El máximo tiempo es de una hora (ha desaparecido el never).


El resultado ha sido que a lo largo de la noche se ha parado repetidas veces de fotografiar. Lo más sorprendente es que unas después, siempre aleatoriamente, volvía a empezar. Sospecho que se debe a vibraciones que activa el monitor por movimientos del ratón. Por supuesto, he intentado encontrar soluciones:

1. Uso de motion. Tiene varias ventajas. Es un programa de vigilancia, así que se puede activar para sacar solo fotos cuando hay movimiento. Es en consola, con lo que supongo que no se verá alterado por un monitor apagado.

2. Editar xorg.conf. Aquí podemos ver como editando la sección ServerFlags

Section "ServerFlags"
Option "blank time" "0"
Option "standby time" "0"
Option "suspend time" "0"
Option "off time" "0"
EndSection

se anula el apagado. El problema es que en las distribuciones modernas la mayor parte de los conf de toda la vida han dejado de existir o se localizan en otro sitio en directorios conf.d. En resumen, en Fedora 16 no existe xorg.conf. Mejor aun, al querer generarlo como administrador, simplemente al escribir estas líneas,

su -
palabrita
gedit /etc/X11/xorg.conf

sin escribir en el fichero y sin guardarlo cheese dejó de funcionar (y tardó un rato antes de poder llamarlo de nuevo). Por lo de ahora he dejado esta posibilidad aparte

3. Ordenes más sencillas a través de setterm. Por ejemplo aquí indica alguna posibilidad

$ setterm -powersave off -blank 0

Empezaré probando esta última. Si no funciona, seguiremos generando un xorg.conf y finalmente con motion (es un programa de terminal cuyas opciones dan para un kilómetro y medio de papel impreso). La versión gráfica kmotion creo que precisa apache, lo que para hacer unas fotos de 50 kb me parece mucho.

Finalmente, si todo sale bien, compraré una cámara con más resolución.

Fedora 64bits. Faltan librerías... a veces

Desde que uso Fedora, debido a la velocidad con que ponen paquetes nuevos, he llegado a la costumbre de actualizar cada vez que empiezo a trabajar con un ordenador (un simple yum update en root). Como dispongo de 4 ordenadores de trabajo, según el momento del día y donde esté, actualizo 3 en 64bits y uno en 32bits, lo que me ha permitido notar (y van dos veces), como las librerías en 64bits se actualizan con retraso, al menos en ocasiones. Lo normal es una actualización sencilla, pero en ocasiones se encuentra uno un mensaje como este


con lo cual le queda a uno la duda de no actualizar, actualizar parcialmente (repetir la orden con un añadido yum update --skip-broken), con lo que actualiza todo aquello que no tenga dependencias irresolubles o hacerlo por las malas, actualizando lo que falta compilando desde código fuente. Debido a los problemas que supone la instalación con dependencias de librerías aun no actualizadas (por ejemplo, véase aquí como se puede bloquear un sistema por solo una librería), prefiero la actualización parcial.


Normalmente en 24 o 48 horas ya está actualizada la librería y todo vuelve a la normalidad, en la siguiente actualización.


jueves, 16 de febrero de 2012

Red inalámbrica. Nuevo router

El proveedor de red que me permite e-comunicarme con matrix ofrecía la posibilidad de doblar la velocidad de red por un euro. Debido a nuestro afan de ser tan matrix como el que más decidí aceptar. Sin embargo la condición era cambiar a un nuevo router N, un Hitron BVW-3653 (el modelo lo supe después). 
Llegan los técnicos, se llevan el modem que tanto servicio le ha dado... al router que ponía después y me ponen esa ... cosa.
El resultado ha sido una red más rápida y completamente abierta sin protección alguna (ni siquiera una simple encriptación WEP). Además, mientras no descubra otras posibilidades, este cablerouter se configura de forma totalmente gráfica, casi sin posibilidades. Además, mirando en la red se puede ver que presenta errores en el enrutado, y que su potencia de emisión inalámbrica es escasa.
Por lo tanto he decidido aplicar una solución drástica; me he comprometido a mantener esta "cosa" 6 meses, pero a cambio he ganado una red de 30 Mbits. Para poder convivir con esa situación, he anulado la emisión WIFI de este router y cambiado el usuario y las palabras de entrada; he cableado directamente el ordenador principal al que he puesto en zona desmilitarizada, y sí, hay 30Mbits -o más, por que en ocasiones la red pasaba de 4MB/s (4*8=32). Tres, en la segunda salida de cable (y aun le quedan dos) he conectado mi antiguo linksys, con lo cual no he tenido que configurar una nueva red inalámbrica, ya que sigo aplicando la configuración anterior. Además, tengo una segunda ventaja. Cuando no se usan los equipos adicionales (otros ordenadores, WD TV Live y Play Station), se puede apagar el router. ¡Fantástico!, no hay Hitron que por bien no venga.
Habrá que buscar en la red si existen firmwares libres para este router.

PD. No sé por que el que es considerado como el mejor proveedor de red de España reparte dispositivos tan malos.

miércoles, 15 de febrero de 2012

Discos de más de 2TB. Posibilidades de uso

El día que me enteré de las inundaciones en Tailandia fui corriendo a mi tienda habitual de material informático a comprar discos duros, y solo me vendieron uno, con lo que hice un recorrido "amplio" por la ciudad y me compré 3, por si tenía luego problemas de suministro. Apresuradamente compré dos unidades de más de 2 TB, que eran inútiles en mi antigua unidad WDTV. Después de haber comprobado que el firmware no se ha cambiado en mucho tiempo, y que por tanto es un dispositivo sin futuro, lo he transferido a otra televisión y en la que se usaba habitualmente he instalado un nuevo WD TV Live. Este nuevo dispositivo sí lee los discos de más de 2TB, así que ahora solo nos queda decidir la forma en la que se van a usar.
Como es sabido, las tablas de partición basadas en MBR (Master Boot Record), la famosa partición msdos que llevamos haciendo desde ya no se sabe cuando, no permiten particiones mayores de 2TB, por diferentes razones que en vez de explicar aquí serán más fácil de entender si las miramos aquí. El resultado final es que tenemos dos discos de 2,5 TB (WD Elements) y 3TB (WD My Book) al que tenemos que darle uso.
El uso de estos discos como arranque genera un problema en la BIOS, que tiene que ser capaz de arrancar en formato EFI (Extensible Firmware Interface), en vez de MBR, ya que así podemos utilizar tablas de partición GPT (GUID Partition Table). Es decir, debemos poder cambiar el tipo de arranque en la BIOS. En mi caso no me preocupa. Primero, uso discos de sistema de 30GB y 34GB en mis ordenadores principales. En los demás no uso nunca discos muy grandes (trabajo, pasó el resultado a Dropbox y punto). Mi principal objetivo para estos discos es almacenamiento. Para ello he probado diferentes formas de distribuir los discos:
1. Lo más sencillo es hacer dos particiones, de tal manera que ninguna tenga más de 2TB. Me surge la duda de si eso es posible si la partición se realiza en sectores de 512 bytes, ya que en ese caso chocaríamos con el límite de número de sectores (ver de nuevo aquí). De todas maneras, ahora la partición estándar en gparted es ahora en sectores de 4096 bytes, así que no tenemos ese problema. En este caso el disco de 2,5TB fue particionado tipo msdos (MBR), con dos particiones inferiores a 2TB


El dispositivo WD TV Live como se ve lee perfectamente las dos particiones y sus ficheros. Por supuesto, no es posible ni ext3, ni ext4. El dispositivo solo lee fat, fat32 y NTFS.



Es decir, una forma de usarlos para simple almacenamiento sería particionarlo "tradicionalmente" con dos particiones (o más) inferiores a 2TB. Para asegurar, formatearemos con sectores de 4096 bytes o más.


2. Por supuesto, lo más adecuado -o quizás no- sería particionarlo una sola vez en una tabla GPT. Lo he aplicado sobre el disco de 3TB y por curiosidad he aplicado inicialmente un formateo en ext4. El dispositivo detectaba el disco,


pero era incapaz de encontrar los ficheros.


Sin embargo, con la tabla de partición GPT, pero formateado a NTFS, el dispositivo lo lee perfectamente


Esto nos da una segunda opción; una tabla de partición GPT con una sola partición (o varias si se prefiere). La decisión depende de varios factores. Sin embargo, por comodidad, seguridad y compatibilidad, quizás lo más adecuado en este momento sea hacer dos particiones o más del disco, ya que un fallo en una partición podría no afectar a la otra y se podrían salvar al menos la mitad de las copias priv..., quiero decir de las manzanas (más de una cesta) y en una tabla MBR.
El uso de las particiones GPT para arranque no es, por ahora, algo que me preocupe, ya que tiendo a utilizar el disco más pequeño que encuentro para el sistema. En estos momentos uso discos sólidos para eso, ya que ahora mismo empieza a ser muy difícil conseguir un disco magnético menor de 1 TB, y prefiero tener separados el sistema y home.

Eso sí, lo reconozco, y se ve en las fotos; he particionado de forma gráfica, a través de gparted. Para los que prefieran hacerlo de forma manual, puede ser útil esta entrada. Sin embargo, una vez particionado y formateado queda asignado al grupo root (gparted solo actua desde root), y el cambio de grupo y los permisos se hicieron en terminal (chgrp y chmod). Son costumbres de trabajo. Sea como fuere, ambos discos funcionan, son utilizables en el ordenador (casi 4 años, no precisamente de hoy) y el WD TV Live también los lee. Tenemos estas opciones y funcionan.

viernes, 10 de febrero de 2012

WD TV Live

He sustituido mi antiguo WDTV con un nuevo WD TV live. Una vez configurada la red inalámbrica señala el posible cambio de firmware; supongo que si está cableado lo mostrará inmediatamente. Además, y eso es lo más importante para mi, y la razón por la que lo compré, lee perfectamente los discos de más de 2TB. Tiene capacidad de streaming, como se puede ver en la página de WD


y hasta se le puede conectar un teclado USB para navegar más fácilmente.

martes, 7 de febrero de 2012

Fedora, cpulimit y discos NTFS

Debido a mis problemas con los discos NTFS decidí seguir los consejos de hckorootx (véase comentarios aquí). Esto nos lleva a algunos problemas. El primero, cpulimit no esta en los repositorios estándar de Fedora, así que nos queda instalarlo desde un paquete rpm (32 bits o 64 bits), o bien introducir el repositorio sphere. Por ejemplo, la forma más fácil es como administrador
$ su -
     palabrita de administrador
# gedit

en ese documento pegamos el texto que podemos extraer de esos enlaces

[rpm-sphere]
name=RPM Sphere
baseurl=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/
gpgkey=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/repodata/repomd.xml.key
enabled=1
gpgcheck=1


y luego lo guardamos en el directorio de los repositorios (/etc/yum.repos.d) como rpm-sphere.repo.

Actualizamos (nos basta un simple # yum update y ya se recargan los repositorios) y lo instalamos directamente

# yum install cpulimit

Sin embargo surgen nuevas dudas a partir de aquí. Si nos fijamos en los comentarios de hckoroot, la forma más fácil de usar cpulimit es, en vez de identificar el comando a controlar por su PID, lo mejor es identificarlo por su nombre. Nos quedaría

cpulimit --path=/ruta/ejecutable --limit=N

lo que nos lleva a como copiamos:

- Si usamos cp en terminal, el comando es cp, claro


- Si usamos rsync, que a mi me gusta particulamente, el comando es rsync



El problema radica en que la mayor parte copiará con Nautilus, que lleva embebido los comandos, y no genera una nueva instancia para copiar, si no que todo lo que hagamos con Nautilus se hace dentro de la misma instancia. A eso se suma que el gran consumo del sistema al copiar en discos NTFS se produce no en la copia, si no en el propio manejo del NTFS a través de mount.ntfs. Por ejemplo este top copiando con Nautilus en un disco formateado NTFS:


Y si a ello le sumamos otras aplicaciones que consuman recursos, por ejemplo Chromium y aMule, llegamos al bloqueo del sistema


¿Podemos solucionarlo con cpulimit? Desde mi punto de vista no. Si el límite que le ponemos es sobrepasado, la aplicación deja de funcionar; si de corta mount.ntfs, probablemente perderemos el contenido que hayamos copiado en él, ya que no se guardarán las nuevas tablas, como ya me ha pasado a mi sin incluir cpulimit. Además, ¿cuál sería el límite? Como se puede ver en esa instancia, mount.ntfs estaba momentáneamente por encima de 50%; probablemente esté a veces por debajo y otras veces por arriba. Si llegamos hasta un 70%, ¿cuanto queda para lo demás?
Conclusión: una única recomendación para copiar en discos formateados en NTFS en Linux - paciencia y nunca hacer saltar el sistema. Mejor esperar. Un segundo apunte, que me aplico en estos momentos, copiar en lotes pequeños, como mucho 30-40GB, por que la paciencia tiene un límite y tendemos a ponernos nerviosos.
Si alguien quiere probar cpulimit en la copia sobre NTFS, que lo haga y nos diga que límite hay que poner. Yo prefiero aplicar la paciencia y no perder más material.

jueves, 2 de febrero de 2012

Fedora. Habilitar sysrq

Desde que uso Fedora no he tenido una necesidad de usar nuestro famoso REISUO hasta hoy. sin embargo, en Fedora no están habilitadas las teclas "mágicas", así que no podemos usarlas. Es muy recomendable activarlas para no tener que reiniciar con la tecla de Reset como me ha pasado hoy a mi. Es sencillo editando de nuevo sysctl.conf:
- Terminal; nos identificamos como administrador
$ su -
palabra
# gedit /etc/sysctl.conf
y ponemos el valor de 1 a kernel.sysrq


tras el reinicio ya están disponibles las teclas mágicas (y REISUB/O).

QR ¿y en el móvil?

Respondiendo a varias preguntas, en mi móvil con Android uso QuickMark. Comencé usando QR Droid, que también funciona bien, pero me gusta más la primera.