El sistema X Window ( X11 , o simplemente X ) es un sistema de ventanas para visualizaciones de mapas de bits , común en sistemas operativos tipo Unix .
X se originó como parte del Proyecto Athena en el Instituto Tecnológico de Massachusetts (MIT) en 1984. [3] 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 libre y de código abierto bajo la Licencia MIT y licencias permisivas similares.
X es un sistema independiente de la arquitectura para interfaces gráficas de usuario remotas y capacidades de dispositivos de entrada. Cada persona que utiliza un 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 interfaz y visualización completa, aunque simple, que ofrece un conjunto de herramientas estándar y una pila de protocolos para construir interfaces gráficas de usuario en la mayoría de los sistemas operativos tipo Unix y OpenVMS , y ha sido portado a muchos otros sistemas operativos contemporáneos de propósito general .
X proporciona el marco básico , o primitivos, para construir tales entornos GUI: dibujar y mover ventanas en la pantalla e interactuar con un mouse, teclado o pantalla táctil. X no impone la interfaz de usuario ; los programas cliente individuales se encargan de 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 enormemente; diferentes programas pueden presentar interfaces radicalmente diferentes.
A diferencia de la mayoría de los protocolos de visualización anteriores, X fue diseñado específicamente para ser utilizado a través de 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 alguna otra computadora en la red. El servidor X es típicamente el proveedor de recursos gráficos y eventos de teclado/ratón para clientes X , lo que significa que el servidor X generalmente se ejecuta en la computadora frente a un usuario humano, mientras que las aplicaciones 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 aplique al software que se encuentra frente al usuario suele sorprender a los usuarios acostumbrados a que sus programas sean clientes de servicios en computadoras remotas. Aquí, en lugar de que una base de datos remota sea el recurso para una aplicación local, la pantalla gráfica y los dispositivos de entrada del usuario se convierten en recursos que el servidor X local pone a disposición de los programas cliente X alojados local y remotamente que necesitan compartir los dispositivos gráficos y de entrada del usuario para comunicarse con él.
El protocolo de red de X se basa en primitivas de comandos X. Este enfoque permite que tanto las operaciones 2D como las 3D (a través de extensiones como GLX) de una aplicación cliente X que podría estar ejecutándose en una computadora diferente se aceleren por completo en la pantalla del servidor X. Por ejemplo, en OpenGL clásico (antes de la versión 3.0), las listas de visualización que contienen una gran cantidad de objetos se podían construir y almacenar completamente en el servidor X mediante un programa cliente X remoto, y luego cada una de ellas se podía renderizar enviando un único glCallList(which) a través de la red.
X no proporciona soporte nativo para audio; existen varios proyectos para llenar este nicho, algunos de los cuales también brindan soporte de red transparente .
X utiliza un modelo cliente-servidor: un servidor X se comunica con varios programas cliente . [4] El servidor acepta solicitudes de salida gráfica (ventanas) y devuelve la entrada del usuario (desde el teclado, el ratón o la pantalla táctil). El servidor puede funcionar como:
Esta terminología cliente-servidor (el terminal del usuario es el servidor y las aplicaciones son los clientes) suele confundir a los nuevos usuarios de X, porque los términos parecen estar invertidos. Pero X adopta 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 funciona de forma transparente en la red: el cliente y el servidor pueden funcionar en la misma máquina o en máquinas diferentes, posiblemente con diferentes arquitecturas y sistemas operativos. Un cliente y un servidor pueden incluso comunicarse de forma segura a través de Internet mediante la tunelización de la conexión a través de una sesión de red cifrada.
Un cliente X puede emular un servidor X al proporcionar servicios de visualización a otros clientes. Esto se conoce como "anidamiento X". Los clientes de código abierto como Xnest y Xephyr admiten este tipo de anidamiento X. [5]
Para ejecutar una aplicación cliente X en una máquina remota, el usuario puede hacer lo siguiente:
ssh -Xel comando para conectarse a la máquina remotaLuego, la aplicación cliente X remota establecerá una conexión con el servidor X local del usuario, brindándole visualización y entrada de información.
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.
Algunos ejemplos prácticos de clientes remotos incluyen:
.png/1280px-GNOME_Shell_41_with_GNOME_Web_(released_in_2021-09).png)
X define principalmente protocolos y primitivas gráficas; deliberadamente no contiene especificaciones para el diseño de la interfaz de usuario de la aplicación, como estilos de botones, menús o barras de título de ventanas. [6] En cambio, el software de aplicación (como administradores de ventanas, kits de herramientas de widgets de GUI y entornos de escritorio, o interfaces gráficas de usuario específicas de la aplicación) definen y proporcionan 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 gestor de ventanas controla la colocación y la apariencia de las ventanas de las aplicaciones. Esto puede dar lugar a interfaces de escritorio que recuerdan a las de Microsoft Windows o Apple Macintosh (por ejemplo, GNOME 2, KDE Plasma, Xfce) o tener controles radicalmente diferentes (como un gestor 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 gestores de ventanas varían en sofisticación y complejidad desde los más básicos ( por ejemplo , twm, el gestor de ventanas básico que se suministra con X, o evilwm, un gestor de ventanas extremadamente ligero) hasta los entornos de escritorio más completos, como Enlightenment, e incluso hasta gestores de ventanas específicos de aplicaciones para mercados verticales, como el punto de venta.
Muchos usuarios utilizan X con un entorno de escritorio que, además del gestor de ventanas, incluye varias aplicaciones que utilizan una interfaz de usuario coherente. Entre los entornos de escritorio más conocidos se encuentran GNOME , KDE Plasma y Xfce . El entorno estándar de UNIX 98 es el Common Desktop Environment (CDE). La iniciativa freedesktop.org aborda la interoperabilidad entre los escritorios y los componentes necesarios para un escritorio X competitivo.
La implementación de X.Org es la implementación canónica de X. Debido a la liberalidad de las licencias, han aparecido numerosas variantes, tanto de código abierto como de código propietario. Los proveedores comerciales de Unix han tendido a tomar la implementación de referencia y adaptarla a su hardware, generalmente personalizándola y añadiéndole extensiones de código propietario.
Hasta 2004, XFree86 era la variante más común de X en sistemas libres tipo Unix. XFree86 comenzó como una adaptación de X a PC compatibles con 386 y, a finales de los años 90, se había convertido en la mayor fuente de innovación técnica en X y en el estándar de facto de 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 forma de X11.app, pero eso ha quedado obsoleto en favor de la implementación de XQuartz . Los servidores de terceros bajo 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 viene con soporte para X, pero existen muchas implementaciones de terceros, como software libre y de código abierto como Cygwin/X , y productos propietarios como Exceed, MKS X/Server, Reflection X, X-Win32 y Xming .
También existen implementaciones de servidores X en Java. WeirdX se ejecuta en cualquier plataforma compatible con Swing 1.1 y se ejecutará como un subprograma en la mayoría de los navegadores. El servidor X de Android 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 del host separada o puede ejecutarse sin raíz , lo que significa que el escritorio X está oculto 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.
Una terminal X es un cliente ligero que sólo ejecuta un servidor X. Esta arquitectura se hizo popular para construir parques de terminales económicos para que muchos usuarios utilicen simultáneamente el mismo servidor informático grande para ejecutar programas de aplicación como clientes de la terminal X de cada usuario. Este uso está muy en línea con la intención original del proyecto MIT.
Los terminales X exploran la red (el dominio de difusió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 cliente debe ejecutar un administrador de pantalla X.
Una limitación de los terminales X y de la mayoría de los clientes ligeros es que no pueden realizar ninguna entrada o salida que no sea mediante el teclado, el ratón y la pantalla. Se supone que todos los datos relevantes existen únicamente en el servidor remoto y el usuario del terminal X no tiene métodos disponibles para guardar o cargar datos desde un dispositivo periférico local .
Los terminales X dedicados (de hardware) han caído en desuso; una PC o un cliente ligero moderno con un servidor X generalmente proporciona la misma funcionalidad al mismo costo o a un costo menor.
El Unix-Haters Handbook (1994) dedicó un capítulo completo a los problemas de X. [7] Why X Is Not Our Ideal Window System (1990) de Gajewska, Manasse y McCormack detalló los problemas del protocolo con recomendaciones para mejorarlos.
La falta de directrices de diseño en X ha dado lugar a varias interfaces muy diferentes y a aplicaciones que no siempre han funcionado bien juntas. El Manual de Convenciones de Comunicación entre Clientes (ICCCM), una especificación para la interoperabilidad de los clientes, tiene fama de ser difícil de implementar correctamente. Otros esfuerzos de normalización como Motif y CDE no aliviaron los problemas, lo que ha frustrado a los usuarios y a los programadores. [8] Los programadores de gráficos ahora suelen abordar la coherencia de la apariencia y la comunicación de las aplicaciones codificando para un entorno de escritorio específico o para un conjunto de herramientas de widgets específico, lo que también evita tener que tratar directamente con el ICCCM.
X también carece de soporte nativo para procedimientos almacenados definidos por el usuario en el servidor X, al estilo de NeWS : no hay una función de scripting Turing-complete . Por lo tanto, varios entornos de escritorio pueden ofrecer sus propias funciones (generalmente incompatibles entre sí).
Los sistemas basados en X pueden tener problemas de accesibilidad que dificultan la utilización de una computadora para usuarios discapacitados, incluyendo clic derecho , doble clic , clic central , mouse-over y focus stealing . Algunos clientes X11 manejan los problemas de accesibilidad mejor que otros, por lo que las personas con problemas de accesibilidad no se ven excluidas del uso de X11. Sin embargo, no existe ningún 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, las necesidades de accesibilidad están siendo abordadas por proyectos de software para proporcionar estas características sobre X.
El proyecto Orca añade soporte de accesibilidad al sistema X Window, incluyendo la implementación de una API ( AT-SPI [9] ). Esto se combina con ATK de GNOME para permitir que se implementen funciones de accesibilidad en programas X utilizando las API de GNOME/GTK. [10] KDE proporciona un conjunto diferente de software de accesibilidad, incluyendo un conversor de texto a voz y un magnificador de pantalla. [11] Los otros escritorios principales (LXDE, Xfce y Enlightenment) intentan ser compatibles con ATK.
Un cliente X no puede ser generalmente separado de un servidor y reconectado a otro a menos que su código específicamente lo provea ( Emacs es uno de los pocos programas comunes con esta habilidad). Como tal, mover una sesión entera de un servidor X a otro generalmente no es posible. Sin embargo, enfoques como Virtual Network Computing (VNC), NX y Xpra permiten que una sesión virtual sea alcanzada desde diferentes servidores X (de una manera similar a GNU Screen en relación a terminales), y otras aplicaciones y kits de herramientas proporcionan facilidades relacionadas. [12] Soluciones alternativas como x11vnc ( VNC :0 viewers ), el modo sombra de Xpra y el modo sombra nxagent de NX también existen para hacer que la pantalla actual del servidor X esté disponible. Esta habilidad permite que la interfaz de usuario (ratón, teclado, monitor) de una aplicación en ejecución sea cambiada 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 le permite ver todo lo que se muestra o se 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 , al utilizar X en una red, las limitaciones de ancho de banda pueden impedir el uso de aplicaciones que utilizan mapas de bits de forma intensiva y que requieren actualizar rápidamente grandes porciones de la pantalla con baja latencia, como la animación 3D o la edición de fotografías. Incluso una secuencia de vídeo relativamente pequeña sin comprimir de 640×480×24 bits a 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 pasar por alto el modelo de red y controlar directamente la tarjeta de vídeo, para el uso de vídeo de pantalla completa, aplicaciones 3D renderizadas y otras aplicaciones similares.
El diseño de X requiere que los clientes y el servidor operen por separado, y la independencia de los dispositivos y la separación del cliente y el servidor generan sobrecarga. La mayor parte de la sobrecarga proviene del tiempo de retardo de ida y vuelta de la red entre el cliente y el servidor ( latencia ) en lugar del protocolo en sí: las mejores soluciones a los problemas de rendimiento dependen de un diseño de aplicación eficiente. [13] Una crítica común a X es que sus características de red dan como resultado una complejidad excesiva y una disminución del rendimiento si solo se usa localmente.
Las implementaciones modernas de X utilizan sockets de dominio Unix para lograr conexiones eficientes en el mismo host. Además, se puede utilizar memoria compartida (a través de la extensión MIT-SHM ) para lograr una comunicación más rápida entre cliente y servidor. [14] Sin embargo, el programador debe activar y utilizar explícitamente la extensión de memoria compartida. También es necesario proporcionar rutas de respaldo para mantener la compatibilidad con implementaciones más antiguas y para comunicarse con servidores X no locales.
Algunas personas han intentado escribir alternativas y reemplazos para X. Las alternativas históricas incluyen NeWS de Sun y Display PostScript de NeXT , ambos sistemas basados en PostScript que admiten procedimientos del lado de visualización definibles por el usuario, de los que X carecía. Las alternativas actuales incluyen:
Otras formas de lograr una forma funcional de la característica de "transparencia de red" de X, a través de la transmisibilidad de red de servicios gráficos, incluyen:
Varios sistemas de visualización de mapas de bits precedieron a X. De Xerox llegaron Alto (1973) y Star (1981). De Apollo Computer llegó Display Manager (1981). De Apple llegaron Lisa (1983) y Macintosh (1984). El mundo Unix tuvo Andrew Project (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 (normalmente sistemas DEC VAX con Unix) fueran responsables de gestionar los eventos de exposición de ventanas y de actualizar el contenido de las ventanas 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 X en el alfabeto inglés ). W se ejecutaba bajo el sistema operativo V. W usaba un protocolo de red que admitía ventanas de terminal y gráficos, y el servidor mantenía las listas de visualización.
De: rws@mit-bold (Robert W. Scheifler) Para: window@athena Asunto: Sistema de ventanas X Fecha: 19 de junio de 1984 0907-EDT (martes) He pasado las últimas dos semanas escribiendo una ventana.Sistema para el VS100. Robé una buena cantidad de código.desde W, lo rodeó con un asincrónico más bienque una interfaz sincrónica, y la llamó X. En generalEl rendimiento parece ser aproximadamente el doble que el de W.El código parece bastante sólido en este punto, aunque hayTodavía quedan algunas deficiencias por corregir.En LCS hemos dejado de usar W y ahora estamos...construyendo aplicaciones activamente en X. ¿Alguien más está usandoW debería considerar seriamente cambiar. Esta no es laEl sistema de ventanas definitivo, pero creo que es bueno.punto de partida para la experimentación. Justo en este momentoHay una interfaz CLU (y una Argus) para X; una CLa interfaz está en desarrollo. Las tres existentesLas aplicaciones son un editor de texto (TED), un Argus I/Ointerfaz y un gestor de ventanas primitivo. HayAún no hay documentación; ¿alguien está lo suficientemente loco como para...?¿Voluntario? Quizás lo haga algún día.Cualquier persona interesada en ver una demostración puede pasarse por aquí.NE43-531, aunque es posible que desee llamar al 3-1945Primero, cualquiera que quiera el código puede venir con uncinta. Cualquiera que esté interesado en hackear deficiencias, siéntase librelibre 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 [20]
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 el DEC , el MIT e IBM para proporcionar un acceso sencillo 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 entonces en el Proyecto Andrew de la Universidad Carnegie Mellon no ofrecía licencias y no existían alternativas.
El proyecto resolvió este problema creando un protocolo que pudiera ejecutar aplicaciones locales y llamar a recursos remotos. A mediados de 1983, un puerto inicial de W para Unix funcionaba a una quinta parte de su velocidad en V; en mayo de 1984, Scheifler reemplazó el protocolo sincrónico de W por un protocolo asincrónico y las listas de visualización por gráficos de modo inmediato para convertir a X en la versión 1. X se convirtió en el primer entorno de sistema de ventanas que ofrecía 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 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 trasladaron X6 a la pantalla QVSS de DEC en MicroVAX .
En el segundo trimestre de 1985, X adquirió soporte de color para funcionar en la DEC VAXstation -II/GPX, formando lo que se convirtió en la versión 9.
Un grupo de la Universidad Brown adaptó la versión 9 al IBM RT PC , pero los problemas con la lectura de datos no alineados en el RT obligaron a un cambio de protocolo incompatible, lo que llevó a la versión 10 a fines de 1985. X10R1 fue lanzado en 1985. [21] Para 1986, organizaciones externas habían comenzado a solicitar X. X10R2 fue lanzado 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 este momento licenciar X10R3 y versiones futuras bajo lo que se conoció como la Licencia MIT , con la intención de popularizar aún más X y, a cambio, esperando que muchas más aplicaciones estuvieran disponibles. X10R3 se convirtió en la primera versión en lograr una amplia implementación, con DEC y Hewlett-Packard lanzando productos basados en él. Otros grupos trasladaron X10 a Apollo y a las estaciones de trabajo Sun e incluso al IBM PC/AT . En la feria Autofact de ese momento se llevaron a cabo demostraciones de la primera aplicación comercial de X (un sistema de ingeniería asistida por computadora mecánica de Cognition Inc. que se ejecutaba en VAXes y se mostraba de forma remota en PC que ejecutaban un servidor X adaptado por Jim Fulton y Jan Hardenbergh). 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, de manera similar a como Virtual Network Computing (VNC) permitiría más tarde compartir un escritorio. Uno de esos primeros esfuerzos fue la herramienta SharedX de Philip J. Gust .
Aunque X10 ofrecía una funcionalidad interesante y potente, se había hecho evidente que el protocolo X podría beneficiarse de un rediseño más neutral en cuanto al hardware antes de que se extendiera demasiado, pero el MIT por sí solo no tendría los recursos disponibles para un rediseño tan completo. En ese momento, el Laboratorio de Software Occidental de DEC se encontró entre dos proyectos con un equipo experimentado. Smokey Wallace de DEC WSL y Jim Gettys propusieron que DEC WSL creara X11 y lo pusiera a disposición de forma gratuita en 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. [22]
El diseño del protocolo X11, dirigido por Scheifler, fue ampliamente discutido en listas de correo abiertas en la naciente Internet que estaban conectadas a grupos de noticias de USENET. Gettys se mudó a California para ayudar a dirigir el trabajo de desarrollo de X11 en WSL desde el Centro de Investigación de Sistemas del DEC, donde Phil Karlton y Susan Angebrandt dirigieron el diseño e 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.
A finales de los años 1980, X era, como escribió Simson Garfinkel en 1989, "el logro individual más importante de Athena hasta la fecha". Según se informa, DEC creía que su desarrollo por sí solo había hecho que la donación de la empresa al MIT valiera la pena. Gettys se unió al equipo de diseño de VAXstation 2000 para garantizar que X (al que DEC llamó DECwindows ) se ejecutara en él, y la empresa asignó 1.200 empleados para trasladar X tanto a Ultrix como a VMS. [23] [24] En 1987, cuando se hizo evidente el éxito de X11, el MIT quiso renunciar a la administración de X, pero en una reunión de junio de 1987 con nueve proveedores, estos 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 Consorcio MIT X se formó como un grupo de proveedores sin fines de lucro, con Scheifler como director, para dirigir el desarrollo futuro de X en una atmósfera neutral que incluyera intereses comerciales y educativos.
Jim Fulton se unió en enero de 1988 y Keith Packard en marzo de 1988 como desarrolladores senior , con Jim centrándose en Xlib , fuentes , gestores 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 kits de herramientas y conjuntos de widgets, trabajando en estrecha colaboración con Ralph Swick del Proyecto Athena del MIT. El Consorcio MIT X produjo varias revisiones significativas de X11, la primera (Release 2 - X11R2) en febrero de 1988. Jay Hersh se unió al personal en enero de 1991 para trabajar en la funcionalidad PEX y X113D. Poco después le siguieron Ralph Mor (que también trabajó en PEX) y Dave Sternlicht. En 1993, cuando el Consorcio MIT X se preparaba para salir del MIT, se unieron al personal R. Gary Cutbill, Kaleb Keithley y David Wiggins. [25]
En 1993, se formó el Consorcio X, Inc. (una corporación sin fines de lucro) como sucesor del Consorcio X del MIT. Lanzó X11R6 el 16 de mayo de 1994. En 1995 se hizo cargo del desarrollo del kit de herramientas Motif y del entorno de escritorio común 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. [26] [27]
En enero de 1997, el Consorcio X transfirió la administración de X a The Open Group , un grupo de proveedores formado a principios de 1996 mediante la fusión de la Open Software Foundation y X/Open .
El Open Group publicó X11R6.4 a principios de 1998. De manera controvertida, X11R6.4 se apartó de los términos liberales tradicionales de la licencia, ya que el Open Group buscaba asegurar la financiación para el desarrollo de X, y citó específicamente a XFree86 como una aplicación que no contribuía significativamente a X. [28] Los nuevos términos habrían hecho que X ya no fuera software libre : cero coste para uso no comercial, pero una tarifa para el resto. Después de que XFree86 pareciera estar a punto de bifurcarse , [29] el Open Group volvió a licenciar X11R6.4 bajo la licencia tradicional en septiembre de 1998. [30] El último lanzamiento del Open Group fue el parche 3 de X11R6.4.
XFree86 se originó en 1992 a partir del servidor X386 para IBM PC compatibles 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 un simple puerto de X hasta la implementación líder y más popular y el estándar de facto del desarrollo de X. [31]
En mayo de 1999, The Open Group formó X.Org. X.Org supervisó el lanzamiento de las versiones X11R6.5.1 en adelante. El desarrollo de X en ese momento estaba moribundo; [32] la mayor parte de la innovación técnica desde que el Consorcio X se había disuelto había tenido lugar en el proyecto XFree86. [33] En 1999, el equipo XFree86 se unió a X.Org como miembro honorario (no remunerado), [34] alentado por varias compañías de hardware [35] [ verificación fallida ] interesadas en usar XFree86 con Linux y en su estatus 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) crecía, X.Org permaneció inactiva [36] y el desarrollo activo se llevó a cabo principalmente dentro de XFree86. Sin embargo, se desarrolló un considerable disenso dentro de XFree86. El proyecto XFree86 sufrió la percepción de un modelo de desarrollo demasiado catedralicio ; los desarrolladores no podían obtener acceso a los commits de CVS [37] [38] y los vendedores tenían que mantener extensos conjuntos de parches [39] . En marzo de 2003, la organización XFree86 expulsó a Keith Packard, quien se había unido a XFree86 después del final del Consorcio X original del MIT, con un considerable malestar [40] [41] [42]
X.Org y XFree86 comenzaron a discutir una reorganización adecuada para fomentar adecuadamente el desarrollo de X. [43] [44] [45] Jim Gettys había estado presionando fuertemente por un modelo de desarrollo abierto desde al menos el año 2000. [46] 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 de licencias 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. [47] La cláusula agregada a la licencia se basó en la cláusula de publicidad de la licencia BSD original, que fue vista por la Free Software Foundation y Debian como incompatible con la Licencia Pública General GNU . [48] Otros grupos lo vieron como contrario al espíritu de la X original. Theo de Raadt de OpenBSD , por ejemplo, amenazó con bifurcar XFree86 citando preocupaciones de licencia. [49] El problema de la licencia, combinado con las dificultades para introducir cambios, dejó a muchos sintiendo que era el momento oportuno para una bifurcación. [50]
A principios de 2004, varias personas de X.Org y freedesktop.org formaron la Fundación X.Org , y el Open Group le dio el control del x.org nombre de dominio . Esto marcó un cambio radical en la gobernanza de X. Mientras que los administradores de X desde 1988 (incluido el X.Org anterior) 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 , [ cita requerida ] que se basa en la participación externa. La membresía estaba abierta a individuos, y la membresía corporativa era en forma de patrocinio. Varias corporaciones importantes como Hewlett-Packard actualmente [ ¿período de tiempo? ] 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, logrando un consenso aproximado entre los miembros de la comunidad. Las decisiones técnicas no las toma la junta directiva; en este sentido, está fuertemente modelada en base a la técnicamente no intervencionista Fundación GNOME . 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 los cambios de X11R6.6 fusionados. Gettys y Packard habían tomado la última versión de XFree86 bajo la antigua licencia y, al hacer hincapié en un modelo de desarrollo abierto y mantener la compatibilidad con la GPL, incorporaron a muchos de los antiguos desarrolladores de XFree86. [48]
Aunque X11 había recibido extensiones como soporte OpenGL durante la década de 1990, su arquitectura se había mantenido 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, incluida una arquitectura de fuentes "defectuosa" , un sistema de gráficos 2D "que siempre había estado destinado a ser aumentado y/o reemplazado", y problemas de latencia . [51] X11R6.8 salió en septiembre de 2004. Añadió nuevas características significativas, incluido el soporte preliminar para ventanas translúcidas y otros efectos visuales sofisticados, magnificadores de pantalla y miniaturas, y facilidades para integrarse con sistemas de visualización inmersiva 3D como el Proyecto Looking Glass de Sun y el proyecto Croquet . Las aplicaciones externas llamadas administradores de ventanas de composición proporcionan una política para la apariencia visual.
El 21 de diciembre de 2005, [52] X.Org lanzó X11R6.9, el árbol de código fuente monolítico para usuarios antiguos, y X11R7.0, el mismo código fuente separado en módulos independientes, cada uno de ellos mantenible en proyectos separados. [53] La Fundación lanzó X11R7.1 el 22 de mayo de 2006, unos cuatro meses después de 7.0, con mejoras considerables en las características. [54]
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. [55]
Los nombres propios del sistema aparecen en la página del manual como X; X Window System; X Versión 11; X Window System, Versión 11; o X11. [56]
El término "X-Windows" (en la forma del posteriormente lanzado "Microsoft Windows") no está oficialmente aprobado - el director de lanzamiento del Consorcio X, Matt Landau, declaró en 1993, "No existe tal cosa como 'X Windows' o 'X Window', a pesar del mal uso repetido de las formas por parte de las revistas comerciales" [57] - aunque ha sido de uso informal común desde el comienzo de la historia de X [58] y se ha utilizado deliberadamente para un efecto provocador, por ejemplo en el Unix-Haters Handbook . [7]
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 "visualización", un subconjunto de los cuales se presenta aquí para mayor comodidad:
El término "pantalla" no debe confundirse con el término más especializado " pantalla Zaphod ". Esta última es una configuración poco común que permite que varios usuarios de una misma computadora tengan cada uno un conjunto independiente de pantalla, mouse y teclado, como si estuvieran usando computadoras separadas, pero a un menor costo por puesto.
Sobre la perspectiva de futuras versiones, el sitio web X.org afirma: [76]
X.Org continúa desarrollando y lanzando los componentes de software del sistema X Window.
Estos se lanzan individualmente a medida que cada componente está listo, sin esperar un cronograma de lanzamiento general "katamari" de X Window System: consulte el directorio de lanzamientos individuales de X.Org para descargas y los archivos xorg-announce o los repositorios git para obtener detalles sobre los cambios incluidos.
No se ha propuesto ningún plan de lanzamiento para una versión katamari acumulativa de X11R7.8.
Los administradores de X realmente se fueron desvaneciendo hasta casi desaparecer hace unos cinco o seis años. Realmente no seguían el ritmo de la tecnología.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}