Archivo de la categoría: Trucos

Trucos generales para distribuciones

Instalando Eclipse Indigo en Ubuntu (u otro Linux)

Actualizado Ha salido la versión 3.7 (Indigo) del famoso IDE Eclipse. Por desgracia, todavía no está disponible como fichero .deb para Ubuntu, así que vamos a instalarlo «a mano».

Lo primero, desinstalar cualquier versión anterior de Eclipse.

A continuación, bajarse la versión correspondiente (32 o 64 bits) desde la página de descargas de Eclipse. Yo he instalado la edición Classic. Lo descomprimimos (como root, obviamente) en /opt/eclipse.

Instalamos la máquina virtual de Java, si es que todavía no la tenemos: sudo apt-get install openjdk-6-jre

Creamos un fichero eclipse.desktop en /usr/share/applications o en ~/.local/share/applications con el siguiente contenido:

[Desktop Entry]
X-MultipleArgs=false
Type=Application
Name=Eclipse
GenericName=Eclipse IDE
TryExec=/opt/eclipse/eclipse
Exec=/opt/eclipse/eclipse
Categories=Development;
Icon=/opt/eclipse/icon.xpm

¡Y listo! Ya tenemos Eclipse Indigo en nuestro sistema y en nuestro menú de aplicaciones.

Instalando Windows desde un pen

Por una serie de circunstancias, este fin de semana necesité instalar un Windows XP en mi portátil, y una tarea tan aparentemente sencilla se convirtió en una tortura. ¿Por qué?

Lo que todo el mundo pensará es que basta con meter el CD en la unidad, reiniciar, y listo. Pero mi portátil es un EEE PC sin lector de CDs. Así que lo siguiente que se piensa es en utilizar un lector de CDs por USB… pero no tenía ninguno a mano, y no me apetecía comprar uno sólo para una vez.

Una opción era utilizar WinToFlash, una utilidad que permite meter el instalador en un pendrive; por desgracia sólo funciona en Windows… y no tengo ningún windows a mano. Incluso intenté hacerlo desde una máquina virtual, pero no funciona: es muy exigente y quiere un pincho «de verdad», no le sirve un disco duro, y la emulación de pinchos USB en KVM da problemas (ya ni hablemos de VirtualBox…).

También intenté utilizar UnetBootin, que está disponible para Linux, pero desgraciadamente no sirve para el instalador de XP.

Sin embargo, a tozudo no me gana nadie, y al final conseguí instalarlo con mucha paciencia, así que aquí está el método, por si a alguien más le puede ser de utilidad.

Lo primero, avisar que el proceso de instalación será mucho más lento de lo normal, así que tomadlo con mucha paciencia y una buena infusión.

Ingredientes necesarios:

Lo primero, copiamos cualquier dato importante que tengamos en nuestro pincho USB a otro lado, porque vamos a tener que formatearlo.

Antes de comenzar la instalación, necesitamos disponer de una partición primaria reservada para el nuevo disco. En caso de que no la tengamos, la mejor opción consiste en crear, mediante UnetBootin, un pincho USB de Ubuntu, arrancar con ella el portátil y utilizar GParted para reducir el tamaño de una de las particiones actuales y dejar sitio para la nueva. Sobre como hacer esto hay  abundante material en Internet, así que no profundizaré.

Cuando ya tengamos una partición primaria en el disco, etiquetada con sistema de archivos FAT32 (importante) y situada antes que cualquier otra partición primaria de tipo FAT en el disco, procedemos a particionar el pincho USB. Lanzamos GParted, borramos todas las particiones que hubiese, creamos una partición extendida, y dentro una unidad lógica, etiquetándola como de tipo FAT32.

Una vez hecho esto, arrancamos UnetBootin, escogemos la imagen de CD fdfullws.iso, y la volcamos en el pincho. Cuando esté listo, copiamos en el pincho todos los archivos del CD de instalación de Windows.

Ahora estamos listos para hacer la instalación de FreeDOS: reiniciamos el ordenador con el pincho, y cuando pregunte, iniciamos con HYMEM y EMM386. Nos saldrá un prompt de DOS, en el que teclearemos D:. Gracias a que el pincho tiene solamente una partición extendida, C: se corresponderá con la partición primaria del disco duro, y D: será el pincho en sí. Si hubiésemos utilizado una partición primaria en el pincho, como éste aparece como primer disco haría que C: fuese el pincho en sí, con lo que no podríamos instalar correctamente FreeDOS.

Ahora tecleamos setup para iniciar la instalación de FreeDOS. Instalamos todo (excepto las fuentes, que no son necesarias), y salimos de nuevo al prompt. Ahora copiamos también todo el CD de instalación de Windows al disco duro mediante xcopy:

    xcopy /E d:*.* c:

Ahora tenemos que asegurarnos de que podremos iniciar el sistema correctamente, para lo que tecleamos

    sys c:
    fdisk /mbr

El primero asegura de que el sistema de arranque de FreeDOS está instalado en C:; el segundo borra el MBR (lo que incluye a GRUB; luego lo recuperaremos) y pone en su lugar el código de arranque básico de DOS.

Reiniciamos el ordenador y debería arrancar FreeDOS. Ahora tecleamos:

    ./i386/winnt.exe

lo que lanzará el instalador de Windows XP. Nos dirá que la caché de disco no está instalada y que podemos cancelar el proceso. No lo haremos; eso sí, la copia de archivos se demorará durante un par de horas (y no sirve la caché que incluye el propio FreeDOS: no funciona). Nos tomaremos un buen café hasta que, por fin, termine de copiar los archivos básicos y reinicie, continuando, ahora sí, por fin, la instalación como siempre.

En determinado punto nos indicará que la unidad está en formato FAT32 y si queremos convertirla a NTFS. En teoría el cambio no supone la pérdida de los datos, pero por si acaso yo preferí hacer la conversión después de instalar todo, y, efectivamente, se puede hacer sin riesgo.

Recuperando GRUB

Ahora que ya está instalado Windows nos queda recuperar GRUB para poder arrancar de nuevo Linux. Para ello volvemos a particionar el pincho, dejando una única partición primaria, instalamos en ella un CD Live de Ubuntu u otra distribución preferida y arrancamos desde él.

Una vez hecho, abrimos un terminal y procedemos a montar la partición raíz de nuestro sistema Linux, así como enlazar los pseudo sistemas de archivos /proc, /dev y /sys. Finalmente, usamos chroot para entrar en nuestro viejo sistema. Si la partición raíz está en /dev/sda1 y tenemos el directorio /tmp disponible para montar en él lo que queramos, haríamos:

    mount /dev/sda1 /mnt
    mount -o bind /proc /mnt/proc
    mount -o bind /dev /mnt/dev
    mount -o bind /dev/pts /mnt/dev/pts
    mount -o bind /sys /mnt/sys
    sudo chroot /mnt /bin/bash

Ahora ya estamos dentro de nuestro sistema como root,  y podemos proceder a reinstalar GRUB. En Ubuntu es tan sencillo como

    dpkg-reconfigure grub-common

el cual reconfigurará GRUB para añadir automáticamente el nuevo windows instalado. En otras distribuciones de Linux es necesario utilizar un editor para modificar el fichero de configuración de GRUB y luego ejectuar grub-install /dev/sda para reinstalarlo en el MBR.

¡Y listo!

InkScape no tiene quien le escriba

Desde que actualicé a la última versión de Ubuntu, InkScape me estaba dando problemas a la hora de añadir tipografías: cada vez que intentaba escribir algo se negaba a cambiar a la fuente o tamaño que yo le decía, y me mostraba una alerta junto a la fuente, que siempre volvía, una y otra vez, a Bitstream Vera Sans, escogiese la que escogiese.

 

Tras rebuscar y rebuscar, encontré en un foro de Ubuntu que el problema es, precisamente, que dicha fuente (que es la que InkScape utiliza por defecto) no está instalada, y por un bug, no deja cambiar a ninguna otra.

La solución fue instalar el paquete ttf-bitstream-vera con un sencillo:

sudo apt-get install ttf-bitstream-vera

(aunque los que odien la línea de comandos pueden usar Synaptic, obviamente 😀 )

Entre signos anda el juego

Una de las frases preferidas de mi madre es Está el viejo muriendo, y está aprendiendo; y como en la gran mayoría de los refranes, hay una grandísima verdad oculta en ella.

Y es que estos días estoy peleándome con el micro ARM de un TomTom, y me encontraba con que el código que iba perfectamente en mi PC daba un fallo rarísimo en el GPS: al imprimir el carácter ‘/’ no lo hacía bien; pero sólo ese, el resto los renderizaba perfectamente. Después de mucho depurar, descubrí que el fallo era debido, nada menos, que al signo de una variable. Y es que, a pesar de utilizar el mismo compilador (GCC) para ambos casos, resulta que un char a secas en PC es signed, como todo el mundo asume, pero en ARM es unsigned, por lo que un valor que tenía que ser -1 se convertía en 255 (la segunda parte del problema es que luego operaba con ese valor y con otro de 32 bits, con lo que, al añadirle los 24 bits restantes, no expandía el bit de signo). Una vez añadido el modificador correspondiente, todo pasó a funcionar perfectamente.

Así pues, nunca deis por supuesto el signo de una variable. Consejo de amigo.

Desplazando bits

Hace mucho tiempo, cuando empecé a programar en C, leí una curiosa advertencia sobre los operadores de desplazamiento de bits, los famosos >> y <<. Se afirmaba allí que, al desplazar una variable con ellos, los bits que salían se perdían (lógico, siendo un desplazamiento), pero que los bits que entraban por el lado opuesto tenían un valor indefinido, que podía ser cero o uno según la implementación.

Es cierto que todos los programadores asumen que lo que entra es cero siempre; pero pese a todo, yo, que tiendo a ser demasiado cauto, opté por añadir siempre una máscara AND para poner a cero los bits entrantes y así evitarme sorpresas.

Sin embargo, hace unos días, mientras optimizaba unas rutinas que hacen uso de desplazamientos, decidí investigar más a fondo el tema, porque a fin de cuentas una máscara consume ciclos de reloj, así que si había alguna forma de evitarla siempre sería una mejora. Y lo que descubrí me dejó gratamente sorprendido, porque en realidad el valor de los bits que entran no depende del compilador, sino que está perfectamente definido en el estándar.

Cuando se utiliza el desplazamiento hacia la izquierda (<<), por el lado derecho siempre entran ceros. Ahí nunca hay problemas. Por otro lado, cuando se utiliza el desplazamiento hacia la derecha (>>) en una variable sin signo (por ejemplo, en un unsigned int), por la izquierda también entran siempre ceros.

Sin embargo, cuando utilizamos variables con signo (por ejemplo, short int) en un desplazamiento hacia la derecha, los bits que entren por la izquierda serán una copia del bit de mayor peso del valor original. Así, si teníamos un número negativo (su bit de mayor peso está a uno), al desplazarlo hacia la derecha seguirá siendo negativo, porque los bits entrantes serán unos; en cambio, si era un número positivo (su bit de mayor peso está a cero) los bits entrantes serán cero.

Supongo que la razón de hacerlo así es que, si se utilizan rotaciones para hacer divisiones, se conserva el signo.

Este código ilustra perfectamente lo dicho aquí:

#include <stdio.h>

void desplaza(unsigned int o) {

  signed int s1,s2;
  unsigned int u1,u2;

  s1=s2=u1=u2=o; // asignamos el mismo valor a las cuatro variables

  s1>>=4; // desplazamos cuatro veces cada una de ellas
  s2<<=4;
  u1>>=4;
  u2<<=4;

  printf("Con signo:ntdesplazamiento a la derecha   %08Xn",s1);
  printf("tdesplazamiento a la izquierda %08Xn",s2);
  printf("Sin signo:ntdesplazamiento a la derecha   %08Xn",u1);
  printf("tdesplazamiento a la izquierda %08Xnn",u2);
}

int main() {

  printf("nDesplazamiento de 4 posiciones.n");
  printf("Valor original: 0xA50000A5 (bit de mayor peso a uno).n");
  desplaza(0xA50000A5);
  printf("nValor original: 0x5A00005A (bit de mayor peso a cero).n");
  desplaza(0x5A00005A);

  return 0;
}

La salida es la siguiente, donde se aprecia claramente como el bit superior se replica en los desplazamientos a la derecha de las variables con signo, pero no en el resto de los casos:

Desplazamiento de 4 posiciones.
Valor original: 0xA50000A5 (bit de mayor peso a uno).
Con signo:
  desplazamiento a la derecha   FA50000A
  desplazamiento a la izquierda 50000A50
Sin signo:
  desplazamiento a la derecha   0A50000A
  desplazamiento a la izquierda 50000A50

Valor original: 0x5A00005A (bit de mayor peso a cero).
Con signo:
  desplazamiento a la derecha   05A00005
  desplazamiento a la izquierda A00005A0
Sin signo:
  desplazamiento a la derecha   05A00005
  desplazamiento a la izquierda A00005A0

Recuperar el applet de sonido en Ubuntu 10.04

Cuando actualicé mi sistema a la nueva Ubuntu 10.04, ocurrió un detalle bastante molesto: el applet de sonido desapareció. Ni rastro. Probé a añadirlo desde la lista de applets y nada, no existía. Busqué con APT, instalé paquetes, y tampoco. Hasta que, finalmente, descubrí como recuperarlo.

Lo primero que necesitamos para que funcione el applet de sonido es tener en nuestra barra de tareas un área de notificación. Esta tiene esta forma:

area de notificacion de gnome

Aquí vemos el área de notificación (que, en realidad está delimitada por esas tres rayitas de la izquierda), mostrando además el icono de conexión de red. Si no tenemos un área de notificación, basta con pulsar con el botón derecho en la barra, seleccionar Añadir al panel, hacer doble click en Area de notificación, y listo.

Si ya os aparece el icono de un altavoz, ya está todo hecho; pero si, como en la imagen de arriba, no aparece, eso es que os falta el applet en sí, en concreto el gnome-volume-control-applet. Dicho programa viene en el paquete gnome-media. Sin embargo, no es un applet a la antigua usanza, sino que es un demonio que utiliza el área de notificación para mostrarse. Si ya instalasteis el paquete y, desde una linea de comandos lanzáis dicho applet (con gnome-volume-control-applet & para que, al hacer un exit del terminal, siga en marcha), veréis que por fin aparece en control de volumen. Pero esa solución sólo sirve para esta sesión, y tan pronto se reinicie el equipo habrá que volver a lanzarlo. Para resolverlo vamos a hacer que se lance automáticamente cada vez que entremos en gnome. Vamos a Sistema -> Preferencias -> Aplicaciones al inicio, pulsamos Añadir, y rellenamos los campos con estos valores:

añadir un programa de inicio a Gnome

(obviamente, en el campo Orden hay que poner gnome-volume-control-applet; ahí está recortado). Una vez hecho esto, siempre que iniciemos tendremos, por fin, el applet del control de volumen, así de hermosote él.

Area de notificacion de gnome con control de volumen

El koala kármico

Hace unos días ya que salió la nueva Ubuntu 9.10, Karmic Koala, y hay que reconocer que no supone un cambio muy agresivo con respecto a la versión anterior, por lo que podría decir que ni me gusta ni me disgusta.

Bueno, miento; sí hay un detalle que no me gusta nada: los iconos de los botones y del menú de sistema han desaparecido por completo. Al principio pensé que era un bug en PyGTK, porque en DeVeDe no mostraba ya los iconos en los botones de Añadir, Eliminar, Arriba… Sólo lo mostraba en Previsualización porque lo había puesto «a mano», al no haber un botón de stock adecuado. Sin embargo, luego descubrí que, por alguna extraña razón, en el nuevo Gnome 2.28 se han desactivado por defecto dichos iconos. La verdad es que no me gusta la idea, porque creo que combinar un icono con un texto ayuda a hacer las aplicaciones más intuitivas.

Afortunadamente es muy sencillo dejar todo como estaba; basta con abrir un terminal, escribir gconf-editor (seguido de la tecla Return), ir a / -> desktop -> gnome -> interface y activar las dos claves siguientes:

Y listo, volveremos a tener iconos en el menú de sistema y en los botones de las aplicaciones.

Ubuntu y el Asus F5GL

Actualizado el fichero de prioridades. Finalmente conseguí hacer que el Asus F5GL de mi amigo funcione como es debido. Para ello, ha «bastado» con instalar la versión 9.04 (la actual estable) y añadir el núcleo de la versión 9.10, con el correspondiente sistema de pinning para que se actualice pero sin tocar nada del resto del sistema. Para los que tengan el mismo problema, explicaré cual es el proceso:

Seguir leyendo Ubuntu y el Asus F5GL

Al rico teclado de piña para el niño y la niña

Actualizado. Si ya tuve una entrada sobre ratones, ahora le toca el turno al teclado. Y es que el de mi flamante Asus EEE PC tiene un detalle algo molesto. Véase la siguiente fotografía:

Resulta que la tecla Mayúsculas derecha está completamente a la derecha y es corta (en lugar de larga, como en los teclados normales), y la tecla Cursor arriba está justo a la izquierda. El resultado es que, cuando se teclea al tacto, es inevitable pulsar con el meñique el cursor cuando se quiere poner una mayúscula.

La solución a este problema es tan sencilla como intercambiar el funcionamiento de dichas teclas, lo cual es muy sencillo gracias a XModMap. Para hacerlo no tenemos más que usar el siguiente script:

#!/bin/bash

xmodmap -e "remove Shift = Shift_R"
xmodmap -e "keycode 62 = Up"
xmodmap -e "keycode 111 = Shift_R"
xmodmap -e "add Shift = Shift_R"
xset -r 111
xset r 62

Los cuatro comandos de XModMap se encargan de remapear los códigos de las teclas con las nuevas funciones deseadas. Luego usamos xset, primero para eliminar la autorrepetición de la nueva tecla Mayúsculas derecha, y luego para añadirla a la nueva tecla Cursor arriba. Es precisamente el hecho de  que la autorrepetición no se pueda controlar desde XModMap lo que obliga a utilizar un script en lugar de un fichero .Xmodmap, como cuando cambiamos los botones del ratón.

Grabamos el script en un lugar cómodo, le damos permisos de ejecución, y ¡voila! Problema resuelto.

O quizás no, porque cada vez que arrancamos el ordenador tendríamos que ejecutar a mano este script para intercambiar las teclas. Lo interesante sería, sin embargo, que se lanzase él solo cada vez que entrásemos en nuestra cuenta. Por fortuna es muy sencillo de hacer en Gnome (en KDE habrá otra manera igual de fácil, pero como no lo uso, no conozco los pasos. ACTUALIZACIÓN: según comenta CoskiBukowsky en los comentarios, se puede copiar el script en ~/.kde/Autostart): basta con ir a Sistema -> Preferencias -> Sesiones y pulsar el botón Añadir, para añadir un nuevo script a ejecutar durante el arranque. Nos saldrá una ventana como ésta, en la que sólo debemos poner la ruta a nuestro script (que, en mi caso, se llama teclas.sh):

¡Y ahora sí, todo listo!

La nueva Ubuntu y mi viejo ratón

(Actualizado 2. Ver al final del artículo) Ayer actualicé mi sistema a la nueva Ubuntu 8.10 y me encontré con el primer problema: mi ratón empezó a funcionar correctamente.

Para explicarlo un poco mejor: mi ratón tiene un total de siete botones: los dos de siempre, el central en la rueda, y dos extra en el pulgar. La rueda, además, se puede mover a derecha e izquierda: dos botones más. Hasta ahora Ubuntu (o más concretamente, las X-Windows) no reconocían los botones extra, y los interpretaba como si fuesen el botón central, lo que para mí era muy cómodo. En efecto, si uso el botón central de la rueda para pegar texto o abrir un enlace de Firefox en una nueva pestaña, es raro que no se me mueva algo y acabe pinchando donde no quiero, problema que resuelvo usando el botón del pulgar.

Por desgracia la nueva versión utiliza HAL para detectar y gestionar el ratón, y éste sí reconoce los nuevos botones, con lo que el botón del pulgar ahora me lleva a la página anterior cada vez que lo pulso.

Por suerte el nuevo sistema también permite reconfigurar el sistema con más comodidad, y lo que es más interesante, sin necesidad de reiniciar las X, sino simplemente desenchufando y volviendo a enchufar el ratón. La manera es mediante unos ficheros XML (con extensión .fdi ) almacenados en /etc/hal/fdi/policy. Estos ficheros permiten modificar y personalizar completamente el funcionamiento de cualquier dispositivo, aunque la documentación es algo confusa.

Para los impacientes, la solución es tan simple como crear un fichero cualquiera en ese directorio (por ejemplo, /etc/hal/fdi/policy/mouse.fdi ) que contenga las siguientes lineas:

<device>
    <match key="info.capabilities" contains="input.mouse">
        <merge key="input.x11_options.ButtonMapping" type="string">1 2 3 4 5 6 7 2 2</merge>
    </match>
</device>

Para los que quieran personalizarlo más, la asignación de eventos es:

  1. Botón izquierdo
  2. Botón central
  3. Botón derecho
  4. Rueda arriba
  5. Rueda abajo
  6. Rueda izquierda
  7. Rueda derecha
  8. Página anterior (en un navegador)
  9. Página siguiente (en un navegador)

En el fichero anterior lo que hago es especificar que los eventos 8 y 9 deben responder como un evento 2, mientras que los demás permanecen inalterados.

Actualización: modifiqué el fichero FDI para que filtre los dispositivos, quedándose sólo con los ratones (tag match).

Actualización 2: Por desgracia la solución no sirve porque sólo funciona cuando primero se cargan las X y luego el módulo del ratón (por ejemplo, al desenchufarlo y volverlo a enchufar con las X ya cargadas). Cuando se arranca el ordenador desde cero, como se carga primero el módulo USB y luego las X, no hace nada.

La solución, al final, es más sencilla:

  • Se crea un fichero .Xmodmap en el directorio del usuario, que contenga la línea pointer = 1 8 3 4 5 6 7 2
  • Se sale de las X y se vuelve a entrar
  • Preguntará si se quiere utilizar un fichero Xmodmap, y mostrará la lista de los que ha encontrado (estará el que acabamos de crear)
  • Lo seleccionamos y lo añadimos a la lista de activos, y nos aseguramos de marcar la opción «No volver a preguntar».

Y con esto sí se resolverá el problema. El único defecto es que no se pueden repetir eventos, por lo que tuve que, simplemente, invertir los eventos 2 y 8, en lugar de asignar el 2 a todos los que me interesaba. Pero menos da una piedra…