Y is a new window system. It's name was chosen for two very simple reasons:
- In the latin alphabet, it's the letter following X.
- It's not a latin character. It's cyrillic, and it's not
pronounced "why". It's pronounced "oo".
The Y Window System consists of three distinct pieces:
- The Micro Server
- Responsible for initializing and shutting down the graphics
hardware, setting up the initial root window, and send input
device events to interested clients.
- The Client Library
- The library used to do anything in Y. It has three possible
connection types. Local, which means it talks directly to the
hardware; Network, which means it talks to a remote Network
Server; and Memory, which means it draws directly to some area
of memory (a YImage.)
- The Network Server
Y attempts to address several limitations in the design of X. These include:
- The developer must keep in mind different Visual types when
writing her application. If there isn't code to handle a
particular visual class, it doesn't work with that visual.
- You have to constantly be aware of color handling.
Applications have to write code to gracefully handle the event
that a color isn't available, or that a colormap is full,
etc. For this reason some applications, such as netscape,
grab as many colors as possible on startup. While this
usually means netscape has enough colors, other applications
- X requires clients on the local machine to use the same
protocol as those on distant networks. There are extensions,
such as XShm, that help to alleviate this situation somewhat,
but they are more a bandaid than a fix.
- Any machine on a network running an X server is susceptable
to any number of security holes. Also, there is no way to
"turn off networking" in an X server. Even if you only want
to run local clients, your X server can be contacted from
- X has had authentication mechanisms grafted onto it after
the fact, trying to fix the relative lack of security present in
the initial release. These solutions are more bandaids to fix
problems that weren't properly addressed in the initial design.
To address the above, Y has the following features:
- There are no visual types. Every Y display, regardless of
color resolution, is available to the developer as 32 bit
RGBA color. If the graphics hardware doesn't directly support
this color depth, software dithering is performed. Also,
alpha-compositing is performed in software if unavailable
for a given graphics device.
- There is practically no communication between the clients
and the server (called the Micro Server) running on the local
machine. The client asks the Micro Server for some
information on startup (what devices it is using, what the ID
of the root window is, etc.) and the Micro Server sends events
from keyboard(s) and mouse(mice) back to the clients.
Everything that would normally involve an X protocol request
being generated is handled directly by the client, using
shared memory and direct access to the video hardware. This
includes any drawing operations, operations that affect the
window heirarchy, etc.
In the event of an operation that results in a window
heirarchy change, the client causing the change notifies all
the clients that have expressed interest in the changed
- The easiest way to lock out network connections in Y is to
just not run the Network Server. The Network Server is the
only program that accepts connections from remote machines and
turns them into Y drawing operations.
- If the Network Server is needed, there are varying levels of
authentication available, provided with plugable security
modules. They range from a simple password challenge to
ssh-styled public key authentication. Sessions can optionally
be encrypted, again using the same method as ssh.
These security modules are configured by the individual
running the server. In addition, the Network Server can be
configured to display a warning dialog when someone attempts
to connect from a remote host. The user can at that time
decide to allow the communication to proceed, or can terminate
the connection. Also, the Network Server can provide a list
of clients that are connected from remote machines, including
information regarding the connecting entity (login, full name,
time connected, etc.). The user running the Network Server
can then terminate a connection if they so wish.