The X Window System uses a client-server architecture. The X server runs on the machine that has the display (monitors + input devices), while X clients can run on any other machine, and connect to the X server using the X protocol (not directly, but rather by using a library, like Xlib, or the more modern non-blocking event-driven XCB). The X protocol is designed to be extensible, and has many extensions (see xdpyinfo(1) ).

The X server does only low level operations, like creating and destroying windows, doing drawing operations (nowadays most drawing is done on the client and sent as an image to the server), sending events to windows, ... You can see how little an X server does by running X :1 & (use any number not already used by another X server) or Xephyr :1 & (Xephyr runs an X server embedded on your current X server) and then running xterm -display :1 & and switching to the new X server (you may need to setup X authorization using xauth(1) ).

As you can see, the X server does very little, it doesn't draw title bars, doesn't do window minimization/iconification, doesn't manage window placement... Of course, you can control window placement manually running a command like xterm -geometry -0-0 , but you will usually have an special X client doing the above things. This client is called a window manager. There can only be one window manager active at a time. If you still have open the bare X server of the previous commands, you can try to run a window manager on it, like twm , metacity , kwin , compiz , larswm , pawm , ...

As we said, X only does low level operations, and doesn't provide higher level concepts as pushbuttons, menus, toolbars, ... These are provided by libraries called toolkits, e.g: Xaw, GTK, Qt, FLTK, ...

Desktop environments are collections of programs designed to provide a unified user experience. So desktop environments typically provides panels, application launchers, system trays, control panels, configuration infrastructure (where to save settings). Some well known desktop environments are KDE (built using the Qt toolkit), Gnome (using GTK), Enlightenment (using its own toolkit libraries), ...

Some modern desktop effects are best done using 3d hardware. So a new component appears, the composite manager. An X extension, the XComposite extension, sends window contents to the composite manager. The composite manager converts those contents to textures and uses 3d hardware via OpenGL to compose them in many ways (alpha blending, 3d projections, ...).

Not so long ago, the X server talked directly to hardware devices. A significant portion of this device handling has been moving to the OS kernel: DRI (permitting access to 3d hardware by X and direct rendering clients), evdev (unified interface for input device handling), KMS (moving graphics mode setting to the kernel), GEM/TTM (texture memory management).

So, with the complexity of device handling now mostly outside of X, it became easier to experiment with simplified window systems. Wayland is a window system based on the composite manager concept, i.e. the window system is the composite manager. Wayland makes use of the device handling that has moved out of X and renders using OpenGL.

As for Unity, it's a desktop environment designed to have a user interface suitable for netbooks.