Language Selection

English French German Italian Portuguese Spanish

X Factor - understanding the X window system

Filed under
Software

X was originally created in the mid-80s by a research group from MIT. Its goal was to create a windowing system quite unlike any that had been conceived before. Thus X's design differs greatly from that of other windowing systems, having designed-in support for many elements which are unique ­ features which in fact are nowadays often being hacked into other windowing systems.

More often than not, such attempts are kludgy and don't work well, because they lack the ground-up desig X offers.

X went through a number of iterations because the original releases were not under a copyleft license. Every Unix developer created his own version, usually only modifying small parts, resulting in divergence into many incompatible versions, most of which fell under proprietary licences.

As a result, a standards body was eventually created to oversee the development of X. This body, known as the X Consortium, includes amongt its members IBM, Hewlett Packard and even Microsoft.

The X server has two important functions. Firstly, it speaks to the hardware; this means the X server needs to contain the driver for your graphics card, mouse, keyboard etc. Secondly, it speaks to X clients (every X program, from xterm to OpenOffice.org is an X client). Thus no X client ever talks directly to the hardware.

The most common channel is Unix Domain Sockets (UDS, a very fast mechanism for interprocess communication on Unix) which provides the highest speeds for local usage (for example where the X server and X clients are on the same machine). However it can also run over several network protocols, such as TCP/IP, allowing you to use your local X server to run a program on a distant machine over the Internet.

Luckily, working directly with the X protocol is seldom needed because X also provides xlib. Xlib is essentially a library of standard X tasks, such as basic drawing primitives and event handling. Xlib is written in C (with wrappers to many languages) and it in turn speaks to the X protocol for you. Xlib takes care of the low-level detail part of using the X protocol, such as establishing a connection over the appropriate channel and talking to the server.

Today the two most important widget sets in the Linux world are GTK and QT respectively. Their importance is greatly enhanced by the fact that these are the two toolkits on which the Gnome and KDE desktops are respectively built. Many other widget sets exist, and although none are as feature-rich as GTK or QT, they are still often used.

The two most important desktop environments today are of course KDE and Gnome, as most new Linux applications are built for one or the other. Currently KDE and Gnome basically match each other for features and which one a user prefers tend to be a matter of taste rather than a technical decision. Almost all Linux users use one of these two. Old-time Unix users and programmers often shun them however, preferring minimalist desktops.

Full Article.

More in Tux Machines

10 tips for easier collaboration between office suites

Yes, you are likely using the Microsoft formats for your documents. However, they don't always follow OpenDocument Format (ODF) standards. Instead of opting for the proprietary Microsoft formats, switch over to one that's welcomed by nearly all office suites: ODF. You'll find a much more seamless collaboration process and fewer gotchas when moving between office suites. The only platform that can have a bit of trouble with this format is Android. The one Android office suite that works well with ODF is OfficeSuite 7 Pro. Read more

Outsourcing your webapp maintenance to Debian

It turns out that I'm not the only one who thought about this approach, which has been named "debops". The same day that my talk was announced on the DebConf website, someone emailed me saying that he had instituted the exact same rules at his company, which operates a large Django-based web application in the US and Russia. It was pretty impressive to read about a real business coming to the same conclusions and using the same approach (i.e. system libraries, deployment packages) as Libravatar. Regardless of this though, I think there is a class of applications that are particularly well-suited for the approach we've just described. If a web application is not your full-time job and you want to minimize the amount of work required to keep it running, then it's a good investment to restrict your options and leverage the work of the Debian community to simplify your maintenance burden. The second criterion I would look at is framework maturity. Given the 2-3 year release cycle of stable distributions, this approach is more likely to work with a mature framework like Django. After all, you probably wouldn't compile Apache from source, but until recently building Node.js from source was the preferred option as it was changing so quickly. While it goes against conventional wisdom, relying on system libraries is a sustainable approach you should at least consider in your next project. After all, there is a real cost in bundling and keeping up with external dependencies. Read more

How Intel HD Graphics On Linux Compare To Open-Source AMD/NVIDIA Drivers With Steam On Linux

As earlier this week I did a 20-way AMD Radeon open-source comparison, looked at the most energy efficient Radeon GPUs for Linux gaming, and then yesterday provided a look at the fastest NVIDIA GPUs for open-source gaming with Nouveau, in this article is a culmination of all the open-source graphics tests this week while seeing how Intel Haswell HD Graphics fall into the mix against the open-source Radeon R600/RadeonSI and Nouveau NV50/NVC0 graphics drivers. Read more

Leftovers: Gaming