martes, 6 de marzo de 2012

Software libre y "compatibilidad"

Estoy bastante harto de escuchar siempre lo mismo "... sí, funciona muy bien. Me pasaré a ese software cuando sea compatible." Esta respuesta la he oído por enésima vez después de que a través de mi software "no compatible" un usuario haya podido leer un fichero que no era capaz de leer con el suyo "compatible". La escena es una muy habitual; un fichero docx no puede ser abierto por MSOffice 2007 compatible por que tiene un error. Por suerte, LibreOffice 3.4.5 incompatible sí puede, se salta el error y se puede leer el documento. Otra afirmación muy común es también "Necesito mantener Explorer para abrir ciertas páginas." Se olvidad de decir páginas mal escritas.
Yo afirmo:
Desde el año 2007 uso software libre en mi trabajo, en el ocio, para jugar, para moverme en la red, para dar mis clases, cursos y conferencias y jamás me he sentido "incompatible". Hago presentaciones, vídeos, escribo artículos, maqueto libros, edito fotos y no he requerido acudir a software propietario (salvo SPSS hasta hace uno par de meses). No sé por que ser compatible es usar software propietario. Es más, cuando hay problemas, los "compatibles" los solucionan pidiéndole a los "incompatibles" que arreglen es "desaguisado compatible" con aplicaciones "incompatibles". Ya está bien; los INCOMPATIBLES vivimos perfectamente y no necesitamos ser más COMPATIBLES. Quizá merezca la pena recordar aquella imagen sobre MS, Apple y Linux de Linux Hispano


Esa es la actitud; te lo mereces, por incompatible.

lunes, 5 de marzo de 2012

Collusion: extension de Firefox

Collusion: con ella podrás ver al gran hermano sin mirar a la televisión. Nos permite ver quien nos está siguiendo, incluso a través de otros, según vamos navegando. La he instalado en mis ordenadores y ofrece información de seguimiento. Sin embargo, a partir de un determinado tiempo de navegación la información empieza a ser confusa. Sin embargo, no está mal instalarla. siempre puede dar un buen fondo de pantalla.

 

Para entender mejor como funciona, es recomendable pasarse por alt1040 y leer su artículo.

viernes, 2 de marzo de 2012

¿Cómo sigue lo de los discos duros?

En The Inquirer ES he visto que la ya se está recuperando la producción de los discos duros. Sin embargo, para mi pesar, entre los más afectados estaban Western Digital y Toshiba, que son los que suelo comprar. De todas maneras, hasta eso dejará de preocuparnos. La evolución es imparable; hemos abandonado los disquettes, prácticamente ya no uso los CDs y DVDs y ahora mismo el uso de la nube provoca que cada vez sea menos necesario el almacenamiento local. En muy poco tiempo dejaremos de usar discos duros propios y usaremos la nube, es decir, discos duros ajenos, de Amazon, Google, Arsys, Microsoft o quien sea. A pesar de que respeto muchas de las ideas de Richard Stallman, la comodidad y la facilidad de uso harán que confiemos nuestros datos a un almacenamiento externo indeterminado. Sí; se utiliza más rápidamente lo fácil que lo más adecuado (y esta vez no me refería a Windows). De todas maneras no debemos olvidar lo que decía R. Stallman en esa entrevista:

"One reason you should not use web applications to do your computing is that you lose control," he said. "It's just as bad as using a proprietary program. Do your own computing on your own computer with your copy of a freedom-respecting program. If you use a proprietary program or somebody else's web server, you're defenceless. You're putty in the hands of whoever developed that software."

Por ejemplo, podías haber confiado tu material de trabajo a megaupload, y ya no tienes nada. Es solo un ejemplo.

Hay un segundo párrafo muy interesante,

"The interesting thing about cloud computing is that we've redefined cloud computing to include everything that we already do," he said. "The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?" (la negrita es mía)

pero no pienso hacer comentario alguno sobre las muchas ideas que se pueden extraer de este párrafo. Extraigan conclusiones (se admiten comentarios).

jueves, 1 de marzo de 2012

rpm vs deb

Durante la revisión que suelo hacer cada día de los blogs que más me interesan, encontré que en Linux Hispano destacaban una aplicación gráfica para montar ficheros ISO, gISOmount.


Ofrece de forma gráfica (ergo sencilla) varias de las cosas que puedes hacer de muchas otras formas. Monta los ficheros ISO para echarles un vistazo para ver que hay dentro; podemos montarlos en terminal o simplemente picar en el y la distribución en la que vivas te ofrece alguna opción; por ejemplo, ahora mismo en Fedora 16 Archive Mounter, que también existe en Ubuntu y otras distribuciones. En segundo lugar nos permite calcular el MD5 (Message-Digest Algorithm 5, Algoritmo de Resumen del Mensaje 5) de los ficheros ISO para comprobar que no hay errores en la bajada del fichero o que no ha sido manipulado y se corresponde al original. Eso lo podemos hacer muy fácilmente en el terminal con md5sum


Por supuesto, nos permite copiar la ISO a un CD/DVD. La copia la podemos hacer sin mayor problema con brasero o K3B, aunque en los últimos tiempos no grabo ISOs en disco. Si son distribuciones, si me lo permiten los ordenadores los preparo con UNetbootin. Si son multimedia (DVDs...), los lectores multimedia los leen sin tener que grabarlos en disco. Finalmente permite navegar en el CD pero, ¿cuándo no hemos podido?
Ciertamente, podemos hacer todo sin esa aplicación, pero nos lo agrupa todo en uno y es sencilla de usar. ¿Por qué el título de la entrada es rpm vs deb y no gmountiso? Por que este paquete, como muchos otros, no está disponible para Fedora, ni para el resto de las distribuciones con paquetes rpm (Red Hat Package Manager) en binarios, que solo se encuentran para deb (Debian y derivados). Como es natural, no necesito el paquete y nos queda el código fuente (no lo he buscado), pero este es uno más de los muchos paquetes que están preparados para distribuciones deb y que  los no debian debemos recurrir a código fuente. Esa es la mayor diferencia que encuentro entre las distribuciones rpm donde estoy ahora y los deb en las que estaba antes.

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.