Primero, una pocas palabras sobre el servidor X, para quien no sepa cómo funciona. Es un servidor gráfico con todas las letras, toma control de la/las pantallas para dibujar cosas en ellas. Un programa cualquiera, es un cliente de este servidor. Cuando se inicia el programa se conecta al servidor y le pide que le reserve una ventana y le dibuje cosas en ella. La comunicación cliente/servidor es como una comunicación de red, a través de sockets. Entonces, desde el punto del cliente, da lo mismo si el servidor al cual se conecta está en su misma PC o está en otra del otro lado del mundo, lo único que cambia es la dirección que usa para abrir la comunicación, luego ni se entera. Internamente, las implementaciones de sockets sí hacen diferencia cuando el socket se conecta a un servidor local, para optimizar así esa comunicación y reducir al mínimo el overhead que agregan los protocolos de red. Pero eso es cosa el socket, al nivel del X no se ve. En conclusión, anda muy rápido cuando es local, pero anda igual de fácil cuando es remoto.
En el artículo sobre el X de Wikipedia hay un buen diagrama de cómo son las cosas con el servidor.
Hay que diferenciar aquí entre usar un X remoto y usar otra solución tipo VNC. Una cosa es renderizar la interfaz gráfica en una pc y enviar la foto a otra para que la otra la vea (más o menos lo que haría VNC), y otra muy distinta es enviar las primitivas a la otra para que sea la otra la que renderize. Es decir, en VNC, para mostrar "Hola" en una ventana remota, renderizo el "Hola" localmente y mando la foto del resultado a la otra. En X, mando el comando "Escribir 'Hola' en la ventana" a la otra PC, y es el servidor en la otra PC el que realmente lo renderiza en la pantalla. Mucha menos comunicación, y algo de trabajo delegado. Esto anda muy muy bien para aplicaciones sin tanto movimiento. Es decir, no vamos a jugar a un juego 3D por medio de un X remoto, pero sí podríamos por ejemplo editar un documento con LibreOffice.
¿Y qué tiene que ver con ZinjaI? Pues bien, en mi trabajo tengo una situación que supongo que no será tan inusual. Hay una PC de escritorio con mucho más capacidad de cálculo (micro y ram) que la que tiene mi notebook. Pero yo trabajo mucho mejor, más rápido y más cómodo en mi notebook, porque allí tengo mis atajos de teclado para los programas auxiliares, mis cuentas y marcadores en mi navegador, mis ejemplos y proyectos, el teclado al que estoy muy muy acostumbrado, datos sensibles que no quisiera pasar a una PC que comparto con mucha gente, etc. Entonces, lo que quiero es programar en mi notebook, pero utilizando el poder de cómputo de la PC de escritorio, para que el compilar, ejecutar y depurar sea mucho más rápido. Y ahí es donde el X remoto me resulta súper útil.
Ejecuto ZinjaI en la PC de escritorio, pero utilizando el servidor gráfico de la notebook. El resultado es que pareciera que ZinjaI está ejecutándose en la notebook (allí lo veo como una ventana más), pero en realidad es la PC de escritorio la que hace la mayor parte del trabajo. Especialmente compilar y ejecutar, que es lo "pesado". Y la forma de hacerlo es tan simple como todo lo que tanto me gusta de GNU/Linux y su filosofía KISS. En mi PC ejecuto "xhost +" para permitir el acceso a mi servidor X de clientes remotos, ya que (por seguridad) por defecto no se permite. Y en la otra PC agrego antes del comando de zinjai el seteo de la variable DISPLAY, que es la que dice a qué servidor conectarse. Si hacen "echo $DISPLAY" verán algo como ":0.0" o ":1.0", donde antes de los ':' va el IP del servidor (o nada si es local) y luego el número de monitor y de pantalla. Entonces, por ejemplo, con "DISPLAY=192.168.0.134:0.0 ./zinjai" ejecuto ZinjaI en una PC pero lo veo en la otra.
El diagrama pretende mostrar dónde se ejecuta y dónde se ve cada programa.
Pero hay más. Lo que tanto quiero correr en la PC más "poderosa" es un algoritmo de mallado en paralelo, que requiere varios cores y lleva algo de tiempo para ejecutarse. El resultado es además una malla (un montón de triangulitos o tetrahedros en un espacio 3D). Para ver el resultado, utilizo un programa basado en OpenGL, que debe dibujar ese montón de triangulitos (y el montón puede ser muy muy grande). Hacer esto de forma remota ya no sale tan bien (es como lo que decía antes de querer jugar), es lento. Entonces, voy a las opciones de ejecución de ZinjaI, y donde dice "Variables de entorno" pongo "DISPLAY=:0.0", para que cuando se ejecute se vea en el servidor local, en la PC de escritorio (la que efectivamente ejecuta, no el de la que solo muestra), donde de paso tengo una placa de video mucho mejor y entonces todo va más fluido que si lo hiciera en mi notebook (aunque fuera localmente).
En conclusión, esto de la arquitectura cliente-servidor tan transparente del X me permite programar en una pc, y compilar/ejecutar/depurar/etc en otra, viendo el resultado en la que yo quiera, y todo eso por el módico precio del seteo de una variable de entorno. No tuve que agregarle a ZinjaI ninguna funcionalidad para eso, ZinjaI jamás notará la diferencia. Por esta clase de cosas, digo que cuando Wayland finalmente se instale como reemplazo, al viejo y querido servidor X lo voy a extrañar. No quiere decir que sea una falla de Wayland, es solo que trabaja distinto, a más bajo nivel, lo cual le da otras muchas ventajas. Pero por eso los intentos por reproducir este aspecto del X todavía no han dado frutos. De todas formas, está claro que los veremos convivir por muchísimo tiempo antes de abandonarlo definitivamente.
excelente aporte!!!! de los mejores vistos PEROOOOOOOOO .... cambia el fondo, casi quedo ciego!!!!!
ResponderEliminar