En muchos sitios, podemos ver esta palabra clave, para muchos RESUIB para otros RESIUB y normalmente REISUB. Y sirve para reiniciar el sistema Linux de forma segura después de que el sistema se congele; de la siguiente forma: Alt+Imprimir Pantalla + R,E,I,S,U,B (no hace falta soltar las teclas Alt + Imprimir pantalla). Cada letra representa una acción del kernel:

• R (Devuelve el control al teclado unRaw)
• E (Termina todos los procesos tErm)
• I (Mata los procesos que queden vivos full kIll)
• S (Sincroniza los discos Sync)
• U (Monta todos los sistemas de archivos como sólo lectura Umount)
• B (Reinicia el ordenador Boot)

Bien, si tenemos acceso físico al ordenador, no hay problema, pero y si estamos enchufados en otra máquina ? Todo está en el fichero especial /proc/sysrq-trigger.

Obteniendo información de los procesos

Enviando a /proc/sysrq-trigger (como root) la letra correspondiente a la acción del kernel vale. Empezaremos pidiendo ayuda:

root $ echo “h” > /proc/sysrq-trigger

root $ dmesg | tail

…. # Nos dirá muchas cosas, sólo nos interesa la última línea
SysRq : HELP : loglevel0-8 reBoot tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw Sync showTasks Unmount shoW-blocked-tasks

Vemos cómo el kernel a través de dmesg se comunicará con nosotros. Cada letra mayúscula nos indicará una acción diferente, empezaremos obteniendo información sobre la memoria:

root $ echo “m” > /proc/sysrq-trigger

root $ dmesg | tail -n 35

O información sobre tareas bloqueadas:

root $ echo “m” > /proc/sysrq-trigger

root $ dmesg

Más acciones

Incluso podemos lanzar el OOM killer con la siguiente línea:

root $ echo “f” > /proc/sysrq-trigger

Terminar todos los procesos (igual que comentábamos arriba del todo):

root $ echo “e” > /proc/sysrq-trigger

Cambia el nivel de información de dmesg (del 0 al 8):

root $ echo 5 > /proc/sysrq-trigger

Para enviar un REISUB es algo más elaborado:

root $ nohup bash -c “for key in s u b; do echo \$key > /proc/sysrq-trigger; sleep 4; done”

Aunque tendremos que asegurarnos de que las tareas estén muertas, ya que, nuestra conexión ssh, o nuestro terminal, o incluso bash, se mueren al mandar un E o un I al kernel (dando igual el nohup). Por otra parte, la R la podemos quitar, ya que vale para devolver el control al teclado, y estamos desde un equipo remoto.

Seguridad

Pero tanto por nosotros mismos (debemos de protegernos de meter la pata), como los posibles usuarios del ordenador, tal vez no nos interese que puedan pulsar en teclado alguna combinación de teclas que comprometa al kernel. Para ello, tenemos  /proc/sys/kernel/sysrq o directamente el comando sysctl del cual modificamos la propiedad kernel.sysrq; lo haremos de la siguiente manera:

root $ sysctl kernel.sysrq=0 # Para desactivar Alt+SysRq

root $ sysctl kernel.sysrq=1 # Para activarlo

Se pueden activar algunos comandos sólo, dependiendo del número que se indique.

Voy a hablar de dos programas para crear macros, aunque hay más, claro que sí. Los dos programas están basados en la grabación de acciones del servidor X y la simulación de movimientos del ratón, clicks y acciones de teclado.

En principio xmacroplay; lo podemos ejecutar así:

$ xmacrorec2 > mi_macro

donde mi_macro es el archivo donde vamos a grabar; este archivo, si vemos su contenido tendrá los comandos en un lenguaje muy sencillo e inteligible, lo que nos permite crear macros directamente programándolos, no grabándolos.
Lo primero que debemos hacer tras ejecutar xmacrorec2 es pulsar una tecla, ésta tecla será la que deberemos pulsar para detener la grabación.

Para ejecutar las macros, lo podemos hacer de la siguiente forma:

$ xmacroplay :0 < mi_macro

donde :0 es la pantalla, el DISPLAY y mi_macro es el nombre de la macro.

Aunque, al menos en la versión 20000911, la última descargable desde sf.net (del año 2001, un poco antigua), se lleva un poco mal con los arrastres de ratón; vamos para hacer macros con clicks bien, pero cuando arrastramos algo, a veces no se reproducen bien las opciones. Se debe a un bug en xmacroplay.cpp, en las siguientes líneas dentro de la función eventLoop(), hay que añadir el código que tiene comentario

Con esta modificación todo debe ir bien, podemos, por ejemplo programar ciertas teclas en nuestro ordenador para automáticamente grabar y reproducir macros de teclado y ratón.

Aunque como dije antes, siempre podemos programar nosotros las macros a mano, o modificar lo que hemos grabado para un mejor comportamiento con los siguientes comandos:

• MotionNotify X Y : Mueve el rató a un punto X,Y de la pantalla
• ButtonPress N : Pulsa el botón N del ratón (1=izquierdo, 2=rerecho, 3=centro, 4,5=rueda del ratón en algunos sistemas, etc)
• Delay N : Retrasa el script N segundos, deteniendo su ejecución un tiempo
• ButtonRelease N : Suelta el botón N del ratón
• KeyCodePress C : Pulsa la tecla con el código C (podemos usar xev para ver los códigos de teclas)
• KeyCodeRelease C : Suelta la tecla con el código C
• KeyStrPress S : Pulsa la tecla llamada S (Es el nombre de forma de cadena de caracteres, por ejemplo “Escape”, “F5″, “Control_L”, etc; podemos utilizar xev para ver los nombres también)
• KeyStrRelease S : Suelta la tecla llamada S

Esto fue parte de un experimento que hice, se trata de conseguir que tras la ejecución de un comando la salida estándar del mismo se representara en color verde en mi terminal y la salida de error en color rojo (por supuesto podemos dejar sólo la salida de error en rojo), pero el hecho es demostrar que estos dos tipos de salida existen y hay forma de distinguirlas:

$ comando 2> >(while read line; do echo -e “\e[01;31m$line\e[0m”; done) 1> >(while read line; do echo -e “\e[01;32m$line\e[0m”; done)

En negrita está la redirección para la salida de error, y en cursiva la redirección para la salida estándar. La hemos hecho con códigos ANSI, y podemos encontrar una referencia de colores en: Colores y posicionamiento en terminales Linux (como conio.h en DOS)
.

Aunque como una referencia rápida incluiré: 31 rojo, 32 verde, 33 amarillo, 34 azul, 35 magenta, 36 cyan, 37 blanco. Y éste será el color a incluir en: echo -e “\e[01;32m$line\e[0m”;

A la hora de crear un hash para una contraseña, es conveniente no incluir sólo la contraseña, sino concatenar una cadena o un número más; lo mismo cuando generamos claves para que interaccionen aplicaciones en varios servidores; aunque hay veces en que, dados los pocos datos de que disponemos a la hora de generar la clave, no tenemos mucho donde elegir a la hora de crear el hash.

Por ese motivo se me ocurrió esta función en PHP, lo que hace es intercalar cadenas, es decir, tenemos dos cadenas, y queremos generar una cadena a partir de las dos anteriores, podemos coger un carácter de una, otro de otra, y así sucesivamente (como si estuviéramos barajando) hasta formar una cadena cuya longitud es la suma de las dos. Por ejemplo si tenemos las palabras “poesia” y “binaria“, resultaría la cadena: pboiensairaia .

Aunque, ya que vamos a hacer algo así, ¿ por qué limitarlo ? Hagamos una función que soporte una cantidad indeterminada de cadenas:

La cadena resultante de este ejemplo será: PBBGPSLoilaroienosofbsagpgtrirarweairaaamraecion.

Sobre todo si hacemos un upgrade desde la versión 2, en muchos sistemas, algo no termina de cuajar y puede causar que cuando abrimos un enlace con nuestro gestor de correo, éste no se abra en nuestro navegador preferido.
Podemos hacer dos cosas:

Definir la aplicación con la que abrir los enlaces

Esta es la opción clásica usada en Thunderbird 2 y no recuerdo bien si también en la primera versión. Tenemos que hacer lo siguiente: Editar/Preferencias/Avanzado/General/Editor de configuración (para usuarios de Windows será Herramientas en lugar de Editar) y ahí buscar network.protocol-handler.app.http, y definir su valor a /usr/bin/firefox-bin (por ejemplo, debe ser la ruta y el ejecutable de nuestro navegador). Hacer lo mismo con network.protocol-handler.app.https.

Podemos también definir una aplicación para ftp, por ejemplo.

Pedir que nos pregunte con qué programa abrirlo

Si no funciona lo anterior, este es el método nuevo de Thunderbird 3 y será una asociación de una aplicación al protocolo de otra forma nueva. Aunque vamos a dejar que Thunderbird actúe, sólo vamos a hacer que nos pregunte cómo abrir los enlaces. Para entrar, es lo mismo de antes: Editar/Preferencias/Avanzado/General/Editor de configuración y debemos definir el valor de network.protocol-handler.warn-external.http a true (hacer también con network.protocol-handler.warn-external.http). Como vemos en la captura de pantalla, podemos definir a true todos los valores que encontramos. De esta manera, Thunderbird nos preguntará la próxima vez que abramos un enlace con qué aplicación abrirlo.

Por otro lado, podremos modificar la aplicación con la que se abrirán, accediendo a Editar/Preferencias/Adjuntos y buscar http o https.

Es muy de 2002/2003, aunque todavía a muchos les gusta tener un pequeño terminal transparente en el fondo para ejecutar comandos o mostrar logs u otra información importante.

Aquí comentaré algunas soluciones que he encontrado y cómo obtenerlas.

xrootconsole

Es muy ligero y rápido. Y vale para mostrar logs en xroot; el fondo es supuestamente transparente, aunque si cambiamos el fondo veremos que no, ya que en la ventana de xrootconsole se mantendrá el fondo anterior. Está bien para hacer el apaño, pero no lo recomiendo. La forma de ejecutar xrootconsole es:

$ xrootconsole [fichero]

donde fichero es el que vamos a vigilar, la visualización se actualiza automáticamente con cada cambio que se observa en el archivo. Es ideal para ver /var/log/messages.

aterm

Muestra un terminal transparente, con muchas opciones, y que podemos ejecutar de la siguiente manera para mostrar las últimas líneas de dmesg en el escritorio:

$ aterm -fg black -geometry 100×10+0+0 -e watch –no-title -n10 -d ‘dmesg | tail’

donde:

Por supuesto podemos sustituir el comando que esta en negrita por lo que queramos mostrar.
Aún así, de esta forma aterm nos muestra decoración de ventana, barra de scroll y no es transparente. Esto lo podemos solucionar ejecutando aterm de la siguiente manera:

$ aterm -tr -bl -sb -fg black -geometry 100×10+0+0 -e watch –no-title -n10 -d ‘dmesg | tail’

O, editando el archivo $HOME/.Xdefaults y añadiendo estas líneas

aterm*transparent:true
aterm*borderLess:true
aterm*scrollBar:false

El problema de aterm es que no admite sombra en las letras, por lo que la lectura sobre algunos fondos es algo complicada.

Eterm

Este emulador de terminal es el más completo y tiene más opciones, y por lo menos es el que soporta poner sombra en las letras, lo que proporciona una mejor visibilidad, y es el que aparece en la captura de pantalla que hay arriba. Para ello, lo podemos ejecutar de la siguiente forma:

Eterm –buttonbar 0 –scrollbar off -f white -n dmessenger -g 211×10+0+0 -O -0 -e watch –no-title -n10 -d ‘dmesg | tail’

Aunque veremos un problema, la decoración de la ventana, para ello hay varias soluciones, dependiendo del sistema en el que trabajemos, para muchos, la solución será incluir el parámetro -x:

$ Eterm -x –buttonbar 0 –scrollbar off -f white -n dmessenger -g 211×10+0+0 -O -0 -e watch –no-title -n10 -d ‘dmesg | tail’

(en negrita aparece el comando, en cursiva un comando opcional), aunque a veces el entorno de ventanas, entre ellos Fluxbox, el que uso actualmente, no se lleva muy bien con ese modo sin decoración de ventanas, y aunque se muestra bien, la ventana aparece sobre todas las demás (on top).
Para solucionar eso, nos vamos a complicar un poco la vida. Para ello, editamos el archivo $HOME/.fluxbox/apps y añadimos las siguientes líneas:

[app] (name=dmessenger)
[Deco] {NONE}
[Sticky] {yes}
[Layer] {10}
[end]

Y a la hora de ejecutar Eterm lo hacemos de la siguiente manera:

Eterm –buttonbar 0 –scrollbar off -f white -n dmessenger -g 211×10+0+0 -O -0 -e watch –no-title -n10 -d ‘dmesg | tail’ & sleep 2 && wmctrl -r dmessenger -b add,skip_taskbar

donde ejecutamos Eterm en segundo plano (al terminar el comando con &) y ejecutamos un sleep 2 (para esperar 2 segundos antes de ejecutar el siguiente comando), a continuación ejecutamos wmctrl donde,

dmesg

En el ejemplo estamos ejecutando dmesg de la siguiente forma (con la ayuda de watch):

watch –no-title -n10 -d ‘dmesg | tail’

donde,

Hace unas semanas estuve en el Curso Avanzado de GPU impartido por el Dr. Manuel Ujaldón en la Universidad de Málaga; y me parece interesante compartir algunas conclusiones y un poco de investigación sobre el tema con todos ustedes.

Una arquitectura diferente

Disponemos de un chip con gran capacidad de procesamiento, pero a su estilo. Aunque originalmente está diseñado para su uso en juegos, recientemente (no tan recientemente porque el primer uso de GPU (Graphics Processing Unit, o Unidad de Procesamiento Gráfico) para propósito general fue en el 1997, lo que sí es más reciente es la implicación de empresas en este tipo de sistemas) muchas personas están concienciadas en aprovechar sus capacidades, y es muy interesante ya que con poco dinero podemos compararnos en capacidad de procesamiento a algunos superordenadores, y es que en ciertas tareas de cálculo muy pesado que en procesadores CPU actuales tardan varios días, con procesamiento GPU y con un coste mucho menor podemos completarlas en pocos minutos.

Ya podríamos pensar que es el momento de prescindir de la CPU, pero ese momento aún no ha llegado, ya que la GPU puede ser muy buena en ciertas tareas relacionadas con el paralelismo, pero la CPU es buena con las sentencias de control y los saltos en el código.

Paralelismo en GPU

Las GPU actuales pueden tener 128, 256 ó 512 núcleos (frente a los 4 ó 6 núcleos de los actuales procesadores más avanzados). Es decir, podemos tener 512 hilos corriendo concurrentemente en GPU. Si estamos acostumbrados a utilizar pthreads, vemos cómo tenemos que programar el hilo y crearlos, y si tenemos 512 núcleos deberíamos crear los 512 hilos; el problema y la solución vienen, en la programación GPU, en que todos los núcleos ejecutarán el mismo código, y cada hilo tendrá una serie de identificadores que nos indicarán qué procesador está funcionando. Por tanto podemos lanzar 512 tareas simultáneas y cada una será lanzada por un núcleo diferente. Si, por ejemplo queremos sumar un vector de 512 elementos con otro, en CPU, realizamos una operación cada vez (hasta 512 operaciones), en GPU lanzaremos las 512 a la vez, y terminarán en el tiempo de una operación (más o menos y a grosso modo)

Velocidad de acceso

Las tarjetas gráficas, por lo general, tienen una memorial RAM, unas cuántas generaciones por delante (mientras en CPU vamos por DDR3, las gráficas ya usan DDR5). La principal razón es que esta memoria está soldada en la plata y precisamente, muy cerca de la GPU, y además, el controlador de memoria está integrado en GPU, lo que facilita las transacciones. Por esto y mucho más, una lectura o escritura en la memoria de la tarjeta gráfica consumirá pocos ciclos en GPU, mientras que los accesos a memoria en CPU consumen muchos ciclos de reloj.
Con esto, tenemos una lectura/escritura en memoria mucho más rápida, y además, tenemos una memoria compartida, mucho más pequeña (de varios Kilobytes) que es mucho más rápida, y que nos permitirá una interacción más rápida. Es algo así como la caché de la CPU, pero en este caso es una memoria que sí podemos controlar (leer y escribir en esa memoria lo que queremos y cuando queremos, mientras que la caché de la CPU es automática).

Metodología de programación

El código que podemos utilizar se ejecuta en CPU, por tanto tenemos que programar la tarea que queremos que realice la GPU aparte (en una función, por ejemplo), ese será nuestro kernel. Justo antes de ejecutar nuestro kernel en GPU, debemos copiar los datos necesarios desde la RAM de nuestro sistema (host) a la memoria de nuestro sistema gráfico (device), tras ello ejecutar el kernel, y luego volver a copiar los datos obtenidos desde el device al host.
Sólo podemos ejecutar un kernel a la vez; éste se ejecutará en todos los núcleos a la vez, y es nuestro trabajo hacer que merezca la pena, si dejaos núcleos sin usar, es potencia que no estamos aprovechando.
Por otra parte, tenemos que conseguir que la realización de las tareas en GPU merezca la pena, ya que:

T_copia_H2D + Procesamiento GPU + T_copia_D2H < Procesamiento CPU

Es decir, el tiempo que tardamos en copiar los datos, primero desde el host al device y luego desde el device al host, más el tiempo que tarde el procesamiento en GPU tiene que ser menor que el tiempo que tarde el procesamiento en CPU, si no, todo esto no merecería la pena.

Dada la naturaleza de los kernels, y que todos los procesadores tienen que ir sincronizados, ejecutando la tarea encomendada, lo óptimo es que estos sean lo más pequeños posible y que tengan el menor número de decisiones posible (un if … else, implica que si la condición se cumple en un conjunto de núcleos, al ir todos los procesadores a la par, mientras unos núcleos procesan, otros pierden tiempo).

¿Cómo empezamos?

Aunque tenemos varias posibilidades, siempre podemos programar en ensamblador, específico a cada modelo de Chip, pero tal y como ocurre en CPU, van surgiendo lenguajes y sistemas que nos permiten generalizar nuestro código y poder ejecutarlo en una amplia gama de Chips (sí, se pierde un poco de rendimiento, pero perderíamos mucho tiempo haciéndolo así, por tanto es un coste que podemos permitirnos). Actualmente hay dos sistemas que podemos utilizar: CUDA (sólo para tarjetas nVidia, a partir de la serie y OpenCL desarrollado por Apple y propuesto al grupo Khronos para ser un estándar de programación GPU libre del control de una empresa y compatible con una amplia gama de chips gráficos y que tanto nVidia, como ATI, y otros muchos fabricantes de chips gráficos.

Lectura recomendada

Giz Explains: GPGPU Computing
Wikipedia: Unidad de Procesamiento Gráfico

Hace unos días que estoy probando Keepnote, y me está convenciendo. Es un gestor de notas personales multiplataforma (Linux, Mac, Windows), escrito en Python.
Hasta ahora estaba trabajando con Kjots (sobre KDE3); aunque este tiene bastantes opciones como la organización de Libros, búsquedas en todas las páginas de un libro, copia de seguridad, permite adjuntar archivos y capturas de pantalla, así como insertar estilos a las notas.
Por otra parte, nos permite organizar los libros en pestañas y tiene una papelera donde insertamos los elementos eliminados y además… extensiones (aunque no hay muchas todavía, pero el sistema lo permite, esperemos que en poco tiempo haya más).

Si estás buscando un software para gestionar tus notas, prueba Keepnote.

Más info: KeepNote : Note Taking and Organization

¡ Hace unas horas publiqué mi tweet 1024 ! Aprovecho este momento para poner mi dirección de Twitter por aquí: blakeyed. Quise poner alguna frase de alguien especial, relacionado con el mundo de la informática, y escogí una frase de Alan Turing:

Sólo podemos ver poco del futuro, pero lo suficiente para darnos cuenta de que hay mucho que hacer.

Aunque seguro que ha sido pronunciada por muchas personalidades a lo largo de la historia.

Si usamos frecuentemente un archivo .netrc para almacenar nombres de usuario y contraseñas para servidores FTP, tal vez queramos utilizar esas mismas contraseñas para Konqueror sin necesidad de volver a escribirlas, ni almacenarlas en Kwallet (ya están en un sitio, ¿para qué meterlas en más lugares?). O tal vez se nos presente el siguiente problema, tenemos que conectar con un servidor FTP que permite conexiones anónimas, y al mismo tiempo el nombre de usuario (o la contraseña) que tenemos contiene el carácter arroba (@), tendríamos que meterlo en la barra de direcciones y al menos en KDE3.5.10 no nos deja hacerlo (no lo he probado en kde4), y la única forma rápida que se me ocurrió fue a través de .netrc.

Bien, si vamos a crear un archivo .netrc de primeras, leer esto, es un post de un proyecto que utilizaba .netrc para conectar donde se explica qué tiene que contener el archivo.

Luego editamos el archivo $HOME/.kde/share/config/kio_ftprc (si no existe lo creamos), por ejemplo con nano:

$ nano ~/.kde/share/config/kio_ftprc

e introducimos la siguiente línea:

EnableAutoLogin=true

Lo más fácil ahora es reiniciar KDE, pero yo opté por ejecutar lo siguiente:

$ dcopserver_shutdown
$ dcopserver

Como véis estoy utilizando dcop, esta solución es para KDE3, aunque supongo que para KDE4 habrá alguna solución sin usar dbus. Por otra parte, en mi sistema no uso KDE como gestor de ventanas, sólo utilizo algunas aplicaciones de KDE, por lo que no garantizo que se reinicie el gestor de ventanas.

Con esta solución, desde Konqueror pude abrir un FTP cuyo nombre de usuario contenía una arroba