Luis Angel Cofiño

El comando ":sh" de gvim saca cosas raras

El comando ":sh" de gvim hace que se abra una pequeña salida al shell en la ventana del editor. Pero puede que os salgan códigos muy raros tal que así:

Mail^[[0m/
-rw-r-----    1 root     root          10k dic 15  2002 ^[[0mmime
install.results^[[0m
-rw-r-----    1 root     root          646 dic 13  2002 ^[[0mplug
in131_02.trace^[[0m
-rw-r-----    1 root     root           52 dic 15  2002 ^[[0mplug
ininstall.results^[[0m
drwx------    4 root     root          104 ago  4 02:18 ^[[01;34m
projects^[[0m/
-rw-r--r--    1 lacofi   personal     651k may 31  2002 ^[[0mSpLo
cale_x86.pkg^[[0m
-rw-r--r--    1 lacofi   personal     599k may 31  2002 ^[[0mSpLo
cale_x86.pkg.zip^[[0m
^[[m^[[1;31m[^[[0;31m21:34:55/0^[[1;31m][root@claudia:~]$^[[

Evidentemente, bash está intentando sacar códigos de colores, pero la falsa terminal que usa gvim no los soporta.

Bien, pues la solución es muy sencilla. Resulta que la terminal que usa gvim se llama "dumb", así que se trata de modificar nuestro .bashrc de acuerdo con esto.

En mi caso, tengo un fichero con varias funciones que se cargan al inicio del shell, entre ellas varios inductores distintos. Vete al truco organizar un poco el fichero .bashrc si quieres más detalles. Bueno, pues una de esas funciones carga un inductor muy simple, sin código alguno, tal que así:

function inductor_plano {
	PS1="[\u@\h \W]\$ "
	PS2='> '
	PS4='+ '
	}

Así que en nuestro fichero .bashrc solo tenemos que poner:

if [ "$TERM" = "dumb" ]; then
	inductor_plano
else
	inductor_normal
fi

Y ya de paso, también podemos cambiar el fichero donde guardamos los alias, de tal forma que ponga:

if [ "$TERM" = "dumb" ]; then 
	alias ls='ls -Fhl --color=none'
else
	alias ls='ls -Fhl --color'
fi

Este truco solo funcionará cuando nos desloguemos y nos volvamos a logar.

Impresora HP DeskJet 895Cxi

Este truco está obsoleto. La impresora HP DeskJet 895Cxi está soportada por cups, de forma plena, en cualquier Linux medianamente actualizado. Pero puede que aún quede por ahí alguien con un sistema antiguo, ¿quién sabe?.

Esta impresora puede funcionar de varias formas, de hecho la tuve durante mucho tiempo funcionando como una DeskJet 550C, lo que me permitía hacer todo cuanto necesitaba.

En aquel momento no existía ningún driver para esta impresora en Linux. Al principio surgieron diferentes drivers que permitían hacerla funcionar, al menos en parte, pero al final, el que me daba menos problemas era el de la 550C. Luego encontré turboprint, un driver que me permitía algunas cosas más prácticas, como usar el modo "draft" de la impresora (ahorra tinta e imprime a una velocidad endiablada, con una calidad que es suficiente para texto puro).

Solo que Turboprint era un driver comercial, no código abierto. Y pagar por un simple driver para una impresora... me parecía una exageración, la verdad. Así que seguí usando el de la DeskJet 550C, salvo para el modo draft (que no precisa comprar la licencia).

Más tarde, la propia Hewlett Packard sacó un driver linux para esta impresora (y reunió información para ella y para otros dispositivos HP, lo que supone una buena muestra de la profesionalidad de Hewlett Packard). El driver permite hacer impresiones draft, normales y en calidad fotográfica.

El único problema es que la información sobre cómo usar el driver estaba muy dispersa, pero se podría resumir así:

Nos vamos a la página de HP donde tienen el driver Luego nos vamos a la página de linux donde tienen el filtro y pulsamos en el enlace "download PPD". Con esto nos bajamos un fichero que renombramos a "HP-DeskJet_895C-hpijs.ppd". ¿Ya está?.

Bueno, pues ahora hay que instalar el driver:

[lacofi@claudia lacofi]$ tar -xzf hpijs-1.4.1.tar.gz
[lacofi@claudia lacofi]$ cd hpijs-1.4.1
[lacofi@claudia hpijs-1.4.1]$ su
password:
[root@claudia hpijs-1.4.1]# ./configure ; make ; make install

Cuando termine, el driver debería quedar compilado. Lo comprobamos:

[root@claudia hpijs-1.4.1]# exit
[lacofi@claudia hpijs-1.4.1]$ cd 
[lacofi@claudia lacofi]$ hpijs -h

Hewlett-Packard Co. Inkjet Server 1.4.1
Copyright (c) 2001-2003, Hewlett-Packard Co.

Como vemos, el driver nos está contestando, así que funciona. Vale. Ahora hay que instalar el filtro.

	[lacofi@claudia lacofi]$ su
	password
	[root@claudia lacofi]# mv HP-DeskJet_895C-hpijs.ppd\
	> /usr/share/cups/model/HP/.
	[root@claudia lacofi]# killall -HUP cupsd

Con esta última orden reiniciamos el servidor CUPS. Ahora abrimos nuestro navegador web y nos vamos a la dirección http://localhost:631 y pulsamos en "Manage Printers".

¿Ya?. Pues ahora pulsamos en "Add printer" y nos pide el nombre de usuario y la contraseña. Nos identificamos como root, claro. :-)

Ahora cubrimos el formulario:

Name: DeskJet_895
Location: /dev/lp0
Description: Impresora local

Y pulsamos en "continue". Desplegamos la lista y elegimos el puerto "Parallel port #1 (HEWLETT-PACKARD DESKJET 895C)". Pulsamos "continue".

En Make, buscamos en la lista y elegimos "HP" y pulsamos "continue".

En Model/Driver buscamos en la lista y elegimos donde pone: "HP DeskJet 895C, Foomatic + hpijs (recommended) (en)" y después pulsamos "continue".

Debería decirnos que nuestra impresora ha sido añadida. :-) Pulsamos en "Printers" y deberíamos verla. Si ahora pulsais en "Configure Printer" podeis elegir la calidad de impresión y otras cosas como el tamaño del papel. También podreis elegirlo cuando imprimais, usando xpp o qtcups como colas de impresión.

Como ya dije antes, este truco está totalmente obsoleto. Hoy en día los drivers de Hewlett Packard están totalmente integrados en las distribuciones linux a través del paquete hplip, que incluye los drivers hpijs en los que está incluida nuestra impresora HP Deskjet 895Cxi. Por cierto, que aún la tengo instalada y funcionando en mi ordenador, y eso que también tengo una excelente HP Deskjet 6840 con conexión WiFi, que es la que usamos habitualmente.

Arrancar una segunda sesión gráfica

Este truco también está obsoleto. La mayoría de las grandes distribuciones Linux incluyen por defecto en el menú principal alguna forma de abrir una segunda sesión gráfica. Pero siempre hay excepciones, claro.

Supongamos que tenemos nuestro escritorio favorito abierto y que hay un programa corriendo que no queremos detener (por ejemplo, estamos bajando un fichero muy grande que no nos interesa cortar). Pero alguien (por ejemplo María) necesita el ordenador precisamente ahora. ¿Podemos iniciar un segundo login gráfico para que pueda entrar en su escritorio?.

Hay muchar formas, por ejemplo ésta: Pulsamos Ctrl-Alt-F1, con lo que nos salimos a una consola. Ahora nos logamos y tecleamos el siguiente comando:

Debian GNU/Linux 3.0 claudia tty1

claudia login: lacofi
Password:
Last login: Wed Sep 10 02:53:12 2003 on :0
Linux claudia 2.4.18 #1 Son Apr 14 09:53 CEST 2002 i686 unknown
You have new mail.
[lacofi@claudia lacofi]$ xinit /usr/bin/wmaker -- :1

Pues ya está. Es así de tonto. Ahora arrancará un segundo escritorio gráfico, y podemos cambiar de uno a otro pulsando Ctrl-Alt-F7 o Ctrl-Alt-F8. Cuando terminemos, solo tenemos que salir del escritorio o, si queremos matarlo, salir a la primera consola (Ctrl-Alt-F1) y pulsar Ctrl-C.

Y si quereis rizar el rizo, podeis automatizarlo todo con este script:

-----------Inicio del script "entrada" -------------
#!/bin/sh

if tty | grep "/dev/tty" ; then
   	ejecuta="si"
else
   	ejecuta="no"
fi
	
if [ "$1" = "" ]; then
   	case "$UID" in
      	501)
         	escritorio="/usr/bin/wmaker"
         	;;
      	502)
         	escritorio="/usr/bin/startkde"
         	;;
      	0)
         	escritorio="/usr/bin/blackbox"
         	;;
      	*)
         	echo "No se quién eres, no deberias usarme. ;-)"
		ejecuta="no"
         	;;
   	esac
else
   	escritorio="$1"
fi
if [ "$ejecuta" = "si" ]; then
	xinit $escritorio -- :1
   else
   	 echo "Esta función solo arrancará desde una consola,"
	 echo "y solo por lacofi, maria o root."
	 echo "Abortado"
   fi
-----------Final del script "entrada" -------------

Ahora, una vez logados en la consola, solo tenemos que ejecutar el script "entrada". Si no especificamos nada más, el script decidirá, según quién lo ejecute, con qué escritorio arranca. Cada usuario, con su escritorio favorito: por ejemplo yo con Window Maker, María con KDE, y root con Blackbox.

Introducir "escenas" numeradas en un documento LyX

En los libros (me refiero a novelas), a veces separan secciones o escenas diferentes usando este separador:

Vale, pero ¿cómo hacer esto con LyX?.

Pues vete a los menús y selecciona "Formato" y después "Preámbulo". Ahora, introduce el siguiente código en el preámbulo LaTeX:

\newcounter{apartado}
\addtocounter{apartado}{1}
\newcommand{\escena}
	 {\vskip 10 pt \centerline{\bf --- \arabic{apartado} ---\nopagebreak} 
	 \addtocounter{apartado}{1}}

El código, en sí mismo, es bastante claro: simplemente crea un nuevo contador que se llama "apartado" y un nuevo comando que se llama "\escena". Cada vez que usemos el comando "\escena", el contador apartado subirá un punto.

Para introducir el separador simplemente hay que escribir:

\escena 

Ojo: lógicamente, hay que meterlo como código LaTeX, no texto normal (esto se hace con el botón TeX, de la barra de botones, o en el menú "insertar" y después "TeX"). Si se introduce de esta forma, el código debería aparecer de color rojo en la pantalla de LyX.

Por cierto, que al imprimir, los tres guiones se imprimen como uno solo, pero más largo. Queda bastante bien.

En LyX, el primer párrafo de una sección no sale indentado

Es el estilo americano de la indentación de párrafos, en efecto. Pero para mí, resulta bastante irritante.

No sé, si decido hacer una sangría de la primera línea en los párrafos, quiero que se haga en TODOS los párrafos, incluido el primero tras el título. No sé si me explico. :-)

¿Cómo se hace esto en LyX?. Pues tienes que irte al preámbulo y meter el siguiente código.

\usepackage{indentfirst}

Y hala. A imprimir...

Cuando juego al bzflag, a veces la escena va a saltos

O se paraliza completamente durante unos segundos. Lo suficiente para que te destruyan con impunidad y alevosía. :-)

A mi me ocurría, principalmente, cuando pasaba cerca de un tanque disparando su arma ShockWave.

Has de saber que Bzflag hace uso intensivo de la aceleración por Hardware. De hecho, si no tienes aceleración por hardware, es prácticamente imposible jugar decentemente.

Por lo que se ve, había algo corrupto en mi tarjeta gráfica (en ese momento una Riva TNT2) o en mis drivers nvidia, y daba la cara cuando tenía que formar determinadas formas poligonales (precisamente las implicadas en la visualización del ShockWave).

En cualquier caso, mis problemas desaparecieron comentando la siguiente línea de mi fichero /etc/X11/XF86Config-4 (ya sabes, hay que poner el símbolo "#" delante):

Option		"UseFBDev"		"true"

Supongo que también serviría si lo cambias a:

Option		"UseFBDev"		"false"

Mi escaner Mustek Paragon 800 II SP no funciona con Linux

Sí, si que funciona. Lo que no funciona es la mielda de tarjeta SCSI que viene con él.

Por cierto, ¿cómo es que tienes esa reliquia?. ¿De segunda mano, tal vez?. :-D

Yo lo tenía cuando usaba Windows, y me encontré con el problema fue cuando me pasé a Linux, con Red Hat. Lo configuré todo (más o menos), pero el escaner fue imposible. Así que, por una temporada (pequeña) seguí dependiendo de Windows para escanear.

Hasta que descubrí lo que pasaba: el problema no era el escaner (de hecho, en la documentación de SANE se recogía el Mustek Paragon 800 II SP como soportado), sino la tarjeta SCSI que venía incluida en el paquete, que era una verdadera porquería (entre otras cosas, no admitía interrupciones, con lo que la multitarea se iba al carajo en cuanto escaneabas).

Bien, pues los problemas se solucionaron de golpe comprando otra tarjeta SCSI, concretamente una Adaptec 2940 que me costó menos de 5000 pesetas (pesetas, la extinta moneda española, ¿recuerdas?... a ver... 5000 ptas equivalían a 30 euros... jesús, qué tiempos).

Eso fue todo. La tarjeta SCSI de Adaptec fue reconocida inmediatamente en cuanto reboté el sistema. Y solo con eso, el escaner empezó a funcionar con Linux mediante nuestro querido SANE.

Hasta que fue jubilado por un Canon Lide 30. Y luego por un scanner HP con alimentador de hojas que es una delicia. :-)

Corrección de sintaxis HTML 4.0 con Gvim

Cuando se edita código HTML sería magnífico tener algo parecido a los correctores ortográficos de los procesadores de texto. Sobre todo, para no apartarse de la norma HTML 4.0 (lo que podría provocar visualizaciones extrañas en otros navegadores diferentes al nuestro).

Gvim no tiene ningún corrector sintáctico que sirva para eso. Pero sí permite ejecutar comandos externos sobre el texto editado. Aprovechando esta característica podemos echar mano de "weblint" un excelente comando que proporciona precisamente eso: corrección de sintaxis HTML.

Edita tu fichero "~/.vimrc", y añade la siguiente instrucción:

map <Ctrl+v><Alt+w> :set nu<Ctrl+v><Intro>:!weblint %<Ctrl+v><Intro>

Si estás editando .vimrc con el propio Gvim, deberías ver en pantalla algo parecido a esto:

map % :set nu^M:!weblint %^M 

Esto significa que cada vez que pulses <Alt+w> en modo comando (no modo inserción), Gvim se pondrá en modo "lineas numeradas" y después ejecutará weblint sobre tu documento HTML.

Para regresar al modo de lineas "no numeradas", solo tienes que teclear en modo comando ":set nu!" o ":set nonu". Claro que también puedes hacer otro macro que cambie entre los dos modos. :-)

Copiar desde una terminal a un programa xwindow

Casi todo el mundo sabe que, si arrastras con el ratón por una terminal (como xterm o aterm), copias su contenido al portapapeles. Y si pulsas el botón del medio del ratón, lo pegas, tanto en una terminal, como en una pantalla gráfica.

Pero a veces la cosa se complica un poco. Por ejemplo, cuando en tu xterm está saliendo una laaaarga salida de un programa. Por ejemplo:

[20:17:41/0][lacofi@moira:~]$ ls -R /

En este caso, los datos desfilan por el terminal, de abajo a arriba, y van desapareciendo rápidamente. ¿Como los capturas para copiarlos?. ¿Con "more" y a trocitos?.

Pues una solución es usar el programa "wcopy" tal que así:

[20:17:41/0][lacofi@moira:~]$ ls -R / | wcopy

Con esta tubería, el programa wcopy captura la salida y la pone en el portapapeles del xwindow. Et voilà. :-)

Sin embargo, wcopy parece retirado hoy en día de todos los repositorios. Afortunadamente, tenemos una alternativa, que sí está incluida al menos en Debian y Gentoo (así que supongo que también en todas las distribuciones grandes): xclip.

Un navegador para ayudas HTML

Existen muchos ficheros HTML que no están en la Web, o que no requieren gran potencia del navegador, porque no precisan Java ni hojas de estilo CSS. Un caso típico son las ayudas de los programas o su documentación, que viene a menudo en formato HTML.

Bien, pues aquí te encuentras con un pequeño conflicto: Mozilla, Firefox, o incluso Galeón, son un poco "pesados" de arrancar, por lo que apetece poco echar mano de ellos para leerse un simple fichero de ayuda. Así que, uno se encuentra muchas veces usando lynx o w3m.

Pero lynx y w3m son programas en modo texto. Están muy bien y son rápidos, pero puede que te apetezca un programa gráfico... una cosa a medio camino entre Mozilla o Galeón y Lynx, que arranque muy rápido, cumpla su función sin pretensiones y que apenas ocupe sitio ni memoria.

La respuesta se llama "dillo". Es un navegador HTML gráfico, basado en GTK, sin Java ni hojas de estilo, pero que lee sin problemas el código HTML. Arranca como un rayo y cumple su función con eficiencia y sin tonterías. Pruébalo. Es ideal para leer la documentación de los programas, por ejemplo.

Visualizar gráficos rápidamente

A veces estas tecleando comandos cómodamente en un terminal como Aterm o Xterm y te interesa ver un determinado archivo gráfico, por ejemplo una imagen jpeg. La mayoría de la gente coge el ratón y arranca un programa visor, como "gqview" o "electric eyes". Pero hay otra forma más rápida:

[lacofi@moira lacofi]$ display imagen.png

Sin embargo, en algunas máquinas "display", que en realidad pertenece al paquete ImageMagick, no va del todo bien: es más lento de lo que debería. Afortunadamente no es la única alternativa. Yo prefiero:

[lacofi@moira lacofi]$ xview imagen.png
imagen.png is 88x31 PNG image, color type PALETTE, 8 bit
Building XImage...done

Xview arranca inmediatamente una ventana con dicha imagen, y además muestra información sobre ella en el terminal.

Xpg no llega a arrancar en Debian por un montón de errores Java

Si usas habitualmente Postgresql en tu Debian, apuesto a que te has metido ya a configurar el unixODBC para tu OpenOffice. Pero a poco que te pongas a manejarlo, te darás cuenta de que es un programa demasiado "pesado" para lo que vas a hacer normalmente con Postgresql. Salvo que manejes una base de datos enorme, claro.

Pero si no es el caso, quizás te interese Xpg. Es un programa de tipo GUI, que sirve para facilitar un poco el manejo de Postgresql, enlazando con él como cliente. ¡Ey, el autor es colombiano, así que el idioma del software es castellano! (¿a qué esperas para probarlo?).

El programa, en sí mismo, es exclusivamente código Java. Eso es bueno, porque el código Java es multiplataforma, con lo que el mismo programa puede ser usado en Windows, Linux, etc... Y también es malo, porque es un lenguaje interpretado, lo que significa que hay un programa que traduce en tiempo real cada instrucción Java para el procesador. Eso implica que su ejecución consume tiempo de proceso, y enlentece cualquier operación del programa.

En cualquier caso, Xpg, con toda la lentitud que implica el hecho de ser un programa Java, sigue siendo bastante más rápido que el dinosaurio de OpenOffice. Así que vas y lo instalas siguiendo exactamente las instrucciones que vienen incluidas en el paquete. :-)

(Leiste las instrucciones, ¿verdad?. Hazlo, hombre; si están en castellano, ¿qué excusa vas a dar?). ;-)

Vale, pues ejecutas tu flamante Xpg y... ¡ups!, empiezan a saltar un montón de errores de Java. ¿Y esto qué es?. :-O

[lacofi@claudia lacofi]$ xpg
Exception in "main" java.lang.InternalError: Unexpected exception while defining class
at [xx]: java.lang.Throwable.Throwable(java.lang.String) (/usr/lib/libgcj.so.2)
at [xx]: java.lang.Error.Error(java.lang.String) (/usr/lib/libgcj.so.2)
at [xx]: java.lang.InternalError.InternalError(java.lang.String) (/usr/lib/libgcj.so.2)
at [xx]: java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.2)
at [xx]: gnu.gcj.runtime.VMClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.2)
at [xx]: java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.2)
at [xx]: _Jv_FindClass(_Jv_Utf8Const, java.lang.ClassLoader) (/usr/lib/libgcj.so.2)
at [xx]: java.lang.Class.forName(java.lang.String) (/usr/lib/libgcj.so.2)
at [xx]: gnu.gcj.runtime.FirstThread.run() (/usr/lib/libgcj.so.2)
at [xx]: java.lang.Thread.run_(java.lang.Object) (/usr/lib/libgcj.so.2)
at [xx]: ?? (??:0)
at [xx]: GC_start_routine (/usr/lib/libgcjgc.so.1)
at [xx]: ?? (??:0)
at [xx]: __clone (/lib/libc.so.6)

Vale, vete a la consola y haz esta comprobación:

[lacofi@claudia lacofi]$ java -version
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

La respuesta de java debería ser algo parecido. Pero si te han salido los mensajes de error de antes, yo diría que te va a salir esto otro:

[lacofi@claudia lacofi]$ java -version
gij (GNU libgcj) version 0.0.7

Copyright (C) 2001 Free Software Foundation.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Claro, no esperarías que Debian te instale el genuino Java de Sun, ¿verdad?. En su lugar, y por defecto, Debian te instala una especie de Java con licencia GNU, y que se llama "gij". Cada vez que ejecutas Java, Debian llama en realidad a "gij". Puedes comprobar cómo lo hace con más detalle haciendo esto:

[lacofi@claudia lacofi]$ whereis java
/usr/bin/java
[lacofi@claudia lacofi]$ ls -Fohl /usr/bin/java
lrwxrwxrwx root 22 2003-07-14 /usr/bin/java -> /etc/alternatives/java*
[lacofi@claudia lacofi]$ ls -Fohl /etc/alternatives/java
lrwxrwxrwx root 22 2003-07-14 /etc/alternatives/java -> /usr/bin/gij-wrapper*

Lo que está pasando es muy simple: el programa "java" es, en realidad un enlace simbólico a /etc/alternatives/java, que a su vez es también un enlace simbólico a gij-wrapper (el verdadero programa que se ejecuta como "java").

Y ahí está el problema. Xpg requiere el Java de Sun (el original y único), con un número de versión de 1.3 o superior. No le sirve el "gij" que proporciona Debian.

Vale, pues para asegurarnos de cómo solucionarlo, puedes hacer:

[lacofi@claudia lacofi]$ su
password:
[root@claudia lacofi]# update-alternatives --display java
java - status is auto.
link currently points to /usr/bin/gij-wrapper-3.0
/usr/bin/gij-wrapper-3.0 - priority 30
slave java.1.gz: /usr/share/man/man1/gij-wrapper-3.0.1.gz
Current `best' version is /usr/bin/gij-wrapper-3.0.

Debería salir alguna ruta en la que aparezca "j2se" o "j2re" pero, como ves, a mi no me sale. Si a ti te pasa lo mismo, eso significa que no tienes ningún Java que permita ejecutar el programa, así que tendrás que instalarlo.

Normalmente, un Knoppix te permite hacerlo con tu "apt-get" de siempre. :-)

[root@claudia lacofi]# apt-cache search j2re
libcommons-dbcp-java - Database Connection Pooling Services
j2re1.3 - Blackdown Java(TM) 2 Runtime Environment, Standard Edition
j2re1.4 - Blackdown Java(TM) 2 Runtime Environment, Standard Edition
[root@claudia lacofi]# apt-get install j2re1.4

Y una vez instalado el nuevo Java, hay que indicarle que lo use siempre que un programa pida acceso a Java, en lugar de "gij".

[root@claudia lacofi]# update-alternatives --config java
There are 3 alternatives which provide "java"
Selection 	Alternative
-------------------------------------------
+ 1 		/usr/bin/gij-wrapper-3.2
  2 		/usr/java/j2re1.4.1_01/bin/java
* 3 		/usr/bin/gif-wrapper-3.3
Enter to keep the default[*], or type selection number.

Y elegimos el número 2, en este caso. A partir de ahí, el sistema modifica toda la cadena de enlaces que vimos al principio, de tal forma que /usr/bin/java apuntará a nuestro nuevo j2re recién instalado.

En el caso de Debian, lo tenemos solo un poquito más complicado. El Java de Sun no estará en los repositorios normales de Debian, así que tendremos que ir directamente a la madre del cordero.

Nos vamos a la dirección de Sun y descargamos la última versión de Java en Español. Ahora lo instalamos en nuestro sistema siguiendo las instrucciones que están en la propia Web. ¡Que sí, que están, y también en castellano!. ;-)

Una vez hecho esto, le decimos a Xpg dónde encontrar el nuevo Java que acabamos de instalar, sin modificar nada con "update-alternatives". Para ello simplemente hay que indicarlo en el script "xpg" que viene incluido con el programa. En mi ordenador habría que cambiar las líneas siguientes, lo que está en color cian:

[...]
else
export XPG_HOME=/opt/xpg-binaries-0.1a
cd /opt/xpg-binaries-0.1a/bin
/usr/java/j2re1.4.1_01/bin/java -DxpgHome=/opt/xpg-binaries-0.1a -jar XPg.jar
fi

Ahora debería arrancar Xpg. El aspecto puedes verlo en la página web del programa o mis propias capturas de pantalla (es la número 13).

Gcombust no puede grabar los CD de 800 Mb

Ni Gcombust (que es lo que yo uso) ni otros programas de grabación, como gtoast o xcdroast.

Vale, te diré que SI puedes grabarlo. Y no necesitas nada especial, solo ajustar un par de cosas que quizás no sueles utilizar pero que están ahí. ;-)

En el caso de Gcombust vete a la pestaña de "datos", despliega el botón de tamaño del CD (por defecto pone 74 min), y elige "disco". La grabadora consultará al disco y le preguntará cuál es su capacidad. Te sorprenderá saberlo, los fabricantes de CDR y CDRW meten de alguna forma esa información es sus discos, de tal forma que los programas pueden consultarlo y ajustarse automáticamente. Solo con esto veras que, en un par de segundos, la capacidad se ajusta sola a 799 Mb.

Ahora vete a la pestaña de grabación y marca la casilla DAO (Disk at Once). Los CDR de 800 Mb (o 90 minutos, que viene a ser lo mismo), no pueden grabarse usando el modo TAO (o Track at Once) que es el que se usa normalmente. ¿Sabes cómo lo se?. Lo leí en la etiqueta del disco. ¿Tú no lo haces?. :-P

Mi grabadora CD-RW no puede grabar a más de 4x

Tienes una magnífica grabadora 48x16x48x, lo que significa que puede grabar discos CD-RW a velocidades de 16x. ¿No?.

Pero te has comprado algunos CD-RW y no consigues grabar a más de 4x. Grabas CD-R a altas velocidades, pero en cuanto intentas grabar tus CD-RW, la velocidad cae siempre a 4x. ¿Qué está pasando?. ¿Linux no soporta bien tu hardware, tal vez?.

Sí, si lo soporta. Y el problema no es de Linux. De hecho, no hay ningún problema. Simplemente has comprado los CD-RW equivocados. Fíjate bien en la caja o en el propio reverso de los discos. Seguramente verás en algún lugar impresa la leyenda "speed 4x" o "multi speed 1x 2x 4x". De alguna manera, los fabricantes meten esa información con la velocidad máxima en algunas pistas del CD, de tal forma que el hardware lo consulta y automáticamente se frena para adaptarse a ello.

Cuando compres tus discos CD-RW, fijate un poco más en qué es lo que compras, y busca CD-RW con la leyenda "High Speed", o que especifiquen una velocidad más alta.

Curioso, ¿verdad?. Uno piensa que esas cosas que ponen en la etiqueta solo son orientativas (certificaciones y esas cosas), pero resulta que esa información está tambien dentro del CD, de tal manera que el hardware se da cuenta y se autorregula.

Quiero usar las teclas de Windows en KDE

Pues adelante. Es muy fácil.

Asegúrate de que tu fichero "/etc/X11/XF86Config-4" contiene esta línea en la sección InputDevice:

Option          "XkbModel"      "pc104"

Con esto le indicas al sistema que el teclado no es el "clásico" de 101-102 teclas, sino que tiene teclas adicionales (las especiales de Windows).

Si has tenido que cambiar algo, resetea tu servidor gráfico o el ordenador, como prefieras.

En KDE vete al Centro de Control (KControl), al menú "Regional y Accesibilidad", y al submenú "Accesos rápido de teclado".

Despliega la lista de esquemas y elige, por ejemplo, "Esquema de Windows (con la tecla Win)". Verás que en la mayoría de los atajos de teclado interviene la tecla Win, que actúa como modificador. Yo solo cambié la entrada que pone "Menú emergente del escritorio", de tal forma que cuando la pulso en KDE aparece el "Menú K".

BZFlag no tiene sonido cuando lo inicio desde KDE

KDE usa aRTs como servidor de sonido, y BZFlag usa ESD. Compiten por el mismo recurso, así que KDE lo bloquea para que nadie interfiera con su forma de controlar el audio. Gnome hace lo mismo con ESD, así que no te sulfures. ;-)

Lo que puedes hacer es detener temporalmente el sistema de audio de KDE, y luego ejecutar BZFlag.

Una posible solución es pulsa en "Menú K" y después "Multimedia" y "Más programas". En ese submenú elige "Control de aRTs".

En ese programa, despliega "Ver" y selecciona "Ver estado de aRTS". Suspende el audio y ya puedes jugar a bzflag. De todas formas, el audio se suspende automáticamente al cabo de unos segundos, si nadie ha reclamado que suene nada. Por eso, puede ocurrir que a veces arranques bzflag y tenga audio y a veces no, aparentemente al azar (en realidad depende de que KDE haya hecho sonar algo o no en los últimos 30 segundos).

gmplayer dice que mi sistema es demasiado lento para ver DVD

Gmplayer (o mplayer) dicen que tu sistema es demasiado lento para poder ver los DVD. Es más, el muy cabr*n te lo restriega por las narices sacando una y otra vez un mensaje que te impide ver a gusto el DVD.

A mi me pasaba con la versión que tenía instalada de Gmplayer, la 0.90. Pero hay varios consejos que dar, en este tema.

Una alternativa es que lo ejecutes con la opción "-framedrop". Esta opción elimina algunos cuadros, con lo que el movimiento deja de ser fluido y empieza dar saltos para resincronizarse con el audio. Evitará el dichoso mensaje, pero solo te lo recomiendo como última opción, porque reduce mucho la calidad y es desagradable.

Pon el bit SUID al ejecutable "mplayer" (gmplayer es solo un enlace simbólico con mplayer). Esto hará que se ejecute con privilegios de root, con lo que es más rápido. Pero ojo, ¡es un problema de seguridad con el que tendrás que convivir!. Esto es aceptable en un ordenador doméstico, pero no en una máquina de empresa donde te estás jugando algo más importante que tus ficheros personales.

Pide ayuda al programa para saber qué dispositivos de video tiene disponibles:

[16:41:05/0][lacofi@claudia:~]$ gmplayer -vo help

Este comando, te sacará por pantalla un listado con los dispositivos de video que gmplayer puede usar, como XV, DGA, o XVIDIX. Puedes especificar que use cualquiera de ellos mediante la línea de comandos:

[16:45:23/0][lacofi@claudia:~]$ gmplayer -vo xvidix

Muchos de estos dispositivos (por ejemplo XV o XVIDIX), escriben directamente en la memoria de vídeo, saltándose el acceso normal del procesador. Por eso no conseguirás hacer un "screenshot" con los programas habituales (la pantalla de gmplayer se verá solo de color azul, sin imagen alguna). Pero te advierto que estos dispositivos necesitan que mplayer se ejecute con privilegios de root, así que tendrás que activar el bit SUID si quieres usarlos. Haz pruebas. Saca el listado que te da la ayuda, y comprueba todos los modos uno a uno. Si tienes problemas con el audio puedes hacer lo mismo con:

[16:48:12/0][lacofi@claudia:~]$ gmplayer -ao help

Pero la mejor opción es que te actualices. Seguramente eso solucionará la mayor parte de tus problemas, o al menos hará desaparecer el dichoso mensaje.

Con autofs, KDE intenta montar dos veces mi DVD

Si instalas autofs (el montador "automágico" para unidades removibles), te encontrarás conque KDE intenta montar dos veces tu unidad DVD, o ZIP, o disquette (o cualquier cosa que hayas incluido en el automounter).

Total, que metes un DVD, haces click en el icono de DVD, y te sale un mensaje en pantalla diciendo que, según mtab, la unidad ya está montada. Y un segundo después, por detrás, ves salir el konqueror con el contenido del DVD. Vale, está bien, pero ¿no hay forma de evitar ese irritante mensaje de error sin sentido?.

Pues sí, claro. Lo que ocurre es que KDE tiene incorporado un sistema de automontaje semiautomático, que presupone que NO estás usando el automounter autofs y que, de hecho, entra en conflicto con él. Así, cuando metes un DVD, autofs lo monta inmediatamente. Después, cuando haces click en el icono del escritorio, KDE intenta montarlo otra vez y ahí es donde salta el conflicto. No puedes evitarlo, KDE está diseñado para comportarse así y no es opcional (supongo que ya esté corregido). Pero mientras tanto puedes solucionarlo dando un pequeño rodeo (un "workaround", que dicen en el imperio).

Vete al Centro de Control del KDE. Despliega "Escritorio" y elige la sección de "Comportamiento". Desactiva la casilla "mostrar dispositivos en el escritorio". Pulsa aceptar.

Vale, ahora verás cómo, en tu escritorio, desaparecen todos los iconos de unidades removibles... el DVD, el floppy, la ZIP, todos la carajo. De acuerdo, eso es lo que queríamos. Ahora tienes que crearlos a mano, uno a uno. Por ejemplo, el DVD tal como sigue.

Haz click en el fondo de escritorio con el botón derecho del ratón. En el menú elige "Crear nuevo". En el submenú... ¡eeeeeh!, contente, no sucumbas, NO pulses "Unidad CD/DVD" porque NO es lo que tienes que hacer. En lugar de eso, elige "Enlace a aplicación".

En el cuadro de diálogo que sale, en la pestaña "General" pon como nombre "DVD-ROM", pulsa en el icono y elige uno bonito, del grupo "dispositivos" y que muestre un DVD. Luego, en la pestaña "Ejecutar" teclea "kfmclient openURL /dvd" siendo "/dvd" el punto de montaje "automágico" que usa autofs. Acepta y ya está.

El nuevo icono se comportará como si fuera un acceso al dispositivo. Cuando hagas click, autofs detectará el acceso y montará la unidad. Luego, Konqueror abrirá esa unidad en pantalla al estilo "Explorer" y podrás navegar en su interior al más puro estilo Windows. Cuando cierres el Konqueror, autofs detectará la inactividad y desmontará la unidad permitiendo la expulsión.

Para más detalles puedes ir a la sección donde cuento cómo se configura autofs.

Como decía, puede que ya esté corregido en las versiones modernas de KDE, pero no suelo usar iconos de dispositivos en mi escritorio, así que...

A veces, en situaciones de estrés gráfico, mi KDE se reinicia solo

Una situación de estrés gráfico sería por ejemplo cuando ejecutas un programa de sintonización de TV, como tvtime. Estos programas no usan la salida de video normal de XWindow sino que escriben directamente en las direcciones de memoria adecuadas saltandose varios pasos intermedios para hacerlo más rápido. Ganan en velocidad, pero lo hacen tocando puntos delicados de tu Linux. Lo que te está pasando, en realidad, es que algun programa o driver está metiendo la pata, provocando un cuelgue de todo el sistema gráfico.

Esto es Linux, no Windows... es muy raro, rarísimo, que Linux se cuelgue por completo. Así que el sistema reacciona a estos cuelgues gráficos cerrando todos los programas presuntamente culpables, empezando por KDE. Luego, intenta arrancarlos de nuevo ordenadamente. Si lo consigue, te devuelve de nuevo a KDE o a tu pantalla de login (dependiendo de tu configuración). Si no lo consigue, te saca a una consola y te ofrece un login de texto.

Cada ordenador es un mundo, así que las causas de un crash gráfico pueden ser tantas que exceden mi capacidad... :-). Pero sí puedo contarte por qué me pasaba a mí y cómo lo solucioné. Si tienes el mismo hardware que yo, puede que eso te ayude un poco. :-)

Mi antigua máquina (claudia) se comportaba muy bien, salvo que esos reinicios de KDE ocurrían de vez en cuando, aunque muy raramente, quizás una vez cada tres o cuatro meses. Pero se hicieron mucho más habituales desde que puse a funcionar una tarjeta Pinnacle PCTV. Lo que pasaba era que a veces (no siempre), KDE se reiniciaba cuando intentaba ejecutar tvtime. Al segundo intento, en cambio, funcionaba bien.

Puedes consultar mi hardware, pero lo que nos importa ahora es que en ese momento tenía una tarjeta gráfica Riva TNT2 y que mi placa madre era una ASUS equipada con un chip VIA. ¿Vale?.

Bueno, pues resulta que se trata de una mala combinación. Había un bug en los drivers de NVidia que se podría resumir en esto: VIA+TNT2+AGP+Aceleración hardware=crash. Estos fallos del driver eran más evidente en situaciones de estrés gráfico. De ahí que se pongan de manifiesto cuando arrancaba tvtime especialmente, o también al ejecutar bzflag.

¿Hay una solución en casos así?. Sí, claro. A pesar de la mala leyenda, tengo la sensación de que NVidia colabora bastante con el mundo Linux, no solo ahora, sino desde hace tiempo, incluso cuando Linux no era tan popular. NVidia saca cada cierto tiempo actualizaciones de sus drivers, soportando los nuevos y los viejos chips. Estas actualizaciones cumplen con las expectativas del software linux: incluyen el código fuente, la licencia GPL e incluso acceso automático al servidor FTP de NVidia para bajarse modulos precompilados. Todo es automático, y el driver reaccionará adecuadamente dependiendo de cual sea tu distribución linux y tu kernel.

Lo único que tienes que hacer, si posees una tarjeta NVidia, es actualizar tus drivers. Hagámoslo. :-)

Tienes que bajarte los drivers. Para ello vete a la página de Nvidia y bájate los Linux IA32 drivers.

Ahora tienes que salir a una consola. NO lo hagas en un terminal como xterm: sal a una consola auténtica (por ejemplo con Ctrl+Alt+F1). Vuelvete root y pon en marcha la instalación del driver.

[lacofi@claudia:~]$ su
password:
[root@claudia:/home/lacofi]# mv NVIDIA-Linux-x86-1.0-5336-pkg1.run /usr/src/.
[root@claudia:/home/lacofi]# cd /usr/src
[root@claudia:/home/lacofi]# sh NVIDIA-Linux-x86-1.0-5336-pkg1.run

Ahora a mi me saltaba un interfaz de texto que me iba diciendo lo que está pasando: que leas la licencia, que está buscando un módulo precompilado, que no lo encuentra, que lo está buscando en el servidor FTP de NVidia, que tampoco lo hay, que está compilando un kernel a partir de las fuentes, que lo está instalando, etc.

En aquella vieja máquina Debian, con un kernel compilado por mí, el programa de instalación empezaba a lanzarme advertencias que tuve la precaución de ir anotando. Decía, por ejemplo, que debía instalar /usr/lib/libGLcore.so.1.0.5336 con permisos 0750, pero tuvo que hacerlo con permisos 0755. Sacó nueve mensajes de estos y los fui anotando todos: qué fichero es, qué permisos debería tener, y con qué permisos queda.

A continuación, modifiqué /etc/X11/XF86Config-4 dejando la sección "Device" así:

Section "Device"
	Identifier      "Riva TNT2"
	Driver          "nvidia"
#	Driver          "nv"
	VideoRam        16384
	Option          "UseFBDev"              "true"
#	Option          "NvAGP"                 "1"

Nada de esto me lo saqué de la manga, claro. La configuración, así como la información sobre el bug estaba en la Web de NVidia, en el fichero README.txt y en la documentación del propio driver. Si es tu caso, leetelo, que merece la pena y para alguien que documenta cuidadosamente algo... :-)

Vale. Luego intenté arrancar un XWindow (por ejemplo con "startx" o con otro script personalizado). En ese momento la pantalla parpadea y sale a consola con un error que dice que no ha conseguido iniciar el módulo de kernel. Hummmm. Tras ejecutar un "modprobe nvidia" carga el módulo sin problemas y XWindow arranca correctamente. Así que estaba claro, había que meter en el fichero /etc/modules una linea que diga "nvidia":

(...lista de modulos a cargar en el arranque...)
gameport
ide-scsi
aic7xxx_old
sr_mod
bttv
nvidia 

En mi caso, apareció el login gráfico (kdm, concretamente). Bueno, pues me logué como "lacofi" y... salta un mensaje de error que dice que no puede arrancar "kdeinit", tras lo cual me devuelve al login gráfico. Me logué como root y entraba correctamente. Evidentemente, se trata de un problema de permisos. Aquí mi cara se iluminó en una sonrisa.

Me salí a consola, me volví root, y saqué el papel con la lista de los ficheros y los permisos que he ido anotando durante la instalación del driver (je, je, jeeee). Cambié a mano los permisos de todos esos ficheros para dejarlos como decía el programa de instalación que deberían estar.

Y luego al iniciar el sistema gráfico aparece de nuevo el login gráfico de kdm. Me logué como lacofi y... ¡arrancó!. Ahora el sistema gráfico funcionaba sin problemas, pero hice pruebas estresando un poco las X Window: en KDE, arranqué tvtime, lo abrí y cerré un par de veces, luego cambié a bzflag y jugueteé un poco. X Window se comportó como debía. Ningún crash. Bravo por NVidia.

Resumen... si usas Linux y necesitas una nueva tarjeta gráfica, que sepas que NVidia te tiene en cuenta. Tú mismo.

Eso si, raramente necesitarás hacer cosas como esta (actualizar tus drivers a mano), porque tanto NVidia como ATI permiten la actualización de los drivers gráficos de forma automática a través de los respositorios de las principales distribuciones. En el caso de Gentoo puedes incluso desenmascarar las versiones de prueba para instalar las actualizaciones más modernas sin testar del todo. Asi que esto de cambiar las cosas a mano solo es apto para impacientes.

Mis notas post-it se me amontonan desordenadamente

Si usas notas post-it, por ejemplo con Kjots, o WMPinboard, a poco que las uses descubrirás que se empiezan a amontonar hasta volverte loco. Un poco de orden no vendría mal, ¿verdad?. Tal vez organizando las notas jerarquicamente, por temas.

Pues tengo noticias: ese trabajo ya ha sido hecho. :-)

Échale un vistazo al programa tuxcards. Está incluido en los respositorios de las distribuciones más importantes, pero también hay disponible una versión compilada estáticamente.

¿Qué es eso de "versión estática"?. Bueno, pues es un binario ya compilado pero que incluye todas las dependencias más engorrosas dentro del propio binario, en lugar de usar librerias externas (como por ejemplo las de KDE). El resultado es un programa más pesado (el tamaño del binario aumenta de forma espectacular), pero que puede ejecutarse sobre la marcha, virtualmente en cualquier ordenador Linux.

¿A qué esperas?. :-P

Tras actualizar unas librerías, no oigo sonidos de sistema en KDE

Ya está. Ya lo has roto. ;-)

Lo digo en serio, ¿eh?. :-D

A ver, te cuento lo que me pasó a mi. Resulta que me bajé dos programas de base de datos, Knoda y Rekall. Ambos hay que compilarlos, pero tienen unas dependencias bastante puñeteras. Total, que "actualicé" unas cuantas librerías y paquetes (sobre todo del grupo KDE y de la sección "devel").

Bien, Knoda y Rekall se compilaron, sí. Pero a partir de ahí empezaron a surgir problemas, todos ellos relacionados con el sonido. Los síntomas principales eran estos, todos ellos bastante sorprendentes:

1. KDE arranca sin el habitual sonido "KDE_Startup.wav".
2. No se oye absolutamente ningún sonido del sistema (ventanitas al abrirse, ventanitas al cerrarse).
3. Sin embargo, puedo abrir ir al "menú K" y abrir cualquier programa de audio (noatun, kaboodle...) y escuchar cualquier mp3 y ogg de mi colección sin ningún problema. También puedo ejecutar noatun y kaboodle en ventana de comandos; y funcionan, pero sacan un curioso mensaje de error que dice "mcop warning: user defined signal handler found for SIG_PIPE, overriding".
4. Curiosamente, ya no puedo arrancar noatun ni kaboodle pulsando los iconos del escritorio. Sale un mensajito que dice que KDEinit no pudo ejecutar "noatun", por ejemplo. Pero si, con el botón derecho del ratón, abro las propiedades del icono, puedo poner como ejecutable "/usr/bin/noatun" en vez de "noatun". Entonces, sí arranca. Pero siguen apareciendo los mensajitos de error "KDEinit no pudo ejecutar "noatun".
5. Si abro Konqueror y me voy a los directorios donde guardo los mp3 y ogg, ocurre lo mismo. Si pulso en un ogg me salta la misma ventanita de error, solo que dos veces seguidas. Puedo modificar los patrones de MIME para que incluya la ruta "/usr/bin/kaboodle" en vez de "kaboodle" con lo que sí arranca. Pero siguen apareciendo los dos mensajitos de error, uno detrás de otro.
6. Abro el Centro de Control de KDE y reviso toda la configuración del audio. Está correcta, exactamente igual que estaba la última vez que la modifiqué. Pero, curiosamente, cuando pulso los botones de prueba para escuchar los sonidos asignados a cada evento, no se oye nada.
7. Abro una ventana de comandos xterm y tecleo un comando "killall artsd". Ejecuto "artsd" en la misma ventana de comandos, con lo que me salen en pantalla todos los mensajes de log. Los log de artsd indican que todo está funcionando bien.
8. Abro otra ventana de comandos distinta para no interferir con los logs de la primera. En ese otro shell ejecuto un glorioso "artscat /usr/share/sounds/KDE_Startup.wav". El sonido se oye perfectamente y la primera ventana de comandos vomita un log en el que identifica claramente el sonido que estoy escuchando. Lo mismo ocurre cuando ejecuto un "play /usr/share...".
9. Abro, cierro, maximizo, minimizo y restauro unas cuantas ventanas del escritorio. Los logs de artsd ni se inmutan... es como si no hubiera hecho nada. ¡La leche, artsd funciona perfectamente, el culpable es el KDE, que no consigue comunicarse con el demonio de sonido!.
10. Salgo de KDE y de todo X Window (o sea me cambio de telinit, vaya, que todo hay que decirlo), me voy a una consola (no un terminal X, sino una verdadera consola). En mi home ejecuto un "rm -Rf .mcop* .DCOP*". Me vuelvo root y ejecuto un "rm -Rf /tmp/*". Rearranco X Windows y que si quiés arroz, Catalina. Que no, que seguimos sin sonidos del sistema.
11. A la desesperada, creo un usuario llamado "tralarí" y con contraseña "chinpón", para que le instale el escritorio KDE por defecto. Lo mismo mismito. El error es mucho más profundo que eso. No es un fallo de configuración, sino un error del propio KDE, concretamente de lo-que-sea que se encargue de comnunicarle los eventos al demonio de sonido (artsd). La única conclusión lógica es que me lo he cepillado con las últimas "actualizaciones". Que lo he roto, vamos. Después de hecha la prueba, borro el usuario "tralarí", por supuesto. ;-)

¿Y la solución?

Pues deshacer el camino andado es la leche. Porque vete tu a saber cual es la librería dañada, y hay que desinstalar cosas, reactualizar paquetes pero a la inversa (con las versionas antiguas, no las nuevas...). Mi madre, también podría recurrir a las copias de seguridad, pero no me hace ninguna gracia meterme en ese berenjenal por los eventos de sonido, que mira tú lo que me importan. Tiene más importancia lo de Konqueror, no por mi, que me la refanfinfla... pero a mi santa esposa no le gusta la informática, a ella lo que le va es que haciendo "click" se oiga la canción y punto. Pobrecita, y yo haciendo trastadas :-D.

Ya. ¿Y la solución?

Pues la "huida hacia delante", claro. Es un buen momento para actualizar TODO el KDE. Qué demonios, es buen momento para actualizar TODO Woody. Al fin y al cabo, KDE es el escritorio por defecto de María. Y el mio también, que hace tiempo que no toco Window Maker. Además, hace mucho que ha salido ya la versión 3.2

Hala, venga. Nos vamos a /etc/apt/sources.list y cambiamos la línea que dice:

deb http://download.at.kde.org/pub/kde/stable/3.1/Debian stable main

por esta otra:

deb http://download.at.kde.org/pub/kde/stable/3.2/Debian stable main

Y luego los consabidos:

[15:05:21/0][root@claudia:~]# apt-get update ;; apt-get upgrade

Eso sí. Hay librerías rotas (era esperable, ¿verdad?). Así que el upgrade es tormentoso y advierte que hay muchos librerías que han sido "keep back" (dejadas atrás). Algunas de esas librerías se refieren al sistema de sonido de KDE (eeeeh, ¿lo has visto?... te pillé). No pasa nada, cuando "apt-get upgrade" se detiene, hago un "apt-get install" manual contra uno de esos paquetes dejados "keep back". Si esto falla por alguna otra dependencia, hago un "dpkg --remove paquete" contra ella y vuelvo a intentarlo. Después, reintento el "apt-get upgrade" y continúo así una y otra vez, hasta dejar todos los paquetes disponibles a cero.

La pregunta que te estás haciendo ahora es... ¿Solucionó esto el problema?.

Sí. Por completo. X-D

Al arrancar KDE 3.2 sale un mensaje "Could not start KDEinit"

Al logarme para entrar en mi nuevo KDE 3.2 sale un estúpido mensaje que dice "Could not start KDEinit. Check your installation". Y la barra de progreso de KDE se detiene hasta que pulso "Okay". Luego, KDE arranca normalmente y funciona muy bien (y es precioso, además ;-) pero cuando deslogo, aparece un mensaje de crash diciendo que KNotify se ha ido al carajo. Afortunadamente, solo dura unos segundos y luego desaparece sola y se desloga normalmente.

Sorprendente, ¿verdad?. Mensajes de error haciendo referencia a no-se-qué porque lo cierto es que KDE 3.2 funciona a la perfección. :-?

Bien, la verdad es que esto se debe a un bug gordo, gordísimo, en el script /usr/bin/startkde. Es tan gordo y evidente que se merece solo un capón y unas risas, porque es como un matemático que después de una larga fórmula de integrales, escribe en la pizarra 2+2=5.

Vale, pues edita con cualquier editor de textos el archivo /usr/bin/startkde. Alrededor de la línea 164, donde pone:

LD_BIND_NOW=true kdeinit +kcminit +knotify
if test $? -ne 0; then
	# Startup error
	echo 'startkde: Could not start kdeinit. Check your installation.'  1>&2
	xmessage -geometry 500x100 "Could not start kdeinit. Check your installation."
fi

Debe poner (fijaos en las dos primeras líneas):

LD_BIND_NOW=true 
kdeinit +kcminit +knotify
if test $? -ne 0; then
	# Startup error
	echo 'startkde: Could not start kdeinit. Check your installation.'  1>&2
	xmessage -geometry 500x100 "Could not start kdeinit. Check your installation."
fi

¿Habeis visto?. Se les olvidó un <Enter> X-D

Pues ya está. Cambiando eso, el bug está resuelto.

En Fedora Core 1, LyX da error al visualizar DVI

Por algún motivo, para mi inexplicable, Fedora Core 1 NO incluye LyX en la distribución por defecto. :-(

LyX es para mi fundamental. Puede ser la diferencia entre aceptar una distribución o eliminarla completamente del disco duro, independientemente de lo buena o mala que pueda ser. Si funciona LyX, me sirve. Si no funciona, me resulta casi inútil. Así de claro.

Naturalmente, la comunidad Linux enseguida le ha saltado al cuello a Fedora Core por este pequeño detalle de la inexistencia de LyX en la distribución. De hecho, si os vais a la página Web de LyX y os meteis en la sección de descargas, vereis un binario perfectamente empaquetado para Fedora Core 1. Y si lo instalais, vereis que funciona correctamente. Puede que incluso de el pego durante un tiempo.

Hasta que querais imprimir, o previsualizar (DVI o Postscript) el texto. En ese momento, abortará y te saldrá un error en pantalla que dice que no encuentra el fichero "babel.sty". Vale, falta Babel, que es fundamental para idiomas no anglosajones, pero puedes copiar los ficheros de estilo de otra distribución.

A partir de ahí, pasará por alto la ausencia de Babel, pero abortará de todas formas y volverá a mostrar dos errores en pantalla (en el título del documento) que dicen esto:

Font T1/cmr/m/n/12=ecrm1200 at 12.0pt not loadable: Metric (TFM) 
file not fou 
\maketitle
                                                                                
I wasn't able to read the size data for this font,
so I will ignore the font specification.
[Wizards can fix TFM files using TFtoPL/PLtoTF.]
You might try inserting a different font spec;
e.g., type `I\font<same font id>=<substitute font name>'.

Grrrrr. Vale, ahora intentas arrancar lyx desde linea de comandos, para ver todos los mensajes de consola. Y cuando pides ver el DVI o hacer una salida a Postscript, te encuentras con esto:

[lacofi@lynette:~]$ lyx
Xdvi Error:
Could not find dvips map ps2pk.map - disabling T1lib.
Direct Type 1 (PostScript) font rendering has been disabled. You should try 
to fix this error, since direct Type 1 font rendering gives you a lot of 
benefits, such as: 
	- quicker startup time, since no bitmap fonts need to be generated;
	- saving disk space for storing the bitmap fonts.
To fix this error, check that the dvips map file is located somewhere in your 
XDVIINPUTS path. Have a look at the xdvi wrapper shell script (type "which xdvi"
to locate that shell script) for the current setting of XDVIINPUTS

El error es aún más dramático si piensas que sin el paso a Postscript, se aborta la impresión del documento. O sea, puedes escribir, pero no ver cómo queda ni imprimir. Todas las ventajas de LaTeX a freir espárragos.

Bien, antes de que empieces a insultar a los chicos de LyX, te diré que no tienen la culpa. De hecho LyX hace bien poco, se limita a ser un front-end (un magnífico GUI, eso sí) para algo mucho más complejo, que es el propio LaTeX.

Y esa es la raiz del problema: que el TeTeX que viene con el Fedora Core 1 está completamente roto y funciona fatal. (TeTeX es la versión específica de LaTeX que suelen usar todos los Linux, así que cuando digo TeTeX, debes entender LaTeX). Sospecho que por eso no metieron LyX en Fedora: dudo mucho que consiguieran hacerlo funcionar, si es que usan esta versión dañada de TeTeX. Esto es aplicable para TeTeX 2.0.2-8 y para LyX 1.3.4.

¿Solución?. No la hay, o al menos no la conozco. He intentado de mil formas distintas reparar el TeTeX de Fedora Core 1, y he sido incapaz. Me he llegado a plantear, de hecho, desinstalar todo Fedora y regresar a Debian, solo por esto. Pero no hizo falta llegar a ese extremo: hay una solución, extrema pero funcional... Desinstalar todo LyX y TeTeX, y compilarlo desde cero, como los grandes. Pues a ello.

En primero lugar, desinstala todos los RPM que estén implicados en LyX y TeTeX. Eso incluye algunos otros que yo no uso nunca, pero que hay que quitar también para cumplir las dependencias. En mi ordenador, tuve que desinstalar: tetex tetex-afm tetex-doc tetex-dvips tetex-fonts tetex-latex tetex-xdvi tetex-lgrind LyX docbook-utils-pdf jadetex xmlto passivetex xmltex linuxdoc-tools TeXmacs gtk-doc docbook-utils. Venga, quita toda esa porquería... ;-)

Ahora vete a la página principal de TeTeX y bájate las fuentes. Son tres ficheros: tetex-texmf.tar.gz, tetex-src.tar.gz y tetex-texmfsrc.tar.gz. Eso sí, te advierto que LaTeX es MUY complejo, lo que significa que ocupa muchos megas: prepárate a bajarte más de 80 Mb, vaya. ;-)

Ahora vuélvete root y empieza por instalar los tipos de letra:

[root@lynette:~]# cd /usr/share
[root@lynette:/usr/share]# mv texmf backup-texmf
[root@lynette:/usr/share]# mkdir texmf
[root@lynette:/usr/share]# chmod a+rx texmf
[root@lynette:/usr/share]# cd texmf
[root@lynette:/usr/share/texmf]# tar -xzf ~/tetex-texmf.tar.gz
[root@lynette:/usr/share/texmf]# tar -xzf ~/tetex-texmfsrc.tar.gz

Ahora descomprime las fuentes del programa TeTeX

[root@lynette:/usr/share/texmf]# cd /usr/src
[root@lynette:/usr/src]# tar -xzf ~/tetex-src.tar.gz
[root@lynette:/usr/src]# cd tetex-src-2.0.2
[root@lynette:/usr/src/tetex-src-2.0.2]# cat INSTALL

Sí, hombre, leete las dichosas instrucciones. Son muy claras y nos vienen de perlas. Yo las he aplicado al pie de la letra.

[root@lynette:/usr/src/tetex-src-2.0.2]# sh -c './configure --prefix=/usr > configure.log 2>&1'
	(esto tarda bastante: paciencia. Luego revisa configure.log en busca de errores)
[root@lynette:/usr/src/tetex-src-2.0.2]# sh -c 'make world>world.log 2>&1'
	(esto tarda todavia más: paciencia. Luego revisa world.log)
[root@lynette:/usr/src/tetex-src-2.0.2]# cd /usr/bin/i686-pc-linux-gnu
[root@lynette:/usr/bin/i686-pc-linux-gnu]# ls | wc -l
	146
[root@lynette:/usr/bin/i686-pc-linux-gnu]# cp * /usr/local/bin/.

Con esto, ya deberías tener un TeTeX (LaTeX) funcionante. Ahora vamos por LyX.

Vete a la página web de LyX y bájate las fuentes de la última versión. No podrás instalar el binario porque te dirá que fallan las dependencias (no encuentra el binario de TeTeX, puesto que lo compilaste a mano). Y no lo instales tampoco con la opción "--nodeps" porque tendrás problemas más adelante. Mejor compila, hazme caso.

Descomprime las fuentes y compila. Leete el fichero INSTALL, que nunca lo haces y ¡es donde viene todo! (¿o crees que yo aprendo del aire?). ;-)

[root@lynette:/usr/bin/i686-pc-linux-gnu]# cd /usr/src
[root@lynette:/usr/src]# tar -xzf ~/lyx-1.3.4.tar.gz
[root@lynette:/usr/src]# cd lyx-1.3.4
[root@lynette:/usr/src/lyx-1.3.4]# ./configure --with-frontend=qt
	(montón de chequeos)
[root@lynette:/usr/src/lyx-1.3.4]# make
	(cosas en chino, que NO terminan en "error")
[root@lynette:/usr/src/lyx-1.3.4]# make install

Helo ahí. Ahora ejecuta /usr/local/bin/lyx. Puede que haga falta ir al menú "Edición" y pulsar "Reconfigurar". Enhorabuena. :-)

Hoy en día, sin embargo, he vuelto a Fedora en mi portátil. Le resulta más fácil manejar Fedora que compilar un Gentoo a medida, la verdad. Bien, pues te diré que Fedora 8 (que es la versión que tenemos ahora en marcha), incluye un LyX completamente funcional. Tenía que decirlo, supongo.

En Fedora Core 1, LyX muestra mal los acentos

Si has conseguido que LyX funcione en tu Fedora Core 1, es probable que te encuentres con un problema menor, que en sí mismo no afecta al funcionamiento del programa, pero que se te hará un poco molesto. Si es que eres de un exigente...

El problema al que me refiero es que determinadas etiquetas muestran mal los acentos. Así, en vez de "Índice General" verás algo parecido a "Á#ndice General". Y en vez de "minipágina", verás algo como "minipÁ¡gina". Es una cuestión estética, si se quiere, pero caramba...

Esto ocurre porque Fedora Core 1 utiliza la página de códigos UTF8 por omisión, en lugar de la clásica ISO-8859-1 o latin1 de toda la vida. Esto es bueno, porque UTF8 permite visualizar correctamente los caracteres especiales de multitud de idiomas simultáneamente. Pero tiene el inconveniente de que no todos los programas aceptan esa página de códigos, como le ocurre a LyX. Si tecleas un comando "echo $LANG", verás que te contesta "es_ES.utf8". Y lo mismo si preguntas "echo $LANGVAR".

¿La solución?. Abre una ventana de comandos y ejecuta:

[08:02:53/0][lacofi@lynette:~]$ LANG=es_ES.latin1 && LANGVAR=es_ES.latin1
[08:02:55/0][lacofi@lynette:~]$ lyx && LANG=es_ES.utf8 && LANGVAR=es_ES.utf8

Obviamente, estamos siendo "no destructivos", es decir, el segundo comando hace que después de terminado lyx, las dos variables recuperen su valor original.

Sin embargo tal vez prefieras utilizar siempre latin1 en vez de utf8. Esta es la solución que yo he adoptado, y para ello solo tienes que cambiar el fichero /etc/sysconfig/i18n de tal forma que contenga esto:

LANG="es_ES@euro"
COUNTRY="es"
LANGUAGE="es"
CHARSET="iso8859-15"
XMODIFIERS=""

Me resulta complicado comprimir ficheros con Nautilus

Si no te gusta teclear comandos, hay determinadas cosas que te resultarán complicadas en el Gnome File Manager por excelencia: el Nautilus. Una de esas cosas es comprimir ficheros con zip o con tar, otra cosa es descomprimirlos, otra es copiar ficheros a tu home, o girar una foto a la derecha o a la izquierda... hay docenas de cositas que se echan de menos. Fáciles, si usas comandos, pero incómodas si sueles manejar tu linux como quien usa windows (cosa totalmente legítima, por supuesto).

Quizás no sepas que Nautilus tiene una función poco utilizada que se llama "nautilus-scripts". Verás, en tu directorio "home" hay un subdirectorio oculto que se llama ".gnome2/nautilus-scripts". Bien, pues cualquier script bash que metas ahí, aparecerá automáticamente en el menú de contexto que aparece en Nautilus. Si seleccionas unos cuantos ficheros y despliegas el menú con el botón derecho del ratón, puedes ejecutar cualquiera de esos scripts con solo hacer click, y la ejecución se aplicará precisamente a los ficheros que has seleccionado. Muy útil ¿verdad?, pero es un poco peñazo tener que escribir scripts a estas alturas, precisamente tú, que no te gusta teclear comandos. ;-)

Afortunadamente, alguien ha hecho ese trabajo por tí. Vete a la página Nautilus File Manager Scripts y encontrarás una buena colección. Puedes bajártelos todos, si quieres, o solo algunos. Los más interesantes, para mí son:

1. archiver-unarchiver: Comprime y descomprime en múltiples formatos, los ficheros seleccionados (o todo un directorio).
2. chmod: Interfaz gráfica para modificar los permisos de los ficheros seleccionados.
3. copyhome: Copia los ficheros seleccionados a tu $HOME.
4. filetype: Informa del tipo de fichero.
5. gedit: Edita el fichero seleccionado con gedit. Puede modificarse fácilmente para que edite con gvim, por ejemplo. ;-)
6. ggrep: Interfaz gráfico para grep.
7. gtk2-du: Informa de cuanto ocupan los ficheros seleccionados.
8. mail_in_evolution: Envia los ficheros seleccionados por correo electrónico, usando Evolution, como archivos adjuntos.
9. moveup: Mueve los ficheros seleccionados al directorio padre.
10. open_terminal_here: Abre un gnome-terminal justo en ese directorio. Por si quieres teclear, después de todo. ;)
11. play_in_xmms: Toma los ficheros seleccionados y los reproduce uno a uno en el XMMS.
12. print: Imprime los ficheros seleccionados.
13. rotate_jpg_left: Gira esa foto a la izquierda.
14. rotate_jpg_right: Gira esa foto a la derecha.
15. scp_to_host: Abre una conexión segura con otro ordenador y transfiere los ficheros seleccionados.
16. Unexec: Elimina el bit de ejecutable en los ficheros de ese directorio y todos sus subdirectorios. Pero solo en los ficheros, no toca los propios directorios. Parece una chorrada, pero si tienes un CD grabado en formato Joliet (el que usa Windows) verás que TODOS los ficheros tienen ese bit, lo que es bastante molesto, si tu interfaz es coloreada.
17. xine: Ejecuta los ficheros seleccionados en Xine, como video digital.

Estos son los que yo encontré más interesantes, pero hay más, muchos más. :-)