17 años en Internet

15 enero 2014

Be "nice", asignar prioridades en shells de Unix

     El estándar POSIX permite la definición de prioridades para que ciertos procesos tengan mayor o menor probabilidad de acceso al quantum de la CPU. En esta entrada no voy a entrar en explicar el funcionamiento de dicho estándar, pero a estas alturas queda claro que todos sabemos que si un procesador tiene uno, dos, cuatro o incluso ocho núcleos, pues resulta físicamente imposible que dicho procesador pueda procesar a la vez todos los procesos y aplicaciones que gestiona un sistema operativo.

A groso modo, podemos afirmar que realmente un sistema operativo no es multi proceso, si no que lo emula de forma bastante eficaz. Por un lado, nuestro núcleo realiza una lista con procesos que debe de procesar y durante un periodo de tiempo reducido (conocido como "quantum") ejecuta uno (o varios, si el procesador es multi hilo) dejando durmiendo al resto. Como es de esperar, al igual que en la justicia española no todos los procesos son iguales, siendo unos más importantes que otros y por consiguiente durante un mismo periodo de tiempo ciertos procesos tendrán mayor número de accesos a la CPU que otros.

Esto se puede observar fácilmente a través del comando "top", donde podemos apreciar distintos asignaciones en la columna PR (siendo la columna NI su inversa), con valores que en condiciones normales por lo general van desde el 39 (poco importante) al 0 (muy importante), siendo 20 la prioridad por defecto de todo nuevo proceso. Por lo general, el estándar dicta que un proceso puede tener prioridad del 1 al 32, menos para Linux, el cual puede definirse del 1 al 99 (1). No obstante estos valores pueden variar dependiendo de las distribuciones (el proyecto GNU recomienda hacer uso de las variable sched_get_priority_max si vas a programar algo que requiera modificar prioridades), además de que en la práctica se suele emplear el sistema del 0 (más prioritario) al 39 (menos prioritario).

La cuestión es que a nivel de programación, los lenguajes compatibles con POSIX traen las distintas herramientas necesarias para pelearte con este sistema de prioridades, pero si no queremos tocar código, siempre podemos hacer uso de nice y renice para modificar a placer nuestros propios scripts. El comando nice está pensado para crear una tarea nueva y asignarle una prioridad distinta a la que traiga por defecto, mientras que renice está pensado para cambiar la prioridad de un proceso ya existente a través de su PID, usuario o grupo.

La sintaxis básica de nice es bien simple, puesto que recibe dos únicos argumentos: un número entero que dicta la cantidad de prioridad a restar y la orden a ejecutar. Tengan en cuenta que un proceso normal tiene asignado valor 20. Es decir, que en caso de pasar los valores 5 o 10, estos se sumarán al 20, obteniendo prioridades de 25 y 30 respectivamente... o lo que es lo mismo, con ello hacemos que el proceso a ejecutar pase a ser menos prioritario. En caso de querer dar más prioridad, habrá que poner un valor negativo, o lo que es lo mismo, escribir "--" antes del número entero. Hay que destacar que un usuario puede hacer que su proceso tenga menor prioridad (un valor superior a 20), pero sólo los usuarios con permisos de administrador son capaces de asignar una prioridad inferior a 20. Aquí tenemos un par de ejemplos prácticos:

Comprimir un archivo tgz con 39 de prioridad (la más baja):
~$ nice -19 tar czvf tar.tgz tmp_folder/
Comprimir el mismo archivo tgz utilizando el máximo de CPU:
~$ sudo nice --20 tar czvf tar.tgz tmp_folder/
El primer caso da a entender que la compresión del fichero no es prioritaria, por lo que tendrán prioridad de acceso a CPU el resto de procesos del sistema. La tarea acabará haciéndose porque los núcleos Unix tienen algoritmos para evitar la "inanición", pero se resolverá en un tiempo mayor de lo que tardaría normalmente.

Mientras, en el segundo ejemplo pasa lo contrario, esta compresión pasa a ser uno de los procesos más importantes del sistema, por lo que en la práctica algunos recursos podrían mostrar ralentizaciones hasta que ésta acabe. Está claro que habrán cambios de contexto en el procesador y que se irán abordando y acabando otras tareas mientras ésta se esté realizando... pero ésta tendrá un mayor número de accesos a CPU que el resto durante el mismo periodo de tiempo. No obstante se recomienda no otorgar nunca una prioridad alta a un proceso pesado que vaya a consumir un número elevado de accesos a CPU, puesto que podría causar una sensación de bloqueo o cuelgue del sistema.

Para verificar esta teoría, vamos a proceder a ejecutar un script con tres tipos de prioridades: 20 (por defecto, 39 y 0. Concrétamente, el contenido del script será el siguiente:
#!/bin/bash
for i in `seq 1 10000`; do touch /tmp/lolo.txt; done
Prioridad 20 (proceso normal):
~$ time ./prueba.sh
real 0m20.507s
user 0m3.490s
sys 0m17.750s

Prioridad 39 (baja):
~$ time nice -19 ./prueba.sh
real 0m20.579s
user 0m3.377s
sys 0m18.005s

Prioridad 0 (alta)
~$ time sudo nice --20 ./prueba.sh
real 0m19.945s
user 0m3.894s
sys 0m16.743s

Como era de esperar, a mayor prioridad antes acaba realizándose nuestra tarea, puesto que esto garantiza un mayor número de accesos a CPU. Tras la ejecución de estas pruebas con "nice" queda aclarado que es posible asignar mayor o menor prioridad a nuevas tareas que queramos ejecutar, ¿pero qué pasa con las ya existentes?

Bueno, para ello podemos hacer uso del comando renice, el cual puede asignar cambios de prioridad a procesos a través de su PID (número identificador de proceso), del grupo o incluso del usuario al que pertenence. El funcionamiento es parecido a nice, por un lado indicaremos el incremento de la prioridad a través de su símbolo (esta vez haciendo uso de + y -, en vez de - y -- de nice), mientras que por otro pondremos el PID del proceso a alterar o bien definiremos el grupo o usuario al que pertenece dicho proceso. Hay que aclarar que pese a que el sistema "habla" de prioridades que van del 0 al 39, renice informa en escala que va del -20 (más prioritaria) al +19 (menos prioritaria). Es decir, para renice la prioridad inicial de un proceso no es 20, es 0.

Ejemplo 1, obtenemos el PID de nuestra shell actual y le damos la máxima prioridad:
~$ echo $$
15708 
~$ sudo renice -19 15708
15708 (ID de proceso) prioridad antigua 0, prioridad nueva -19
Ejemplo 2, incrementamos la prioridad para todos los procesos pertenecientes a los usuarios MySQL y Apache:
~$ renice -n -19 -u mysql
107 (user ID) old priority 0, new priority -19 
~$ renice -n -19 -u www-data
107 (user ID) old priority 0, new priority -19

09 enero 2014

Inyección de ficheros en código HTML

     Desde HTML 4.01 se hace referencia al esquema "Data: URL", el cual permite embeber código en base 64 dentro de una definición de ruta para acceder a él como si tratara de una referencia externa (12, 3). Esta versatilidad permite la creación de documentos html compatibles con los navegadores actuales que puedan hacer uso de hojas de estilo, clases de javascript o de cualquier otro recurso externo sin necesidad de emplear más de un documento.

No obstante, es una táctica sólo recomendada para ficheros ligeros, puesto que este mecanismo de inyección de recursos realmente vuelca el contenido del fichero como una URL a resolver y determinados navegadores como Opera truncan las URL que poseen más de 4.000 carácteres (lo que vendría siendo un fichero de texto plano de 4KB)... además de que resulta poco práctico porque siempre que queramos modificar el recurso tendremos que reconvertirlo a base 64 y editar manualmente el html.

Para hacer uso de este esquema símplemente debemos convertir nuestro fichero en una cadena de texto base 64. Esto puede hacerse en Unix a través del binario base64. Ejemplo:
sebas@MacBookPro:~$ echo "hola qué tal?" > hola.txt 
sebas@MacBookPro:~$ cat hola.txt
hola qué tal? 
sebas@MacBookPro:~$ base64 hola.txt
aG9sYSBxdcOpIHRhbD8K
Ahora bien, esto no se limita a cadenas de texto. También nos sirve cualquier clase de archivo que queramos. En el siguiente ejemplo convierto en base 64 un código QR almacenado en una imagen de formato PNG de 0,6KB:
sebas@MacBookPro:~$ ls -lh Ubuntu\ One/QR/blog.png
-rw-r--r-- 1 sebas sebas 655 ene  9 20:16 Ubuntu One/QR/blog.png 
sebas@MacBookPro:~$ base64 Ubuntu\ One/QR/blog.png
iVBORw0KGgoAAAANSUhEUgAAAGMAAABjCAIAAAAAWSnCAAAAA3NCSVQICAjb4U/gAAAACXBIWXMA
AAsSAAALEgHS3X78AAACMklEQVR4nO2bS27DMAwF66L3v3K6UxZCieHHcgPMLBNFEh74Qou0rtfr
9SWA76c38DGoFEWlKCpFUSmKSlFUiqJSFJWiqBRFpSg/ZNB1XZ011tFyzRN8si9KTqZTOwwwpigq
RUHuW6RKNLsjdtORtVKebe4wwJiiqBQl575FELep+Cd+JKa7b4cLY4qiUpSi+8a5z4ZTGFMUlaI8
477ANc0D4H0YUxSVohTdN26E4JBYW2t8h8YURaUoOfc1S4ukfrIvcbL4GWBMUVSKgtx34JGvZszF
gR0aUxSVoly1hBI4ItXLC0h1HGpnw9SvjCmKSlGQ+96j//baPiaY+UD7PjUPwZiiqBQl5773z4Ye
C4mdyeBmCjb3TaJSlLE3zZ59H4z8CTRXN6YoKkUpPnmmkk7wFRm8rx7gue95VIqSy32pBLc7q1Zs
IYPJNshXAcYURaUoxZrnTjOL1dJis6wa7HDHmKKoFGX+jkMqH6XSIlmr6esAY4qiUpTuHYdm0tkh
Zhl/5YZgTFFUilLsOBQXO9gl99z3GCpFGTv3BTRrNfs8tdfS7PcdQqUoR++2B2OavbwDV5aMKYpK
UY7ebU+92TLVQJ+6HmhMUVSK8l/utjf7+Dsp8/rkOYlKUY66b+oAGMy810Vr/YUdY4qiUpSjd9vJ
k2etpXjfpdqFMUVRKcrRu+3BhEH1MlU2SQ22234LKkU52u/7aIwpikpRVIqiUhSVoqgURaUoKkVR
KYpKUVSK8gskWJXNsyhgrgAAAABJRU5ErkJggg==
Una vez tengamos el contenido en base 64 haremos uso de la etiqueta HTML correspondiente a nuestro recurso ("img" para imágenes, "a" para realizar una descarga, "audio" para reproducir un sonido, etcétera). Después definiremos en la url (ojo, dependiendo la etiqueta esto se hace en href o src)  el tipo de fichero (precedido por la cabecera "data:"), el tipo de decodificación (en este caso ";base64,") y todo el contenido que hemos calculado anteriormente.

Por ejemplo, la definición del PNG que contiene mi código QR quedaría así:

<img border="0" height="97" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAGMAAABjCAIAAAAAWSnCAAAAA3NCSVQICAjb4U/gAAAACXBIWXMA
AAsSAAALEgHS3X78AAACMklEQVR4nO2bS27DMAwF66L3v3K6UxZCieHHcgPMLBNFEh74Qou0rtfr
9SWA76c38DGoFEWlKCpFUSmKSlFUiqJSFJWiqBRFpSg/ZNB1XZ011tFyzRN8si9KTqZTOwwwpigq
RUHuW6RKNLsjdtORtVKebe4wwJiiqBQl575FELep+Cd+JKa7b4cLY4qiUpSi+8a5z4ZTGFMUlaI8
477ANc0D4H0YUxSVohTdN26E4JBYW2t8h8YURaUoOfc1S4ukfrIvcbL4GWBMUVSKgtx34JGvZszF
gR0aUxSVoly1hBI4ItXLC0h1HGpnw9SvjCmKSlGQ+96j//baPiaY+UD7PjUPwZiiqBQl5773z4Ye
C4mdyeBmCjb3TaJSlLE3zZ59H4z8CTRXN6YoKkUpPnmmkk7wFRm8rx7gue95VIqSy32pBLc7q1Zs
IYPJNshXAcYURaUoxZrnTjOL1dJis6wa7HDHmKKoFGX+jkMqH6XSIlmr6esAY4qiUpTuHYdm0tkh
Zhl/5YZgTFFUilLsOBQXO9gl99z3GCpFGTv3BTRrNfs8tdfS7PcdQqUoR++2B2OavbwDV5aMKYpK
UY7ebU+92TLVQJ+6HmhMUVSK8l/utjf7+Dsp8/rkOYlKUY66b+oAGMy810Vr/YUdY4qiUpSjd9vJ
k2etpXjfpdqFMUVRKcrRu+3BhEH1MlU2SQ22234LKkU52u/7aIwpikpRVIqiUhSVoqgURaUoKkVR
KYpKUVSK8gskWJXNsyhgrgAAAABJRU5ErkJggg==" width="97" />

Y se visualiza así:
 


qrencoder + zbar: Generación y lectura de códigos QR en Linux

Los famosos códigos QR, que a día de hoy vemos en todas partes, fueron inventados en 1994 por Denso Wave (del grupo Toyota) y su nombre es el acrónimo de Quick Response. El motivo del nombre se debe a la necesidad imperiosa de mostrar una gran cantidad de información en un código de barras y que éste tenga una lectura casi inmediata. De hecho, un código QR alfanumérico puede contener nada menos que 4296 caracteres. Esta versatilidad le ha llevado a ser ahora mismo el código de barras más famoso de Japón, hasta el punto de que su gobierno lo emplea incluso a la hora de emitir sus visados.

Gran parte de este éxito se debe a que, a pesar de provenir de un laboratorio de empresa privada, los códigos QR están libres de toda licencia y además cuentan con su propio estándar ISO. Realmente esto es una mentira a medias, puesto que Denso Wave tiene la patente del código QR pero ha decidido no hacer uso de sus derechos de autor. Digamos que, por un lado, la renuncia de sus derechos de autor permite que todo el mundo pueda explotarlo como le parezca, mientras que por otro lado la existencia de un estándar ISO garantiza la existencia de una serie de reglas que todo el mundo debe de cumplir.

Esta flexibilidad, el de tener una serie de normas bien definidas y una licencia de libre uso, permite la profelización de aplicaciones para todo sistema operativo, siendo sobre todo notable en el gran ecosistema actual de smartphones. No obstante, al igual que en los teléfonos inteligentes también existen herramientas de creación y de descifrado de imágenes QR en los sistemas operativos de ordenador, siendo qrencoder y zbar los referentes más famosos de Linux. Ambos suelen estar presentes en los repositorios de toda distribución actual, pudiéndose instalar fácilmente a través de apt-get, yum o yast2.

El uso de qrencoder es bien sencillo:
qrencoder -o imagen.png 'texto a añadir'
Por ejemplo, escribiendo "qrencoder -o imagen.png 'http://www.elgeneralfailure.com'" crearíamos el siguiente código QR:
Al igual que en toda aplicación Unix, podemos jugar con las tuberías o redirigir la entrada estándar para elaborar toda clase de scripts de bash:
echo "http://www.elgeneralfailure.com" | qrencode -o imagen.png
echo "http://www.elgeneralfailure.com" > /tmp/texto.txt
qrencode -o imagen.png < /tmp/texto.txt
echo "http://www.elgeneralfailure.com" > /tmp/texto.txt
cat /tmp/texto.txt | qrencode -o imagen.png
El segundo y tercer ejemplo son bastante útiles si queremos hacer textos complejos con retornos de carro inclusive. No obstante, si desconocemos las bondades de las que permite hacer uso los códigos QT, resultaría útil darle un vistazo a la aplicación QtQR, una aplicación gráfica escrita en Qt que simplifica labores como automatizar el envío de un e-mail o crear una entrada de agenda de contactos:


Para leerlos no hace falta mostrar estos códigos por webcam, también existen aplicaciones que permiten la decodificación de QR a través de imágenes PNG.  El más práctico que he probado es zbarimg (se instala a través del paquete zbar-tools) y requiere cómo único parámetro la imagen a analizar. Ahora bien, habría que aclarar que se trata de una utilidad que permite analizar toda clase de códigos de barra, no sólo los QR.

Ejemplo de uso:
sebas@MacBookPro:~$ zbarimg imagen.png
QR-Code:http://www.elgeneralfailure.com
scanned 1 barcode symbols from 1 images in 0.04 seconds
Por desgracia, a diferencia de qrencode para la entrada de datos no se nos permite jugar a placer con redirecciones ni con tuberías. No obstante, si tenemos instalado el paquete imagemagick, con la instrucción "import :- | zbarimg :-" podemos capturar una región de pantalla para analizar el código QR que contenga (1).

07 enero 2014

05 enero 2014

Juegos viejunos guays: The Legend of Zelda - Twilight Princess


Trailer de presentación del juego durante el E3 de 2004.

Como se puede observar a raíz de la reacción del público, Nintendo presentó algo más que un juego durante la Electronic Entertainment Expo de 2004. Hagamos memoria, la Nintendo Gamecube apenas llevaba 2 años en el mercado y ya era la gran perdedora de su generación. De poco servía tener en su catálogo a grandes juegazos como Metroid Prime o Double Dash, puesto que desde la Nintendo 64 los third parties estaban abandonando las plataformas de sobremesa de Nintendo y por aquel entonces la gente se obsesionaba más por jugar con el jefe maestro en la Xbox o con el Final Fantasy de turno en la PlayStation 2. Antes de que saliera a la venta este juego, la consola Gamecube ya se podía conseguir por 99€ en cualquier centro comercial de España.

Vale, la Gamecube, a pesar de su gran hardware, resultó ser un fiasco en ventas. No obstante, eso no fue lo que hizo enloquecer a toda esa gente cuando se presentó al público lo que posteriormente pasaría a llamarse "Twilight Princess". Para ello tenemos que analizar también los antecedentes de la saga. Recordemos que cuatro años antes, durante la Spaceworld del 2000, Nintendo enseñó un corto donde ya se veía un Link adulto luchando contra un Ganon en una escena animada de lo que parecía que iba a ser el Zelda de su próxima consola (la Gamecube) y a la que la revista española Nintendo Acción calificó como "escena digna de una película de animación". No obstante, finalmente esa escena cayó en saco roto y Nintendo acabó anunciando el "infantil" "The Wind Waker". Los fans se quedaron con la cara traspuesta, puesto que esperaban "otra cosa". Finalmente "The Wind Waker" resultó ser una maravilla técnica que enamoró a un gran público, pero que por desgracia hizo que gran parte de los fans de la saga Zelda se sintieran traicionados hasta la llegada de esa mágica tarde de Junio de 2004.

Consciente de todo ello, del fracaso de la consola y de la decepción de gran parte de los fans de la saga, Nintendo se puso de rodillas y le ofreció a su público lo que quería, lo que pasaría a ser el Rodrigo Díaz de Vivar de la Gamecube: Una nueva entrega The Legend of Zelda, protagonizada por un Link adulto. Y la gente se lo agradeció mostrando una de las escenas más emotivas vistas en un E3. El juego estaba planeado para salir a la venta a mediados de 2005, pero un suceso "inesperado" produjo que finalmente fuera publicado en Diciembre de 2006.


Trailer pomocional presentado durante el E3 de 2005.

Llegado el E3 de 2005, Nintendo volvió a sorprendernos con un nuevo trailer del juego donde se dieron a conocer importantes novedades. Por un lado vemos que Link pasa a transformarse en lobo mientras es manejado por una especie de diablillo (que posteriormente descubriríamos que se trata de Midna, la "princesa del Crepúsculo" que da nombre a este juego). Por otro lado Nintendo mostró en este trailer toda una lección magistral de cómo emplear las paletas de colores  para conseguir despertar ciertos "déjà vus" en los fanáticos de la saga, pudiéndose encontrar en dos grupos principales: El primero es el juego de colores grises, los cuales recordaban al "Dark world" de "A Link to the past", de Super Nintendo; El otro es la combinación de colores verdes y cálidos, que recordaban bastante al "Ocarina of Time", de Nintendo 64.

No obstante, aquel E3 no será recordado por la presentación de este segundo trailer, si no por el anuncio de su nueva consola: La Nintendo Wii. Si señores, éste es el "suceso inesperado" que he nombrado antes. El lanzamiento de Twilight Princess se retrasa hasta 2006 para coincidir con el lanzamiento de la Nintendo Wii, puesto que el juego saldrá finalmente para ambas plataformas.


Trailer de lanzamiento del juego.

Como he mencionado antes, finalmente el juego fue lanzado en Diciembre de 2006, coincidiendo con el lanzamiento de la Nintendo Wii, con un precio de venta recomendado de 59,95€. Ambas versiones eran idénticas, pero poseían dos excepciones que los diferenciaban notablemente. El principal era el control, puesto que la versión de Wii hacía uso del sensor de movimiento para apuntar y del "nunchuck" para desplazarse. La otra diferencia estaba en que la versión de Wii era el modo espejo de la versión de Gamecube. Es decir, la forma de representar los distintos lugares, caminos, mazmorras... todo estaba reflejado de izquierda a derecha, de forma que un mismo juego luciera de forma distinta en sendas versiones.

Se vendieron más de 8,48 millones de copias de "Twilight Princess", de los cuales 1,59 millones de ellas pertenecen a la versión de Gamecube y el otro 6,89 a la versión de Wii. Supone el doble de ventas que su predecesor, "The Wind Waker", pero apenas supuso 1 millón más que el "Ocarina of Time". El caso de que vendiera más unidades que el "Ocarina of Time" resultó bastante llamativo, puesto que pese a tratarse de un buen juego rara vez la gente suele considerarlo mejor que el gran clásico de la Nintendo 64. Las malas lenguas hablan de que su elevado número de ventas se debía a que unos hackers descubrieron cómo hacer uso de un exploit del juego para poder piratear la consola, aunque seguramente se deba a que la Wii vendió tres veces más consolas que la Nintendo 64.

Hablando de ventas, recordemos que el juego iba a ser originalmente exclusivo de Gamecube y es en esta versión la que más rápidamente se agotó, puesto que en contra de todo pronostico resulta que la demanda para esta versión fue mayor de lo que Nintendo previno. Para haceros una idea, en pocos meses el juego pasó a costar 120 euros en el mercado de segunda mano, el doble de lo que valía nuevo... y todo porque no había un stock suficiente. Parecía lógico que esto acabara pasando, puesto que era el último juegazo de Gamecube y muchos usuarios de dicha consola lo querían sí o sí. Y qué decir que la fiebre por esta versión sigue ahí a día de hoy: seis años más tarde rara vez se vende por menos de 80€ en eBay.

AMV del juego con el tema "Knights of Cydonia" del grupo Muse.
Ideal para representar la epicidad de este juego.
Subido a Youtube por BladeVeemon612.

01 enero 2014

El Gobierno congela el salario mínimo, éste apenas ha crecido 14€ en 4 años


Programa Caiga Quien Caiga (La Sexta), Diciembre de 2008.
Entonces los políticos desconocían el salario mínimo de los ciudadanos.
Seis años más tarde el SMI apenas ha crecido en 53€.

El Gobierno ha decidido congelar el salario mínimo por segunda vez desde que éste existe. En ambas ocasiones, éste fue congelado por el Gobierno popular de Mariano Rajoy. Esta medida entra en contradicción con los numerosos mensajes del ejecutivo, donde defiende a los cuatro vientos la existencia de una recuperación económica en España. Con todo ello, el salario mínimo apenas se ha incrementado en 14 euros en 4 años.

Evolución del salario mínimo (bruto, 12 pagas):
- 2014 - 753€
- 2013 - 753€
- 2012 - 748€
- 2011 - 748€
- 2010 - 739€