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 gratuito 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 del 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 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 operativos contemporáneos de propósito general. sistemas .
X proporciona el marco básico , o primitivos, para construir dichos 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 cliente individuales manejan esto. Los programas pueden utilizar las capacidades gráficas de X sin 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 fue diseñado específicamente para usarse a través de conexiones de red en lugar de en un dispositivo de visualización integral 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 de la red. El servidor X suele ser el proveedor de recursos gráficos y eventos de teclado/ratón para los clientes X , lo que significa que el servidor X normalmente se ejecuta en la computadora frente a un usuario humano, mientras que las aplicaciones del cliente X se ejecutan en cualquier lugar 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 tiene delante el usuario suele sorprender a los usuarios acostumbrados a que sus programas sean clientes de servicios en ordenadores remotos. 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 locales y remotos que necesitan compartir los dispositivos de entrada y gráficos del usuario. 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 mediante una aplicación cliente X que podría estar ejecutándose en una computadora diferente aún estén completamente aceleradas en la pantalla del servidor X. Por ejemplo, en OpenGL clásico (antes de la versión 3.0), un programa cliente X remoto podía construir y almacenar listas de visualización que contuvieran una gran cantidad de objetos en su totalidad en el servidor X, y cada una de ellas luego se representaba enviando un único glCallList(que) a través del 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 . 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:
Esta terminología cliente-servidor (el terminal del usuario es el servidor y las aplicaciones son los clientes) a menudo confunde a los nuevos usuarios X, porque los términos aparecen invertidos. Pero X adopta la perspectiva de la aplicación, más que 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 ejecutarse 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 un túnel de la conexión a través de una sesión de red cifrada.
Un cliente X puede emular un servidor X proporcionando 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 de X.
Para ejecutar una aplicación cliente X en una máquina remota, el usuario puede hacer lo siguiente:
ssh -X
el comando para conectarse a la máquina remotaLa aplicación cliente X remota establecerá entonces una conexión con el servidor X local del usuario, proporcionando visualización e información 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.
Ejemplos prácticos de clientes remotos incluyen:
X define principalmente 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 estilos de botones, menús o barras de título de ventanas. [4] En cambio, el software de aplicación, como los administradores de ventanas, los kits de herramientas de widgets GUI y los entornos de escritorio, o las 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 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 Plasma, 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, simplificando sus interfaces para aplicaciones especializadas. Los administradores de ventanas varían en sofisticación y complejidad desde lo básico ( por ejemplo , twm, el administrador de ventanas básico suministrado con X, o evilwm, un administrador de ventanas extremadamente liviano) hasta entornos de escritorio más completos como Enlightenment e incluso ventanas específicas de aplicaciones. gerentes para mercados verticales como el punto de venta.
Muchos usuarios utilizan X con un entorno de escritorio que, además del administrador de ventanas, incluye varias aplicaciones que utilizan una interfaz de usuario coherente. 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 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 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, normalmente personalizándola y añadiendo extensiones propietarias.
Hasta 2004, XFree86 proporcionaba la variante X más común en sistemas libres tipo Unix. XFree86 comenzó como una adaptación de PC compatibles con X a 386 y, a finales 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 para el 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 a 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 se entrega con soporte para X, pero existen muchas implementaciones de terceros, como software gratuito y de código abierto como Cygwin/X , y productos propietarios 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 que admita Swing 1.1 y se ejecutará como un subprograma en la mayoría de los navegadores. Android X Server es una implementación Java de código abierto que se ejecuta en dispositivos Android.
Cuando un sistema operativo con un sistema de ventanas nativo hospeda X además, el sistema X puede usar su propio escritorio normal en una ventana de 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 apariencia de las ventanas X alojadas dentro de la pantalla del host.
Un 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 usaran simultáneamente el mismo servidor de computadora grande para ejecutar programas de aplicaciones como clientes del 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 X Display Manager 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 los terminales X y de la mayoría de los clientes ligeros es que no son capaces de realizar ninguna entrada o salida aparte del teclado, el mouse y la pantalla. Se supone que todos los datos relevantes existen únicamente en el servidor remoto y que 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 (hardware) han dejado de utilizarse; una PC o un cliente ligero moderno con un servidor X normalmente 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. [5] Why X Is Not Our Ideal Window System (1990) de Gajewska, Manasse y McCormack detallaron los problemas en el protocolo con recomendaciones para mejorar.
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 fama de ser difícil de implementar correctamente. Otros esfuerzos de normalización como Motif y CDE no aliviaron los problemas. Esto ha frustrado a usuarios y programadores. [6] Los programadores de gráficos ahora generalmente abordan la coherencia de la apariencia y la comunicación de las aplicaciones codificando en un entorno de escritorio específico o en 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, a la manera de NeWS : no existe una función de secuencias de comandos completa de Turing . Por tanto, varios entornos de escritorio pueden ofrecer sus propias funciones (normalmente mutuamente incompatibles).
Los sistemas construidos sobre X pueden tener problemas de accesibilidad que dificultan el uso de una computadora para usuarios discapacitados, incluyendo clic derecho , doble clic , clic central , pasar el mouse por encima y robo de foco . Algunos clientes de X11 abordan los problemas de accesibilidad mejor que otros, por lo que las personas con problemas de accesibilidad no quedan excluidas del uso de X11. Sin embargo, no existe un estándar de accesibilidad ni pautas de accesibilidad para X11. Dentro del proceso de estándares X11 no existe un grupo de trabajo sobre accesibilidad; sin embargo, las necesidades de accesibilidad se están abordando mediante proyectos de software 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 [7] ). Esto se combina con ATK de GNOME para permitir que se implementen funciones de accesibilidad en programas X utilizando las API de GNOME/GTK. [8] KDE proporciona un conjunto diferente de software de accesibilidad, que incluye un conversor de texto a voz y una lupa de pantalla. [9] Los otros escritorios principales (LXDE, Xfce y Enlightenment) intentan ser compatibles con ATK.
Por lo general, un cliente X no se puede desconectar 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 terminales), y otras aplicaciones y conjuntos de herramientas brindan instalaciones relacionadas. [10] También existen soluciones alternativas como x11vnc ( VNC:0 espectadores ), el modo de sombra de Xpra y el modo de sombra nxagent de NX para que la pantalla actual del servidor X esté disponible. Esta capacidad permite que la interfaz de usuario (ratón, teclado, monitor) de una aplicación en ejecución cambie de una ubicación a otra sin detener ni 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, haciendo posible ver cualquier cosa que se muestre o se envíe 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.
Como todos los clientes ligeros , cuando se utiliza 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 animación 3D o edición de fotografías. Incluso una transmisión 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 evitar el modelo de red y controlar directamente la tarjeta de video, para el uso de video en pantalla completa, aplicaciones renderizadas en 3D y otras. tales aplicaciones.
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 retardo de ida y vuelta de la red entre el cliente y el servidor ( latencia ) más que del protocolo en sí: las mejores soluciones a los problemas de rendimiento dependen de un diseño eficiente de la aplicación. [11] Una crítica común a X es que sus características de red resultan en una complejidad excesiva y un rendimiento reducido si solo se usa localmente.
Las implementaciones modernas de X utilizan 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. [12] Sin embargo, el programador aún debe activar y usar explícitamente la extensión de memoria compartida. También es necesario proporcionar rutas alternativas para seguir siendo compatible con implementaciones anteriores y para comunicarse con servidores X no locales.
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 soportan procedimientos de visualización definibles por el usuario, de los cuales X carecía. Las alternativas actuales incluyen:
Formas adicionales 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 surgieron el Alto (1973) y el Star (1981). De Apollo Computer surgió Display Manager (1981). De Apple surgieron 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 Xerox Alto y hacía que los hosts remotos (generalmente sistemas DEC VAX que ejecutan Unix) fueran responsables de manejar los eventos de exposición de ventanas y 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 ejecutó bajo el sistema operativo V. W utilizó un protocolo de red que soportaba terminales y ventanas gráficas, 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 ventanasistema para el VS100. Robé una buena cantidad de códigode W, lo rodeó con un asincrónico bastanteque una interfaz síncrona, 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 hayAún quedan algunas deficiencias por corregir.Nosotros en LCS hemos dejado de usar W y ahora estamoscreando aplicaciones activamente en X. Cualquier otra persona que useDeberíamos considerar seriamente cambiar. Este no es elsistema de ventanas definitivo, pero creo que es una buenapunto de partida para la experimentación. Justo en este momentohay una interfaz CLU (y Argus) para X; una CLa interfaz está en proceso. Los tres existentesLas aplicaciones son un editor de texto (TED), un Argus I/Ointerfaz y un administrador de ventanas primitivo. Hayaún no hay documentación; alguien lo suficientemente loco como para¿voluntario? Puede que con el tiempo lo haga.Cualquier persona interesada en ver una demostración puede visitarnos.NE43-531, aunque es posible que quieras llamar al 3-1945primero. Cualquiera que quiera el código puede venir con uncinta. Cualquier persona interesada en solucionar las deficiencias, sientalibre 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 [18]
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 fácil acceso a 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 entonces se estaba desarrollando en el Proyecto Andrew de la Universidad Carnegie Mellon no ofrecía licencias disponibles y no existían alternativas.
El proyecto resolvió esto creando un protocolo que podía ejecutar aplicaciones locales y solicitar recursos remotos. A mediados de 1983, una adaptación inicial de W a Unix funcionó a una quinta parte de su velocidad en 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 en modo inmediato para hacer de X 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 proveedores.
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 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 estación DEC VAX -II/GPX, formando lo que se convirtió en la versión 9.
Un grupo de la Universidad de Brown portó 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 finales de 1985. X10R1 se lanzó en 1985. [19] En 1986, fuera Las organizaciones habían comenzado a solicitar X. X10R2 se lanzó en enero de 1986, luego X10R3 en febrero de 1986. Aunque el MIT había otorgado licencias de X6 a algunos grupos externos pagando una tarifa, decidió en ese momento otorgar licencias de X10R3 y versiones futuras bajo lo que se conoció como el 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, y tanto DEC como Hewlett-Packard lanzaron productos basados en él. Otros grupos portaron X10 a estaciones de trabajo Apollo y Sun e incluso a IBM PC/AT . En la feria Autofact en ese tiempo. La última versión de X10, X10R4, apareció en diciembre de 1986. Se intentó habilitar los servidores X como dispositivos de colaboración en tiempo real, de la misma manera que 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 poderosa, se había vuelto obvio que el protocolo X podría necesitar un rediseño más neutral en cuanto al hardware antes de que se implementara demasiado ampliamente, 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 construyera X11 y lo pusiera a disposición de forma gratuita bajo los mismos términos que X9 y X10. Este proceso comenzó en mayo de 1986 y el protocolo 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. [20]
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 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 .
A finales 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 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, que DEC llamó DECwindows , se ejecutara en él, y la empresa asignó 1200 empleados para trasladar X tanto a Ultrix como a VMS. [21] [22] En 1987, cuando el éxito de X11 se hizo evidente, el MIT deseaba renunciar a la administración de X, pero en una reunión en 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 fragmente en el mercado. En enero de 1988, el MIT X Consortium 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 enfocándose 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 kits de herramientas y conjuntos de widgets, trabajando en estrecha colaboración con Ralph Swick del MIT Project Athena. El MIT X Consortium 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. Poco después le siguieron Ralph Mor (quien también trabajó en PEX) y Dave Sternlicht. En 1993, mientras el Consorcio MIT X se preparaba para abandonar el MIT, se unieron al personal R. Gary Cutbill, Kaleb Keithley y David Wiggins. [23]
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 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 finales de 1996, produciendo una revisión final, X11R6.3, y un legado de creciente influencia comercial en el desarrollo. [24] [25]
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 mediante la fusión de Open Software Foundation y X/Open .
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 fondos para el desarrollo de X, y citó específicamente a XFree86 por no contribuir significativamente a X. [ 26] Los nuevos términos habrían hecho que X ya no fuera software libre : costo cero para uso no comercial, pero pago en caso contrario. Después de que XFree86 parecía a punto de bifurcarse , [27] Open Group volvió a otorgar la licencia de X11R6.4 bajo la licencia tradicional en septiembre de 1998. [28] La última versión de Open Group fue el parche 3 de X11R6.4.
XFree86 se originó en 1992 a partir del servidor X386 para PC IBM 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 solo puerto de X hasta la implementación líder y más popular y el estándar de facto del desarrollo de X. [29]
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 este momento se había vuelto moribundo; [30] La mayor innovación técnica desde que se disolvió el Consorcio X se había producido en el proyecto XFree86. [31] En 1999, el equipo de XFree86 se unió a X.Org como miembro honorario (no remunerado), [32] alentado por varias empresas de hardware [33] [ verificación fallida ] interesadas en utilizar XFree86 con Linux y en su estatus como versión más popular de X.
En 2003, mientras la popularidad de Linux (y por tanto la base instalada de X) aumentaba, X.Org permaneció inactivo [34] y el desarrollo activo tuvo lugar en gran medida dentro de XFree86. Sin embargo, se desarrolló un considerable desacuerdo dentro de XFree86. El proyecto XFree86 adolecía de la percepción de un modelo de desarrollo demasiado catedralicio ; los desarrolladores no podían obtener acceso de confirmación CVS [35] [36] y los proveedores tenían que mantener extensos conjuntos de parches . [37] En marzo de 2003, la organización XFree86 expulsó a Keith Packard, que se había unido a XFree86 después del final del Consorcio MIT X original, con considerable malestar. [38] [39] [40]
X.Org y XFree86 comenzaron a discutir una reorganización adecuada para nutrir adecuadamente el desarrollo de X. [41] [42] [43] Jim Gettys había estado presionando fuertemente por un modelo de desarrollo abierto desde al menos el año 2000. [44] Gettys, Packard y varios otros comenzaron a discutir en detalle los requisitos para la gobernanza efectiva de X con desarrollo abierto.
Finalmente, haciendo 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. [45] La cláusula agregada a la licencia se basó en la cláusula publicitaria de la licencia BSD original, que fue considerada por la Free Software Foundation y Debian como incompatible con la Licencia Pública General GNU . [46] Otros grupos lo vieron en contra del espíritu del X original. Theo de Raadt de OpenBSD , por ejemplo, amenazó con bifurcar XFree86 citando preocupaciones sobre la licencia. [47] El problema de la licencia, combinado con las dificultades para introducir cambios, dejó a muchos con la sensación de que había llegado el momento de una bifurcación. [48]
A principios de 2004, varias personas de X.Org y freedesktop.org formaron la Fundación X.Org , y 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 (incluida la anterior X.Org) habían sido organizaciones proveedoras, la Fundación estaba dirigida por desarrolladores de software y utilizaba el desarrollo comunitario basado en el modelo de bazar , [ cita necesario ] que depende de la participación externa. La membresía estaba abierta a individuos, y la membresía corporativa se daba en forma de patrocinio. Varias corporaciones importantes como Hewlett-Packard actualmente [ ¿plazo? ] apoya a la Fundación X.Org.
La Fundación asume un papel de supervisión del 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 inspirado 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 los cambios de X11R6.6 combinados. Gettys y Packard habían tomado la última versión de XFree86 bajo la licencia anterior y, al destacar un modelo de desarrollo abierto y conservar la compatibilidad GPL, incorporaron a muchos de los antiguos desarrolladores de XFree86. [46]
Si bien X11 había recibido extensiones como soporte 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, incluida una arquitectura de fuentes "defectuosa" , un sistema de gráficos 2D "que siempre había estado pensado para ser aumentado y/o reemplazado" y problemas de latencia . [49] X11R6.8 salió a la luz en septiembre de 2004. Agregó nuevas características significativas, incluido el soporte preliminar para ventanas translúcidas y otros efectos visuales sofisticados, lupas y miniaturas de pantalla, e instalaciones 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 políticas para la apariencia visual.
El 21 de diciembre de 2005, [50] 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. [51] La Fundación lanzó X11R7.1 el 22 de mayo de 2006, aproximadamente cuatro meses después de 7.0, con mejoras considerables en sus funciones. [52]
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. [53]
Los nombres propios del sistema aparecen en la página del manual como X; Sistema de ventana X; X Versión 11; Sistema X Window, versión 11; o X11. [54]
El término "X-Windows" (a la manera del "Microsoft Windows", lanzado posteriormente) no está respaldado oficialmente; el gerente de lanzamiento del X Consortium, Matt Landau, afirmó en 1993: "No existe tal cosa como 'X Windows' o 'X Windows'. Window', a pesar del repetido mal uso de las formas por parte de los trapos comerciales" [55] – aunque ha sido de uso informal común desde principios de la historia de X [56] y se ha utilizado deliberadamente para lograr un efecto provocativo, por ejemplo en el Manual de los que odian a Unix . [5]
El sistema X Window ha matizado el uso de una serie de términos en comparación con el uso común, en particular "pantalla" y "pantalla", un subconjunto de los cuales se proporciona aquí por conveniencia:
El término "pantalla" no debe confundirse con la jerga más especializada " pantalla Zaphod ". Esta última es una configuración poco común que permite que varios 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 menor.
Sobre la perspectiva de futuras versiones, el sitio web X.org afirma: [74]
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" del sistema X Window; consulte el directorio de lanzamientos individuales de X.Org para descargas y los archivos xorg-announce o repositorios git para obtener detalles sobre los cambios incluidos.
No se ha propuesto ningún plan de lanzamiento para un lanzamiento katamari acumulativo X11R7.8.
Los comisarios de X realmente regatearon hasta casi nada hace unos cinco o seis años. Realmente no estaba siguiendo el ritmo de la tecnología.
{{cite journal}}
: Citar diario requiere |journal=
( ayuda )