Fd.o: Building the Desktop in the Right Places
Vector graphics create an image by drawing more or less complex lines and filling in the resulting areas with colors. The corresponding files are small in size and can be scaled at any resolution without losses. Consequently, this technique is interesting for everybody who wants to be sure that what they print is what they see. Unfortunately, X knows how to manage screen pixmaps of text, rectangles and such, but it simply ignores printing or vector graphics. This is one of the reasons why we still do not have 100% consistency between screen, paper and saved files.
The FD.o solution is Cairo, “a new 2D vector graphics library with cross-device output support”. In plain English, this means the result is the same on all output media. Externally, Cairo provides user-level APIs similar to the PDF 1.4 imaging model.
Through different back ends, Cairo can support different output devices. The first one is screens, through either Xlibs or XCB, and in-memory image buffers, which then can be saved to a file or passed to other applications. PostScript and PNG output already is possible, and PDF is planned. OpenGL accelerated output also will be available through a back end called Glitz. In addition, it will be possible to use Glitz as a standalone layer above OpenGL. Cairo language bindings exist for C++, Java, Python, Ruby and GTK+.
The developers of OpenOffice.org also are planning to use Cairo after version 2.0 of the OOo suite is released, possibly even as a separately downloadable graphics plugin. Still being in active development and minus a completely stable API, Cairo is not included yet in official FD.o platform releases.
D-BUS is a binary protocol for Inter Process Communication (IPC) among the applications of one desktop session or between that session and the operating system. The second case corresponds to dynamic interactions with the user whenever new hardware or software is added to the computer. The internals of D-BUS were discussed by Robert Love in “Get on the D-BUS” in the February 2005 issue of Linux Journal. As far as the desktop end user is concerned, D-BUS should provide at least the same level of service currently available in both GNOME and KDE. To achieve this, both a system dæmon called message bus and a per-user, per session dæmon are available. It also is possible for any two programs to communicate directly by using D-BUS, to maximize performance. For the same reason, because the programs using the same D-BUS almost always live inside the same host, a binary format is used instead of plain XML.
The message bus dæmon is an executable acting like a router. By passing messages instead of byte streams among applications, the dæmon makes their services available to the desktop. Normally there are multiple independent instances of this dæmon on each computer. One would be used for system-level communications, with heavy security restrictions on what messages it can accept. The others would be created for each user session, to serve applications inside it. The systemwide instance of D-BUS can become a security hole: services running as root must be able to exchange information and events with user applications. For this reason, it is designed with limited privileges and runs in a chroot jail. D-BUS-specific security guidelines can be found on the Fd.o Web site (see on-line Resources).
Most programmers do not need to talk to the D-BUS protocol directly. There are wrapper libraries to use it in any desired framework or language. In this way, everybody is able to maintain his or her preferred environment rather than learning or switching to a new one specifically for IPC. End users, again, receive gains in interoperability: KDE, GNOME and Mono programs will be able to talk to one another, regardless of toolkit. As with Cairo, the first versions of the FD.o platform don't include D-BUS, because its API is not stabilized yet. But, the developers consider D-BUS to be a cornerstone of future releases. D-BUS also is meant to replace DCOP in KDE 4.
Only time will tell if the first implementations of Fd.o are good enough and if the related specifications are valid. In this context, valid means something complete that can be re-implemented from scratch with totally new code, if one feels like doing so. I am convinced, however, that the approach is valid and has more potential than any other “complete desktop” already existing.
The two most frequent complaints I've read so far are 1) the current desktops would lose their identities, becoming “only user-interface stuff” and 2) FD.o is not standards, simply other implementations. My personal response to the first concern is, even if it happened, would it really be a problem? Most end users wouldn't even realize it, nor would they be concerned at all. They most likely would note the improvements I mentioned at the beginning and be done with it. Making sure that all applications can cooperate, no matter how they were developed, also would make Linux much more acceptable as a corporate desktop, shutting up a whole category of arguments in favor of proprietary solutions.
If protocols and formats stop being tied to specific implementations or toolkits, they can be shared across multiple “desktop environments”. Code stability and lightness would directly benefit from this, as would innovation. Completely new programs could interact immediately with existing ones. I therefore hope that this trend is generalized and that more application-independent standards are submitted to FD.o, covering file formats, sound schemes, color and tasks settings. Imagine one mail configuration file that could be used by any e-mail client, from Evolution to mutt, or one bookmark file usable by every browser from Mozilla to Lynx.
As far as the second objection goes—FD.o is not standards, simply other implementations—that's exactly how free software and RFC work. As long as specifications are written alongside the code, concepts can be validated in the field as soon as possible. For the record, this same thing currently is happening with OO.o and the OASIS Office standard (see LJ, April 2004). The file format started and matured inside StarOffice and OO.o, but now it has a life of its own. The committee currently includes representatives from KOffice, and any future office suite can use it as its native format, starting only from the specification.
Some traps do exist along this path, but as far as I can tell, the developers are aware of them and determined to avoid them. The first risk is to develop standards that for one reason or another work well only on Linux, leaving out the other UNIXes. The other is resource usage: all the magic described here would look much less attractive if it required doubling the RAM to run smoothly. As far as we know today, however, this seems to be an unlikely possibility. In any case, this is the right moment to join this effort. Happy hacking!
Articles about Digital Rights and more at http://stop.zona-m.net CV, talks and bio at http://mfioretti.com
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- My +1 Sword of Productivity
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide