Sistema de ventana X
El Sistema de ventanas X (X11, o simplemente X) es un sistema de ventanas para pantallas de mapas de bits, común en sistemas operativos tipo Unix..
X proporciona el marco básico para un entorno GUI: dibujar y mover ventanas en el dispositivo de visualización e interactuar con un mouse y un teclado. X no exige la interfaz de usuario; esto lo manejan los programas individuales. Como tal, el estilo visual de los entornos basados en X varía mucho; diferentes programas pueden presentar interfaces radicalmente diferentes.
X se originó como parte del Proyecto Athena en el Instituto Tecnológico de Massachusetts (MIT) en 1984. El protocolo X ha estado en la versión 11 (de ahí "X11") desde septiembre de 1987. La Fundación X.Org lidera el proyecto X, con la implementación de referencia actual, X.Org Server, disponible como software gratuito y de código abierto bajo la licencia MIT y licencias permisivas similares.
Propósito y habilidades
X es un sistema independiente de la arquitectura para interfaces gráficas de usuario remotas y capacidades de dispositivos de entrada. Cada persona que usa una terminal en red tiene la capacidad de interactuar con la pantalla con cualquier tipo de dispositivo de entrada de usuario.
En su distribución estándar, es una solución de visualización e interfaz completa, aunque simple, que ofrece un kit de herramientas estándar y una pila de protocolos para crear interfaces gráficas de usuario en la mayoría de los sistemas operativos tipo Unix y OpenVMS, y se ha adaptado a muchos otros sistemas contemporáneos. Sistemas operativos de propósito general.
X proporciona el marco básico, o primitivas, para construir tales entornos GUI: dibujar y mover ventanas en la pantalla e interactuar con un mouse, teclado o pantalla táctil. X no exige la interfaz de usuario; los programas de clientes individuales manejan esto. Los programas pueden usar las capacidades gráficas de X sin una interfaz de usuario. Como tal, el estilo visual de los entornos basados en X varía mucho; diferentes programas pueden presentar interfaces radicalmente diferentes.
A diferencia de la mayoría de los protocolos de visualización anteriores, X se diseñó específicamente para usarse en conexiones de red en lugar de en un dispositivo de visualización integrado o adjunto. X presenta transparencia de red, lo que significa que un programa X que se ejecuta en una computadora en algún lugar de una red (como Internet) puede mostrar su interfaz de usuario en un servidor X que se ejecuta en otra computadora en la red. El servidor X suele ser el proveedor de recursos gráficos y eventos de teclado/mouse para los clientes X, lo que significa que el servidor X generalmente se ejecuta en la computadora frente a un usuario humano, mientras que las aplicaciones del cliente X se ejecutan en cualquier parte de la red y se comunican con la computadora del usuario para solicitar la representación de contenido gráfico y recibir eventos de dispositivos de entrada, incluidos teclados y ratones.
El hecho de que el término "servidor" se aplica al software frente al usuario suele sorprender a los usuarios acostumbrados a que sus programas sean clientes de servicios en equipos remotos. Aquí, en lugar de que una base de datos remota sea el recurso para una aplicación local, la pantalla gráfica del usuario y los dispositivos de entrada se convierten en recursos que el servidor X local pone a disposición de los programas cliente X locales y remotos que necesitan compartir el usuario. #39;s gráficos y dispositivos de entrada para comunicarse con el usuario.
El protocolo de red de X se basa en las primitivas de comando X. Este enfoque permite que las operaciones 2D y (a través de extensiones como GLX) 3D por parte de una aplicación de cliente X que podría estar ejecutándose en una computadora diferente aún se aceleren por completo en la pantalla del servidor X. Por ejemplo, en el OpenGL clásico (antes de la versión 3.0), las listas de visualización que contenían una gran cantidad de objetos podían construirse y almacenarse por completo en el servidor X mediante un programa cliente X remoto, y luego cada una de ellas se representaba enviando una única glCallList(que) a través del servidor X. red.
X no proporciona soporte nativo para audio; existen varios proyectos para llenar este nicho, algunos también brindan soporte de red transparente.
Arquitectura de software

X utiliza un modelo cliente-servidor: un servidor X se comunica con varios programas cliente. El servidor acepta solicitudes de salida gráfica (ventanas) y devuelve la entrada del usuario (desde el teclado, el mouse o la pantalla táctil). El servidor puede funcionar como:
- una aplicación que muestra una ventana de otro sistema de visualización
- un programa de sistema que controla la salida de vídeo de un PC
- una pieza dedicada de hardware
Esta terminología cliente-servidor (la terminal del usuario es el servidor y las aplicaciones son los clientes) a menudo confunde a los nuevos usuarios de X, porque los términos aparecen al revés. Pero X toma la perspectiva de la aplicación, en lugar de la del usuario final: X proporciona servicios de visualización y E/S a las aplicaciones, por lo que es un servidor; Las aplicaciones utilizan estos servicios, por lo que son clientes.
El protocolo de comunicación entre el servidor y el cliente opera de forma transparente en la red: el cliente y el servidor pueden ejecutarse en la misma máquina o en diferentes, posiblemente con diferentes arquitecturas y sistemas operativos. Un cliente y un servidor pueden incluso comunicarse de forma segura a través de Internet al canalizar la conexión a través de una sesión de red cifrada.
Un cliente X en sí mismo puede emular un servidor X proporcionando servicios de visualización a otros clientes. Esto se conoce como "Anidamiento de X". Los clientes de código abierto como Xnest y Xephyr admiten dicha anidación de X.
Escritorio remoto
Para ejecutar una aplicación de cliente X en una máquina remota, el usuario puede hacer lo siguiente:
- en la máquina local, abrir una ventana terminal
- uso
ssh -X
comando para conectarse a la máquina remota - solicitar un servicio de visualización / entrada local (por ejemplo, export export DISPLAY=[La máquina del usuario]:0 si no utiliza SSH con X reenvío habilitado)
La aplicación del cliente X remoto establecerá una conexión con el servidor X local del usuario, proporcionando visualización y entrada al usuario.
Alternativamente, la máquina local puede ejecutar un pequeño programa que se conecta a la máquina remota e inicia la aplicación cliente.
Los ejemplos prácticos de clientes remotos incluyen:
- administrar una máquina remota gráficamente (similar a usar escritorio remoto, pero con ventanas individuales)
- usando una aplicación cliente para unirse con muchos otros usuarios terminales en grupos de trabajo colaborativos
- ejecutar una simulación computacionalmente intensiva en una máquina remota y mostrar los resultados en una máquina de escritorio local
- ejecutar software gráfico en varias máquinas a la vez, controlado por una sola pantalla, teclado y ratón
Interfaces de usuario
X define principalmente las primitivas de protocolo y gráficos; deliberadamente no contiene ninguna especificación para el diseño de la interfaz de usuario de la aplicación, como botones, menús o estilos de barra de título de ventana. En cambio, el software de la aplicación, como los administradores de ventanas, los kits de herramientas de widgets de GUI y los entornos de escritorio, o las interfaces gráficas de usuario específicas de la aplicación, definen y brindan dichos detalles. Como resultado, no existe una interfaz X típica y varios entornos de escritorio diferentes se han vuelto populares entre los usuarios.
Un administrador de ventanas controla la ubicación y apariencia de las ventanas de las aplicaciones. Esto puede dar como resultado interfaces de escritorio que recuerdan a las de Microsoft Windows o Apple Macintosh (los ejemplos incluyen GNOME 2, KDE, Xfce) o tener controles radicalmente diferentes (como un administrador de ventanas en mosaico, como wmii o Ratpoison). Algunas interfaces, como Sugar o ChromeOS, evitan por completo la metáfora del escritorio y simplifican sus interfaces para aplicaciones especializadas. Los administradores de ventanas varían en sofisticación y complejidad, desde los básicos (por ejemplo,, twm, el administrador de ventanas básico suministrado con X, o evilwm, un administrador de ventanas extremadamente ligero) hasta los entornos de escritorio más completos, como Enlightenment. e incluso a gestores de ventanas de aplicaciones específicas para mercados verticales como el punto de venta.
Muchos usuarios usan X con un entorno de escritorio que, además del administrador de ventanas, incluye varias aplicaciones que usan una interfaz de usuario uniforme. Los entornos de escritorio populares incluyen GNOME, KDE Plasma y Xfce. El entorno estándar de UNIX 98 es el entorno de escritorio común (CDE). La iniciativa freedesktop.org aborda la interoperabilidad entre los escritorios y los componentes necesarios para un escritorio X competitivo.
Implementaciones
La implementación de X.Org es la implementación canónica de X. Debido a las licencias liberales, han aparecido una serie de variaciones, tanto gratuitas como de código abierto y propietarias. Los proveedores comerciales de Unix han tendido a tomar la implementación de referencia y adaptarla a su hardware, generalmente personalizándola y agregando extensiones propietarias.
Hasta 2004, XFree86 proporcionaba la variante X más común en sistemas libres tipo Unix. XFree86 comenzó como un puerto de X a PC compatibles con 386 y, a fines de la década de 1990, se había convertido en la mayor fuente de innovación técnica en X y en el estándar de facto del desarrollo de X. Sin embargo, desde 2004, el servidor X.Org, una bifurcación de XFree86, se ha vuelto predominante.
Si bien es común asociar X con Unix, los servidores X también existen de forma nativa dentro de otros entornos gráficos. El sistema operativo OpenVMS de VMS Software Inc. incluye una versión de X con Common Desktop Environment (CDE), conocido como DECwindows, como su entorno de escritorio estándar. Apple originalmente portó X a macOS en la forma de X11.app, pero eso ha quedado obsoleto a favor de la implementación de XQuartz. Los servidores de terceros con los sistemas operativos más antiguos de Apple en la década de 1990, System 7 y Mac OS 8 y 9, incluían MacX de Apple y eXodus de White Pine Software.
Microsoft Windows no se envía con soporte para X, pero existen muchas implementaciones de terceros, como software gratuito y de código abierto como Cygwin/X, y productos patentados como Exceed, MKS X/Server, Reflection X, X- Win32 y Xming.
También hay implementaciones Java de servidores X. WeirdX se ejecuta en cualquier plataforma compatible con Swing 1.1 y se ejecutará como un subprograma en la mayoría de los navegadores. Android X Server es una implementación de Java de código abierto que se ejecuta en dispositivos Android.
Cuando un sistema operativo con un sistema de ventanas nativo aloja X además, el sistema X puede usar su propio escritorio normal en una ventana de host separada o puede ejecutar rootless, lo que significa que el escritorio X es hidden y el entorno de ventanas del host administra la geometría y la apariencia de las ventanas X alojadas dentro de la pantalla del host.
Terminales X
Un terminal X es un cliente ligero que solo ejecuta un servidor X. Esta arquitectura se hizo popular para construir parques de terminales económicos para que muchos usuarios usaran simultáneamente el mismo servidor de computadora grande para ejecutar programas de aplicación como clientes de la terminal X de cada usuario. Este uso está muy alineado con la intención original del proyecto MIT.
Los terminales X exploran la red (el dominio de transmisión local) utilizando el Protocolo de control del administrador de pantalla X para generar una lista de hosts disponibles que están permitidos como clientes. Uno de los hosts del cliente debe ejecutar un administrador de pantalla X.
Una limitación de las terminales X y la mayoría de los clientes ligeros es que no tienen capacidad para ninguna entrada o salida que no sea el teclado, el mouse y la pantalla. Se supone que todos los datos relevantes existen únicamente en el servidor remoto, y el usuario de la terminal X no tiene métodos disponibles para guardar o cargar datos desde un dispositivo periférico local.
Los terminales X dedicados (hardware) han caído en desuso; una PC o un thin client moderno con un servidor X generalmente proporciona la misma funcionalidad al mismo costo o a un costo menor.
Limitaciones y críticas
The Unix-Haters Handbook (1994) dedicó un capítulo completo a los problemas de X. Por qué X no es nuestro sistema de ventanas ideal (1990) por Gajewska, Manasse y McCormack detallaron problemas en el protocolo con recomendaciones para mejorar.
Problemas de interfaz de usuario
La falta de pautas de diseño en X ha resultado en varias interfaces muy diferentes y en aplicaciones que no siempre han funcionado bien juntas. El Manual de convenciones de comunicación entre clientes (ICCCM), una especificación para la interoperabilidad del cliente, tiene la reputación de ser difícil de implementar correctamente. Otros esfuerzos de estándares como Motif y CDE no aliviaron los problemas. Esto ha frustrado a usuarios y programadores. Los programadores de gráficos ahora generalmente abordan la coherencia de la apariencia y la comunicación de la aplicación mediante la codificación en un entorno de escritorio específico o en un conjunto de herramientas de widget específico, lo que también evita tener que tratar directamente con el ICCCM.
X también carece de soporte nativo para los procedimientos almacenados definidos por el usuario en el servidor X, a la manera de NeWS: no hay una función de secuencias de comandos completa de Turing. Varios entornos de escritorio pueden ofrecer sus propias instalaciones (generalmente incompatibles entre sí).
Problemas relacionados con la accesibilidad de la computadora
Los sistemas basados en X pueden tener problemas de accesibilidad que dificulten el uso de una computadora para los usuarios discapacitados, incluidos el clic derecho, el doble clic, el clic central, el mouse-over y el robo de enfoque. Algunos clientes de X11 se ocupan de los problemas de accesibilidad mejor que otros, por lo que las personas con problemas de accesibilidad no tienen problemas para usar X11. Sin embargo, no existe un estándar de accesibilidad o pautas de accesibilidad para X11. Dentro del proceso de estándares X11 no hay un grupo de trabajo sobre accesibilidad; sin embargo, los proyectos de software están abordando las necesidades de accesibilidad para proporcionar estas funciones además de X.
El proyecto Orca agrega soporte de accesibilidad al sistema X Window, incluida la implementación de una API (AT-SPI). Esto se combina con el ATK de GNOME para permitir que se implementen funciones de accesibilidad en los programas X utilizando las API de GNOME/GTK. KDE proporciona un conjunto diferente de software de accesibilidad, que incluye un convertidor de texto a voz y una lupa de pantalla. Los otros escritorios principales (LXDE, Xfce y Enlightenment) intentan ser compatibles con ATK.
Red
Por lo general, un cliente X no se puede separar de un servidor y volver a conectar a otro a menos que su código lo permita específicamente (Emacs es uno de los pocos programas comunes con esta capacidad). Como tal, generalmente no es posible mover una sesión completa de un servidor X a otro. Sin embargo, enfoques como Virtual Network Computing (VNC), NX y Xpra permiten acceder a una sesión virtual desde diferentes servidores X (de manera similar a GNU Screen en relación con los terminales), y otras aplicaciones y conjuntos de herramientas brindan servicios relacionados. También existen soluciones alternativas como x11vnc (VNC:0 visores), el modo de sombra de Xpra y el modo de sombra nxagent de NX para que la pantalla del servidor X actual esté disponible. Esta capacidad permite cambiar la interfaz de usuario (mouse, teclado, monitor) de una aplicación en ejecución de una ubicación a otra sin detener y reiniciar la aplicación.
El tráfico de red entre un servidor X y clientes X remotos no está cifrado de forma predeterminada. Un atacante con un rastreador de paquetes puede interceptarlo, lo que permite ver todo lo que se muestra o envía desde la pantalla del usuario. La forma más común de cifrar el tráfico X es establecer un túnel Secure Shell (SSH) para la comunicación.
Al igual que todos los clientes ligeros, cuando se usa X en una red, las limitaciones de ancho de banda pueden impedir el uso de aplicaciones con uso intensivo de mapas de bits que requieren una actualización rápida de grandes porciones de la pantalla con baja latencia, como la animación 3D o la edición de fotos. Incluso una transmisión de video relativamente pequeña sin comprimir de 640 × 480 × 24 bits y 30 fps (~211 Mbit/s) puede superar fácilmente el ancho de banda de una red de 100 Mbit/s para un solo cliente. Por el contrario, las versiones modernas de X generalmente tienen extensiones como MESA que permiten optimizar la visualización local de los gráficos de un programa local para omitir el modelo de red y controlar directamente la tarjeta de video, para el uso de video de pantalla completa, renderizado en 3D. aplicaciones y otras aplicaciones similares.
Separación cliente-servidor
El diseño de X requiere que los clientes y el servidor funcionen por separado, y la independencia del dispositivo y la separación del cliente y el servidor generan gastos generales. La mayor parte de la sobrecarga proviene del tiempo de demora de ida y vuelta de la red entre el cliente y el servidor (latencia) en lugar del protocolo mismo: las mejores soluciones a los problemas de rendimiento dependen del diseño eficiente de la aplicación. Una crítica común de X es que sus características de red dan como resultado una complejidad excesiva y un rendimiento reducido si solo se usa localmente.
Las implementaciones X modernas usan sockets de dominio Unix para conexiones eficientes en el mismo host. Además, se puede emplear memoria compartida (a través de la extensión MIT-SHM) para una comunicación cliente-servidor más rápida. Sin embargo, el programador aún debe activar y usar explícitamente la extensión de memoria compartida. También es necesario proporcionar rutas de respaldo para mantener la compatibilidad con implementaciones anteriores y para comunicarse con servidores X no locales.
Competidores
Algunas personas han intentado escribir alternativas y reemplazos para X. Las alternativas históricas incluyen Sun's NeWS y NeXT's Display PostScript, ambos sistemas basados en PostScript que admiten procedimientos del lado de la pantalla definibles por el usuario, de los que X carecía.. Las alternativas actuales incluyen:
- macOS (y su contraparte móvil, iOS) implementa su sistema de ventana, que se conoce como Quartz. Cuando Apple Computer compró NeXT y utilizó NeXTSTEP para construir Mac OS X, reemplazó Display PostScript con Quartz. Mike Paquette, uno de los autores de Quartz, explicó que si Apple hubiera añadido soporte para todas las características que quería incluir en X11, no tendría mucho parecido a X11 ni sería compatible con otros servidores de todos modos.
- El plan 9 utiliza rio.
- Haiku tiene su propio sistema de ventana.
- HelenOS tiene su propio sistema de ventana.
- Android, que se ejecuta en el kernel de Linux, utiliza su propio sistema para dibujar la interfaz de usuario conocida como SurfaceFlinger. La renderización 3D es manejada por EGL.
- Wayland está siendo desarrollado por varios desarrolladores de X.Org como un reemplazo prospectivo para X. Funciona directamente con el hardware GPU, vía DRI. Wayland puede ejecutar un servidor X como compositor Wayland, que puede ser sin raíces. En 2013 se completó un puerto propietario del backend Wayland al Raspberry Pi. El proyecto alcanzó la versión 1.0 en 2012. Como Android, Wayland está basado en EGL.
- Mir era un proyecto de Canonical Ltd. con objetivos similares a Wayland. Mir tenía la intención de trabajar con dispositivos móviles usando chipsets ARM (un objetivo declarado era compatibilidad con Android-drivers) así como escritorios x86. Como Android, Mir/UnitySiguiente fueron basados en EGL. La compatibilidad con X cliente-aplicaciones se logró a través de Xmir. El proyecto se ha trasladado desde entonces a ser un compositor Wayland en lugar de ser un servidor de visualización alternativo.
- Otras alternativas intentan evitar la sobrecarga de X trabajando directamente con el hardware; tales proyectos incluyen DirectFB. La Infraestructura de Rendering Directo (DRI) proporciona una interfaz a nivel de kernel al framebuffer.
Formas adicionales de lograr una forma funcional de la "transparencia de la red" característica de X, a través de la transmisibilidad de red de los servicios gráficos, incluyen:
- Virtual Network Computing (VNC), un sistema de muy bajo nivel que envía mapas comprimidos a través de la red; la implementación Unix incluye un servidor X
- Protocolo de escritorio remoto (RDP), que es similar a VNC en propósito, pero se originó en Microsoft Windows antes de ser portado a sistemas similares a Unix; cf NX, GotoMyPc, etc.
- Citrix XenApp, un protocolo tipo X y pila de aplicaciones para Microsoft Windows
- Tarantella, que proporciona un cliente de guía remoto basado en Java para su uso en los navegadores web
Historia
Predecesores
Varios sistemas de visualización de mapa de bits precedieron a X. De Xerox llegaron Alto (1973) y Star (1981). De Apollo Computer vino Display Manager (1981). De Apple vinieron Lisa (1983) y Macintosh (1984). El mundo Unix tenía el Proyecto Andrew (1982) y la terminal Blit de Rob Pike (1982).
La Universidad Carnegie Mellon produjo una aplicación de acceso remoto llamada Alto Terminal, que mostraba ventanas superpuestas en la Xerox Alto y hacía que los hosts remotos (generalmente sistemas DEC VAX que ejecutan Unix) fueran responsables de manejar eventos de exposición de ventana y actualizar el contenido de la ventana según fuera necesario..
X deriva su nombre como sucesor de un sistema de ventanas anterior a 1983 llamado W (la letra que precede a la X en el alfabeto inglés). W se ejecutó bajo el sistema operativo V. W usó un protocolo de red compatible con terminales y ventanas gráficas, y el servidor mantuvo las listas de visualización.
Origen y desarrollo temprano
De: rws@mit-bold (Robert) W. Scheifler)A: ventana@athenaAsunto: ventana sistema XFecha: 19 Junio 1984 0907-EDT (Martes)He pasado las últimas semanas escribiendo una ventana sistema para el VS100. Robé una cantidad justa de código de W, la rodeó con un asincrónico que una interfaz sincronizada, y lo llamó X. En general el rendimiento parece ser aproximadamente el doble de W. El el código parece bastante sólido en este punto, aunque hay Aún quedan algunas deficiencias por arreglar. Nosotros en LCS hemos dejado de usar W, y ahora activamente la construcción de aplicaciones en X. Cualquiera más W debería considerar seriamente cambiar. Este no es el último sistema de ventanas, pero creo que es un buen punto de partida para la experimentación. Justo en este momento hay una interfaz CLU (y un Argus) a X; a C la interfaz está en los trabajos. Los tres existentes las solicitudes son un editor de texto (TED), un Argus I/O interfaz, y un gestor de ventana primitivo. Hay no documentación todavía; alguien lo suficientemente loco voluntario? Puedo llegar a él eventualmente. Cualquier persona interesada en ver una demo puede pasar por NE43-531, aunque quizás quieras llamar 3-1945 primero. Cualquier persona que quiera el código puede venir con un cinta. Cualquier persona interesada en hackear deficiencias, sentir libre de ponerse en contacto.
El correo electrónico en el que X fue presentado a la comunidad del Proyecto Athena en el MIT en junio de 1984
La idea original de X surgió en el MIT en 1984 como una colaboración entre Jim Gettys (del Proyecto Athena) y Bob Scheifler (del Laboratorio de Ciencias de la Computación del MIT). Scheifler necesitaba un entorno de visualización utilizable para depurar el sistema Argus. El Proyecto Athena (un proyecto conjunto entre DEC, MIT e IBM para proporcionar un fácil acceso a los recursos informáticos para todos los estudiantes) necesitaba un sistema de gráficos independiente de la plataforma para vincular sus sistemas heterogéneos de múltiples proveedores; el sistema de ventanas que se estaba desarrollando en el Proyecto Andrew de la Universidad Carnegie Mellon no ofrecía licencias y no existían alternativas.
El proyecto resolvió esto mediante la creación de un protocolo que podría ejecutar aplicaciones locales y llamar a recursos remotos. A mediados de 1983, un puerto inicial de W a Unix funcionó a una quinta parte de su velocidad bajo V; en mayo de 1984, Scheifler reemplazó el protocolo síncrono de W con un protocolo asíncrono y las listas de visualización con gráficos de modo inmediato para hacer la versión 1 de X. X se convirtió en el primer entorno de sistema de ventanas en ofrecer verdadera independencia de hardware e independencia de proveedor.
Scheifler, Gettys y Ron Newman se pusieron a trabajar y X progresó rápidamente. Lanzaron la versión 6 en enero de 1985. DEC, que entonces se preparaba para lanzar su primera estación de trabajo Ultrix, consideró que X era el único sistema de ventanas que probablemente estaría disponible a tiempo. Los ingenieros de DEC portaron X6 a la pantalla QVSS de DEC en MicroVAX.
En el segundo trimestre de 1985, X adquirió soporte de color para funcionar en DEC VAXstation-II/GPX, formando lo que se convirtió en la versión 9.
Un grupo de la Universidad de Brown transfirió la versión 9 a IBM RT PC, pero los problemas con la lectura de datos no alineados en el RT forzaron un cambio de protocolo incompatible, lo que llevó a la versión 10 a fines de 1985. Para 1986, organizaciones externas habían comenzado a solicitar X X10R2 se lanzó en enero de 1986, luego X10R3 en febrero de 1986. Aunque el MIT había licenciado X6 a algunos grupos externos por una tarifa, decidió en ese momento licenciar X10R3 y versiones futuras bajo lo que se conoció como la Licencia MIT, con la intención de popularizar X más y, a cambio, con la esperanza de que haya muchas más aplicaciones disponibles. X10R3 se convirtió en la primera versión en lograr una implementación amplia, y tanto DEC como Hewlett-Packard lanzaron productos basados en ella. Otros grupos portaron X10 a estaciones de trabajo Apollo y Sun e incluso a IBM PC/AT. En la feria comercial Autofact de ese hora. La última versión de X10, X10R4, apareció en diciembre de 1986. Se hicieron intentos para habilitar servidores X como dispositivos de colaboración en tiempo real, al igual que Virtual Network Computing (VNC) más tarde permitiría compartir un escritorio. Uno de esos primeros esfuerzos fue la herramienta SharedX de Philip J. Gust.
Aunque X10 ofrecía una funcionalidad interesante y poderosa, se hizo evidente que el protocolo X podría usar un rediseño más neutral en cuanto al hardware antes de que se implementara demasiado, pero el MIT por sí solo no tendría los recursos disponibles para un rediseño tan completo. Dio la casualidad de que el Laboratorio de Software Occidental de DEC se encontró entre proyectos con un equipo experimentado. Smokey Wallace de DEC WSL y Jim Gettys propusieron que DEC WSL cree X11 y lo haga disponible gratuitamente bajo los mismos términos que X9 y X10. Este proceso comenzó en mayo de 1986 y el protocolo se finalizó en agosto. Las pruebas alfa del software comenzaron en febrero de 1987, las pruebas beta en mayo; el lanzamiento de X11 finalmente se produjo el 15 de septiembre de 1987.
El diseño del protocolo X11, dirigido por Scheifler, se discutió extensamente en las listas de correo abiertas en la naciente Internet que se unieron a los grupos de noticias de USENET. Gettys se mudó a California para ayudar a liderar el trabajo de desarrollo de X11 en WSL desde el Centro de Investigación de Sistemas de DEC, donde Phil Karlton y Susan Angebrandt dirigieron el diseño y la implementación del servidor de muestra X11. Por lo tanto, X representa uno de los primeros proyectos de software libre y de código abierto distribuidos a gran escala.
El Consorcio MIT X y el Consorcio X, Inc.
A fines de la década de 1980, X era, escribió Simson Garfinkel en 1989, "el logro individual más importante de Athena hasta la fecha". Según los informes, DEC creía que su desarrollo por sí solo había hecho que la donación de la compañía al MIT valiera la pena. Gettys se unió al equipo de diseño de VAXstation 2000 para garantizar que X, que DEC llamó DECwindows, se ejecutaría en él, y la empresa asignó 1200 empleados al puerto X tanto para Ultrix como para VMS. En 1987, cuando se hizo evidente el éxito de X11, el MIT deseaba renunciar a la administración de X, pero en una reunión de junio de 1987 con nueve proveedores, los proveedores le dijeron al MIT que creían en la necesidad de una parte neutral para evitar que X se fragmentara en el mercado. En enero de 1988, el MIT X Consortium se formó como un grupo de vendedores sin fines de lucro, con Scheifler como director, para dirigir el desarrollo futuro de X en una atmósfera neutral que incluye intereses comerciales y educativos.
Jim Fulton se unió en enero de 1988 y Keith Packard en marzo de 1988 como desarrolladores sénior, y Jim se centró en Xlib, fuentes, administradores de ventanas y utilidades; y Keith reimplementando el servidor. Donna Converse, Chris D. Peterson y Stephen Gildea se unieron más tarde ese año, centrándose en juegos de herramientas y conjuntos de widgets, trabajando en estrecha colaboración con Ralph Swick del MIT Project Athena. El Consorcio MIT X produjo varias revisiones importantes de X11, la primera (Versión 2 - X11R2) en febrero de 1988. Jay Hersh se unió al personal en enero de 1991 para trabajar en la funcionalidad PEX y X113D. Le siguieron poco después Ralph Mor (quien también trabajó en PEX) y Dave Sternlicht. En 1993, cuando el MIT X Consortium se preparaba para partir del MIT, R. Gary Cutbill, Kaleb Keithley y David Wiggins se unieron al personal.
En 1993, se formó X Consortium, Inc. (una corporación sin fines de lucro) como sucesora del MIT X Consortium. Lanzó X11R6 el 16 de mayo de 1994. En 1995 asumió el desarrollo del kit de herramientas Motif y del Common Desktop Environment para sistemas Unix. El Consorcio X se disolvió a fines de 1996, produciendo una revisión final, X11R6.3, y un legado de creciente influencia comercial en el desarrollo.
El Grupo Abierto
En enero de 1997, el Consorcio X pasó la administración de X a The Open Group, un grupo de proveedores formado a principios de 1996 por la fusión de Open Software Foundation y X/Open.
The Open Group lanzó X11R6.4 a principios de 1998. De manera controvertida, X11R6.4 se apartó de los términos de licencia liberales tradicionales, ya que Open Group buscaba asegurar la financiación para el desarrollo de X, y mencionó específicamente que XFree86 no contribuía significativamente a X. Los nuevos términos habrían hecho que X ya no fuera software libre: costo cero para uso no comercial, pero una tarifa en caso contrario. Después de que XFree86 pareciera estar a punto de bifurcarse, Open Group volvió a otorgar la licencia X11R6.4 bajo la licencia tradicional en septiembre de 1998. El último lanzamiento de Open Group fue el parche 3 de X11R6.4.
X.Org y XFree86
XFree86 se originó en 1992 a partir del servidor X386 para PC compatibles de IBM incluido con X11R5 en 1991, escrito por Thomas Roell y Mark W. Snitily y donado al MIT X Consortium por Snitily Graphics Consulting Services (SGCS). XFree86 evolucionó con el tiempo desde solo un puerto de X hasta la implementación líder y más popular y el estándar de facto del desarrollo de X.
En mayo de 1999, The Open Group formó X.Org. X.Org supervisó el lanzamiento de las versiones X11R6.5.1 en adelante. X desarrollo en este momento se había vuelto moribundo; La mayor innovación técnica desde que se disolvió el Consorcio X había tenido lugar en el proyecto XFree86. En 1999, el equipo de XFree86 se unió a X.Org como miembro honorario (no remunerado), alentado por varias compañías de hardware interesadas en usar XFree86 con Linux y en su estado como la versión más popular de X.
En 2003, mientras la popularidad de Linux (y, por lo tanto, la base instalada de X) aumentaba, X.Org permaneció inactivo y el desarrollo activo tuvo lugar principalmente dentro de XFree86. Sin embargo, se desarrolló una disidencia considerable dentro de XFree86. El proyecto XFree86 sufría de una percepción de un modelo de desarrollo demasiado parecido a una catedral; los desarrolladores no pudieron obtener acceso a la confirmación de CVS y los proveedores tuvieron que mantener extensos conjuntos de parches. En marzo de 2003, la organización XFree86 expulsó a Keith Packard, que se había unido a XFree86 después de la finalización del MIT X Consortium original, con considerable resentimiento.
X.Org y XFree86 comenzaron a discutir una reorganización adecuada para nutrir adecuadamente el desarrollo de X. Jim Gettys había estado presionando fuertemente por un modelo de desarrollo abierto desde al menos 2000. Gettys, Packard y varios otros comenzaron a discutir en detalle los requisitos para la gobernanza efectiva de X con desarrollo abierto.
Finalmente, en un eco de la disputa por la licencia de X11R6.4, XFree86 lanzó la versión 4.4 en febrero de 2004 bajo una licencia más restrictiva que muchos proyectos que dependían de X encontraron inaceptable. La cláusula añadida a la licencia se basó en la cláusula de publicidad de la licencia BSD original, que la Free Software Foundation y Debian consideraban incompatible con la Licencia pública general de GNU. Otros grupos lo vieron en contra del espíritu del X original. Theo de Raadt de OpenBSD, por ejemplo, amenazó con bifurcar XFree86 citando problemas de licencia. El problema de la licencia, combinado con las dificultades para obtener cambios, hizo que muchos sintieran que había llegado el momento de una bifurcación.
La Fundación X.Org
A principios de 2004, varias personas de X.Org y freedesktop.org formaron la Fundación X.Org, y Open Group le otorgó el control del nombre de dominio x.org
. Esto marcó un cambio radical en la gobernanza de X. Mientras que los administradores de X desde 1988 (incluida la anterior X.Org) habían sido organizaciones de proveedores, la Fundación estaba dirigida por desarrolladores de software y utilizaba el desarrollo comunitario basado en el modelo de bazar, que se basa en sobre la participación exterior. La membresía se abrió a individuos, y la membresía corporativa se realizó en forma de patrocinio. Varias corporaciones importantes, como Hewlett-Packard, actualmente apoyan a la Fundación X.Org.
La Fundación asume un papel de supervisión sobre el desarrollo de X: las decisiones técnicas se toman según sus méritos al lograr un consenso general entre los miembros de la comunidad. Las decisiones técnicas no las toma la junta directiva; en este sentido, está fuertemente modelado en la Fundación GNOME técnicamente no intervencionista. La Fundación no emplea desarrolladores. La Fundación lanzó X11R6.7, el servidor X.Org, en abril de 2004, basado en XFree86 4.4RC2 con cambios X11R6.6 fusionados. Gettys y Packard habían tomado la última versión de XFree86 bajo la licencia anterior y, al enfatizar un modelo de desarrollo abierto y conservar la compatibilidad con GPL, incorporaron a muchos de los antiguos desarrolladores de XFree86.
Si bien X11 recibió extensiones como la compatibilidad con OpenGL durante la década de 1990, su arquitectura se mantuvo fundamentalmente sin cambios durante la década. Sin embargo, a principios de la década de 2000, se revisó para resolver una serie de problemas que habían surgido a lo largo de los años, incluido un "defectuoso" arquitectura de fuentes, un sistema de gráficos 2D "que siempre había tenido la intención de ser aumentado y/o reemplazado" y problemas de latencia. X11R6.8 salió a la luz en septiembre de 2004. Agregó nuevas características significativas, incluida la compatibilidad preliminar con ventanas translúcidas y otros efectos visuales sofisticados, magnificadores de pantalla y miniaturas, y facilidades para integrarse con sistemas de visualización inmersivos en 3D como el Proyecto Mirando de Sun. El vidrio y el proyecto Croquet. Las aplicaciones externas denominadas administradores de ventanas de composición proporcionan una política para la apariencia visual.
El 21 de diciembre de 2005, X.Org lanzó X11R6.9, el árbol fuente monolítico para usuarios heredados, y X11R7.0, el mismo código fuente separado en módulos independientes, cada uno de los cuales se puede mantener en proyectos separados. La Fundación lanzó X11R7.1 el 22 de mayo de 2006, unos cuatro meses después de 7.0, con considerables mejoras en las funciones.
El desarrollo de XFree86 continuó durante algunos años más, y la versión 4.8.0 se lanzó el 15 de diciembre de 2008.
Nomenclatura
Los nombres propios del sistema se enumeran en la página del manual como X; sistema de ventanas X; X Versión 11; Sistema X Window, Versión 11; o X11.
El término "X-Windows" (a la manera de 'Microsoft Windows' lanzado posteriormente) no está respaldado oficialmente; el gerente de lanzamiento de X Consortium, Matt Landau, declaró en 1993: 'No existe tal cosa como 'X Windows'. #39; o 'X Window', a pesar del repetido mal uso de los formularios por parte de los trapos comerciales" – aunque ha sido de uso informal común desde principios de la historia de X y se ha utilizado deliberadamente con efectos provocativos, por ejemplo, en el Manual de los enemigos de Unix.
Términos clave
El sistema X Window tiene un uso matizado de una serie de términos en comparación con el uso común, en particular "pantalla" y "pantalla", un subconjunto del cual se proporciona aquí por conveniencia:
- dispositivo
- Un dispositivo gráfico como una tarjeta gráfica de ordenador o el chipset gráfico integrado de un ordenador.
- monitor
- Un dispositivo físico como un CRT o una pantalla plana del ordenador.
- pantalla
- Un área en el que se pueden renderizar gráficos, ya sea a través del software solo en la memoria del sistema como con VNC, o dentro de un dispositivo gráfico, algunos de los cuales pueden renderizar en más de una pantalla simultáneamente, ya sea visible simultáneamente o intercambiable. Las pantallas intercambiables se establecen a menudo para ser notoriamente izquierdas y derechas unas de otras, volteando de uno a otro, ya que el puntero del ratón alcanza el borde del monitor.
- pantalla virtual
- Dos significados diferentes están asociados con este término:
- Una técnica que permite el cableado de un monitor alrededor de una pantalla corriendo en una resolución más grande que el monitor se muestra actualmente.
- Un efecto simulado por un gestor de ventana manteniendo la información de posición de ventana en un sistema de coordenadas más grande que la pantalla y permitiendo el panning simplemente moviendo las ventanas en respuesta al usuario.
- pantalla
- Una colección de pantallas, a menudo involucrando múltiples monitores, generalmente configurado para permitir que el ratón mueva el puntero a cualquier posición dentro de ellos. Las estaciones de trabajo basadas en Linux suelen ser capaces de tener múltiples pantallas, entre las cuales el usuario puede cambiar con una combinación de teclado especial como control-alt-función-key, girando simultáneamente todos los monitores de mostrar las pantallas de una pantalla a las pantallas en otra.
El término "pantalla" no debe confundirse con la jerga más especializada "Zaphod display". Esta última es una configuración rara que permite que múltiples usuarios de una sola computadora tengan cada uno un conjunto independiente de pantalla, mouse y teclado, como si estuvieran usando computadoras separadas, pero a un costo por asiento más bajo.
Historial de versiones
Versión | Fecha de lanzamiento | Cambios más importantes |
---|---|---|
X1 | Junio de 1984 | Primer uso del nombre "X"; cambios fundamentales que distinguen el producto de W. |
X6 | Enero de 1985 | Primera versión con licencia para un puñado de compañías externas. |
X9 | Septiembre de 1985 | Color. Primer lanzamiento bajo licencia MIT. |
X10 | Noviembre de 1985 | IBM RT PC, AT (running DOS), y otros. |
X10R2 | Enero de 1986 | |
X10R3 | Febrero de 1986 | Primera liberación de X libremente redistribuible. Las versiones anteriores requerían una licencia BSD fuente para cubrir cambios de código a init/getty para apoyar el inicio de sesión. Uwm hizo gerente de ventana estándar. |
X10R4 | Diciembre de 1986 | Última versión de X10. |
X11 | 15 de septiembre de 1987 | Primera liberación del protocolo actual. |
X11R2 | Febrero de 1988 | Primer X Consortium. |
X11R3 | 25 de octubre de 1988 | XDM. |
X11R4 | 22 de diciembre de 1989 | XDMCP, twm (desde el principio conocido como gestor de ventana de Tom) trajo como gestor de ventana estándar, mejoras de aplicaciones, extensión de forma, nuevas fuentes. |
X11R5 | 5 de septiembre de 1991 | X386 1.2, PEX, Xcms (gestión de color), servidor de fuentes, extensión de vídeo X. |
X11R6 | 16 de mayo de 1994 | ICCCM v2.0; Inter-Client Exchange; X Session Management; X Synchronization extension; X Image extension; XTEST extension; X Input; X Big Request; XC-MISC; XFree86 changes. |
X11R6.1 | 14 de marzo de 1996 | X Extensión de doble amortiguación; extensión de teclado X; extensión de disco X. |
X11R6.3 | X11R6.223 de diciembre de 1996 | Funcionalidad web, LBX. Último X Consorcio. X11R6.2 es la etiqueta para un subconjunto de X11R6.3 (Broadway) con las únicas características nuevas sobre R6.1 siendo XPrint y la implementación Xlib de escritura vertical y soporte de caracteres definido por el usuario. |
X11R6.4 | 31 de marzo de 1998 | Xinerama. |
X11R6.5 | 2000 | Publicación interna de X.org; no disponible públicamente. |
X11R6.5.1 | 20 de agosto de 2000 | |
X11R6.6 | 4 de abril de 2001 | Corrección de errores, cambios XFree86. |
X11R6.7.0 | 6 de abril de 2004 | Primera publicación de la Fundación X.Org, incorporando XFree86 4.4rc2. Distribución completa de usuarios finales. Eliminación de XIE, PEX y libxml2. |
X11R6.8.0 | 8 de septiembre de 2004 | Translucencia de ventana, XDamage, Multihead Distribuido X, XFixes, Composite, XEvIE. |
X11R6.8.1 | 17 de septiembre de 2004 | Seguridad fijada en libxpm. |
X11R6.8.2 | 10 de febrero de 2005 | Corrección de errores, actualizaciones de conductor. |
X11R7.0 | X11R6.921 de diciembre de 2005 | XServer 1.0.1, EXA, refactorización de código fuente principal. Desde la misma base de código fuente, la versión modular se convirtió en 7.0 y la versión monolítica de imake se congeló en 6.9. |
X11R7.1 | 22 de mayo de 2006 | XServer 1.1.0, mejoras de EXA, KDrive integrado, AIGLX, OS y mejoras de soporte de plataforma. |
X11R7.2 | 15 de febrero de 2007 | XServer 1.2.0, Eliminación de LBX y controlador de teclado incorporado, X-ACE, XCB, mejoras de autoconfig, limpiezas. |
X11R7.3 | 6 de septiembre de 2007 | XServer 1.4.0, Input hotplug, hotplug de salida (RandR 1.2), sondas DTrace, soporte de dominio PCI. |
X11R7.4 | 23 de septiembre de 2008 | XServer 1.5.1, XACE, PCI-rework, EXA speed-ups, _X_EXPORT, GLX 1.4, inicio y cierre más rápido. |
X11R7.5 | 26 de octubre de 2009 | XServer 1.7.1, Xi 2, XGE, soporte E-EDID, RandR 1.3, MPX, aceleración de puntero predecible, administrador de memoria DRI2, módulo de seguridad SELinux, eliminación adicional de bibliotecas y extensiones obsoletas. |
X11R7.6 | 20 de diciembre de 2010 | X Server 1.9.3, requisito XCB. |
X11R7.7 | 6 de junio de 2012 | X Server 1.12.2; extensión Sync 3.1: adds Fence object support; Soporte multitouch Xi 2.2; XFixes 5.0: Pointer Barriers. |
Versión antigua Última versión |
Sobre la perspectiva de futuras versiones, el sitio web de X.org afirma:
X. Org continúa desarrollando y liberando los componentes del software X Window System.
Estos son liberados individualmente ya que cada componente está listo, sin esperar un programa de liberación global del sistema X Window System "katamari" - ver el directorio individual de lanzamientos X.Org para descargas, y los archivos xorg-announce o repositorios git para detalles sobre cambios incluidos.
No se ha propuesto ningún plan de liberación para un lanzamiento de katamari X11R7.8.
Contenido relacionado
ÑU
Operador bastardo del infierno
Navegador