Still sounds to me like you are living a pretty good life in the boonies. A lot was discussed on USENET in the 90s and on webpages in early 2000s about the "backwardness" of the X11 client/server terminology. My personal understanding, and the best explanation I can provide to clear up confusion, is that an X server "serves the display" to clients who want to "connect and display on it." Remember, on Linux, the user sitting at the X server's display does not even own the X server process. But to be clear, to do 3D acceleration there are some devices that need to be owned by the user, and the starting of the X session makes sure that ownership of those devices in /dev/ are handed to the user. I am rusty on this, but it has been like that since the 90s. And I just looked, and on my desktop right now I am the owner of /dev/xconsole. Yup... It can confuse people; I can see that. Your book probably has a much better high-level explanation of the graphics context than I can provide. In a nutshell, all drawing happens through some kind of graphics context, and there are separate graphics contexts for different functionality. Programmatically, you just create the GC type that you need and then you start using its resources. Not much to know here unless you are diving deep into the X architecture, which is probably not worth your time right now. If you have got as far as hacking Pascal together with C for X11 client applications, you are not exactly a n00b then... Unix sockets are great, and simple to program. "Unidirectional pipes," which is what you were talking about with those two file descriptors, I use all the time for real-time applications that require communication across threads. I use POSIX threads (always), and I make unidirectional pipes in order to pass data across them instead of using shared memory and dealing with race conditions. I put the output file descriptor of the unidirectional pipe in a "select() monitoring state with a long timeout, and trap events as they come, meaning one thread piping data to the other. It has never let me down. But if anyone has a better method, I am dying to hear it. > > Unix was engineered, and works like a symphony orchestra. > The fact that so much was ported to Linux/BSD from modern, desktop-use driven, single-user oriented platforms (like Windows) is a testament to an excellent OS architecture. Some old American programmers in the 70s can stand proudly. OK. We steered this thread sufficiently far away from flu-shots, and I feel good about that.