Arreglo -temporal- de la regresión de Intel Sandy Bridge

Algunos usuarios de chipsets Intel (montados en placas bases para Core Duo, i3, i5, e i7) hemos sufrido desde hace un año este problema que hace que nuestras baterías lleguen a durar la mitad en los peores casos. Problema causado por los drivers que intel ha incluído en el kernel Linux desde la versión 2.6.38.

Adnan Hodzic, de OMG Ubuntu, ha encontrado una solución temporal que hará que tu batería dure más tiempo: añadir dos opciones al grub pcie_aspm=force y i915.i915_enable_rc6=1.

Siempre que se trata de configurar el grub2 en Ubuntu, y aunque es sencillo hacerlo modificando los archivos a mano, yo recomiendo grub-customizer, para instarlo en Ubuntu basta con añadir el ppa ejecutando desde consola:

sudo add-apt-repository ppa:danielrichter2007/grub-customizer
sudo apt-get update
sudo apt-get install grub-customizer

Para otras distribuciones, Daniel Ritcher, el autor, ha publicado un tutorial en el mismo launchpad.
Ahora solo toca ejecutarlo (está en la sección Sistema como Grub Customizer), pedirá la contraseña de administración, y una vez abierto, ir a preferencias.

Añadir pcie_aspm=force i915.i915_enable_rc6=1 a la lista de parámetros del kernel.

Y guardar los cambios (que actualizará el grub).

Rápido y fácil. Me gustaría que me contarais si os ha funcionado en los comentarios, pero como mi número de lectores tiende a cero, tampoco voy a hacerme muchas ilusiones .

Un saludo.

Créditos: a Adnan Hodzic de OMG Ubuntu por encontrar esta solución y a Daniel Ritcher por su estupendo Grub Customizer.

Ubuntu desde USB no reconocido por algunas BIOS, Unetbootin paso a paso

Algo básico a día de hoy, cuando ya muchos ordenadores carecen de lector óptico o no queremos pagar el impuesto revolucionario a la pútrida SGAE, es el instalar nuestra distribución de linux favorita desde un lápiz USB.

El problema

En algunos ordenadores no funciona el USB generado por usb-creator-gtk, el "Creador de discos de arranque" que Ubuntu usa por defecto, en ellos la BIOS se niega a arrancar desde dicho USB. De hecho me ha sucedido en dos de tres portátiles en los que he instalado: un Asus M50SV y un Samsung NP-R530.

La solución

Existe otro generador de discos de arranque con, digámoslo así, mucha más experiencia: Unetbootin, está en el repositorio universe de Ubuntu, y puedes instalarlo desde tu gestor de paquetes favorito o tecleando en consola:

sudo apt-get install unetbootin

Unetbootin no te aparecerá en el menú (no han incluido en fichero .desktop correspondiente), de modo que para lanzarlo deberemos recurrir al terminal:

 unetbootin

Te preguntará tu contraseña de administrador y te mostrará una ventana como esta.

Como podéis comprobar, es bastante sencillo de usar (es muy parecido a usb-creator-gtk), pero además nos permitirá descargar la imagen iso correspondiente desde el mismo programa pudiendo elegir entre muchas de las distribuciones más populares, o elegir alguno que hayamos descargado previamente seleccionándolo desde nuestro disco duro.

Crear usb paso a paso con Unetbootin

El primer paso es descargar la imagen iso correspondiente, porque aunque Unetbootin nos permita descargarlo automáticamente en el acto, yo soy de los que prefieren hacerlo a mano y guardar la imagen a buen recaudo, podéis descargar Ubuntu desde su página de descargas, así como Xubuntu (ubuntu con xfce, más sencillo de usar y que yo encuentro más estable) o Kubuntu (con KDE). Hay más derivados, pero citarlos todos no es la finalidad de este post.

Ahora toca formatear el pendrive porque, desgraciadamente, Unetbootin no lo hace automáticamente.

Advertencia: tened mucho cuidado al formatear, y fijaos bien qué disco es el que estáis formateando, podríais perder todos vuestros archivos y documentos en un desliz. Repito, tened mucho cuidado al formatear, si tenéis alguna duda, preguntar por ahí, siempre es mejor preguntar antes de cometer una fatal estupidez.

La forma más fácil de hacerlo es con gparted, el gestor de particiones. Para instalarlo, nuevamente con tu gestor de paquetes favorito o desde consola:

sudo apt-get install gparted

Lo podrás encontrar en el menú de aplicaciones, en la sección de sistema, o puedes lanzarlo desde terminal:

sudo gparted

Elegimos el disco USB en el desplegable.

Comprobad que habéis seleccionado efectivamente el USB: normalmente debería haber una sola partición en el disco, o ninguna si el pendrive es nuevo, y comprobad también el espacio del mismo. Si os equivocáis de disco. podrías estar borrando el disco duro de vuestro ordenador. Así que andad con pies de plomo.

Si el disco USB ya tiene una partición, y ésta ya es FAT32, podéis cerrar el gparted y saltaros todo esto del formateo si queréis, abrir el USB con el navegador de archivos y borrar el contenido a mano hasta tener 670 700 MiB de espacio. Si aún así queréis formatear la partición debéis desmontarla primero, usando el menú contextual (botón derecho del ratón):

Ahora usad el botón secundario del ratón sobre la primera opción de la lista de particiones y, en el caso de que no haya ninguna partición creada, seleccionáis "Nueva" y en la ventana emergente seleccionáis FAT32 como sistema de archivos. Si por el contrario ya hay una partición basta con seleccionar Formatear como y FAT32:

Ahora, comprobad que en la lista de operaciones pendientes (la nueva sección bajo lista de particiones) aparece lo que hemos hecho. Si no es así, usad la opción de deshacer del menú editar. Una ves hayamos terminado, aplicaremos los cambios y gparted formateará el disco USB:

Ahora toca arrancar Unetbootin, desde consola:

unetbootin

Seleccionais como imagen de disco (en la captura, DiscoImagen) la imagen iso que os habéis bajado, seleccionáis como tipo "Unidad USB" y la seleccionáis el disco USB (la ruta será la misma que la que tuvisteis que seleccionar en el desplegable gparted para formatear), una vez hecho esto, sólo toca aceptar y esperar a que Unetbootin haga todo el trabajo:

Espero que os haya servido, sinceramente, conocer el grave problema de compatibilidad en el arranque de usb-creator-gtk frente a Unetbootin me hubiera evitado más de un dolor de cabeza.

Ubuntu 10.04, agosto de 2010, Mplayer ha muerto

Yo tan feliz, listo para ver mi ración diaria de porno series sin molestos anuncios, y me encuentro que mplayer no funciona y suelta lo siguiente por stderr:

mplayer: relocation error: mplayer: symbol codec_wav_tags, version LIBAVFORMAT_52 not defined in file libavformat.so.52 with link time reference

Y claro, esos inteligentísimos señores empaquetadores de Ubuntu han actualizado el libac, haciendo que el imprescindible mplayer muera instantáneamente de viejo. Alguna cabeza pensante ya ha corregido el bug, pero por razones que desconozco no ha aparecido en los repositorios, y todo hace temer que, como de costumbre, vengan a solucionarlo en la próxima versión de la distribución.

Pero para variar, despierto de mi letargo veraniego para salvaros.
Todo desde consola, añadid el repositorio de rvm (un alma caritativa) en launchpad:

sudo add-apt-repository ppa:rvm/mplayer

Y actualizad:

sudo apt-get update&&sudo apt-get dist-upgrade

Se actualizará mplayer (y mencoder si lo tenéis instalado) a una versión más reciente.

Boot time!

Sin bilis¹: tiempos de arranque de los dos últimos hasefroch (aunque en realidad sean el mismo²) y las dos últimas versiones de Ubuntu.

1. La entradilla que escribí en primer momento no era tan condescendiente
2. Mismo núcleo, mismos drivers en el 99.9% de los casos, mismo diseño, mismas capas de DRM, mismo gestor de ventanas (con algunos errores menos, eso sí)... y sigue fallando como una escopeta de feria en cuanto a seguridad informática.

Créditos
Vía GULIC y TuxRadar.

Arreglar permisos de interfaces de CUPS (ubuntu 9.04)

A algún "genio" empaquetador de ubuntu se le ha ocurrido restringir todos los permisos de los backends (interfaces) que el mismo CUPS (el servidor de impresión) necesita para poder comunicarse con la impresora, lo que en palabras llanas significa: Mi impresora no funciona porque algún listillo la ha cagado.

El error se manifiesta con un discreto mensaje de error:

Unable to open device “hal:///org/freedesktop/Hal/devices/[...]”: Permission denied

Para arreglar el desaguisado tenéis que usar la consola:

sudo chmod 700 /usr/lib/cups/backend/*

Con esto asignaremos los permisos necesarios a todos los backends disponibles. Existen otras opciones, pero ni las he encontrado, ni creo que sean tan sencillas.

Créditos:

• A Lars, de plasticboy.de, por su artículo explicando cómo hacerlo para el backend usb.

PC City también cae

Y esta vez con pegatina de Ubuntu y todo, pero sin pantalla. Una cosa más, los tres años de garantía sólo cuesta 90€ menos que el equipo completo. Aunque en la web no dice nada del sistema operativo.

Ahora que lo pienso, extrapolando las burradas que sufrimos los linuxeros cuando nos libramos del SO preinstalado ¿Instalarle WinXP anulará la garantía?

Hasta aquí el minipost semanal. Un saludo y feliz pastafaridad.

Créditos:

• A la espontánea que esta vez no quiso presumir de mano en la foto.
• A Nokia, por dotar al N70 de una cámara emborrona-fotos a distancias cortas (saqué 7, y 6 borrosas).

La frase:

No es que el Linux sea más barato en sí, lo cierto es que se gestiona mejor.

(Lawrence J Ellison)

Bug de Wammu en Ubuntu Hardy

Otro de los insistentes bug con los que la gallina caponata, más que una grulla resistente (o Hardy Heron), nos viene sorprendiendo, es el que impide la ejecución de éste popular programa para gestionar dispositivos móviles tales como teléfonos o PDAs soportadas.

El fallo en cuestión se da cuando se inicia Wammu (y presumiblemente otras aplicaciones que utilizen python y wxWidgets):

'import site' failed; use -v for traceback
Traceback (most recent call last):
File "/usr/bin/wammu", line 77, in
import Wammu.App
File "/usr/lib/

python2.5/site-packages/Wammu/App.py", line 25, in
import wx
ImportError: No module named wx

En la última línea se ve que no puede importar la librería de wxWidgets para python, python-wxgtk2.6 o python-wxgtk2.8, debido a un error por parte de los empaquetadores de Ubuntu, la solución pasa por eliminar un supuesto enlace simbólico a la librería en cuestión mal hecho (el que viene por defecto) y hacer nosotros uno que funcione (nada difícil por otro lado):

sudo rm /etc/alternatives/wx.pth
sudo ln /usr/lib/python2.5/site-packages/wx.pth /etc/alternatives/wx.pth

Como vemos, es un error muy tonto, pero visto como andan las cosas respecto a la corrección de bugs en Ubuntu Hardy Heron, yo no esperaría a que la gente de Canonical lo arreglara en un período razonable de tiempo, ni siquiera en uno no tan razonable...

Un saludo.

PD. A lo mejor me equivoco, dejan de aparecerme actualizaciones de paquetes inútiles día tras día, y aparece algún bug corregido. Pero lo dudo mucho.

Créditos:

• A hiperair por encontrar la solución.
• La captura de Wammu es de http://wammu.eu, su web oficial.
  

La historia de nunca acabar...

De entrada, y preludio a esta entrada, he de aclarar que soy un tipo muy consecuente, con lo que hago, digo y opino, y muchas veces exigo que los demás se comporten igual (ya, cómo si no supiera en qué mundo vivo...), y precisamente cosas como las que os voy a contar hacen que me hierva la sangre:

Programando un "poco mucho" con Python (mi lenguaje de programación predilecto) y pygtk (librerías gráficas de gtk para python) me topé con un error con libxcb hace semanas, buscando un poco de información (y tras mucho tiempo intentando buscar algún error en mi código) me di cuenta que no era cosa mía: la gente de x.org había metido la pata, y hasta el fondo: Un componente fundamental para la gestión de threads (hilos de procesamiento que siguen los programas para hacer cosas simultáneamente) funcionaba rematadamente mal, por no decir que directamente no funcionaba.

Tan grave es este error, que ni el OpenOffice.org (con sus paquetes de integración con el escritorio Gnome), ni la mayoría de aplicaciones en java funcionan (ni tan siquiera arrancan), y el resto, directamete dejan de funcionar esporádicamente (grupo dentro del cual integro mi pequeño e inconcluso programa) cerrándose inmediatamente y dejando tan sólo un mensaje de error que reza así:

../../src/xcb_lock.c:77: _XGetXCBBuffer: Afirmación `((int) ((xc
(dpy->request)) >= 0)' fallida. Aborted

El error, como se deduce, es exageradamente grave, ya que afecta a prácticamente todo lo que tenga que ver con el xserver, esto es, todas las aplicaciones que usan interfaz gráfica.

Hasta aquí, todo bien (nótese el sarcasmo que enmascara preocupación). La mayoría de las distribuciones, por ejemplo Debian Testing (a Debian Etch no le afecta por usar paquetes anteriores al error) ya han arreglado el problema, y a muchas otras directamente no le afectan, precisamente por haber encontrado el error y haber tomado medidas oportunas...

Y ahora el turno de Ubuntu:
La entrada en el Launchpad del error con 381 comentarios, un listado con los paquetes más importantes afectados, todos marcados como alta prioridad por ser aplicaciones básicas para el usuario corriente, Ubuntu 8.04 y 8.10 (en su muy temprana versión alpha) afectados, y todo ello desde el 23 de Enero de este mismo año, es decir: meses y meses después nadie desde Canonical ha hecho nada para remediarlo, y cuando digo nada de nada es absolutamente nada, total despreocupación, interés cero (como si de otra empresa, muy odiada por ello, se tratase).

La gente de x.org ya ha arreglado esa librería, a falta de publicar el parche con la próxima versión, y la gente de Debian, con la que Ubuntu comparte el 99'9% de su código ya lo ha arreglado (ni falta hace de decir que la solución no es ni secreta ni imposible).

De modo que la gente de Canonical se ha ganado un gran suspenso en éste caso, tal como hicieron en su día con el bug de los escáneres (achacado al núcleo Linux).

Si queríais saber porqué no he posteado, ya lo sabéis, he estado programando algo muy majo, que ésta gente me ha estropeado (no podré publicarlo para Ubuntu hasta que esta gente se digne en hacer algo). Estoy a un paso de pasarme del todo a OpenSuse (lo único que me retiene es la famosa lentitud del Yast). Además, la solucionarlo por mi mismo no arreglaría que miles de usuarios lo estén sufriendo y no puedan solucionarlo (puede que por desconocimiento), aunque bueno, si consigo hacer un apaño y arreglar el entuerto, lo publicaré en este mismo blog, además de hacer el correspondiente comentario en el launchpad.

Por cierto, si queréis saber como hacer funcionar OpenOffice.org mientras esta situación persiste, desinstalad los paquetes openoffice.org-gnome y openoffice.org-gtk, OpenOffice.org se verá francamente mal, pero al menos funcionará.

Iluminación de pantalla en Asus M50SV

EDITADO 5.01.2010: La ruta de las propiedades del dispositivo ha cambiado a partir de Ubuntu 9.10 (incluído), por lo que he añadido la nueva variación.

Tarde o temprano ocurriría: poner Ubuntu (el nuevo, Hardy) al nuevo portátil de mi padre, un Asus M50SV, y quitar el "sistema inoperativo" de fábrica (a petición suya). Una vez terminado, todo parece funcionar a la perfección (incluso la webcam con cheese), driver privativo Nvidia de por medio.

Hoy, cuando tocaba recibir el visto bueno, el dueño del portátil (mi padre) se dió cuenta de que la pantalla estaba demasiado oscura. Más concretamente el brillo (backlight) del la pantalla era muy débil para su gusto: busqué cómo modificar el brillo (no había forma de hacerlo con interfaz gráfica) y ninguno de los métodos típicos funcionaba; tardé en descubrir el porqué:
El brillo se autoajusta cuando es necesario pero lo estaba haciendo mal (realmente no, pero el cliente siempre tiene la razón).

Una vez sabido el problema, la solución pasa por desactivar el sensor, y ajustar el brillo manualmente, teniéndose que hacer como root (usar sudo parece no funcionar):

Para convertirse en root:

sudo su

Para desactivar el sensor:
(Ubuntu hasta 9.08)

echo 2 > /sys/devices/platform/asus-laptop/ls_switch

(Ubuntu 9.10 en adelante)

echo 2 > /sys/devices/platform/asus_laptop/ls_switch

(0 para desactivar y 1 para activar el sensor lumínico)
Para ajustar manualmente el brillo:
(Ubuntu hasta 9.08)

echo 5 > /sys/devices/platform/asus-laptop/ls_level

(Ubuntu 9.10 en adelante)

echo 5 > /sys/devices/platform/asus_laptop/ls_level

(el 5 es el nivel de intensidad, entre 0 y 15 ambos inclusive)
La siguiente receta evitará tener que ejecutar los comandos de arriba tras cada reinicio (esa configuración no se guarda) o cada vez que queramos cambiar el nivel.

Para tener una forma sencilla de ajustar el brillo de pantalla sin tener que usar comandos, usaremos zenity (que viene instalado por defecto en Ubuntu).
Creamos un archivo de configuración que guarde el brillo:

sudo su
echo 1 > /etc/brillo
exit

Creamos nuestro propio comando en /usr/bin:

sudo gedit /usr/bin/brillo
("brillo" es el nombre del comando de consola, si no te gusta, puedes elegir otro, pero tenlo en cuenta al seguir las instrucciones posteriores)

Que contenga lo siguiente:
(Ubuntu hasta 9.08)

#! /bin/bash
echo 2 > /sys/devices/platform/asus-laptop/ls_switch
export a=$(cat /sys/devices/platform/asus-laptop/ls_level)
export b=$(zenity --scale --text="Ajuste el brillo al nivel que desee" --min-value=0 --max-value=15 --value=$a --step=1 --title="Configuración del brillo")
echo $b > /sys/devices/platform/asus-laptop/ls_level
echo $b > /etc/brillo
echo "Brillo establecido a $b"

(Ubuntu 9.10 en adelante)

#! /bin/bash
echo 2 > /sys/devices/platform/asus_laptop/ls_switch
export a=$(cat /sys/devices/platform/asus_laptop/ls_level)
export b=$(zenity --scale --text="Ajuste el brillo al nivel que desee" --min-value=0 --max-value=15 --value=$a --step=1 --title="Configuración del brillo")
echo $b > /sys/devices/platform/asus_laptop/ls_level
echo $b > /etc/brillo
echo "Brillo establecido a $b"

Y guárdalo. Ese script hará que zenity muestre una barra de desplazamiento para establecer el brillo de la pantalla, y guardará el nivel establecido en /etc/brillo.
Ahora para poder ejecutarlo, debemos darle permisos de ejecución tal que así:

sudo chmod +x /usr/bin/brillo

El script debe ser ejecutado como superusuario (puedes lanzarlo ejecutando sudo brillo en la consola).
Modificar el rc.local para desactivar el sensor y poner el brillo determinado por el usuario (guardado en /etc/brillo) cuando se inicie el sistema.
Editamos el script de inicio local:

sudo gedit /etc/rc.local

Y ahora añadir estas tres líneas (no borres su contenido, simplemente agrégalo en las líneas previas al exit 0, que marca el final):
(Ubuntu hasta 9.08)

export a=$(cat /etc/brillo)
echo 2 > /sys/devices/platform/asus-laptop/ls_switch
echo $a > /sys/devices/platform/asus-laptop/ls_level

(Ubuntu 9.10 en adelante)

export a=$(cat /etc/brillo)
echo 2 > /sys/devices/platform/asus_laptop/ls_switch
echo $a > /sys/devices/platform/asus_laptop/ls_level

Parte opcional:
Crear un acceso directo en el menú (usando el editor de menú alacarte), que es lo que yo he hecho, o un lanzador en el panel, que llame al siguiente comando:

gksudo brillo

Si quieres añadir el enlace al menú sin usar alacarte (útil para los que usan Xfce, por ejemplo) puedes crear un archivo .desktop en ~/.local/share/applications que contenga, por ejemplo:

[Desktop Entry]
Encoding=UTF-8
Exec=gksudo brillo
Hidden=false
Name=Ajuste de brillo
Terminal=false
Type=Application

Aparecerá en la sección Otros, para cambiarlo hay que especificar el parámetro Categories en el .desktop, pero creo que no es imprescindible para el tutorial.

EDIT 14/05/08: He mejorado un poco los scripts, ahora recuerda el nivel de brillo tras los reinicios.

Créditos:

• Charlie Chuno de ubuntuforums.org por encontrar la solución.

ePSXe 1.6.0 en Ubuntu (y amd64)

EDITADO 22/27/2010 :Epsxe 1.6.0 ya no funciona en versiones recientes de ubuntu. Y parece que la incompatibilidad ya es grave (han aparecido nuevas librerías desfasadas con incompatibilidades con el resto del sistema) de modo que es muy probable que el siguiente tutorial ya no sirva de nada, y la única opción sea la instalación mediante Wine. Os recuerdo que si queréis un gestor de prefijos de wine podéis probar podéis usar PyWinery, os facilitará la vida enormemente.

EDITADO 19/11/2008 : El tutorial siguiente hará funcionar la versión de epsxe 1.6.0, la última para linux. Sin embargo, existe una versión no nativa más reciente, la 1.7.0, que sólo podréis disfrutar usando wine, David ha publicado una guía por si estáis interesados.

Bueno... llevo días dándole vueltas sobre si publicar este apunte o no (debido a esto) y recomendar otro emulador libre como PSemu o psX... pero la verdad esque, después de probar las alternativas... no queda otro remedio que usar ePSXe si queremos una emulación mínimamente decente de modo que aquí va la receta para echarlo a andar pese a estar un poco abandonado...

Lo primero, por supuesto, es descargarse el binario de la página web, http://www.epsxe.com/download.php y elegir la versión de Linux.

Ahora toca bajarse los plugins para hacerlo funcionar (ePSXe, como muchos otros, requiere de plugins individuales que emulen el sonido, el vídeo, etc), tienes los siguientes para elegir (recomiendo bajar más de uno de cada categoría para ir probando):

• Vídeo:
  • Pete's XGL2 (y para para activar pixel-shading adicional tienes estos archivos).
  • Pete's MesaGL
  • P.E.op.S. soft gpu (aceleración por software)
    
• Audio:
  • P.E.op.S. OSS/ALSA
  • Pete's NULL
    
• Joypad (sólo es necesario si tienes un mando de PSX conectado al PC):
  • ammoQ Joy-Device to X mapping
    

Lo siguiente es hacerse con una BIOS dumpeada de una PlayStation, ¿que te suena a chino? Normal. Si tienes una PSX original y dotes de electrónica puedes hacerlo legalmente, si no, siempre puedes usar programas P2P y/o usar algún buscador... pero es algo que roza la delgada línea de la legalidad...
Normalmente te encontrarás con una bios con alguno de estos nombres:
SCPH1001.zip, SCPH5000.zip, SCPH5500.zip, SCPH7001.zip, scph7502.zip, scph75021.zip, scph75023.zip ó scph75024.zip.

Bueno, si ya tienes todo lo necesario, ahora toca descomprimir el epsxe a un directorio. Copia la imagen de la BIOS al subdirectorio bios, y todos los plugins al subdirectorio plugins. Fíjate en los archivos que contengan cfg o tengan la extensión .cfg , estos deberán ir en el subdirectorio cfg, no al de plugins , ya que se trata de los archivos de configuración de los plugins.

Ahora la cosa se complica un poco:
En el directorio plugins, crea enlaces simbólicos al plugin de vídeo que quieras usar por defecto y llámalo libgpu.so , y lo mismo con el de audio que quieras usar por defecto llamándolo libspu.so . Esto se debe a que la versión de ePSXe para linux no trae plugins por defecto, y no puede arrancar sin ellos.
Puedes crear los enlaces desde el entorno gráfico (generalmente botón derecho, crear Enlace o enlace simbólico) o desde línea de comandos (ln -s fichero_original fichero_enlace).

Intenta arrancar el ePSXe, ejecutando el binario epsxe que descomprimiste anteriormente (puede que haga falta hacerlo ejecutable en sus opciones, o ejecutando chmod +x epsxe en consola).

Hasta aquí es todo "oficial", y está en los tutoriales de miles de páginas. Si se ejecuta bien, eres afortunado. Pero a mí no me funcionó (uso amd64) y no soy el único... De modo que me lo tuve que currar un poquito más....

Lo primero a probar: al intentar lanzar ePSXe desde consola me encuentro con que no da ningún error, simplemente no hace nada, investigo un poco y descubro que está compilado con un tipo de compresión incorporado que no se lleva excesivamente bien con versiones recientes del kernel linux, el UPX, de modo que intentaremos quitarle esa compresión (no es la página que leí cuando lo hice, pero está explicado aquí). Para ello necesitamos instalar el paquete upx-ucl desde Synaptic o desde consola (con sudo apt-get install upx-ucl). Y ejecutar (desde consola) upx -d epsxe .
Lo segundo a probar: al intentar arrancar el emulador, me salen errores de librerías que no encuentra, librerías antiguas que el ia32libs de Ubuntu (las librerías para ejecutar programas de 32bits en ubuntu a 64bits) no incluyen, de modo que tuve que recurrir a la paquetería Debian y buscar esas librerías.

Para facilitaros el trabajo, he creado un paquete con esas librerías (disponible aquí) que deberéis descomprimir en una carpeta cualquiera (yo elegí la misma que el epsxe, en un subdirectorio llamado usr_lib32 que ya viene incluido en el paquete).

Ahora hay que decirle a ePSXe que use esas librerías, para ello ejecuta por consola (en la misma línea) LD_LIBRARY_PATH="directorio_de_librerias" ./epsxe , cambiando el directorio_de_librerias por la carpeta donde tengas descomprimidas las librerías del paquete de arriba.

A mí me funcionó, pero para no tener que lanzar el emulador desde consola, siempre usando esa línea, me creé el siguiente script (haz un archivo de texto vacío, y pega el código modificando los directorios para tu caso particular):

#! /bin/bash
cd /home/apps/epsxe
LD_LIBRARY_PATH="/home/apps/epsxe/usr_lib32" ./epsxe

Recuerda cambiar los directorios por el del ejecutable epsxe y las librerías, respectivamente. Guardadlo con extensión .sh y dale permisos de ejecución.

Luego toca lo de configurarlo y eso, pero no debería haber más problema.

Un saludo y espero que os haya sido útil, y ya sabéis, preguntas a los comentarios.

NOTA: ePSXe usa gtk1.2, por lo que las fuentes pueden verse sobredimensionadas, y el aspecto bastante tosco, si os parece incómodo hay forma de configurar gtk1.2 para que no sea tan horriblemente feo, si estás interesado sigue por aquí.

EDITADO (20/3/2008): Acabo de poner el ePSXe en mi cacharro portátil, y me he dado cuenta de que las instrucciones que pululan por todos sitios para hacer que las fuentes gtk1.2 se vean bien, en efecto, distan mucho de funcionar (al menos en este caso).
La solución: la configuración de las fuentes para cada una de las codificaciones de caracteres (locale) se esconden en /etc/gtk , para saber que locale es el de tu sistema, escribe locale en la consola. En mi caso el archivo a modificar es gtkrc.utf-8 (ejecutando en consola sudo gedit /etc/gtk/gtkrc.utf-8 ) , que he dejado tal que así:

style "default-text" {
fontset = "-*-helvetica-medium-r-normal--*-75-*-*-*-*-*-*"
}
class "GtkWidget" style "default-text"

75 el el tamaño de la fuente, puede ser mayor o menor (puedes probar sin miedo), pero en mi portátil 75 es un tamaño aceptable.

EDITADO (12/11/08): Gracias David, efectivamente, cuanto más tiempo pase, más librerías se irán quedando desfasadas, por lo cual tendré que ir modificando el tar.gz para incluirlas, en este caso, para añadir el libglib1.2.

Créditos:

• Imágenes mías.
• Información de los plugins (inicialmente) sacado de ngemu.

Ejemplo: El código cerrado del ePSXe

No quiero que el post genere un flame acerca de si se debe tener como requisito importante que el software que utilizamos sea software libre, open-source, o cerrado, simplemente quiero exponer una demostración de que esas situaciones "hipotéticas" que frecuentemente se mencionan no son tan hipotéticas como intentan hacernos creer los generadores profesionales de FUD.

El caso trata de uno de los mejores, si no el mejor, emulador de PlayStation (la primera), que tuvo su gran apogeo hace ya unos años, cuando otros muchos emuladores para este sistema empezaron a surgir como setas, algunos de pago (Bleem! por ejemplo), algunos freeware, y algunos libres. Con el afianzamiento de la emulación y las continuas mejoras, la guerra entre las diferentes alternativas fomentó una sana competitividad de las que todos salimos beneficiados con emuladores que evolucionaban muy rápido. Algunos proyectos quedaron descontinuados, por no lograr llamar la atención, o simplemente por falta de tiempo de sus desarrolladores (en la mayoría de los casos, estaban programados por gente que usaba su tiempo libre para tal fin).


A día de hoy, todo ese apogeo ha cesado, y varios emuladores de PSX han logrado un nivel de perfeccionamiento bastante alto, muchos otros no, pero la gran mayoría de los proyectos que se iniciaron entonces se encuentran en una especie de estado hibernación.

EPSXe es uno de estos proyectos, pero lleva muerto desde el año 2003. Los autores continuamente reiteran que el proyecto no está "abandonado", sin embargo parece que esas declaraciones simplemente buscan que el proyecto no sea incluida en la larga lista de los que nadie se preocupa, los proyectos muertos, de sitios como Emunations o NGEmu.

En los mismos foros del proyecto se amontonan las peticiones para que el código sea liberado (es freeware, pero no open-source) a fin de que gente a quien realmente le importe el emulador puedan seguir desarrollándolo y adaptándolo a los nuevos sistemas, arquitecturas, etc, independientemente de que sus autores iniciales lo tengan tan desatendido (falta de tiempo dicen, en dos años algo de código podría haberse podido optimizar, digo yo).


Una clara muestra de cómo mueren los proyectos cuando los autores desaparecen y el código no es libre (es más, en este caso tan sólo aparecen para recordar a los usuarios que no tienen intención de liberar el código, pese a no tener la menor intención de usarlo para nada).
Al menos, y sirve un poco como consuelo, muchos de sus plugins (encargados del sistema gráfico, del sonido, el lector de CD y el controlador para joypad), desarrollados por programadores independientes, son GPL (y se nota, si bien llevan bastante tiempo sin sacar nuevas versiones éstas suelen ser bastante más recientes que el propio emulador).

Yo soy de los que se entristecen cuando un proyecto, con muchas horas de trabajo, ilusión, y esfuerzo, desaparece por no actualizarse y quedarse desfasado. Soy de los que, con cada actualización del kernel, de las librerías del sistema, o Wine, Firefox, OpenOffice, Geany (que estoy usando para crear este testamento) se emocionan, y no pueden esperar para que, con los ojos vidriosos, ver como apt-get los descargue junto con sus dependencias y los configure para hacerlos encajar perfectamente en este engranaje casi perfecto que es el sistema derivado de GNU/Linux.

Hacer funcionar ePSXe en ubuntu x86_64 se convirtió en toda una odisea, debido al uso de librerías gráficas desfasadas (gtk1.2) y la no existencia de binarios para arquitecturas de 64 bits, siendo esto último muy facilmente solventable si el código fuese libre, ya que podría compilarse en cualquier arquitectura, y si el código no lo permitiese, siempre se podría modificar el código para solventarlo. Lo peor fue la combinación de ambos problemas para algunas librerías requeridas (tuve que recurrir a la paquetería debian de 32 bits, ya que paquetes tan antiguos ni tan siquiera se encontraba en los repositorios de Ubuntu). Pero esto último será material con el que publicaré otra entrada.

Un saludo.

Créditos:

1. Captura Legend of Dragoon, funcionando en ePSXe, sacado de NGEmu.
2. Logo de ePSXe, sacado de NGEmu.
3. Captura de ePSXe, sacado de asher256.tuxfamily.org
   

Tuto de instalar AIGLX con el último driver de ATI

Un breve apunte:
Un tutorial para instalar en Ubuntu el último driver de ATI (el más estable), con AIGLX (apto para usar Compiz), muy fácil de seguir paso a paso.

No lo he probado, uso NVIDIA, pero creerme cuando os digo que lo probaré en una de mis "cobayas" en cuanto pueda.

http://jfibergran.wordpress.com/2008/01/25/instalar-driver-nuevo-de-ati-con-aiglx/

Gracias a jfibergran (avasallado a votos negativos en menéame.net).

Créditos:
Imagen de ATI creada por lorddanneh licencia CCv3 con reconocimiento.

Mi N70 y Ubuntu, la senda del OBEX...

Editado 25.12.2009: Ahora, gracias a ciertos bugs corregidos en Ubuntu 9.10, es posible hacer esto de forma mucho más sencilla con ObexFS. Si te interesa, puedes pasarte por Nseries, Ubuntu 9.10, y obexFS vía USB.

Sujerente título, ¿eh? Jajaja, bueno, mejor me explico:
Tengo un N70 (no haré propaganda diciendo que uso YOIGO... ¡outch!) y viene el problema de siempre a la hora de pasar programas/música/fotos/droga del entre el PC y el móvil/mp4/dispositivo raro... bueno, alomejor droga no... Vamos, que los drivers/programas/chapuzas que incluyen estos "artilugios" olvida tristemente que hay gente que es libre, por lo que, una vez más la comunidad linuxera ha tenido que buscarse la vida por su cuenta... la solución es la implementación OpenOBEX (OBEX es un protocolo de intercomunicación por Bluetooth, USB, etcétera que usan muchos dispositivos móviles, info aquí,), oséase, toca instalar los paquetes de esta maravilla... por consola:

sudo apt-get install obexftp

Bueno... obexftp también puede instalarse por synaptic por supuesto... sea como sea, instalar esto implicará instalar el resto de paquetes de los que depende.

Ahora dispondremos de una gran aplicación para intercomunicarnos con nuestro dispositivo móvil por la bella línea de comandos...

Bueno, ya sé que siempre es mejor tener una interfaz gráfica, de modo que tendremos que instalar OpenObex-Frontend de aquí (bajaos el .deb) y lo instaláis.

EDITADO EL 31/08/2008: Debéis tener en cuenta de que es una aplicación en java, es decir, deberéis tener instalado el java de Sun Microsystems y no el de GNU, para que funcione correctamente. Para ver y elegir cuáles tenéis instalado ejecutad sudo update-alternatives --config java (gracias al visitante anónimo que lo avisó). Y por cierto, la versión a día de hoy es la 0.6.6, pero la interfaz sigue siendo casi igual, por lo que no veo necesario actualizar las capturas.

NOTA: Es probable que para poder usar ciertas interfaces OBEX con este programa, deba ser iniciado como root (ejecutando sudo obexftp-frontend).

Este frontend no permite (a día de hoy) ver las interfaces disponibles, de modo que deberemos especificarlas en su configuración (menú options, configuration)...

*1 - Aquí va el tipo de interfaz: Bluetooth, Intranet, infrarrojos, USB, o puerto serie.

*2 - Aquí va el canal de la conexión.

Comprendo que el tipo de interfaz será fácil de elegir, no así con el canal de la conexión. Para ver los canales disponibles (y elegir el adecuado) tendremos que ejecutar uno de los siguientes comandos (sí, para esto hace falta la consola):
Es probable que tengas que ejecutar alguno de estos comandos como root, usando: sudo COMANDO

Para Bluetooth: obexftp -b DISPOSITIVO
Para Intranet: obexftp -n IP
Para infrarrojos: obexftp -i
Para USB: obexftp -u
Para puerto serie: obexftp -t DISPOSITIVO

En mi caso (mi super N70 chupiguachi), por USB me devuelve lo siguiente:

Interface 0:
Manufacturer: Nokia
Product: Nokia N70
Interface description: SYNCML-SYNC
Interface 1:
Manufacturer: Nokia
Product: Nokia N70
Interface description: PC Suite Services

Según he leído por ahí, la interfaz 0 es (al menos en mi caso) para sincronizar lista de contactos y demás (puedo usar otra aplicación llamada wammu), y la interfaz 1 es para transferir archivos (lo que necesitaba), por lo que lo pongo en las opciones del frontend (en el *2 de antes).

Ahora solo hay que hacer que actualice la lista de directorios (pulsando F5 o yendo al menú device y Query root files)...
Ya puedo transferir lo que quiera (incluso aplicaciones .sis o .jar, para instalar en el móvil) usando el botón de upload (la flecha verde para arriba) o download (la flecha para abajo), o incluso puedo hacerlo arrastrando los archivos al directorio (Drag'N'Drop) adecuado. Pero ten cuidado con esto último, intenta tener puntería arrastrándolo al directorio adecuado, de lo contrario la aplicación aparecerá en otro o en la carpeta por defecto del móvil.

Espero que me haya quedado lo más sencillo y explicativo posible, si tenéis dudas ya sabéis.

PD. Hay otra interfaz gráfica, obex-tool, que detecta automáticamente las interfaces (por lo que no hay que ver cuales son las disponibles por consola), sin embargo tiene muchos bugs, es fea y lenta, por lo que no la recomiendo para nada.

PD2. El protocolo OBEX es usado por...

• Sony Ericsons usando USB, pero sólo si seleccionas modo móvil (phone mode) en la pantalla de conexión USB del móvil.
• La mayoría de teléfonos con Symbian.

(Sacado de la wiki de OpenOBEX)

Yo conozco a alguien que...

Bueno, ciertamente, yo tengo un amigo "futuro informático" (sarcasmo sarcasmoso), aparte de conocer bastantes "futuros informáticos" (y el sarcasmómetro está apunto de explotar) que dicen que linux esto... linux lo otro... que no sirve... (están muy agusto con sus cuelgues y virus, hay gente para todo)...

Bueno, al menos parece que hay gente que no es, no ha sido, ni probablemente será "informática", que por lo menos tiene las cosas claras:
Paz Padilla se confiesa a Ramonchu:

Si otros aprendieran...

NOTA: Generalmente no soy un devorador de noticias, es más, tengo por principio no incluir, salvo contadas ocasiones, noticias que se divulgan perfectamente sin mi ayuda, pero esta ocasión lo valía:
VÍA MENÉAME.

¡Escanear en Ubuntu!

Algunos habréis intentado utilizar vuestro escáner en Ubuntu, y sin duda muchos habréis fracasado, y ahora os explicaré el porqué; Ubuntu está configurado para que funcione, pero la versión del kernel que contiene Ubuntu Feisty contiene un bug que impide acceder correctamente a escáneres USB.

Muchos dolores de cabeza me han llevado a probar sane desde consola, trastear con xsane... pero nada de nada. Por suerte, en nuestra estupendísima comunidad de ubunteros, más concretamente en ubuntuforums.org, matews ha encontrado una solución temporal:

Simplemente hay que ejecutar en consola...

while [ true ]; do sleep 0.3; lsusb; done

Y mientras se ejecuta (es un bucle infinito), podrás usar el scanner (que irá lento, pero funcionará). Cuando termines de trabajar con él, simplemente tendrás que volver a la consola, parar la ejecución con CTRL+C y cerrarla.

Es fácil, sencillo, y funciona... medianamente. Pero con ello podrás scannear hasta que los negros de Torvalds arreglen el problema.

¡Adiosete!

Nota 23/7/08: Siglos después de escribir esta entrada me he dado cuenta de que el título decía "Utuntu" dónde debería de estar "Ubuntu"... ya está corregido, más vale tarde que nunca (y lo más curioso es que pese al comentario de la entrada, parece que nadie se dio cuenta).

Instalar Compiz-fusion y Compiztray

Cómo habréis notado algunos, he estado un tiempo sin postear. Pues bien, la razón es que he estado ocupado desarrollando un manager (como el Beryl manager, el icono de la bandeja de estado para controlar fácilmente sus funciones) para usar con compiz fusion. Si bien es cierto que ya existen algunos oficiales, aún no he logrado hacerlos funcionar correctamente, así que, como dice el dicho: Si quieres algo bien hecho hazlo tú mismo. Así que por lo menos, hasta que fusion-icon esté terminado, ésta será mi elección, y la de a quien le guste, claro.

EDITADO: LINK BORRADO, MÁS INFORMACIÓN AL FINAL

Y aquí tenéis una captura (es de una versión anterior, así que algunas cosas han cambiado de sitio):



Más info en el foro oficial.

Y por supuesto, ahora os diré como instalar compiz-fusion:

Editad el fichero /etc/apt/sources.list (si queréis, lanzad desde consola sudo gedit /etc/apt/sources.list) y añadid la siguientes líneas:

Repositorio de 3v1n0 (32 bits)[*1]:

deb http://download.tuxfamily.org/3v1deb feisty eyecandy
deb-src http://download.tuxfamily.org/3v1deb feisty eyecandy

[*1]Además deberéis ejecutar esto en consola:

wget http://download.tuxfamily.org/3v1deb/DD800CD9.gpg -O- | sudo apt-key add -

Repositorio de upure64 (64 bits)[*2] (EDITADO 7/10/07 por cambio de URL):

deb http://download.tuxfamily.org/upure64/ feisty-upure64 main-amd64
deb-src http://download.tuxfamily.org/upure64/ feisty-upure64 main-amd64

[*2]Además deberéis ejecutar esto en consola:

gpg --keyserver hkp://keyserver.ubuntu.com:11371/ --recv-keys 2C4C84CC && gpg --export --armor 2C4C84CC | sudo apt-key add -

Nota: 3v1n0 también tiene un repositorio para 64 bits, pero el de upure64 se mantiene más actualizado.

Pues, como siempre, actualizáis los índices de los repositorios (en consola sudo apt-get update), e instaláis compiz, compizconfig-settings-manager, compiz-gnome o compiz-kde (según tu escritorio), emerald y los compiz-fusion-plugins (podéis usar el gestor de paquetes si queréis)... el modo rápido desde consola sería:

sudo apt-get install compiz compizconfig-settings-manager compiz-gnome emerald compiz-fusion-plugins*

Y recordad que deberéis tener aceleración 3D. Adiós y hasta otra.

EDITADO el 30/9/07: Última versión 0.2.5ubuntu1.
EDITADO el 26/10/07: Compiztray se ha vuelto demasiado inestable con nuevas versiones de compiz, además de provocar graves problemas con el gconf frontend que podían llegar bloquear completamente el PC, problemas con el wrapper, incompatibilidad con gráficas Intel... arreglar todo esto significaría rehacer todo el código desde cero, pero ello requiere tiempo y no lo tengo. Así que a quien lo tenga instalado recomiendo el desinstalarlo y buscar alternativas (las hay y son muy buenas).
Si alguien quiere echar un vistazo al código, o continuar el proyecto, le pasaré los archivos de desarrollo que tenga (tampoco tengo mucho, se me quemó el disco duro hace poco, pero tengo los paquetes y demás subido en filefront).

Mercury Messenger (paquete y repositorios)

Como bien se dice en cierta tira de Bilo y nano (ver aquí), más valdría que el Gaim fuese un grupo que pegase palizas a los usuarios de MSN Messenger que lo que realmente es, un programa para conectarse a varias redes de mensajería instantánea.
Si bien Gaim (o como se le conoce ahora: Pidgin) cumple su función principal de enviar mensajes y recibirlos en la red del tío Bill, no implementa una gran parte de características inútiles estilo Emoticonos, Zumbidos, Cámara Web, y soporta muy mal las Display Pictures (imágenes de contactos, o avatars). Nadie les culpa, ya que el msn mierdesenger useaun protocolo ultrasecretamente cerrado, lo que no ayuda mucho...
Pero por suerte para nosotros, unas "hermanitas de la caridad" han creado un cliente muy bueno basado en java (el Sun Java, no funciona bien si usas el GNU-Java) llamado Mercury Messenger, inicialmente pensado para MAC, pero compatible (con sus respectivos arreglos) a toda plataforma compatible con Sun Java.

La última versión aquí publicada, la cual está en pleno desarrollo y por tanto no es estable al 100% (aunque no suele dar problemas), soporta webcam, emoticonos personalizados, avatares, guiños (aunque de una forma un poco extraña) y unos pocos juegos (están trabajando en ello).

Más información aquí (inglés).

Para especificar que quieres usar Sun Java en Ubuntu (ya que este java no es el predeterminado) deberás ejecutar lo siguiente en consola (omite el primer paso si ya lo tienes instalado):

sudo apt-get install sun-java6-jre sun-java6-bin
sudo update-alternatives --config java

Él último comando lanzará un menú para elegir la versión de java a usar, selecciona el que diga " /usr/lib/jvm/java-6-sun/jre/bin/java", o si no aparece, simplemente el que contenga "java-6-sun".

(El método para obtenerlo por repositorios está más abajo)

V. 1.9 Release 8
mercury-messenger-1.9RC8.deb (Ubuntu y Debian)
md5sum: 41f60d4ea3749b65890829d9a7d73673

mercury-messenger-1.9RC8-2.noarch.rpm (RedHat y similares)
md5sum: 41f60d4ea3749b65890829d9a7d73673

(NOTA: he eliminado la 1.9 RC 7 por un bug bastante molesto)

V. 1.9 Release 6
mercury-messenger-1.9RC6.deb (Ubuntu y Debian)
md5sum: 43983eca6d5dbd469a490460c96e160e

mercury-messenger-1.9RC6-h.rpm (RedHat y similares)
md5sum: d31dcac349fe1db2070b41ad3c15f6c5

mercury-messenger-1.9RC6.tgz (Tarball)
md5sum: be4955a85c8239f44ec7d9455265dfed

Paquete experimental para usuarios de Gentoo:
mercury-bin-1.9rc6.tar.gz
(Copiar a /opt y extraer con tar -zxvf mercury-bin-1.9rc6.tar.gz)
md5sum: aef339c7bf9ef5bd76ae9cf44c8ff9ae

Nota, si usáis una distro con arquitectura x86_64, y queréis la funcionalidad del icono en la bandeja de sistema, tendréis que ir como root a usr/lib/mercury/jni (o en Gentoo a /opt/mercury/jni ) y renombrar libtray-x64-untested.so a libtray.so (sustituyendo el original).

Los paquetes han sido creados por lazaruX (usuario del foro oficial). Cualquier duda pues dirigiros a él (en inglés, claro).

Personalmente, no me agrada añadir este tipo de repositorios "de poca confianza" a mi sources.list, pero en el foro parece que no tienen problemas y está bastante actualizado, de modo que aquí tenéis como añadir repositorios específicos de Mercury messenger:

Método de los repositorios

Debian, Ubuntu, y similares:
Añadir la clave gpg escribiendo lo siguiente en consola:

wget http://jgoguen.net/repo/jgoguen.gpg -O- | sudo apt-key add -

Editar /etc/sources.list y añade lo siguiente para tener siempre la última versión:

deb http://jgoguen.net/repo mercury release pre-release

O si tan sólo quieres las versiones estables:

deb http://jgoguen.net/repo mercury release

RedHat y similares:
Descargar la clave gpg escribiendo lo siguiente:

Crear (o modificar) el archivo /etc/yum.repos.d/mercury.repo y añadir lo siguiente:

[mercury]
gpgcheck=0
name=Mercury Messenger
baseurl=http://jgoguen.net/yum/mercury/

Sacado del foro oficial de Mercury messenger: Ver post.
(Por cierto, hay que registrarse para entrar).

EDITADO 30-08-07: He puesto la ultimísima versión 1.9Rc7-2, la última en desarrollo.
EDITADO 11-09-07: He puesto la última versión 1.9Rc8, y añadido el método de los repositorios.

Envy ... ¡verde de nVidia! (o cómo instalar fácilmente 3D de nVidia y ATI)

Bueno, todos sabemos que es un auténtico trauma instalar ciertos drivers propietarios en nuestras distribuciones favoritas, descargar los binarios, lidiar con la consola... Sin embargo, recientemente existe la posibilidad de instalarlos desde los repositorios (aunque no siempre se tratará de la última versión), por lo que nuestro gestor de paquetes hará todo el trabajo, y lo hará bien... o no.

En Ubuntu, a día de hoy, existe un grave problema con estos paquete (lo he comunicado en el Launchpad hace unos meses, pero ni caso), me explicaré de forma sencilla:

• Existen dos drivers nVidia, los "normales" y los Legacy (para las tarjetas viejunas).
• En la última versión publicada se relegó el soporte de varias tarjetas de la rama normal a la legacy (porque se hacían ya viejas).
• Como era de esperar, en los repositorios se actualizó el driver para que las tarjetas más recientes funcionasen... pero ¡TACHÁN! se olvidaron del Legacy, por lo que varias tarjetas se quedaron sin soporte alguno (mi gForce 440 MX entre ellas).
• Además me consta de que los drivers ATI no están muy actualizados.

Menuda metedura de pata ¿no? Pues sí, pero por otro lado, nadie tiene la obligación de añadir o mantener drivers propietarios, ya que ni es su responsabilidad, ni es una actitud muy afín a la filosofía GNU.

Pero antes de que me vaya por las ramas, os diré que para quienes hayan pasado lo mismo que yo (o algo parecido), tanto con drivers nVidia como ATI, existe una utilidad llamada Envy, creada por Alberto Milone usando Python y GTK para ubuntu y debian, que automatiza completamente la instalación de los drivers gráficos de nVidia y ATI, pudiendo incluso elegir qué versión instalar manualmente, desde consola (con menús muy simples, útil cuando no te arranca el gestor de ventanas) o gráficamente (sin tener que tocar la consola para nada).

Pero tiene un problema, cada vez que haya una actualización del kernel (cualquiera de los paquetes linux-headers y linux-image) deberás desinstalar el driver antes de actualizar, reiniciar (para cargar el nuevo kernel) y luego volverlo a instalar. Es muy sencillo gracias a la interfaz gráfica, y no lleva sino unos segundos en hacerse. Por lo demás es perfecto.

Podrás conseguirlo en su web, o descargar desde filefront la versión envy_0.9.7ubuntu11 (la última hasta el momento).

Disfrutad.

Un DOCK en tu Ubuntu

Famosa es la característica de los últimos MAC OS que ubica una barra en la parte inferior de la pantalla, donde se agrupan desde lanzadores a las aplicaciones más usuales del usuario, hasta las aplicaciones minimizadas en ese momento, pasando por applets (pequeñas aplicaciones que muestran información).



En Ubuntu, hay dos formas de hacer algo parecido:
La más simple consiste en usar tu gestor de ventanas y crear una barra más, donde colocar tus lanzadores y applets, y hacer que se adapte a su contenido (siempre que tu escritorio lo permita, claro). Sin embargo no es tan "vistosa" y no difiere mucho de poner otra barra de herramientas (en realidad el concepto es el mismo, pero la impresión y uso no deberían).
La segunda consiste en usar ciertos "programillas" que ubiquen un DOCK donde tú quieras, personalizable y configurable, pero por lo visto esto se encuentra todavía en pañales, y las opciones (al menos en linux) son pocas.

De hecho yo destacaré dos:
Kiba Dock, el cual es conocido por su desenfrenado uso de CPU y GPU, sus efectos estúpidos e inútiles y su herramienta de configuración (la cual no ayuda mucho), y sobretodo por su inestabilidad.
Avant Window Navigator, el cual en principio fue concebido principalmente para sustituir la barra de tareas. Es más estable y fácil de usar, y sobretodo más ligero. Tiene una utilidad de configuración muy simple y adecuada, se le pueden añadir lanzadores, el applet del taskbar, systray (a día de hoy no funciona bien), papelera...

Y como muchos habréis supuesto, comentaré cómo instalar este último en este POST (dejaré KIBA DOCK para otro momento... como para cuando sea más estable).

Demostración del AWN:



La idea es añadir cualquiera de estos repositorios a tu lista sources.list (está en /etc/apt/sources.list aunque también puedes usar tu gestor de paquetes gráfico para hacerlo):

GETDEB (feisty, 32 y 64 bits), también disponible en getdeb.net

deb http://ubuntu.org.ua/ getdeb/

SYZYGY42 (edgy, feisty y gutsy, cambiando la sección del repositorio "feisty" pos la que os convenga, ,32 y 64 bits, no testado)

deb http://download.tuxfamily.org/syzygy42/ feisty avant-window-navigator
deb-src http://download.tuxfamily.org/syzygy42/ feisty avant-window-navigator

Para poder usarlo ejecuta esto en consola (sin saltos de línea):

wget http://download.tuxfamily.org/syzygy42/8434D43A.gpg -O- | sudo apt-key add -

uPure64 (edgy, feisty y gutsy, cambiando la sección del repositorio "feisty" pos la que os convenga, 64 bits; es el que yo uso)

deb http://janvitus.interfree.it/ubuntu/ feisty-upure64 main-amd64
deb-src http://janvitus.interfree.it/ubuntu/ feisty-upure64 main-amd64

Para poder usarlo ejecuta esto en consola (sin saltos de línea):

wget http://janvitus.interfree.it/ubuntu/2C4C84CC.gpg -O- | sudo apt-key add -

Actualiza la lista de paquetes, instálalo (puedes buscarlo con el nombre de avant-window-navigator en tu gestor, o ejecutar sudo apt-get install avant-window-navigator en consola) y ya está, listo para usar.

Estará en el menú Aplicaciones, sección Accesorios, o siempre puedes ejecutar avant-window-navigator en la consola.


Fin.

Disk-Manager, cuando "mount" se vuelve pesadilla

De todos es sabido el inmenso poder del comando "mount", que permite desde enlazar carpetas entre sí (de modo que una muestre el contenido de otra) a montar imágenes de CD, pasando por su uso más extendido: Montar particiones.

Es cierto que distribuciones como Ubuntu intentan liberar al usuario de la crueldad que supone editar el fstab (/etc/fstab) o usar el comando mount para que sus "otras particiones" sean accesibles, y se pueda escribir en ellas. Pero el caso es que no siempre lo consiguen, obligando al usuario a pelearse con la consola (la verdad es que incluso a muchos nos gusta).

Por ello, nuestro amigo Florent Mertens ha creado una utilidad (escrita en Python y GTK) con la que montar las particiones es un juego de niños. Su nombre es Disk-Manager, tiene versión para Ubuntu Edgy y Ubuntu Feisty (además del código fuente), y se puede bajar desde su web oficial.

Nota: esta utilidad me ha salvado de apuros varias veces, y ya iba siendo hora de publicarla aquí. Disfrutadla.

Nota 2: Una vez instalado aparece en el Menú sistema - Administración - Administrador de disco. Sí, lo sé, un poco escondido, pero ese es su sitio.