La solución más rápida era buscar el archivo /boot/grub/grub.cfg de GRUB 2 y mirar en la zona de abajo cuáles eran las entradas que había y cuáles sobraban. Y luego, ya, desinstalarlas con apt-get purge.

Pero como al hacer un cat sobre grub.cfg se muestra mucha información que cuesta descifrar de un sólo vistazo, he hecho un script (ya sabéis, prefiero hacer un script que hacer las cosas a mano ) que muestra las entradas de GRUB tal y como salen en el menú de inicio con el fin de identificarlas igual de rápido que al iniciar el sistema.

#!/bin/bash

FILE=/boot/grub/grub.cfg
PATTERN='menuentry'

cat $FILE | grep $PATTERN | while read; do
	LINE=${REPLY:11}
	PROCESSED=`echo $LINE | rev | cut -s -d"'" -f2 | rev`
	if [ "$PROCESSED" == "" ]; then
		PROCESSED=`echo $LINE | rev | cut -s -d'"' -f2 | rev`
	fi
	echo $PROCESSED
done

Si tampoco tenéis ganas de copiarlo y pegarlo, también lo podéis descargar. No os olvidéis de quitarle la extensión .txt (si queréis) para que se parezca más a un comando de Linux y de darle permisos de ejecución con chmod 755 .

En Linux existe un paquete de software llamado Aspell que es la base de la mayoría de correctores ortográficos que se usan en este sistema operativo. Y, Aspell, obviamente, también tiene muchas palabras de diferentes idiomas que usa para su cometido, sólo que los tiene en su formato interno.

Pero, ¿qué pasa cuando queremos obtener un diccionario para nuestros propios fines? Por ejemplo, para instalarlo como corrector ortográfico de Eclipse. Pues para ello, haremos uso, en Linux, del nombrado paquete Aspell en su forma de comando de consola. El famoso comando, que luego explicaré, es este:

$ aspell --lang=es dump master | aspell --lang=es expand | tr ‘ ‘ ‘\n’ > spanish-dict.txt

Este gran comando, en realidad son cuatro (separados por ‘|’ y el último por ‘>’):

1. aspell --lang=es dump master: Vuelca todas las palabras del diccionario interno de Aspell a formato de texto plano y una por línea, con la salvedad de que dichas palabras tienen códigos específicos para poder expandirlas (por ejemplo, poder expandir el infinitivo de un verbo en todas sus formas).
2. aspell --lang=es expand: Dada una entrada (que en el comando es la salida del comando anterior), expande cada palabra de cada línea en todas las que puede generar. Por ejemplo, lo que he comentado antes, un verbo en todas sus formas. Esta expansión se hace en la misma línea, es decir, todas las formas verbales, por ejemplo, aparecerán en la misma línea separadas por espacios.
3. tr ' ' '\n': La entrada de este comando es la salida del anterior, transformando todos los espacios en retornos de carro. Con esto se consigue que, ahora sí, cada palabra esté en una línea.
4. > spanish-dict.txt: Finalmente, la salida del comando anterior se redirige a un archivo cuyo nombre es “spanish-dict.txt”.

Ahora, en el archivo spanish-dict.txt tenemos 1 250 789 palabras, una por línea, que podremos usar para lo que queramos.

P.D.: Llegados a este punto, os podéis preguntar para qué sirven, además, estos diccionarios, porque sólo como corrector ortográfico podría parecer poco, ¿no? Pues lleváis razón. Una de las cosas donde más se utilizan estos diccionarios, a parte de corregirnos las faltas, es para crackear contraseñas. El método se llama ataque de diccionario y consiste en coger cada una de las palabras del archivo e ir probando si coinciden con la contraseña. Y, como la mayoría de las contraseñas que usamos son débiles, pues suele ser bastante rápido el descifrado.

Pero ¿qué pasa cuando queremos trabajar en otro ordenador pero sin movernos del nuestro? Bien porque está lejos, bien porque somos unos vagos…

En Windows es de sobra conocido el Protocolo de Escritorio Remoto, donde nos conectamos a cualquier ordenador con Windows cuyo equipo esté compartido (que acepte conexiones remotas) y tenemos, en una ventana o en pantalla completa, el escritorio completo del ordenador remoto con el que podemos trabajar como si estuviéramos delante.

Y, en Linux, ¿podemos hacer algo similar? La respuesta corta es: por supuesto. La respuesta larga incluye la siguiente explicación:

El sistema operativo GNU/Linux cuenta con un servidor gráfico (la aplicación que gestiona la interfaz gráfica de usuario) llamado X.org, que es una implementación del sistema X Window System. Este servidor es el programa encargado de gestionar las pantallas, las ventanas y, también, las conexiones remotas a otros equipos para tener interfaz gráfica remota. El protocolo usado para estas conexiones remotas, que es lo que nos interesa, se llama XDMCP.

Este servidor gráfico se apoya en otra aplicación, llamada Display Manager, encargada de iniciar dicho servidor gráfico a la vez que muestra la pantalla de acceso, es decir, donde se pone el usuario y la contraseña. Y seguro que los usuarios de Linux conocéis más de un gestor de pantalla: xdm, gdm, kdm, lightdm…

A partir de este punto donde ya sabemos, más o menos, cómo funciona esto de la gestión de la interfaz gráfica, lo que nos queda para habilitar el acceso remoto en Linux es configurar el gestor de pantalla (display manager) del ordenador remoto al que queremos acceder para que tenga activado el protocolo XDMCP.

Hay que tener en cuenta que cada gestor usado (como hemos dicho: gdm, kdm, lightdm…) tiene su propia configuración, pero para el más moderno y usado en la última versión de Ubuntu, lightdm, la configuración está en el archivo /etc/lightdm/lightdm.conf (para el resto se puede ver su configuración usando el manual o, en una consola, con el comando man <dm>). En este archivo de configuración hay que activar el protocolo XDMCP añadiendo las siguientes líneas en dicho archivo:

Y luego reiniciar el servidor lightdm —teniendo en cuenta que se cerrarán todas las sesiones— con el comando:

$ sudo service lightdm restart

Ya tenemos nuestro servidor funcionando y aceptando conexiones remotas. Y, ahora, para acceder a él, lo podemos hacer de dos formas:

La primera es usando el programa Xnest que se instala escribiendo el comando sudo apt-get install xnest. Luego, para lanzar la sesión remota hay que lanzar el comando:

$ Xnest :1 -query remote.server

En el caso de que tengáis en vuestro equipo más de una sesión gráfica iniciada, hay que cambiar el :1 por un número de pantalla que no está usado. Además, remote.server puede ser tanto el nombre de un servidor como su IP.

Con este comando se nos abrirá una ventana donde aparecerá la pantalla de acceso a nuestro servidor remoto como si estuviéramos delante de él.

La segunda opción es lanzar directamente las X (otra instancia del servidor X.org) desde un terminal mediante el comando:

$ X :1 -query remote.server

Hay que tener en cuenta lo mismo sobre el número de pantalla (:1) y el nombre del servidor que con Xnest.

Con este comando, en lugar de abrir una ventana, lo que hará será cambiar de terminal virtual (VT) —de forma similar a cuando cambiamos entre la interfaz gráfica y una consola con las teclas Ctrl+Alt+F1/F7— a, generalmente, el número 8 (Ctrl+Alt+F8) mostrándonos la pantalla de acceso al sistema remoto.

Con el segundo método realmente parece que estamos delante de la máquina remota ya que no hay ventanas de por medio que aparenten estar en un sistema virtualizado. Además, con las combinaciones de teclas Ctrl+Alt+Fx bastará para cambiar entre equipos de forma muy cómoda y muy rápida, teniendo tanto la sesión local como la sesión remota totalmente activas y funcionales.

Y realmente es muy cómodo no tener que desplazarse para trabajar en otros equipos cuando necesitas la interfaz gráfica. Aunque, bueno, ya sabéis que para administrar sistemas no hay nada mejor ni más rápido que una consola en modo texto, por supuesto .

Cuando se inicia el sistema operativo Haiku se presentan una serie de iconos para indicar en qué estado del inicio nos encontramos. Estos iconos significan lo siguiente:

• Inicializa los módulos del kernel.
• Monta el sistema de archivos principal en / (rootfs) y monta el sistema de archivos de los dispositivos en /dev (devfs).
• Inicializa el gestor de dispositivos.
• Monta el disco del sistema (/boot).
• Activa los módulos para controlar las características específicas de la CPU.
• Finalización del inicio de los subsistemas (que cargan módulos del disco principal en /boot).
• Carga en memoria e inicia el script (BootScript) que carga los servidores de inicio como el app_server o el input_server.

En una máquina virtual con VirtualBox (en un equipo moderno, todo hay que decirlo) tarda algo menos de 10 segundos en iniciar el sistema. Supongo que en hardware real tardará menos .

Pero resulta que, ya en el 2001, BeOS —y ahora Haiku— tenía su propio cuadro de diálogo de copia de archivos mediante el Tracker (el homólogo al Explorador de Windows) y, fijaos qué casualidad, era así:

¿Y ahora estos vienen con innovaciones? ¡Já!

Actualización: He notado que en Google Chrome no se ve correctamente la imagen del Tracker de Haiku así que, si esto os sucede, probad con Firefox donde no he detectado ningún problema.

Actualización 2: El problema de que se oculte la segunda imagen en Chrome es debido a la extensión AdBlock, así que basta con desactivarla para que se vea dicha imagen (o añadir una excepción, pero no se como se hace ).

Conforme a este estudio, el nuevo rediseño del Explorador… bueno, deja un poco que desear, teniendo en cuenta que han creado una barra de herramientas mucho más grande e intrusiva que las anteriores con acciones que los usuarios apenas usan (menos del 1 % de las veces se usa la opción de la barra de herramientas en detrimento de otras opciones como el menú contextual o una tecla de acceso rápido).

Pero eso no es lo que quiero destacar aquí. Lo que quiero destacar es este gráfico:

Punto de entrada de los comandos en el Explorador de Windows

Es decir, según este gráfico, la mayoría de las acciones que un usuario hace en el Explorador de Windows —esto es, tratamiento de archivos— es mediante el menú contextual; luego mediante una combinación de teclas (teclas rápidas); lo siguiente es el uso de la barra de herramientas; y, finalmente, mediante el menú normal de toda la vida.

De este gráfico mi conclusión es que la barra de menús es un punto de entrada de comandos superfluo que, en cuanto estás acostumbrado a usar el software, obvias en favor de los menús contextuales y de las teclas de acceso rápido. Es decir, a mi parecer, la barra de menús sobraría en muchas interfaces de software.

Entonces, me pregunto ¿por qué los chicos de Apple se empeñan en mantener un menú global que ocupa una parte muy importante del escritorio y que, según el estudio de Microsoft, apenas se usaría?

Por poner un sólo ejemplo, esa zona de la pantalla se usa en Google Chrome y en Mozilla Firefox para acceder más rápidamente a las pestañas teniendo en cuenta que el ratón “no se sale” del borde de la pantalla.

Y esto ocurre con todas las interfaces que copian descaradamente la interfaz de Mac OS X (léase Gnome Shell, Unity…). Vamos, para mí es perder espacio y, sobre todo, funcionalidad y usabilidad. Pero no tengáis miedo de que en Mac OS X (y demás) lo quiten alguna vez (aunque sea por configuración). Ante todo hay que tener señas de identidad. Aunque no sean usables.

P.D.: Tengo en mente escribir algún día sobre las disposiciones de los elementos de los escritorio informáticos —esquinas, bordes…— y la tendencia de hoy en día. El problema es la falta de tiempo… y ganas .

Esta es la primera entrada que escribo desde el sistema operativo HaikuOS, el clon de mi querido BeOS, en una máquina virtual de VirtualBox.

Además, tanto la escritura en el blog como el pantallazo y la posterior edición de la imagen han sido hechas desde la versión R1A3 del propio Haiku —la imagen se editó con WonderBrush y el navegador es WebPositive—, con lo que se podría decir que el sistema operativo ya es bastante completo.

Obviamente todavía falta mucho por hacer, sobre todo teniendo en cuenta que no es un proyecto demasiado atractivo para el gran público y el número de desarrolladores está muy limitado, pero, aunque lento, va por buen camino.

Y quizás os preguntéis ¿por qué otro sistema operativo? La respuesta es sencilla: porque aunque BeOS es de principios de 1990, tanto BeOS como Haiku son los únicos sistemas operativos que se podrían considerar “modernos” ya que tanto su arquitectura principal como su API son innovadoras desechando modelos obsoletos y atreviéndose a hacer las cosas mejor sin mantener la compatibilidad.

¿Y eso es bueno? Yo opino que sí porque así que se consigue avance e innovación haciendo las cosas más rápidas y mejores. Pero es sólo una opinión .

En resumen, BeOS ya era muy rápido en mi Pentium II a 350 MHz (11 segundos en arrancar). Además, tanto en BeOS como ahora en Haiku, es muy fácil programar para ellos gracias a su API sencilla pero potente en C++. Y muchas otras virtudes y algún que otro defecto.

No pretendo con esto que hagáis de Haiku vuestro sistema principal (a día de hoy sería inviable) pero sí que le déis una oportunidad revisándolo de vez en cuando.

Todo este tinglado de letras y números en el título de la entrada no es más que para hacerse eco de la salida de la versión Release 1 Alpha 3 del sistema operativo Haiku, el clon libre de mi querido BeOS, un año y un mes después de la Alpha 2 (que no comenté aquí, por cierto).

Los cambios principales son:

• Hardware: mejor soporte de hardware con nuevos controladores.
• Sistemas de archivos: soporte para btrfs, ext4 y exFAT.
• Localización: soporte para traducir y localizar el sistema operativo.
• Layout API: nuevo API para la colocación de componentes en el desarrollo de aplicaciones.
• Aplicaciones: mejores en la funcionalidad y en las aplicaciones.
• Gestión de ventanas: apilado y ordenación de ventanas. Y con accesos directos de teclado.
• Multimedia: más formatos de audio y vídeo y mejoras en la reproducción de contenidos.
• Solución de errores: más de 950 incidencias resueltas desde la versión anterior.

En definitiva, el avance es lento de constante, lo que me lleva a pensar que, quizás, dentro de ¿un año? ¿dos años? podamos disfrutar de la primera versión de HaikuOS.

Por supuesto, hoy en día no es alternativa de uso; es, simplemente, para trastear, para aprender, para desarrollar… en definitiva, para quién le gusten las cosas bien hechas. Y sí, he dicho bien hechas. Hay mucha documentación sobre BeOS y Haiku para ver el porqué .

Pues la solución es bien sencilla, aunque muy chapucera. Basta con ejecutar el comando:

diego@ubuntu:~:$ compiz --replace &

Con esto se reinicia el decorador de ventanas y desaparecen los síntomas… al menos durante un rato.

Que esta sea una posible solución indica que es compiz quien falla, así que lo chicos de desarrollo deberían darle un repaso. A ver si pronto hay una buena actualización…

Esta nuevo sistema pretende imitar la manida bandeja del sistema de Windows donde aplicaciones en segundo plano incrustan su icono para tener constancia de su ejecución y poder realizar acciones sobre las mismas.

Y, a lo que voy: los iconos son muy bonitos, pero la funcionalidad es una basura. Siento ser tan duro, pero me fastidia mucho que involucionemos en lugar de evolucionar. Porque en cada icono de la antigua bandeja del sistema yo podía hacer clic, doble clic y clic con el botón secundario para realizar diferentes acciones, mientras que con este sistema sólo puedo hacer un clic normal y siempre saldrá un menú de acciones.

¿Es esto evolución? ¿Mejora esto la usabilidad del sistema?

A mi entender no. Mismamente, con la aplicación Dropbox (el primer icono empezando por la izquierda de la imagen), antes al hacer clic se abría la carpeta de Dropbox y, con el botón secundario, salía un menú. Ahora siempre sale un menú con el clic. ¿Dónde está el resto de funcionalidad?

¿Creen los desarrolladores de Ubuntu que eliminando funcionalidad se mejora la usabilidad? Yo creo que no.

Hasta aquí mi pataleta de hoy. Otro día seguiré con Unity, que para él tiene…

• La actualización ha transcurrido sin ningún problema aún usando el sistema mientras dura la misma. Eso sí, ha tardado unas 4 horas (o algo más) ya que tenía que descargar más de dos mil paquetes.
• Una vez reiniciado, en general el sistema va más rápido. Y esta es la conclusión a la que llego cada vez que actualizo por lo que no sé cuán objetiva es.
• Por defecto inicia Unity y no el escritorio clásico, con lo que, dependiendo de tus gustos, tendrás que volver al anterior (o no) que seguirá ahí.
• Por defecto instala gnome-wm como gestor de ventanas. Este archivo es un script que inicia compiz como gestor de ventanas siempre que pueda y, en caso de error, iniciará metacity (el antiguo de Gnome). Esto se puede cambiar fácilmente en la configuración (con gconf-editor). De mutter, el gestor de ventanas de Gnome3, no se sabe nada.
• En general compiz (y sus plugins) funciona bastante mejor en esta versión ganando en estabilidad y retocando algunas cosas en cuanto a la apariencia.
• Se desinstala el Java oficial de Sun (ahora Oracle) para instalar openjdk. Llevo usándolo unos días y funciona bien, aunque hace un tiempo no lo hacía.
• Se sustituye Rhythmbox (bonita palabra inglesa con 9 letras y sólo una vocal) por Banshee como reproductor de audio.
• Un fallo, a mi entender bastante grande, es que no se pueden reubicar los botones del panel de la lista de ventanas en el escritorio de Gnome clásico.
• Otro fallo, esta vez creo que es debido a compiz, es que, a veces, haciendo clic en la barra de título de una aplicación, esta gana el foco pero no se visualiza en dicha barra (esto es, no cambia de color ni indica nada que muestre que dicha ventana tiene el foco).
• Y el fallo más “raro” que me ha pasado es que parece que hay una ventana invisible en el medio de la pantalla de unos 300×100 píxeles (aproximados, que no se ve, sólo se intuye debido a los síntomas) que impide hacer clic sobre la ventana que esté debajo. Incluso cambia el cursor cuando estás en gedit, por ejemplo. La he identificado con el comando xwininfo y, al matarla con xkill, se ha reiniciado el gestor de ventanas y esta ventana invisible ha desaparecido (ya no hay síntomas).

Del resto todo bien. Creo que con cada versión que sacan los chicos de Ubuntu esto va a mejor, por supuesto sin desmerecer a los chicos del kernel, así que merece la pena la actualización.

Esta aplicación sirve para crear widgets del mismo estilo que el gestor de energía de Android 2.x (el widget con los botones para activar el Wifi, el Bluetooth, el GPS, la sincronización y el brillo) pero con un botón para (casi) cualquier acción posible dentro de la configuración de Android.

Además cuenta con varios estilos personalizados para hacerlo lo más parecido al tema que estés usando en cada momento pudiendo elegir tanto el color de fondo, el color de los iconos o el color de la barra que indica si el elemento está activado o no.

Lo mejor, a parte de la gran cantidad de configuración que tiene, es que es gratuita, aunque también existe una versión donate que cuesta 1 €.

Lo peor es que la interfaz no es muy amigable (la gente se empeña en crear su propia interfaz cuando el sistema ya trae la suya; y a veces no es la mejor opción).

Pero el problema más grave que he detectado es que consume muchísima batería. Al menos en estas versiones en mi Magic se pasa de durar la batería día y medio (uso normal) a durar ¡medio día! Además, aunque elimines todos los widgets, queda el servicio de Widgetsoid en ejecución. Espero que solucionen pronto esto porque es una aplicación muy interesante.

Y para que no lo pierda, mi configuración es:

• En el widget principal: Wifi, Bluetooth, GPS, temporizador de pantalla y brillo.
• En el secundario: sincronización, sincronizar ahora, activar/desactivar 2G/3G y activar/desactivar acceso a Internet (datos).

Pero, por supuesto, todo esto se puede configurar hasta llegar al extremo .

Después de buscar un rato, una de las razones que se dan es que, debido a las actualizaciones en lugar de a una reinstalación limpia del sistema operativo, puede que queden archivos de configuración incorrectos que dan lugar a este consumo excesivo de memoria.

Y después de seguir buscando… no aparece nada más excepto que este problema se da en bastante usuarios.

Una forma de mitigarlo es matar el proceso nm-applet en el administrador de procesos y, posteriormente, iniciarlo como root presionando Alt+F2 y ejecutando gksu nm-applet --sm-disable.

Así que, de momento, no hay resolución. Habrá que estar atento para que el proceso no se desboque y podamos seguir trabajando sin reiniciar.

Pues ese problema se produce en más ocasiones y, una de ellas, es que cuando el sistema operativo no se apaga correctamente, es decir, no se apaga con reboot o poweroff sino que hay un fallo en el sistema operativo o hay un fallo de corriente, al reiniciar de nuevo, a GRUB2 le da por esperar hasta que el usuario seleccione una de las entradas de su lista de sistemas operativos.

Eso no está nada mal cuando es un ordenador de escritorio, así puede saber que ha ocurrido un error y entrar en el modo seguro para solucionarlo. El problema viene cuando el sistema operativo se está ejecutando en un servidor que no tiene ni pantalla ni teclado. Te puedes tirar un día intentando conectar por ssh probando diferentes IP y diferentes cables hasta que, por fin, te decides ir a la sala donde está y poner un monitor y un teclado para ver, con entre sorpresa y cabreo, que llevas una jornada intentando conectar con GRUB porque está esperando a que algún usuario compasivo presione Enter.

Este es un error de GRUB, no es que haya una configuración rara por ahí, así está programado en sus scripts. Existe una variable de este cargador de arranque que se llama recordfail que es la que se fija cuando se apaga correctamente y que es la que hace esperar cuando hay un error.

Para intentar aplicar un parche para solucionarlo hay que editar dos archivos. El primero es el archivo /etc/default/grub. En ese archivo hay que comentar (con una almohadilla como primer carácter de la línea: #) la línea que contiene el texto GRUB_HIDDEN_TIMEOUT="0". Además, si estás en un servidor, también se pueden quitar los parámetros por defecto del kernel, quiet splash, para que salga la información de inicio en lugar de la agradable imagen de inicio del sistema.

El segundo archivo que hay que modificar es el archivo /etc/grub.d/00_header. Hay que modificar la función make_timeout() (a partir de la línea 238, más o menos) comentando (también con una almohadilla como primer carácter de la línea: #) la línea que pone set timeout=-1 y añadiendo, justo debajo, la línea set timeout=15, donde 15 es el número de segundos que esperará GRUB a iniciar en caso de error (en caso de que recordfail esté a 1). Y digo comentar en vez de sustituir la línea para que, en caso de que no funcione, se pueda volver sin problemas a la versión anterior de este archivo.

Con estos cambios conseguiremos que aunque el equipo no se apague correctamente, sí se inicie correctamente cuando vuelva la luz (o cuando se inicie de nuevo). Y, en caso de que el fallo sea de hardware o de software, no os preocupéis que el propio Linux ya indicará información sobre el error.

diego@box:~/projects/my_lib/test:$ ./test
test: error while loading shared libraries: libsxxx.so: cannot open shared object file: No such file or directory
diego@box:~/projects/my_lib/test:$

Para solucionarlo basta que con insertes en la variable de entorno LD_LIBRARY_PATH el directorio donde está esta librería:

diego@box:~/projects/my_lib/test:$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:../lib

Suponiendo que la librería está en ../lib.

Con esto ya se ejecutará tu programa de prueba sin problemas, aunque hay que tener en cuenta que cuando salgas de ese terminal esta variable va a volver a su valor original (que suele ser la cadena vacía).

Una vez que instales tu librería en alguna ruta del sistema (generalmente las librerías propias irán en /usr/local/lib) debes ejecutar el comando ldconfig para que se actualice la caché de librerías y todos los programas que la usen la encuentren sin problemas.

Dicen que Windows NT es (o era) bastante portable y que lleva años funcionando en procesadores ARM dentro de los laborarios de Microsoft, pero ¿cuánto de Windows NT tiene Windows 7?

Además, espero que sea rápido porque Android ya está muy metido en harina, sobre todo en tablets que, a mi entender, son el futuro cercano de las comunicaciones móviles junto con los teléfonos “inteligentes” o smartphones.

Estaremos atentos a los movimientos en el patio.