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:

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:

(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.

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.

Para empezar, hay que crear un fichero de prioridades y asignar más prioridad a Jaunty (Ubuntu 9.04) que a Karmic (Ubuntu 9.10). Esto lo hacemos creando, como root, el fichero /etc/apt/preferences con el siguiente contenido:

Package: *
Pin: release a=jaunty
Pin-Priority: 700
Package: *
Pin: release a=karmic
Pin-Priority: 100

Actualización: he cambiado la prioridad de  Karmic de 600 a 100 para evitar actualizaciones accidentales.

A continuación, editamos como root el fichero /etc/apt/sources.list y añadimos la siguiente entrada:

deb http://archive.ubuntu.com/ubuntu/ karmic main restricted

Tras ello, actualizamos la lista de paquetes ejecutando en un terminal el comando:

sudo apt-get update

Y, finalmente, instalamos los paquetes que necesitamos con:

sudo apt-get install -t karmic  nvidia-180-kernel-source  linux-image-2.6.30-4-generic  linux-headers-2.6.30-4-generic

Y con ésto ya tendremos nuestro portátil plenamente funcional.

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!

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…

Acceder a estos servicios desde Linux parecía tan sencillo como abrir Lugares->Red y navegar gracias a SAMBA; pero, como de costumbre, las cosas nunca son tan sencillas. En efecto, el firewall que utilizo no me dejaba acceder, así que tras rebuscar en Internet encontré que tenía que abrir los puertos 135, 137, 138, 139 y 445. Me parecía extraño que, queriendo trabajar sólo como cliente (sin compartir yo nada) tuviese que abrir puertos, pero de todas formas lo probé. El resultado: ni con esas funcionaba, aunque si quitaba el firewall entonces iba como la seda.

Bastante mosqueado volví a buscar en Internet, pero no encontré absolutamente nada, así que me armé de paciencia y de Wireshark y empecé a ver qué demonios pasaba con los paquetes. Así fue como descubrí que el problema estaba en la resolución de nombres. En efecto, cuando un recurso no está en el DNS (un servidor, una impresora), SAMBA utiliza su propio servicio para descubrir su dirección IP, para lo que envía una petición UDP a toda la red usando la dirección de broadcast. El problema es que la respuesta no viene de la dirección de broadcast, sino de un equipo concreto (el buscado), por lo que el firewall la bloquea.

Pensando que era un bug del módulo ip_conntrack escribí a los desarrolladores para avisarles. Su respuesta, sin embargo, fue que cargase el módulo nf_conntrack_netbios_ns. Y efectivamente, con dicho módulo, y sin necesidad de abrir ningún puerto, todo ha funcionado perfectamente.

Me harté de buscar en google y en todas partes decían lo mismo: si tenía los w32codecs instalados debería poder reproducir archivos .rm sin problemas. Pero a la vez mucha gente se quejaba de que los tenía instalados y ni con esas (como era mi caso).

Los volví a bajar de la página oficial, probé con otros reproductores… y nada. Al final ya me veía resignado a utilizar el RealPlayer para Linux, pero su interfaz me tiraba para atrás. Hasta que echando un vistazo a la salida de Mplayer encontré un mensajito de error en el que no había reparado antes:

 Error: libstdc++.so.5: cannot open shared object file: No such file or directory

Y efectivamente: un simple sudo apt-get install libstdc++5 resolvió el problema.

Por si le sirve a alguien más.