El servidor gráfico

Es muy común en Unix que las cosas no sean tan simples como parecen. Casi todas las herramientas que forman el sistema operativo GNU/Linux son de gran potencia, es muy normal que después de varios años usando un programa descubramos una opción en el manual que va de perlas para ahorrarnos algunas preocupaciones. Esto choca completamente conla concepción moderna del software. En ella se dice que si una característica de tu programa está tan escondida que nadie la puede ver, entonces no sirve de nada. Las aplicaciones en el mundo Unix ofrecen una cara mucho más amable de la que tienen en realidad.

Un ejemplo claro de ello es el entorno gráfico. Ahora es cuando recordamos que el título de la sección es "El servidor gráfico". ¿Qué tienen que ver los gráficos con los servidores? Aparentemente es una comparación sin sentido como la que se lanzaría entre los routers y el hábitat de la avutarda.

En Windows los gráficos son gestionados directamente por el driver. Los programas hablan a una biblioteca gráfica que se comunica directamente con el hardware de la tarjeta gráfica. Los que sepan de gráficos tridimensionales y de realidad virtual estarán pensando en OpenGL y Direct3D. Estas bibliotecas son en realidad un interfaz para asignar procesos a la GPU (Graphic Process Unit). Windows utiliza esta arquitectura.

En cambio Linux, como el resto de entornos Unix, utiliza el esquema de servidor-protocolo-cliente. Significa que para conseguir ventanitas a colores es necesario encender un cliente llamado display manager que se conecta a un servidor gráfico utilizando un protocolo. El protocolo gráfico de Unix por excelencia es el protocolo X. Sobre las parejas servidor-cliente existen dos implementaciones principales, la Xfree86 y la de X.org. La segunda es una derivación de la primera por desavenencias en las licencias y en la concepción del desarrollo; es la que se está imponiendo.

Cuando en Linux utilizamos un entorno gráfico programado con alguna biblioteca como Qt o GTK+ estamos en realidad comunicándonos con un servidor gráfico que contiene las librerías gráficas y las aplicaciones. Es el cliente el que se comunica con la tarjeta gráfica a nivel de hardware. Esto no significa que siempre sea así, también se pueden utilizar métodos de renderizado directo en la tarjeta gráfica pero lo más habitual operar de este modo.

Este diseño tiene una gran ventaja respecto al uso directo del hardware. La existencia de una comunicación permite que el cliente y el servidor no estén en el mismo ordenador. Significa esto que puedo renderizar en mi monitor de Madrid una ventana de una aplicación que en realidad se está ejecutando en Hong Kong. Probablemente no sea conveniente con comunicaciones a tan larga distancia pero en una red local es perfectamente factible crear un servidor central de aplicaciones de este modo.

Aún hay más. Existe una variación del protocolo X llamado NX. No es más que el mismo protocolo con un tipo especial de compresión en vivo. Mostrar una ventana conectándose al servidor por internet no es factible por la gran cantidad de información que debe transmitirse en un tiempo récord. La solución es reducir las comunicaciones al mínimo para reducir los tiempos de espera y de latencia. El funcionamiento de NX es espectacular y muy sorprendente.

Otra posibilidad es implementar el servidor X bajo otro sistema operativo. Hay muchas apliciones que están tan íntimamente unidas al protocolo X que portarlas a otro tipo de sistema gráfico es casi imposible (muy importante el casi). Lo que se ha hecho para solucionarlo es portar el servidor X. Portarlo no es del todo correcto, se ha compatibilizado mediante Cygwin. Aunque su instalación no es sencilla otorga a Windows una gran potencia. Si instalamos un servidor X en Windows con unas pocas herramientas más seremos capaces de mostrar aplicaciones Linux que estén en otros ordenadores.

Esta tecnología es conceptualmente muy compleja. Por eso he empezado con la complejidad real de un sistema Unix. No es necesario entender todo esto, en el fondo la arquitectura es transparente al usuario, pero es un caso curioso de la verdadera potencia de Linux, un mejor diseño.

Montar un dispositivo.

Este tema es completamente distinto al anterior pero ya que hemos hablado de un concepto sorprendente de Linux pasaremos directamente a otro quizás más sorprendente: montar un dispositivo.

Cuando nos dicen que montemos un disco duro lo que nos viene a la cabez a es abrir la caja del ordenador y, armados con un destornillador, conectemos el disco para hacerlo funcionar. La manera en la que Unix gestiona el hardware es completamente distinta de la de Windows.

En Windows, cuando el sistema descubre un dispositivo inmediatamente lo hace accesible al sistema. El usuario no tiene poder para decidir qué dispositivos están activos y cuáles están reconocidos pero desactivados. No es lo mismo que ocultar un disco. Significa que el sistema operativo ha reservado una posición de memoria desde la que se accede al dispositivo pero no podemos comunicarnos por él porque no lo hemos "montado".

Montar significa dar a un dispositivo reconocido por el sistema operativo una cara visible para el usuario. Imaginemos que en Windows tuviéramos un segundo disco duro. Supongamos que Windows se comportara de la misma manera que Unix y nosotros no hubiéramos montado el dispositivo. En Mi PC el disco duro aparecería como: (Unidad de disco esclava en el puerto IDE 1). Montarla sería que nosotros le dijéramos que queremos la unidad en el directorio Z:

Lo verdaderamente potente es que nadie nos impide, en vez de asignarle el directorio Z: asignarle el C:\Documents and settings\Guillem Borrell\Mi segundo disco. Esto sí es sorprendente para un usuario de Wundows. Acabamos de introducir un disco duro en el árbol de directorios contenido en otro disco duro. ¿¿Qué??

Si lo pensamos un poco esto sólo es posible si nuestro árbol de directorios es completamente independiente de las unidades de disco. Cuando en Windows se acopla un disco USB el sistema lo tiene claro: una nueva unidad de disco es un nuevo árbol de directorios. En cambio el árbol de directorios Unix es único. Cuando en el fascículo 6 se habló de dicho árbol no se dijo en ningún momento que fuera el de C:. Si acoplamos un disco USB a nuestro ordenador lo más probable es que HAL (Hardware Abstraction Layer) lo monte asignandole el directorio /media/usbdisk1.

¿Cómo es todo esto posible? Pues definiendo cada dispositivo como un archivo dentro del árbol de directorios. Para ello está el directorio /dev y un sistema de archivos virtual que es en realidad una interfaz del núcleo del sistema operativo. En /dev están todos los dispositivos que el núcleo ha reconocido; inmediatamente les ha asignado un archivo para definirlos; por ejemplo la primera partición del disco duro primario es /dev/hda1 y el ratón está en /dev/input/mouse0. Oviamente el ratón no tiene ningún archivo asociado con lo que no será necesario montarlo en un directorio, pero /dev/hda1 sí. Uno de los primeros pasos del arranque es montar la partición primaria de disco con el comando “mount /dev/hda1 /”. Esto significa que estamos montando la la primera partición del disco primaro en el directorio raíz.

Algunas conclusiones

Se que este tema ha sido bastante teórico pero la información que contiene no es esencial para utilizar un sistema operativo tipo Unix. Que diga y repita que la consola es la herramienta más importante no significa que sea imprescindible. Las distribuciones Linux son cada vez más orientadas al usuario final de modo que alguien sin conocimiento alguno de informática puede ser productivo (aunque menos).