How Linux works
Have you ever wondered what exactly DCOP is, or where your drivers are hidden?
If you come to Linux from Windows or OS X rather than through the server room, the idea that there's something called a desktop is quite a strange one. It's like trying to explain that Microsoft Windows is an operating system to someone who just thinks it's 'the computer'.
The desktop is really just a special kind of application that has been designed to aid communication between the user and any other applications you may run.
This communication part is important, because the desktop always needs to know what's happening and where. It's only then it can do clever things like offer virtual desktops, minimise applications, or divide windows into different activities.
There are two ways that a desktop helps this to happen. The first is through something called its API, which is the Application Programming Interface. When a programmer developers an application using a desktop's API, they're able to take advantage of lots of things the desktop offers. It could be spell checking, for example, or it could be the list of contacts you keep in another app that uses the same API.
MOBLIN: Moblin and UNR make good use of the Clutter framework to offer accelerated and smooth scrolling graphics
When lots of applications use the same API, it creates a much more homogeneous and refined experience, and that's exactly what we've come to expect of both Gnome and KDE desktops.
The reason why K3b works so well with your music files is because it's using the same KDE API that your music player uses, and it's the same with many Gnome apps too.
Get daily insight, inspiration and deals in your inbox
Sign up for breaking news, reviews, opinion, top tech deals, and more.
Toolkits
But applications designed for a specific desktop environment don't have to use any one API exclusively. There are probably more APIs than there are Linux distributions, and they can do anything from complex mathematics to hardware interfacing.
This is where you'll hear terms like Clutter and Cairo bandied around, as these are additional toolkits that can help a programmer build more unified-looking applications.
Clutter, for example, is used by both Ubuntu Netbook Remix and Moblin to create hardware-accelerated, smoothly animated GUIs for low-power devices.
It's Clutter that scrolls the top bar down in Moblin, for instance, and provides the fade-in effects of the launch menu in UNR. Cairo helps programmers create vector graphics easily, and is the default rendering engine in GTK, the toolkit behind Gnome, for many of its icons.
Rather than locking an image to a specific resolution, vector-based images can be infinitely scaled, making them perfect for images that are going to be used in a variety of resolutions. Inter-process communication The second way the desktop helps is by using something called 'inter-process communication'.
As you might expect from its name, this helps one process talk to another, which in the case of a desktop, is usually one application talking to another. This is important because it helps a desktop feel cohesive: your music player might want to know when an MP3 player has been connected, for example, or your wireless networking software may want to use the system-wide notification system to let you know its found an open network.
In general terms, inter-process communication is the reason why GTK apps perform better on the Gnome desktop, and KDE apps work well with KDE, but the great thing about both desktops is that they use the same compatible method for inter-process communication – a system called D-BUS.
So why do Gnome and KDE feel so different to each another? Well, it's because they use different window managers.
The idea of a window manager stretches right back to the time when Unix systems first crawled out of the primordial soup of the command line, and started to display a terminal within a window. You could drag this single window across the cross-hatched background, and open other terminals that you could also manipulate thanks to something called TWM, an acronym that reputedly stood for Tom's Window Manager.
It didn't do much, but it did free the user from pages of text. You could move windows freely around the display, resize them, maximize them and let them overlap one another. And this is exactly what Gnome and KDE's window managers are still doing today.
KDE's window manager, dubbed KWin, augments the moving and management components of TWM with some advanced features, such as its new-found abilities to embed any window within a tabbed border, snap applications to an area of the screen or move specific applications to preset virtual activities on their own desktops.
KWin also recreates plenty of compositing effects, such as window wobble, drop shadows and reflections, an idea pioneered by Compiz. This is yet another window manager, but rather than adding functionality, it was created specifically to add eye-candy to the previously static world of window management.
Compiz is still the default replacement for Gnome's window manager (Metacity), and you can get it on your Gnome machine if you enable the advanced effects in the Visual Effects panel. You'll find that it seamlessly replaces the default drawing routines with hardware-accelerated compositing.
Dependencies
One of biggest hurdles for people when they switch to Linux is the idea that you can't simply download an executable from the internet and expect it to run.
When a new version of Firefox is released, for example, you can't just grab a file from www.mozilla.org, save it to your desktop and double-click on the file to install the new version. A few distributions are getting close to this ideal, but that's the problem.
It's distribution-dependent, and we're no closer to a single solution for application installation than we were 10 years ago. The problem is down to dependencies and the different ways distributions try to tame them.
A dependency is simply a package that an application needs if it's to work properly. These are normally the APIs that the developers have used to help them develop the application, and they need to be included because the application uses parts of its functionality.
When they're bundled in this way they're known as libraries, because an app will borrow one or two components from a library to add to its own functionality.
Clutter is a dependency for both Moblin and UNR, for instance, and it would need to be installed for both desktops to work. And while Firefox may seem relatively self-contained on the surface, it has a considerable list of dependencies, including Cairo, a selection of TrueType fonts and even an audio engine.
Other operating systems solve this problem by statically linking applications to the resources they require. This means that they bundle everything that an app needs in one file.
All dependencies are hidden within the setup.msi file on Windows, for example, or the DMG file on OS X, giving the application or utility everything it needs to be able to run without any further additions.
The main disadvantage with this approach is that you'll typically end up with several different versions of the same library on your system. This takes up more space, and if a security flaw is found, you'll have to update all the applications rather than just the single library.