Fd.o: Building the Desktop in the Right Places
End users care only about applications that perform the desired tasks. They come to Linux to have the freedom to pick up these applications one by one. To them, integrated desktop means the freedom to choose any mix of programs and the assurance that they work together. A monolithic desktop environment can limit programmers as well. Making sure that your code cooperates with existing applications is essential to good software, if not the main characteristic that makes it useful. Being forced to use one or two development toolchains to achieve this result makes much less sense.
A sore spot of the GNU/Linux desktop used to be XFree86—development progressed too slowly and performance was not satisfying. Many tools, from fontconfig to zlib, were duplicated to avoid external dependencies. If one driver changed, the whole package had to be released again. On top of all this, the XFree86 license changed last year to one that appeared to prohibit GPL programs from linking to any of the new code. Several distributions immediately reacted by not shipping the new version with the license problem.
Freedesktop.org (FD.o) was formed in March 2000 to help developers solve the technical problems outlined above. The goal of this project is to create a base platform upon which every desktop can build. The method is to define independent specifications, complete with working code where needed. Formal standardization is left to other bodies. Following these specs should guarantee real interoperability among applications as early as possible during their development, ideally before it starts. All software will be placed under LGPL or X-style licenses. FD.o hosts a lot of neat projects, but this article introduces the main tools constituting the so-called FD.o platform.
The X Window System is a network transparent protocol for graphical display. GUI programs use X to give drawing commands to the software, called the X server, which actually controls the screen. Until last year, servers and libraries usually were found in monolithic packages. FD.o broke that bundle into parts, however, that now can be developed and packaged separately. The main advantage of this is that programmers and Linux distributions can mix and customize, at will, different implementations of each piece.
Other X improvements include the removal of all in-tree dependencies and the use of autotools as the build system and of the iconv library for all conversions between Unicode and other encodings. The libraries wrapping the X protocol are called Xlibs. FD.o released its first version of them in January 2004. They adhere to the X standard, so they can be used with any X server.
Even after several optimizations, the size of Xlibs may create problems on low-end platforms. Furthermore, some Xlibs request block until they receive a reply, even when it is not really necessary. This can interfere with some latency reduction features in the 2.6 kernels. Xlibs also do a lot to hide the protocol, through caching, layering and similar efforts; these efforts are an advantage in many cases, an overhead in others. Last but not least, support for the creation of X extensions is limited.
The FD.o proposal to solve these problems is the X C Binding, XCB for short. This second library can be a base for new toolkits and lightweight emulation of parts of the Xlibs API. XCB is designed to work transparently with POSIX thread or single-thread programs. The code maintains binary compatibility with Xlibs extensions and applications and might not require recompilation of extensions. This makes slow, gradual migration from Xlibs to XCB easier, without losing functionality. The next step along this path, the Xlibs Compatibility Layer (XCL), should allow existing applications built on Xlibs to take advantage of XCB.
FD.o hosts two alternatives to XFree86. The first one started as a fork of the XFree86 4.4-RC2 code before the license change. This server is called X.org and is used in the same way as XFree86. The other alternative, called Xserver, is the most promising option in the long run. It is the fork of Kdrive, which started years ago as a lightweight, heavily modified version of XFree86. Kdrive is small, partly because it has less code duplication with the kernel. Size reduction also came about by removing some obsolete features and driver modules. The much smaller code size makes it easier to start from Kdrive to build a whole new server.
The version of Xserver available today still is used mainly as a testbed for new extensions and features, such as transparency or OpenGL acceleration. Memory usage is minimized by performing a lot of calculations at runtime instead of always keeping the results in memory.
The goal of Xserver is to reduce slowness as well as the other phenomena that make looking at a screen unpleasant, including flickers. A new X extension, called Composite, allows double buffering of the entire screen. Of course, no server can be smarter than its dumbest client, but the lighter architecture should make it easier to find and fix slow code, wherever it is. The new server makes no impact at the toolkit level, except when the programmer chooses to take direct advantage of the new extensions.
Articles about Digital Rights and more at http://stop.zona-m.net CV, talks and bio at http://mfioretti.com
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- What's the tweeting protocol?
- A Topic for Discussion - Open Source Feature-Richness?
- Validate an E-Mail Address with PHP, the Right Way
- Mediated Reality: University of Toronto RWM Project
- Home, My Backup Data Center
1 hour 27 min ago
- Kernel Problem
11 hours 30 min ago
- BASH script to log IPs on public web server
15 hours 57 min ago
19 hours 32 min ago
- Reply to comment | Linux Journal
20 hours 5 min ago
- All the articles you talked
22 hours 28 min ago
- All the articles you talked
22 hours 32 min ago
- All the articles you talked
22 hours 33 min ago
1 day 2 hours ago
- Keeping track of IP address
1 day 4 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?