BeOSmAn's Blooog

¿No os ha pasado alguna vez que actualizáis un sistema Linux y, después de reiniciar, queréis quitar los kernels antiguos pero no sabéis cuáles son?

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 .

Cuando accedemos a un ordenador, generalmente lo hacemos en modo consola, es decir, estamos delante de la pantalla, el teclado y el ratón y todo lo que hagamos mediante la interfaz lo hacemos en la máquina que tenemos delante.

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 .

Los chicos de Microsoft se lo curran y han hecho un estudio donde se muestra el uso que los usuarios le damos al Explorador de Windows, esto es, cómo accedemos a las acciones para el tratamiento de archivos —mediante menús, iconos, teclas de acceso rápido, etc.— con el fin de “optimizar” estos componentes para mejorar la experiencia de usuario.

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 .

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

Los chicos de Ubuntu han desarrollado en las últimas versiones de este sistema operativo un nuevo concepto de bandeja del sistema (esa zona de la barra de menús donde se concentran iconos de aplicaciones en segundo plano) a lo que ellos llaman miniaplicación de indicadores (indicators applet en inglés); y es algo como esto (los iconos grises de la izquierda):

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…

¿Es normal que el nm-applet, la aplicación que gestiona las conexiones a redes en Ubuntu (el applet del NetworkManager), consuma más de 500 MB de memoria RAM después de tener el sistema arrancado menos de un día?

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.

Hace tiempo que comenté el problema de que GRUB2 se quedaba esperando la respuesta del usuario al hibernar Ubuntu.

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.

Cuando estás desarrollado alguna librería en Linux, es probable que durante este desarrollo no tengas la librería instalada en los directorios por defecto del sistema (que son /lib, /usr/lib y /usr/local/lib) por lo que cuando vayas a probar el programa que hace uso de esa librería se produzca el siguiente 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.

¿Recuerdan ustedes que comenté que mi previsión era que los procesadores ARM conquistasen el escritorio y que, probablemente, no sería Windows el sistema operativo que los controlase? Pues parece que Microsoft no quiere perder esa parte del pastel (como es lógico) y ya planea portar sus Windows a esta arquitectura.

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.